November 2019 - System-dt - lists.openampproject.org

[PATCH 0/3] system device tree initial set of bindings

by Stefano Stabellini

Hi all, This small series introduces a few key concepts needed to make system device tree a reality: - cpus,cluster - indirect-bus - address-map We discussed a few times making address-map a property that can be used by any bus masters, including a PCI RC for instance. Thus, I tried not to tie address-map with cpus,cluster. Let me know if you would like to make address-map a cpus,cluster specific property instead. Each patch introduces references to other sections introduced by the other patches. In other words, the patch series doesn't bisect properly, but I don't know if that is important for devicetree spec changes. Nothing related to interrupts is introduced because the existing bindings seem to be sufficient for the task. I have also attached a complete example where the properties are used, and also interrupts are handled. Cheers, Stefano

5 years

2
2
0 0

Re: [System-dt] [PATCH 2/3] Introduce cpus,cluster

by Benjamin GAIGNARD

On 11/7/19 11:15 PM, Stefano Stabellini via System-dt wrote: > Signed-off-by: Stefano Stabellini <stefano.stabellini(a)xilinx.com> > --- > source/devicenodes.rst | 88 ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 88 insertions(+) > > diff --git a/source/devicenodes.rst b/source/devicenodes.rst > index 8825ad9..bcf6163 100644 > --- a/source/devicenodes.rst > +++ b/source/devicenodes.rst > @@ -737,3 +737,91 @@ each with their own on-chip L2 and a shared L3. > }; > }; > > +.. _sect-cpus-cluster: > + > +CPUs Cluster Node Properties > +---------------------------- > + > +Similarly to ``/cpus``, CPUs cluster nodes do not represent real devices > +in the system, but act as containers for children cpu nodes. They group > +together a set of CPUs that share the same view of the system, the same > +``address-map`` (see section :ref:`sect-address-map`). CPUs clusters are > +optional, there can be multiple in a single system, and are represented > +by nodes compatible with ``cpus,cluster``. Hi Stefano, Earlier this year I have proposed a concept of domain-ctrl [1]. I think it is close to your idea of CPUs clusters since it aim to describe group of hardware blocks that share the same access rights in the system. I was targeting the bus firewalls that we can find on many SoC. Do you think we can mix these two concepts ? It would, at least, means extend your CPUs cluster concept to be able to describe CPU when they are running in TrustZone. Regards, Benjamin [1] https://lwn.net/ml/linux-kernel/20190227121232.24873-1-benjamin.gaignard@st… > + > +A child ``cpu`` node represents a system CPU. All ``cpus`` nodes under > +the same cluster share key properties (i.e. instruction set) so that a > +SMP operating system could run on all of the CPUs in the cluster if > +configured to do so. > + > +.. tabularcolumns:: | p{4cm} p{0.75cm} p{4cm} p{6.5cm} | > +.. table:: ``CPUs cluster`` Node Properties > + > + ======================= ===== ===================== =============================================== > + Property Name Usage Value Type Definition > + ======================= ===== ===================== =============================================== > + ``compatible`` R ``<string list>`` Value shall include "cpus,cluster". > + ``#address-cells`` R ``<u32>`` The value specifies how many cells each > + element of the ``reg`` property array takes in > + children of this node. > + ``#size-cells`` R ``<u32>`` Value shall be 0. Specifies that no size is > + required in the ``reg`` property in children of > + this node. > + ``address-map`` SD ``<array>`` If present, it specifies an address mapping > + translation between the root node and the > + address space of the CPUs cluster. address-map > + is fully described in section > + :ref:`sect-address-map`. > + Usage legend: R=Required, O=Optional, OR=Optional but Recommended, SD=See Definition > + =================================================================================================== > + > +The CPUs cluster node may contain properties that are common across CPU > +nodes. > + > +Example: > + > +.. code-block:: dts > + > + cpus_a53 { > + #size-cells = <0x0>; > + #address-cells = <0x1>; > + compatible = "cpus,cluster"; > + > + cpu@0 { > + reg = <0x0>; > + compatible = "arm,cortex-a53"; > + device_type = "cpu"; > + }; > + cpu@1 { > + reg = <0x1>; > + compatible = "arm,cortex-a53"; > + device_type = "cpu"; > + }; > + cpu@2 { > + reg = <0x2>; > + compatible = "arm,cortex-a53"; > + device_type = "cpu"; > + }; > + cpu@3 { > + reg = <0x3>; > + compatible = "arm,cortex-a53"; > + device_type = "cpu"; > + }; > + }; > + > + cpus_r5 { > + #size-cells = <0x0>; > + #address-cells = <0x1>; > + compatible = "cpus,cluster"; > + > + cpu@0 { > + reg = <0x0>; > + compatible = "arm,cortex-r5"; > + device_type = "cpu"; > + }; > + cpu@1 { > + reg = <0x1>; > + compatible = "arm,cortex-r5"; > + device_type = "cpu"; > + }; > + };

5 years

2
4
0 0

System Device Tree call - December

by Nathalie Chan King Choy

Hi all, Please join the call on Zoom: https://zoom.us/my/openampproject (If you need the meeting ID, it's 9031895760) Due to the holiday season, we should discuss during the December call what timeframe makes sense for a next call in January. Please send thoughts by email if you can't attend the call. The notes from the previous call (Oct 31) can be found on the OpenAMP wiki at this link: https://github.com/OpenAMP/open-amp/wiki/System-DT-Meeting-Notes-2019#20191… Action items from the previous call: - All: if you can think of simple solution to interrupt-map info duplication, let Stefano know & he will try to add to the example. - Stefano: Remove ranges from amba_rpu - Stefano: In next couple weeks, look at GPIO controller extensions & write in detail & send to list so we can discuss. - Nathalie: Confirm with Kumar that Wed slot will work & send out meeting invitation for 4 weeks from now. [Update: Picked Dec 11 to avoid US Thanksgiving week] - Nathalie: Add Connect meeting attendees & send out info on how to subscribe to OpenAMP system-dt mailing list. - Nathalie: At bottom of all system-dt-related emails, put how to join the list/get involved/learn more For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/system-dt For information about the System Device Trees effort, including a link to the intro presentation from Linaro Connect SAN19: https://github.com/OpenAMP/open-amp/wiki/System-Device-Trees Best regards, Nathalie C. Chan King Choy Project Manager focused on Open Source and Community

5 years, 1 month

1
0
0 0

[PATCH 3/3] Introduce address-map

by Stefano Stabellini

Signed-off-by: Stefano Stabellini <stefano.stabellini(a)xilinx.com> --- source/devicetree-basics.rst | 59 ++++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) diff --git a/source/devicetree-basics.rst b/source/devicetree-basics.rst index b91b048..82242ad 100644 --- a/source/devicetree-basics.rst +++ b/source/devicetree-basics.rst @@ -803,6 +803,65 @@ Description: from the *#size-cells* of this node (the node in which the dma-ranges property appears). +.. _sect-address-map: + +address-map +~~~~~~~~~~~ + +Property name: ``address-map`` + +Value type: ``<empty>`` or ``<prop-encoded-array>`` encoded as an arbitrary +number of (*bus-master-address*, *ref-node*, *root-node-address*, *length*) +quartets. + +Description: + + CPUs, represented by ``cpu`` nodes under either ``/cpus`` or a cluster + compatible to ``cpus,cluster`` and other bus masters (i.e. PCI Root + Complexes), can have different address mappings compared to the one of the + root node. The *address-map* property provides a mean of defining a mapping, + or translation, between the address space of the root node and the address + space of the CPUs cluster (or other bus master). See section + :ref:`sect-cpus-cluster` for a full description of CPUs clusters. + *address-map* can be used to create a mapping between the address + space of an ``indirect-bus`` and the address space of the node. + ``indirect-bus`` is defined in section :ref:`sect-bindings-indirect-bus`. + + The format of the value of the *address-map* property is an arbitrary number + of quartets of (*node-address*, *ref-node*, *root-node-address*, *length*). + Each quartet specified describes a contiguous address range. + + * the *node-address* is a physical address within this node address space + (the node in which the address-map property appears). The number of cells + to represent the address is determined by the *#ranges-address-cells* + property of this node. + + * *ref-node* is a phandle that points to the node describing the resource + whose address is being mapped into this node address space. + + * *root-node-address* is a physical address within the root node address + space. The number of cells to represent the parent address can be + determined from the #address-cells property of root node. + + * *length* specifies the size of the range in this node address space. + The number of cells to represent the size can be determined by the + *#ranges-size-cells* of this node. + +If the property is defined with an <empty> value, it specifies that this node +has no mappings of the root node address space. + +If the property is not present, it is assumed that the address space of +this node and the address space of the root node are identical. + +Example: + +.. code-block:: dts + + #ranges-size-cells = <0x1>; + #ranges-address-cells = <0x1>; + address-map = <0xf0000000 &amba 0xf0000000 0x10000000 + 0xffe90000 &tcm_bus 0x0 0x10000>; + name (deprecated) ~~~~~~~~~~~~~~~~~ -- 2.17.1

5 years, 1 month

1
0
0 0

[PATCH 2/3] Introduce cpus,cluster

by Stefano Stabellini

Signed-off-by: Stefano Stabellini <stefano.stabellini(a)xilinx.com> --- source/devicenodes.rst | 88 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+) diff --git a/source/devicenodes.rst b/source/devicenodes.rst index 8825ad9..bcf6163 100644 --- a/source/devicenodes.rst +++ b/source/devicenodes.rst @@ -737,3 +737,91 @@ each with their own on-chip L2 and a shared L3. }; }; +.. _sect-cpus-cluster: + +CPUs Cluster Node Properties +---------------------------- + +Similarly to ``/cpus``, CPUs cluster nodes do not represent real devices +in the system, but act as containers for children cpu nodes. They group +together a set of CPUs that share the same view of the system, the same +``address-map`` (see section :ref:`sect-address-map`). CPUs clusters are +optional, there can be multiple in a single system, and are represented +by nodes compatible with ``cpus,cluster``. + +A child ``cpu`` node represents a system CPU. All ``cpus`` nodes under +the same cluster share key properties (i.e. instruction set) so that a +SMP operating system could run on all of the CPUs in the cluster if +configured to do so. + +.. tabularcolumns:: | p{4cm} p{0.75cm} p{4cm} p{6.5cm} | +.. table:: ``CPUs cluster`` Node Properties + + ======================= ===== ===================== =============================================== + Property Name Usage Value Type Definition + ======================= ===== ===================== =============================================== + ``compatible`` R ``<string list>`` Value shall include "cpus,cluster". + ``#address-cells`` R ``<u32>`` The value specifies how many cells each + element of the ``reg`` property array takes in + children of this node. + ``#size-cells`` R ``<u32>`` Value shall be 0. Specifies that no size is + required in the ``reg`` property in children of + this node. + ``address-map`` SD ``<array>`` If present, it specifies an address mapping + translation between the root node and the + address space of the CPUs cluster. address-map + is fully described in section + :ref:`sect-address-map`. + Usage legend: R=Required, O=Optional, OR=Optional but Recommended, SD=See Definition + =================================================================================================== + +The CPUs cluster node may contain properties that are common across CPU +nodes. + +Example: + +.. code-block:: dts + + cpus_a53 { + #size-cells = <0x0>; + #address-cells = <0x1>; + compatible = "cpus,cluster"; + + cpu@0 { + reg = <0x0>; + compatible = "arm,cortex-a53"; + device_type = "cpu"; + }; + cpu@1 { + reg = <0x1>; + compatible = "arm,cortex-a53"; + device_type = "cpu"; + }; + cpu@2 { + reg = <0x2>; + compatible = "arm,cortex-a53"; + device_type = "cpu"; + }; + cpu@3 { + reg = <0x3>; + compatible = "arm,cortex-a53"; + device_type = "cpu"; + }; + }; + + cpus_r5 { + #size-cells = <0x0>; + #address-cells = <0x1>; + compatible = "cpus,cluster"; + + cpu@0 { + reg = <0x0>; + compatible = "arm,cortex-r5"; + device_type = "cpu"; + }; + cpu@1 { + reg = <0x1>; + compatible = "arm,cortex-r5"; + device_type = "cpu"; + }; + }; -- 2.17.1

5 years, 1 month

1
0
0 0

[PATCH 1/3] Introduce indirect-bus

by Stefano Stabellini

Signed-off-by: Stefano Stabellini <stefano.stabellini(a)xilinx.com> --- source/device-bindings.rst | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/source/device-bindings.rst b/source/device-bindings.rst index 5cdee09..f3df006 100644 --- a/source/device-bindings.rst +++ b/source/device-bindings.rst @@ -436,3 +436,30 @@ represented as a node with a compatible value of "simple-bus". ranges). Usage legend: R=Required, O=Optional, OR=Optional but Recommended, SD=See Definition ==================================================================================================== + + +.. _sect-bindings-indirect-bus: + +``indirect-bus`` Compatible Value +--------------------------------- + +``indirect-bus`` specifies a type of bus that can be accessed directly +without additional configuration required. However, it does not +automatically map to the parent address space. As a consequence, CPUs +represented by cpu nodes either under ``/cpus`` or under a +"cpus,cluster" compatible node will not have a mapping of it, unless +they also have an ``address-map`` property mapping it. In fact, +``address-map`` can be used to specify a mapping of an ``indirect-bus`` +into the address space of the cluster, see section +:ref:`sect-address-map` for a complete description of the property. + + +.. tabularcolumns:: | p{4cm} p{0.75cm} p{4cm} p{6.5cm} | +.. table:: ``indirect-bus`` Compatible Node Properties + + ======================== ===== ===================== =============================================== + Property Name Usage Value Type Definition + ======================== ===== ===================== =============================================== + ``compatible`` R ``<string>`` Value shall include "indirect-bus". + Usage legend: R=Required, O=Optional, OR=Optional but Recommended, SD=See Definition + ==================================================================================================== -- 2.17.1

5 years, 1 month

1
0
0 0

Re: [System-dt] 2019-10-31 System DT meeting notes, mailing list info

by Rob Herring

On Fri, Nov 1, 2019 at 2:31 PM Stefano Stabellini via System-dt <system-dt(a)lists.openampproject.org> wrote: > > On Thu, 31 Oct 2019, Nathalie Chan King Choy via System-dt wrote: > > Hi all, > > > > Welcome to the OpenAMP system-dt mailing list. You're subscribed because > > you are either (1) in the OpenAMP TSC list, (2) on the DTE Wednesday call > > invitation that I received, (3) were on the System DT meeting invitation > > from Linaro Connect SAN19. Info is at the end of this email on how others > > can subscribe, or how you can unsubscribe yourself. If you are not sure if > > your colleague is subscribed & want to make sure they are, as a member of > > the list, you are able to log in & see who else is a member, from the list > > info page (use the password reminder in the edit options section to find out > > your auto-generated password). > > > > The notes from today's call can be found on the OpenAMP wiki at this link: > > https://github.com/OpenAMP/open-amp/wiki/System-DT-Meeting-Notes-2019#20191… > > Hi Nathalie, > > Thank you for the notes. I'll take this opportunity to test the new > mailing list as well ;-) > > > > In today's call, Stefano presented from the example System DTS file that is > > attached. It is an early draft based on discussions between Stefano & > > Grant after Linaro Connect SAN19, related to getting a system DT to work in > > the default case, without requiring pruning. (I wasn't sure how to allow .dts > > files in the mailing list content filter, so I changed the extension to .txt) > > > > Action items: > > - All: if you can think of simple solution to interrupt-map info > > duplication, let Stefano know & he will try to add to the example. > > - Stefano: Remove ranges from amba_rpu > > - Stefano: In next couple weeks, look at GPIO controller extensions & write > > in detail & send to list so we can discuss. > > I am trying to look for the interrupt-related GPIO extensions, and the > only one I could find is: socionext,interrupt-ranges > from Documentation/devicetree/bindings/gpio/gpio-uniphier.txt: > > - socionext,interrupt-ranges: Specifies an interrupt number mapping between > this GPIO controller and its interrupt parent, in the form of arbitrary > number of <child-interrupt-base parent-interrupt-base length> triplets. No, there's numerous examples that *should* have used interrupt-map, but invented their own thing. > which is very similar to what we need here, but it looks like a > socionext specific property while I seem to recall that Rob said that it > was made "standard". > > Rob, is this the property you had in mind? Or is there another one? No. It's '*-map-pass-thru' and in the DT spec. Here's the commit adding it[1]. The motivation for this was GPIO, but the spec was written generically. Rob [1] https://github.com/devicetree-org/devicetree-specification/commit/32c96cd64…

5 years, 1 month

2
2
0 0

Re: [System-dt] 2019-10-31 System DT meeting notes, mailing list info

by Stefano Stabellini

On Thu, 31 Oct 2019, Nathalie Chan King Choy via System-dt wrote: > Hi all, > > Welcome to the OpenAMP system-dt mailing list. You're subscribed because > you are either (1) in the OpenAMP TSC list, (2) on the DTE Wednesday call > invitation that I received, (3) were on the System DT meeting invitation > from Linaro Connect SAN19. Info is at the end of this email on how others > can subscribe, or how you can unsubscribe yourself. If you are not sure if > your colleague is subscribed & want to make sure they are, as a member of > the list, you are able to log in & see who else is a member, from the list > info page (use the password reminder in the edit options section to find out > your auto-generated password). > > The notes from today's call can be found on the OpenAMP wiki at this link: > https://github.com/OpenAMP/open-amp/wiki/System-DT-Meeting-Notes-2019#20191… Hi Nathalie, Thank you for the notes. I'll take this opportunity to test the new mailing list as well ;-) > In today's call, Stefano presented from the example System DTS file that is > attached. It is an early draft based on discussions between Stefano & > Grant after Linaro Connect SAN19, related to getting a system DT to work in > the default case, without requiring pruning. (I wasn't sure how to allow .dts > files in the mailing list content filter, so I changed the extension to .txt) > > Action items: > - All: if you can think of simple solution to interrupt-map info > duplication, let Stefano know & he will try to add to the example. > - Stefano: Remove ranges from amba_rpu > - Stefano: In next couple weeks, look at GPIO controller extensions & write > in detail & send to list so we can discuss. I am trying to look for the interrupt-related GPIO extensions, and the only one I could find is: socionext,interrupt-ranges from Documentation/devicetree/bindings/gpio/gpio-uniphier.txt: - socionext,interrupt-ranges: Specifies an interrupt number mapping between this GPIO controller and its interrupt parent, in the form of arbitrary number of <child-interrupt-base parent-interrupt-base length> triplets. which is very similar to what we need here, but it looks like a socionext specific property while I seem to recall that Rob said that it was made "standard". Rob, is this the property you had in mind? Or is there another one?

5 years, 1 month

1
0
0 0

2024

2023

2022

2021

2020

2019

System-dt November 2019