* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
[not found] <1490950079-10145-1-git-send-email-narmstrong@baylibre.com>
@ 2017-03-31 8:47 ` Neil Armstrong
[not found] ` <1490950079-10145-3-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
2017-03-31 8:47 ` [PATCH 3/3] ARM64: dts: meson-gx: Add SoC info register Neil Armstrong
1 sibling, 1 reply; 9+ 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] 9+ messages in thread
* [PATCH 3/3] ARM64: dts: meson-gx: Add SoC info register
[not found] <1490950079-10145-1-git-send-email-narmstrong@baylibre.com>
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
1 sibling, 0 replies; 9+ 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] 9+ messages in thread
* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
[not found] ` <1490950079-10145-3-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
@ 2017-03-31 13:44 ` Arnd Bergmann
2017-03-31 14:10 ` Neil Armstrong
0 siblings, 1 reply; 9+ 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] 9+ 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
[not found] ` <4ab7d4ee-e805-69f1-b76b-b827b46285bd-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
0 siblings, 1 reply; 9+ 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] 9+ messages in thread
* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
[not found] ` <4ab7d4ee-e805-69f1-b76b-b827b46285bd-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
@ 2017-04-03 16:34 ` Rob Herring
2017-04-04 8:51 ` Neil Armstrong
0 siblings, 1 reply; 9+ 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] 9+ 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
[not found] ` <265460a5-9295-f58a-f149-030e5dd750a1-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
0 siblings, 1 reply; 9+ 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] 9+ messages in thread
* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
[not found] ` <265460a5-9295-f58a-f149-030e5dd750a1-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
@ 2017-04-04 12:26 ` Rob Herring
[not found] ` <CAL_JsqKWi=sNgOTTw6+PAxwgFyFQMw6BiUz0uNuG4kWr+ORO_g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 9+ 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@public.gmane.org
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] 9+ messages in thread
* Re: [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
[not found] ` <CAL_JsqKWi=sNgOTTw6+PAxwgFyFQMw6BiUz0uNuG4kWr+ORO_g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2017-04-04 12:49 ` Neil Armstrong
2017-04-05 19:11 ` Rob Herring
0 siblings, 1 reply; 9+ 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@public.gmane.org
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] 9+ 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; 9+ 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@vger.kernel.org
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] 9+ messages in thread
end of thread, other threads:[~2017-04-05 19:11 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1490950079-10145-1-git-send-email-narmstrong@baylibre.com>
2017-03-31 8:47 ` [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings Neil Armstrong
[not found] ` <1490950079-10145-3-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
2017-03-31 13:44 ` Arnd Bergmann
2017-03-31 14:10 ` Neil Armstrong
[not found] ` <4ab7d4ee-e805-69f1-b76b-b827b46285bd-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
2017-04-03 16:34 ` Rob Herring
2017-04-04 8:51 ` Neil Armstrong
[not found] ` <265460a5-9295-f58a-f149-030e5dd750a1-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
2017-04-04 12:26 ` Rob Herring
[not found] ` <CAL_JsqKWi=sNgOTTw6+PAxwgFyFQMw6BiUz0uNuG4kWr+ORO_g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
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;
as well as URLs for NNTP newsgroup(s).