Hi Geert,
On 23/06/2021 13:53, Geert Uytterhoeven wrote:
> Hi Kieran,
>
> On Wed, Jun 23, 2021 at 1:11 AM Kieran Bingham
> <kieran.bingham@xxxxxxxxxxxxxxxx> 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?
>
> 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.
>
> Gr{oetje,eeting}s,
>
> Geert
>
