Bug 221777
| Summary: | merge the latest changes to the ig4 module from DragonFly BSD and add Kaby Lake / Intel 100 series platform support | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | marc.priggemeyer | ||||||||
| Component: | kern | Assignee: | Oleksandr Tymoshenko <gonzo> | ||||||||
| Status: | Closed FIXED | ||||||||||
| Severity: | Affects Some People | CC: | KOT, b4, daniel.piecebypiece, emaste, gonzo, nc | ||||||||
| Priority: | --- | Keywords: | patch | ||||||||
| Version: | CURRENT | ||||||||||
| Hardware: | amd64 | ||||||||||
| OS: | Any | ||||||||||
| Attachments: |
|
||||||||||
Has there been any further progress on this ? Specifically about supporting HID over I2C ? I would love to contribute, if someone is already working on it. I have a working implementation on my laptop (Dell Latitude 5480 with Kabylake CPU and chipset) but didn't find the time to submit for reviews. Hopefully, that will happen be soon. That sounds awesome. I would love to test your patch if you don't mind. I have a Huawei MateBook X Pro, also Kabylake. I can also take a look at your code and give you some feedback. I'm not exactly a FreeBSD developer but have done quite some coding. This was partially committed in base r330558 as a part of the review D13654 The only missing part is re-initialization after power down I have build a version of ig4 based on base r330558. The result I get is the same as with the head revision. I tested against 11.2 and 12-Current. Is there any additional configuration needed. E.g. device hints ? ig4iic_pci0: <Intel Sunrise Point-LP I2C Controller-0> mem 0x2ff3021000-0x2ff3021fff at device 21.0 on pci0 ig4iic_pci0: Using MSI ig4iic_pci0: controller error during attach-2 iicbus0: <Philips I2C bus> on ig4iic_pci0 ig4iic_pci1: <Intel Sunrise Point-LP I2C Controller-1> mem 0x2ff3020000-0x2ff3020fff at device 21.1 on pci0 ig4iic_pci1: Using MSI ig4iic_pci1: controller error during attach-2 iicbus1: <Philips I2C bus> on ig4iic_pci1 (In reply to Daniel from comment #5) The board I used for tests has BIOS option to switch I2C controllers between ACPI and PCI mode. In PCI mode ig4 works as expected in ACPI mode attach fails with the same error. I didn't have time to investigate it popery yet. As a workaround you can check for something like this in your device's BIOS. Could you also post the output of acpidump -dt here? It may be useful. (In reply to Oleksandr Tymoshenko from comment #6) Please consider these two parts from the patch I provided last year: In ig4_reg.h: +/* Newer versions of the I2C controller allow to check whether + * the above ASSERT/DEASSERT is necessary by querying the DEVIDLE_CONTROL + * register. + * + * the RESTORE_REQUIRED bit can be cleared by writing 1 + * the DEVICE_IDLE status can be set to put the controller in an idle state + * */ + +#define IG4_RESTORE_REQUIRED 0x0008 +#define IG4_DEVICE_IDLE 0x0004 and in ig4_iic.c + v = reg_read(sc, IG4_REG_DEVIDLE_CTRL); + if (sc->version == IG4_SKYLAKE && (v & IG4_RESTORE_REQUIRED) ) { + reg_write(sc, IG4_REG_DEVIDLE_CTRL, IG4_DEVICE_IDLE | IG4_RESTORE_REQUIRED); + reg_write(sc, IG4_REG_DEVIDLE_CTRL, 0); + + reg_write(sc, IG4_REG_RESETS_SKL, IG4_RESETS_ASSERT_SKL); + reg_write(sc, IG4_REG_RESETS_SKL, IG4_RESETS_DEASSERT_SKL); + DELAY(1000); + } This reinitialization makes sure to activate the I2C controller after power down if necessary. It is based on the Intel 100 series PCH documentation. Please also consider that there currently is a faulty version check in the preprocessor-deactivated code block in ig4_iic.c that was committed to base. Created attachment 196137 [details]
Huawei_MateBook_X_Pro_acpidump
Please find my acpidump attached.
(In reply to Daniel from comment #9) FYI, please check https://reviews.freebsd.org/D16698 (In reply to marc.priggemeyer from comment #7) Success !!! With your changes Marc, the "ig4iic_pci1: controller error during attach-2" is gone. I did a quick test loading "kldload iic" and then run sudo i2c -f /dev/iic1 -s which reports now "Scanning I2C devices on /dev/iic1: 15". At iic0 it finds a device at 0x20. That matches my expactation. Similar tests done Ubuntu show the same result. So my touchpad and trackpad now seem to be visible. Thanks a lot. I just tested against 12-Current for now. I also tested suspend/resume. This still does not work. Is there any other tests I can do to confirm your changes work ? Thank you for sharing https://reviews.freebsd.org/D16698. I will have a look. (In reply to Daniel from comment #11) That means that you can now access your I2C devices. There still is a bug in ig4 that, I am not sure if I remember correctly, but either left- or right shifts all I2C addresses by one bit (I think it was division, so it should be 2*your device address). Since it is consistent throughout modules (for example the cyapa module besides others) it won't be a show stopper but it should be addressed at some point. You could try to apply the patch I now submitted for review and check if the hid device can successfully be enumerated on your device (acpi_iichid). The code ran on my laptop for almost a year now without issues but please consider it unstable. It might cause a kernel panic on your laptop. Apply patch. Go to sys/modules/i2c/iichid, run make and kldload. Go to sys/modules/acpi/acpi_iichid, run make and kldload. You should then be able to see some output on dmesg. If your trackpad has pointing device capabilities besides touchpad, you will have a good chance that you can read descriptors from /dev/ims* In any case you can use vmstat -i to verify interrupt handling if attach is successful. (In reply to marc.priggemeyer from comment #12) I did a first test of https://reviews.freebsd.org/D16698 Basically just compiled it and loader both kernel modules as you suggested. It did not compile right away but finally I got it. I will give it another shot on a clean kernel tree later. Is it ok to follow up here or should we continue in phabricator or file a new ticket ? Dmesg shows: iichid_acpi0: <HID over I2C (ACPI)> on acpi0 iichid_acpi0: descriptor register address is 20 iichid_acpi0: unexpected type 17 while parsing Current Resource Settings (_CSR ) iichid_acpi0: parent device is "\134_SB_.PCI0.I2C0" iichid0: <HID over I2C> at addr 0x20 on iicbus0 iichid0: ADDR 0x20 REG 0x20 iichid0: determined (len=34) and described (len=36) input report lengths misma tch iichid_acpi0: added iichid0 ADDR 0x20 REG 0x20 to iicbus0 iichid_acpi0: allocated irq at 0x0 and rid 0 iichid_acpi0: could not allocate IRQ resource iichid_acpi1: <HID over I2C (ACPI)> on acpi0 iichid_acpi1: descriptor register address is 20 iichid_acpi1: unexpected type 17 while parsing Current Resource Settings (_CSR ) iichid_acpi1: parent device is "\134_SB_.PCI0.I2C1" iichid1: <HID over I2C> at addr 0x15 on iicbus1 iichid1: ADDR 0x15 REG 0x20 iichid1: determined (len=62) and described (len=64) input report lengths misma tch iichid_acpi1: added iichid1 ADDR 0x15 REG 0x20 to iicbus1 iichid_acpi1: allocated irq at 0x0 and rid 0 iichid_acpi1: could not allocate IRQ resource (In reply to Daniel from comment #13) I would suggest to continue on phaebricator. At the bottom line, the changes to ig4 should be merged to resolve this issue. (In reply to marc.priggemeyer from comment #14) I will try to prepare a patch against current base such that the merge will be easier for committers. Ok. Let's follow up on Phabricator. Just a last update here. I have merged https://reviews.freebsd.org/D16698 into a clean tree. I have used: http://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/12.0-ALPHA1/src.txz It looks better than before: iichid_acpi0: <HID over I2C (ACPI)> on acpi0 iichid_acpi0: descriptor register address is 20 iichid_acpi0: unexpected type 17 while parsing Current Resource Settings (_CSR) iichid_acpi0: parent device is "\134_SB_.PCI0.I2C0" iichid0: <HID over I2C> at addr 0x20 on iicbus0 iichid0: ADDR 0x20 REG 0x20 iichid0: determined (len=34) and described (len=36) input report lengths mismatch iichid_acpi0: added iichid0 ADDR 0x20 REG 0x20 to iicbus0 iichid_acpi0: allocated irq at 0x0 and rid 0 iichid_acpi0: could not allocate IRQ resource iichid_acpi1: <HID over I2C (ACPI)> on acpi0 iichid_acpi1: descriptor register address is 20 iichid_acpi1: unexpected type 17 while parsing Current Resource Settings (_CSR) iichid_acpi1: parent device is "\134_SB_.PCI0.I2C1" iichid1: <HID over I2C> at addr 0x15 on iicbus1 iichid1: ADDR 0x15 REG 0x20 iichid1: 2 buttons and [XY] coordinates ID=2 iichid1: 2 buttons and [XY] coordinates ID=2 iichid1: determined (len=62) and described (len=64) input report lengths mismatch iichid_acpi1: added iichid1 ADDR 0x15 REG 0x20 to iicbus1 iichid_acpi1: allocated irq at 0x0 and rid 0 iichid_acpi1: could not allocate IRQ resource A commit references this bug: Author: gonzo Date: Mon Aug 13 18:53:15 UTC 2018 New revision: 337719 URL: https://svnweb.freebsd.org/changeset/base/337719 Log: [ig4] Fix initialization sequence for newer ig4 chips Newer chips may require assert/deassert after power down for proper startup. Check respective flag in DEVIDLE_CTRL and perform operation if neccesssary. PR: 221777 Submitted by: marc.priggemeyer@gmail.com Obtained from: DragonFly BSD Tested on: Thinkpad T470 Changes: head/sys/dev/ichiic/ig4_iic.c head/sys/dev/ichiic/ig4_reg.h (In reply to commit-hook from comment #17) I pulled a fresh copy of https://svnweb.freebsd.org/changeset/base/337719 Test Device: Huawei MateBook X Pro ( i7, Kabylake ) Test Result: it works (In reply to marc.priggemeyer from comment #12) Thanks you! I'm got working touchpad on Dell Lattitude 5290 on 12.0-ALPHA3 r338342. But: 1. iichid.ko and acpi_iichid.ko can't be loaded by enabling on /boot/loader.conf - I'm got a kernel panic on boot with this modules enabled in loader.conf. And currently I'm using kld_list in rc.conf 2. moused -p /dev/ims0 should be started before starting X.org. Otherwise X hangs on start. (patch < D16698.diff works very strange, but I solved this issue) Created attachment 196970 [details]
PCI Ids for Kabylake
I noticed that the Kabylake IDs are still missing in current. I would like to ask one of the committers to apply the latest patch as well.
(In reply to marc.priggemeyer from comment #20) Hi Marc, I don't have a system with these PC IDs so can't test the patch. Did you test it on actual hardware? (In reply to Oleksandr Tymoshenko from comment #21) I have a Kabylake laptop running with those ids, see devinfo -v output below: ig4iic_pci0 pnpinfo vendor=0x8086 device=0xa160 subvendor=0x1028 subdevice=0x07d0 class=0x118000 at slot=21 function=0 dbsf=pci0:0:21:0 handle=\_SB_.PCI0.I2C0 iicbus0 ig4iic_pci1 pnpinfo vendor=0x8086 device=0xa161 subvendor=0x1028 subdevice=0x07d0 class=0x118000 at slot=21 function=1 dbsf=pci0:0:21:1 handle=\_SB_.PCI0.I2C1 iicbus1 Fyi, the "Intel 100 Series and Intel 230 Series Chipset Family Platform Controller Hub (PCH)" Datasheet Volume 1/2 p. 26 even suggests using PCI Ids 0xa160 through 0xa163, but I could not test the 0xa162 and 0xa163. A commit references this bug: Author: gonzo Date: Thu Sep 13 17:36:56 UTC 2018 New revision: 338654 URL: https://svnweb.freebsd.org/changeset/base/338654 Log: [ig4] Add PCI IDs for I2C controller on Intel Kaby Lake systems PR: 221777 Approved by: re (kib) Submitted by: marc.priggemeyer@gmail.com Changes: head/sys/dev/ichiic/ig4_pci.c A commit references this bug: Author: gonzo Date: Sun Sep 30 23:14:08 UTC 2018 New revision: 339029 URL: https://svnweb.freebsd.org/changeset/base/339029 Log: MFC r336050-r336051, r336142, r336326, r337719 r336050: ig4(4): add support for Apollo Lake I2C controllers Add PCI ids for I2C controllers on Apollo Lake platform. Also convert switch/case probe logic into a table. Reviewed by: avg Differential Revision: https://reviews.freebsd.org/D16120 r336051: ig4(4): Fix Apollo lake entries platform identifier Identify Apollo Lake controllers as IG4_APL and not as a IG4_SKYLAKE Reported by: rpokala@ r336142: ig4(4): add devmatch(8) PNP info Now that we have all devices ids in a table add MODULE_PNP_INFO macro to let devmatch autoload module r336326: Remove MODULE_PNP_INFO for ig4(4) driver ig4(4) does not support suspend/resume but present on the hardware where such functionality is critical, like laptops. Remove PNP info to avoid breaking suspend/resume on the systems where ig4(4) load is not explicitly requested by the user. PR: 229791 Reported by: Ali Abdallah r337719: [ig4] Fix initialization sequence for newer ig4 chips Newer chips may require assert/deassert after power down for proper startup. Check respective flag in DEVIDLE_CTRL and perform operation if neccesssary. PR: 221777 Submitted by: marc.priggemeyer@gmail.com Obtained from: DragonFly BSD Tested on: Thinkpad T470 Changes: _U stable/11/ stable/11/sys/dev/ichiic/ig4_iic.c stable/11/sys/dev/ichiic/ig4_pci.c stable/11/sys/dev/ichiic/ig4_reg.h stable/11/sys/dev/ichiic/ig4_var.h A commit references this bug: Author: gonzo Date: Sun Sep 30 23:17:33 UTC 2018 New revision: 339031 URL: https://svnweb.freebsd.org/changeset/base/339031 Log: MFC r338654, r338701 r338654: [ig4] Add PCI IDs for I2C controller on Intel Kaby Lake systems PR: 221777 Approved by: re (kib) Submitted by: marc.priggemeyer@gmail.com r338701: [ig4] Fix device description for Kaby Lake systems Kaby Lake I2C controller is Intel Sunrise Point-H not Intel Sunrise Point-LP. Submitted by: Dmitry Luhtionov Approved by: re (kib) Changes: _U stable/11/ stable/11/sys/dev/ichiic/ig4_pci.c driver bug: Unable to set devclass (class: ppc devname: (unknown))
driver bug: Unable to set devclass (class: ppc devname: (unknown))
ig4iic_acpi0: <Designware I2C Controller> iomem 0xe1122000-0xe1122fff irq 7 on acpi0
ig4iic_acpi0: controller error during attach-1
driver bug: Unable to set devclass (class: ppc devname: (unknown))
ig4iic_acpi1: <Designware I2C Controller> iomem 0xe1124000-0xe1124fff irq 7 on acpi0
ig4iic_acpi1: controller error during attach-1
iicbus0: <Philips I2C bus> on ig4iic_acpi0
iic0: <I2C generic I/O> on iicbus0
iicbus1: <Philips I2C bus> on ig4iic_acpi1
iic1: <I2C generic I/O> on iicbus1
driver bug: Unable to set devclass (class: ppc devname: (unknown))
Weird...still not attaching on Broadwell.
hostb0@pci0:0:0:0: class=0x060000 card=0x16048086 chip=0x16048086 rev=0x09 hdr=0x00
vendor = 'Intel Corporation'
device = 'Broadwell-U Host Bridge -OPI'
class = bridge
subclass = HOST-PCI
vgapci0@pci0:0:2:0: class=0x030000 card=0x16168086 chip=0x16168086 rev=0x09 hdr=0x00
vendor = 'Intel Corporation'
device = 'HD Graphics 5500'
class = display
subclass = VGA
hdac0@pci0:0:3:0: class=0x040300 card=0x160c8086 chip=0x160c8086 rev=0x09 hdr=0x00
vendor = 'Intel Corporation'
device = 'Broadwell-U Audio Controller'
class = multimedia
subclass = HDA
xhci0@pci0:0:20:0: class=0x0c0330 card=0x9cb18086 chip=0x9cb18086 rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = 'Wildcat Point-LP USB xHCI Controller'
class = serial bus
subclass = USB
none0@pci0:0:22:0: class=0x078000 card=0x9cba8086 chip=0x9cba8086 rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = 'Wildcat Point-LP MEI Controller'
class = simple comms
hdac1@pci0:0:27:0: class=0x040300 card=0x9ca08086 chip=0x9ca08086 rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = 'Wildcat Point-LP High Definition Audio Controller'
class = multimedia
subclass = HDA
pcib1@pci0:0:28:0: class=0x060400 card=0x9c908086 chip=0x9c908086 rev=0xe3 hdr=0x01
vendor = 'Intel Corporation'
device = 'Wildcat Point-LP PCI Express Root Port'
class = bridge
subclass = PCI-PCI
isab0@pci0:0:31:0: class=0x060100 card=0x9cc38086 chip=0x9cc38086 rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = 'Wildcat Point-LP LPC Controller'
class = bridge
subclass = PCI-ISA
ahci0@pci0:0:31:2: class=0x010601 card=0x9c838086 chip=0x9c838086 rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = 'Wildcat Point-LP SATA Controller [AHCI Mode]'
class = mass storage
subclass = SATA
none1@pci0:0:31:6: class=0x118000 card=0x9ca48086 chip=0x9ca48086 rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = 'Wildcat Point-LP Thermal Management Controller'
class = dasp
iwm0@pci0:1:0:0: class=0x028000 card=0x50708086 chip=0x08b18086 rev=0xcb hdr=0x00
vendor = 'Intel Corporation'
device = 'Wireless 7260'
class = network
Handle 0x000C, DMI type 41, 11 bytes
Onboard Device
Reference Designation: trackpad
Type: Other
Status: Enabled
Type Instance: 37
Bus Address: 0001:15:00.0
From dmidecode it should show up on the i2c controller...which can't be found.
Is my ACPI table broken or is there a bug?
(I tested this on latest commit as of this time and date, w/o patch as it's in -CURRENT from then afaict)
(In reply to Cory Smelosky from comment #26) Would you mind posting a full acpi dump $(acpidump -t -d)? In addition, a full device tree might come in handy identifying your problem: devinfo -v I have tried this on a HP EliteBook 1040 G3 and while the touchpad was detected, I could not move the cursor. psm works on the 1040 G3 as an Alps GlidePoint (the 1040 G3 uses the Alps T4 chip) but I cannot do things like two finger scroll. The T4 chip supports HID over I2C and I think this is a better place to support the T4 than psm (keep in mind that I am no expert on pointing devices or the FreeBSD kernel). dmesg reports this: acpi_iichid0: <HID over I2C (ACPI)> on acpi0 acpi_iichid0: descriptor register address is 20 acpi_iichid0: unexpected type 17 while parsing Current Resource Settings (_CSR) acpi_iichid0: parent device is "\134_SB_.PCI0.I2C1" iichid0: <HID over I2C> at addr 0x20 on iicbus1 iichid0: ADDR 0x20 REG 0x20 iichid0: 3 buttons and [XYZ] coordinates ID=6 iichid0: 3 buttons and [XYZ] coordinates ID=6 acpi_iichid0: added iichid0 ADDR 0x20 REG 0x20 to iicbus1 acpi_iichid0: could not allocate IRQ resource The last line seems interesting. If I start moused and point at /dev/ims0, I get this error: moused: unable to get status of mouse fd: Inappropriate ioctl for device And am unable to move the cursor. However, /dev/ims0 does exist. A Linux patch for Alps T4 is here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=73196ebe134d11a68a2e27814c489d685cfc8b03 (In reply to Neel Chauhan from comment #28) CSR type 17 indicates GPIO interrupt signaling, which is not supported yet. You can try polling by setting the sampling_rate sysctl of your acpi_iichid device to something greater then 0, please have a look at the "Test Plan" section on https://reviews.freebsd.org/D16698 for details. By the way, I think this issue here is resolved and since MFC to stable/11 was already done, I would like to close this issue to have further comments regarding iichid go to reviews. Any objections? Closing since the original issue has been fixed and MFCed. If there are additional bugs related to ig4 please open new PRs for them Thanks |
Created attachment 185729 [details] Patch for ig4 ichiic/ig4 support for more recent hardware has progress quite a bit in DragonFly BSD. The attached patch tracks these changes and adds the following: * Kaby Lake / Intel 100 series PCH (Sunrise Point-H) IDs * correct controller initialization after power down Recent laptops ship with HID over I2C trackpads, this is the first patch to get access to devices on the bus.