From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Rob Herring <robh@kernel.org>
Cc: Nishanth Menon <nm@ti.com>, <devicetree@vger.kernel.org>,
Grygorii Strashko <grygorii.strashko@ti.com>,
Lokesh Vutla <lokeshvutla@ti.com>, Keerthy <j-keerthy@ti.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Tero Kristo <t-kristo@ti.com>, Tony Lindgren <tony@atomide.com>,
Vinod <vkoul@kernel.org>, Santosh Shilimkar <ssantosh@kernel.org>,
"open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM"
<dmaengine@vger.kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 08/15] dt-bindings: dma: ti: Add document for K3 UDMA
Date: Tue, 26 Nov 2019 10:29:15 +0200 [thread overview]
Message-ID: <f2f4a4f5-335d-9a20-b410-91a7619fb84d@ti.com> (raw)
In-Reply-To: <b4705f2e-b2fb-f00f-7d4d-bd440fe89135@ti.com>
Rob,
On 15/11/2019 11.45, Peter Ujfalusi wrote:
> Rob,
>
> On 14/11/2019 19.53, Rob Herring wrote:
>> On Tue, Nov 5, 2019 at 4:07 AM Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>>>
>>>
>>>
>>> On 05/11/2019 4.19, Rob Herring wrote:
>>>> On Fri, Nov 01, 2019 at 10:41:28AM +0200, Peter Ujfalusi wrote:
>>>>> New binding document for
>>>>> Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P).
>>>>>
>>>>> UDMA-P is introduced as part of the K3 architecture and can be found in
>>>>> AM654 and j721e.
>>>>>
>>>>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>>>>> ---
>>>>> Rob,
>>>>>
>>>>> can you give me some hint on how to fix these two warnings from dt_binding_check:
>>>>>
>>>>> DTC Documentation/devicetree/bindings/dma/ti/k3-udma.example.dt.yaml
>>>>> Documentation/devicetree/bindings/dma/ti/k3-udma.example.dts:23.13-72: Warning (ranges_format): /example-0/interconnect@30800000:ranges: "ranges" property has invalid length (24 bytes) (parent #address-cells == 1, child #address-cells == 2, #size-cells == 2)
>>>>> CHECK Documentation/devicetree/bindings/dma/ti/k3-udma.example.dt.yaml
>>>>
>>>> The default #address-cells is 1 for examples. So you need to
>>>> either override it or change ranges parent address size.
>>>
>>> wrapping the cbass_main_navss inside:
>>> cbass_main {
>>> #address-cells = <2>;
>>> #size-cells = <2>;
>>> ...
>>> };
>>>
>>> fixes it.
>>>
>>>>>
>>>>> Documentation/devicetree/bindings/dma/ti/k3-udma.example.dt.yaml: interconnect@30800000: $nodename:0: 'interconnect@30800000' does not match '^(bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
>>>>
>>>> Use 'bus' for the node name of 'simple-bus'.
>>>
>>> I took the navss node from the upstream dts (I'm going to fix it there
>>> as well).
>>> It has simple-bus for the navss, which is not quite right as NAVSS is
>>> not a bus, but a big subsystem with multiple components (UDMAP, ringacc,
>>> INTA, INTR, timers, etc).
>>>
>>> What about to change the binding doc to simple-mfd like this
>>
>> That's really for things not memory-mapped (I'm sure you can probably
>> find an example to contradict me), so better to keep simple-bus if all
>> the child nodes have addresses.
>
> According to Documentation/devicetree/bindings/mfd/mfd.txt:
> - A range of memory registers containing "miscellaneous system
> registers" also known as a system controller "syscon" or any other
> memory range containing a mix of unrelated hardware devices.
>
> NAVSS (NAVigator SubSystem) falls in the later case, it contains
> unrelated blocks, like the UDMAP, ringacc, mailboxes, spinlocks,
> interrupt aggregator, interrupt router, etc.
>
> - compatible : "simple-mfd" - this signifies that the operating system
> should consider all subnodes of the MFD device as separate devices
> akin to how "simple-bus" indicates when to see subnodes as children
> for a simple memory-mapped bus.
>
> This is a bit confusing, but NAVSS is not really a bus, everything in it
> can be accessed by the CPU via memory mapped registers (some sub devices
> does not have registers defined, they are controlled via system firmware).
>
>> Do you need the node name to be 'navss' for some reason? If so, then
>> better have a compatible string in there to identify it. If not, just
>> use 'bus' and be done with it.
>
> We don't need unique compatible for the NAVSS itself as there is not
> much we can configure on the top level, it is 'just' a big subsystem
> with all sorts of things.
>
> I like to keep the 'navss' as node name as it gives human understandable
> representation of it in /sys for example, easier to see the topology.
>
> I just feel that the 'bus' does not really apply to what NAVSS is.
> Probably my view of simple-bus is not correct.
Can you advice on how to proceed? I would like to send v6 so Vinod can
pick it for next after 5.5-rc1 is tagged.
This is the only thing which I need to close on to be able to do that.
>
>>> cbass_main_navss: navss@30800000 {
>>> compatible = "simple-mfd";
>>> #address-cells = <2>;
>>> #size-cells = <2>;
>>> ...
>>> };
>>>
>>> and fix up the DT when I got to the point when I can send the patches to
>>> enable DMA for am654 and j721e?
>>
>> There's no requirement yet for DTS files to not have warnings.
>
> Sure, but it does not hurt if they are clean ;)
>
>>>>> + compatible:
>>>>> + oneOf:
>>>>> + - const: ti,am654-navss-main-udmap
>>>>> + - const: ti,am654-navss-mcu-udmap
>>>>> + - const: ti,j721e-navss-main-udmap
>>>>> + - const: ti,j721e-navss-mcu-udmap
>>>>
>>>> enum works better than oneOf+const. Better error messages.
>>>
>>> Like this:
>>> compatible:
>>> oneOf:
>>> - description: for AM654
>>> items:
>>> - enum:
>>> - ti,am654-navss-main-udmap
>>> - ti,am654-navss-mcu-udmap
>>>
>>> - description: for J721E
>>> items:
>>> - enum:
>>> - ti,j721e-navss-main-udmap
>>> - ti,j721e-navss-mcu-udmap
>>
>> If the 'description' was useful, but it's not. Just:
>>
>> compatible:
>> enum:
>> - ti,am654-navss-main-udmap
>> - ti,am654-navss-mcu-udmap
>> - ti,j721e-navss-main-udmap
>> - ti,j721e-navss-mcu-udmap
>
> OK, can I keep your Reviewed-by you have given to v5 if I do this change
> for v6?
>
>>
>>
>> Rob
>>
>
> - Péter
>
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
next prev parent reply other threads:[~2019-11-26 8:29 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-01 8:41 [PATCH v4 00/15] dmaengine/soc: Add Texas Instruments UDMA support Peter Ujfalusi
2019-11-01 8:41 ` [PATCH v4 01/15] bindings: soc: ti: add documentation for k3 ringacc Peter Ujfalusi
2019-11-11 4:07 ` Vinod Koul
2019-11-11 7:24 ` Peter Ujfalusi
2019-11-01 8:41 ` [PATCH v4 02/15] soc: ti: k3: add navss ringacc driver Peter Ujfalusi
2019-11-11 4:21 ` Vinod Koul
2019-11-11 7:39 ` Peter Ujfalusi
2019-11-01 8:41 ` [PATCH v4 03/15] dmaengine: doc: Add sections for per descriptor metadata support Peter Ujfalusi
2019-11-01 8:41 ` [PATCH v4 04/15] dmaengine: Add metadata_ops for dma_async_tx_descriptor Peter Ujfalusi
2019-11-01 8:41 ` [PATCH v4 05/15] dmaengine: Add support for reporting DMA cached data amount Peter Ujfalusi
2019-11-11 4:39 ` Vinod Koul
2019-11-11 8:00 ` Peter Ujfalusi
2019-11-01 8:41 ` [PATCH v4 06/15] dmaengine: ti: Add cppi5 header for K3 NAVSS/UDMA Peter Ujfalusi
2019-11-05 7:40 ` Tero Kristo
2019-11-01 8:41 ` [PATCH v4 07/15] dmaengine: ti: k3 PSI-L remote endpoint configuration Peter Ujfalusi
2019-11-05 7:49 ` Tero Kristo
2019-11-05 8:13 ` Peter Ujfalusi
2019-11-05 10:00 ` Grygorii Strashko
2019-11-05 10:27 ` Peter Ujfalusi
2019-11-05 11:25 ` Grygorii Strashko
2019-11-11 4:47 ` Vinod Koul
2019-11-11 8:47 ` Peter Ujfalusi
2019-11-01 8:41 ` [PATCH v4 08/15] dt-bindings: dma: ti: Add document for K3 UDMA Peter Ujfalusi
2019-11-05 2:19 ` Rob Herring
2019-11-05 10:08 ` Peter Ujfalusi
2019-11-14 17:53 ` Rob Herring
2019-11-15 9:45 ` Peter Ujfalusi
2019-11-26 8:29 ` Peter Ujfalusi [this message]
2019-11-01 8:41 ` [PATCH v4 09/15] dmaengine: ti: New driver for K3 UDMA - split#1: defines, structs, io func Peter Ujfalusi
2019-11-11 5:28 ` Vinod Koul
2019-11-11 8:33 ` Peter Ujfalusi
2019-11-11 9:00 ` Vinod Koul
2019-11-11 9:12 ` Peter Ujfalusi
2019-11-01 8:41 ` [PATCH v4 10/15] dmaengine: ti: New driver for K3 UDMA - split#2: probe/remove, xlate and filter_fn Peter Ujfalusi
2019-11-11 5:33 ` Vinod Koul
2019-11-11 9:16 ` Peter Ujfalusi
2019-11-12 5:34 ` Vinod Koul
2019-11-12 7:22 ` Peter Ujfalusi
2019-11-01 8:41 ` [PATCH v4 11/15] dmaengine: ti: New driver for K3 UDMA - split#3: alloc/free chan_resources Peter Ujfalusi
2019-11-11 6:06 ` Vinod Koul
2019-11-11 9:40 ` Peter Ujfalusi
2019-11-01 8:41 ` [PATCH v4 12/15] dmaengine: ti: New driver for K3 UDMA - split#4: dma_device callbacks 1 Peter Ujfalusi
2019-11-11 6:09 ` Vinod Koul
2019-11-11 10:29 ` Peter Ujfalusi
2019-11-12 5:36 ` Vinod Koul
2019-11-12 7:24 ` Peter Ujfalusi
2019-11-01 8:41 ` [PATCH v4 13/15] dmaengine: ti: New driver for K3 UDMA - split#5: dma_device callbacks 2 Peter Ujfalusi
2019-11-01 8:41 ` [PATCH v4 14/15] dmaengine: ti: New driver for K3 UDMA - split#6: Kconfig and Makefile Peter Ujfalusi
2019-11-11 6:11 ` Vinod Koul
2019-11-11 10:30 ` Peter Ujfalusi
2019-11-01 8:41 ` [PATCH v4 15/15] dmaengine: ti: k3-udma: Add glue layer for non DMAengine users Peter Ujfalusi
2019-11-11 6:12 ` Vinod Koul
2019-11-11 10:31 ` Peter Ujfalusi
2019-11-12 5:37 ` Vinod Koul
2019-11-12 7:25 ` 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=f2f4a4f5-335d-9a20-b410-91a7619fb84d@ti.com \
--to=peter.ujfalusi@ti.com \
--cc=dan.j.williams@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=grygorii.strashko@ti.com \
--cc=j-keerthy@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lokeshvutla@ti.com \
--cc=nm@ti.com \
--cc=robh@kernel.org \
--cc=ssantosh@kernel.org \
--cc=t-kristo@ti.com \
--cc=tony@atomide.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).