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@xxxxxxxxxxxx> wrote: >>>> Add bindings for the SoC information register of the Amlogic SoCs. >>>> >>>> Signed-off-by: Neil Armstrong <narmstrong@xxxxxxxxxxxx> >>>> --- >>>> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html