[PATCH v9 1/4] dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings

[Laurent Pinchart]

Hi Rob,

On Fri, Nov 08, 2019 at 04:07:33PM +0200, Laurent Pinchart wrote:
> On Thu, Sep 26, 2019 at 09:57:29AM -0500, Rob Herring wrote:
> > On Thu, Sep 26, 2019 at 9:23 AM Laurent Pinchart wrote:
> >> On Thu, Sep 26, 2019 at 09:15:01AM -0500, Rob Herring wrote:
> >>> On Wed, Sep 25, 2019 at 6:56 PM Laurent Pinchart wrote:
> >>>>
> >>>> From: Hyun Kwon <hyun.kwon at xilinx.com>
> >>>>
> >>>> The bindings describe the ZynqMP DP subsystem. They don't support the
> >>>> interface with the programmable logic (FPGA) or audio yet.
> >>>>
> >>>> Signed-off-by: Hyun Kwon <hyun.kwon at xilinx.com>
> >>>> Signed-off-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> >>>> ---
> >>>> Changes since v8:
> >>>>
> >>>> - Convert to yaml
> >>>> - Rename aclk to dp_apb_clk
> >>>
> >>> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.example.dt.yaml:
> >>> display at fd4a0000: clock-names:2: 'dp_vtc_pixel_clk_in' was expected
> >>
> >> If you allow me to steal a bit of your brain time, could you help me
> >> expressing the clocks constraint ?
> >>
> >>   clocks:
> >>     description:
> >>       The AXI clock and at least one video clock are mandatory, the audio clock
> >>       optional.
> >>     minItems: 2
> >>     maxItems: 4
> >>     items:
> >>       - description: AXI clock
> >>       - description: Audio clock
> >>       - description: Non-live video clock (from Processing System)
> >>       - description: Live video clock (from Programmable Logic)
> >>   clock-names:
> >>     minItems: 2
> >>     maxItems: 4
> >>     items:
> >>       - const: dp_apb_clk
> >>       - const: dp_aud_clk
> >>       - const: dp_vtc_pixel_clk_in
> >>       - const: dp_live_video_in_clk
> >>
> >> dp_apb_clk is required, dp_aud_clk is optional, and at least one of
> >> dp_vtc_pixel_clk_in and dp_live_video_in_clk is required.
> > 
> > I'm hoping people's inability to express the schema will prevent
> > complicated ones like this in the first place...
> > 
> > clock-names:
> >   oneOf:
> >     - minItems: 3
> >       maxItems: 4
> >       items:
> >         - const: dp_apb_clk
> >         - const: dp_aud_clk
> >         - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ]
> >         - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ]
> >     - minItems: 2
> >       maxItems: 3
> >       items:
> >         - const: dp_apb_clk
> >         - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ]
> >         - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ]
> 
> The above would make
> 
> 	clock-names = "dp_apb_clk", "dp_vtc_pixel_clk_in", "dp_vtc_pixel_clk_in";
> 
> valid. I've investigated a little bit and found uniqueItems which solves
> my issue.
> 
> Would the following simpler solution be acceptable ?
> 
> clock-names:
>     minItems: 2
>     maxItems: 4
>     items:
>       - const: dp_apb_clk
>       - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ]
>       - const: dp_aud_clk
>       - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ]
>     uniqueItems: true

To give more context,

  clocks:
    description:
      The AXI clock and at least one video clock are mandatory, the audio clock
      is optional.
    minItems: 2
    maxItems: 4
    items:
      - description: dp_apb_clk is the AXI clock
      - description: dp_aud_clk is the Audio clock
      - description:
          dp_vtc_pixel_clk_in is the non-live video clock (from Processing
          System)
      - description:
          dp_live_video_in_clk is the live video clock (from Programmable
          Logic)
  clock-names:
      minItems: 2
      maxItems: 4
      items:
        - const: dp_apb_clk
        - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ]
        - const: dp_aud_clk
        - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ]
      uniqueItems: true

> > Strictly speaking, that leaves items clocks wrong, but 'description'
> > doesn't do anything. So I'd just leave it as is.
> 
> Speaking of which, there doesn't seem to be anything that validates the
> size of clocks and clock-names being identical. Is that a known issue ?

-- 
Regards,

Laurent Pinchart