On Fri, Nov 08, 2019 at 06:12:26PM +0200, Laurent Pinchart wrote: > On Fri, Nov 08, 2019 at 06:01:20PM +0200, Laurent Pinchart wrote: > > On Fri, Nov 08, 2019 at 09:57:55AM -0600, Rob Herring wrote: > >> On Fri, Nov 8, 2019 at 8:32 AM Laurent Pinchart wrote: > >>> On Fri, Nov 08, 2019 at 04:10:40PM +0200, Laurent Pinchart wrote: > >>>> 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@xxxxxxxxxx> > >>>>>>>>> > >>>>>>>>> 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@xxxxxxxxxx> > >>>>>>>>> Signed-off-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > >>>>>>>>> --- > >>>>>>>>> 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@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. > >> > >> It wouldn't because uniqueItems is the default (not for json-schema, > >> but DT schema string-arrays). > >> > >>>>> 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 > >> > >> 'clock' and 'clock-names' don't match. dp_aud_clk is in the wrong spot. > > > > You're right, and after thinking twice about it, this won't allow > > > > clock-names = "dp_apb_clk", "dp_vtc_pixel_clk_in", "dp_live_video_in_clk"; > > > > so your solution is the only one that will work. > > > >>> > >>> There's something going on that I can't really understand... > >>> > >>> 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 > >>> > >>> results in dt_mk_schema complaining about an invalid schema. However, > >>> the following works: > >> > >> Because 'uniqueItems' is not allowed because it's not needed. > > > > Error messages could be improved :-) > > > >>> clock-names: > >>> oneOf: > >>> - 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 > >>> > >>> I assume this is due to clock-names being a string-array, which already > >>> contains uniqueItems. However, if I leave uniqueItems out, an example > >>> with a duplicated clock-names validates fine. > >> > >> Are you using 'DT_SCHEMA_FILES' as that leaves out all the core schema? > > > > Ah, that's probably why ! Thank you. > > I've now run dt_binding_check without DT_SCHEMA_FILES, and without a > uniqueItems in each of the oneOf options, duplicate values are allowed. > Is this expected ? Sorry, please scratch this, I made a mistake. Things now work as expected. Thank you for your help ! > >> BTW, this case is probably allowed because we fail to apply the same > >> meta-schemas for schema behind the oneOf. -- Regards, Laurent Pinchart
