mirror of
https://github.com/freebsd/freebsd-src.git
synced 2026-10-28 11:25:21 +01:00
On controllers with the LPSS "additional registers" (Skylake and later, IG4_HAS_ADDREGS), ig4iic_suspend() places the controller in the device idle state (IG4_DEVICE_IDLE) and asserts core reset. While idle the DesignWare core is power-gated: its register bank reads back as zero and writes are dropped until the core is taken out of the idle state again. ig4iic_set_config(), called from ig4iic_resume(), only performs that un-idle handshake when it observes IG4_RESTORE_REQUIRED set in DEVIDLE_CTRL. Some platforms (e.g. Intel Alder Lake-P) do not raise that status across suspend-to-idle (S0ix). The core is then left gated: set_config()'s register writes have no effect, it nevertheless returns success, and every subsequent transfer fails with IIC_ETIMEOUT, leaving child I2C-HID devices (touchpad, touchscreen) dead after resume. Give ig4iic_set_config() a force_restore argument and pass it from ig4iic_resume() so the un-idle handshake runs unconditionally for IG4_HAS_ADDREGS controllers, regardless of the RESTORE_REQUIRED status. This keeps the handshake and its reset/restore sequence in one place instead of duplicating it in the resume path. The DesignWare core's register bank stays inaccessible (reads back as zero) until it leaves reset, which happens when ig4iic_set_config() deasserts the core reset. Rather than waiting a fixed, guessed interval, poll the fixed component-type signature (IG4_REG_COMP_TYPE == IG4_COMP_TYPE) immediately after that deassert and continue as soon as the core is ready. On Alder Lake-P the core is ready with no measurable delay; the bounded poll keeps this correct on slower parts, and warns if the core never leaves reset. While integrating these I2C-HID touch devices, also raise hid(4)'s MAXLOCCNT from 2048 to 4096: the report-descriptor parser truncates any variable main item whose usage count exceeds MAXLOCCNT, silently dropping the trailing report fields. Some contemporary touch devices declare variable items with more than 2048 entries, so part of their input reports was being discarded. Reviewed by: adrian MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D57673