diff mbox

[v2,5/5] vf610-soc: Add Vybrid SoC device tree binding documentation

Message ID 65f3a7bd7a9faf1b390644d7c599c69683c753c4.1462171990.git.maitysanchayan@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Sanchayan May 2, 2016, 7:05 a.m. UTC
Add device tree binding documentation for Vybrid SoC.

Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
 .../bindings/arm/freescale/fsl,vf610-soc.txt       | 35 ++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt

Comments

Rob Herring May 4, 2016, 2:30 a.m. UTC | #1
On Mon, May 02, 2016 at 12:35:04PM +0530, Sanchayan Maity wrote:
> Add device tree binding documentation for Vybrid SoC.
> 
> Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
> ---
>  .../bindings/arm/freescale/fsl,vf610-soc.txt       | 35 ++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> new file mode 100644
> index 0000000..bdd95e8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> @@ -0,0 +1,35 @@
> +Vybrid System-on-Chip
> +---------------------
> +
> +Required properties:
> +
> +- #address-cells: must be 1
> +- #size-cells: must be 1
> +- compatible: "fsl,vf610-soc-bus", "simple-bus"

If this is a bus, put the file in bindings/bus/...

> +- interrupt-parent: phandle to the MSCM interrupt router node
> +- ranges
> +- fsl,rom-revision: phandle to the on-chip ROM node and address of rom
> +  revision register

Why is this needed here? Can't you search the tree for the ROM node and 
get this info.

> +- fsl,cpu-count: phandle to the MSCM CPU configuration node and address of
> +  CPU count register
> +- fsl,l2-size: phandle to the MSCM CPU configuration node and address of
> +  L2 cache size register
> +- nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> +- nvmem-cell-names: should contain string names "cfg0" and "cfg1"

How are all these properties used?

> +
> +Example:
> +
> +	soc {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		compatible = "fsl,vf610-soc-bus", "simple-bus";
> +		interrupt-parent = <&mscm_ir>;
> +		ranges;
> +		fsl,rom-revision = <&ocrom 0x80>;
> +		fsl,cpu-count = <&mscm_cpucfg 0x2C>;
> +		fsl,l2-size = <&mscm_cpucfg 0x14>;
> +		nvmem-cells = <&ocotp_cfg0>, <&ocotp_cfg1>;
> +		nvmem-cell-names = "cfg0", "cfg1";
> +
> +		...
> +	};
> -- 
> 2.8.2
>
Sanchayan May 5, 2016, 8:27 a.m. UTC | #2
Hello Rob,

On 16-05-03 21:30:26, Rob Herring wrote:
> On Mon, May 02, 2016 at 12:35:04PM +0530, Sanchayan Maity wrote:
> > Add device tree binding documentation for Vybrid SoC.
> > 
> > Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
> > ---
> >  .../bindings/arm/freescale/fsl,vf610-soc.txt       | 35 ++++++++++++++++++++++
> >  1 file changed, 35 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > new file mode 100644
> > index 0000000..bdd95e8
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > @@ -0,0 +1,35 @@
> > +Vybrid System-on-Chip
> > +---------------------
> > +
> > +Required properties:
> > +
> > +- #address-cells: must be 1
> > +- #size-cells: must be 1
> > +- compatible: "fsl,vf610-soc-bus", "simple-bus"
> 
> If this is a bus, put the file in bindings/bus/...

The fsl,vf610-soc-bus binding is used to bind the driver in question with
an appropriate compatible node.

Basically being a standalone platform driver, there was need of a compatible
property to bind on. Introducing a separate device tree node for it's sake
didn't seem appropriate so the alteration to SoC node's compatible.

> 
> > +- interrupt-parent: phandle to the MSCM interrupt router node
> > +- ranges
> > +- fsl,rom-revision: phandle to the on-chip ROM node and address of rom
> > +  revision register
> 
> Why is this needed here? Can't you search the tree for the ROM node and 
> get this info.

Strictly per say this and next two can be specified in their respective nodes
of ocrom and mscm cpucfg, however they would then require the use of syscon_
regmap_lookup_by_compatible and this seems clean along with the introduction
of new syscon_regmap_read_from_offset function used with SoC node.

> 
> > +- fsl,cpu-count: phandle to the MSCM CPU configuration node and address of
> > +  CPU count register
> > +- fsl,l2-size: phandle to the MSCM CPU configuration node and address of
> > +  L2 cache size register
> > +- nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> > +- nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> 
> How are all these properties used?

All the above five are used to get the relevant values from the registers and
expose the information for SoC sysfs device.
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-devices-soc

nvmem are consumer nodes which are accessed using the NVMEM consumer API's
leveraging the NVMEM framework and NVMEM vf610 ocotp driver.

Regards,
Sanchayan.

> 
> > +
> > +Example:
> > +
> > +	soc {
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +		compatible = "fsl,vf610-soc-bus", "simple-bus";
> > +		interrupt-parent = <&mscm_ir>;
> > +		ranges;
> > +		fsl,rom-revision = <&ocrom 0x80>;
> > +		fsl,cpu-count = <&mscm_cpucfg 0x2C>;
> > +		fsl,l2-size = <&mscm_cpucfg 0x14>;
> > +		nvmem-cells = <&ocotp_cfg0>, <&ocotp_cfg1>;
> > +		nvmem-cell-names = "cfg0", "cfg1";
> > +
> > +		...
> > +	};
> > -- 
> > 2.8.2
> >
Rob Herring May 9, 2016, 5:14 p.m. UTC | #3
On Thu, May 5, 2016 at 3:27 AM,  <maitysanchayan@gmail.com> wrote:
> Hello Rob,
>
> On 16-05-03 21:30:26, Rob Herring wrote:
>> On Mon, May 02, 2016 at 12:35:04PM +0530, Sanchayan Maity wrote:
>> > Add device tree binding documentation for Vybrid SoC.
>> >
>> > Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
>> > ---
>> >  .../bindings/arm/freescale/fsl,vf610-soc.txt       | 35 ++++++++++++++++++++++
>> >  1 file changed, 35 insertions(+)
>> >  create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
>> > new file mode 100644
>> > index 0000000..bdd95e8
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
>> > @@ -0,0 +1,35 @@
>> > +Vybrid System-on-Chip
>> > +---------------------
>> > +
>> > +Required properties:
>> > +
>> > +- #address-cells: must be 1
>> > +- #size-cells: must be 1
>> > +- compatible: "fsl,vf610-soc-bus", "simple-bus"
>>
>> If this is a bus, put the file in bindings/bus/...
>
> The fsl,vf610-soc-bus binding is used to bind the driver in question with
> an appropriate compatible node.
>
> Basically being a standalone platform driver, there was need of a compatible
> property to bind on. Introducing a separate device tree node for it's sake
> didn't seem appropriate so the alteration to SoC node's compatible.

Ah, so you are designing a node around the needs of a Linux specific
driver. Don't do that. DT describes the h/w and this node is not a h/w
block.

Create a platform device based on a matching SOC compatible string
instead and make your driver find the information it needs directly
from the relevant nodes like the ROM node.

>> > +- interrupt-parent: phandle to the MSCM interrupt router node
>> > +- ranges
>> > +- fsl,rom-revision: phandle to the on-chip ROM node and address of rom
>> > +  revision register
>>
>> Why is this needed here? Can't you search the tree for the ROM node and
>> get this info.
>
> Strictly per say this and next two can be specified in their respective nodes
> of ocrom and mscm cpucfg, however they would then require the use of syscon_
> regmap_lookup_by_compatible and this seems clean along with the introduction
> of new syscon_regmap_read_from_offset function used with SoC node.

That does not make sense. You can find the ROM node by compatible
string, get the address, get an revision offset property, and read the
address. There's no need for syscon nor regmap here.

>> > +- fsl,cpu-count: phandle to the MSCM CPU configuration node and address of
>> > +  CPU count register
>> > +- fsl,l2-size: phandle to the MSCM CPU configuration node and address of
>> > +  L2 cache size register
>> > +- nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
>> > +- nvmem-cell-names: should contain string names "cfg0" and "cfg1"
>>
>> How are all these properties used?
>
> All the above five are used to get the relevant values from the registers and
> expose the information for SoC sysfs device.
> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-devices-soc
>
> nvmem are consumer nodes which are accessed using the NVMEM consumer API's
> leveraging the NVMEM framework and NVMEM vf610 ocotp driver.

So, please describe in the binding doc what the values contain. cfg0
and cfg1 is meaningless. But based on the above, this whole binding
should go.

Rob
Stefan Agner May 9, 2016, 6:25 p.m. UTC | #4
On 2016-05-09 10:14, Rob Herring wrote:
> On Thu, May 5, 2016 at 3:27 AM,  <maitysanchayan@gmail.com> wrote:
>> Hello Rob,
>>
>> On 16-05-03 21:30:26, Rob Herring wrote:
>>> On Mon, May 02, 2016 at 12:35:04PM +0530, Sanchayan Maity wrote:
>>> > Add device tree binding documentation for Vybrid SoC.
>>> >
>>> > Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
>>> > ---
>>> >  .../bindings/arm/freescale/fsl,vf610-soc.txt       | 35 ++++++++++++++++++++++
>>> >  1 file changed, 35 insertions(+)
>>> >  create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
>>> >
>>> > diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
>>> > new file mode 100644
>>> > index 0000000..bdd95e8
>>> > --- /dev/null
>>> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
>>> > @@ -0,0 +1,35 @@
>>> > +Vybrid System-on-Chip
>>> > +---------------------
>>> > +
>>> > +Required properties:
>>> > +
>>> > +- #address-cells: must be 1
>>> > +- #size-cells: must be 1
>>> > +- compatible: "fsl,vf610-soc-bus", "simple-bus"
>>>
>>> If this is a bus, put the file in bindings/bus/...
>>
>> The fsl,vf610-soc-bus binding is used to bind the driver in question with
>> an appropriate compatible node.
>>
>> Basically being a standalone platform driver, there was need of a compatible
>> property to bind on. Introducing a separate device tree node for it's sake
>> didn't seem appropriate so the alteration to SoC node's compatible.
> 
> Ah, so you are designing a node around the needs of a Linux specific
> driver. Don't do that. DT describes the h/w and this node is not a h/w
> block.
> 
> Create a platform device based on a matching SOC compatible string
> instead and make your driver find the information it needs directly
> from the relevant nodes like the ROM node.

That reads like my words a year ago:
https://lkml.org/lkml/2015/5/22/408

Initially pretty much everything was hard-coded in the driver.

Arnd then pushed to use more descriptive in the device tree.

Of course, we should not end up making up relations which are not there
in hardware. We need to find the right balance.

Here is my suggestion:
1. Add "fsl,vf610-soc-bus" as compatible string to the soc node, use it
to bind the "soc bus driver" as a platform driver located in driver/soc/
2. Add ROM as syscon device (it is not erasable ROM memory, hence eeprom
seems not to be appropriate)
3. In the new soc bus driver, search for the relevant nodes using
hardcoded strings:
   - "ocrom" to get the syscon device, read the ROM revision with the
hardcoded offset
   - "ocotp" to get the NVMEM device or "cfg0"/"cfg1" to the cells
directly, read the values using the defined cells.
   - "mscm_cpucfg" is already there as a syscon device

Arnd, Rob, does that sound reasonable?

--
Stefan
Rob Herring May 9, 2016, 10:58 p.m. UTC | #5
On Mon, May 9, 2016 at 1:25 PM, Stefan Agner <stefan@agner.ch> wrote:
> On 2016-05-09 10:14, Rob Herring wrote:
>> On Thu, May 5, 2016 at 3:27 AM,  <maitysanchayan@gmail.com> wrote:
>>> Hello Rob,
>>>
>>> On 16-05-03 21:30:26, Rob Herring wrote:
>>>> On Mon, May 02, 2016 at 12:35:04PM +0530, Sanchayan Maity wrote:
>>>> > Add device tree binding documentation for Vybrid SoC.
>>>> >
>>>> > Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
>>>> > ---
>>>> >  .../bindings/arm/freescale/fsl,vf610-soc.txt       | 35 ++++++++++++++++++++++
>>>> >  1 file changed, 35 insertions(+)
>>>> >  create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
>>>> >
>>>> > diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
>>>> > new file mode 100644
>>>> > index 0000000..bdd95e8
>>>> > --- /dev/null
>>>> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
>>>> > @@ -0,0 +1,35 @@
>>>> > +Vybrid System-on-Chip
>>>> > +---------------------
>>>> > +
>>>> > +Required properties:
>>>> > +
>>>> > +- #address-cells: must be 1
>>>> > +- #size-cells: must be 1
>>>> > +- compatible: "fsl,vf610-soc-bus", "simple-bus"
>>>>
>>>> If this is a bus, put the file in bindings/bus/...
>>>
>>> The fsl,vf610-soc-bus binding is used to bind the driver in question with
>>> an appropriate compatible node.
>>>
>>> Basically being a standalone platform driver, there was need of a compatible
>>> property to bind on. Introducing a separate device tree node for it's sake
>>> didn't seem appropriate so the alteration to SoC node's compatible.
>>
>> Ah, so you are designing a node around the needs of a Linux specific
>> driver. Don't do that. DT describes the h/w and this node is not a h/w
>> block.
>>
>> Create a platform device based on a matching SOC compatible string
>> instead and make your driver find the information it needs directly
>> from the relevant nodes like the ROM node.
>
> That reads like my words a year ago:
> https://lkml.org/lkml/2015/5/22/408
>
> Initially pretty much everything was hard-coded in the driver.
>
> Arnd then pushed to use more descriptive in the device tree.
>
> Of course, we should not end up making up relations which are not there
> in hardware. We need to find the right balance.
>
> Here is my suggestion:
> 1. Add "fsl,vf610-soc-bus" as compatible string to the soc node, use it
> to bind the "soc bus driver" as a platform driver located in driver/soc/

I'm not convinced this is a h/w block. This keeps coming up and I
think this is a kernel problem, not a DT problem. Let's face it that
there are drivers at the SOC level which don't fit into a DT node.
They may be the exception, but they are a common exception. My
proposal for how to deal with these cases is here[1].

I also think drivers/soc is a mess because it is randomly used or not.
IMO, using it should not be at the whim of whomever does SOC support.

> 2. Add ROM as syscon device (it is not erasable ROM memory, hence eeprom
> seems not to be appropriate)

It is not a syscon. It is just memory. nvmem covers read-only memory,
so I have no issue using that.

Rob

[1] https://lkml.org/lkml/2013/10/30/27
Stefan Agner May 10, 2016, 1:13 a.m. UTC | #6
On 2016-05-09 15:58, Rob Herring wrote:
> On Mon, May 9, 2016 at 1:25 PM, Stefan Agner <stefan@agner.ch> wrote:
>> On 2016-05-09 10:14, Rob Herring wrote:
>>> On Thu, May 5, 2016 at 3:27 AM,  <maitysanchayan@gmail.com> wrote:
>>>> Hello Rob,
>>>>
>>>> On 16-05-03 21:30:26, Rob Herring wrote:
>>>>> On Mon, May 02, 2016 at 12:35:04PM +0530, Sanchayan Maity wrote:
>>>>> > Add device tree binding documentation for Vybrid SoC.
>>>>> >
>>>>> > Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
>>>>> > ---
>>>>> >  .../bindings/arm/freescale/fsl,vf610-soc.txt       | 35 ++++++++++++++++++++++
>>>>> >  1 file changed, 35 insertions(+)
>>>>> >  create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
>>>>> >
>>>>> > diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
>>>>> > new file mode 100644
>>>>> > index 0000000..bdd95e8
>>>>> > --- /dev/null
>>>>> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
>>>>> > @@ -0,0 +1,35 @@
>>>>> > +Vybrid System-on-Chip
>>>>> > +---------------------
>>>>> > +
>>>>> > +Required properties:
>>>>> > +
>>>>> > +- #address-cells: must be 1
>>>>> > +- #size-cells: must be 1
>>>>> > +- compatible: "fsl,vf610-soc-bus", "simple-bus"
>>>>>
>>>>> If this is a bus, put the file in bindings/bus/...
>>>>
>>>> The fsl,vf610-soc-bus binding is used to bind the driver in question with
>>>> an appropriate compatible node.
>>>>
>>>> Basically being a standalone platform driver, there was need of a compatible
>>>> property to bind on. Introducing a separate device tree node for it's sake
>>>> didn't seem appropriate so the alteration to SoC node's compatible.
>>>
>>> Ah, so you are designing a node around the needs of a Linux specific
>>> driver. Don't do that. DT describes the h/w and this node is not a h/w
>>> block.
>>>
>>> Create a platform device based on a matching SOC compatible string
>>> instead and make your driver find the information it needs directly
>>> from the relevant nodes like the ROM node.
>>
>> That reads like my words a year ago:
>> https://lkml.org/lkml/2015/5/22/408
>>
>> Initially pretty much everything was hard-coded in the driver.
>>
>> Arnd then pushed to use more descriptive in the device tree.
>>
>> Of course, we should not end up making up relations which are not there
>> in hardware. We need to find the right balance.
>>
>> Here is my suggestion:
>> 1. Add "fsl,vf610-soc-bus" as compatible string to the soc node, use it
>> to bind the "soc bus driver" as a platform driver located in driver/soc/
> 
> I'm not convinced this is a h/w block. This keeps coming up and I
> think this is a kernel problem, not a DT problem. Let's face it that
> there are drivers at the SOC level which don't fit into a DT node.
> They may be the exception, but they are a common exception. My
> proposal for how to deal with these cases is here[1].

Probably "fsl,vf610-soc" would be better than "fsl,vf610-soc-bus".

But the SoC is definitely a h/w block! Despite all the individual
silicon in there, I can even touch the SoC ;-)

But yeah, I understand what you are saying... We model it as a
container, and do not attribute any specific thing directly to it. But
aren't there other containers where we bind to? Is it wrong to bind a
driver to a container, if that driver implements issues concerning that
level..?

The two drivers under drivers/soc/ which implement the SoC bus API and
both use a compatible string on a container level (e.g.
arm,realview-pb11mp-soc in arch/arm/boot/dts/arm-realview-pb11mp.dts).

> 
> I also think drivers/soc is a mess because it is randomly used or not.
> IMO, using it should not be at the whim of whomever does SOC support.

Are you talking about random drivers under drivers/soc/ or the ones
which implement the SoC bus API? I think that is not the same...

If SoC bus, agreed, it is a mess. Not only its adoption is sparse, the
specification is also interpreted differently across different SoC's,
which I brought up in the past:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333765.html

But it exports really useful information to user space, and that has
real value in practice.

--
Stefan
Rob Herring May 11, 2016, 3:24 a.m. UTC | #7
On Mon, May 9, 2016 at 8:13 PM, Stefan Agner <stefan@agner.ch> wrote:
> On 2016-05-09 15:58, Rob Herring wrote:
>> On Mon, May 9, 2016 at 1:25 PM, Stefan Agner <stefan@agner.ch> wrote:
>>> On 2016-05-09 10:14, Rob Herring wrote:
>>>> On Thu, May 5, 2016 at 3:27 AM,  <maitysanchayan@gmail.com> wrote:
>>>>> Hello Rob,
>>>>>
>>>>> On 16-05-03 21:30:26, Rob Herring wrote:
>>>>>> On Mon, May 02, 2016 at 12:35:04PM +0530, Sanchayan Maity wrote:
>>>>>> > Add device tree binding documentation for Vybrid SoC.

[...]

>>>>> Basically being a standalone platform driver, there was need of a compatible
>>>>> property to bind on. Introducing a separate device tree node for it's sake
>>>>> didn't seem appropriate so the alteration to SoC node's compatible.
>>>>
>>>> Ah, so you are designing a node around the needs of a Linux specific
>>>> driver. Don't do that. DT describes the h/w and this node is not a h/w
>>>> block.
>>>>
>>>> Create a platform device based on a matching SOC compatible string
>>>> instead and make your driver find the information it needs directly
>>>> from the relevant nodes like the ROM node.
>>>
>>> That reads like my words a year ago:
>>> https://lkml.org/lkml/2015/5/22/408
>>>
>>> Initially pretty much everything was hard-coded in the driver.
>>>
>>> Arnd then pushed to use more descriptive in the device tree.
>>>
>>> Of course, we should not end up making up relations which are not there
>>> in hardware. We need to find the right balance.
>>>
>>> Here is my suggestion:
>>> 1. Add "fsl,vf610-soc-bus" as compatible string to the soc node, use it
>>> to bind the "soc bus driver" as a platform driver located in driver/soc/
>>
>> I'm not convinced this is a h/w block. This keeps coming up and I
>> think this is a kernel problem, not a DT problem. Let's face it that
>> there are drivers at the SOC level which don't fit into a DT node.
>> They may be the exception, but they are a common exception. My
>> proposal for how to deal with these cases is here[1].
>
> Probably "fsl,vf610-soc" would be better than "fsl,vf610-soc-bus".

But the node in question is just the bus part of the SoC. Things like
cpus are not included.

> But the SoC is definitely a h/w block! Despite all the individual
> silicon in there, I can even touch the SoC ;-)

Can't argue with that...

> But yeah, I understand what you are saying... We model it as a
> container, and do not attribute any specific thing directly to it. But
> aren't there other containers where we bind to? Is it wrong to bind a
> driver to a container, if that driver implements issues concerning that
> level..?

It is supposed to be a bus, not just a container. However, we probably
don't generally fully and accurately model the buses in SoCs so DT
ends up being just a container frequently. If the bus is more than
simple-bus, then it should have some resource that needs to be
controlled to enable the bus.

>
> The two drivers under drivers/soc/ which implement the SoC bus API and
> both use a compatible string on a container level (e.g.
> arm,realview-pb11mp-soc in arch/arm/boot/dts/arm-realview-pb11mp.dts).

I'm not sure Realview and Integrator are models to follow. They are a
bit unique in their h/w design.

>
>>
>> I also think drivers/soc is a mess because it is randomly used or not.
>> IMO, using it should not be at the whim of whomever does SOC support.
>
> Are you talking about random drivers under drivers/soc/ or the ones
> which implement the SoC bus API? I think that is not the same...

The SoC bus API.

> If SoC bus, agreed, it is a mess. Not only its adoption is sparse, the
> specification is also interpreted differently across different SoC's,
> which I brought up in the past:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333765.html
>
> But it exports really useful information to user space, and that has
> real value in practice.

Yes, but the information exported has nothing really to do with a bus.
The "bus" part of it is more sub-classing platform_bus_type for all
platform devices on an SOC. That container may or may not directly
correspond to the bus structure of the SOC as defined in DT. I guess
it is the mixing of really 2 independent things that I don't like and
has made its use sparse. We should perhaps mandate using the bus (for
what I described) and make the information part separate and be able
to populate it from any driver (e.g. an SoC syscon driver which reads
the SOC revision).

Rob
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
new file mode 100644
index 0000000..bdd95e8
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
@@ -0,0 +1,35 @@ 
+Vybrid System-on-Chip
+---------------------
+
+Required properties:
+
+- #address-cells: must be 1
+- #size-cells: must be 1
+- compatible: "fsl,vf610-soc-bus", "simple-bus"
+- interrupt-parent: phandle to the MSCM interrupt router node
+- ranges
+- fsl,rom-revision: phandle to the on-chip ROM node and address of rom
+  revision register
+- fsl,cpu-count: phandle to the MSCM CPU configuration node and address of
+  CPU count register
+- fsl,l2-size: phandle to the MSCM CPU configuration node and address of
+  L2 cache size register
+- nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
+- nvmem-cell-names: should contain string names "cfg0" and "cfg1"
+
+Example:
+
+	soc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "fsl,vf610-soc-bus", "simple-bus";
+		interrupt-parent = <&mscm_ir>;
+		ranges;
+		fsl,rom-revision = <&ocrom 0x80>;
+		fsl,cpu-count = <&mscm_cpucfg 0x2C>;
+		fsl,l2-size = <&mscm_cpucfg 0x14>;
+		nvmem-cells = <&ocotp_cfg0>, <&ocotp_cfg1>;
+		nvmem-cell-names = "cfg0", "cfg1";
+
+		...
+	};