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

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

[phucduc.bui]

From: bui duc phuc <phucduc.bui@gmail.com>

The LCDC controller on R8A7740 loses its register state during
deep sleep. Upon resume, the driver's Mirror Register mechanism
(MRS) fails to update active registers because the controller is
stopped (DO=0).

According to the datasheet (Section 38.7.1, Figure 38.13), the
Two-Set Register Switching logic only triggers a change between
Set A and Set B when a Frame End Interrupt occurs at the
completion of a display frame. During resume, as the LCDC is
stopped, no frame is processed and no Frame End pulse is
generated. This leaves the Display Data Start Address (SA)
pending in the standby set, while the active register (Side A)
remains at 0x00000000, preventing the display engine from
starting.Debug logs collected during resume confirm this
behavior, showing the start address written to the standby set
while the active register remains unchanged.

Prime both register sets when the LCDC is stopped:

    If DO=0: Use lcdc_write() to force the Start Address (SA)
    into both Set A and Set B registers. This bypasses the
    switching logic and ensures the engine has a valid base
    address immediately upon being enabled.

    If DO=1: Maintain the standard Mirror mechanism and MRS
    toggle for normal, tear-free operation.

Verified on R8A7740.

Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
 .../gpu/drm/renesas/shmobile/shmob_drm_plane.c  | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/renesas/shmobile/shmob_drm_plane.c b/drivers/gpu/drm/renesas/shmobile/shmob_drm_plane.c
index 9d166ab2af8b..21fd1e19beda 100644
--- a/drivers/gpu/drm/renesas/shmobile/shmob_drm_plane.c
+++ b/drivers/gpu/drm/renesas/shmobile/shmob_drm_plane.c
@@ -70,6 +70,7 @@ static void shmob_drm_primary_plane_setup(struct shmob_drm_plane *splane,
 	struct shmob_drm_plane_state *sstate = to_shmob_plane_state(state);
 	struct shmob_drm_device *sdev = to_shmob_device(splane->base.dev);
 	struct drm_framebuffer *fb = state->fb;
+	u32 ldcnt2r;
 
 	/* TODO: Handle YUV colorspaces. Hardcode REC709 for now. */
 	lcdc_write(sdev, LDDFR, sstate->format->lddfr | LDDFR_CF1);
@@ -78,11 +79,19 @@ static void shmob_drm_primary_plane_setup(struct shmob_drm_plane *splane,
 	/* Word and long word swap. */
 	lcdc_write(sdev, LDDDSR, sstate->format->ldddsr);
 
-	lcdc_write_mirror(sdev, LDSA1R, sstate->dma[0]);
-	if (shmob_drm_format_is_yuv(sstate->format))
-		lcdc_write_mirror(sdev, LDSA2R, sstate->dma[1]);
+	ldcnt2r = lcdc_read(sdev, LDCNT2R);
+
+	if (ldcnt2r & LDCNT2R_DO) {
+		lcdc_write_mirror(sdev, LDSA1R, sstate->dma[0]);
+		if (shmob_drm_format_is_yuv(sstate->format))
+			lcdc_write_mirror(sdev, LDSA2R, sstate->dma[1]);
 
-	lcdc_write(sdev, LDRCNTR, lcdc_read(sdev, LDRCNTR) ^ LDRCNTR_MRS);
+		lcdc_write(sdev, LDRCNTR, lcdc_read(sdev, LDRCNTR) ^ LDRCNTR_MRS);
+	} else {
+		lcdc_write(sdev, LDSA1R, sstate->dma[0]);
+		if (shmob_drm_format_is_yuv(sstate->format))
+			lcdc_write_mirror(sdev, LDSA2R, sstate->dma[1]);
+	}
 }
 
 static void shmob_drm_overlay_plane_setup(struct shmob_drm_plane *splane,
-- 
2.43.0

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

[phucduc.bui]

From: bui duc phuc <phucduc.bui@gmail.com>

The LCDC controller on R8A7740 loses its register state during
deep sleep. Upon resume, the driver's Mirror Register mechanism
(MRS) fails to update active registers because the controller is
stopped (DO=0).

According to the datasheet (Section 38.7.1, Figure 38.13), the
Two-Set Register Switching logic only triggers a change between
Set A and Set B when a Frame End Interrupt occurs at the
completion of a display frame. During resume, as the LCDC is
stopped, no frame is processed and no Frame End pulse is
generated. This leaves the Display Data Start Address (SA)
pending in the standby set, while the active register (Side A)
remains at 0x00000000, preventing the display engine from
starting.Debug logs collected during resume confirm this
behavior, showing the start address written to the standby set
while the active register remains unchanged.

Prime both register sets when the LCDC is stopped:

    If DO=0: Use lcdc_write() to force the Start Address (SA)
    into both Set A and Set B registers. This bypasses the
    switching logic and ensures the engine has a valid base
    address immediately upon being enabled.

    If DO=1: Maintain the standard Mirror mechanism and MRS
    toggle for normal, tear-free operation.

Verified on R8A7740.

Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---

Changes in v2:
 - Fix incorrect use of lcdc_write_mirror() for LDSA2R in
   the DO=0 path; use lcdc_write() to update both register
   sets as intended.

 .../gpu/drm/renesas/shmobile/shmob_drm_plane.c  | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/renesas/shmobile/shmob_drm_plane.c b/drivers/gpu/drm/renesas/shmobile/shmob_drm_plane.c
index 9d166ab2af8b..6371bdc2371a 100644
--- a/drivers/gpu/drm/renesas/shmobile/shmob_drm_plane.c
+++ b/drivers/gpu/drm/renesas/shmobile/shmob_drm_plane.c
@@ -70,6 +70,7 @@ static void shmob_drm_primary_plane_setup(struct shmob_drm_plane *splane,
 	struct shmob_drm_plane_state *sstate = to_shmob_plane_state(state);
 	struct shmob_drm_device *sdev = to_shmob_device(splane->base.dev);
 	struct drm_framebuffer *fb = state->fb;
+	u32 ldcnt2r;
 
 	/* TODO: Handle YUV colorspaces. Hardcode REC709 for now. */
 	lcdc_write(sdev, LDDFR, sstate->format->lddfr | LDDFR_CF1);
@@ -78,11 +79,19 @@ static void shmob_drm_primary_plane_setup(struct shmob_drm_plane *splane,
 	/* Word and long word swap. */
 	lcdc_write(sdev, LDDDSR, sstate->format->ldddsr);
 
-	lcdc_write_mirror(sdev, LDSA1R, sstate->dma[0]);
-	if (shmob_drm_format_is_yuv(sstate->format))
-		lcdc_write_mirror(sdev, LDSA2R, sstate->dma[1]);
+	ldcnt2r = lcdc_read(sdev, LDCNT2R);
+
+	if (ldcnt2r & LDCNT2R_DO) {
+		lcdc_write_mirror(sdev, LDSA1R, sstate->dma[0]);
+		if (shmob_drm_format_is_yuv(sstate->format))
+			lcdc_write_mirror(sdev, LDSA2R, sstate->dma[1]);
 
-	lcdc_write(sdev, LDRCNTR, lcdc_read(sdev, LDRCNTR) ^ LDRCNTR_MRS);
+		lcdc_write(sdev, LDRCNTR, lcdc_read(sdev, LDRCNTR) ^ LDRCNTR_MRS);
+	} else {
+		lcdc_write(sdev, LDSA1R, sstate->dma[0]);
+		if (shmob_drm_format_is_yuv(sstate->format))
+			lcdc_write(sdev, LDSA2R, sstate->dma[1]);
+	}
 }
 
 static void shmob_drm_overlay_plane_setup(struct shmob_drm_plane *splane,
-- 
2.43.0

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

[Geert Uytterhoeven]

Hi Phucduc,

On Thu, 26 Feb 2026 at 06:40, <phucduc.bui@gmail.com> wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> The LCDC controller on R8A7740 loses its register state during
> deep sleep. Upon resume, the driver's Mirror Register mechanism
> (MRS) fails to update active registers because the controller is
> stopped (DO=0).
>
> According to the datasheet (Section 38.7.1, Figure 38.13), the
> Two-Set Register Switching logic only triggers a change between
> Set A and Set B when a Frame End Interrupt occurs at the
> completion of a display frame. During resume, as the LCDC is
> stopped, no frame is processed and no Frame End pulse is
> generated. This leaves the Display Data Start Address (SA)
> pending in the standby set, while the active register (Side A)
> remains at 0x00000000, preventing the display engine from
> starting.Debug logs collected during resume confirm this
> behavior, showing the start address written to the standby set
> while the active register remains unchanged.
>
> Prime both register sets when the LCDC is stopped:
>
>     If DO=0: Use lcdc_write() to force the Start Address (SA)
>     into both Set A and Set B registers. This bypasses the
>     switching logic and ensures the engine has a valid base
>     address immediately upon being enabled.
>
>     If DO=1: Maintain the standard Mirror mechanism and MRS
>     toggle for normal, tear-free operation.
>
> Verified on R8A7740.
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>

Thanks for your patch!

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!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

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

[phucduc.bui]

Hi Geert,

> Thanks for your patch!

> 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

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

Testing on Stable and Upstream:
I have verified this behavior on both the stable and latest upstream 
kernels. While the patch was originally developed on a stable branch, I 
have confirmed that it applies cleanly to the current upstream tree and 
successfully resolves the issue there as well.

Context and Environment Difference:
I first tested several Armadillo-800 EVA boards more than 10 years ago, 
and this specific resume failure was already a known, persistent 
issue back then. After 10 years, I am returning to this platform and 
testing with my current hardware, and I can confirm the behavior 
remains exactly the same.

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:
I have recorded a short video demonstrating the bug (white screen after 
pressing "Switch 3" to resume):

https://youtu.be/0n9NHeZ7MWU

Detailed Logs and Configuration:
I have uploaded the kernel config and dmesg logs (including debug 
traces for LDSA1R) to this Gist:

https://gist.github.com/BuiDucPhuc/b31fc7ee784e65d192b2f49a406c3326

Technical Analysis:
I focused my debug traces on the LDSA1R register. The logs confirm that 
during resume, LDSA1R is reset to 0. When the driver updates the 
registers:
1. It writes the correct address to Side B (Mirror).
2. However, according to Figure 38.13 ("Two-set register switching 
timing") in the R8A7740 Group Hardware Manual, the transfer from Side B 
to Side A requires a Frame End interrupt.
3. Since the controller is currently stopped (DO=0), no frame is 
processed and no Frame End pulse is generated. Consequently, Side A 
remains 0x00000000, leading to the DMA fetch error and white screen.

This priming patch ensures Side A is explicitly initialized while the 
switching logic is idle, making the driver robust against register 
context loss.

Best regards,
Bui Duc Phuc

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

[Geert Uytterhoeven]

Hi Bui,

On Fri, 27 Feb 2026 at 10:57, <phucduc.bui@gmail.com> 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 <geert+renesas@glider.be>

> 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 -- geert@linux-m68k.org

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

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

[Geert Uytterhoeven]

On Fri, 13 Mar 2026 at 09:37, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Fri, 27 Feb 2026 at 10:57, <phucduc.bui@gmail.com> 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 <geert+renesas@glider.be>

And of course:
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

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

[phucduc.bui]

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

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

[Geert Uytterhoeven]

Hi Phuc,

On Mon, 16 Mar 2026 at 12:25, <phucduc.bui@gmail.com> wrote:
> > 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.

Thank you, that explains the difference!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

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

[phucduc.bui]

Hi Geert,

> Thank you, that explains the difference!

Thank you for your confirmation. I am glad that we were able to
identify the root cause.

I also appreciate the support you and Morimoto-san have provided in
the past. It is a pleasure to work with you again.

If there are any further changes or improvements needed, please let
me know and I will prepare a v3 accordingly.

Best regards,

Phuc