On 1/22/2024 11:06, Sébastien Chaumat wrote:
Le mer. 17 janv. 2024 à 03:20, Mario Limonciello
<mario.limoncie...@amd.com <mailto: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 <mailto: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/
<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 <mailto:mario.limoncie...@amd.com> ?
No; the INT_SRV_OVR you'll see on Framework 13 AMD is on IRQ 2 and IRQ 9.
