Le mer. 17 janv. 2024 à 03:20, Mario Limonciello <mario.limoncie...@amd.com> a écrit :
> On 1/16/2024 10:18, Jan Beulich wrote: > > 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 > > Shot in the dark - but could this be a problem where PCAT_COMPAT from > the MADT is being ignored causing PIC not to be setup properly in the > Xen case? > > See https://lore.kernel.org/all/875y2u5s8g.ffs@tglx/ for some context. > > At least we know that no MADT override is found by xen for INT7 as no INT_SRC_OVR message is printed. Do we expect one @Mario Limonciello <mario.limoncie...@amd.com> ?
