From: Rob Herring <robh@kernel.org>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: vkoul@kernel.org, nm@ti.com, ssantosh@kernel.org,
vigneshr@ti.com, dan.j.williams@intel.com, t-kristo@ti.com,
lokeshvutla@ti.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
dmaengine@vger.kernel.org
Subject: Re: [PATCH 09/18] dt-bindings: dma: ti: Add document for K3 BCDMA
Date: Wed, 7 Oct 2020 10:46:35 -0500 [thread overview]
Message-ID: <20201007154635.GA273523@bogus> (raw)
In-Reply-To: <bc054ef7-dcd7-dde2-13f8-4900a33b1377@ti.com>
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.
> >> + ti,asel:
> >> + description: ASEL value for non slave channels
> >> + allOf:
> >
> > You no longer need 'allOf' here.
>
> OK, I changed it in all instances.
>
> >
> >> + - $ref: /schemas/types.yaml#/definitions/uint32
> >> +
> >> + 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
>
> >> +
> >> + ti,sci-rm-range-tchan:
> >> + description: |
> >> + Array of BCDMA split tx channel resource subtypes for resource allocation
> >> + for this host
> >> + allOf:
> >> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> >> + minItems: 1
> >> + # Should be enough
> >> + maxItems: 255
> >> +
> >> + ti,sci-rm-range-rchan:
> >> + description: |
> >> + Array of BCDMA split rx channel resource subtypes for resource allocation
> >> + for this host
> >> + allOf:
> >> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> >> + minItems: 1
> >> + # Should be enough
> >> + maxItems: 255
> >> +
> >> +required:
> >> + - compatible
> >> + - "#address-cells"
> >> + - "#size-cells"
> >> + - "#dma-cells"
> >> + - reg
> >> + - reg-names
> >> + - msi-parent
> >> + - ti,sci
> >> + - ti,sci-dev-id
> >> + - ti,sci-rm-range-bchan
> >> + - ti,sci-rm-range-tchan
> >> + - ti,sci-rm-range-rchan
> >> +
> >> +additionalProperties: false
> >> +
> >> +examples:
> >> + - |+
> >> + cbass_main {
> >> + #address-cells = <2>;
> >> + #size-cells = <2>;
> >> +
> >> + main_dmss {
> >> + compatible = "simple-mfd";
> >
> > IMO, if it is memory-mapped, then you should be using 'simple-bus'.
>
> We had the same discussion when I introduced the k3-udma binding and we
> have concluded on the simple-mfd as DMSS is not a bus, but contains
> different peripherals.
Ok.
Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: nm@ti.com, devicetree@vger.kernel.org, vigneshr@ti.com,
lokeshvutla@ti.com, linux-kernel@vger.kernel.org,
t-kristo@ti.com, vkoul@kernel.org, ssantosh@kernel.org,
dmaengine@vger.kernel.org, dan.j.williams@intel.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 09/18] dt-bindings: dma: ti: Add document for K3 BCDMA
Date: Wed, 7 Oct 2020 10:46:35 -0500 [thread overview]
Message-ID: <20201007154635.GA273523@bogus> (raw)
In-Reply-To: <bc054ef7-dcd7-dde2-13f8-4900a33b1377@ti.com>
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.
> >> + ti,asel:
> >> + description: ASEL value for non slave channels
> >> + allOf:
> >
> > You no longer need 'allOf' here.
>
> OK, I changed it in all instances.
>
> >
> >> + - $ref: /schemas/types.yaml#/definitions/uint32
> >> +
> >> + 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
>
> >> +
> >> + ti,sci-rm-range-tchan:
> >> + description: |
> >> + Array of BCDMA split tx channel resource subtypes for resource allocation
> >> + for this host
> >> + allOf:
> >> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> >> + minItems: 1
> >> + # Should be enough
> >> + maxItems: 255
> >> +
> >> + ti,sci-rm-range-rchan:
> >> + description: |
> >> + Array of BCDMA split rx channel resource subtypes for resource allocation
> >> + for this host
> >> + allOf:
> >> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> >> + minItems: 1
> >> + # Should be enough
> >> + maxItems: 255
> >> +
> >> +required:
> >> + - compatible
> >> + - "#address-cells"
> >> + - "#size-cells"
> >> + - "#dma-cells"
> >> + - reg
> >> + - reg-names
> >> + - msi-parent
> >> + - ti,sci
> >> + - ti,sci-dev-id
> >> + - ti,sci-rm-range-bchan
> >> + - ti,sci-rm-range-tchan
> >> + - ti,sci-rm-range-rchan
> >> +
> >> +additionalProperties: false
> >> +
> >> +examples:
> >> + - |+
> >> + cbass_main {
> >> + #address-cells = <2>;
> >> + #size-cells = <2>;
> >> +
> >> + main_dmss {
> >> + compatible = "simple-mfd";
> >
> > IMO, if it is memory-mapped, then you should be using 'simple-bus'.
>
> We had the same discussion when I introduced the k3-udma binding and we
> have concluded on the simple-mfd as DMSS is not a bus, but contains
> different peripherals.
Ok.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-07 15:46 UTC|newest]
Thread overview: 80+ 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 ` Peter Ujfalusi
2020-09-30 9:13 ` [PATCH 01/18] dmaengine: of-dma: Add support for optional router configuration callback Peter Ujfalusi
2020-09-30 9:13 ` Peter Ujfalusi
2020-10-07 5:44 ` Vinod Koul
2020-10-07 5:44 ` Vinod Koul
2020-10-07 8:08 ` Peter Ujfalusi
2020-10-07 8:08 ` Peter Ujfalusi
2020-10-07 15:55 ` Vinod Koul
2020-10-07 15:55 ` Vinod Koul
2020-10-08 6:41 ` Peter Ujfalusi
2020-10-08 6:41 ` Peter Ujfalusi
2020-10-28 5:55 ` Vinod Koul
2020-10-28 5:55 ` Vinod Koul
2020-10-28 9:56 ` Peter Ujfalusi
2020-10-28 9:56 ` Peter Ujfalusi
2020-11-09 11:45 ` Vinod Koul
2020-11-09 11:45 ` Vinod Koul
2020-11-09 12:09 ` Peter Ujfalusi
2020-11-09 12:09 ` Peter Ujfalusi
2020-11-09 12:23 ` Vinod Koul
2020-11-09 12:23 ` Vinod Koul
2020-11-09 12:36 ` Peter Ujfalusi
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 ` 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 ` Peter Ujfalusi
2020-09-30 9:13 ` [PATCH 04/18] dmaengine: dmatest: Use dmaengine_get_dma_device Peter Ujfalusi
2020-09-30 9:13 ` 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:13 ` 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 ` 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-09-30 9:14 ` Peter Ujfalusi
2020-10-07 6:53 ` Vinod Koul
2020-10-07 6:53 ` Vinod Koul
2020-10-07 8:22 ` Peter Ujfalusi
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 ` Peter Ujfalusi
2020-09-30 9:14 ` [PATCH 09/18] dt-bindings: dma: ti: Add document for K3 BCDMA Peter Ujfalusi
2020-09-30 9:14 ` Peter Ujfalusi
2020-10-01 6:49 ` Peter Ujfalusi
2020-10-01 6:49 ` Peter Ujfalusi
2020-10-06 19:23 ` Rob Herring
2020-10-06 19:23 ` Rob Herring
2020-10-06 19:29 ` Rob Herring
2020-10-06 19:29 ` Rob Herring
2020-10-07 9:09 ` Peter Ujfalusi
2020-10-07 9:09 ` Peter Ujfalusi
2020-10-07 15:46 ` Rob Herring [this message]
2020-10-07 15:46 ` Rob Herring
2020-10-08 8:40 ` Peter Ujfalusi
2020-10-08 8:40 ` Peter Ujfalusi
2020-10-08 19:15 ` Rob Herring
2020-10-08 19:15 ` Rob Herring
2020-10-09 8:06 ` Peter Ujfalusi
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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` Peter Ujfalusi
2020-09-30 9:14 ` [PATCH 18/18] dmaengine: ti: k3-udma-glue: Add " Peter Ujfalusi
2020-09-30 9:14 ` Peter Ujfalusi
2020-09-30 10:17 ` [PATCH 00/18] dmaengine/soc: k3-udma: Add support for BCDMA and PKTDMA Peter Ujfalusi
2020-09-30 10:17 ` 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=20201007154635.GA273523@bogus \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.