Re: [PATCH v3 4/5] drm: renesas: rz-du: Move mode_valid logic to per-output clock limits

["Lad, Prabhakar" <prabhakar.csengg@gmail.com>]

Hi Laurent,

Thank you for the review.

On Thu, May 14, 2026 at 12:02 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hi Prabhakar,
>
> Thank you for the patch.
>
> On Tue, May 12, 2026 at 03:41:03PM +0100, Prabhakar wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > Move pixel clock validation from a fixed encoder check to per-output
> > constraints stored in rzg2l_du_output_routing.
> >
> > Previously, rzg2l_du_encoder_mode_valid() applied a hard-coded 83.5 MHz
> > upper limit specifically for DPAD0. This approach cannot scale across the
> > RZ DU family because pixel clock limits vary per SoC and per output
> > interface.
> >
> > Add mode_clock_min and mode_clock_max fields to rzg2l_du_output_routing
> > so that clock constraints are expressed at the granularity of individual
> > output interfaces rather than globally per SoC. Update
> > rzg2l_du_encoder_mode_valid() to look up the routing entry for the active
> > output and return MODE_CLOCK_LOW or MODE_CLOCK_HIGH when the pixel clock
> > falls outside the declared range. A value of 0 for either field means no
> > bound is enforced in that direction.
> >
> > Set the DPAD0 pixel clock limits for RZ/G2UL (R9A07G043U) to 20.875 MHz
> > minimum and 83.5 MHz maximum. RZ/G2L and RZ/G2LC (R9A07G044) share the
> > same DPAD0 pixel clock limits.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > ---
> > v2->v3:
> > - Moved clock limits from device_info to output_routing to allow
> >   per-output constraints.
>
> Given that the DU has a single output, connected to multiple encoders,
> is the clock frequency limitation really a *per-output* property of the
> DU ? Clock constraints coming from encoders can be expressed in the
> respective bridge drivers (and the DSI encoder driver does so already).
>
For SoCs supporting DSI + DPI, the clock ranges vary for these
interfaces. For the DSI this is handled by the DSI encoder drivers,
but for DPI we must perform this check in the DU driver. Therefore, I
chose an approach involving a per-output clock range check.

Cheers,
Prabhakar