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
