Re: [PATCH v2] drm: shmobile: Fix blank screen after resume when LCDC is stopped

[phucduc.bui@gmail.com]

Hi Geert,

> Your MIRROR value is truncated (I don't trust the final zero)

I apologize for the inconvenience. The displayed value was
truncated due to a missing newline character in my debug print
function. As you suspected, the value is indeed not 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=0x5c100000 MIRROR=0x5c100000
shmob-drm fe940000.lcd-controller:
[AFTER MIRROR] LDSA1R: A=0x00000000 B=0x5c100000 MIRROR=0x5c100000
shmob-drm fe940000.lcd-controller:
[AFTER SWAP] LDSA1R: A=0x00000000 B=0x5c100000 MIRROR=0x5c100000
OOM killer enabled.
Restarting tasks: Starting
Restarting tasks: Done
PM: suspend exit

> 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.

Thank you for sharing your configuration file. I noticed there are
numerous differences between our configurations. After further
investigation, I narrowed down the main cause to the following debug
options:

CONFIG_PROVE_LOCKING=n

CONFIG_DEBUG_LOCK_ALLOC=n

CONFIG_DEBUG_RT_MUTEXES=n

CONFIG_DEBUG_SPINLOCK=n

CONFIG_DEBUG_MUTEXES=n

CONFIG_DEBUG_WW_MUTEX_SLOWPATH=n

CONFIG_DEBUG_RWSEMS=n

CONFIG_DEBUG_LOCKING_API_SELFTESTS=n

CONFIG_LOCK_STAT=n

CONFIG_DEBUG_ATOMIC_SLEEP=n


These options are enabled in your configuration but disabled in mine.
Enabling these debug features introduces additional overhead, which
slows down the resume process. This delay unintentionally provides
enough time for the hardware to generate the Frame End interrupt,
effectively masking the issue on your system.

It is also worth mentioning that this behavior is not new. I have been
able to reproduce it consistently for a long time, dating back to the
Kernel 3.x era when armadillo800eva_defconfig was used upstream. In
fact, the issue can be reproduced as far back as Kernel 3.12. While the
exact configurations may have changed over time, the underlying
behavior has remained the same across multiple kernel versions.

This observation suggests the presence of a systemic race condition.
If the resume process completes too quickly, the Frame End interrupt
may not occur in time to trigger the transfer from Side B to Side A.
As a result, explicitly initializing Side A (priming) during resume,
as proposed in my patch, provides a more robust and deterministic
solution. This ensures correct behavior regardless of CPU speed,
system load, or debug configuration, rather than relying on the
incidental timing introduced by debug options.


Best regard,

Phuc