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

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

On Fri, Jan 30, 2026 at 03:18:05AM -0500, correctmost wrote:
> > Lets try this: block LPSS runtime PM. I know you did it in the past but
> > this one does it slightly differently (you commented out the ops, this one
> > prevents the LPSS from runtime suspending). Can you replace previous hack
> > patch with the below?
> 
> After applying that patch, I still see the IRQ message and the touchpad
> doesn't work (full log attached).
> 
> I'm not sure if this is helpful, but it seems like a similar IRQ issue was discussed in the past:
> - https://lore.kernel.org/all/20251102190921.30068-1-hansg@kernel.org/
> - https://github.com/alexpevzner/hotfix-kvadra-touchpad
> - https://bbs.archlinux.org/viewtopic.php?id=302348

Yeah, I think Andy has been part of many of those discussions.

I went through again the logs that you have sent and tried to figure if
there is something we are missing. I noticed couple of things actually.
First of all it seems that even if we get the interrupt storm the I2C works
fine until the touchpad has been reset. Second is that the Linux interrupt
number is different when it "works". This itself does not say much because
it is just a number (not HW number) but since they are allocated sequently
maybe something messes up with that.

The working case:

i2c_hid_acpi i2c-ELAN06FA:00: HID Descriptor: 1e 00 00 01 a3 02 02 00 03 00 1f 00 04 00 00 00 05 00 06 00 f3 04 7e 32 04 00 00 00 00 00
i2c_hid_acpi i2c-ELAN06FA:00: Requesting IRQ: 156
i2c_hid_acpi i2c-ELAN06FA:00: entering i2c_hid_parse
i2c_hid_acpi i2c-ELAN06FA:00: i2c_hid_start_hwreset
i2c_hid_acpi i2c-ELAN06FA:00: i2c_hid_set_power
i2c_hid_acpi i2c-ELAN06FA:00: i2c_hid_xfer: cmd=05 00 00 08
i2c_hid_acpi i2c-ELAN06FA:00: i2c_hid_xfer: cmd=05 00 00 01
i2c_hid_acpi i2c-ELAN06FA:00: i2c_hid_finish_hwreset: waiting...
i2c_hid_acpi i2c-ELAN06FA:00: i2c_hid_finish_hwreset: finished.
i2c_hid_acpi i2c-ELAN06FA:00: asking HID report descriptor
i2c_hid_acpi i2c-ELAN06FA:00: i2c_hid_xfer: cmd=02 00
i2c_hid_acpi i2c-ELAN06FA:00: Report Descriptor: 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02 95 06 81 03 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 75 08 95 05 81 03 c0 06 00 ff 09 01 85 0e 09 c5

the non-working case:

i2c_hid_acpi i2c-ELAN06FA:00: HID Descriptor: 1e 00 00 01 a3 02 02 00 03 00 1f 00 04 00 00 00 05 00 06 00 f3 04 7e 32 04 00 00 00 00 00
i2c_hid_acpi i2c-ELAN06FA:00: Requesting IRQ: 155
i2c_hid_acpi i2c-ELAN06FA:00: entering i2c_hid_parse
i2c_hid_acpi i2c-ELAN06FA:00: i2c_hid_start_hwreset
i2c_hid_acpi i2c-ELAN06FA:00: i2c_hid_set_power
i2c_hid_acpi i2c-ELAN06FA:00: i2c_hid_xfer: cmd=05 00 00 08
i2c_hid_acpi i2c-ELAN06FA:00: i2c_hid_xfer: cmd=05 00 00 01
i2c_hid_acpi i2c-ELAN06FA:00: i2c_hid_finish_hwreset: waiting...
i2c_hid_acpi i2c-ELAN06FA:00: i2c_hid_finish_hwreset: finished.
i2c_hid_acpi i2c-ELAN06FA:00: asking HID report descriptor
i2c_hid_acpi i2c-ELAN06FA:00: i2c_hid_xfer: cmd=02 00
i2c_designware i2c_designware.0: i2c_dw_xfer: msgs: 2
i2c_designware i2c_designware.0: enabled=0x1 stat=0x10
i2c_designware i2c_designware.0: enabled=0x1 stat=0x2514
i2c_designware i2c_designware.0: enabled=0x1 stat=0x2514
i2c_designware i2c_designware.0: enabled=0x1 stat=0x2514
i2c_designware i2c_designware.0: enabled=0x1 stat=0x2514
i2c_designware i2c_designware.0: enabled=0x1 stat=0x2514
i2c_designware i2c_designware.0: enabled=0x1 stat=0x2514
i2c_designware i2c_designware.0: enabled=0x1 stat=0x2514
i2c_designware i2c_designware.0: enabled=0x1 stat=0x2514
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

Both cases the HID descriptor read over I2C works fine. It's just after the
reset when reading the HID report descriptor things stall. I left the debug
there above it shows for I2C that MASTER_ON_HOLD is set which means the TX
fifo is empty and the controller is holding the bus which, I think should
not happen.

Notice also IRQ 155 vs 156.

Can you run one more test so that you have the latest debug patch but
comment out in the idma64.c this part:

static irqreturn_t idma64_irq(int irq, void *dev)
{
	struct idma64 *idma64 = dev;
	u32 status = dma_readl(idma64, STATUS_INT);
	u32 status_xfer;
	u32 status_err;
	unsigned short i;

#if 0
	/* Since IRQ may be shared, check if DMA controller is powered on */
	if (status == GENMASK(31, 0))
		return IRQ_NONE;
#endif

	dev_vdbg(idma64->dma.dev, "%s: status=%#x\n", __func__, status);


I would like to see what's the difference in "working" wrt. I2C-HD messages
above. If you can provide full dmesg again? Thanks!