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

[Mika Westerberg <mika.westerberg@linux.intel.com>]

On Wed, Jan 28, 2026 at 11:54:50PM -0500, correctmost wrote:
> On Wed, Jan 28, 2026, at 7:31 AM, Mika Westerberg wrote:
> > On Wed, Jan 28, 2026 at 05:21:20AM -0500, correctmost wrote:
> >> On Wed, Jan 28, 2026, at 4:34 AM, Andy Shevchenko wrote:
> >> > On Tue, Jan 20, 2026 at 11:56:15PM -0500, correctmost wrote:
> >> >> On Tue, Jan 20, 2026, at 4:33 AM, Andy Shevchenko wrote:
> >> >> > On Mon, Jan 19, 2026 at 12:49:59PM +0200, Andy Shevchenko wrote:
> >> >> >> 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:
> >> >
> >> > ...
> >> >
> >> >> >> > 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.
> >> >> 
> >> >> I tested commit c03e9c42ae8 with the following patch and still saw the "probe
> >> >> with driver i2c_hid_acpi failed" error:
> >> >
> >> >> +	{
> >> >> +		void __iomem *padcfg0;
> >> >> +	        u32 value;
> >> >
> >> >> +		padcfg0 = intel_get_padcfg(pctrl, 3, PADCFG0);
> >> >
> >> > I'm sorry to get you back to this one, but can you replace 3 with 82 and try
> >> > again (keep the kernel command options with HID debug enabled, etc, but no
> >> > other patches applied).
> >> 
> >> I tested the pin 82 patch by itself (no other patches and no config changes).  I received the IRQ message and the touchpad didn't work (full log attached):
> >
> > Okay let's add some debug to the drivers involved and try to figure out
> > what is happening.
> >
> > Can you next apply the below patch (only that one) and try? Any test case
> > where it reproduces is good. The provide again full dmesg. While at it can
> > you enable CONFIG_PRINTK_TIME=y so we can also get timestamps to the dmesg.
> 
> Full log attached with the added debug prints and timestamps

Thanks! Okay so the interrupt is active immediately when the LPSS probes.
One thing that could explain this is that the IO-APIC is misconfigured to
have the polarity reversed. Can you boot with "apic=debug" in the kernel
command line so that it dumps the entries and provide again full dmesg?