Skip to contentSkip to conversation

Implement SoC bus support for Vybrid

PATCH Superseded Sanchayan Maity 3 participants 8 messages May 22, 2015 – May 25, 2015

Subsystems (2)

v3 of 10 Superseded Latest is v10 →

lore
Share & tools
lore
#0 lore raw

v3 cover Implement SoC bus support for Vybrid

Hello,

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

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

Changes since v2:
- Implement the SoC bus code as a driver in drivers/soc by registering with fsl,mscm-cpucfg as per Arnd's feedback

Changes since v1:
- Sort the headers in alphabetical order

Changes since RFC:
- Use a DT entry for the ROM area while specifying it as syscon.

One question I had in comparison to the previous implementation is, the previous patch also resulted in exposing the DT devices in the subdirectory soc under soc0/ which happened due to the of_platform_populate call. With the current implementation this does not happen anymore. I am not too thorough on all this, but I guess that of_platform_populate needs to be called early with the right arguments. With the current implementation is it possible to get that soc0/soc directory exposed in any way? Am I missing something trivial in all this?

I guess we are OK, even if the above cannot be achived with the current implementation. The main aim of this exercise was to expose the SoC specific attributes. However it did be nice, if it could still be done. Perhaps that part of the implementation can go in later in a separate patch.

Arnd are you ok with this implementation?

Notes same since v1 and v2:
Currently the required information is more or less read across the whole SoC, but I guess we cannot change that since these are the locations with the required information.

There seem to be three options for the revision field:
- ROM revision (see https://community.freescale.com/docs/DOC-94802)
- ANADIG revision (ANADIG_DIGIPROC, as used for the i.MX SoC's)
- OCOTP revision

Some numbers:

Colibri VF61 1.1A (2N02G)
- 0x00000013
- 0x00610000
- 0x01000000
- 0x410000c8

Colibri VF61 V1.0B (1N02G)
- 0x00000011
- 0x00610000
- 0x01000000
- 0x410000c8

Colibri VF61 V1.0A (which is actually a VF600 SoC, no L2 cache, since that was the only one we could buy back then, 1N02G printed on it)
- 0x00000011
- 0x00610000
- 0x01000000
- none...

Colibri VF50 V1.0A (1N02G)
- 0x00000011
- 0x00610000
- 0x01000000
- none...

Vybrid Tower Rev J (1N02G)
- 0x00000011
- 0x00610000
- 0x01000000
- 0x410000c8

The ROM revision differs the most, so we would like to go with the revision information from the ROM register 0x80.

Sanchayan Maity (2):
ARM: dts: vfxxx: Add OCOTP and OCROM nodes
soc: Add driver for Freescale Vybrid Platform

 arch/arm/boot/dts/vfxxx.dtsi |  10 ++++
 drivers/soc/Kconfig          |   1 +
 drivers/soc/Makefile         |   1 +
 drivers/soc/fsl/Kconfig      |   9 ++++
 drivers/soc/fsl/Makefile     |   1 +
 drivers/soc/fsl/soc-vf610.c  | 113 +++++++++++++++++++++++++++++++++++++++++++
 6 files changed, 135 insertions(+)
 create mode 100644 drivers/soc/fsl/Kconfig
 create mode 100644 drivers/soc/fsl/Makefile
 create mode 100644 drivers/soc/fsl/soc-vf610.c
Signature · 1 line
2.4.1
#1 lore raw

PATCH v3 1/2 ARM: dts: vfxxx: Add OCOTP and OCROM nodes

Add a device tree node for the On-Chip One Time Programmable Controller (OCOTP) and the On-Chip ROM.

---
 arch/arm/boot/dts/vfxxx.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)
arch/arm/boot/dts/vfxxx.dtsi +10 -0
index 2f4b04d..66c529f 100644
@@ -57,6 +57,11 @@
 		interrupt-parent = <&mscm_ir>;
 		ranges;
 
+		ocrom: ocrom {
+			compatible = "fsl,vf610-ocrom", "syscon";
+			reg = <0x00000000 0x18000>;
+		};
+
 		aips0: aips-bus at 40000000 {
 			compatible = "fsl,aips-bus", "simple-bus";
 			#address-cells = <1>;
@@ -403,6 +408,11 @@
 				status = "disabled";
 			};
 
+			ocotp: ocotp at 400a5000 {
+				compatible = "fsl,vf610-ocotp", "syscon";
+				reg = <0x400a5000 0x1000>;
+			};
+
 			snvs0: snvs at 400a7000 {
 			    compatible = "fsl,sec-v4.0-mon", "simple-bus";
 				#address-cells = <1>;
Signature · 1 line
2.4.1
#2 lore raw

PATCH v3 2/2 soc: Add driver for Freescale Vybrid Platform

In reply to Sanchayan Maity

This adds a SoC driver to be used by the Freescale Vybrid SoC's. We create the "fsl" directory for holding the different Freescale designs. Driver utilises syscon to get the various register values needed. After this sysfs exposes some SoC specific properties as below:

Quoted 2 lines

cd /sys/devices/soc0
ls

family machine power revision soc_id subsystem uevent

Quoted 1 line

cat family

Freescale Vybrid VF610

Quoted 1 line

cat machine

Freescale Vybrid

Quoted 1 line

cat revision

00000013

Quoted 1 line

cat soc_id

df6472a60c1c39d4

---
 drivers/soc/Kconfig         |   1 +
 drivers/soc/Makefile        |   1 +
 drivers/soc/fsl/Kconfig     |   9 ++++
 drivers/soc/fsl/Makefile    |   1 +
 drivers/soc/fsl/soc-vf610.c | 113 ++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 125 insertions(+)
 create mode 100644 drivers/soc/fsl/Kconfig
 create mode 100644 drivers/soc/fsl/Makefile
 create mode 100644 drivers/soc/fsl/soc-vf610.c
drivers/soc/Kconfig +1 -0
index d8bde82..8b4dd2b 100644
@@ -1,5 +1,6 @@
 menu "SOC (System On Chip) specific Drivers"
 
+source "drivers/soc/fsl/Kconfig"
 source "drivers/soc/mediatek/Kconfig"
 source "drivers/soc/qcom/Kconfig"
 source "drivers/soc/ti/Kconfig"
drivers/soc/Makefile +1 -0
index 70042b2..142676e 100644
@@ -2,6 +2,7 @@
 # Makefile for the Linux Kernel SOC specific device drivers.
 #
 
+obj-$(CONFIG_SOC_VF610)         += fsl/
 obj-$(CONFIG_ARCH_MEDIATEK)	+= mediatek/
 obj-$(CONFIG_ARCH_QCOM)		+= qcom/
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
drivers/soc/fsl/Kconfig new file +9 -0
new file mode 100644
index 0000000..d0ac671
@@ -0,0 +1,9 @@
+#
+# Freescale SoC drivers
+
+config SOC_VF610
+	   bool "SoC bus device for the Freescale Vybrid platform"
+	   select SOC_BUS
+	   help
+	     Include support for the SoC bus on the Freescale Vybrid platform
+		 providing some sysfs information about the module variant.
\ No newline at end of file
drivers/soc/fsl/Makefile new file +1 -0
new file mode 100644
index 0000000..5fccbba
@@ -0,0 +1 @@
+obj-$(CONFIG_SOC_VF610)		+= soc-vf610.o
drivers/soc/fsl/soc-vf610.c new file +113 -0

113 lines not on this page · raw message

Signature · 1 line
2.4.1
#3 lore raw

Re: [PATCH v3 2/2] soc: Add driver for Freescale Vybrid Platform

Quoted 17 lines · On Friday 22 May 2015 16:21:54 Sanchayan Maity wrote:
drivers/soc/fsl/soc-vf610.c new file +17 -0
+#define OCOTP_CFG0_OFFSET      0x00000410
+#define OCOTP_CFG1_OFFSET      0x00000420
+#define MSCM_CPxCOUNT_OFFSET   0x0000002C
+#define MSCM_CPxCFG1_OFFSET    0x00000014
+#define ROM_REVISION_OFFSET    0x00000080
+
+static const struct of_device_id vf610_soc_bus_match[] = {
+	{ .compatible = "fsl,vf610-mscm-cpucfg", },
+	{ /* sentinel */ }
+};
+
+static int __init vf610_soc_init(void)
+{
+	struct regmap *ocotp_regmap, *mscm_regmap, *rom_regmap;
+	struct soc_device_attribute *soc_dev_attr;
+	struct soc_device *soc_dev;
+	struct device_node *np;

drivers/soc/fsl/soc-vf610.c line 46

Quoted 10 lines
drivers/soc/fsl/soc-vf610.c new file +10 -0
+	char soc_type[] = "xx0";
+	u32 cpxcount, cpxcfg1;
+	u32 soc_id1, soc_id2, rom_rev;
+	u64 soc_id;
+	int ret;
+
+	np = of_find_matching_node(NULL, vf610_soc_bus_match);
+	if (!np)
+		return -ENODEV;
+

Why not use module_platform_driver() and make this a probe function instead?

Quoted 7 lines
drivers/soc/fsl/soc-vf610.c new file +7 -0
+	ocotp_regmap = syscon_regmap_lookup_by_compatible("fsl,vf610-ocotp");
+	if (IS_ERR(ocotp_regmap)) {
+		pr_err("regmap lookup for octop failed\n");
+		return PTR_ERR(ocotp_regmap);
+	}
+
+	mscm_regmap = syscon_regmap_lookup_by_compatible("fsl,vf610-mscm-cpucfg");

drivers/soc/fsl/soc-vf610.c line 63

Quoted 10 lines
drivers/soc/fsl/soc-vf610.c new file +10 -0
+	if (IS_ERR(mscm_regmap)) {
+		pr_err("regmap lookup for mscm failed");
+		return PTR_ERR(mscm_regmap);
+	}
+
+	rom_regmap = syscon_regmap_lookup_by_compatible("fsl,vf610-ocrom");
+	if (IS_ERR(rom_regmap)) {
+		pr_err("regmap lookup for ocrom failed");
+		return PTR_ERR(rom_regmap);
+	}

Can you use syscon_regmap_lookup_by_phandle instead, and put the phandles in the fsl,vf610-mscm-cpucfg node?

Also, I'd argue that the mscm should not be a syscon device at all, but instead I'd use platform_get_resource()/devm_ioremap_resource() to get an __iomem pointer.

Arnd

#4 lore raw

Re: [PATCH v3 2/2] soc: Add driver for Freescale Vybrid Platform

Hello Arnd,

Quoted 22 lines · Arnd Bergmann
Quoted 21 lines · On Friday 22 May 2015 16:21:54 Sanchayan Maity wrote:
drivers/soc/fsl/soc-vf610.c new file +21 -0
+#define OCOTP_CFG0_OFFSET      0x00000410
+#define OCOTP_CFG1_OFFSET      0x00000420
+#define MSCM_CPxCOUNT_OFFSET   0x0000002C
+#define MSCM_CPxCFG1_OFFSET    0x00000014
+#define ROM_REVISION_OFFSET    0x00000080
+
+static const struct of_device_id vf610_soc_bus_match[] = {
+	{ .compatible = "fsl,vf610-mscm-cpucfg", },
+	{ /* sentinel */ }
+};
+
+static int __init vf610_soc_init(void)
+{
+	struct regmap *ocotp_regmap, *mscm_regmap, *rom_regmap;
+	struct soc_device_attribute *soc_dev_attr;
+	struct soc_device *soc_dev;
+	struct device_node *np;
+	char soc_type[] = "xx0";
+	u32 cpxcount, cpxcfg1;
+	u32 soc_id1, soc_id2, rom_rev;
+	u64 soc_id;
Quoted 8 lines

drivers/soc/fsl/soc-vf610.c line 46

Quoted 6 lines
drivers/soc/fsl/soc-vf610.c new file +6 -0
+	int ret;
+
+	np = of_find_matching_node(NULL, vf610_soc_bus_match);
+	if (!np)
+		return -ENODEV;
+

Why not use module_platform_driver() and make this a probe function instead?

Had done that but after having a look at the existing integrator and versatile platform implementation, I changed it. Will switch to using that.

Quoted 13 lines
Quoted 13 lines
drivers/soc/fsl/soc-vf610.c new file +12 -0
+	ocotp_regmap = syscon_regmap_lookup_by_compatible("fsl,vf610-ocotp");
+	if (IS_ERR(ocotp_regmap)) {
+		pr_err("regmap lookup for octop failed\n");
+		return PTR_ERR(ocotp_regmap);
+	}
+
+	mscm_regmap = syscon_regmap_lookup_by_compatible("fsl,vf610-mscm-cpucfg");
+	if (IS_ERR(mscm_regmap)) {
+		pr_err("regmap lookup for mscm failed");
+		return PTR_ERR(mscm_regmap);
+	}
+
Quoted 8 lines

drivers/soc/fsl/soc-vf610.c line 63

Quoted 5 lines
drivers/soc/fsl/soc-vf610.c new file +5 -0
+	rom_regmap = syscon_regmap_lookup_by_compatible("fsl,vf610-ocrom");
+	if (IS_ERR(rom_regmap)) {
+		pr_err("regmap lookup for ocrom failed");
+		return PTR_ERR(rom_regmap);
+	}

Can you use syscon_regmap_lookup_by_phandle instead, and put the phandles in the fsl,vf610-mscm-cpucfg node?

Ok. Will do so.

- Sanchayan.

Quoted 6 lines

Also, I'd argue that the mscm should not be a syscon device at all, but instead I'd use platform_get_resource()/devm_ioremap_resource() to get an __iomem pointer.

Arnd

#5 lore raw

Re: [PATCH v3 2/2] soc: Add driver for Freescale Vybrid Platform

In reply to Arnd Bergmann
Quoted 43 lines · Arnd Bergmann
Quoted 17 lines · On Friday 22 May 2015 16:21:54 Sanchayan Maity wrote:
drivers/soc/fsl/soc-vf610.c new file +17 -0
+#define OCOTP_CFG0_OFFSET      0x00000410
+#define OCOTP_CFG1_OFFSET      0x00000420
+#define MSCM_CPxCOUNT_OFFSET   0x0000002C
+#define MSCM_CPxCFG1_OFFSET    0x00000014
+#define ROM_REVISION_OFFSET    0x00000080
+
+static const struct of_device_id vf610_soc_bus_match[] = {
+	{ .compatible = "fsl,vf610-mscm-cpucfg", },
+	{ /* sentinel */ }
+};
+
+static int __init vf610_soc_init(void)
+{
+	struct regmap *ocotp_regmap, *mscm_regmap, *rom_regmap;
+	struct soc_device_attribute *soc_dev_attr;
+	struct soc_device *soc_dev;
+	struct device_node *np;

drivers/soc/fsl/soc-vf610.c line 46

Quoted 10 lines
drivers/soc/fsl/soc-vf610.c new file +10 -0
+	char soc_type[] = "xx0";
+	u32 cpxcount, cpxcfg1;
+	u32 soc_id1, soc_id2, rom_rev;
+	u64 soc_id;
+	int ret;
+
+	np = of_find_matching_node(NULL, vf610_soc_bus_match);
+	if (!np)
+		return -ENODEV;
+

Why not use module_platform_driver() and make this a probe function instead?

Quoted 12 lines
drivers/soc/fsl/soc-vf610.c new file +12 -0
+	ocotp_regmap = syscon_regmap_lookup_by_compatible("fsl,vf610-ocotp");
+	if (IS_ERR(ocotp_regmap)) {
+		pr_err("regmap lookup for octop failed\n");
+		return PTR_ERR(ocotp_regmap);
+	}
+
+	mscm_regmap = syscon_regmap_lookup_by_compatible("fsl,vf610-mscm-cpucfg");
+	if (IS_ERR(mscm_regmap)) {
+		pr_err("regmap lookup for mscm failed");
+		return PTR_ERR(mscm_regmap);
+	}
+
Quoted 8 lines

drivers/soc/fsl/soc-vf610.c line 63

Quoted 5 lines
drivers/soc/fsl/soc-vf610.c new file +5 -0
+	rom_regmap = syscon_regmap_lookup_by_compatible("fsl,vf610-ocrom");
+	if (IS_ERR(rom_regmap)) {
+		pr_err("regmap lookup for ocrom failed");
+		return PTR_ERR(rom_regmap);
+	}

Can you use syscon_regmap_lookup_by_phandle instead, and put the phandles in the fsl,vf610-mscm-cpucfg node?

Hm, with that we would wire up hardware modules which does nothing has to do with each other. We just happen to need a driver which collects information accross the SoC. I'm not sure we should put the modules required into the device tree.

I don't think its nice to have the compatible strings in the source code, however it feels more appropriate than in the device tree, IMHO...

Quoted 3 lines

Also, I'd argue that the mscm should not be a syscon device at all, but instead I'd use platform_get_resource()/devm_ioremap_resource() to get an __iomem pointer.

We need to have mscm-cpucfg to be syscon because we need to get the CPU personality in the MSCM interrupt router driver (irq-vf610-mscm-ir.c).

--
Stefan

#6 lore raw

Re: [PATCH v3 2/2] soc: Add driver for Freescale Vybrid Platform

Quoted 10 lines · On Friday 22 May 2015 14:02:52 Stefan Agner wrote:
Quoted 2 lines

Can you use syscon_regmap_lookup_by_phandle instead, and put the phandles in the fsl,vf610-mscm-cpucfg node?

Hm, with that we would wire up hardware modules which does nothing has to do with each other. We just happen to need a driver which collects information accross the SoC. I'm not sure we should put the modules required into the device tree.

I don't think its nice to have the compatible strings in the source code, however it feels more appropriate than in the device tree, IMHO...

I see. Another option would be to point directly to the registers you need:

	ocotp-cfg0 = <&ocotp 0x10>;
	ocotp-cfg1 = <&ocotp 0x20>;
	rom-revision = <&rom 0x80>;

We don't yet have an abstraction to access a register from a syscon reference like this, but you could either roll your own here, or add a generic abstraction.

Quoted 6 lines
Quoted 3 lines

Also, I'd argue that the mscm should not be a syscon device at all, but instead I'd use platform_get_resource()/devm_ioremap_resource() to get an __iomem pointer.

We need to have mscm-cpucfg to be syscon because we need to get the CPU personality in the MSCM interrupt router driver (irq-vf610-mscm-ir.c).

It can be both at the same time now.

Arnd

#7 lore raw

Re: [PATCH v3 2/2] soc: Add driver for Freescale Vybrid Platform

Hello Arnd,

Quoted 15 lines · Arnd Bergmann
Quoted 10 lines · On Friday 22 May 2015 14:02:52 Stefan Agner wrote:
Quoted 2 lines

Can you use syscon_regmap_lookup_by_phandle instead, and put the phandles in the fsl,vf610-mscm-cpucfg node?

Hm, with that we would wire up hardware modules which does nothing has to do with each other. We just happen to need a driver which collects information accross the SoC. I'm not sure we should put the modules required into the device tree.

I don't think its nice to have the compatible strings in the source code, however it feels more appropriate than in the device tree, IMHO...

I see. Another option would be to point directly to the registers you need:

Quoted 7 lines
	ocotp-cfg0 = <&ocotp 0x10>;
	ocotp-cfg1 = <&ocotp 0x20>;
	rom-revision = <&rom 0x80>;

We don't yet have an abstraction to access a register from a syscon reference like this, but you could either roll your own here, or add a generic abstraction.

Can you tell me a little about how can I start implementing it? I am not clear on how to approach this.

Quoted 11 lines
Quoted 7 lines
Quoted 4 lines

Also, I'd argue that the mscm should not be a syscon device at all, but instead I'd use platform_get_resource()/devm_ioremap_resource() to get an __iomem pointer.

We need to have mscm-cpucfg to be syscon because we need to get the CPU personality in the MSCM interrupt router driver (irq-vf610-mscm-ir.c).

It can be both at the same time now.

Arnd

Regards,
Sanchayan.