Hi Hugo, > -----Original Message----- > From: dri-devel <[email protected]> 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 <[email protected]> wrote: > > > Hi Hugo, > > > > > -----Original Message----- > > > From: Hugo Villeneuve <[email protected]> > > > 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 <[email protected]> wrote: > > > > > > > From: Biju Das <[email protected]> > > > > > > > > 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 <[email protected]> > > > > > > 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
