Bug 245654 - ig4(4): Intel Bay Trail I2C not recognized
Summary: ig4(4): Intel Bay Trail I2C not recognized
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.1-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: Vladimir Kondratyev
URL:
Keywords: needs-qa, patch
Depends on:
Blocks:
 
Reported: 2020-04-16 00:39 UTC by xspbe3ho3p5uac
Modified: 2020-07-25 23:57 UTC (History)
1 user (show)

See Also:
koobs: maintainer-feedback? (wulf)
koobs: mfc-stable12?


Attachments
pciconf -l; dmesg (1.03 KB, text/plain)
2020-04-16 00:39 UTC, xspbe3ho3p5uac
no flags Details
pciconf -lv; dmesg.boot (15.71 KB, text/plain)
2020-04-16 01:19 UTC, xspbe3ho3p5uac
no flags Details
BayTrail_PCI_IDs.patch (1.66 KB, patch)
2020-04-16 09:09 UTC, Vladimir Kondratyev
no flags Details | Diff
BayTrail_PCI_IDs.patch (1.78 KB, patch)
2020-04-17 00:25 UTC, Vladimir Kondratyev
no flags Details | Diff
dmesg; pciconf -lv; devinfo -rv (99.70 KB, text/plain)
2020-04-18 00:53 UTC, xspbe3ho3p5uac
no flags Details
ls /dev/iic*; i2c -s; acpidump -dt (436.69 KB, text/plain)
2020-04-19 01:26 UTC, xspbe3ho3p5uac
no flags Details
dmesg (57.91 KB, text/plain)
2020-04-20 23:39 UTC, xspbe3ho3p5uac
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description xspbe3ho3p5uac 2020-04-16 00:39:16 UTC
Created attachment 213438 [details]
pciconf -l; dmesg

Hi,

I believe the I2C bus in my ASUSTOR AS5002T (Bay Trail CPU) is not being recognized properly:

~ $ ls /dev|grep iic                                                                                
~ $ 

According to the ig4(4) HARDWARE section, Bay Trail devices should be supported.

I tried adding all of the PCI IDs (80860f41-0f47) to sys/dev/ichiic/ig4_pci.c and recompiling, which caused `iic` devices to show up in /dev, but they did not seem to be functioning properly via i2c(8) and I'm worried I could mess up my hardware if I try any more (I am NOT a developer).

I can provide any data you need, please let me know how I can help.

Thank you!
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2020-04-16 00:59:03 UTC
Thank you for the report. Could you provide full versions of /var/run/dmesg.boot and pciconf -lv as attachments please
Comment 2 xspbe3ho3p5uac 2020-04-16 01:19:10 UTC
Created attachment 213440 [details]
pciconf -lv; dmesg.boot
Comment 3 Vladimir Kondratyev freebsd_committer 2020-04-16 09:09:45 UTC
Created attachment 213457 [details]
BayTrail_PCI_IDs.patch

Please:

1. Upgrade sources to latest STABLE
2. Apply attached patch
3. Rebuild and reinstall kernel

than post here output of:
1. dmesg after verbose boot (with -v option)
2. pciconf -lv
3. devinfo -rv
Comment 4 Vladimir Kondratyev freebsd_committer 2020-04-17 00:25:42 UTC
Created attachment 213474 [details]
BayTrail_PCI_IDs.patch

Missing 4-th port added.
Comment 5 xspbe3ho3p5uac 2020-04-18 00:53:16 UTC
Created attachment 213514 [details]
dmesg; pciconf -lv; devinfo -rv
Comment 6 Vladimir Kondratyev freebsd_committer 2020-04-18 10:29:45 UTC
(In reply to xspbe3ho3p5uac from comment #5)
It is appeared that 2 I2C devices are connected to device that was missed in first version of  BayTrail_PCI_IDs.patch. :-(
Please, apply 2-nd version and rebuild your kernel.
After that, you can try to scan both your I2C buses that have I2C children in ACPI DST table with following commands:
i2c -s -f /dev/iic3
i2c -s -f /dev/iic5
I do not know what to do except to scan as we do not have drivers for ATML2000 and CLK devices in our OS
Comment 7 xspbe3ho3p5uac 2020-04-18 18:43:33 UTC
I actually had applied the latest patch, though I do see that for some reason ID 0f438086 is not recognized by the driver. The ID that was mistakenly left out in the first patch, 0f448086, seems to be working, as you can see in my latest `pciconf -lv`.

I also have a feeling I may have been chasing my own tail on this one. Funnily enough, this machine doesn't actually seem to have any devices attached on the I2C bus. I thought the indicator LEDs were accessed through I2C, but now I'm almost certain they work through GPIO (however, I cannot get any of the pins to change state, even with bytgpio(4), but that is another issue).
Comment 8 Vladimir Kondratyev freebsd_committer 2020-04-18 20:31:43 UTC
(In reply to xspbe3ho3p5uac from comment #7)
> this machine doesn't actually seem to have any devices attached on the I2C bus.

This machine have at least 3 I2C devices defined in DSDT table. You can find them with searching of "devinfo -rv" output for 'handle=\_SB_.I2C' string. I doubt that they can be used for something good, but it would be nice to read at least 1 byte from any of them. BayTrail is known for sharing I2C lines with power management unit so I would like to know if I2C works at all without dedicated support for this unit.

Could you post output of "sudo acpidump -dt" command here too. It looks like one of I2C devices were not recognized properly by ACPI subsystem.
Comment 9 xspbe3ho3p5uac 2020-04-19 01:26:43 UTC
Created attachment 213553 [details]
ls /dev/iic*; i2c -s; acpidump -dt
Comment 10 Vladimir Kondratyev freebsd_committer 2020-04-20 14:20:46 UTC
(In reply to xspbe3ho3p5uac from comment #9)

There are only 6 /dev/iic* rather than 7. One device is still not configured.

It looks like your ACPI BIOS has so called I2C OpRegion handler. I ported support for it from DragonFlyBSD recently but it is disabled by default as non tested.
It is used by ACPI BIOS to communicate with peripheral devices e.g. battery charge controllers over I2C bus. It can be enabled with placing following line to /boot/loader.conf:

hw.iicbus.enable_acpi_space_handler=1

You should reboot after that. I do not know how to test it though. Maybe verbose boot will reveal some debugging messages.
Comment 11 xspbe3ho3p5uac 2020-04-20 23:39:06 UTC
Created attachment 213622 [details]
dmesg

Here is the dmesg after I enabled `hw.iicbus.enable_acpi_space_handler`. Let me know if you have any ideas on how to get that last device to show up.

Also, I noticed a couple lines in the latest dmesg. Am I doing something wrong here? I've removed all the *_load lines from /boot/loader.conf.

```
interface ig4iic.1 already present in the KLD 'kernel'!
linker_load_file: /boot/kernel/ig4.ko - unsupported file type
```

Sorry if this is a stupid question, I'm not very familiar with FreeBSD yet.
Comment 12 Vladimir Kondratyev freebsd_committer 2020-04-23 14:57:03 UTC
(In reply to xspbe3ho3p5uac from comment #11)
> Here is the dmesg after I enabled `hw.iicbus.enable_acpi_space_handler`.
> Let me know if you have any ideas on how to get that last device to show up.

Unfortunately, nothing interesting. Except the 3-rd controller is dysfunctional. 
Full power off/on cycle may be required to restore it. I hope, all 7 /dev/iic* will appear after that.

> interface ig4iic.1 already present in the KLD 'kernel'!
> linker_load_file: /boot/kernel/ig4.ko - unsupported file type

Looks like you have ig4 compiled in to kernel and something ?devmatch? tries to load it one more time as a module. Most probably, it is harmless in the case if you have `device ig4` line in your kernel config.
Comment 13 xspbe3ho3p5uac 2020-04-23 21:49:30 UTC
(In reply to Vladimir Kondratyev from comment #12)
Sadly, a full shutdown, unplug, and boot does not cause the missing /dev/iic to appear.
Comment 14 commit-hook freebsd_committer 2020-04-26 20:17:06 UTC
A commit references this bug:

Author: wulf
Date: Sun Apr 26 20:16:19 UTC 2020
New revision: 360355
URL: https://svnweb.freebsd.org/changeset/base/360355

Log:
  ig4(4): Add PCI IDs for Intel Bay Trail I2C controllers.

  PR:		245654
  Reported by:	<xspbe3ho3p5uac@protonmail.com>
  MFC after:	1 week

Changes:
  head/sys/dev/ichiic/ig4_pci.c
Comment 15 commit-hook freebsd_committer 2020-05-03 23:40:47 UTC
A commit references this bug:

Author: wulf
Date: Sun May  3 23:40:16 UTC 2020
New revision: 360618
URL: https://svnweb.freebsd.org/changeset/base/360618

Log:
  MFC r360355:

  ig4(4): Add PCI IDs for Intel Bay Trail I2C controllers.

  PR:		245654
  Reported by:	<xspbe3ho3p5uac@protonmail.com>

Changes:
_U  stable/12/
  stable/12/sys/dev/ichiic/ig4_pci.c