From: Rob Herring <robh@kernel.org>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Vinod <vkoul@kernel.org>, Nishanth Menon <nm@ti.com>,
Santosh Shilimkar <ssantosh@kernel.org>,
Vignesh R <vigneshr@ti.com>,
Dan Williams <dan.j.williams@intel.com>,
Tero Kristo <t-kristo@ti.com>, Lokesh Vutla <lokeshvutla@ti.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
devicetree@vger.kernel.org,
"open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM"
<dmaengine@vger.kernel.org>
Subject: Re: [PATCH 09/18] dt-bindings: dma: ti: Add document for K3 BCDMA
Date: Thu, 8 Oct 2020 14:15:45 -0500 [thread overview]
Message-ID: <CAL_JsqJnk=ycRurUTBwWgX1+vOq_MZuevegvK2MwGJHkHW50mg@mail.gmail.com> (raw)
In-Reply-To: <d5746fca-bbdd-0fd1-cbcb-21b6269c39ac@ti.com>
On Thu, Oct 8, 2020 at 3:40 AM Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>
>
>
> On 07/10/2020 18.46, Rob Herring wrote:
> > On Wed, Oct 07, 2020 at 12:09:06PM +0300, Peter Ujfalusi wrote:
> >>
> >>
> >> On 06/10/2020 22.29, Rob Herring wrote:
> >>> On Wed, Sep 30, 2020 at 12:14:03PM +0300, Peter Ujfalusi wrote:
> >>>> New binding document for
> >>>> Texas Instruments K3 Block Copy DMA (BCDMA).
> >>>>
> >>>> BCDMA is introduced as part of AM64.
> >>>>
> >>
> >> ...
> >>
> >>>
> >>>> + ti,sci:
> >>>> + description: phandle to TI-SCI compatible System controller node
> >>>> + allOf:
> >>>> + - $ref: /schemas/types.yaml#/definitions/phandle
> >>>> +
> >>>> + ti,sci-dev-id:
> >>>> + description: TI-SCI device id of BCDMA
> >>>> + allOf:
> >>>> + - $ref: /schemas/types.yaml#/definitions/uint32
> >>>
> >>> We have a common definition for these.
> >>
> >> Yes, in arm/keystone/ti,k3-sci-common.yaml, but I could not get to use
> >> that as reference.
> >>
> >> I can not list it under the topmost allOf and drop the ti,sci and
> >> ti,sci-dev-id like this:
> >>
> >> allOf:
> >> - $ref: /schemas/dma/dma-controller.yaml#
> >> - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
> >>
> >> It results:
> >> CHKDT Documentation/devicetree/bindings/processed-schema-examples.json
> >> DTEX Documentation/devicetree/bindings/dma/ti/k3-bcdma.example.dts
> >> SCHEMA Documentation/devicetree/bindings/processed-schema-examples.json
> >> DTC Documentation/devicetree/bindings/dma/ti/k3-bcdma.example.dt.yaml
> >> CHECK Documentation/devicetree/bindings/dma/ti/k3-bcdma.example.dt.yaml
> >> Documentation/devicetree/bindings/dma/ti/k3-bcdma.example.dt.yaml:
> >> dma-controller@485c0100: 'ti,sci', 'ti,sci-dev-id' do not match any of
> >> the regexes: 'pinctrl-[0-9]+'
> >> From schema: Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
> >>
> >> If I remove the "additionalProperties: false" from the schema file, then
> >> it compiles fine.
> >
> > Yeah, you have to do 'unevaluatedProperties: false' which doesn't
> > actually do anything yet, but can 'see' into $ref's.
>
> I see, but even if I add the unevaluatedProperties: false I will have
> the same error as long as I have additionalProperties: false
Yes. I meant unevaluatedProperties instead of additionalProperties.
> If I remove the additionalProperties then it makes no difference if I
> have the unevaluatedProperties: false or I don't.
Not yet, but it will soon. Once I have the tree in a consistent state
in 5.10-rc1, there will be a meta-schema to check all this (which is
one of those must always be present).
Though, as of now 'unevaluatedProperties' doesn't do anything because
the underlying json-schema tool doesn't yet support it.
> >>>> + ti,sci-rm-range-bchan:
> >>>> + description: |
> >>>> + Array of BCDMA block-copy channel resource subtypes for resource
> >>>> + allocation for this host
> >>>> + allOf:
> >>>> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> >>>> + minItems: 1
> >>>> + # Should be enough
> >>>> + maxItems: 255
> >>>
> >>> Are there constraints for the individual elements?
> >>
> >> In practice the subtype ID is 6bits number.
> >> Should I add limits to individual elements?
> >
> > Yes:
> >
> > items:
> > maximum: 0x3f
>
> Right, I can just omit the minimum.
>
> It would be nice if I could use definitions for these ranges to avoid
> duplicated lines by adding
>
> definitions:
> ti,rm-range:
> $ref: /schemas/types.yaml#/definitions/uint32-array
> minItems: 1
> # Should be enough
> maxItems: 255
> items:
> minimum: 0
> maximum: 0x3f
>
> to schemas/arm/keystone/ti,k3-sci-common.yaml
>
> and only have:
>
> ti,sci-rm-range-bchan:
> $ref:
> /schemas/arm/keystone/ti,k3-sci-common.yaml#/definitions/ti,rm-range
> description: |
> Array of BCDMA block-copy channel resource subtypes for resource
> allocation for this host
Just do:
patternProperties:
"^ti,sci-rm-range-[btr]chan$":
...
If this is common for other bindings, then you can put it in
ti,k3-sci-common.yaml.
> but it results:
> Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml:
> properties:ti,sci-rm-range-bchan: {'$ref':
> '/schemas/arm/keystone/ti,k3-sci-common.yaml#/definitions/ti,rm-range',
> 'description': 'Array of BCDMA block-copy channel resource subtypes for
> resource\nallocation for this host\n'} is not valid under any of the
> given schemas (Possible causes of the failure):
> Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml:
> properties:ti,sci-rm-range-bchan: 'not' is a required property
> Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml:
> properties:ti,sci-rm-range-bchan:$ref:
> '/schemas/arm/keystone/ti,k3-sci-common.yaml#/definitions/ti,rm-range'
> does not match 'types.yaml#[/]{0,1}definitions/.*'
We probably should allow for using 'definitions' which is pretty
common json-schema practice, but don't primarily in order to keep
folks within the lines. Things are optimized for not knowing
json-schema and trying to minimize errors I have to check for.
Supporting it would complicate the meta-schema and the tools' fixup
code. So far, the need for it has been pretty infrequent.
Rob
next prev parent reply other threads:[~2020-10-08 19:16 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-30 9:13 [PATCH 00/18] dmaengine/soc: k3-udma: Add support for BCDMA and PKTDMA Peter Ujfalusi
2020-09-30 9:13 ` [PATCH 01/18] dmaengine: of-dma: Add support for optional router configuration callback Peter Ujfalusi
2020-10-07 5:44 ` Vinod Koul
2020-10-07 8:08 ` Peter Ujfalusi
2020-10-07 15:55 ` Vinod Koul
2020-10-08 6:41 ` Peter Ujfalusi
2020-10-28 5:55 ` Vinod Koul
2020-10-28 9:56 ` Peter Ujfalusi
2020-11-09 11:45 ` Vinod Koul
2020-11-09 12:09 ` Peter Ujfalusi
2020-11-09 12:23 ` Vinod Koul
2020-11-09 12:36 ` Peter Ujfalusi
2020-09-30 9:13 ` [PATCH 02/18] dmaengine: Add support for per channel coherency handling Peter Ujfalusi
2020-09-30 9:13 ` [PATCH 03/18] dmaengine: doc: client: Update for dmaengine_get_dma_device() usage Peter Ujfalusi
2020-09-30 9:13 ` [PATCH 04/18] dmaengine: dmatest: Use dmaengine_get_dma_device Peter Ujfalusi
2020-09-30 9:13 ` [PATCH 05/18] dmaengine: ti: k3-udma: Wait for peer teardown completion if supported Peter Ujfalusi
2020-09-30 9:14 ` [PATCH 06/18] dmaengine: ti: k3-udma: Add support for second resource range from sysfw Peter Ujfalusi
2020-09-30 9:14 ` [PATCH 07/18] dmaengine: ti: k3-udma-glue: Add function to get device pointer for DMA API Peter Ujfalusi
2020-10-07 6:53 ` Vinod Koul
2020-10-07 8:22 ` Peter Ujfalusi
2020-09-30 9:14 ` [PATCH 08/18] dmaengine: ti: k3-udma-glue: Configure the dma_dev for rings Peter Ujfalusi
2020-09-30 9:14 ` [PATCH 09/18] dt-bindings: dma: ti: Add document for K3 BCDMA Peter Ujfalusi
2020-10-01 6:49 ` Peter Ujfalusi
2020-10-06 19:23 ` Rob Herring
2020-10-06 19:29 ` Rob Herring
2020-10-07 9:09 ` Peter Ujfalusi
2020-10-07 15:46 ` Rob Herring
2020-10-08 8:40 ` Peter Ujfalusi
2020-10-08 19:15 ` Rob Herring [this message]
2020-10-09 8:06 ` Peter Ujfalusi
2020-09-30 9:14 ` [PATCH 10/18] dt-bindings: dma: ti: Add document for K3 PKTDMA Peter Ujfalusi
2020-09-30 9:14 ` [PATCH 11/18] dmaengine: ti: k3-psil: Extend psil_endpoint_config " Peter Ujfalusi
2020-09-30 9:14 ` [PATCH 12/18] dmaengine: ti: k3-psil: Add initial map for AM64 Peter Ujfalusi
2020-09-30 9:14 ` [PATCH 13/18] dmaengine: ti: Add support for k3 event routers Peter Ujfalusi
2020-09-30 9:14 ` [PATCH 14/18] soc: ti: k3-ringacc: add AM64 DMA rings support Peter Ujfalusi
2020-09-30 9:14 ` [PATCH 15/18] dmaengine: ti: k3-udma: Initial support for K3 BCDMA Peter Ujfalusi
2020-09-30 9:14 ` [PATCH 16/18] dmaengine: ti: k3-udma: Add support for BCDMA channel TPL handling Peter Ujfalusi
2020-09-30 9:14 ` [PATCH 17/18] dmaengine: ti: k3-udma: Initial support for K3 PKTDMA Peter Ujfalusi
2020-09-30 9:14 ` [PATCH 18/18] dmaengine: ti: k3-udma-glue: Add " Peter Ujfalusi
2020-09-30 10:17 ` [PATCH 00/18] dmaengine/soc: k3-udma: Add support for BCDMA and PKTDMA Peter Ujfalusi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAL_JsqJnk=ycRurUTBwWgX1+vOq_MZuevegvK2MwGJHkHW50mg@mail.gmail.com' \
--to=robh@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lokeshvutla@ti.com \
--cc=nm@ti.com \
--cc=peter.ujfalusi@ti.com \
--cc=ssantosh@kernel.org \
--cc=t-kristo@ti.com \
--cc=vigneshr@ti.com \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).