RE: [PATCH v2 4/4] drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay to 1 msec

[Biju Das]

Hi Hugo,

> -----Original Message-----
> From: dri-devel <dri-devel-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of Hugo Villeneuve
> Sent: 23 March 2026 17:41
> Subject: Re: [PATCH v2 4/4] drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay to 1 msec
> 
> Hi Biju,
> 
> On Mon, 23 Mar 2026 15:19:27 +0000
> Biju Das <biju.das.jz@xxxxxxxxxxxxxx> wrote:
> 
> > Hi Hugo,
> >
> > > -----Original Message-----
> > > From: Hugo Villeneuve <hugo@xxxxxxxxxxx>
> > > Sent: 23 March 2026 14:20
> > > Subject: Re: [PATCH v2 4/4] drm: renesas: rzg2l_mipi_dsi: Increase
> > > reset deassertion delay to 1 msec
> > >
> > > Hi Biju,
> > >
> > > On Thu, 19 Mar 2026 16:48:28 +0000
> > > Biju <biju.das.au@xxxxxxxxx> wrote:
> > >
> > > > From: Biju Das <biju.das.jz@xxxxxxxxxxxxxx>
> > > >
> > > > The RZ/G2L hardware manual (Rev. 1.50, May 2025), Section
> > > > 34.4.2.1, requires waiting more than 1 msec after deasserting the
> > > > CMN_RSTB signal before the DSI-Tx module is ready. Increase the
> > > > delay from 1 usec to
> > > > 1 msec by replacing udelay(1) with fsleep(1000).
> > > >
> > > > Signed-off-by: Biju Das <biju.das.jz@xxxxxxxxxxxxxx>
> > >
> > > In your first submission, I commented that "...this should be
> > > backported to stable branches (missing Fixes / Cc: stable tags)?" and you answered with "Agreed,
> will add fixes/stable tags".
> > >
> > > If you still agree, this patch should be #3 in your list, so that it
> > > is easier/straightforward to backport to stable branches.
> >
> > The patch order is changed. that is the reason I have not added any fixes/stable tags.
> 
> This is not a logical nor valid justification if the change merits to be backported to stable branches
> as you indicated in series 1. Why have you changed your mind?
> 
> > The if check in patch#3 makes it is not backportable to stable branches.
> 
> If you put the delay patch before that "if check", then it is irrelevant, no?
> 
> > If I reorder this to patch#3 it is fixing just the delay mentioned in the hardware manual.
> 
> Yes, and that is also exactly what this current version does, no?
> 
> For me, it is simply changing a delay from 1us to 1ms. Whether you change it before or after another
> patch isn't supposed to matter in the end, unless I am missing something?

OK, I will move this to patch#2 with fixes tag and based on [1],
will merge patch#2 and #3 to avoid breakage.


[1] https://sashiko.dev/#/patchset/20260319164833.409126-1-biju.das.jz%40bp.renesas.com

Cheers,
Biju