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

[Mario Limonciello <mario.limonciello@xxxxxxx>]

On 3/6/2024 14:34, Sébastien Chaumat wrote:
> Le mer. 6 mars 2024 à 19:51, Mario Limonciello 
> <mario.limonciello@xxxxxxx <mailto:mario.limonciello@xxxxxxx>> a écrit :
>     On 3/6/2024 12:49, Sébastien Chaumat wrote:
>      >
>      >
>      > Le mer. 6 mars 2024 à 19:08, Mario Limonciello
>      > <mario.limonciello@xxxxxxx <mailto:mario.limonciello@xxxxxxx>
>     <mailto:mario.limonciello@xxxxxxx
>     <mailto:mario.limonciello@xxxxxxx>>> a écrit :
>      >
>      >     On 3/6/2024 12:05, Sébastien Chaumat wrote:
>      >      >
>      >      >
>      >      > Le mer. 6 mars 2024 à 18:33, Mario Limonciello
>      >      > <mario.limonciello@xxxxxxx
>     <mailto:mario.limonciello@xxxxxxx> <mailto:mario.limonciello@xxxxxxx
>     <mailto:mario.limonciello@xxxxxxx>>
>      >     <mailto:mario.limonciello@xxxxxxx
>     <mailto:mario.limonciello@xxxxxxx>
>      >     <mailto:mario.limonciello@xxxxxxx
>     <mailto:mario.limonciello@xxxxxxx>>>> a écrit :
>      >      >
>      >      >     On 3/6/2024 11:28, Sébastien Chaumat wrote:
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      >     Reasoning backward  (using a  kernel without the
>      >     pinctrl_amd
>      >      >     driver
>      >      >      >     to ensure xen only is at stake) :
>      >      >      >       checking the diff in IOAPIC  between bare
>     metal and xen
>      >      >     (IRQ7 is
>      >      >      >     on pin07 on APIC )
>      >      >      >
>      >      >      >     using kernel argument : apic=debug
>      >      >      >
>      >      >      >     bare metal :
>      >      >      >     [    0.715330] fedora kernel: ... APIC VERSION:
>     81050010
>      >      >      >     ...
>      >      >      >     [    0.715433] fedora kernel:  pin07, disabled,
>     edge ,
>      >     high,
>      >      >     V(00),
>      >      >      >     IRR(0), S(0), physical, D(0000), M(0)
>      >      >      >
>      >      >      >     xen :
>      >      >      >     [    2.249582] fedora kernel: ... APIC VERSION:
>     00000014
>      >      >      >     ...
>      >      >      >     [    2.249730] fedora kernel:  pin07, disabled,
>     level,
>      >     low ,
>      >      >     V(60),
>      >      >      >     IRR(0), S(0), physical, D(0000), M(0)
>      >      >      >
>      >      >      >     So the APIC table is not the same.
>      >      >      >
>      >      >      >     As strange as it looks the  (IOAPIC 0) pin07 is
>     correctly
>      >      >     described
>      >      >      >     by the APIC in xen but yet differently than in
>     baremetal.
>      >      >      >     But the APIC message comes long after the
>      >      >      >     [    1.833145] fedora kernel: xen: registering
>     gsi 7
>      >     triggering 0
>      >      >      >     polarity 1
>      >      >      >
>      >      >      >     so I wonder if the APIC pin07 info had any
>     influence.
>      >      >      >
>      >      >      > Finally found the fix : adding ioapic_ack=new to
>     xen boot
>      >     parameters.
>      >      >      > Not only the trackpad is now working but also the ACPI
>      >     Embedded
>      >      >      > Controller which is completely disabled.
>      >      >      >
>      >      >      > Sébastien
>      >      >      >
>      >      >     That's great news!  I'm personally totally unfamiliar with
>      >      >     ioapic_ack=new, so I did a quick search and found out
>     it's a Xen
>      >      >     parameter (I came across
>      >      >
>      >
>     https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html
>     <https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html>
>      >   
>       <https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html <https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html>>
>      >      >
>      >     
>       <https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html <https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html> <https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html <https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html>>>).
>      >      >
>      >      >     This mentions that "new" should be the default, so why
>     isn't
>      >     it the
>      >      >     case?
>      >      >
>      >      >
>      >      >   "This is the the default unless directed-EOI is supported"
>      >      > xl dmesg without forcing the parameters shows :
>      >      >
>      >      > (XEN) Enabled directed EOI with ioapic_ack_old on!
>      >
>      >     Got it; it sounds to me like a logic mismatch in Xen then.
>      >
>      >      >
>      >      >     Also; I'd be really interested to hear what happens with
>      >     s2idle with
>      >      >     Xen
>      >      >     now (if it works).
>      >      >
>      >      >
>      >      > suspend to RAM now works :)
>      >
>      >     Do you see /sys/power/suspend_stats/last_hw_sleep increasing
>     with your
>      >     suspend cycle?
>      >
>      >
>      > No,  it does not increase (0).
>      >
>
>     OK, then in that case I suggest you run
>     https://gitlab.freedesktop.org/drm/amd/-/blob/master/scripts/amd_s2idle.py 
> <https://gitlab.freedesktop.org/drm/amd/-/blob/master/scripts/amd_s2idle.py>
>     in the hypervisor to find out what's wrong.
>
>
> It fails with xen (not bare metal) during the prerequisite tests :
The script might need some modifications for tests that don't make sense 
in the context of Xen.
> ✅ GPIO driver `pinctrl_amd` available
> Traceback (most recent call last):
>    File "/home/sch/Downloads/amd_s2idle.py", line 2447, in <module>
>      test = app.prerequisites()
>             ^^^^^^^^^^^^^^^^^^^
>    File "/home/sch/Downloads/amd_s2idle.py", line 1938, in prerequisites
>      if not check():
>             ^^^^^^^
>    File "/home/sch/Downloads/amd_s2idle.py", line 826, in check_msr
>      val = read_msr(reg, 0)
>            ^^^^^^^^^^^^^^^^
>    File "/home/sch/Downloads/amd_s2idle.py", line 813, in read_msr
>      val = struct.unpack("Q", os.read(f, 8))[0]
>                               ^^^^^^^^^^^^^
> OSError: [Errno 5] Input/output error
>
> Last line in the log is :
> 2024-03-06 21:29:33,146 DEBUG: Lockdown: [none] integrity confidentiality
Do you have userspace MSR support compiled in?  If not; that could 
explain that problem.  But it's very unlikely you changed the MSRs.
For the purpose of finding where the suspend problem is, I'd comment out 
that specific check for now.