On 16.01.2024 16:52, Sébastien Chaumat wrote: > Le mar. 2 janv. 2024 à 21:23, Sébastien Chaumat <euidz...@gmail.com> a > écrit : > >> >> output of gpioinfo >>> >>> kernel alone : >>> >>> line 5: unnamed input active-low consumer=interrupt >>> line 84: unnamed input active-low consumer=interrupt >>> >>> xen: >>> >>> line 5: unnamed input active-low >>> line 84: unnamed input active-low >>> >>> xen with skipping IRQ7 double init : >>> >>> line 5: unnamed input active-low consumer=interrupt >>> line 84: unnamed input active-low >>> >>> >>> So definitely progressing. >>> >> >> Checking /sys/kernel/irq/7 >> >> kernel alone : >> actions: pinctrl_amd >> chip_name: IR-IO-APIC >> hwirq: 7 >> name: fasteoi >> per_cpu_count: 0,0,0,0,0,20,0,0,0,0,0,0,0,0,0,0 >> type: level >> wakeup: enabled >> >> xen skipping IRQ7 double init : >> >> actions: pinctrl_amd >> chip_name: xen-pirq >> hwirq: >> name: ioapic-level >> per_cpu_count: 0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0 >> type: edge >> wakeup: disabled >> >> So the skip of IRQ7 in pci_xen_initial_domain() sets the correct handler >> (IIUC xen uses the ioapic-level and handles the eoi separately), but not >> the correct type (still edge). >> I guess this may explains the results above. >> >> > Mario (in CC) patched the pinctrl_amd to flush pending interrupt before > starting the driver for the GPIO. > > This helped in the sense of there's no more pending interrupt on IRQ7 > (whatever the handler is, level or edge) but then the touchpad is not > detected by i2c-hid. > > Is there any work in progress related to the incorrect IRQ configuration ?
I'm not aware of any. As per my recollection it's still not entirely clear where in the kernel things go astray. And to be honest I don't feel comfortable trying to half-blindly address this, e.g. by trying to circumvent / defer the early setting up of the low 16 IRQs. Jan
