Hi Kieran, On Wed, Sep 01, 2021 at 11:01:11PM +0100, Kieran Bingham wrote: > On 23/06/2021 13:53, Geert Uytterhoeven wrote: > > On Wed, Jun 23, 2021 at 1:11 AM Kieran Bingham wrote: > >> From: Kieran Bingham <kieran.bingham+renesas@xxxxxxxxxxxxxxxx> > >> > >> Extend the Renesas DU display bindings to support the r8a779a0 V3U. > >> > >> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@xxxxxxxxxxxxxxxx> > > > > Thanks for your patch! > > > >> --- a/Documentation/devicetree/bindings/display/renesas,du.yaml > >> +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml > >> @@ -39,6 +39,7 @@ properties: > >> - renesas,du-r8a77980 # for R-Car V3H compatible DU > >> - renesas,du-r8a77990 # for R-Car E3 compatible DU > >> - renesas,du-r8a77995 # for R-Car D3 compatible DU > >> + - renesas,du-r8a779a0 # for R-Car V3U compatible DU > >> > >> reg: > >> maxItems: 1 > >> @@ -774,6 +775,57 @@ allOf: > >> - reset-names > >> - renesas,vsps > >> > >> + - if: > >> + properties: > >> + compatible: > >> + contains: > >> + enum: > >> + - renesas,du-r8a779a0 > >> + then: > >> + properties: > >> + clocks: > >> + items: > >> + - description: Functional clock for DU0 > >> + - description: Functional clock for DU1 > >> + > >> + clock-names: > >> + items: > >> + - const: du.0 > >> + - const: du.1 > > > > The hardware block has only a single function clock for both channels, > > like on R-Car H1. > > Indeed, but I believe both channels still need to set them, if they can > be operated independently, the driver looks up the clock based on the > du.%d, and so for DU1, it is simply expressed as the same clock in DT. > > Is this acceptable? or is there further issues there? Could we handle that on the driver side, like we do for H1 by not setting RCAR_DU_FEATURE_CRTC_IRQ_CLOCK ? We would probably need to split that flag in two, as there are two interrupts. It's a bit annoying not knowing what the MSTP bits do exactly, we've modelled them as gates for the functional clock, but maybe in cases like this one the mapping isn't fully correct, I'm not sure. > > And what about DU_DOTCLKIN? > > This thread has already discussed this with Laurent, and I concur - > There doesn't appear to be any relevant reference to DU_DOTCLKIN on the > DU side. -- Regards, Laurent Pinchart
