Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1392028 > unrolled thread

[PATCH v2 0/5] Implement SoC bus driver for Vybrid

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 0/5] Implement SoC bus driver for Vybrid Sanchayan Maity <maitysanchayan@gmail.com> - 2016-05-02 09:20 +0200
    [PATCH v2 1/5] mfd: syscon: Introduce syscon_regmap_read_from_offset Sanchayan Maity <maitysanchayan@gmail.com> - 2016-05-02 09:20 +0200
    [PATCH v2 2/5] ARM: dts: vfxxx: Add device tree node for OCOTP Sanchayan Maity <maitysanchayan@gmail.com> - 2016-05-02 09:20 +0200
      Re: [PATCH v2 2/5] ARM: dts: vfxxx: Add device tree node for OCOTP Arnd Bergmann <arnd@arndb.de> - 2016-05-02 09:40 +0200
        Re: [PATCH v2 2/5] ARM: dts: vfxxx: Add device tree node for OCOTP maitysanchayan@gmail.com - 2016-05-02 10:20 +0200

#1392028 — [PATCH v2 0/5] Implement SoC bus driver for Vybrid

Hello,

This second patch series is rebased on top of shawn's for-next branch
and tested on Colibri Vybrid VF50 and VF61 modules.

This patchset implements SoC bus support for Freescale Vybrid platform,
implementing the following
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-devices-soc

This a reworked version of an older patchset series posted in June 2015
which was at v5 then [1]. Since the NVMEM framework was then getting
introduced, we decided that first a NVMEM driver for OCOTP peripheral
being in place would be better.

Compared to the older revisions, this driver now relies on NVMEM
consumer API using the NVMEM based vf610_ocotp driver which has
already been in mainline for a while now. Also now a new syscon
abstraction "syscon_regmap_read_from_offset" is implemented and
exported from syscon allowing accessing a register from a syscon
reference like this

ocotp-cfg1 = <&ocotp 0x20>;

avoiding code repetition in the driver.

One point on which we were not sure here is whether we really should
introduce a new Kconfig symbol as being introduced here. While we
could just enable it when SOC_VF610 is selected, this however would
introduce circular dependencies.

Feedback is most welcome.

Changes since v1:
Add device tree binding documentation.

v1 new patchset
https://lkml.org/lkml/2016/3/11/132

[1] Older v5:
http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
Even earlier versions:
Version 4 of the patchset can be found here
https://lkml.org/lkml/2015/5/26/199
Version 3 of the patchset can be found here
http://www.spinics.net/lists/arm-kernel/msg420847.html
Version 2 of the patchset can be found here
http://www.spinics.net/lists/devicetree/msg80654.html
Version 1 of the patchset can be found here
http://www.spinics.net/lists/devicetree/msg80257.html
The RFC version can be found here
https://lkml.org/lkml/2015/5/11/13

Regards,
Sanchayan.

Sanchayan Maity (5):
  mfd: syscon: Introduce syscon_regmap_read_from_offset
  ARM: dts: vfxxx: Add device tree node for OCOTP
  ARM: dts: vfxxx: Add OCROM and phandle entries for Vybrid SoC bus driver
  soc: Add SoC bus driver for Freescale Vybrid Platform
  vf610-soc: Add Vybrid SoC device tree binding documentation

 .../bindings/arm/freescale/fsl,vf610-soc.txt       |  35 +++++
 arch/arm/boot/dts/vfxxx.dtsi                       |  28 +++-
 drivers/mfd/syscon.c                               |  30 ++++
 drivers/soc/Kconfig                                |   1 +
 drivers/soc/fsl/Kconfig                            |  10 ++
 drivers/soc/fsl/Makefile                           |   1 +
 drivers/soc/fsl/soc-vf610.c                        | 160 +++++++++++++++++++++
 include/linux/mfd/syscon.h                         |  10 ++
 8 files changed, 274 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
 create mode 100644 drivers/soc/fsl/Kconfig
 create mode 100644 drivers/soc/fsl/soc-vf610.c

-- 
2.8.2

[toc] | [next] | [standalone]

#1392029 — [PATCH v2 1/5] mfd: syscon: Introduce syscon_regmap_read_from_offset

Currently syscon does not provide an abstraction to access a
register from syscon reference like below

ocotp-cfg1 = <&ocotp 0x20>

syscon_regmap_read_from_offset provides a generic abstraction to
access a register from syscon reference as above. It allows to
specify the node and node name of phandle reference, reading the
offset from the node entry and providing the value from the offset
in the register map.

Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
 drivers/mfd/syscon.c       | 30 ++++++++++++++++++++++++++++++
 include/linux/mfd/syscon.h | 10 ++++++++++
 2 files changed, 40 insertions(+)

diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index 2f2225e..74724c3 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -136,6 +136,36 @@ struct regmap *syscon_node_to_regmap(struct device_node *np)
 }
 EXPORT_SYMBOL_GPL(syscon_node_to_regmap);
 
+int syscon_regmap_read_from_offset(struct device_node *np,
+				const char *s, unsigned int *val)
+{
+	struct of_phandle_args pargs;
+	struct regmap *regmap;
+	int offset;
+	int ret;
+
+	if (!np)
+		return -ENODEV;
+
+	ret = of_parse_phandle_with_fixed_args(np, s, 1, 0, &pargs);
+	if (ret)
+		return ret;
+
+	regmap = syscon_node_to_regmap(pargs.np);
+	if (IS_ERR(regmap)) {
+		of_node_put(pargs.np);
+		return PTR_ERR(regmap);
+	}
+
+	offset = pargs.args[0];
+	of_node_put(pargs.np);
+
+	ret = regmap_read(regmap, offset, val);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(syscon_regmap_read_from_offset);
+
 struct regmap *syscon_regmap_lookup_by_compatible(const char *s)
 {
 	struct device_node *syscon_np;
diff --git a/include/linux/mfd/syscon.h b/include/linux/mfd/syscon.h
index 1088149..42b0759 100644
--- a/include/linux/mfd/syscon.h
+++ b/include/linux/mfd/syscon.h
@@ -26,6 +26,9 @@ extern struct regmap *syscon_regmap_lookup_by_pdevname(const char *s);
 extern struct regmap *syscon_regmap_lookup_by_phandle(
 					struct device_node *np,
 					const char *property);
+extern int syscon_regmap_read_from_offset(struct device_node *np,
+					  const char *s,
+					  unsigned int *val);
 #else
 static inline struct regmap *syscon_node_to_regmap(struct device_node *np)
 {
@@ -48,6 +51,13 @@ static inline struct regmap *syscon_regmap_lookup_by_phandle(
 {
 	return ERR_PTR(-ENOTSUPP);
 }
+
+static inline int syscon_regmap_read_from_offset(struct device_node *np,
+						 const char *s,
+						 unsigned int *val)
+{
+	return ERR_PTR(-ENOSYS);
+}
 #endif
 
 #endif /* __LINUX_MFD_SYSCON_H__ */
-- 
2.8.2

[toc] | [prev] | [next] | [standalone]

#1392030 — [PATCH v2 2/5] ARM: dts: vfxxx: Add device tree node for OCOTP

Add device tree node for the OCOTP peripheral on Vybrid.

Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
 arch/arm/boot/dts/vfxxx.dtsi | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 2c13ec6..0e34d44 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -520,6 +520,22 @@
 				status = "disabled";
 			};
 
+			ocotp@400a5000 {
+				compatible = "fsl,vf610-ocotp";
+				#address-cells = <1>;
+				#size-cells = <1>;
+				reg = <0x400a5000 0xCF0>;
+				clocks = <&clks VF610_CLK_OCOTP>;
+
+				ocotp_cfg0: cfg0@410 {
+					reg = <0x410 0x4>;
+				};
+
+				ocotp_cfg1: cfg1@420 {
+					reg = <0x420 0x4>;
+				};
+			};
+
 			snvs0: snvs@400a7000 {
 			    compatible = "fsl,sec-v4.0-mon", "syscon", "simple-mfd";
 				reg = <0x400a7000 0x2000>;
-- 
2.8.2

[toc] | [prev] | [next] | [standalone]

#1392034 — Re: [PATCH v2 2/5] ARM: dts: vfxxx: Add device tree node for OCOTP

[Multipart message — attachments visible in raw view] — view raw

On Monday 02 May 2016 12:35:01 Sanchayan Maity wrote:
> +                       ocotp@400a5000 {
> +                               compatible = "fsl,vf610-ocotp";
> +                               #address-cells = <1>;
> +                               #size-cells = <1>;
> +                               reg = <0x400a5000 0xCF0>;
> +                               clocks = <&clks VF610_CLK_OCOTP>;
> +
> +                               ocotp_cfg0: cfg0@410 {
> +                                       reg = <0x410 0x4>;
> +                               };
> +
> +                               ocotp_cfg1: cfg1@420 {
> +                                       reg = <0x420 0x4>;
> +                               };
> +                       };

How do the registers of the child nodes relate to the registers of the
parent? If there are in the same address space, it might be good to
add a "ranges" property to describe it.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1392054 — Re: [PATCH v2 2/5] ARM: dts: vfxxx: Add device tree node for OCOTP

Hello Arnd,

On 16-05-02 09:31:12, Arnd Bergmann wrote:
> On Monday 02 May 2016 12:35:01 Sanchayan Maity wrote:
> > +                       ocotp@400a5000 {
> > +                               compatible = "fsl,vf610-ocotp";
> > +                               #address-cells = <1>;
> > +                               #size-cells = <1>;
> > +                               reg = <0x400a5000 0xCF0>;
> > +                               clocks = <&clks VF610_CLK_OCOTP>;
> > +
> > +                               ocotp_cfg0: cfg0@410 {
> > +                                       reg = <0x410 0x4>;
> > +                               };
> > +
> > +                               ocotp_cfg1: cfg1@420 {
> > +                                       reg = <0x420 0x4>;
> > +                               };
> > +                       };
> 
> How do the registers of the child nodes relate to the registers of the
> parent? If there are in the same address space, it might be good to
> add a "ranges" property to describe it.

cfg0 and cfg1 are in the same address space viz. 0x400a5410 and 0x400a5420
respectively. These nodes are primarily for use by the NVMEM consumer API in
the SoC bus driver to retrieve the values from these registers leveraging
the NVMEM vf610 ocotp driver.

Based on the NVMEM bindings here
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/nvmem/nvmem.txt#L33

Thanks.

Regards,
Sanchayan.

> 
> 	Arnd

> Date: Mon, 02 May 2016 12:02:21 +1000
> From: Gavin Shan <gwshan@linux.vnet.ibm.com>
> To: Rob Herring <robherring2@gmail.com>
> Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
>  aik@ozlabs.ru, Gavin Shan <gwshan@linux.vnet.ibm.com>, Grant Likely
>  <grant.likely@linaro.org>, "linux-pci@vger.kernel.org"
>  <linux-pci@vger.kernel.org>, Bjorn Helgaas <bhelgaas@google.com>,
>  linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, dja@axtens.net
> Subject: Re: [PATCH v8 40/45] drivers/of: Split unflatten_dt_node()
> 
> On Wed, Feb 17, 2016 at 08:30:42AM -0600, Rob Herring wrote:
> >On Tue, Feb 16, 2016 at 9:44 PM, Gavin Shan <gwshan@linux.vnet.ibm.com> wrote:
> >> The function unflatten_dt_node() is called recursively to unflatten
> >> device nodes and properties in the FDT blob. It looks complicated
> >> and hard to be understood.
> >>
> >> This splits the function into 3 functions: populate_properties(),
> >> populate_node() and unflatten_dt_node(). populate_properties(),
> >> which is called by populate_node(), creates properties for the
> >> indicated device node. The later one creates the device nodes
> >> from FDT blob. populate_node() gets the offset in FDT blob for
> >> next device nodes and then calls populate_node(). No logical
> >> changes introduced.
> >>
> >> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
> >> ---
> >>  drivers/of/fdt.c | 249 ++++++++++++++++++++++++++++++++-----------------------
> >>  1 file changed, 147 insertions(+), 102 deletions(-)
> >
> >One nit, otherwise:
> >
> >Acked-by: Rob Herring <robh@kernel.org>
> >
> >[...]
> >
> >> +               /* And we process the "ibm,phandle" property
> >> +                * used in pSeries dynamic device tree
> >> +                * stuff
> >> +                */
> >> +               if (!strcmp(pname, "ibm,phandle"))
> >> +                       np->phandle = be32_to_cpup(val);
> >> +
> >> +               pp->name   = (char *)pname;
> >> +               pp->length = sz;
> >> +               pp->value  = (__be32 *)val;
> >
> >This cast should not be needed.
> >
> 
> It's needed. Otherwise, we will have warning. So I will keep it. I just
> went through this one for next revision and sorry for late response.
> 
> drivers/of/fdt.c:225:14: warning: assignment discards ‘const’ qualifier from pointer target type
>    pp->value  = val;
>               ^
> 
> Thanks,
> Gavin
> 
> >> +               *pprev     = pp;
> >> +               pprev      = &pp->next;
> >> +       }
> >
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web