Re: [REGRESSION][BISECTED] Lenovo IdeaPad touchpad does not work when idma64 is present in initramfs

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Mon, Jan 19, 2026 at 12:39:41PM +0200, Andy Shevchenko wrote:
> On Fri, Jan 16, 2026 at 07:25:54PM -0500, correctmost wrote:
> > On Fri, Jan 16, 2026, at 5:35 AM, Andy Shevchenko wrote:
> > > On Fri, Jan 16, 2026 at 12:03:12PM +0200, Andy Shevchenko wrote:
> > >> On Thu, Jan 15, 2026 at 05:50:36PM -0500, correctmost wrote:
> > >> > On Mon, Jan 12, 2026, at 9:35 AM, Andy Shevchenko wrote:
> > >> > > On Tue, Dec 16, 2025 at 12:57:10PM -0500, correctmost wrote:
> > >> > >
> > >> > >> The following commit
> > >> > >
> > >> > > No, it's false positive. The reality is that something else is going on
> > >> > > there on this and other similar laptops.
> > >> > >
> > >> > >> causes my Lenovo IdeaPad touchpad not to work when
> > >> > >> kernel/drivers/dma/idma64.ko.zst is present in the initramfs image:
> > >> > >> 
> > >> > >> #regzbot introduced: 9140ce47872bfd89fca888c2f992faa51d20c2bc
> > >> > >> 
> > >> > >> "idma64: Don't try to serve interrupts when device is powered off"
> > >> > >
> > >> > > So, the touchpad is an I²C device, which is connected to an Intel SoC.
> > >> > > The I²C host controller is Synopsys DesignWare. On Intel SoCs the above
> > >> > > mentioned IP is generated with private DMA engine, that's called Intel
> > >> > > iDMA 64-bit. Basically it's two devices under a single PCI hood.
> > >> > > The problem here is that when PCI device is in D3, both devices are
> > >> > > powered off, but something sends an interrupt and it's not recognized
> > >> > > being the one, send by a device (touchpad).
> > >> > >
> > >> > > There is one of the following potential issues (or their combinations):
> > >> > >
> > >> > > - the I²C host controller hardware got off too early
> > >> > > - the line is shared with something else that generates interrupt storm
> > >> > > - the BIOS does weird (wrong) things at a boot time, like not properly
> > >> > >   shutting down and disabling interrupt sources; also may have wrong
> > >> > >   pin control settings
> > >> > > - the touchpad is operating on higher frequency like 400kHz (because
> > >> > >   BIOS told to use that one instead of 100kHz) than the HW is designed
> > >> > >   for and hence unreliable with all possible side effects
> > >> > > - the touchpad firmware behaves wrongly on some sequences (see also
> > >> > >   note about the bus speed above), try to upgrade touchpad FW
> > >> > >
> > >> > > With my experience with the case of the above mentioned commit that it
> > >> > > may be BIOS thingy. Also consider the bus speed, there are quirks in
> > >> > > the kernel for that.
> > >> > 
> > >> > Thank you for the detailed notes.  I will see if I can update my BIOS and
> > >> > experiment with different quirks values, though I won't be able to do that
> > >> > until late next week.
> > >> 
> > >> You're welcome!
> > >> 
> > >> > >> Here are the related logs:
> > >> > >> 
> > >> > >> ---
> > >> > >> 
> > >> > >> irq 27: nobody cared (try booting with the "irqpoll" option)
> > >> > >
> > >> > > Almost all below is not so interesting.
> > >> > >
> > >> > > ...
> > >> > >
> > >> > >> handlers:
> > >> > >> [<00000000104a7621>] idma64_irq [idma64]
> > >> > >> [<00000000bd8d08e9>] i2c_dw_isr
> > >> > >> Disabling IRQ #27
> > >> > >
> > >> > > Yes, this line at least shared between those two and might be more.
> > >> > >
> > >> > > ...
> > >> > >
> > >> > >> i2c_designware i2c_designware.0: controller timed out
> > >> > >> hid (null): reading report descriptor failed
> > >> > >> i2c_hid_acpi i2c-ELAN06FA:00: can't add hid device: -110
> > >> > >> i2c_hid_acpi i2c-ELAN06FA:00: probe with driver i2c_hid_acpi failed with error -110
> > >> > >
> > >> > > Yes, sounds familiar with the speed settings. Try to down it to 100kHz in case
> > >> > > it's confirmed to be 400kHz.
> > >> > >
> > >> > >> ---
> > >> > >
> > >> > > Any pointers to that thread, please?
> > >> > 
> > >> > The following threads have users who were able to restore touchpad
> > >> > functionality by undoing the idma64 change in initramfs:
> > >> 
> > >> Yes, = "they have hidden the existing problem". No value in that, sorry.
> > >> What is the exact link that refer to the thread you previously mentioned?
> > >> 
> > >> ...
> > >> 
> > >> > Lastly, I saw another bug report that mentions the "probe with driver
> > >> > i2c_hid_acpi failed with error -110" error.  It seems to state that the error
> > >> > only occurs when a power cable is connected during boot:
> > >> > 
> > >> > - https://bugzilla.altlinux.org/57094
> > >> >   - Huawei Matebook D15 BOD-WXX9-PCB-B4
> > >> >   - i2c-GXTP7863:00
> > >> > 
> > >> > >> so I don't think this is a hardware issue with my individual laptop.
> > >> > >
> > >> > > I don't know how this conclusion is came here. You mean HW as laptop model?
> > >> > > But are the involved components the same (I²C host controller + touchpad)?
> > >> > 
> > >> > Sorry for the confusion.  I meant the individual machine in my possession and
> > >> > not the laptop model as a whole.
> > >> 
> > >> Yeah, something here is common and I can't say for sure this all about Synaptic
> > >> touchpads...
> > >
> > > So, what I think I need to understand this more is the following
> > > (all information should be gathered under root user) for working
> > > and non-working cases:
> > >
> > > - `cat /proc/interrupts`
> > > - `dmesg`
> > >    # with `initcall_debug ignore_loglevel` added to the kernel command line
> > > - `cat /sys/kernel/debug/pinctrl/.../pins`
> > >    # ... should be something like INTC1234:00
> > >
> > > And just once these:
> > > - `acpidump -o tables.dat` # the tables.dat file
> > > - `grep -H 15 /sys/bus/acpi/devices/*/status`
> > > - `lspci -nk -vv`
> > 
> > The tables.dat file and the dmesg logs seemed too big to post inline, so I
> > ended up zipping all of the files (attached).
> 
> Thanks for the files. The same suspicion as in the original report
> https://lore.kernel.org/all/e3f2debf-c762-48d9-876e-bcb60841f909@gmail.com/
> 
> Have you read it in full?
> 
> My understanding that the pin 3 on GPIO might be wrongly configured
> by BIOS.  The difference with the original case is that your GPIO device
> is locked against modifications and until you unlock it (usually
> it's done in BIOS in some debug menu) it may not be fixable without OEM
> fixing the issue themselves. In any case you can try the workaround
> (see https://lore.kernel.org/all/ZftTcSA5dn13eAmr@smile.fi.intel.com/).
> But I am skeptical about it.

Just in case, this https://hansdegoede.dreamwidth.org/25589.html might be
also useful.

-- 
With Best Regards,
Andy Shevchenko