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
Add node for the Amlogic Meson GX SoC information register.
Signed-off-by: Neil Armstrong <[email protected]>
---
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
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 <[email protected]>
---
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 <[email protected]>
+ *
+ * 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
Add bindings for the SoC information register of the Amlogic SoCs.
Signed-off-by: Neil Armstrong <[email protected]>
---
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
On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
<[email protected]> wrote:
> Add bindings for the SoC information register of the Amlogic SoCs.
>
> Signed-off-by: Neil Armstrong <[email protected]>
> ---
> 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
On 03/31/2017 03:44 PM, Arnd Bergmann wrote:
> On Fri, Mar 31, 2017 at 10:47 AM, Neil Armstrong
> <[email protected]> wrote:
>> Add bindings for the SoC information register of the Amlogic SoCs.
>>
>> Signed-off-by: Neil Armstrong <[email protected]>
>> ---
>> 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
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
> > <[email protected]> wrote:
> >> Add bindings for the SoC information register of the Amlogic SoCs.
> >>
> >> Signed-off-by: Neil Armstrong <[email protected]>
> >> ---
> >> 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
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
>>> <[email protected]> wrote:
>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>
>>>> Signed-off-by: Neil Armstrong <[email protected]>
>>>> ---
>>>> 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
On Tue, Apr 4, 2017 at 3:51 AM, Neil Armstrong <[email protected]> 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
>>>> <[email protected]> wrote:
>>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>>
>>>>> Signed-off-by: Neil Armstrong <[email protected]>
>>>>> ---
>>>>> 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
On 04/04/2017 02:26 PM, Rob Herring wrote:
> On Tue, Apr 4, 2017 at 3:51 AM, Neil Armstrong <[email protected]> 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
>>>>> <[email protected]> wrote:
>>>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>>>
>>>>>> Signed-off-by: Neil Armstrong <[email protected]>
>>>>>> ---
>>>>>> 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
On Tue, Apr 4, 2017 at 7:49 AM, Neil Armstrong <[email protected]> wrote:
> On 04/04/2017 02:26 PM, Rob Herring wrote:
>> On Tue, Apr 4, 2017 at 3:51 AM, Neil Armstrong <[email protected]> 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
>>>>>> <[email protected]> wrote:
>>>>>>> Add bindings for the SoC information register of the Amlogic SoCs.
>>>>>>>
>>>>>>> Signed-off-by: Neil Armstrong <[email protected]>
>>>>>>> ---
>>>>>>> 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