Hi Bui,

On Fri, 27 Feb 2026 at 10:57, <[email protected]> wrote:
> > What do you mean by "deep sleep"? s2ram? In upstream, s2ram behaves
> > the same as s2idle, and the LCD works fine after resume from s2ram on
> > my Amadillo, with and without your patch,
>
> > What am I missing?
> > Thanks!
>
> Thank you for your feedback.
>
> To clarify the "deep sleep" context, I have tested both s2idle and deep
> states using:
> - echo freeze > /sys/power/state
> - echo mem > /sys/power/state

OK, same for me.

> On my hardware, the issue is consistently reproducible in both cases,
> resulting in a completely white screen after resume.

TL;DR it depends on kernel config.
With my .config, your patch is not needed (but it doesn't hurt).
With your .config, your patch is needed.
Unfortunately I haven't found yet which config options causes this.
I will send you my .config by personal email.

Your change looks valid to me, so
Reviewed-by: Geert Uytterhoeven <[email protected]>

> Regarding why it works on your side: I cannot be certain about the
> specific differences in our hardware configurations. However, on my
> setup, the debug traces clearly confirm that the LDSA1R register is
> reset to 0 after resume.
>
> Video demonstration:

[...]

> Detailed Logs and Configuration:

[...]

Thanks for this very detailed information!
Since I did the investigation anyway, here are my results:

1) Using commit a75cb869a8ccc88b + debug info:

I get:

    >>> ENTER: shmob_drm_plane_atomic_update
    >>> ENTER: shmob_drm_primary_plane_setup
    shmob-drm fe940000.lcd-controller: [BEFORE] LDSA1R: A=0x00000000
B=0x00000000  MIRROR=0x00000000

Same as yours, OK

    shmob-drm fe940000.lcd-controller: [AFTER MIRROR] LDSA1R:
A=0x00000000  B=0x43a00000  MIRROR=0x43a00000

A and B are similar to yours, B is just a different address, so OK.
In your log, the MIRROR value is truncated, so nothing can be decided.

    shmob-drm fe940000.lcd-controller: [AFTER SWAP] LDSA1R:
A=0x00000000  B=0x43a00000  MIRROR=0x43a00000

A and B are similar to yours, so OK
Your MIRROR value is truncated (I don't trust the final zero)

    >>> ENTER: shmob_drm_crtc_atomic_enable
    >>> ENTER: shmob_drm_plane_atomic_update
    >>> ENTER: shmob_drm_primary_plane_setup
    shmob-drm fe940000.lcd-controller: [BEFORE] LDSA1R: A=0x00000000
B=0x43a00000  MIRROR=0x00000000

A and B are similar to yours, so OK
Your MIRROR value is truncated, but different from zero!

    shmob-drm fe940000.lcd-controller: [AFTER MIRROR] LDSA1R:
A=0x43a00000  B=0x43a00000  MIRROR=0x43a00000

Your A value is zero!
B is similar to yours, so OK
Your MIRROR value is truncated (I don't trust the final zero)

    shmob-drm fe940000.lcd-controller: [AFTER SWAP] LDSA1R:
A=0x43a00000  B=0x43a00000  MIRROR=0x43a00000

Your A value is zero!
B is similar to yours, so OK
Your MIRROR value is truncated (I don't trust the final zero)


2) Using commit a75cb869a8ccc88b + debug info + fix:

I get:

    shmob-drm: LDCNT2R=0x00000000 (DO=0)
    shmob-drm fe940000.lcd-controller: [BEFORE] LDSA1R: A=0x00000000
B=0x00000000  MIRROR=0x00000000
    shmob-drm: >>> BRANCH: DO = 0 (Direct write path)

Taking the new path

    shmob-drm fe940000.lcd-controller: [AFTER DIRECT WRITE] LDSA1R:
A=0x43a00000  B=0x43a00000  MIRROR=0x43a00000

A is now set, too

    >>> ENTER: shmob_drm_crtc_atomic_enable
    >>> ENTER: shmob_drm_plane_atomic_update
    >>> ENTER: shmob_drm_primary_plane_setup
    shmob-drm: LDCNT2R=0x00000003 (DO=1)
    shmob-drm fe940000.lcd-controller: [BEFORE] LDSA1R: A=0x43a00000
B=0x43a00000  MIRROR=0x43a00000

A is now set, too

    shmob-drm: >>> BRANCH: DO = 1 (Mirror path)
    shmob-drm fe940000.lcd-controller: [AFTER MIRROR] LDSA1R:
A=0x43a00000  B=0x43a00000  MIRROR=0x43a00000
    shmob-drm fe940000.lcd-controller: [AFTER SWAP] LDSA1R:
A=0x43a00000  B=0x43a00000  MIRROR=0x43a00000

End result is the same as before.

Without the fix, I ended up with the correct value for A, while you didn't.
With the fix, we get the same results.

Using your .config, I get the same results as you did.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Reply via email to