All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/3] soc: amlogic: Add Amlogic SoC Information driver
@ 2017-03-31  8:47 ` Neil Armstrong
  0 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-03-31  8:47 UTC (permalink / raw)
  To: khilman, carlo
  Cc: Neil Armstrong, linux-amlogic, linux-arm-kernel, linux-kernel

Amlogic SoCs have a SoC information register for SoC type, package type and
revision information.
This patchset adds support for this register decoding and exposing with the
SoC bus infrastructure, with dt-bindings and DT node.

Neil Armstrong (3):
  soc: Add Amlogic SoC Information driver
  dt-bindings: arm: amlogic: Add SoC information bindings
  ARM64: dts: meson-gx: Add SoC info register

 Documentation/devicetree/bindings/arm/amlogic.txt |  20 +++
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi         |   5 +
 drivers/soc/Kconfig                               |   1 +
 drivers/soc/Makefile                              |   1 +
 drivers/soc/amlogic/Kconfig                       |  12 ++
 drivers/soc/amlogic/Makefile                      |   1 +
 drivers/soc/amlogic/meson-gx-socinfo.c            | 158 ++++++++++++++++++++++
 7 files changed, 198 insertions(+)
 create mode 100644 drivers/soc/amlogic/Kconfig
 create mode 100644 drivers/soc/amlogic/Makefile
 create mode 100644 drivers/soc/amlogic/meson-gx-socinfo.c

-- 
1.9.1

^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH 0/3] soc: amlogic: Add Amlogic SoC Information driver
@ 2017-03-31  8:47 ` Neil Armstrong
  0 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-03-31  8:47 UTC (permalink / raw)
  To: linux-arm-kernel

Amlogic SoCs have a SoC information register for SoC type, package type and
revision information.
This patchset adds support for this register decoding and exposing with the
SoC bus infrastructure, with dt-bindings and DT node.

Neil Armstrong (3):
  soc: Add Amlogic SoC Information driver
  dt-bindings: arm: amlogic: Add SoC information bindings
  ARM64: dts: meson-gx: Add SoC info register

 Documentation/devicetree/bindings/arm/amlogic.txt |  20 +++
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi         |   5 +
 drivers/soc/Kconfig                               |   1 +
 drivers/soc/Makefile                              |   1 +
 drivers/soc/amlogic/Kconfig                       |  12 ++
 drivers/soc/amlogic/Makefile                      |   1 +
 drivers/soc/amlogic/meson-gx-socinfo.c            | 158 ++++++++++++++++++++++
 7 files changed, 198 insertions(+)
 create mode 100644 drivers/soc/amlogic/Kconfig
 create mode 100644 drivers/soc/amlogic/Makefile
 create mode 100644 drivers/soc/amlogic/meson-gx-socinfo.c

-- 
1.9.1

^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH 0/3] soc: amlogic: Add Amlogic SoC Information driver
@ 2017-03-31  8:47 ` Neil Armstrong
  0 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-03-31  8:47 UTC (permalink / raw)
  To: linus-amlogic

Amlogic SoCs have a SoC information register for SoC type, package type and
revision information.
This patchset adds support for this register decoding and exposing with the
SoC bus infrastructure, with dt-bindings and DT node.

Neil Armstrong (3):
  soc: Add Amlogic SoC Information driver
  dt-bindings: arm: amlogic: Add SoC information bindings
  ARM64: dts: meson-gx: Add SoC info register

 Documentation/devicetree/bindings/arm/amlogic.txt |  20 +++
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi         |   5 +
 drivers/soc/Kconfig                               |   1 +
 drivers/soc/Makefile                              |   1 +
 drivers/soc/amlogic/Kconfig                       |  12 ++
 drivers/soc/amlogic/Makefile                      |   1 +
 drivers/soc/amlogic/meson-gx-socinfo.c            | 158 ++++++++++++++++++++++
 7 files changed, 198 insertions(+)
 create mode 100644 drivers/soc/amlogic/Kconfig
 create mode 100644 drivers/soc/amlogic/Makefile
 create mode 100644 drivers/soc/amlogic/meson-gx-socinfo.c

-- 
1.9.1

^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH 1/3] soc: Add Amlogic SoC Information driver
  2017-03-31  8:47 ` Neil Armstrong
  (?)
@ 2017-03-31  8:47   ` Neil Armstrong
  -1 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-03-31  8:47 UTC (permalink / raw)
  To: khilman, carlo
  Cc: Neil Armstrong, linux-amlogic, linux-arm-kernel, linux-kernel

Amlogic SoCs have a SoC information register for SoC type, package type and
revision information.
This patchs adds support for this register decoding and exposing with the
SoC bus infrastructure.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 drivers/soc/Kconfig                    |   1 +
 drivers/soc/Makefile                   |   1 +
 drivers/soc/amlogic/Kconfig            |  12 +++
 drivers/soc/amlogic/Makefile           |   1 +
 drivers/soc/amlogic/meson-gx-socinfo.c | 158 +++++++++++++++++++++++++++++++++
 5 files changed, 173 insertions(+)
 create mode 100644 drivers/soc/amlogic/Kconfig
 create mode 100644 drivers/soc/amlogic/Makefile
 create mode 100644 drivers/soc/amlogic/meson-gx-socinfo.c

diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index f09023f..0b149a6 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,5 +1,6 @@
 menu "SOC (System On Chip) specific Drivers"
 
+source "drivers/soc/amlogic/Kconfig"
 source "drivers/soc/bcm/Kconfig"
 source "drivers/soc/fsl/Kconfig"
 source "drivers/soc/mediatek/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 05eae52..4c0c776 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_ARCH_DOVE)		+= dove/
 obj-$(CONFIG_MACH_DOVE)		+= dove/
 obj-y				+= fsl/
 obj-$(CONFIG_ARCH_MEDIATEK)	+= mediatek/
+obj-$(CONFIG_ARCH_MESON)	+= amlogic/
 obj-$(CONFIG_ARCH_QCOM)		+= qcom/
 obj-$(CONFIG_ARCH_RENESAS)	+= renesas/
 obj-$(CONFIG_ARCH_ROCKCHIP)	+= rockchip/
diff --git a/drivers/soc/amlogic/Kconfig b/drivers/soc/amlogic/Kconfig
new file mode 100644
index 0000000..22acf06
--- /dev/null
+++ b/drivers/soc/amlogic/Kconfig
@@ -0,0 +1,12 @@
+menu "Amlogic SoC drivers"
+
+config MESON_GX_SOCINFO
+	bool "Amlogic Meson GX SoC Information driver"
+	depends on ARCH_MESON || COMPILE_TEST
+	default ARCH_MESON
+	select SOC_BUS
+	help
+	  Say yes to support decoding of Amlogic Meson GX SoC family
+	  information about the type, package and version.
+
+endmenu
diff --git a/drivers/soc/amlogic/Makefile b/drivers/soc/amlogic/Makefile
new file mode 100644
index 0000000..3e85fc4
--- /dev/null
+++ b/drivers/soc/amlogic/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MESON_GX_SOCINFO) += meson-gx-socinfo.o
diff --git a/drivers/soc/amlogic/meson-gx-socinfo.c b/drivers/soc/amlogic/meson-gx-socinfo.c
new file mode 100644
index 0000000..bfdc644
--- /dev/null
+++ b/drivers/soc/amlogic/meson-gx-socinfo.c
@@ -0,0 +1,158 @@
+/*
+ * Copyright (c) 2017 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/sys_soc.h>
+
+#define SOCINFO_MAJOR_SHIFT	24
+#define SOCINFO_MINOR_SHIFT	16
+#define SOCINFO_PACK_SHIFT	8
+#define SOCINFO_MISC_SHIFT	0
+#define SOCINFO_MASK		0xff
+
+static const struct meson_gx_soc_id {
+	const char *name;
+	unsigned int id;
+} soc_ids[] = {
+	{ "GXBB", 0x1f },
+	{ "GXTVBB", 0x20 },
+	{ "GXL", 0x21 },
+	{ "GXM", 0x22 },
+	{ "TXL", 0x23 },
+};
+
+static const struct meson_gx_package_id {
+	const char *name;
+	unsigned int major_id;
+	unsigned int pack_id;
+} soc_packages[] = {
+	{ "S905", 0x1f, 0 },
+	{ "S905M", 0x1f, 0x20 },
+	{ "S905D", 0x21, 0 },
+	{ "S905X", 0x21, 0x80 },
+	{ "S905L", 0x21, 0xc0 },
+	{ "S905M2", 0x21, 0xe0 },
+	{ "S912", 0x22, 0 },
+};
+
+static inline unsigned int socinfo_to_major(u32 socinfo)
+{
+	return (socinfo >> SOCINFO_MAJOR_SHIFT) & SOCINFO_MASK;
+}
+
+static inline unsigned int socinfo_to_minor(u32 socinfo)
+{
+	return (socinfo >> SOCINFO_MINOR_SHIFT) & SOCINFO_MASK;
+}
+
+static inline unsigned int socinfo_to_pack(u32 socinfo)
+{
+	return (socinfo >> SOCINFO_PACK_SHIFT) & SOCINFO_MASK;
+}
+
+static inline unsigned int socinfo_to_misc(u32 socinfo)
+{
+	return (socinfo >> SOCINFO_MISC_SHIFT) & SOCINFO_MASK;
+}
+
+static const char *socinfo_to_package_id(u32 socinfo)
+{
+	unsigned int pack = socinfo_to_pack(socinfo) & 0xf0;
+	unsigned int major = socinfo_to_major(socinfo);
+	int i;
+
+	for (i = 0 ; i < ARRAY_SIZE(soc_packages) ; ++i) {
+		if (soc_packages[i].major_id == major &&
+		    soc_packages[i].pack_id == pack)
+			return soc_packages[i].name;
+	}
+
+	return "Unknown";
+}
+
+static const char *socinfo_to_soc_id(u32 socinfo)
+{
+	unsigned int id = socinfo_to_major(socinfo);
+	int i;
+
+	for (i = 0 ; i < ARRAY_SIZE(soc_ids) ; ++i) {
+		if (soc_ids[i].id == id)
+			return soc_ids[i].name;
+	}
+
+	return "Unknown";
+}
+
+int __init meson_gx_socinfo_init(void)
+{
+	struct soc_device_attribute *soc_dev_attr;
+	void __iomem *meson_gx_socinfo_base;
+	struct soc_device *soc_dev;
+	struct device_node *root;
+	struct device_node *np;
+	struct device *dev;
+	u32 socinfo;
+
+	/* look up for socinfo node */
+	np = of_find_compatible_node(NULL, NULL, "amlogic,meson-gx-socinfo");
+	if (!np)
+		return -ENODEV;
+
+	meson_gx_socinfo_base = of_iomap(np, 0);
+	of_node_put(np);
+
+	if (!meson_gx_socinfo_base) {
+		pr_err("%s: failed to map socinfo\n", np->name);
+		return -ENOMEM;
+	}
+
+	socinfo = readl_relaxed(meson_gx_socinfo_base);
+	iounmap(meson_gx_socinfo_base);
+
+	soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+	if (!soc_dev_attr)
+		return -ENODEV;
+
+	soc_dev_attr->family = "Amlogic Meson";
+
+	root = of_find_node_by_path("/");
+	of_property_read_string(root, "model", &soc_dev_attr->machine);
+	of_node_put(root);
+
+	soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%x:%x - %x:%x",
+					   socinfo_to_major(socinfo),
+					   socinfo_to_minor(socinfo),
+					   socinfo_to_pack(socinfo),
+					   socinfo_to_misc(socinfo));
+	soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "%s (%s)",
+					 socinfo_to_soc_id(socinfo),
+					 socinfo_to_package_id(socinfo));
+
+	soc_dev = soc_device_register(soc_dev_attr);
+	if (IS_ERR(soc_dev)) {
+		kfree(soc_dev_attr->revision);
+		kfree_const(soc_dev_attr->soc_id);
+		kfree(soc_dev_attr);
+		return PTR_ERR(soc_dev);
+	}
+	dev = soc_device_to_device(soc_dev);
+
+	dev_info(dev, "Amlogic Meson %s Revision %x:%x (%x:%x) Detected\n",
+			soc_dev_attr->soc_id,
+			socinfo_to_major(socinfo),
+			socinfo_to_minor(socinfo),
+			socinfo_to_pack(socinfo),
+			socinfo_to_misc(socinfo));
+
+	return 0;
+}
+core_initcall(meson_gx_socinfo_init);
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH 1/3] soc: Add Amlogic SoC Information driver
@ 2017-03-31  8:47   ` Neil Armstrong
  0 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-03-31  8:47 UTC (permalink / raw)
  To: linux-arm-kernel

Amlogic SoCs have a SoC information register for SoC type, package type and
revision information.
This patchs adds support for this register decoding and exposing with the
SoC bus infrastructure.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 drivers/soc/Kconfig                    |   1 +
 drivers/soc/Makefile                   |   1 +
 drivers/soc/amlogic/Kconfig            |  12 +++
 drivers/soc/amlogic/Makefile           |   1 +
 drivers/soc/amlogic/meson-gx-socinfo.c | 158 +++++++++++++++++++++++++++++++++
 5 files changed, 173 insertions(+)
 create mode 100644 drivers/soc/amlogic/Kconfig
 create mode 100644 drivers/soc/amlogic/Makefile
 create mode 100644 drivers/soc/amlogic/meson-gx-socinfo.c

diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index f09023f..0b149a6 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,5 +1,6 @@
 menu "SOC (System On Chip) specific Drivers"
 
+source "drivers/soc/amlogic/Kconfig"
 source "drivers/soc/bcm/Kconfig"
 source "drivers/soc/fsl/Kconfig"
 source "drivers/soc/mediatek/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 05eae52..4c0c776 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_ARCH_DOVE)		+= dove/
 obj-$(CONFIG_MACH_DOVE)		+= dove/
 obj-y				+= fsl/
 obj-$(CONFIG_ARCH_MEDIATEK)	+= mediatek/
+obj-$(CONFIG_ARCH_MESON)	+= amlogic/
 obj-$(CONFIG_ARCH_QCOM)		+= qcom/
 obj-$(CONFIG_ARCH_RENESAS)	+= renesas/
 obj-$(CONFIG_ARCH_ROCKCHIP)	+= rockchip/
diff --git a/drivers/soc/amlogic/Kconfig b/drivers/soc/amlogic/Kconfig
new file mode 100644
index 0000000..22acf06
--- /dev/null
+++ b/drivers/soc/amlogic/Kconfig
@@ -0,0 +1,12 @@
+menu "Amlogic SoC drivers"
+
+config MESON_GX_SOCINFO
+	bool "Amlogic Meson GX SoC Information driver"
+	depends on ARCH_MESON || COMPILE_TEST
+	default ARCH_MESON
+	select SOC_BUS
+	help
+	  Say yes to support decoding of Amlogic Meson GX SoC family
+	  information about the type, package and version.
+
+endmenu
diff --git a/drivers/soc/amlogic/Makefile b/drivers/soc/amlogic/Makefile
new file mode 100644
index 0000000..3e85fc4
--- /dev/null
+++ b/drivers/soc/amlogic/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MESON_GX_SOCINFO) += meson-gx-socinfo.o
diff --git a/drivers/soc/amlogic/meson-gx-socinfo.c b/drivers/soc/amlogic/meson-gx-socinfo.c
new file mode 100644
index 0000000..bfdc644
--- /dev/null
+++ b/drivers/soc/amlogic/meson-gx-socinfo.c
@@ -0,0 +1,158 @@
+/*
+ * Copyright (c) 2017 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/sys_soc.h>
+
+#define SOCINFO_MAJOR_SHIFT	24
+#define SOCINFO_MINOR_SHIFT	16
+#define SOCINFO_PACK_SHIFT	8
+#define SOCINFO_MISC_SHIFT	0
+#define SOCINFO_MASK		0xff
+
+static const struct meson_gx_soc_id {
+	const char *name;
+	unsigned int id;
+} soc_ids[] = {
+	{ "GXBB", 0x1f },
+	{ "GXTVBB", 0x20 },
+	{ "GXL", 0x21 },
+	{ "GXM", 0x22 },
+	{ "TXL", 0x23 },
+};
+
+static const struct meson_gx_package_id {
+	const char *name;
+	unsigned int major_id;
+	unsigned int pack_id;
+} soc_packages[] = {
+	{ "S905", 0x1f, 0 },
+	{ "S905M", 0x1f, 0x20 },
+	{ "S905D", 0x21, 0 },
+	{ "S905X", 0x21, 0x80 },
+	{ "S905L", 0x21, 0xc0 },
+	{ "S905M2", 0x21, 0xe0 },
+	{ "S912", 0x22, 0 },
+};
+
+static inline unsigned int socinfo_to_major(u32 socinfo)
+{
+	return (socinfo >> SOCINFO_MAJOR_SHIFT) & SOCINFO_MASK;
+}
+
+static inline unsigned int socinfo_to_minor(u32 socinfo)
+{
+	return (socinfo >> SOCINFO_MINOR_SHIFT) & SOCINFO_MASK;
+}
+
+static inline unsigned int socinfo_to_pack(u32 socinfo)
+{
+	return (socinfo >> SOCINFO_PACK_SHIFT) & SOCINFO_MASK;
+}
+
+static inline unsigned int socinfo_to_misc(u32 socinfo)
+{
+	return (socinfo >> SOCINFO_MISC_SHIFT) & SOCINFO_MASK;
+}
+
+static const char *socinfo_to_package_id(u32 socinfo)
+{
+	unsigned int pack = socinfo_to_pack(socinfo) & 0xf0;
+	unsigned int major = socinfo_to_major(socinfo);
+	int i;
+
+	for (i = 0 ; i < ARRAY_SIZE(soc_packages) ; ++i) {
+		if (soc_packages[i].major_id == major &&
+		    soc_packages[i].pack_id == pack)
+			return soc_packages[i].name;
+	}
+
+	return "Unknown";
+}
+
+static const char *socinfo_to_soc_id(u32 socinfo)
+{
+	unsigned int id = socinfo_to_major(socinfo);
+	int i;
+
+	for (i = 0 ; i < ARRAY_SIZE(soc_ids) ; ++i) {
+		if (soc_ids[i].id == id)
+			return soc_ids[i].name;
+	}
+
+	return "Unknown";
+}
+
+int __init meson_gx_socinfo_init(void)
+{
+	struct soc_device_attribute *soc_dev_attr;
+	void __iomem *meson_gx_socinfo_base;
+	struct soc_device *soc_dev;
+	struct device_node *root;
+	struct device_node *np;
+	struct device *dev;
+	u32 socinfo;
+
+	/* look up for socinfo node */
+	np = of_find_compatible_node(NULL, NULL, "amlogic,meson-gx-socinfo");
+	if (!np)
+		return -ENODEV;
+
+	meson_gx_socinfo_base = of_iomap(np, 0);
+	of_node_put(np);
+
+	if (!meson_gx_socinfo_base) {
+		pr_err("%s: failed to map socinfo\n", np->name);
+		return -ENOMEM;
+	}
+
+	socinfo = readl_relaxed(meson_gx_socinfo_base);
+	iounmap(meson_gx_socinfo_base);
+
+	soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+	if (!soc_dev_attr)
+		return -ENODEV;
+
+	soc_dev_attr->family = "Amlogic Meson";
+
+	root = of_find_node_by_path("/");
+	of_property_read_string(root, "model", &soc_dev_attr->machine);
+	of_node_put(root);
+
+	soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%x:%x - %x:%x",
+					   socinfo_to_major(socinfo),
+					   socinfo_to_minor(socinfo),
+					   socinfo_to_pack(socinfo),
+					   socinfo_to_misc(socinfo));
+	soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "%s (%s)",
+					 socinfo_to_soc_id(socinfo),
+					 socinfo_to_package_id(socinfo));
+
+	soc_dev = soc_device_register(soc_dev_attr);
+	if (IS_ERR(soc_dev)) {
+		kfree(soc_dev_attr->revision);
+		kfree_const(soc_dev_attr->soc_id);
+		kfree(soc_dev_attr);
+		return PTR_ERR(soc_dev);
+	}
+	dev = soc_device_to_device(soc_dev);
+
+	dev_info(dev, "Amlogic Meson %s Revision %x:%x (%x:%x) Detected\n",
+			soc_dev_attr->soc_id,
+			socinfo_to_major(socinfo),
+			socinfo_to_minor(socinfo),
+			socinfo_to_pack(socinfo),
+			socinfo_to_misc(socinfo));
+
+	return 0;
+}
+core_initcall(meson_gx_socinfo_init);
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH 1/3] soc: Add Amlogic SoC Information driver
@ 2017-03-31  8:47   ` Neil Armstrong
  0 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-03-31  8:47 UTC (permalink / raw)
  To: linus-amlogic

Amlogic SoCs have a SoC information register for SoC type, package type and
revision information.
This patchs adds support for this register decoding and exposing with the
SoC bus infrastructure.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 drivers/soc/Kconfig                    |   1 +
 drivers/soc/Makefile                   |   1 +
 drivers/soc/amlogic/Kconfig            |  12 +++
 drivers/soc/amlogic/Makefile           |   1 +
 drivers/soc/amlogic/meson-gx-socinfo.c | 158 +++++++++++++++++++++++++++++++++
 5 files changed, 173 insertions(+)
 create mode 100644 drivers/soc/amlogic/Kconfig
 create mode 100644 drivers/soc/amlogic/Makefile
 create mode 100644 drivers/soc/amlogic/meson-gx-socinfo.c

diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index f09023f..0b149a6 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,5 +1,6 @@
 menu "SOC (System On Chip) specific Drivers"
 
+source "drivers/soc/amlogic/Kconfig"
 source "drivers/soc/bcm/Kconfig"
 source "drivers/soc/fsl/Kconfig"
 source "drivers/soc/mediatek/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 05eae52..4c0c776 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_ARCH_DOVE)		+= dove/
 obj-$(CONFIG_MACH_DOVE)		+= dove/
 obj-y				+= fsl/
 obj-$(CONFIG_ARCH_MEDIATEK)	+= mediatek/
+obj-$(CONFIG_ARCH_MESON)	+= amlogic/
 obj-$(CONFIG_ARCH_QCOM)		+= qcom/
 obj-$(CONFIG_ARCH_RENESAS)	+= renesas/
 obj-$(CONFIG_ARCH_ROCKCHIP)	+= rockchip/
diff --git a/drivers/soc/amlogic/Kconfig b/drivers/soc/amlogic/Kconfig
new file mode 100644
index 0000000..22acf06
--- /dev/null
+++ b/drivers/soc/amlogic/Kconfig
@@ -0,0 +1,12 @@
+menu "Amlogic SoC drivers"
+
+config MESON_GX_SOCINFO
+	bool "Amlogic Meson GX SoC Information driver"
+	depends on ARCH_MESON || COMPILE_TEST
+	default ARCH_MESON
+	select SOC_BUS
+	help
+	  Say yes to support decoding of Amlogic Meson GX SoC family
+	  information about the type, package and version.
+
+endmenu
diff --git a/drivers/soc/amlogic/Makefile b/drivers/soc/amlogic/Makefile
new file mode 100644
index 0000000..3e85fc4
--- /dev/null
+++ b/drivers/soc/amlogic/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MESON_GX_SOCINFO) += meson-gx-socinfo.o
diff --git a/drivers/soc/amlogic/meson-gx-socinfo.c b/drivers/soc/amlogic/meson-gx-socinfo.c
new file mode 100644
index 0000000..bfdc644
--- /dev/null
+++ b/drivers/soc/amlogic/meson-gx-socinfo.c
@@ -0,0 +1,158 @@
+/*
+ * Copyright (c) 2017 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/sys_soc.h>
+
+#define SOCINFO_MAJOR_SHIFT	24
+#define SOCINFO_MINOR_SHIFT	16
+#define SOCINFO_PACK_SHIFT	8
+#define SOCINFO_MISC_SHIFT	0
+#define SOCINFO_MASK		0xff
+
+static const struct meson_gx_soc_id {
+	const char *name;
+	unsigned int id;
+} soc_ids[] = {
+	{ "GXBB", 0x1f },
+	{ "GXTVBB", 0x20 },
+	{ "GXL", 0x21 },
+	{ "GXM", 0x22 },
+	{ "TXL", 0x23 },
+};
+
+static const struct meson_gx_package_id {
+	const char *name;
+	unsigned int major_id;
+	unsigned int pack_id;
+} soc_packages[] = {
+	{ "S905", 0x1f, 0 },
+	{ "S905M", 0x1f, 0x20 },
+	{ "S905D", 0x21, 0 },
+	{ "S905X", 0x21, 0x80 },
+	{ "S905L", 0x21, 0xc0 },
+	{ "S905M2", 0x21, 0xe0 },
+	{ "S912", 0x22, 0 },
+};
+
+static inline unsigned int socinfo_to_major(u32 socinfo)
+{
+	return (socinfo >> SOCINFO_MAJOR_SHIFT) & SOCINFO_MASK;
+}
+
+static inline unsigned int socinfo_to_minor(u32 socinfo)
+{
+	return (socinfo >> SOCINFO_MINOR_SHIFT) & SOCINFO_MASK;
+}
+
+static inline unsigned int socinfo_to_pack(u32 socinfo)
+{
+	return (socinfo >> SOCINFO_PACK_SHIFT) & SOCINFO_MASK;
+}
+
+static inline unsigned int socinfo_to_misc(u32 socinfo)
+{
+	return (socinfo >> SOCINFO_MISC_SHIFT) & SOCINFO_MASK;
+}
+
+static const char *socinfo_to_package_id(u32 socinfo)
+{
+	unsigned int pack = socinfo_to_pack(socinfo) & 0xf0;
+	unsigned int major = socinfo_to_major(socinfo);
+	int i;
+
+	for (i = 0 ; i < ARRAY_SIZE(soc_packages) ; ++i) {
+		if (soc_packages[i].major_id == major &&
+		    soc_packages[i].pack_id == pack)
+			return soc_packages[i].name;
+	}
+
+	return "Unknown";
+}
+
+static const char *socinfo_to_soc_id(u32 socinfo)
+{
+	unsigned int id = socinfo_to_major(socinfo);
+	int i;
+
+	for (i = 0 ; i < ARRAY_SIZE(soc_ids) ; ++i) {
+		if (soc_ids[i].id == id)
+			return soc_ids[i].name;
+	}
+
+	return "Unknown";
+}
+
+int __init meson_gx_socinfo_init(void)
+{
+	struct soc_device_attribute *soc_dev_attr;
+	void __iomem *meson_gx_socinfo_base;
+	struct soc_device *soc_dev;
+	struct device_node *root;
+	struct device_node *np;
+	struct device *dev;
+	u32 socinfo;
+
+	/* look up for socinfo node */
+	np = of_find_compatible_node(NULL, NULL, "amlogic,meson-gx-socinfo");
+	if (!np)
+		return -ENODEV;
+
+	meson_gx_socinfo_base = of_iomap(np, 0);
+	of_node_put(np);
+
+	if (!meson_gx_socinfo_base) {
+		pr_err("%s: failed to map socinfo\n", np->name);
+		return -ENOMEM;
+	}
+
+	socinfo = readl_relaxed(meson_gx_socinfo_base);
+	iounmap(meson_gx_socinfo_base);
+
+	soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+	if (!soc_dev_attr)
+		return -ENODEV;
+
+	soc_dev_attr->family = "Amlogic Meson";
+
+	root = of_find_node_by_path("/");
+	of_property_read_string(root, "model", &soc_dev_attr->machine);
+	of_node_put(root);
+
+	soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%x:%x - %x:%x",
+					   socinfo_to_major(socinfo),
+					   socinfo_to_minor(socinfo),
+					   socinfo_to_pack(socinfo),
+					   socinfo_to_misc(socinfo));
+	soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "%s (%s)",
+					 socinfo_to_soc_id(socinfo),
+					 socinfo_to_package_id(socinfo));
+
+	soc_dev = soc_device_register(soc_dev_attr);
+	if (IS_ERR(soc_dev)) {
+		kfree(soc_dev_attr->revision);
+		kfree_const(soc_dev_attr->soc_id);
+		kfree(soc_dev_attr);
+		return PTR_ERR(soc_dev);
+	}
+	dev = soc_device_to_device(soc_dev);
+
+	dev_info(dev, "Amlogic Meson %s Revision %x:%x (%x:%x) Detected\n",
+			soc_dev_attr->soc_id,
+			socinfo_to_major(socinfo),
+			socinfo_to_minor(socinfo),
+			socinfo_to_pack(socinfo),
+			socinfo_to_misc(socinfo));
+
+	return 0;
+}
+core_initcall(meson_gx_socinfo_init);
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
  2017-03-31  8:47 ` Neil Armstrong
  (?)
@ 2017-03-31  8:47   ` Neil Armstrong
  -1 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-03-31  8:47 UTC (permalink / raw)
  To: khilman, carlo
  Cc: Neil Armstrong, linux-amlogic, linux-arm-kernel, linux-kernel,
	devicetree

Add bindings for the SoC information register of the Amlogic SoCs.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
index bfd5b55..b850985 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.txt
+++ b/Documentation/devicetree/bindings/arm/amlogic.txt
@@ -52,3 +52,23 @@ Board compatible values:
   - "amlogic,q201" (Meson gxm s912)
   - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
   - "nexbox,a1" (Meson gxm s912)
+
+Amlogic Meson GX SoCs Information
+----------------------------------
+
+The Meson SoCs have a Product Register that allows to retrieve SoC type,
+package and revision information. If present, a device node for this register
+should be added.
+
+Required properties:
+  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
+  - reg: Base address and length of the register block.
+
+Examples
+--------
+
+	chipid@220 {
+		compatible = "amlogic,meson-gx-socinfo";
+		reg = <0x0 0x00220 0x0 0x4>;
+	};
+
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-03-31  8:47   ` Neil Armstrong
  0 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-03-31  8:47 UTC (permalink / raw)
  To: linux-arm-kernel

Add bindings for the SoC information register of the Amlogic SoCs.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
index bfd5b55..b850985 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.txt
+++ b/Documentation/devicetree/bindings/arm/amlogic.txt
@@ -52,3 +52,23 @@ Board compatible values:
   - "amlogic,q201" (Meson gxm s912)
   - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
   - "nexbox,a1" (Meson gxm s912)
+
+Amlogic Meson GX SoCs Information
+----------------------------------
+
+The Meson SoCs have a Product Register that allows to retrieve SoC type,
+package and revision information. If present, a device node for this register
+should be added.
+
+Required properties:
+  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
+  - reg: Base address and length of the register block.
+
+Examples
+--------
+
+	chipid at 220 {
+		compatible = "amlogic,meson-gx-socinfo";
+		reg = <0x0 0x00220 0x0 0x4>;
+	};
+
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-03-31  8:47   ` Neil Armstrong
  0 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-03-31  8:47 UTC (permalink / raw)
  To: linus-amlogic

Add bindings for the SoC information register of the Amlogic SoCs.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
index bfd5b55..b850985 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.txt
+++ b/Documentation/devicetree/bindings/arm/amlogic.txt
@@ -52,3 +52,23 @@ Board compatible values:
   - "amlogic,q201" (Meson gxm s912)
   - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
   - "nexbox,a1" (Meson gxm s912)
+
+Amlogic Meson GX SoCs Information
+----------------------------------
+
+The Meson SoCs have a Product Register that allows to retrieve SoC type,
+package and revision information. If present, a device node for this register
+should be added.
+
+Required properties:
+  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
+  - reg: Base address and length of the register block.
+
+Examples
+--------
+
+	chipid at 220 {
+		compatible = "amlogic,meson-gx-socinfo";
+		reg = <0x0 0x00220 0x0 0x4>;
+	};
+
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH 3/3] ARM64: dts: meson-gx: Add SoC info register
  2017-03-31  8:47 ` Neil Armstrong
  (?)
@ 2017-03-31  8:47   ` Neil Armstrong
  -1 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-03-31  8:47 UTC (permalink / raw)
  To: khilman, carlo
  Cc: Neil Armstrong, linux-amlogic, linux-arm-kernel, linux-kernel,
	devicetree

Add node for the Amlogic Meson GX SoC information register.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 886efa5..c8e42d4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -357,6 +357,11 @@
 				#reset-cells = <1>;
 			};
 
+			chipid@220 {
+				compatible = "amlogic,meson-gx-socinfo";
+				reg = <0x0 0x00220 0x0 0x4>;
+			};
+
 			uart_AO: serial@4c0 {
 				compatible = "amlogic,meson-uart";
 				reg = <0x0 0x004c0 0x0 0x14>;
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH 3/3] ARM64: dts: meson-gx: Add SoC info register
@ 2017-03-31  8:47   ` Neil Armstrong
  0 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-03-31  8:47 UTC (permalink / raw)
  To: linux-arm-kernel

Add node for the Amlogic Meson GX SoC information register.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 886efa5..c8e42d4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -357,6 +357,11 @@
 				#reset-cells = <1>;
 			};
 
+			chipid at 220 {
+				compatible = "amlogic,meson-gx-socinfo";
+				reg = <0x0 0x00220 0x0 0x4>;
+			};
+
 			uart_AO: serial at 4c0 {
 				compatible = "amlogic,meson-uart";
 				reg = <0x0 0x004c0 0x0 0x14>;
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH 3/3] ARM64: dts: meson-gx: Add SoC info register
@ 2017-03-31  8:47   ` Neil Armstrong
  0 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-03-31  8:47 UTC (permalink / raw)
  To: linus-amlogic

Add node for the Amlogic Meson GX SoC information register.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 886efa5..c8e42d4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -357,6 +357,11 @@
 				#reset-cells = <1>;
 			};
 
+			chipid at 220 {
+				compatible = "amlogic,meson-gx-socinfo";
+				reg = <0x0 0x00220 0x0 0x4>;
+			};
+
 			uart_AO: serial at 4c0 {
 				compatible = "amlogic,meson-uart";
 				reg = <0x0 0x004c0 0x0 0x14>;
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 37+ messages in thread

* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-03-31 13:44     ` Arnd Bergmann
  0 siblings, 0 replies; 37+ messages in thread
From: Arnd Bergmann @ 2017-03-31 13:44 UTC (permalink / raw)
  To: Neil Armstrong
  Cc: Kevin Hilman, carlo, linux-amlogic, Linux ARM,
	Linux Kernel Mailing List, devicetree

On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
<narmstrong@baylibre.com> wrote:
> Add bindings for the SoC information register of the Amlogic SoCs.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
> index bfd5b55..b850985 100644
> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
> @@ -52,3 +52,23 @@ Board compatible values:
>    - "amlogic,q201" (Meson gxm s912)
>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>    - "nexbox,a1" (Meson gxm s912)
> +
> +Amlogic Meson GX SoCs Information
> +----------------------------------
> +
> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
> +package and revision information. If present, a device node for this register
> +should be added.
> +
> +Required properties:
> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
> +  - reg: Base address and length of the register block.
> +
> +Examples
> +--------
> +
> +       chipid@220 {
> +               compatible = "amlogic,meson-gx-socinfo";
> +               reg = <0x0 0x00220 0x0 0x4>;
> +       };
> +

The register location would hint that this is in the middle of some block of
random registers, i.e. a syscon or some unrelated device.

Are you sure that "socinfo" is the actual name of the IP block and that
it only has a single 32-bit register?

     Arnd

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-03-31 13:44     ` Arnd Bergmann
  0 siblings, 0 replies; 37+ messages in thread
From: Arnd Bergmann @ 2017-03-31 13:44 UTC (permalink / raw)
  To: Neil Armstrong
  Cc: Kevin Hilman, carlo-KA+7E9HrN00dnm+yROfE0A,
	linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Linux ARM,
	Linux Kernel Mailing List, devicetree-u79uwXL29TY76Z2rM5mHXA

On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
<narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> Add bindings for the SoC information register of the Amlogic SoCs.
>
> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
> index bfd5b55..b850985 100644
> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
> @@ -52,3 +52,23 @@ Board compatible values:
>    - "amlogic,q201" (Meson gxm s912)
>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>    - "nexbox,a1" (Meson gxm s912)
> +
> +Amlogic Meson GX SoCs Information
> +----------------------------------
> +
> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
> +package and revision information. If present, a device node for this register
> +should be added.
> +
> +Required properties:
> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
> +  - reg: Base address and length of the register block.
> +
> +Examples
> +--------
> +
> +       chipid@220 {
> +               compatible = "amlogic,meson-gx-socinfo";
> +               reg = <0x0 0x00220 0x0 0x4>;
> +       };
> +

The register location would hint that this is in the middle of some block of
random registers, i.e. a syscon or some unrelated device.

Are you sure that "socinfo" is the actual name of the IP block and that
it only has a single 32-bit register?

     Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-03-31 13:44     ` Arnd Bergmann
  0 siblings, 0 replies; 37+ messages in thread
From: Arnd Bergmann @ 2017-03-31 13:44 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
<narmstrong@baylibre.com> wrote:
> Add bindings for the SoC information register of the Amlogic SoCs.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
> index bfd5b55..b850985 100644
> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
> @@ -52,3 +52,23 @@ Board compatible values:
>    - "amlogic,q201" (Meson gxm s912)
>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>    - "nexbox,a1" (Meson gxm s912)
> +
> +Amlogic Meson GX SoCs Information
> +----------------------------------
> +
> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
> +package and revision information. If present, a device node for this register
> +should be added.
> +
> +Required properties:
> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
> +  - reg: Base address and length of the register block.
> +
> +Examples
> +--------
> +
> +       chipid at 220 {
> +               compatible = "amlogic,meson-gx-socinfo";
> +               reg = <0x0 0x00220 0x0 0x4>;
> +       };
> +

The register location would hint that this is in the middle of some block of
random registers, i.e. a syscon or some unrelated device.

Are you sure that "socinfo" is the actual name of the IP block and that
it only has a single 32-bit register?

     Arnd

^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-03-31 13:44     ` Arnd Bergmann
  0 siblings, 0 replies; 37+ messages in thread
From: Arnd Bergmann @ 2017-03-31 13:44 UTC (permalink / raw)
  To: linus-amlogic

On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
<narmstrong@baylibre.com> wrote:
> Add bindings for the SoC information register of the Amlogic SoCs.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
> index bfd5b55..b850985 100644
> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
> @@ -52,3 +52,23 @@ Board compatible values:
>    - "amlogic,q201" (Meson gxm s912)
>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>    - "nexbox,a1" (Meson gxm s912)
> +
> +Amlogic Meson GX SoCs Information
> +----------------------------------
> +
> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
> +package and revision information. If present, a device node for this register
> +should be added.
> +
> +Required properties:
> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
> +  - reg: Base address and length of the register block.
> +
> +Examples
> +--------
> +
> +       chipid at 220 {
> +               compatible = "amlogic,meson-gx-socinfo";
> +               reg = <0x0 0x00220 0x0 0x4>;
> +       };
> +

The register location would hint that this is in the middle of some block of
random registers, i.e. a syscon or some unrelated device.

Are you sure that "socinfo" is the actual name of the IP block and that
it only has a single 32-bit register?

     Arnd

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
  2017-03-31 13:44     ` Arnd Bergmann
  (?)
@ 2017-03-31 14:10       ` Neil Armstrong
  -1 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-03-31 14:10 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Kevin Hilman, carlo, linux-amlogic, Linux ARM,
	Linux Kernel Mailing List, devicetree

On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
> <narmstrong@baylibre.com> wrote:
>> Add bindings for the SoC information register of the Amlogic SoCs.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>>  1 file changed, 20 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
>> index bfd5b55..b850985 100644
>> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
>> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
>> @@ -52,3 +52,23 @@ Board compatible values:
>>    - "amlogic,q201" (Meson gxm s912)
>>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>>    - "nexbox,a1" (Meson gxm s912)
>> +
>> +Amlogic Meson GX SoCs Information
>> +----------------------------------
>> +
>> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
>> +package and revision information. If present, a device node for this register
>> +should be added.
>> +
>> +Required properties:
>> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
>> +  - reg: Base address and length of the register block.
>> +
>> +Examples
>> +--------
>> +
>> +       chipid@220 {
>> +               compatible = "amlogic,meson-gx-socinfo";
>> +               reg = <0x0 0x00220 0x0 0x4>;
>> +       };
>> +
> 
> The register location would hint that this is in the middle of some block of
> random registers, i.e. a syscon or some unrelated device.
> 
> Are you sure that "socinfo" is the actual name of the IP block and that
> it only has a single 32-bit register?
> 
>      Arnd
> 

Hi Arnd,

I'm sorry I did not find any relevant registers in the docs or source code describing
it in a specific block of registers, and no close enough register definitions either.
They may be used by the secure firmware I imagine.

For the register name, Amlogic refers it to "cpu_version" in their code, but it really
gives some details on the whole SoC and package, and socinfo seems better.

Neil

^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-03-31 14:10       ` Neil Armstrong
  0 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-03-31 14:10 UTC (permalink / raw)
  To: linux-arm-kernel

On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
> <narmstrong@baylibre.com> wrote:
>> Add bindings for the SoC information register of the Amlogic SoCs.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>>  1 file changed, 20 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
>> index bfd5b55..b850985 100644
>> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
>> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
>> @@ -52,3 +52,23 @@ Board compatible values:
>>    - "amlogic,q201" (Meson gxm s912)
>>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>>    - "nexbox,a1" (Meson gxm s912)
>> +
>> +Amlogic Meson GX SoCs Information
>> +----------------------------------
>> +
>> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
>> +package and revision information. If present, a device node for this register
>> +should be added.
>> +
>> +Required properties:
>> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
>> +  - reg: Base address and length of the register block.
>> +
>> +Examples
>> +--------
>> +
>> +       chipid at 220 {
>> +               compatible = "amlogic,meson-gx-socinfo";
>> +               reg = <0x0 0x00220 0x0 0x4>;
>> +       };
>> +
> 
> The register location would hint that this is in the middle of some block of
> random registers, i.e. a syscon or some unrelated device.
> 
> Are you sure that "socinfo" is the actual name of the IP block and that
> it only has a single 32-bit register?
> 
>      Arnd
> 

Hi Arnd,

I'm sorry I did not find any relevant registers in the docs or source code describing
it in a specific block of registers, and no close enough register definitions either.
They may be used by the secure firmware I imagine.

For the register name, Amlogic refers it to "cpu_version" in their code, but it really
gives some details on the whole SoC and package, and socinfo seems better.

Neil

^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-03-31 14:10       ` Neil Armstrong
  0 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-03-31 14:10 UTC (permalink / raw)
  To: linus-amlogic

On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
> <narmstrong@baylibre.com> wrote:
>> Add bindings for the SoC information register of the Amlogic SoCs.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>>  1 file changed, 20 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
>> index bfd5b55..b850985 100644
>> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
>> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
>> @@ -52,3 +52,23 @@ Board compatible values:
>>    - "amlogic,q201" (Meson gxm s912)
>>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>>    - "nexbox,a1" (Meson gxm s912)
>> +
>> +Amlogic Meson GX SoCs Information
>> +----------------------------------
>> +
>> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
>> +package and revision information. If present, a device node for this register
>> +should be added.
>> +
>> +Required properties:
>> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
>> +  - reg: Base address and length of the register block.
>> +
>> +Examples
>> +--------
>> +
>> +       chipid at 220 {
>> +               compatible = "amlogic,meson-gx-socinfo";
>> +               reg = <0x0 0x00220 0x0 0x4>;
>> +       };
>> +
> 
> The register location would hint that this is in the middle of some block of
> random registers, i.e. a syscon or some unrelated device.
> 
> Are you sure that "socinfo" is the actual name of the IP block and that
> it only has a single 32-bit register?
> 
>      Arnd
> 

Hi Arnd,

I'm sorry I did not find any relevant registers in the docs or source code describing
it in a specific block of registers, and no close enough register definitions either.
They may be used by the secure firmware I imagine.

For the register name, Amlogic refers it to "cpu_version" in their code, but it really
gives some details on the whole SoC and package, and socinfo seems better.

Neil

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-04-03 16:34         ` Rob Herring
  0 siblings, 0 replies; 37+ messages in thread
From: Rob Herring @ 2017-04-03 16:34 UTC (permalink / raw)
  To: Neil Armstrong
  Cc: Arnd Bergmann, Kevin Hilman, carlo, linux-amlogic, Linux ARM,
	Linux Kernel Mailing List, devicetree

On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
> > On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
> > <narmstrong@baylibre.com> wrote:
> >> Add bindings for the SoC information register of the Amlogic SoCs.
> >>
> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> >> ---
> >>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
> >>  1 file changed, 20 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
> >> index bfd5b55..b850985 100644
> >> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
> >> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
> >> @@ -52,3 +52,23 @@ Board compatible values:
> >>    - "amlogic,q201" (Meson gxm s912)
> >>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
> >>    - "nexbox,a1" (Meson gxm s912)
> >> +
> >> +Amlogic Meson GX SoCs Information
> >> +----------------------------------
> >> +
> >> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
> >> +package and revision information. If present, a device node for this register
> >> +should be added.
> >> +
> >> +Required properties:
> >> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
> >> +  - reg: Base address and length of the register block.
> >> +
> >> +Examples
> >> +--------
> >> +
> >> +       chipid@220 {
> >> +               compatible = "amlogic,meson-gx-socinfo";
> >> +               reg = <0x0 0x00220 0x0 0x4>;
> >> +       };
> >> +
> > 
> > The register location would hint that this is in the middle of some block of
> > random registers, i.e. a syscon or some unrelated device.
> > 
> > Are you sure that "socinfo" is the actual name of the IP block and that
> > it only has a single 32-bit register?
> > 
> >      Arnd
> > 
> 
> Hi Arnd,
> 
> I'm sorry I did not find any relevant registers in the docs or source code describing
> it in a specific block of registers, and no close enough register definitions either.
> They may be used by the secure firmware I imagine.
> 
> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
> gives some details on the whole SoC and package, and socinfo seems better.

A register at address 0x220 seems a bit strange (unless there's ranges 
you're not showing), but ROM code at this address would be fairly 
typical. And putting version information into the ROM is also common.

Rob

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-04-03 16:34         ` Rob Herring
  0 siblings, 0 replies; 37+ messages in thread
From: Rob Herring @ 2017-04-03 16:34 UTC (permalink / raw)
  To: Neil Armstrong
  Cc: Arnd Bergmann, Kevin Hilman, carlo-KA+7E9HrN00dnm+yROfE0A,
	linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Linux ARM,
	Linux Kernel Mailing List, devicetree-u79uwXL29TY76Z2rM5mHXA

On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
> > On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
> > <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> >> Add bindings for the SoC information register of the Amlogic SoCs.
> >>
> >> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> >> ---
> >>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
> >>  1 file changed, 20 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
> >> index bfd5b55..b850985 100644
> >> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
> >> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
> >> @@ -52,3 +52,23 @@ Board compatible values:
> >>    - "amlogic,q201" (Meson gxm s912)
> >>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
> >>    - "nexbox,a1" (Meson gxm s912)
> >> +
> >> +Amlogic Meson GX SoCs Information
> >> +----------------------------------
> >> +
> >> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
> >> +package and revision information. If present, a device node for this register
> >> +should be added.
> >> +
> >> +Required properties:
> >> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
> >> +  - reg: Base address and length of the register block.
> >> +
> >> +Examples
> >> +--------
> >> +
> >> +       chipid@220 {
> >> +               compatible = "amlogic,meson-gx-socinfo";
> >> +               reg = <0x0 0x00220 0x0 0x4>;
> >> +       };
> >> +
> > 
> > The register location would hint that this is in the middle of some block of
> > random registers, i.e. a syscon or some unrelated device.
> > 
> > Are you sure that "socinfo" is the actual name of the IP block and that
> > it only has a single 32-bit register?
> > 
> >      Arnd
> > 
> 
> Hi Arnd,
> 
> I'm sorry I did not find any relevant registers in the docs or source code describing
> it in a specific block of registers, and no close enough register definitions either.
> They may be used by the secure firmware I imagine.
> 
> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
> gives some details on the whole SoC and package, and socinfo seems better.

A register at address 0x220 seems a bit strange (unless there's ranges 
you're not showing), but ROM code at this address would be fairly 
typical. And putting version information into the ROM is also common.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-04-03 16:34         ` Rob Herring
  0 siblings, 0 replies; 37+ messages in thread
From: Rob Herring @ 2017-04-03 16:34 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
> > On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
> > <narmstrong@baylibre.com> wrote:
> >> Add bindings for the SoC information register of the Amlogic SoCs.
> >>
> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> >> ---
> >>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
> >>  1 file changed, 20 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
> >> index bfd5b55..b850985 100644
> >> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
> >> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
> >> @@ -52,3 +52,23 @@ Board compatible values:
> >>    - "amlogic,q201" (Meson gxm s912)
> >>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
> >>    - "nexbox,a1" (Meson gxm s912)
> >> +
> >> +Amlogic Meson GX SoCs Information
> >> +----------------------------------
> >> +
> >> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
> >> +package and revision information. If present, a device node for this register
> >> +should be added.
> >> +
> >> +Required properties:
> >> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
> >> +  - reg: Base address and length of the register block.
> >> +
> >> +Examples
> >> +--------
> >> +
> >> +       chipid at 220 {
> >> +               compatible = "amlogic,meson-gx-socinfo";
> >> +               reg = <0x0 0x00220 0x0 0x4>;
> >> +       };
> >> +
> > 
> > The register location would hint that this is in the middle of some block of
> > random registers, i.e. a syscon or some unrelated device.
> > 
> > Are you sure that "socinfo" is the actual name of the IP block and that
> > it only has a single 32-bit register?
> > 
> >      Arnd
> > 
> 
> Hi Arnd,
> 
> I'm sorry I did not find any relevant registers in the docs or source code describing
> it in a specific block of registers, and no close enough register definitions either.
> They may be used by the secure firmware I imagine.
> 
> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
> gives some details on the whole SoC and package, and socinfo seems better.

A register at address 0x220 seems a bit strange (unless there's ranges 
you're not showing), but ROM code at this address would be fairly 
typical. And putting version information into the ROM is also common.

Rob

^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-04-03 16:34         ` Rob Herring
  0 siblings, 0 replies; 37+ messages in thread
From: Rob Herring @ 2017-04-03 16:34 UTC (permalink / raw)
  To: linus-amlogic

On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
> > On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
> > <narmstrong@baylibre.com> wrote:
> >> Add bindings for the SoC information register of the Amlogic SoCs.
> >>
> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> >> ---
> >>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
> >>  1 file changed, 20 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
> >> index bfd5b55..b850985 100644
> >> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
> >> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
> >> @@ -52,3 +52,23 @@ Board compatible values:
> >>    - "amlogic,q201" (Meson gxm s912)
> >>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
> >>    - "nexbox,a1" (Meson gxm s912)
> >> +
> >> +Amlogic Meson GX SoCs Information
> >> +----------------------------------
> >> +
> >> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
> >> +package and revision information. If present, a device node for this register
> >> +should be added.
> >> +
> >> +Required properties:
> >> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
> >> +  - reg: Base address and length of the register block.
> >> +
> >> +Examples
> >> +--------
> >> +
> >> +       chipid at 220 {
> >> +               compatible = "amlogic,meson-gx-socinfo";
> >> +               reg = <0x0 0x00220 0x0 0x4>;
> >> +       };
> >> +
> > 
> > The register location would hint that this is in the middle of some block of
> > random registers, i.e. a syscon or some unrelated device.
> > 
> > Are you sure that "socinfo" is the actual name of the IP block and that
> > it only has a single 32-bit register?
> > 
> >      Arnd
> > 
> 
> Hi Arnd,
> 
> I'm sorry I did not find any relevant registers in the docs or source code describing
> it in a specific block of registers, and no close enough register definitions either.
> They may be used by the secure firmware I imagine.
> 
> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
> gives some details on the whole SoC and package, and socinfo seems better.

A register at address 0x220 seems a bit strange (unless there's ranges 
you're not showing), but ROM code at this address would be fairly 
typical. And putting version information into the ROM is also common.

Rob

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
  2017-04-03 16:34         ` Rob Herring
  (?)
@ 2017-04-04  8:51           ` Neil Armstrong
  -1 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-04-04  8:51 UTC (permalink / raw)
  To: Rob Herring
  Cc: Arnd Bergmann, Kevin Hilman, carlo, linux-amlogic, Linux ARM,
	Linux Kernel Mailing List, devicetree

On 04/03/2017 06:34 PM, Rob Herring wrote:
> On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
>> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
>>> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
>>> <narmstrong@baylibre.com> wrote:
>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>>>>  1 file changed, 20 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>> index bfd5b55..b850985 100644
>>>> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>> @@ -52,3 +52,23 @@ Board compatible values:
>>>>    - "amlogic,q201" (Meson gxm s912)
>>>>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>>>>    - "nexbox,a1" (Meson gxm s912)
>>>> +
>>>> +Amlogic Meson GX SoCs Information
>>>> +----------------------------------
>>>> +
>>>> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
>>>> +package and revision information. If present, a device node for this register
>>>> +should be added.
>>>> +
>>>> +Required properties:
>>>> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
>>>> +  - reg: Base address and length of the register block.
>>>> +
>>>> +Examples
>>>> +--------
>>>> +
>>>> +       chipid@220 {
>>>> +               compatible = "amlogic,meson-gx-socinfo";
>>>> +               reg = <0x0 0x00220 0x0 0x4>;
>>>> +       };
>>>> +
>>>
>>> The register location would hint that this is in the middle of some block of
>>> random registers, i.e. a syscon or some unrelated device.
>>>
>>> Are you sure that "socinfo" is the actual name of the IP block and that
>>> it only has a single 32-bit register?
>>>
>>>      Arnd
>>>
>>
>> Hi Arnd,
>>
>> I'm sorry I did not find any relevant registers in the docs or source code describing
>> it in a specific block of registers, and no close enough register definitions either.
>> They may be used by the secure firmware I imagine.
>>
>> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
>> gives some details on the whole SoC and package, and socinfo seems better.
> 
> A register at address 0x220 seems a bit strange (unless there's ranges 
> you're not showing), but ROM code at this address would be fairly 
> typical. And putting version information into the ROM is also common.
> 
> Rob
> 

Hi Rob.

Indeed it's part of a larger range :
                 aobus: aobus@c8100000 {
                        compatible = "simple-bus";
                        reg = <0x0 0xc8100000 0x0 0x100000>;
                        #address-cells = <2>;
                        #size-cells = <2>;
                        ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;


While scrubbing on the uboot source, I found a sort of block of registers dedicated to communicate with
the secure firmware :
AO_SEC_REG0							0x140
AO_SEC_REG1							0x144
AO_SEC_REG2							0x148
AO_SEC_TMODE_PWD0						0x160
AO_SEC_TMODE_PWD1						0x164
AO_SEC_TMODE_PWD2						0x168
AO_SEC_TMODE_PWD3						0x16C
AO_SEC_SCRATCH							0x17C
AO_SEC_JTAG_PWD0						0x180
AO_SEC_JTAG_PWD1						0x184
AO_SEC_JTAG_PWD2						0x188
AO_SEC_JTAG_PWD3						0x18C
AO_SEC_JTAG_SEC_CNTL						0x190
AO_SEC_JTAG_PWD_ADDR0						0x194
AO_SEC_JTAG_PWD_ADDR1						0x198
AO_SEC_JTAG_PWD_ADDR2						0x19C
AO_SEC_JTAG_PWD_ADDR3						0x1A0
AO_SEC_SHARED_AHB_SRAM_REG0_0					0x1C0
AO_SEC_SHARED_AHB_SRAM_REG0_1					0x1C4
AO_SEC_SHARED_AHB_SRAM_REG0_2					0x1C8
AO_SEC_SHARED_AHB_SRAM_REG1_0					0x1CC
AO_SEC_SHARED_AHB_SRAM_REG1_1					0x1D0
AO_SEC_SHARED_AHB_SRAM_REG1_2					0x1D4
AO_SEC_SHARED_AHB_SRAM_REG2_0					0x1D8
AO_SEC_SHARED_AHB_SRAM_REG2_1					0x1DC
AO_SEC_SHARED_AHB_SRAM_REG2_2					0x1E0
AO_SEC_SHARED_AHB_SRAM_REG3_0					0x1E4
AO_SEC_SHARED_AHB_SRAM_REG3_1					0x1E8
AO_SEC_SHARED_AHB_SRAM_REG3_2					0x1EC
AO_SEC_AO_AHB_SRAM_REG0_0					0x1F0
AO_SEC_AO_AHB_SRAM_REG0_1					0x1F4
AO_SEC_AO_AHB_SRAM_REG1_0					0x1F8
AO_SEC_AO_AHB_SRAM_REG1_1					0x1FC
AO_SEC_SD_CFG8							0x220
AO_SEC_SD_CFG9							0x224
AO_SEC_SD_CFG10							0x228
AO_SEC_SD_CFG11							0x22C
AO_SEC_SD_CFG12							0x230
AO_SEC_SD_CFG13							0x234
AO_SEC_SD_CFG14							0x238
AO_SEC_SD_CFG15							0x23C
AO_SEC_GP_CFG0							0x240
AO_SEC_GP_CFG1							0x244
AO_SEC_GP_CFG2							0x248
AO_SEC_GP_CFG3							0x24C
AO_SEC_GP_CFG4							0x250
AO_SEC_GP_CFG5							0x254
AO_SEC_GP_CFG6							0x258
AO_SEC_GP_CFG7							0x25C
AO_SEC_GP_CFG8							0x260
AO_SEC_GP_CFG9							0x264
AO_SEC_GP_CFG10							0x268
AO_SEC_GP_CFG11							0x26C
AO_SEC_GP_CFG12							0x270
AO_SEC_GP_CFG13							0x274
AO_SEC_GP_CFG14							0x278
AO_SEC_GP_CFG15							0x27C


As you see, the register we use here is AO_SEC_SD_CFG8...

Should I define all this block as simple-mfd and refer to it as a regmap ?

aobus: aobus@c8100000 {
	compatible = "simple-bus";
	reg = <0x0 0xc8100000 0x0 0x100000>;
	#address-cells = <2>;
	#size-cells = <2>;
	ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;

	ao_secure: ao-secure@140 {
		compatible = "amlogic,meson-gx-ao-secure", "simple-mfd";
		reg = <0x0 0x140 0x0 0x140>;
	};
};

chipid {
	compatible = "amlogic,meson-gx-socinfo";
	ao-secure = <&ao_secure>;
	chip-info-reg = <0xe0>;
};

Neil

^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-04-04  8:51           ` Neil Armstrong
  0 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-04-04  8:51 UTC (permalink / raw)
  To: linux-arm-kernel

On 04/03/2017 06:34 PM, Rob Herring wrote:
> On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
>> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
>>> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
>>> <narmstrong@baylibre.com> wrote:
>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>>>>  1 file changed, 20 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>> index bfd5b55..b850985 100644
>>>> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>> @@ -52,3 +52,23 @@ Board compatible values:
>>>>    - "amlogic,q201" (Meson gxm s912)
>>>>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>>>>    - "nexbox,a1" (Meson gxm s912)
>>>> +
>>>> +Amlogic Meson GX SoCs Information
>>>> +----------------------------------
>>>> +
>>>> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
>>>> +package and revision information. If present, a device node for this register
>>>> +should be added.
>>>> +
>>>> +Required properties:
>>>> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
>>>> +  - reg: Base address and length of the register block.
>>>> +
>>>> +Examples
>>>> +--------
>>>> +
>>>> +       chipid at 220 {
>>>> +               compatible = "amlogic,meson-gx-socinfo";
>>>> +               reg = <0x0 0x00220 0x0 0x4>;
>>>> +       };
>>>> +
>>>
>>> The register location would hint that this is in the middle of some block of
>>> random registers, i.e. a syscon or some unrelated device.
>>>
>>> Are you sure that "socinfo" is the actual name of the IP block and that
>>> it only has a single 32-bit register?
>>>
>>>      Arnd
>>>
>>
>> Hi Arnd,
>>
>> I'm sorry I did not find any relevant registers in the docs or source code describing
>> it in a specific block of registers, and no close enough register definitions either.
>> They may be used by the secure firmware I imagine.
>>
>> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
>> gives some details on the whole SoC and package, and socinfo seems better.
> 
> A register at address 0x220 seems a bit strange (unless there's ranges 
> you're not showing), but ROM code at this address would be fairly 
> typical. And putting version information into the ROM is also common.
> 
> Rob
> 

Hi Rob.

Indeed it's part of a larger range :
                 aobus: aobus at c8100000 {
                        compatible = "simple-bus";
                        reg = <0x0 0xc8100000 0x0 0x100000>;
                        #address-cells = <2>;
                        #size-cells = <2>;
                        ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;


While scrubbing on the uboot source, I found a sort of block of registers dedicated to communicate with
the secure firmware :
AO_SEC_REG0							0x140
AO_SEC_REG1							0x144
AO_SEC_REG2							0x148
AO_SEC_TMODE_PWD0						0x160
AO_SEC_TMODE_PWD1						0x164
AO_SEC_TMODE_PWD2						0x168
AO_SEC_TMODE_PWD3						0x16C
AO_SEC_SCRATCH							0x17C
AO_SEC_JTAG_PWD0						0x180
AO_SEC_JTAG_PWD1						0x184
AO_SEC_JTAG_PWD2						0x188
AO_SEC_JTAG_PWD3						0x18C
AO_SEC_JTAG_SEC_CNTL						0x190
AO_SEC_JTAG_PWD_ADDR0						0x194
AO_SEC_JTAG_PWD_ADDR1						0x198
AO_SEC_JTAG_PWD_ADDR2						0x19C
AO_SEC_JTAG_PWD_ADDR3						0x1A0
AO_SEC_SHARED_AHB_SRAM_REG0_0					0x1C0
AO_SEC_SHARED_AHB_SRAM_REG0_1					0x1C4
AO_SEC_SHARED_AHB_SRAM_REG0_2					0x1C8
AO_SEC_SHARED_AHB_SRAM_REG1_0					0x1CC
AO_SEC_SHARED_AHB_SRAM_REG1_1					0x1D0
AO_SEC_SHARED_AHB_SRAM_REG1_2					0x1D4
AO_SEC_SHARED_AHB_SRAM_REG2_0					0x1D8
AO_SEC_SHARED_AHB_SRAM_REG2_1					0x1DC
AO_SEC_SHARED_AHB_SRAM_REG2_2					0x1E0
AO_SEC_SHARED_AHB_SRAM_REG3_0					0x1E4
AO_SEC_SHARED_AHB_SRAM_REG3_1					0x1E8
AO_SEC_SHARED_AHB_SRAM_REG3_2					0x1EC
AO_SEC_AO_AHB_SRAM_REG0_0					0x1F0
AO_SEC_AO_AHB_SRAM_REG0_1					0x1F4
AO_SEC_AO_AHB_SRAM_REG1_0					0x1F8
AO_SEC_AO_AHB_SRAM_REG1_1					0x1FC
AO_SEC_SD_CFG8							0x220
AO_SEC_SD_CFG9							0x224
AO_SEC_SD_CFG10							0x228
AO_SEC_SD_CFG11							0x22C
AO_SEC_SD_CFG12							0x230
AO_SEC_SD_CFG13							0x234
AO_SEC_SD_CFG14							0x238
AO_SEC_SD_CFG15							0x23C
AO_SEC_GP_CFG0							0x240
AO_SEC_GP_CFG1							0x244
AO_SEC_GP_CFG2							0x248
AO_SEC_GP_CFG3							0x24C
AO_SEC_GP_CFG4							0x250
AO_SEC_GP_CFG5							0x254
AO_SEC_GP_CFG6							0x258
AO_SEC_GP_CFG7							0x25C
AO_SEC_GP_CFG8							0x260
AO_SEC_GP_CFG9							0x264
AO_SEC_GP_CFG10							0x268
AO_SEC_GP_CFG11							0x26C
AO_SEC_GP_CFG12							0x270
AO_SEC_GP_CFG13							0x274
AO_SEC_GP_CFG14							0x278
AO_SEC_GP_CFG15							0x27C


As you see, the register we use here is AO_SEC_SD_CFG8...

Should I define all this block as simple-mfd and refer to it as a regmap ?

aobus: aobus at c8100000 {
	compatible = "simple-bus";
	reg = <0x0 0xc8100000 0x0 0x100000>;
	#address-cells = <2>;
	#size-cells = <2>;
	ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;

	ao_secure: ao-secure at 140 {
		compatible = "amlogic,meson-gx-ao-secure", "simple-mfd";
		reg = <0x0 0x140 0x0 0x140>;
	};
};

chipid {
	compatible = "amlogic,meson-gx-socinfo";
	ao-secure = <&ao_secure>;
	chip-info-reg = <0xe0>;
};

Neil

^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-04-04  8:51           ` Neil Armstrong
  0 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-04-04  8:51 UTC (permalink / raw)
  To: linus-amlogic

On 04/03/2017 06:34 PM, Rob Herring wrote:
> On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
>> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
>>> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
>>> <narmstrong@baylibre.com> wrote:
>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>>>>  1 file changed, 20 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>> index bfd5b55..b850985 100644
>>>> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>> @@ -52,3 +52,23 @@ Board compatible values:
>>>>    - "amlogic,q201" (Meson gxm s912)
>>>>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>>>>    - "nexbox,a1" (Meson gxm s912)
>>>> +
>>>> +Amlogic Meson GX SoCs Information
>>>> +----------------------------------
>>>> +
>>>> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
>>>> +package and revision information. If present, a device node for this register
>>>> +should be added.
>>>> +
>>>> +Required properties:
>>>> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
>>>> +  - reg: Base address and length of the register block.
>>>> +
>>>> +Examples
>>>> +--------
>>>> +
>>>> +       chipid at 220 {
>>>> +               compatible = "amlogic,meson-gx-socinfo";
>>>> +               reg = <0x0 0x00220 0x0 0x4>;
>>>> +       };
>>>> +
>>>
>>> The register location would hint that this is in the middle of some block of
>>> random registers, i.e. a syscon or some unrelated device.
>>>
>>> Are you sure that "socinfo" is the actual name of the IP block and that
>>> it only has a single 32-bit register?
>>>
>>>      Arnd
>>>
>>
>> Hi Arnd,
>>
>> I'm sorry I did not find any relevant registers in the docs or source code describing
>> it in a specific block of registers, and no close enough register definitions either.
>> They may be used by the secure firmware I imagine.
>>
>> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
>> gives some details on the whole SoC and package, and socinfo seems better.
> 
> A register at address 0x220 seems a bit strange (unless there's ranges 
> you're not showing), but ROM code at this address would be fairly 
> typical. And putting version information into the ROM is also common.
> 
> Rob
> 

Hi Rob.

Indeed it's part of a larger range :
                 aobus: aobus at c8100000 {
                        compatible = "simple-bus";
                        reg = <0x0 0xc8100000 0x0 0x100000>;
                        #address-cells = <2>;
                        #size-cells = <2>;
                        ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;


While scrubbing on the uboot source, I found a sort of block of registers dedicated to communicate with
the secure firmware :
AO_SEC_REG0							0x140
AO_SEC_REG1							0x144
AO_SEC_REG2							0x148
AO_SEC_TMODE_PWD0						0x160
AO_SEC_TMODE_PWD1						0x164
AO_SEC_TMODE_PWD2						0x168
AO_SEC_TMODE_PWD3						0x16C
AO_SEC_SCRATCH							0x17C
AO_SEC_JTAG_PWD0						0x180
AO_SEC_JTAG_PWD1						0x184
AO_SEC_JTAG_PWD2						0x188
AO_SEC_JTAG_PWD3						0x18C
AO_SEC_JTAG_SEC_CNTL						0x190
AO_SEC_JTAG_PWD_ADDR0						0x194
AO_SEC_JTAG_PWD_ADDR1						0x198
AO_SEC_JTAG_PWD_ADDR2						0x19C
AO_SEC_JTAG_PWD_ADDR3						0x1A0
AO_SEC_SHARED_AHB_SRAM_REG0_0					0x1C0
AO_SEC_SHARED_AHB_SRAM_REG0_1					0x1C4
AO_SEC_SHARED_AHB_SRAM_REG0_2					0x1C8
AO_SEC_SHARED_AHB_SRAM_REG1_0					0x1CC
AO_SEC_SHARED_AHB_SRAM_REG1_1					0x1D0
AO_SEC_SHARED_AHB_SRAM_REG1_2					0x1D4
AO_SEC_SHARED_AHB_SRAM_REG2_0					0x1D8
AO_SEC_SHARED_AHB_SRAM_REG2_1					0x1DC
AO_SEC_SHARED_AHB_SRAM_REG2_2					0x1E0
AO_SEC_SHARED_AHB_SRAM_REG3_0					0x1E4
AO_SEC_SHARED_AHB_SRAM_REG3_1					0x1E8
AO_SEC_SHARED_AHB_SRAM_REG3_2					0x1EC
AO_SEC_AO_AHB_SRAM_REG0_0					0x1F0
AO_SEC_AO_AHB_SRAM_REG0_1					0x1F4
AO_SEC_AO_AHB_SRAM_REG1_0					0x1F8
AO_SEC_AO_AHB_SRAM_REG1_1					0x1FC
AO_SEC_SD_CFG8							0x220
AO_SEC_SD_CFG9							0x224
AO_SEC_SD_CFG10							0x228
AO_SEC_SD_CFG11							0x22C
AO_SEC_SD_CFG12							0x230
AO_SEC_SD_CFG13							0x234
AO_SEC_SD_CFG14							0x238
AO_SEC_SD_CFG15							0x23C
AO_SEC_GP_CFG0							0x240
AO_SEC_GP_CFG1							0x244
AO_SEC_GP_CFG2							0x248
AO_SEC_GP_CFG3							0x24C
AO_SEC_GP_CFG4							0x250
AO_SEC_GP_CFG5							0x254
AO_SEC_GP_CFG6							0x258
AO_SEC_GP_CFG7							0x25C
AO_SEC_GP_CFG8							0x260
AO_SEC_GP_CFG9							0x264
AO_SEC_GP_CFG10							0x268
AO_SEC_GP_CFG11							0x26C
AO_SEC_GP_CFG12							0x270
AO_SEC_GP_CFG13							0x274
AO_SEC_GP_CFG14							0x278
AO_SEC_GP_CFG15							0x27C


As you see, the register we use here is AO_SEC_SD_CFG8...

Should I define all this block as simple-mfd and refer to it as a regmap ?

aobus: aobus at c8100000 {
	compatible = "simple-bus";
	reg = <0x0 0xc8100000 0x0 0x100000>;
	#address-cells = <2>;
	#size-cells = <2>;
	ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;

	ao_secure: ao-secure at 140 {
		compatible = "amlogic,meson-gx-ao-secure", "simple-mfd";
		reg = <0x0 0x140 0x0 0x140>;
	};
};

chipid {
	compatible = "amlogic,meson-gx-socinfo";
	ao-secure = <&ao_secure>;
	chip-info-reg = <0xe0>;
};

Neil

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-04-04 12:26             ` Rob Herring
  0 siblings, 0 replies; 37+ messages in thread
From: Rob Herring @ 2017-04-04 12:26 UTC (permalink / raw)
  To: Neil Armstrong
  Cc: Arnd Bergmann, Kevin Hilman, Carlo Caione, linux-amlogic,
	Linux ARM, Linux Kernel Mailing List, devicetree

On Tue, Apr 4, 2017 at 3:51 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> On 04/03/2017 06:34 PM, Rob Herring wrote:
>> On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
>>> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
>>>> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
>>>> <narmstrong@baylibre.com> wrote:
>>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>>
>>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>>> ---
>>>>>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>>>>>  1 file changed, 20 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>> index bfd5b55..b850985 100644
>>>>> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>> @@ -52,3 +52,23 @@ Board compatible values:
>>>>>    - "amlogic,q201" (Meson gxm s912)
>>>>>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>>>>>    - "nexbox,a1" (Meson gxm s912)
>>>>> +
>>>>> +Amlogic Meson GX SoCs Information
>>>>> +----------------------------------
>>>>> +
>>>>> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
>>>>> +package and revision information. If present, a device node for this register
>>>>> +should be added.
>>>>> +
>>>>> +Required properties:
>>>>> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
>>>>> +  - reg: Base address and length of the register block.
>>>>> +
>>>>> +Examples
>>>>> +--------
>>>>> +
>>>>> +       chipid@220 {
>>>>> +               compatible = "amlogic,meson-gx-socinfo";
>>>>> +               reg = <0x0 0x00220 0x0 0x4>;
>>>>> +       };
>>>>> +
>>>>
>>>> The register location would hint that this is in the middle of some block of
>>>> random registers, i.e. a syscon or some unrelated device.
>>>>
>>>> Are you sure that "socinfo" is the actual name of the IP block and that
>>>> it only has a single 32-bit register?
>>>>
>>>>      Arnd
>>>>
>>>
>>> Hi Arnd,
>>>
>>> I'm sorry I did not find any relevant registers in the docs or source code describing
>>> it in a specific block of registers, and no close enough register definitions either.
>>> They may be used by the secure firmware I imagine.
>>>
>>> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
>>> gives some details on the whole SoC and package, and socinfo seems better.
>>
>> A register at address 0x220 seems a bit strange (unless there's ranges
>> you're not showing), but ROM code at this address would be fairly
>> typical. And putting version information into the ROM is also common.
>>
>> Rob
>>
>
> Hi Rob.
>
> Indeed it's part of a larger range :
>                  aobus: aobus@c8100000 {
>                         compatible = "simple-bus";
>                         reg = <0x0 0xc8100000 0x0 0x100000>;
>                         #address-cells = <2>;
>                         #size-cells = <2>;
>                         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>
>
> While scrubbing on the uboot source, I found a sort of block of registers dedicated to communicate with
> the secure firmware :
> AO_SEC_REG0                                                     0x140
> AO_SEC_REG1                                                     0x144
> AO_SEC_REG2                                                     0x148
> AO_SEC_TMODE_PWD0                                               0x160
> AO_SEC_TMODE_PWD1                                               0x164
> AO_SEC_TMODE_PWD2                                               0x168
> AO_SEC_TMODE_PWD3                                               0x16C
> AO_SEC_SCRATCH                                                  0x17C
> AO_SEC_JTAG_PWD0                                                0x180
> AO_SEC_JTAG_PWD1                                                0x184
> AO_SEC_JTAG_PWD2                                                0x188
> AO_SEC_JTAG_PWD3                                                0x18C
> AO_SEC_JTAG_SEC_CNTL                                            0x190
> AO_SEC_JTAG_PWD_ADDR0                                           0x194
> AO_SEC_JTAG_PWD_ADDR1                                           0x198
> AO_SEC_JTAG_PWD_ADDR2                                           0x19C
> AO_SEC_JTAG_PWD_ADDR3                                           0x1A0
> AO_SEC_SHARED_AHB_SRAM_REG0_0                                   0x1C0
> AO_SEC_SHARED_AHB_SRAM_REG0_1                                   0x1C4
> AO_SEC_SHARED_AHB_SRAM_REG0_2                                   0x1C8
> AO_SEC_SHARED_AHB_SRAM_REG1_0                                   0x1CC
> AO_SEC_SHARED_AHB_SRAM_REG1_1                                   0x1D0
> AO_SEC_SHARED_AHB_SRAM_REG1_2                                   0x1D4
> AO_SEC_SHARED_AHB_SRAM_REG2_0                                   0x1D8
> AO_SEC_SHARED_AHB_SRAM_REG2_1                                   0x1DC
> AO_SEC_SHARED_AHB_SRAM_REG2_2                                   0x1E0
> AO_SEC_SHARED_AHB_SRAM_REG3_0                                   0x1E4
> AO_SEC_SHARED_AHB_SRAM_REG3_1                                   0x1E8
> AO_SEC_SHARED_AHB_SRAM_REG3_2                                   0x1EC
> AO_SEC_AO_AHB_SRAM_REG0_0                                       0x1F0
> AO_SEC_AO_AHB_SRAM_REG0_1                                       0x1F4
> AO_SEC_AO_AHB_SRAM_REG1_0                                       0x1F8
> AO_SEC_AO_AHB_SRAM_REG1_1                                       0x1FC
> AO_SEC_SD_CFG8                                                  0x220
> AO_SEC_SD_CFG9                                                  0x224
> AO_SEC_SD_CFG10                                                 0x228
> AO_SEC_SD_CFG11                                                 0x22C
> AO_SEC_SD_CFG12                                                 0x230
> AO_SEC_SD_CFG13                                                 0x234
> AO_SEC_SD_CFG14                                                 0x238
> AO_SEC_SD_CFG15                                                 0x23C
> AO_SEC_GP_CFG0                                                  0x240
> AO_SEC_GP_CFG1                                                  0x244
> AO_SEC_GP_CFG2                                                  0x248
> AO_SEC_GP_CFG3                                                  0x24C
> AO_SEC_GP_CFG4                                                  0x250
> AO_SEC_GP_CFG5                                                  0x254
> AO_SEC_GP_CFG6                                                  0x258
> AO_SEC_GP_CFG7                                                  0x25C
> AO_SEC_GP_CFG8                                                  0x260
> AO_SEC_GP_CFG9                                                  0x264
> AO_SEC_GP_CFG10                                                 0x268
> AO_SEC_GP_CFG11                                                 0x26C
> AO_SEC_GP_CFG12                                                 0x270
> AO_SEC_GP_CFG13                                                 0x274
> AO_SEC_GP_CFG14                                                 0x278
> AO_SEC_GP_CFG15                                                 0x27C
>
>
> As you see, the register we use here is AO_SEC_SD_CFG8...
>
> Should I define all this block as simple-mfd and refer to it as a regmap ?
>
> aobus: aobus@c8100000 {
>         compatible = "simple-bus";
>         reg = <0x0 0xc8100000 0x0 0x100000>;
>         #address-cells = <2>;
>         #size-cells = <2>;
>         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>
>         ao_secure: ao-secure@140 {
>                 compatible = "amlogic,meson-gx-ao-secure", "simple-mfd";
>                 reg = <0x0 0x140 0x0 0x140>;
>         };
> };
>
> chipid {
>         compatible = "amlogic,meson-gx-socinfo";
>         ao-secure = <&ao_secure>;
>         chip-info-reg = <0xe0>;

Why even divide it up further in DT? IMO, describing single
registers/address in DT is too fine grained.

Rob

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-04-04 12:26             ` Rob Herring
  0 siblings, 0 replies; 37+ messages in thread
From: Rob Herring @ 2017-04-04 12:26 UTC (permalink / raw)
  To: Neil Armstrong
  Cc: Arnd Bergmann, Kevin Hilman, Carlo Caione,
	linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Linux ARM,
	Linux Kernel Mailing List, devicetree-u79uwXL29TY76Z2rM5mHXA

On Tue, Apr 4, 2017 at 3:51 AM, Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> On 04/03/2017 06:34 PM, Rob Herring wrote:
>> On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
>>> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
>>>> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
>>>> <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
>>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>>
>>>>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>>>> ---
>>>>>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>>>>>  1 file changed, 20 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>> index bfd5b55..b850985 100644
>>>>> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>> @@ -52,3 +52,23 @@ Board compatible values:
>>>>>    - "amlogic,q201" (Meson gxm s912)
>>>>>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>>>>>    - "nexbox,a1" (Meson gxm s912)
>>>>> +
>>>>> +Amlogic Meson GX SoCs Information
>>>>> +----------------------------------
>>>>> +
>>>>> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
>>>>> +package and revision information. If present, a device node for this register
>>>>> +should be added.
>>>>> +
>>>>> +Required properties:
>>>>> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
>>>>> +  - reg: Base address and length of the register block.
>>>>> +
>>>>> +Examples
>>>>> +--------
>>>>> +
>>>>> +       chipid@220 {
>>>>> +               compatible = "amlogic,meson-gx-socinfo";
>>>>> +               reg = <0x0 0x00220 0x0 0x4>;
>>>>> +       };
>>>>> +
>>>>
>>>> The register location would hint that this is in the middle of some block of
>>>> random registers, i.e. a syscon or some unrelated device.
>>>>
>>>> Are you sure that "socinfo" is the actual name of the IP block and that
>>>> it only has a single 32-bit register?
>>>>
>>>>      Arnd
>>>>
>>>
>>> Hi Arnd,
>>>
>>> I'm sorry I did not find any relevant registers in the docs or source code describing
>>> it in a specific block of registers, and no close enough register definitions either.
>>> They may be used by the secure firmware I imagine.
>>>
>>> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
>>> gives some details on the whole SoC and package, and socinfo seems better.
>>
>> A register at address 0x220 seems a bit strange (unless there's ranges
>> you're not showing), but ROM code at this address would be fairly
>> typical. And putting version information into the ROM is also common.
>>
>> Rob
>>
>
> Hi Rob.
>
> Indeed it's part of a larger range :
>                  aobus: aobus@c8100000 {
>                         compatible = "simple-bus";
>                         reg = <0x0 0xc8100000 0x0 0x100000>;
>                         #address-cells = <2>;
>                         #size-cells = <2>;
>                         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>
>
> While scrubbing on the uboot source, I found a sort of block of registers dedicated to communicate with
> the secure firmware :
> AO_SEC_REG0                                                     0x140
> AO_SEC_REG1                                                     0x144
> AO_SEC_REG2                                                     0x148
> AO_SEC_TMODE_PWD0                                               0x160
> AO_SEC_TMODE_PWD1                                               0x164
> AO_SEC_TMODE_PWD2                                               0x168
> AO_SEC_TMODE_PWD3                                               0x16C
> AO_SEC_SCRATCH                                                  0x17C
> AO_SEC_JTAG_PWD0                                                0x180
> AO_SEC_JTAG_PWD1                                                0x184
> AO_SEC_JTAG_PWD2                                                0x188
> AO_SEC_JTAG_PWD3                                                0x18C
> AO_SEC_JTAG_SEC_CNTL                                            0x190
> AO_SEC_JTAG_PWD_ADDR0                                           0x194
> AO_SEC_JTAG_PWD_ADDR1                                           0x198
> AO_SEC_JTAG_PWD_ADDR2                                           0x19C
> AO_SEC_JTAG_PWD_ADDR3                                           0x1A0
> AO_SEC_SHARED_AHB_SRAM_REG0_0                                   0x1C0
> AO_SEC_SHARED_AHB_SRAM_REG0_1                                   0x1C4
> AO_SEC_SHARED_AHB_SRAM_REG0_2                                   0x1C8
> AO_SEC_SHARED_AHB_SRAM_REG1_0                                   0x1CC
> AO_SEC_SHARED_AHB_SRAM_REG1_1                                   0x1D0
> AO_SEC_SHARED_AHB_SRAM_REG1_2                                   0x1D4
> AO_SEC_SHARED_AHB_SRAM_REG2_0                                   0x1D8
> AO_SEC_SHARED_AHB_SRAM_REG2_1                                   0x1DC
> AO_SEC_SHARED_AHB_SRAM_REG2_2                                   0x1E0
> AO_SEC_SHARED_AHB_SRAM_REG3_0                                   0x1E4
> AO_SEC_SHARED_AHB_SRAM_REG3_1                                   0x1E8
> AO_SEC_SHARED_AHB_SRAM_REG3_2                                   0x1EC
> AO_SEC_AO_AHB_SRAM_REG0_0                                       0x1F0
> AO_SEC_AO_AHB_SRAM_REG0_1                                       0x1F4
> AO_SEC_AO_AHB_SRAM_REG1_0                                       0x1F8
> AO_SEC_AO_AHB_SRAM_REG1_1                                       0x1FC
> AO_SEC_SD_CFG8                                                  0x220
> AO_SEC_SD_CFG9                                                  0x224
> AO_SEC_SD_CFG10                                                 0x228
> AO_SEC_SD_CFG11                                                 0x22C
> AO_SEC_SD_CFG12                                                 0x230
> AO_SEC_SD_CFG13                                                 0x234
> AO_SEC_SD_CFG14                                                 0x238
> AO_SEC_SD_CFG15                                                 0x23C
> AO_SEC_GP_CFG0                                                  0x240
> AO_SEC_GP_CFG1                                                  0x244
> AO_SEC_GP_CFG2                                                  0x248
> AO_SEC_GP_CFG3                                                  0x24C
> AO_SEC_GP_CFG4                                                  0x250
> AO_SEC_GP_CFG5                                                  0x254
> AO_SEC_GP_CFG6                                                  0x258
> AO_SEC_GP_CFG7                                                  0x25C
> AO_SEC_GP_CFG8                                                  0x260
> AO_SEC_GP_CFG9                                                  0x264
> AO_SEC_GP_CFG10                                                 0x268
> AO_SEC_GP_CFG11                                                 0x26C
> AO_SEC_GP_CFG12                                                 0x270
> AO_SEC_GP_CFG13                                                 0x274
> AO_SEC_GP_CFG14                                                 0x278
> AO_SEC_GP_CFG15                                                 0x27C
>
>
> As you see, the register we use here is AO_SEC_SD_CFG8...
>
> Should I define all this block as simple-mfd and refer to it as a regmap ?
>
> aobus: aobus@c8100000 {
>         compatible = "simple-bus";
>         reg = <0x0 0xc8100000 0x0 0x100000>;
>         #address-cells = <2>;
>         #size-cells = <2>;
>         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>
>         ao_secure: ao-secure@140 {
>                 compatible = "amlogic,meson-gx-ao-secure", "simple-mfd";
>                 reg = <0x0 0x140 0x0 0x140>;
>         };
> };
>
> chipid {
>         compatible = "amlogic,meson-gx-socinfo";
>         ao-secure = <&ao_secure>;
>         chip-info-reg = <0xe0>;

Why even divide it up further in DT? IMO, describing single
registers/address in DT is too fine grained.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-04-04 12:26             ` Rob Herring
  0 siblings, 0 replies; 37+ messages in thread
From: Rob Herring @ 2017-04-04 12:26 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Apr 4, 2017 at 3:51 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> On 04/03/2017 06:34 PM, Rob Herring wrote:
>> On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
>>> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
>>>> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
>>>> <narmstrong@baylibre.com> wrote:
>>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>>
>>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>>> ---
>>>>>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>>>>>  1 file changed, 20 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>> index bfd5b55..b850985 100644
>>>>> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>> @@ -52,3 +52,23 @@ Board compatible values:
>>>>>    - "amlogic,q201" (Meson gxm s912)
>>>>>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>>>>>    - "nexbox,a1" (Meson gxm s912)
>>>>> +
>>>>> +Amlogic Meson GX SoCs Information
>>>>> +----------------------------------
>>>>> +
>>>>> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
>>>>> +package and revision information. If present, a device node for this register
>>>>> +should be added.
>>>>> +
>>>>> +Required properties:
>>>>> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
>>>>> +  - reg: Base address and length of the register block.
>>>>> +
>>>>> +Examples
>>>>> +--------
>>>>> +
>>>>> +       chipid at 220 {
>>>>> +               compatible = "amlogic,meson-gx-socinfo";
>>>>> +               reg = <0x0 0x00220 0x0 0x4>;
>>>>> +       };
>>>>> +
>>>>
>>>> The register location would hint that this is in the middle of some block of
>>>> random registers, i.e. a syscon or some unrelated device.
>>>>
>>>> Are you sure that "socinfo" is the actual name of the IP block and that
>>>> it only has a single 32-bit register?
>>>>
>>>>      Arnd
>>>>
>>>
>>> Hi Arnd,
>>>
>>> I'm sorry I did not find any relevant registers in the docs or source code describing
>>> it in a specific block of registers, and no close enough register definitions either.
>>> They may be used by the secure firmware I imagine.
>>>
>>> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
>>> gives some details on the whole SoC and package, and socinfo seems better.
>>
>> A register at address 0x220 seems a bit strange (unless there's ranges
>> you're not showing), but ROM code at this address would be fairly
>> typical. And putting version information into the ROM is also common.
>>
>> Rob
>>
>
> Hi Rob.
>
> Indeed it's part of a larger range :
>                  aobus: aobus at c8100000 {
>                         compatible = "simple-bus";
>                         reg = <0x0 0xc8100000 0x0 0x100000>;
>                         #address-cells = <2>;
>                         #size-cells = <2>;
>                         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>
>
> While scrubbing on the uboot source, I found a sort of block of registers dedicated to communicate with
> the secure firmware :
> AO_SEC_REG0                                                     0x140
> AO_SEC_REG1                                                     0x144
> AO_SEC_REG2                                                     0x148
> AO_SEC_TMODE_PWD0                                               0x160
> AO_SEC_TMODE_PWD1                                               0x164
> AO_SEC_TMODE_PWD2                                               0x168
> AO_SEC_TMODE_PWD3                                               0x16C
> AO_SEC_SCRATCH                                                  0x17C
> AO_SEC_JTAG_PWD0                                                0x180
> AO_SEC_JTAG_PWD1                                                0x184
> AO_SEC_JTAG_PWD2                                                0x188
> AO_SEC_JTAG_PWD3                                                0x18C
> AO_SEC_JTAG_SEC_CNTL                                            0x190
> AO_SEC_JTAG_PWD_ADDR0                                           0x194
> AO_SEC_JTAG_PWD_ADDR1                                           0x198
> AO_SEC_JTAG_PWD_ADDR2                                           0x19C
> AO_SEC_JTAG_PWD_ADDR3                                           0x1A0
> AO_SEC_SHARED_AHB_SRAM_REG0_0                                   0x1C0
> AO_SEC_SHARED_AHB_SRAM_REG0_1                                   0x1C4
> AO_SEC_SHARED_AHB_SRAM_REG0_2                                   0x1C8
> AO_SEC_SHARED_AHB_SRAM_REG1_0                                   0x1CC
> AO_SEC_SHARED_AHB_SRAM_REG1_1                                   0x1D0
> AO_SEC_SHARED_AHB_SRAM_REG1_2                                   0x1D4
> AO_SEC_SHARED_AHB_SRAM_REG2_0                                   0x1D8
> AO_SEC_SHARED_AHB_SRAM_REG2_1                                   0x1DC
> AO_SEC_SHARED_AHB_SRAM_REG2_2                                   0x1E0
> AO_SEC_SHARED_AHB_SRAM_REG3_0                                   0x1E4
> AO_SEC_SHARED_AHB_SRAM_REG3_1                                   0x1E8
> AO_SEC_SHARED_AHB_SRAM_REG3_2                                   0x1EC
> AO_SEC_AO_AHB_SRAM_REG0_0                                       0x1F0
> AO_SEC_AO_AHB_SRAM_REG0_1                                       0x1F4
> AO_SEC_AO_AHB_SRAM_REG1_0                                       0x1F8
> AO_SEC_AO_AHB_SRAM_REG1_1                                       0x1FC
> AO_SEC_SD_CFG8                                                  0x220
> AO_SEC_SD_CFG9                                                  0x224
> AO_SEC_SD_CFG10                                                 0x228
> AO_SEC_SD_CFG11                                                 0x22C
> AO_SEC_SD_CFG12                                                 0x230
> AO_SEC_SD_CFG13                                                 0x234
> AO_SEC_SD_CFG14                                                 0x238
> AO_SEC_SD_CFG15                                                 0x23C
> AO_SEC_GP_CFG0                                                  0x240
> AO_SEC_GP_CFG1                                                  0x244
> AO_SEC_GP_CFG2                                                  0x248
> AO_SEC_GP_CFG3                                                  0x24C
> AO_SEC_GP_CFG4                                                  0x250
> AO_SEC_GP_CFG5                                                  0x254
> AO_SEC_GP_CFG6                                                  0x258
> AO_SEC_GP_CFG7                                                  0x25C
> AO_SEC_GP_CFG8                                                  0x260
> AO_SEC_GP_CFG9                                                  0x264
> AO_SEC_GP_CFG10                                                 0x268
> AO_SEC_GP_CFG11                                                 0x26C
> AO_SEC_GP_CFG12                                                 0x270
> AO_SEC_GP_CFG13                                                 0x274
> AO_SEC_GP_CFG14                                                 0x278
> AO_SEC_GP_CFG15                                                 0x27C
>
>
> As you see, the register we use here is AO_SEC_SD_CFG8...
>
> Should I define all this block as simple-mfd and refer to it as a regmap ?
>
> aobus: aobus at c8100000 {
>         compatible = "simple-bus";
>         reg = <0x0 0xc8100000 0x0 0x100000>;
>         #address-cells = <2>;
>         #size-cells = <2>;
>         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>
>         ao_secure: ao-secure at 140 {
>                 compatible = "amlogic,meson-gx-ao-secure", "simple-mfd";
>                 reg = <0x0 0x140 0x0 0x140>;
>         };
> };
>
> chipid {
>         compatible = "amlogic,meson-gx-socinfo";
>         ao-secure = <&ao_secure>;
>         chip-info-reg = <0xe0>;

Why even divide it up further in DT? IMO, describing single
registers/address in DT is too fine grained.

Rob

^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-04-04 12:26             ` Rob Herring
  0 siblings, 0 replies; 37+ messages in thread
From: Rob Herring @ 2017-04-04 12:26 UTC (permalink / raw)
  To: linus-amlogic

On Tue, Apr 4, 2017 at 3:51 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> On 04/03/2017 06:34 PM, Rob Herring wrote:
>> On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
>>> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
>>>> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
>>>> <narmstrong@baylibre.com> wrote:
>>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>>
>>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>>> ---
>>>>>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>>>>>  1 file changed, 20 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>> index bfd5b55..b850985 100644
>>>>> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>> @@ -52,3 +52,23 @@ Board compatible values:
>>>>>    - "amlogic,q201" (Meson gxm s912)
>>>>>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>>>>>    - "nexbox,a1" (Meson gxm s912)
>>>>> +
>>>>> +Amlogic Meson GX SoCs Information
>>>>> +----------------------------------
>>>>> +
>>>>> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
>>>>> +package and revision information. If present, a device node for this register
>>>>> +should be added.
>>>>> +
>>>>> +Required properties:
>>>>> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
>>>>> +  - reg: Base address and length of the register block.
>>>>> +
>>>>> +Examples
>>>>> +--------
>>>>> +
>>>>> +       chipid at 220 {
>>>>> +               compatible = "amlogic,meson-gx-socinfo";
>>>>> +               reg = <0x0 0x00220 0x0 0x4>;
>>>>> +       };
>>>>> +
>>>>
>>>> The register location would hint that this is in the middle of some block of
>>>> random registers, i.e. a syscon or some unrelated device.
>>>>
>>>> Are you sure that "socinfo" is the actual name of the IP block and that
>>>> it only has a single 32-bit register?
>>>>
>>>>      Arnd
>>>>
>>>
>>> Hi Arnd,
>>>
>>> I'm sorry I did not find any relevant registers in the docs or source code describing
>>> it in a specific block of registers, and no close enough register definitions either.
>>> They may be used by the secure firmware I imagine.
>>>
>>> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
>>> gives some details on the whole SoC and package, and socinfo seems better.
>>
>> A register at address 0x220 seems a bit strange (unless there's ranges
>> you're not showing), but ROM code at this address would be fairly
>> typical. And putting version information into the ROM is also common.
>>
>> Rob
>>
>
> Hi Rob.
>
> Indeed it's part of a larger range :
>                  aobus: aobus at c8100000 {
>                         compatible = "simple-bus";
>                         reg = <0x0 0xc8100000 0x0 0x100000>;
>                         #address-cells = <2>;
>                         #size-cells = <2>;
>                         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>
>
> While scrubbing on the uboot source, I found a sort of block of registers dedicated to communicate with
> the secure firmware :
> AO_SEC_REG0                                                     0x140
> AO_SEC_REG1                                                     0x144
> AO_SEC_REG2                                                     0x148
> AO_SEC_TMODE_PWD0                                               0x160
> AO_SEC_TMODE_PWD1                                               0x164
> AO_SEC_TMODE_PWD2                                               0x168
> AO_SEC_TMODE_PWD3                                               0x16C
> AO_SEC_SCRATCH                                                  0x17C
> AO_SEC_JTAG_PWD0                                                0x180
> AO_SEC_JTAG_PWD1                                                0x184
> AO_SEC_JTAG_PWD2                                                0x188
> AO_SEC_JTAG_PWD3                                                0x18C
> AO_SEC_JTAG_SEC_CNTL                                            0x190
> AO_SEC_JTAG_PWD_ADDR0                                           0x194
> AO_SEC_JTAG_PWD_ADDR1                                           0x198
> AO_SEC_JTAG_PWD_ADDR2                                           0x19C
> AO_SEC_JTAG_PWD_ADDR3                                           0x1A0
> AO_SEC_SHARED_AHB_SRAM_REG0_0                                   0x1C0
> AO_SEC_SHARED_AHB_SRAM_REG0_1                                   0x1C4
> AO_SEC_SHARED_AHB_SRAM_REG0_2                                   0x1C8
> AO_SEC_SHARED_AHB_SRAM_REG1_0                                   0x1CC
> AO_SEC_SHARED_AHB_SRAM_REG1_1                                   0x1D0
> AO_SEC_SHARED_AHB_SRAM_REG1_2                                   0x1D4
> AO_SEC_SHARED_AHB_SRAM_REG2_0                                   0x1D8
> AO_SEC_SHARED_AHB_SRAM_REG2_1                                   0x1DC
> AO_SEC_SHARED_AHB_SRAM_REG2_2                                   0x1E0
> AO_SEC_SHARED_AHB_SRAM_REG3_0                                   0x1E4
> AO_SEC_SHARED_AHB_SRAM_REG3_1                                   0x1E8
> AO_SEC_SHARED_AHB_SRAM_REG3_2                                   0x1EC
> AO_SEC_AO_AHB_SRAM_REG0_0                                       0x1F0
> AO_SEC_AO_AHB_SRAM_REG0_1                                       0x1F4
> AO_SEC_AO_AHB_SRAM_REG1_0                                       0x1F8
> AO_SEC_AO_AHB_SRAM_REG1_1                                       0x1FC
> AO_SEC_SD_CFG8                                                  0x220
> AO_SEC_SD_CFG9                                                  0x224
> AO_SEC_SD_CFG10                                                 0x228
> AO_SEC_SD_CFG11                                                 0x22C
> AO_SEC_SD_CFG12                                                 0x230
> AO_SEC_SD_CFG13                                                 0x234
> AO_SEC_SD_CFG14                                                 0x238
> AO_SEC_SD_CFG15                                                 0x23C
> AO_SEC_GP_CFG0                                                  0x240
> AO_SEC_GP_CFG1                                                  0x244
> AO_SEC_GP_CFG2                                                  0x248
> AO_SEC_GP_CFG3                                                  0x24C
> AO_SEC_GP_CFG4                                                  0x250
> AO_SEC_GP_CFG5                                                  0x254
> AO_SEC_GP_CFG6                                                  0x258
> AO_SEC_GP_CFG7                                                  0x25C
> AO_SEC_GP_CFG8                                                  0x260
> AO_SEC_GP_CFG9                                                  0x264
> AO_SEC_GP_CFG10                                                 0x268
> AO_SEC_GP_CFG11                                                 0x26C
> AO_SEC_GP_CFG12                                                 0x270
> AO_SEC_GP_CFG13                                                 0x274
> AO_SEC_GP_CFG14                                                 0x278
> AO_SEC_GP_CFG15                                                 0x27C
>
>
> As you see, the register we use here is AO_SEC_SD_CFG8...
>
> Should I define all this block as simple-mfd and refer to it as a regmap ?
>
> aobus: aobus at c8100000 {
>         compatible = "simple-bus";
>         reg = <0x0 0xc8100000 0x0 0x100000>;
>         #address-cells = <2>;
>         #size-cells = <2>;
>         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>
>         ao_secure: ao-secure at 140 {
>                 compatible = "amlogic,meson-gx-ao-secure", "simple-mfd";
>                 reg = <0x0 0x140 0x0 0x140>;
>         };
> };
>
> chipid {
>         compatible = "amlogic,meson-gx-socinfo";
>         ao-secure = <&ao_secure>;
>         chip-info-reg = <0xe0>;

Why even divide it up further in DT? IMO, describing single
registers/address in DT is too fine grained.

Rob

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-04-04 12:49               ` Neil Armstrong
  0 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-04-04 12:49 UTC (permalink / raw)
  To: Rob Herring
  Cc: Arnd Bergmann, Kevin Hilman, Carlo Caione, linux-amlogic,
	Linux ARM, Linux Kernel Mailing List, devicetree

On 04/04/2017 02:26 PM, Rob Herring wrote:
> On Tue, Apr 4, 2017 at 3:51 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>> On 04/03/2017 06:34 PM, Rob Herring wrote:
>>> On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
>>>> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
>>>>> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
>>>>> <narmstrong@baylibre.com> wrote:
>>>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>>>
>>>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>>>> ---
>>>>>>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>>>>>>  1 file changed, 20 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>> index bfd5b55..b850985 100644
>>>>>> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>> @@ -52,3 +52,23 @@ Board compatible values:
>>>>>>    - "amlogic,q201" (Meson gxm s912)
>>>>>>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>>>>>>    - "nexbox,a1" (Meson gxm s912)
>>>>>> +
>>>>>> +Amlogic Meson GX SoCs Information
>>>>>> +----------------------------------
>>>>>> +
>>>>>> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
>>>>>> +package and revision information. If present, a device node for this register
>>>>>> +should be added.
>>>>>> +
>>>>>> +Required properties:
>>>>>> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
>>>>>> +  - reg: Base address and length of the register block.
>>>>>> +
>>>>>> +Examples
>>>>>> +--------
>>>>>> +
>>>>>> +       chipid@220 {
>>>>>> +               compatible = "amlogic,meson-gx-socinfo";
>>>>>> +               reg = <0x0 0x00220 0x0 0x4>;
>>>>>> +       };
>>>>>> +
>>>>>
>>>>> The register location would hint that this is in the middle of some block of
>>>>> random registers, i.e. a syscon or some unrelated device.
>>>>>
>>>>> Are you sure that "socinfo" is the actual name of the IP block and that
>>>>> it only has a single 32-bit register?
>>>>>
>>>>>      Arnd
>>>>>
>>>>
>>>> Hi Arnd,
>>>>
>>>> I'm sorry I did not find any relevant registers in the docs or source code describing
>>>> it in a specific block of registers, and no close enough register definitions either.
>>>> They may be used by the secure firmware I imagine.
>>>>
>>>> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
>>>> gives some details on the whole SoC and package, and socinfo seems better.
>>>
>>> A register at address 0x220 seems a bit strange (unless there's ranges
>>> you're not showing), but ROM code at this address would be fairly
>>> typical. And putting version information into the ROM is also common.
>>>
>>> Rob
>>>
>>
>> Hi Rob.
>>
>> Indeed it's part of a larger range :
>>                  aobus: aobus@c8100000 {
>>                         compatible = "simple-bus";
>>                         reg = <0x0 0xc8100000 0x0 0x100000>;
>>                         #address-cells = <2>;
>>                         #size-cells = <2>;
>>                         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>>
>>
>> While scrubbing on the uboot source, I found a sort of block of registers dedicated to communicate with
>> the secure firmware :
>> AO_SEC_REG0                                                     0x140
>> AO_SEC_REG1                                                     0x144
>> AO_SEC_REG2                                                     0x148
>> AO_SEC_TMODE_PWD0                                               0x160
>> AO_SEC_TMODE_PWD1                                               0x164
>> AO_SEC_TMODE_PWD2                                               0x168
>> AO_SEC_TMODE_PWD3                                               0x16C
>> AO_SEC_SCRATCH                                                  0x17C
>> AO_SEC_JTAG_PWD0                                                0x180
>> AO_SEC_JTAG_PWD1                                                0x184
>> AO_SEC_JTAG_PWD2                                                0x188
>> AO_SEC_JTAG_PWD3                                                0x18C
>> AO_SEC_JTAG_SEC_CNTL                                            0x190
>> AO_SEC_JTAG_PWD_ADDR0                                           0x194
>> AO_SEC_JTAG_PWD_ADDR1                                           0x198
>> AO_SEC_JTAG_PWD_ADDR2                                           0x19C
>> AO_SEC_JTAG_PWD_ADDR3                                           0x1A0
>> AO_SEC_SHARED_AHB_SRAM_REG0_0                                   0x1C0
>> AO_SEC_SHARED_AHB_SRAM_REG0_1                                   0x1C4
>> AO_SEC_SHARED_AHB_SRAM_REG0_2                                   0x1C8
>> AO_SEC_SHARED_AHB_SRAM_REG1_0                                   0x1CC
>> AO_SEC_SHARED_AHB_SRAM_REG1_1                                   0x1D0
>> AO_SEC_SHARED_AHB_SRAM_REG1_2                                   0x1D4
>> AO_SEC_SHARED_AHB_SRAM_REG2_0                                   0x1D8
>> AO_SEC_SHARED_AHB_SRAM_REG2_1                                   0x1DC
>> AO_SEC_SHARED_AHB_SRAM_REG2_2                                   0x1E0
>> AO_SEC_SHARED_AHB_SRAM_REG3_0                                   0x1E4
>> AO_SEC_SHARED_AHB_SRAM_REG3_1                                   0x1E8
>> AO_SEC_SHARED_AHB_SRAM_REG3_2                                   0x1EC
>> AO_SEC_AO_AHB_SRAM_REG0_0                                       0x1F0
>> AO_SEC_AO_AHB_SRAM_REG0_1                                       0x1F4
>> AO_SEC_AO_AHB_SRAM_REG1_0                                       0x1F8
>> AO_SEC_AO_AHB_SRAM_REG1_1                                       0x1FC
>> AO_SEC_SD_CFG8                                                  0x220
>> AO_SEC_SD_CFG9                                                  0x224
>> AO_SEC_SD_CFG10                                                 0x228
>> AO_SEC_SD_CFG11                                                 0x22C
>> AO_SEC_SD_CFG12                                                 0x230
>> AO_SEC_SD_CFG13                                                 0x234
>> AO_SEC_SD_CFG14                                                 0x238
>> AO_SEC_SD_CFG15                                                 0x23C
>> AO_SEC_GP_CFG0                                                  0x240
>> AO_SEC_GP_CFG1                                                  0x244
>> AO_SEC_GP_CFG2                                                  0x248
>> AO_SEC_GP_CFG3                                                  0x24C
>> AO_SEC_GP_CFG4                                                  0x250
>> AO_SEC_GP_CFG5                                                  0x254
>> AO_SEC_GP_CFG6                                                  0x258
>> AO_SEC_GP_CFG7                                                  0x25C
>> AO_SEC_GP_CFG8                                                  0x260
>> AO_SEC_GP_CFG9                                                  0x264
>> AO_SEC_GP_CFG10                                                 0x268
>> AO_SEC_GP_CFG11                                                 0x26C
>> AO_SEC_GP_CFG12                                                 0x270
>> AO_SEC_GP_CFG13                                                 0x274
>> AO_SEC_GP_CFG14                                                 0x278
>> AO_SEC_GP_CFG15                                                 0x27C
>>
>>
>> As you see, the register we use here is AO_SEC_SD_CFG8...
>>
>> Should I define all this block as simple-mfd and refer to it as a regmap ?
>>
>> aobus: aobus@c8100000 {
>>         compatible = "simple-bus";
>>         reg = <0x0 0xc8100000 0x0 0x100000>;
>>         #address-cells = <2>;
>>         #size-cells = <2>;
>>         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>>
>>         ao_secure: ao-secure@140 {
>>                 compatible = "amlogic,meson-gx-ao-secure", "simple-mfd";
>>                 reg = <0x0 0x140 0x0 0x140>;
>>         };
>> };
>>
>> chipid {
>>         compatible = "amlogic,meson-gx-socinfo";
>>         ao-secure = <&ao_secure>;
>>         chip-info-reg = <0xe0>;
> 
> Why even divide it up further in DT? IMO, describing single
> registers/address in DT is too fine grained.
> 
> Rob
> 

Rob, I don't get it.

Maybe something like that ?

aobus: aobus@c8100000 {
        compatible = "simple-bus";
        reg = <0x0 0xc8100000 0x0 0x100000>;
        #address-cells = <2>;
        #size-cells = <2>;
        ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;

        ao_secure: ao-secure@140 {
                compatible = "amlogic,meson-gx-ao-secure", "simple-mfd", "simple-bus";
                reg = <0x0 0x140 0x0 0x140>;
		#address-cells = <1>;
		#size-cells = <1>;

		chipid@e0 {
        		compatible = "amlogic,meson-gx-socinfo";
			reg = <0xe0 0x4>;
        	};
	};
};

Concerning the fine graining, I'm sorry but the actual information comes from a single register here...

Neil

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-04-04 12:49               ` Neil Armstrong
  0 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-04-04 12:49 UTC (permalink / raw)
  To: Rob Herring
  Cc: Arnd Bergmann, Kevin Hilman, Carlo Caione,
	linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Linux ARM,
	Linux Kernel Mailing List, devicetree-u79uwXL29TY76Z2rM5mHXA

On 04/04/2017 02:26 PM, Rob Herring wrote:
> On Tue, Apr 4, 2017 at 3:51 AM, Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
>> On 04/03/2017 06:34 PM, Rob Herring wrote:
>>> On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
>>>> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
>>>>> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
>>>>> <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
>>>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>>>
>>>>>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>>>>> ---
>>>>>>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>>>>>>  1 file changed, 20 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>> index bfd5b55..b850985 100644
>>>>>> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>> @@ -52,3 +52,23 @@ Board compatible values:
>>>>>>    - "amlogic,q201" (Meson gxm s912)
>>>>>>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>>>>>>    - "nexbox,a1" (Meson gxm s912)
>>>>>> +
>>>>>> +Amlogic Meson GX SoCs Information
>>>>>> +----------------------------------
>>>>>> +
>>>>>> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
>>>>>> +package and revision information. If present, a device node for this register
>>>>>> +should be added.
>>>>>> +
>>>>>> +Required properties:
>>>>>> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
>>>>>> +  - reg: Base address and length of the register block.
>>>>>> +
>>>>>> +Examples
>>>>>> +--------
>>>>>> +
>>>>>> +       chipid@220 {
>>>>>> +               compatible = "amlogic,meson-gx-socinfo";
>>>>>> +               reg = <0x0 0x00220 0x0 0x4>;
>>>>>> +       };
>>>>>> +
>>>>>
>>>>> The register location would hint that this is in the middle of some block of
>>>>> random registers, i.e. a syscon or some unrelated device.
>>>>>
>>>>> Are you sure that "socinfo" is the actual name of the IP block and that
>>>>> it only has a single 32-bit register?
>>>>>
>>>>>      Arnd
>>>>>
>>>>
>>>> Hi Arnd,
>>>>
>>>> I'm sorry I did not find any relevant registers in the docs or source code describing
>>>> it in a specific block of registers, and no close enough register definitions either.
>>>> They may be used by the secure firmware I imagine.
>>>>
>>>> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
>>>> gives some details on the whole SoC and package, and socinfo seems better.
>>>
>>> A register at address 0x220 seems a bit strange (unless there's ranges
>>> you're not showing), but ROM code at this address would be fairly
>>> typical. And putting version information into the ROM is also common.
>>>
>>> Rob
>>>
>>
>> Hi Rob.
>>
>> Indeed it's part of a larger range :
>>                  aobus: aobus@c8100000 {
>>                         compatible = "simple-bus";
>>                         reg = <0x0 0xc8100000 0x0 0x100000>;
>>                         #address-cells = <2>;
>>                         #size-cells = <2>;
>>                         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>>
>>
>> While scrubbing on the uboot source, I found a sort of block of registers dedicated to communicate with
>> the secure firmware :
>> AO_SEC_REG0                                                     0x140
>> AO_SEC_REG1                                                     0x144
>> AO_SEC_REG2                                                     0x148
>> AO_SEC_TMODE_PWD0                                               0x160
>> AO_SEC_TMODE_PWD1                                               0x164
>> AO_SEC_TMODE_PWD2                                               0x168
>> AO_SEC_TMODE_PWD3                                               0x16C
>> AO_SEC_SCRATCH                                                  0x17C
>> AO_SEC_JTAG_PWD0                                                0x180
>> AO_SEC_JTAG_PWD1                                                0x184
>> AO_SEC_JTAG_PWD2                                                0x188
>> AO_SEC_JTAG_PWD3                                                0x18C
>> AO_SEC_JTAG_SEC_CNTL                                            0x190
>> AO_SEC_JTAG_PWD_ADDR0                                           0x194
>> AO_SEC_JTAG_PWD_ADDR1                                           0x198
>> AO_SEC_JTAG_PWD_ADDR2                                           0x19C
>> AO_SEC_JTAG_PWD_ADDR3                                           0x1A0
>> AO_SEC_SHARED_AHB_SRAM_REG0_0                                   0x1C0
>> AO_SEC_SHARED_AHB_SRAM_REG0_1                                   0x1C4
>> AO_SEC_SHARED_AHB_SRAM_REG0_2                                   0x1C8
>> AO_SEC_SHARED_AHB_SRAM_REG1_0                                   0x1CC
>> AO_SEC_SHARED_AHB_SRAM_REG1_1                                   0x1D0
>> AO_SEC_SHARED_AHB_SRAM_REG1_2                                   0x1D4
>> AO_SEC_SHARED_AHB_SRAM_REG2_0                                   0x1D8
>> AO_SEC_SHARED_AHB_SRAM_REG2_1                                   0x1DC
>> AO_SEC_SHARED_AHB_SRAM_REG2_2                                   0x1E0
>> AO_SEC_SHARED_AHB_SRAM_REG3_0                                   0x1E4
>> AO_SEC_SHARED_AHB_SRAM_REG3_1                                   0x1E8
>> AO_SEC_SHARED_AHB_SRAM_REG3_2                                   0x1EC
>> AO_SEC_AO_AHB_SRAM_REG0_0                                       0x1F0
>> AO_SEC_AO_AHB_SRAM_REG0_1                                       0x1F4
>> AO_SEC_AO_AHB_SRAM_REG1_0                                       0x1F8
>> AO_SEC_AO_AHB_SRAM_REG1_1                                       0x1FC
>> AO_SEC_SD_CFG8                                                  0x220
>> AO_SEC_SD_CFG9                                                  0x224
>> AO_SEC_SD_CFG10                                                 0x228
>> AO_SEC_SD_CFG11                                                 0x22C
>> AO_SEC_SD_CFG12                                                 0x230
>> AO_SEC_SD_CFG13                                                 0x234
>> AO_SEC_SD_CFG14                                                 0x238
>> AO_SEC_SD_CFG15                                                 0x23C
>> AO_SEC_GP_CFG0                                                  0x240
>> AO_SEC_GP_CFG1                                                  0x244
>> AO_SEC_GP_CFG2                                                  0x248
>> AO_SEC_GP_CFG3                                                  0x24C
>> AO_SEC_GP_CFG4                                                  0x250
>> AO_SEC_GP_CFG5                                                  0x254
>> AO_SEC_GP_CFG6                                                  0x258
>> AO_SEC_GP_CFG7                                                  0x25C
>> AO_SEC_GP_CFG8                                                  0x260
>> AO_SEC_GP_CFG9                                                  0x264
>> AO_SEC_GP_CFG10                                                 0x268
>> AO_SEC_GP_CFG11                                                 0x26C
>> AO_SEC_GP_CFG12                                                 0x270
>> AO_SEC_GP_CFG13                                                 0x274
>> AO_SEC_GP_CFG14                                                 0x278
>> AO_SEC_GP_CFG15                                                 0x27C
>>
>>
>> As you see, the register we use here is AO_SEC_SD_CFG8...
>>
>> Should I define all this block as simple-mfd and refer to it as a regmap ?
>>
>> aobus: aobus@c8100000 {
>>         compatible = "simple-bus";
>>         reg = <0x0 0xc8100000 0x0 0x100000>;
>>         #address-cells = <2>;
>>         #size-cells = <2>;
>>         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>>
>>         ao_secure: ao-secure@140 {
>>                 compatible = "amlogic,meson-gx-ao-secure", "simple-mfd";
>>                 reg = <0x0 0x140 0x0 0x140>;
>>         };
>> };
>>
>> chipid {
>>         compatible = "amlogic,meson-gx-socinfo";
>>         ao-secure = <&ao_secure>;
>>         chip-info-reg = <0xe0>;
> 
> Why even divide it up further in DT? IMO, describing single
> registers/address in DT is too fine grained.
> 
> Rob
> 

Rob, I don't get it.

Maybe something like that ?

aobus: aobus@c8100000 {
        compatible = "simple-bus";
        reg = <0x0 0xc8100000 0x0 0x100000>;
        #address-cells = <2>;
        #size-cells = <2>;
        ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;

        ao_secure: ao-secure@140 {
                compatible = "amlogic,meson-gx-ao-secure", "simple-mfd", "simple-bus";
                reg = <0x0 0x140 0x0 0x140>;
		#address-cells = <1>;
		#size-cells = <1>;

		chipid@e0 {
        		compatible = "amlogic,meson-gx-socinfo";
			reg = <0xe0 0x4>;
        	};
	};
};

Concerning the fine graining, I'm sorry but the actual information comes from a single register here...

Neil
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-04-04 12:49               ` Neil Armstrong
  0 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-04-04 12:49 UTC (permalink / raw)
  To: linux-arm-kernel

On 04/04/2017 02:26 PM, Rob Herring wrote:
> On Tue, Apr 4, 2017 at 3:51 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>> On 04/03/2017 06:34 PM, Rob Herring wrote:
>>> On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
>>>> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
>>>>> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
>>>>> <narmstrong@baylibre.com> wrote:
>>>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>>>
>>>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>>>> ---
>>>>>>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>>>>>>  1 file changed, 20 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>> index bfd5b55..b850985 100644
>>>>>> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>> @@ -52,3 +52,23 @@ Board compatible values:
>>>>>>    - "amlogic,q201" (Meson gxm s912)
>>>>>>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>>>>>>    - "nexbox,a1" (Meson gxm s912)
>>>>>> +
>>>>>> +Amlogic Meson GX SoCs Information
>>>>>> +----------------------------------
>>>>>> +
>>>>>> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
>>>>>> +package and revision information. If present, a device node for this register
>>>>>> +should be added.
>>>>>> +
>>>>>> +Required properties:
>>>>>> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
>>>>>> +  - reg: Base address and length of the register block.
>>>>>> +
>>>>>> +Examples
>>>>>> +--------
>>>>>> +
>>>>>> +       chipid at 220 {
>>>>>> +               compatible = "amlogic,meson-gx-socinfo";
>>>>>> +               reg = <0x0 0x00220 0x0 0x4>;
>>>>>> +       };
>>>>>> +
>>>>>
>>>>> The register location would hint that this is in the middle of some block of
>>>>> random registers, i.e. a syscon or some unrelated device.
>>>>>
>>>>> Are you sure that "socinfo" is the actual name of the IP block and that
>>>>> it only has a single 32-bit register?
>>>>>
>>>>>      Arnd
>>>>>
>>>>
>>>> Hi Arnd,
>>>>
>>>> I'm sorry I did not find any relevant registers in the docs or source code describing
>>>> it in a specific block of registers, and no close enough register definitions either.
>>>> They may be used by the secure firmware I imagine.
>>>>
>>>> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
>>>> gives some details on the whole SoC and package, and socinfo seems better.
>>>
>>> A register at address 0x220 seems a bit strange (unless there's ranges
>>> you're not showing), but ROM code at this address would be fairly
>>> typical. And putting version information into the ROM is also common.
>>>
>>> Rob
>>>
>>
>> Hi Rob.
>>
>> Indeed it's part of a larger range :
>>                  aobus: aobus at c8100000 {
>>                         compatible = "simple-bus";
>>                         reg = <0x0 0xc8100000 0x0 0x100000>;
>>                         #address-cells = <2>;
>>                         #size-cells = <2>;
>>                         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>>
>>
>> While scrubbing on the uboot source, I found a sort of block of registers dedicated to communicate with
>> the secure firmware :
>> AO_SEC_REG0                                                     0x140
>> AO_SEC_REG1                                                     0x144
>> AO_SEC_REG2                                                     0x148
>> AO_SEC_TMODE_PWD0                                               0x160
>> AO_SEC_TMODE_PWD1                                               0x164
>> AO_SEC_TMODE_PWD2                                               0x168
>> AO_SEC_TMODE_PWD3                                               0x16C
>> AO_SEC_SCRATCH                                                  0x17C
>> AO_SEC_JTAG_PWD0                                                0x180
>> AO_SEC_JTAG_PWD1                                                0x184
>> AO_SEC_JTAG_PWD2                                                0x188
>> AO_SEC_JTAG_PWD3                                                0x18C
>> AO_SEC_JTAG_SEC_CNTL                                            0x190
>> AO_SEC_JTAG_PWD_ADDR0                                           0x194
>> AO_SEC_JTAG_PWD_ADDR1                                           0x198
>> AO_SEC_JTAG_PWD_ADDR2                                           0x19C
>> AO_SEC_JTAG_PWD_ADDR3                                           0x1A0
>> AO_SEC_SHARED_AHB_SRAM_REG0_0                                   0x1C0
>> AO_SEC_SHARED_AHB_SRAM_REG0_1                                   0x1C4
>> AO_SEC_SHARED_AHB_SRAM_REG0_2                                   0x1C8
>> AO_SEC_SHARED_AHB_SRAM_REG1_0                                   0x1CC
>> AO_SEC_SHARED_AHB_SRAM_REG1_1                                   0x1D0
>> AO_SEC_SHARED_AHB_SRAM_REG1_2                                   0x1D4
>> AO_SEC_SHARED_AHB_SRAM_REG2_0                                   0x1D8
>> AO_SEC_SHARED_AHB_SRAM_REG2_1                                   0x1DC
>> AO_SEC_SHARED_AHB_SRAM_REG2_2                                   0x1E0
>> AO_SEC_SHARED_AHB_SRAM_REG3_0                                   0x1E4
>> AO_SEC_SHARED_AHB_SRAM_REG3_1                                   0x1E8
>> AO_SEC_SHARED_AHB_SRAM_REG3_2                                   0x1EC
>> AO_SEC_AO_AHB_SRAM_REG0_0                                       0x1F0
>> AO_SEC_AO_AHB_SRAM_REG0_1                                       0x1F4
>> AO_SEC_AO_AHB_SRAM_REG1_0                                       0x1F8
>> AO_SEC_AO_AHB_SRAM_REG1_1                                       0x1FC
>> AO_SEC_SD_CFG8                                                  0x220
>> AO_SEC_SD_CFG9                                                  0x224
>> AO_SEC_SD_CFG10                                                 0x228
>> AO_SEC_SD_CFG11                                                 0x22C
>> AO_SEC_SD_CFG12                                                 0x230
>> AO_SEC_SD_CFG13                                                 0x234
>> AO_SEC_SD_CFG14                                                 0x238
>> AO_SEC_SD_CFG15                                                 0x23C
>> AO_SEC_GP_CFG0                                                  0x240
>> AO_SEC_GP_CFG1                                                  0x244
>> AO_SEC_GP_CFG2                                                  0x248
>> AO_SEC_GP_CFG3                                                  0x24C
>> AO_SEC_GP_CFG4                                                  0x250
>> AO_SEC_GP_CFG5                                                  0x254
>> AO_SEC_GP_CFG6                                                  0x258
>> AO_SEC_GP_CFG7                                                  0x25C
>> AO_SEC_GP_CFG8                                                  0x260
>> AO_SEC_GP_CFG9                                                  0x264
>> AO_SEC_GP_CFG10                                                 0x268
>> AO_SEC_GP_CFG11                                                 0x26C
>> AO_SEC_GP_CFG12                                                 0x270
>> AO_SEC_GP_CFG13                                                 0x274
>> AO_SEC_GP_CFG14                                                 0x278
>> AO_SEC_GP_CFG15                                                 0x27C
>>
>>
>> As you see, the register we use here is AO_SEC_SD_CFG8...
>>
>> Should I define all this block as simple-mfd and refer to it as a regmap ?
>>
>> aobus: aobus at c8100000 {
>>         compatible = "simple-bus";
>>         reg = <0x0 0xc8100000 0x0 0x100000>;
>>         #address-cells = <2>;
>>         #size-cells = <2>;
>>         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>>
>>         ao_secure: ao-secure at 140 {
>>                 compatible = "amlogic,meson-gx-ao-secure", "simple-mfd";
>>                 reg = <0x0 0x140 0x0 0x140>;
>>         };
>> };
>>
>> chipid {
>>         compatible = "amlogic,meson-gx-socinfo";
>>         ao-secure = <&ao_secure>;
>>         chip-info-reg = <0xe0>;
> 
> Why even divide it up further in DT? IMO, describing single
> registers/address in DT is too fine grained.
> 
> Rob
> 

Rob, I don't get it.

Maybe something like that ?

aobus: aobus at c8100000 {
        compatible = "simple-bus";
        reg = <0x0 0xc8100000 0x0 0x100000>;
        #address-cells = <2>;
        #size-cells = <2>;
        ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;

        ao_secure: ao-secure at 140 {
                compatible = "amlogic,meson-gx-ao-secure", "simple-mfd", "simple-bus";
                reg = <0x0 0x140 0x0 0x140>;
		#address-cells = <1>;
		#size-cells = <1>;

		chipid at e0 {
        		compatible = "amlogic,meson-gx-socinfo";
			reg = <0xe0 0x4>;
        	};
	};
};

Concerning the fine graining, I'm sorry but the actual information comes from a single register here...

Neil

^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-04-04 12:49               ` Neil Armstrong
  0 siblings, 0 replies; 37+ messages in thread
From: Neil Armstrong @ 2017-04-04 12:49 UTC (permalink / raw)
  To: linus-amlogic

On 04/04/2017 02:26 PM, Rob Herring wrote:
> On Tue, Apr 4, 2017 at 3:51 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>> On 04/03/2017 06:34 PM, Rob Herring wrote:
>>> On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
>>>> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
>>>>> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
>>>>> <narmstrong@baylibre.com> wrote:
>>>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>>>
>>>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>>>> ---
>>>>>>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>>>>>>  1 file changed, 20 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>> index bfd5b55..b850985 100644
>>>>>> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>> @@ -52,3 +52,23 @@ Board compatible values:
>>>>>>    - "amlogic,q201" (Meson gxm s912)
>>>>>>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>>>>>>    - "nexbox,a1" (Meson gxm s912)
>>>>>> +
>>>>>> +Amlogic Meson GX SoCs Information
>>>>>> +----------------------------------
>>>>>> +
>>>>>> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
>>>>>> +package and revision information. If present, a device node for this register
>>>>>> +should be added.
>>>>>> +
>>>>>> +Required properties:
>>>>>> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
>>>>>> +  - reg: Base address and length of the register block.
>>>>>> +
>>>>>> +Examples
>>>>>> +--------
>>>>>> +
>>>>>> +       chipid at 220 {
>>>>>> +               compatible = "amlogic,meson-gx-socinfo";
>>>>>> +               reg = <0x0 0x00220 0x0 0x4>;
>>>>>> +       };
>>>>>> +
>>>>>
>>>>> The register location would hint that this is in the middle of some block of
>>>>> random registers, i.e. a syscon or some unrelated device.
>>>>>
>>>>> Are you sure that "socinfo" is the actual name of the IP block and that
>>>>> it only has a single 32-bit register?
>>>>>
>>>>>      Arnd
>>>>>
>>>>
>>>> Hi Arnd,
>>>>
>>>> I'm sorry I did not find any relevant registers in the docs or source code describing
>>>> it in a specific block of registers, and no close enough register definitions either.
>>>> They may be used by the secure firmware I imagine.
>>>>
>>>> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
>>>> gives some details on the whole SoC and package, and socinfo seems better.
>>>
>>> A register at address 0x220 seems a bit strange (unless there's ranges
>>> you're not showing), but ROM code at this address would be fairly
>>> typical. And putting version information into the ROM is also common.
>>>
>>> Rob
>>>
>>
>> Hi Rob.
>>
>> Indeed it's part of a larger range :
>>                  aobus: aobus at c8100000 {
>>                         compatible = "simple-bus";
>>                         reg = <0x0 0xc8100000 0x0 0x100000>;
>>                         #address-cells = <2>;
>>                         #size-cells = <2>;
>>                         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>>
>>
>> While scrubbing on the uboot source, I found a sort of block of registers dedicated to communicate with
>> the secure firmware :
>> AO_SEC_REG0                                                     0x140
>> AO_SEC_REG1                                                     0x144
>> AO_SEC_REG2                                                     0x148
>> AO_SEC_TMODE_PWD0                                               0x160
>> AO_SEC_TMODE_PWD1                                               0x164
>> AO_SEC_TMODE_PWD2                                               0x168
>> AO_SEC_TMODE_PWD3                                               0x16C
>> AO_SEC_SCRATCH                                                  0x17C
>> AO_SEC_JTAG_PWD0                                                0x180
>> AO_SEC_JTAG_PWD1                                                0x184
>> AO_SEC_JTAG_PWD2                                                0x188
>> AO_SEC_JTAG_PWD3                                                0x18C
>> AO_SEC_JTAG_SEC_CNTL                                            0x190
>> AO_SEC_JTAG_PWD_ADDR0                                           0x194
>> AO_SEC_JTAG_PWD_ADDR1                                           0x198
>> AO_SEC_JTAG_PWD_ADDR2                                           0x19C
>> AO_SEC_JTAG_PWD_ADDR3                                           0x1A0
>> AO_SEC_SHARED_AHB_SRAM_REG0_0                                   0x1C0
>> AO_SEC_SHARED_AHB_SRAM_REG0_1                                   0x1C4
>> AO_SEC_SHARED_AHB_SRAM_REG0_2                                   0x1C8
>> AO_SEC_SHARED_AHB_SRAM_REG1_0                                   0x1CC
>> AO_SEC_SHARED_AHB_SRAM_REG1_1                                   0x1D0
>> AO_SEC_SHARED_AHB_SRAM_REG1_2                                   0x1D4
>> AO_SEC_SHARED_AHB_SRAM_REG2_0                                   0x1D8
>> AO_SEC_SHARED_AHB_SRAM_REG2_1                                   0x1DC
>> AO_SEC_SHARED_AHB_SRAM_REG2_2                                   0x1E0
>> AO_SEC_SHARED_AHB_SRAM_REG3_0                                   0x1E4
>> AO_SEC_SHARED_AHB_SRAM_REG3_1                                   0x1E8
>> AO_SEC_SHARED_AHB_SRAM_REG3_2                                   0x1EC
>> AO_SEC_AO_AHB_SRAM_REG0_0                                       0x1F0
>> AO_SEC_AO_AHB_SRAM_REG0_1                                       0x1F4
>> AO_SEC_AO_AHB_SRAM_REG1_0                                       0x1F8
>> AO_SEC_AO_AHB_SRAM_REG1_1                                       0x1FC
>> AO_SEC_SD_CFG8                                                  0x220
>> AO_SEC_SD_CFG9                                                  0x224
>> AO_SEC_SD_CFG10                                                 0x228
>> AO_SEC_SD_CFG11                                                 0x22C
>> AO_SEC_SD_CFG12                                                 0x230
>> AO_SEC_SD_CFG13                                                 0x234
>> AO_SEC_SD_CFG14                                                 0x238
>> AO_SEC_SD_CFG15                                                 0x23C
>> AO_SEC_GP_CFG0                                                  0x240
>> AO_SEC_GP_CFG1                                                  0x244
>> AO_SEC_GP_CFG2                                                  0x248
>> AO_SEC_GP_CFG3                                                  0x24C
>> AO_SEC_GP_CFG4                                                  0x250
>> AO_SEC_GP_CFG5                                                  0x254
>> AO_SEC_GP_CFG6                                                  0x258
>> AO_SEC_GP_CFG7                                                  0x25C
>> AO_SEC_GP_CFG8                                                  0x260
>> AO_SEC_GP_CFG9                                                  0x264
>> AO_SEC_GP_CFG10                                                 0x268
>> AO_SEC_GP_CFG11                                                 0x26C
>> AO_SEC_GP_CFG12                                                 0x270
>> AO_SEC_GP_CFG13                                                 0x274
>> AO_SEC_GP_CFG14                                                 0x278
>> AO_SEC_GP_CFG15                                                 0x27C
>>
>>
>> As you see, the register we use here is AO_SEC_SD_CFG8...
>>
>> Should I define all this block as simple-mfd and refer to it as a regmap ?
>>
>> aobus: aobus at c8100000 {
>>         compatible = "simple-bus";
>>         reg = <0x0 0xc8100000 0x0 0x100000>;
>>         #address-cells = <2>;
>>         #size-cells = <2>;
>>         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>>
>>         ao_secure: ao-secure at 140 {
>>                 compatible = "amlogic,meson-gx-ao-secure", "simple-mfd";
>>                 reg = <0x0 0x140 0x0 0x140>;
>>         };
>> };
>>
>> chipid {
>>         compatible = "amlogic,meson-gx-socinfo";
>>         ao-secure = <&ao_secure>;
>>         chip-info-reg = <0xe0>;
> 
> Why even divide it up further in DT? IMO, describing single
> registers/address in DT is too fine grained.
> 
> Rob
> 

Rob, I don't get it.

Maybe something like that ?

aobus: aobus at c8100000 {
        compatible = "simple-bus";
        reg = <0x0 0xc8100000 0x0 0x100000>;
        #address-cells = <2>;
        #size-cells = <2>;
        ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;

        ao_secure: ao-secure at 140 {
                compatible = "amlogic,meson-gx-ao-secure", "simple-mfd", "simple-bus";
                reg = <0x0 0x140 0x0 0x140>;
		#address-cells = <1>;
		#size-cells = <1>;

		chipid at e0 {
        		compatible = "amlogic,meson-gx-socinfo";
			reg = <0xe0 0x4>;
        	};
	};
};

Concerning the fine graining, I'm sorry but the actual information comes from a single register here...

Neil

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
  2017-04-04 12:49               ` Neil Armstrong
  (?)
@ 2017-04-05 19:11                 ` Rob Herring
  -1 siblings, 0 replies; 37+ messages in thread
From: Rob Herring @ 2017-04-05 19:11 UTC (permalink / raw)
  To: Neil Armstrong
  Cc: Arnd Bergmann, Kevin Hilman, Carlo Caione, linux-amlogic,
	Linux ARM, Linux Kernel Mailing List, devicetree

On Tue, Apr 4, 2017 at 7:49 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> On 04/04/2017 02:26 PM, Rob Herring wrote:
>> On Tue, Apr 4, 2017 at 3:51 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>>> On 04/03/2017 06:34 PM, Rob Herring wrote:
>>>> On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
>>>>> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
>>>>>> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
>>>>>> <narmstrong@baylibre.com> wrote:
>>>>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>>>>
>>>>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>>>>> ---
>>>>>>>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>>>>>>>  1 file changed, 20 insertions(+)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>>> index bfd5b55..b850985 100644
>>>>>>> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>>> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>>> @@ -52,3 +52,23 @@ Board compatible values:
>>>>>>>    - "amlogic,q201" (Meson gxm s912)
>>>>>>>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>>>>>>>    - "nexbox,a1" (Meson gxm s912)
>>>>>>> +
>>>>>>> +Amlogic Meson GX SoCs Information
>>>>>>> +----------------------------------
>>>>>>> +
>>>>>>> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
>>>>>>> +package and revision information. If present, a device node for this register
>>>>>>> +should be added.
>>>>>>> +
>>>>>>> +Required properties:
>>>>>>> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
>>>>>>> +  - reg: Base address and length of the register block.
>>>>>>> +
>>>>>>> +Examples
>>>>>>> +--------
>>>>>>> +
>>>>>>> +       chipid@220 {
>>>>>>> +               compatible = "amlogic,meson-gx-socinfo";
>>>>>>> +               reg = <0x0 0x00220 0x0 0x4>;
>>>>>>> +       };
>>>>>>> +
>>>>>>
>>>>>> The register location would hint that this is in the middle of some block of
>>>>>> random registers, i.e. a syscon or some unrelated device.
>>>>>>
>>>>>> Are you sure that "socinfo" is the actual name of the IP block and that
>>>>>> it only has a single 32-bit register?
>>>>>>
>>>>>>      Arnd
>>>>>>
>>>>>
>>>>> Hi Arnd,
>>>>>
>>>>> I'm sorry I did not find any relevant registers in the docs or source code describing
>>>>> it in a specific block of registers, and no close enough register definitions either.
>>>>> They may be used by the secure firmware I imagine.
>>>>>
>>>>> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
>>>>> gives some details on the whole SoC and package, and socinfo seems better.
>>>>
>>>> A register at address 0x220 seems a bit strange (unless there's ranges
>>>> you're not showing), but ROM code at this address would be fairly
>>>> typical. And putting version information into the ROM is also common.
>>>>
>>>> Rob
>>>>
>>>
>>> Hi Rob.
>>>
>>> Indeed it's part of a larger range :
>>>                  aobus: aobus@c8100000 {
>>>                         compatible = "simple-bus";
>>>                         reg = <0x0 0xc8100000 0x0 0x100000>;
>>>                         #address-cells = <2>;
>>>                         #size-cells = <2>;
>>>                         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>>>
>>>
>>> While scrubbing on the uboot source, I found a sort of block of registers dedicated to communicate with
>>> the secure firmware :
>>> AO_SEC_REG0                                                     0x140
>>> AO_SEC_REG1                                                     0x144
>>> AO_SEC_REG2                                                     0x148
>>> AO_SEC_TMODE_PWD0                                               0x160
>>> AO_SEC_TMODE_PWD1                                               0x164
>>> AO_SEC_TMODE_PWD2                                               0x168
>>> AO_SEC_TMODE_PWD3                                               0x16C
>>> AO_SEC_SCRATCH                                                  0x17C
>>> AO_SEC_JTAG_PWD0                                                0x180
>>> AO_SEC_JTAG_PWD1                                                0x184
>>> AO_SEC_JTAG_PWD2                                                0x188
>>> AO_SEC_JTAG_PWD3                                                0x18C
>>> AO_SEC_JTAG_SEC_CNTL                                            0x190
>>> AO_SEC_JTAG_PWD_ADDR0                                           0x194
>>> AO_SEC_JTAG_PWD_ADDR1                                           0x198
>>> AO_SEC_JTAG_PWD_ADDR2                                           0x19C
>>> AO_SEC_JTAG_PWD_ADDR3                                           0x1A0
>>> AO_SEC_SHARED_AHB_SRAM_REG0_0                                   0x1C0
>>> AO_SEC_SHARED_AHB_SRAM_REG0_1                                   0x1C4
>>> AO_SEC_SHARED_AHB_SRAM_REG0_2                                   0x1C8
>>> AO_SEC_SHARED_AHB_SRAM_REG1_0                                   0x1CC
>>> AO_SEC_SHARED_AHB_SRAM_REG1_1                                   0x1D0
>>> AO_SEC_SHARED_AHB_SRAM_REG1_2                                   0x1D4
>>> AO_SEC_SHARED_AHB_SRAM_REG2_0                                   0x1D8
>>> AO_SEC_SHARED_AHB_SRAM_REG2_1                                   0x1DC
>>> AO_SEC_SHARED_AHB_SRAM_REG2_2                                   0x1E0
>>> AO_SEC_SHARED_AHB_SRAM_REG3_0                                   0x1E4
>>> AO_SEC_SHARED_AHB_SRAM_REG3_1                                   0x1E8
>>> AO_SEC_SHARED_AHB_SRAM_REG3_2                                   0x1EC
>>> AO_SEC_AO_AHB_SRAM_REG0_0                                       0x1F0
>>> AO_SEC_AO_AHB_SRAM_REG0_1                                       0x1F4
>>> AO_SEC_AO_AHB_SRAM_REG1_0                                       0x1F8
>>> AO_SEC_AO_AHB_SRAM_REG1_1                                       0x1FC
>>> AO_SEC_SD_CFG8                                                  0x220
>>> AO_SEC_SD_CFG9                                                  0x224
>>> AO_SEC_SD_CFG10                                                 0x228
>>> AO_SEC_SD_CFG11                                                 0x22C
>>> AO_SEC_SD_CFG12                                                 0x230
>>> AO_SEC_SD_CFG13                                                 0x234
>>> AO_SEC_SD_CFG14                                                 0x238
>>> AO_SEC_SD_CFG15                                                 0x23C
>>> AO_SEC_GP_CFG0                                                  0x240
>>> AO_SEC_GP_CFG1                                                  0x244
>>> AO_SEC_GP_CFG2                                                  0x248
>>> AO_SEC_GP_CFG3                                                  0x24C
>>> AO_SEC_GP_CFG4                                                  0x250
>>> AO_SEC_GP_CFG5                                                  0x254
>>> AO_SEC_GP_CFG6                                                  0x258
>>> AO_SEC_GP_CFG7                                                  0x25C
>>> AO_SEC_GP_CFG8                                                  0x260
>>> AO_SEC_GP_CFG9                                                  0x264
>>> AO_SEC_GP_CFG10                                                 0x268
>>> AO_SEC_GP_CFG11                                                 0x26C
>>> AO_SEC_GP_CFG12                                                 0x270
>>> AO_SEC_GP_CFG13                                                 0x274
>>> AO_SEC_GP_CFG14                                                 0x278
>>> AO_SEC_GP_CFG15                                                 0x27C
>>>
>>>
>>> As you see, the register we use here is AO_SEC_SD_CFG8...
>>>
>>> Should I define all this block as simple-mfd and refer to it as a regmap ?
>>>
>>> aobus: aobus@c8100000 {
>>>         compatible = "simple-bus";
>>>         reg = <0x0 0xc8100000 0x0 0x100000>;
>>>         #address-cells = <2>;
>>>         #size-cells = <2>;
>>>         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>>>
>>>         ao_secure: ao-secure@140 {
>>>                 compatible = "amlogic,meson-gx-ao-secure", "simple-mfd";
>>>                 reg = <0x0 0x140 0x0 0x140>;
>>>         };
>>> };
>>>
>>> chipid {
>>>         compatible = "amlogic,meson-gx-socinfo";
>>>         ao-secure = <&ao_secure>;
>>>         chip-info-reg = <0xe0>;
>>
>> Why even divide it up further in DT? IMO, describing single
>> registers/address in DT is too fine grained.
>>
>> Rob
>>
>
> Rob, I don't get it.
>
> Maybe something like that ?
>
> aobus: aobus@c8100000 {
>         compatible = "simple-bus";
>         reg = <0x0 0xc8100000 0x0 0x100000>;
>         #address-cells = <2>;
>         #size-cells = <2>;
>         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>
>         ao_secure: ao-secure@140 {
>                 compatible = "amlogic,meson-gx-ao-secure", "simple-mfd", "simple-bus";
>                 reg = <0x0 0x140 0x0 0x140>;
>                 #address-cells = <1>;
>                 #size-cells = <1>;
>
>                 chipid@e0 {
>                         compatible = "amlogic,meson-gx-socinfo";
>                         reg = <0xe0 0x4>;
>                 };
>         };
> };

That's somewhat better, though your addressing is wrong.

>
> Concerning the fine graining, I'm sorry but the actual information comes from a single register here...

Yes, but the only useful information here is really "0xe0". I imagine
you also want "amlogic,meson-gx-socinfo" to instantiate a driver, but
that's not a reason to put a node into DT. You can just easily have
whatever handles "amlogic,meson-gx-ao-secure" provide the version
information out of register 0xe0.

Rob

^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-04-05 19:11                 ` Rob Herring
  0 siblings, 0 replies; 37+ messages in thread
From: Rob Herring @ 2017-04-05 19:11 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Apr 4, 2017 at 7:49 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> On 04/04/2017 02:26 PM, Rob Herring wrote:
>> On Tue, Apr 4, 2017 at 3:51 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>>> On 04/03/2017 06:34 PM, Rob Herring wrote:
>>>> On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
>>>>> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
>>>>>> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
>>>>>> <narmstrong@baylibre.com> wrote:
>>>>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>>>>
>>>>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>>>>> ---
>>>>>>>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>>>>>>>  1 file changed, 20 insertions(+)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>>> index bfd5b55..b850985 100644
>>>>>>> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>>> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>>> @@ -52,3 +52,23 @@ Board compatible values:
>>>>>>>    - "amlogic,q201" (Meson gxm s912)
>>>>>>>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>>>>>>>    - "nexbox,a1" (Meson gxm s912)
>>>>>>> +
>>>>>>> +Amlogic Meson GX SoCs Information
>>>>>>> +----------------------------------
>>>>>>> +
>>>>>>> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
>>>>>>> +package and revision information. If present, a device node for this register
>>>>>>> +should be added.
>>>>>>> +
>>>>>>> +Required properties:
>>>>>>> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
>>>>>>> +  - reg: Base address and length of the register block.
>>>>>>> +
>>>>>>> +Examples
>>>>>>> +--------
>>>>>>> +
>>>>>>> +       chipid at 220 {
>>>>>>> +               compatible = "amlogic,meson-gx-socinfo";
>>>>>>> +               reg = <0x0 0x00220 0x0 0x4>;
>>>>>>> +       };
>>>>>>> +
>>>>>>
>>>>>> The register location would hint that this is in the middle of some block of
>>>>>> random registers, i.e. a syscon or some unrelated device.
>>>>>>
>>>>>> Are you sure that "socinfo" is the actual name of the IP block and that
>>>>>> it only has a single 32-bit register?
>>>>>>
>>>>>>      Arnd
>>>>>>
>>>>>
>>>>> Hi Arnd,
>>>>>
>>>>> I'm sorry I did not find any relevant registers in the docs or source code describing
>>>>> it in a specific block of registers, and no close enough register definitions either.
>>>>> They may be used by the secure firmware I imagine.
>>>>>
>>>>> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
>>>>> gives some details on the whole SoC and package, and socinfo seems better.
>>>>
>>>> A register at address 0x220 seems a bit strange (unless there's ranges
>>>> you're not showing), but ROM code at this address would be fairly
>>>> typical. And putting version information into the ROM is also common.
>>>>
>>>> Rob
>>>>
>>>
>>> Hi Rob.
>>>
>>> Indeed it's part of a larger range :
>>>                  aobus: aobus at c8100000 {
>>>                         compatible = "simple-bus";
>>>                         reg = <0x0 0xc8100000 0x0 0x100000>;
>>>                         #address-cells = <2>;
>>>                         #size-cells = <2>;
>>>                         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>>>
>>>
>>> While scrubbing on the uboot source, I found a sort of block of registers dedicated to communicate with
>>> the secure firmware :
>>> AO_SEC_REG0                                                     0x140
>>> AO_SEC_REG1                                                     0x144
>>> AO_SEC_REG2                                                     0x148
>>> AO_SEC_TMODE_PWD0                                               0x160
>>> AO_SEC_TMODE_PWD1                                               0x164
>>> AO_SEC_TMODE_PWD2                                               0x168
>>> AO_SEC_TMODE_PWD3                                               0x16C
>>> AO_SEC_SCRATCH                                                  0x17C
>>> AO_SEC_JTAG_PWD0                                                0x180
>>> AO_SEC_JTAG_PWD1                                                0x184
>>> AO_SEC_JTAG_PWD2                                                0x188
>>> AO_SEC_JTAG_PWD3                                                0x18C
>>> AO_SEC_JTAG_SEC_CNTL                                            0x190
>>> AO_SEC_JTAG_PWD_ADDR0                                           0x194
>>> AO_SEC_JTAG_PWD_ADDR1                                           0x198
>>> AO_SEC_JTAG_PWD_ADDR2                                           0x19C
>>> AO_SEC_JTAG_PWD_ADDR3                                           0x1A0
>>> AO_SEC_SHARED_AHB_SRAM_REG0_0                                   0x1C0
>>> AO_SEC_SHARED_AHB_SRAM_REG0_1                                   0x1C4
>>> AO_SEC_SHARED_AHB_SRAM_REG0_2                                   0x1C8
>>> AO_SEC_SHARED_AHB_SRAM_REG1_0                                   0x1CC
>>> AO_SEC_SHARED_AHB_SRAM_REG1_1                                   0x1D0
>>> AO_SEC_SHARED_AHB_SRAM_REG1_2                                   0x1D4
>>> AO_SEC_SHARED_AHB_SRAM_REG2_0                                   0x1D8
>>> AO_SEC_SHARED_AHB_SRAM_REG2_1                                   0x1DC
>>> AO_SEC_SHARED_AHB_SRAM_REG2_2                                   0x1E0
>>> AO_SEC_SHARED_AHB_SRAM_REG3_0                                   0x1E4
>>> AO_SEC_SHARED_AHB_SRAM_REG3_1                                   0x1E8
>>> AO_SEC_SHARED_AHB_SRAM_REG3_2                                   0x1EC
>>> AO_SEC_AO_AHB_SRAM_REG0_0                                       0x1F0
>>> AO_SEC_AO_AHB_SRAM_REG0_1                                       0x1F4
>>> AO_SEC_AO_AHB_SRAM_REG1_0                                       0x1F8
>>> AO_SEC_AO_AHB_SRAM_REG1_1                                       0x1FC
>>> AO_SEC_SD_CFG8                                                  0x220
>>> AO_SEC_SD_CFG9                                                  0x224
>>> AO_SEC_SD_CFG10                                                 0x228
>>> AO_SEC_SD_CFG11                                                 0x22C
>>> AO_SEC_SD_CFG12                                                 0x230
>>> AO_SEC_SD_CFG13                                                 0x234
>>> AO_SEC_SD_CFG14                                                 0x238
>>> AO_SEC_SD_CFG15                                                 0x23C
>>> AO_SEC_GP_CFG0                                                  0x240
>>> AO_SEC_GP_CFG1                                                  0x244
>>> AO_SEC_GP_CFG2                                                  0x248
>>> AO_SEC_GP_CFG3                                                  0x24C
>>> AO_SEC_GP_CFG4                                                  0x250
>>> AO_SEC_GP_CFG5                                                  0x254
>>> AO_SEC_GP_CFG6                                                  0x258
>>> AO_SEC_GP_CFG7                                                  0x25C
>>> AO_SEC_GP_CFG8                                                  0x260
>>> AO_SEC_GP_CFG9                                                  0x264
>>> AO_SEC_GP_CFG10                                                 0x268
>>> AO_SEC_GP_CFG11                                                 0x26C
>>> AO_SEC_GP_CFG12                                                 0x270
>>> AO_SEC_GP_CFG13                                                 0x274
>>> AO_SEC_GP_CFG14                                                 0x278
>>> AO_SEC_GP_CFG15                                                 0x27C
>>>
>>>
>>> As you see, the register we use here is AO_SEC_SD_CFG8...
>>>
>>> Should I define all this block as simple-mfd and refer to it as a regmap ?
>>>
>>> aobus: aobus at c8100000 {
>>>         compatible = "simple-bus";
>>>         reg = <0x0 0xc8100000 0x0 0x100000>;
>>>         #address-cells = <2>;
>>>         #size-cells = <2>;
>>>         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>>>
>>>         ao_secure: ao-secure at 140 {
>>>                 compatible = "amlogic,meson-gx-ao-secure", "simple-mfd";
>>>                 reg = <0x0 0x140 0x0 0x140>;
>>>         };
>>> };
>>>
>>> chipid {
>>>         compatible = "amlogic,meson-gx-socinfo";
>>>         ao-secure = <&ao_secure>;
>>>         chip-info-reg = <0xe0>;
>>
>> Why even divide it up further in DT? IMO, describing single
>> registers/address in DT is too fine grained.
>>
>> Rob
>>
>
> Rob, I don't get it.
>
> Maybe something like that ?
>
> aobus: aobus at c8100000 {
>         compatible = "simple-bus";
>         reg = <0x0 0xc8100000 0x0 0x100000>;
>         #address-cells = <2>;
>         #size-cells = <2>;
>         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>
>         ao_secure: ao-secure at 140 {
>                 compatible = "amlogic,meson-gx-ao-secure", "simple-mfd", "simple-bus";
>                 reg = <0x0 0x140 0x0 0x140>;
>                 #address-cells = <1>;
>                 #size-cells = <1>;
>
>                 chipid at e0 {
>                         compatible = "amlogic,meson-gx-socinfo";
>                         reg = <0xe0 0x4>;
>                 };
>         };
> };

That's somewhat better, though your addressing is wrong.

>
> Concerning the fine graining, I'm sorry but the actual information comes from a single register here...

Yes, but the only useful information here is really "0xe0". I imagine
you also want "amlogic,meson-gx-socinfo" to instantiate a driver, but
that's not a reason to put a node into DT. You can just easily have
whatever handles "amlogic,meson-gx-ao-secure" provide the version
information out of register 0xe0.

Rob

^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
@ 2017-04-05 19:11                 ` Rob Herring
  0 siblings, 0 replies; 37+ messages in thread
From: Rob Herring @ 2017-04-05 19:11 UTC (permalink / raw)
  To: linus-amlogic

On Tue, Apr 4, 2017 at 7:49 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> On 04/04/2017 02:26 PM, Rob Herring wrote:
>> On Tue, Apr 4, 2017 at 3:51 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>>> On 04/03/2017 06:34 PM, Rob Herring wrote:
>>>> On Fri, Mar 31, 2017 at 04:10:30PM +0200, Neil Armstrong wrote:
>>>>> On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
>>>>>> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
>>>>>> <narmstrong@baylibre.com> wrote:
>>>>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>>>>
>>>>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>>>>> ---
>>>>>>>  Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
>>>>>>>  1 file changed, 20 insertions(+)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>>> index bfd5b55..b850985 100644
>>>>>>> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>>> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
>>>>>>> @@ -52,3 +52,23 @@ Board compatible values:
>>>>>>>    - "amlogic,q201" (Meson gxm s912)
>>>>>>>    - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
>>>>>>>    - "nexbox,a1" (Meson gxm s912)
>>>>>>> +
>>>>>>> +Amlogic Meson GX SoCs Information
>>>>>>> +----------------------------------
>>>>>>> +
>>>>>>> +The Meson SoCs have a Product Register that allows to retrieve SoC type,
>>>>>>> +package and revision information. If present, a device node for this register
>>>>>>> +should be added.
>>>>>>> +
>>>>>>> +Required properties:
>>>>>>> +  - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
>>>>>>> +  - reg: Base address and length of the register block.
>>>>>>> +
>>>>>>> +Examples
>>>>>>> +--------
>>>>>>> +
>>>>>>> +       chipid at 220 {
>>>>>>> +               compatible = "amlogic,meson-gx-socinfo";
>>>>>>> +               reg = <0x0 0x00220 0x0 0x4>;
>>>>>>> +       };
>>>>>>> +
>>>>>>
>>>>>> The register location would hint that this is in the middle of some block of
>>>>>> random registers, i.e. a syscon or some unrelated device.
>>>>>>
>>>>>> Are you sure that "socinfo" is the actual name of the IP block and that
>>>>>> it only has a single 32-bit register?
>>>>>>
>>>>>>      Arnd
>>>>>>
>>>>>
>>>>> Hi Arnd,
>>>>>
>>>>> I'm sorry I did not find any relevant registers in the docs or source code describing
>>>>> it in a specific block of registers, and no close enough register definitions either.
>>>>> They may be used by the secure firmware I imagine.
>>>>>
>>>>> For the register name, Amlogic refers it to "cpu_version" in their code, but it really
>>>>> gives some details on the whole SoC and package, and socinfo seems better.
>>>>
>>>> A register at address 0x220 seems a bit strange (unless there's ranges
>>>> you're not showing), but ROM code at this address would be fairly
>>>> typical. And putting version information into the ROM is also common.
>>>>
>>>> Rob
>>>>
>>>
>>> Hi Rob.
>>>
>>> Indeed it's part of a larger range :
>>>                  aobus: aobus at c8100000 {
>>>                         compatible = "simple-bus";
>>>                         reg = <0x0 0xc8100000 0x0 0x100000>;
>>>                         #address-cells = <2>;
>>>                         #size-cells = <2>;
>>>                         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>>>
>>>
>>> While scrubbing on the uboot source, I found a sort of block of registers dedicated to communicate with
>>> the secure firmware :
>>> AO_SEC_REG0                                                     0x140
>>> AO_SEC_REG1                                                     0x144
>>> AO_SEC_REG2                                                     0x148
>>> AO_SEC_TMODE_PWD0                                               0x160
>>> AO_SEC_TMODE_PWD1                                               0x164
>>> AO_SEC_TMODE_PWD2                                               0x168
>>> AO_SEC_TMODE_PWD3                                               0x16C
>>> AO_SEC_SCRATCH                                                  0x17C
>>> AO_SEC_JTAG_PWD0                                                0x180
>>> AO_SEC_JTAG_PWD1                                                0x184
>>> AO_SEC_JTAG_PWD2                                                0x188
>>> AO_SEC_JTAG_PWD3                                                0x18C
>>> AO_SEC_JTAG_SEC_CNTL                                            0x190
>>> AO_SEC_JTAG_PWD_ADDR0                                           0x194
>>> AO_SEC_JTAG_PWD_ADDR1                                           0x198
>>> AO_SEC_JTAG_PWD_ADDR2                                           0x19C
>>> AO_SEC_JTAG_PWD_ADDR3                                           0x1A0
>>> AO_SEC_SHARED_AHB_SRAM_REG0_0                                   0x1C0
>>> AO_SEC_SHARED_AHB_SRAM_REG0_1                                   0x1C4
>>> AO_SEC_SHARED_AHB_SRAM_REG0_2                                   0x1C8
>>> AO_SEC_SHARED_AHB_SRAM_REG1_0                                   0x1CC
>>> AO_SEC_SHARED_AHB_SRAM_REG1_1                                   0x1D0
>>> AO_SEC_SHARED_AHB_SRAM_REG1_2                                   0x1D4
>>> AO_SEC_SHARED_AHB_SRAM_REG2_0                                   0x1D8
>>> AO_SEC_SHARED_AHB_SRAM_REG2_1                                   0x1DC
>>> AO_SEC_SHARED_AHB_SRAM_REG2_2                                   0x1E0
>>> AO_SEC_SHARED_AHB_SRAM_REG3_0                                   0x1E4
>>> AO_SEC_SHARED_AHB_SRAM_REG3_1                                   0x1E8
>>> AO_SEC_SHARED_AHB_SRAM_REG3_2                                   0x1EC
>>> AO_SEC_AO_AHB_SRAM_REG0_0                                       0x1F0
>>> AO_SEC_AO_AHB_SRAM_REG0_1                                       0x1F4
>>> AO_SEC_AO_AHB_SRAM_REG1_0                                       0x1F8
>>> AO_SEC_AO_AHB_SRAM_REG1_1                                       0x1FC
>>> AO_SEC_SD_CFG8                                                  0x220
>>> AO_SEC_SD_CFG9                                                  0x224
>>> AO_SEC_SD_CFG10                                                 0x228
>>> AO_SEC_SD_CFG11                                                 0x22C
>>> AO_SEC_SD_CFG12                                                 0x230
>>> AO_SEC_SD_CFG13                                                 0x234
>>> AO_SEC_SD_CFG14                                                 0x238
>>> AO_SEC_SD_CFG15                                                 0x23C
>>> AO_SEC_GP_CFG0                                                  0x240
>>> AO_SEC_GP_CFG1                                                  0x244
>>> AO_SEC_GP_CFG2                                                  0x248
>>> AO_SEC_GP_CFG3                                                  0x24C
>>> AO_SEC_GP_CFG4                                                  0x250
>>> AO_SEC_GP_CFG5                                                  0x254
>>> AO_SEC_GP_CFG6                                                  0x258
>>> AO_SEC_GP_CFG7                                                  0x25C
>>> AO_SEC_GP_CFG8                                                  0x260
>>> AO_SEC_GP_CFG9                                                  0x264
>>> AO_SEC_GP_CFG10                                                 0x268
>>> AO_SEC_GP_CFG11                                                 0x26C
>>> AO_SEC_GP_CFG12                                                 0x270
>>> AO_SEC_GP_CFG13                                                 0x274
>>> AO_SEC_GP_CFG14                                                 0x278
>>> AO_SEC_GP_CFG15                                                 0x27C
>>>
>>>
>>> As you see, the register we use here is AO_SEC_SD_CFG8...
>>>
>>> Should I define all this block as simple-mfd and refer to it as a regmap ?
>>>
>>> aobus: aobus at c8100000 {
>>>         compatible = "simple-bus";
>>>         reg = <0x0 0xc8100000 0x0 0x100000>;
>>>         #address-cells = <2>;
>>>         #size-cells = <2>;
>>>         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>>>
>>>         ao_secure: ao-secure at 140 {
>>>                 compatible = "amlogic,meson-gx-ao-secure", "simple-mfd";
>>>                 reg = <0x0 0x140 0x0 0x140>;
>>>         };
>>> };
>>>
>>> chipid {
>>>         compatible = "amlogic,meson-gx-socinfo";
>>>         ao-secure = <&ao_secure>;
>>>         chip-info-reg = <0xe0>;
>>
>> Why even divide it up further in DT? IMO, describing single
>> registers/address in DT is too fine grained.
>>
>> Rob
>>
>
> Rob, I don't get it.
>
> Maybe something like that ?
>
> aobus: aobus at c8100000 {
>         compatible = "simple-bus";
>         reg = <0x0 0xc8100000 0x0 0x100000>;
>         #address-cells = <2>;
>         #size-cells = <2>;
>         ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
>
>         ao_secure: ao-secure at 140 {
>                 compatible = "amlogic,meson-gx-ao-secure", "simple-mfd", "simple-bus";
>                 reg = <0x0 0x140 0x0 0x140>;
>                 #address-cells = <1>;
>                 #size-cells = <1>;
>
>                 chipid at e0 {
>                         compatible = "amlogic,meson-gx-socinfo";
>                         reg = <0xe0 0x4>;
>                 };
>         };
> };

That's somewhat better, though your addressing is wrong.

>
> Concerning the fine graining, I'm sorry but the actual information comes from a single register here...

Yes, but the only useful information here is really "0xe0". I imagine
you also want "amlogic,meson-gx-socinfo" to instantiate a driver, but
that's not a reason to put a node into DT. You can just easily have
whatever handles "amlogic,meson-gx-ao-secure" provide the version
information out of register 0xe0.

Rob

^ permalink raw reply	[flat|nested] 37+ messages in thread

end of thread, other threads:[~2017-04-05 19:12 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-31  8:47 [PATCH 0/3] soc: amlogic: Add Amlogic SoC Information driver Neil Armstrong
2017-03-31  8:47 ` Neil Armstrong
2017-03-31  8:47 ` Neil Armstrong
2017-03-31  8:47 ` [PATCH 1/3] soc: " Neil Armstrong
2017-03-31  8:47   ` Neil Armstrong
2017-03-31  8:47   ` Neil Armstrong
2017-03-31  8:47 ` [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings Neil Armstrong
2017-03-31  8:47   ` Neil Armstrong
2017-03-31  8:47   ` Neil Armstrong
2017-03-31 13:44   ` Arnd Bergmann
2017-03-31 13:44     ` Arnd Bergmann
2017-03-31 13:44     ` Arnd Bergmann
2017-03-31 13:44     ` Arnd Bergmann
2017-03-31 14:10     ` Neil Armstrong
2017-03-31 14:10       ` Neil Armstrong
2017-03-31 14:10       ` Neil Armstrong
2017-04-03 16:34       ` Rob Herring
2017-04-03 16:34         ` Rob Herring
2017-04-03 16:34         ` Rob Herring
2017-04-03 16:34         ` Rob Herring
2017-04-04  8:51         ` Neil Armstrong
2017-04-04  8:51           ` Neil Armstrong
2017-04-04  8:51           ` Neil Armstrong
2017-04-04 12:26           ` Rob Herring
2017-04-04 12:26             ` Rob Herring
2017-04-04 12:26             ` Rob Herring
2017-04-04 12:26             ` Rob Herring
2017-04-04 12:49             ` Neil Armstrong
2017-04-04 12:49               ` Neil Armstrong
2017-04-04 12:49               ` Neil Armstrong
2017-04-04 12:49               ` Neil Armstrong
2017-04-05 19:11               ` Rob Herring
2017-04-05 19:11                 ` Rob Herring
2017-04-05 19:11                 ` Rob Herring
2017-03-31  8:47 ` [PATCH 3/3] ARM64: dts: meson-gx: Add SoC info register Neil Armstrong
2017-03-31  8:47   ` Neil Armstrong
2017-03-31  8:47   ` Neil Armstrong

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.