Hi Laurent, On 01/09/2021 23:13, Laurent Pinchart wrote: > 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. Ok, that's not so bad to split, Done. > 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. >
