In D16698#568171, @KOT_MATPOCKuH.Ru wrote:

I'm using patches from this review for last two years.
Please apply this patch to FreeBSD base code.

Thanks for the remarks. I'd suggest to stop riding a dead horse and make the switch altogether. It has been pointed out previously that the separation of ACPI and HID over I2C code like it was done here, especially the interrupt handling, was ill-conceived.
Abstraction of HID code was initially considered, but not implemented on my part. Since wulf has already done these things and even has the multitouch part working, switching over is the most sensible thing. This code here was intended to be a first draft and has served its purpose.

In D16698#454202, @nikola.lecic_anthesphoria.net wrote:

Many thanks for your efforts! My laptop: Asus Zenbook 14 UX410UFR with 12.0-RELEASE. After kldload ig4 iic acpi_iichid the device works after being probed with i2c -v -s -f /dev/iic1 (thanks fbsd_opal.com). My /var/log/messages:

I reuploaded the full patch with a sysctl (power_state) added.
Setting

Hmm, I think I did not intend to create a new diff. Should I reupload, or can it be merged?

In D16698#452186, @markj wrote:

Do you have a license header for iichid.c?

#1

In D16698#452086, @markj wrote:

The acpi_iichid driver needs to be rewritten. It should be a child of the iic bus, not the acpi bus. I've started working on this.

In D16698#431923, @seanc wrote:

Can someone summarize what's left or preventing this from being committed?

In D16698#374594, @markj wrote:

...
I haven't spent any significant amount of time looking at the diff yet, but I'll take a stab at answering these.
...

I got some open questions that someone actually reviewing this code or just stumbling by might be able to answer:

1. is PI_TTY the preferred thread priority, or should it be something else?
2. I read locking(9), mutex(9), bus_setup_intr(9) and a paper on locking mechanisms in FreeBSD and think that I got a fair idea about the basic principles, but I think I still didn't get a grasp on when sleeping is allowed when using an interrupt routine. From what I understand, I almost always need to create a task queue due to the fact that almost all bus implementations call mtx_sleep at some point. Is that correct? Then again I think I saw some modules calling bus operations (that possibly call mtx_sleep) during interrupt handling directly from the associated ithread routine. Are they doing it wrong?
3. If I use a task queue to handle interrupts and retrieve data from a device and that retrieval method goes to sleep eventually. From my understanding I should release my locks before and reacquire them after the bus operation. What is the preferred method to prevent another thread trying to detach the sleeping module? Possible solutions I figured that might be applicable are flag and condition variable or nested mutex. But what is the right way to do it, or is it even unnecessary because some internal mechanism prevents detaching (device busy msg)?

Thanks for your help.

I just uploaded a new diff that lacks the changes to usb. iichid for now depends on usb but should be easier to test.

In D16698#372549, @b4_gewt.net wrote:

Hmmm. Does my ACPI table not _know_ there should be an i2c mouse?

In D16698#372199, @tfagart_brozs.net wrote:

Hello Marc,

Thanks for your quick answer.

My revision is r339210. So I guess I should try 338291.

Regards

Thomas

Hi Thomas,

• Tested against base revision 338291.
• Sampling mode was added to periodically poll for reporrts (see Test Plan for further information)
• Still make sure to have a running iicbus implementation
• it was reported in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221777 that a panic occures when trying to load iichid and acpi_iichid by bootloader kld_list in rc.conf is still the way to go if you tested manually beforehand.

It appears that GPIO interrupt allocation is implemented in general, but I think chipset support might yet be missing for Intel PCH.

Hi Daniel,

Daniel provideddmesg output for his laptop, thanks for the effort.
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