Re: [PATCH v2 0/5] acpi/x86: s2idle: move Display off/on calls outside suspend (fixes ROG Ally suspend)

[Mario Limonciello <mario.limonciello@amd.com>]

On 9/23/2024 11:11, Antheas Kapenekakis wrote:
>> I don't think it's possible to have it both ways that the ordering is
>> wrong AND the timing is wrong.
> 
> I think the current firmware manifests 2 issues on the Ally X: Display
> On needed to be called once the kernel is ready otherwise it NOOPed
> and Display Off needed to be called 1 second before suspend. Then,
> there is the issue in my previous email that also exists in Windows.
> 
> I tried from 0 - 4000ms for Display off and 0 - 1500ms for Display on.
> Display Off, as long as the RGB fades 100-200ms before, made no
> difference. Display On likewise made no difference.

Part of the problem here is that we (Linux kernel developers) don't have 
the details of how the MCU actually interacts with the OS vs how it 
wants to interact with the OS.  Only ASUS knows this and all we can do 
is guess (or join an NDA).

"For example" (not saying this is the problem; I don't know) if we have 
a Linux sequence that we put the XHCI host controller into D3 but don't 
turn off the port first this might not matter to most devices because 
you're saving power by the controller being in D3.  But if the device is 
looking for some sequence of packets there could be a failure if those 
never happen or happen at the wrong time.

> 
> I am currently playing a bit with the calls in the Legion Go. Seems
> like one of them turns off its controller as well.
> 
> I did not know fwupd could do microprocessors, if it is simple that
> would be great.

Yeah in this case it interacts with the USB HID interface.

Unfortunately we don't have the HID spec from ASUS, so the entire thing 
would need to be reverse engineered.

I hope that more of these handhelds with MCUs that get regular updates 
make the same investment.