Bug 221777 - merge the latest changes to the ig4 module from DragonFly BSD and add Kaby Lake / Intel 100 series platform support
Summary: merge the latest changes to the ig4 module from DragonFly BSD and add Kaby La...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Some People
Assignee: Oleksandr Tymoshenko
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2017-08-24 20:46 UTC by marc.priggemeyer
Modified: 2019-01-21 21:46 UTC (History)
6 users (show)

See Also:


Attachments
Patch for ig4 (13.00 KB, patch)
2017-08-24 20:46 UTC, marc.priggemeyer
no flags Details | Diff
Huawei_MateBook_X_Pro_acpidump (103.59 KB, application/x-bzip)
2018-08-12 21:59 UTC, Daniel Zeisig
no flags Details
PCI Ids for Kabylake (1.25 KB, patch)
2018-09-08 21:33 UTC, marc.priggemeyer
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description marc.priggemeyer 2017-08-24 20:46:14 UTC
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.
Comment 1 Daniel Zeisig 2018-08-11 09:04:05 UTC
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.
Comment 2 marc.priggemeyer 2018-08-11 15:31:27 UTC
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.
Comment 3 Daniel Zeisig 2018-08-11 23:55:55 UTC
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.
Comment 4 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2018-08-12 00:30:44 UTC
This was partially committed in base r330558 as a part of the review D13654

The only missing part is re-initialization after power down
Comment 5 Daniel Zeisig 2018-08-12 03:47:18 UTC
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
Comment 6 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2018-08-12 18:45:27 UTC
(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.
Comment 7 marc.priggemeyer 2018-08-12 20:09:00 UTC
(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.
Comment 8 marc.priggemeyer 2018-08-12 20:15:48 UTC
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.
Comment 9 Daniel Zeisig 2018-08-12 21:59:48 UTC
Created attachment 196137 [details]
Huawei_MateBook_X_Pro_acpidump

Please find my acpidump attached.
Comment 10 marc.priggemeyer 2018-08-12 22:52:45 UTC
(In reply to Daniel from comment #9)
FYI, please check https://reviews.freebsd.org/D16698
Comment 11 Daniel Zeisig 2018-08-12 23:13:58 UTC
(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.
Comment 12 marc.priggemeyer 2018-08-12 23:35:00 UTC
(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.
Comment 13 Daniel Zeisig 2018-08-13 07:03:15 UTC
(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
Comment 14 marc.priggemeyer 2018-08-13 08:32:31 UTC
(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.
Comment 15 marc.priggemeyer 2018-08-13 10:02:11 UTC
(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.
Comment 16 Daniel Zeisig 2018-08-13 13:34:28 UTC
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
Comment 17 commit-hook freebsd_committer 2018-08-13 18:53:30 UTC
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
Comment 18 Daniel Zeisig 2018-08-14 02:38:36 UTC
(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
Comment 19 Dmitry Afanasiev 2018-08-30 19:39:14 UTC
(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)
Comment 20 marc.priggemeyer 2018-09-08 21:33:42 UTC
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.
Comment 21 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2018-09-10 18:30:38 UTC
(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?
Comment 22 marc.priggemeyer 2018-09-10 20:03:10 UTC
(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.
Comment 23 commit-hook freebsd_committer 2018-09-13 17:37:27 UTC
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
Comment 24 commit-hook freebsd_committer 2018-09-30 23:14:17 UTC
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
Comment 25 commit-hook freebsd_committer 2018-09-30 23:18:25 UTC
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
Comment 26 Cory Smelosky 2018-10-08 08:13:49 UTC
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)
Comment 27 marc.priggemeyer 2018-10-10 21:49:41 UTC
(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
Comment 28 Neel Chauhan 2018-10-14 00:14:21 UTC
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
Comment 29 marc.priggemeyer 2018-10-14 17:39:58 UTC
(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?
Comment 30 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2019-01-21 21:46:52 UTC
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