* [PATCH 0/3] soc: amlogic: Add Amlogic SoC Information driver
@ 2017-03-31 8:47 Neil Armstrong
2017-03-31 8:47 ` [PATCH 1/3] soc: " Neil Armstrong
` (2 more replies)
0 siblings, 3 replies; 11+ 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] 11+ messages in thread* [PATCH 1/3] soc: Add Amlogic SoC Information driver 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 ` [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings Neil Armstrong 2017-03-31 8:47 ` [PATCH 3/3] ARM64: dts: meson-gx: Add SoC info register Neil Armstrong 2 siblings, 0 replies; 11+ 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 [flat|nested] 11+ messages in thread
* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings 2017-03-31 8:47 [PATCH 0/3] soc: amlogic: Add Amlogic SoC Information driver Neil Armstrong 2017-03-31 8:47 ` [PATCH 1/3] soc: " Neil Armstrong @ 2017-03-31 8:47 ` Neil Armstrong 2017-03-31 13:44 ` Arnd Bergmann 2017-03-31 8:47 ` [PATCH 3/3] ARM64: dts: meson-gx: Add SoC info register Neil Armstrong 2 siblings, 1 reply; 11+ 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 [flat|nested] 11+ messages in thread
* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings 2017-03-31 8:47 ` [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings Neil Armstrong @ 2017-03-31 13:44 ` Arnd Bergmann 2017-03-31 14:10 ` Neil Armstrong 0 siblings, 1 reply; 11+ 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] 11+ 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 2017-04-03 16:34 ` Rob Herring 0 siblings, 1 reply; 11+ 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] 11+ messages in thread
* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings 2017-03-31 14:10 ` Neil Armstrong @ 2017-04-03 16:34 ` Rob Herring 2017-04-04 8:51 ` Neil Armstrong 0 siblings, 1 reply; 11+ 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] 11+ 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 2017-04-04 12:26 ` Rob Herring 0 siblings, 1 reply; 11+ 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] 11+ messages in thread
* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings 2017-04-04 8:51 ` Neil Armstrong @ 2017-04-04 12:26 ` Rob Herring 2017-04-04 12:49 ` Neil Armstrong 0 siblings, 1 reply; 11+ 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] 11+ messages in thread
* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings 2017-04-04 12:26 ` Rob Herring @ 2017-04-04 12:49 ` Neil Armstrong 2017-04-05 19:11 ` Rob Herring 0 siblings, 1 reply; 11+ 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] 11+ 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 0 siblings, 0 replies; 11+ 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] 11+ messages in thread
* [PATCH 3/3] ARM64: dts: meson-gx: Add SoC info register 2017-03-31 8:47 [PATCH 0/3] soc: amlogic: Add Amlogic SoC Information driver Neil Armstrong 2017-03-31 8:47 ` [PATCH 1/3] soc: " 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 2 siblings, 0 replies; 11+ 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 [flat|nested] 11+ messages in thread
end of thread, other threads:[~2017-04-05 19:12 UTC | newest] Thread overview: 11+ 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 ` [PATCH 1/3] soc: " Neil Armstrong 2017-03-31 8:47 ` [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings Neil Armstrong 2017-03-31 13:44 ` Arnd Bergmann 2017-03-31 14:10 ` Neil Armstrong 2017-04-03 16:34 ` Rob Herring 2017-04-04 8:51 ` Neil Armstrong 2017-04-04 12:26 ` Rob Herring 2017-04-04 12:49 ` Neil Armstrong 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
Powered by JetHome