Re: [BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD

[Mario Limonciello <mario.limonciello@xxxxxxx>]

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 <euidzero@xxxxxxxxx> 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.