linux-kernel - Re: [PATCH] dt-bindings: display: renesas,du: Provide bindings for r8a779a0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 2 Sep 2021 01:13:26 +0300
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Kieran Bingham <kieran.bingham@...asonboard.com>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Rob Herring <robh+dt@...nel.org>,
        "open list:DRM DRIVERS FOR RENESAS" <dri-devel@...ts.freedesktop.org>,
        "open list:DRM DRIVERS FOR RENESAS" 
        <linux-renesas-soc@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] dt-bindings: display: renesas,du: Provide bindings for
 r8a779a0

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@...asonboard.com>
> >>
> >> Extend the Renesas DU display bindings to support the r8a779a0 V3U.
> >>
> >> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@...asonboard.com>
> > 
> > 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