- User Since
- Jan 18 2018, 9:48 PM (231 w, 5 d)
Jul 25 2020
Jul 15 2020
Oct 7 2019
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.
Jul 16 2019
Jul 8 2019
I reuploaded the full patch with a sysctl (power_state) added.
Jul 6 2019
Hmm, I think I did not intend to create a new diff. Should I reupload, or can it be merged?
May 7 2019
Nov 4 2018
Oct 14 2018
Oct 13 2018
Oct 12 2018
I got some open questions that someone actually reviewing this code or just stumbling by might be able to answer:
- is PI_TTY the preferred thread priority, or should it be something else?
- 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?
- 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.
Oct 10 2018
Oct 6 2018
Sep 22 2018
- 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.
Aug 15 2018
It appears that GPIO interrupt allocation is implemented in general, but I think chipset support might yet be missing for Intel PCH.
Aug 14 2018
Aug 13 2018
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
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
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