| Message ID | 65f3a7bd7a9faf1b390644d7c599c69683c753c4.1462171990.git.maitysanchayan@gmail.com |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
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 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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"; + + ... + };
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