diff mbox

[PATCHv3,1/6] ARM: dts: Add SoC level device tree support for LS1021A

Message ID 1410253952-15631-2-git-send-email-jingchang.lu@freescale.com (mailing list archive)
State New, archived
Headers show

Commit Message

Jingchang Lu Sept. 9, 2014, 9:12 a.m. UTC
From: Jingchang Lu <b35083@freescale.com>

Add Freescale LS1021A SoC device tree support

Signed-off-by: Nikhil Badola <nikhil.badola@freescale.com>
Signed-off-by: Chenhui Zhao <chenhui.zhao@freescale.com>
Signed-off-by: Suresh Gupta <suresh.gupta@freescale.com>
Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
Signed-off-by: Chao Fu <b44548@freescale.com>
Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: Jingchang Lu <jingchang.lu@freescale.com>
---
 arch/arm/boot/dts/ls1021a.dtsi | 670 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 670 insertions(+)
 create mode 100644 arch/arm/boot/dts/ls1021a.dtsi

Comments

Arnd Bergmann Sept. 9, 2014, 11:50 a.m. UTC | #1
On Tuesday 09 September 2014 17:12:27 Jingchang Lu wrote:

> +		dcfg: dcfg@1ee0000 {
> +			compatible = "fsl,ls1021a-dcfg";
> +			reg = <0x0 0x1ee0000 0x0 0x10000>;
> +		};
> +		scfg: scfg@1570000 {
> +			compatible = "fsl,ls1021a-scfg";
> +			reg = <0x0 0x1570000 0x0 0x10000>;
> +		};

Should these be marked as 'compatible = "syscon"' as well?

> +	dcsr {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		compatible = "fsl,dcsr", "simple-bus";
> +
> +		ranges = <0x0 0x0 0x20000000 0x1000000>;
> +
> +		dcsr-epu@0 {
> +			compatible = "fsl,ls1021a-dcsr-epu";
> +			reg = <0x0 0x10000>;
> +		};

The binding document only specifies a generic "fsl,dcsr-epu", not
"fsl,ls1021a-dcsr-epu". It also mandates that "interrupts"
must be present and contain three interrupt lines.

Please fix either the DT or the binding, so they match.	

> +		dcsr-gdi@100000 {
> +			compatible = "fsl,ls1021a-dcsr-gdi";
> +			reg = <0x100000 0x10000>;
> +		};
> +
> +		dcsr-dddi@120000 {
> +			compatible = "fsl,ls1021a-dcsr-dddi";
> +			reg = <0x120000 0x10000>;
> +		};
> +
> +		dcsr-dcfg@220000 {
> +			compatible = "fsl,ls1021a-dcsr-dcfg";
> +			reg = <0x220000 0x1000>;
> +		};
> +
> +		dcsr-clock@221000 {
> +			compatible = "fsl,ls1021a-dcsr-clock";
> +			reg = <0x221000 0x1000>;
> +		};

None of these are part of the dcsr.txt binding.

> +		dcsr-rcpm@222000 {
> +			compatible = "fsl,ls1021a-dcsr-rcpm";
> +			reg = <0x222000 0x1000 0x223000 0x1000>;
> +		};

Missing generic fsl,dcsr-rcpm compatible value again.

> +		dcsr-ccp@225000 {
> +			compatible = "fsl,ls1021a-dcsr-ccp";
> +			reg = <0x225000 0x1000>;
> +		};

I'm not checking any devices below this one, I assume they are mostly
incomplete, so please go through the whole list and make sure they
all match the documentation.
I can't really find any code using the dcsr in Linux. Is there
an out of tree driver that you plan to submit?

	Arnd
Arnd Bergmann Sept. 9, 2014, 11:53 a.m. UTC | #2
On Tuesday 09 September 2014 17:12:27 Jingchang Lu wrote:
> +       aliases {
> +               serial0 = &lpuart0;
> +               serial1 = &lpuart1;
> +               serial2 = &lpuart2;
> +               serial3 = &lpuart3;
> +               serial4 = &lpuart4;
> +               serial5 = &lpuart5;
> +               ethernet0 = &enet0;
> +               ethernet1 = &enet1;
> +               ethernet2 = &enet2;
> +               sysclk = &sysclk;
> +       };
> +
> +       memory@80000000 {
> +               device_type = "memory";
> +               reg = <0x0 0x80000000 0x0 0x20000000>;
> +       };
> +
> 


One more thing: these should all go into the board specific files.

The installed memory is almost always a property of the board, not the
SoC, and a lot of boards only connect a subset of the serial ports,
or they may have them in a different order.

In particular, you only provide aliases for the six out of the
ten available uarts, which seems arbitrary.

	Arnd
Jingchang Lu Sept. 11, 2014, 8:21 a.m. UTC | #3
>-----Original Message-----
>From: Arnd Bergmann [mailto:arnd@arndb.de]
>Sent: Tuesday, September 09, 2014 7:50 PM
>To: linux-arm-kernel@lists.infradead.org
>Cc: Lu Jingchang-B35083; Guo Shawn-R65073; devicetree@vger.kernel.org;
>Zhao Chenhui-B35336; Fu Chao-B44548; Leekha Shaveta-B20052; Gupta Suresh-
>B42813; Sharma Bhupesh-B45370; Xiubo Li-B47053; Gupta Ruchika-R66431; Lu
>Jingchang-B35083; Badola Nikhil-B46172
>Subject: Re: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for
>LS1021A
>
>On Tuesday 09 September 2014 17:12:27 Jingchang Lu wrote:
>
>> +		dcfg: dcfg@1ee0000 {
>> +			compatible = "fsl,ls1021a-dcfg";
>> +			reg = <0x0 0x1ee0000 0x0 0x10000>;
>> +		};
>> +		scfg: scfg@1570000 {
>> +			compatible = "fsl,ls1021a-scfg";
>> +			reg = <0x0 0x1570000 0x0 0x10000>;
>> +		};
>
>Should these be marked as 'compatible = "syscon"' as well?
Yes, some driver may reference them by the syscon driver, 
I will add the "syscon" compatible for driver has another reference way, thanks.

>
>> +	dcsr {
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		compatible = "fsl,dcsr", "simple-bus";
>> +
>> +		ranges = <0x0 0x0 0x20000000 0x1000000>;
>> +
>> +		dcsr-epu@0 {
>> +			compatible = "fsl,ls1021a-dcsr-epu";
>> +			reg = <0x0 0x10000>;
>> +		};
>
>The binding document only specifies a generic "fsl,dcsr-epu", not
>"fsl,ls1021a-dcsr-epu". It also mandates that "interrupts"
>must be present and contain three interrupt lines.
>
>Please fix either the DT or the binding, so they match.
>
>> +		dcsr-gdi@100000 {
>> +			compatible = "fsl,ls1021a-dcsr-gdi";
>> +			reg = <0x100000 0x10000>;
>> +		};
>> +
>> +		dcsr-dddi@120000 {
>> +			compatible = "fsl,ls1021a-dcsr-dddi";
>> +			reg = <0x120000 0x10000>;
>> +		};
>> +
>> +		dcsr-dcfg@220000 {
>> +			compatible = "fsl,ls1021a-dcsr-dcfg";
>> +			reg = <0x220000 0x1000>;
>> +		};
>> +
>> +		dcsr-clock@221000 {
>> +			compatible = "fsl,ls1021a-dcsr-clock";
>> +			reg = <0x221000 0x1000>;
>> +		};
>
>None of these are part of the dcsr.txt binding.
>
>> +		dcsr-rcpm@222000 {
>> +			compatible = "fsl,ls1021a-dcsr-rcpm";
>> +			reg = <0x222000 0x1000 0x223000 0x1000>;
>> +		};
>
>Missing generic fsl,dcsr-rcpm compatible value again.
>
>> +		dcsr-ccp@225000 {
>> +			compatible = "fsl,ls1021a-dcsr-ccp";
>> +			reg = <0x225000 0x1000>;
>> +		};
>
>I'm not checking any devices below this one, I assume they are mostly
>incomplete, so please go through the whole list and make sure they all
>match the documentation.
>I can't really find any code using the dcsr in Linux. Is there an out of
>tree driver that you plan to submit?
>
>	Arnd

I will remove these dcsr related nodes and leave them to be added later when
All ok. Thanks.


Best Regards,
Jingchang
Jingchang Lu Sept. 11, 2014, 8:21 a.m. UTC | #4
>-----Original Message-----
>From: Arnd Bergmann [mailto:arnd@arndb.de]
>Sent: Tuesday, September 09, 2014 7:53 PM
>To: linux-arm-kernel@lists.infradead.org
>Cc: Lu Jingchang-B35083; Guo Shawn-R65073; devicetree@vger.kernel.org;
>Zhao Chenhui-B35336; Fu Chao-B44548; Leekha Shaveta-B20052; Gupta Suresh-
>B42813; Sharma Bhupesh-B45370; Xiubo Li-B47053; Gupta Ruchika-R66431; Lu
>Jingchang-B35083; Badola Nikhil-B46172
>Subject: Re: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for
>LS1021A
>
>On Tuesday 09 September 2014 17:12:27 Jingchang Lu wrote:
>> +       aliases {
>> +               serial0 = &lpuart0;
>> +               serial1 = &lpuart1;
>> +               serial2 = &lpuart2;
>> +               serial3 = &lpuart3;
>> +               serial4 = &lpuart4;
>> +               serial5 = &lpuart5;
>> +               ethernet0 = &enet0;
>> +               ethernet1 = &enet1;
>> +               ethernet2 = &enet2;
>> +               sysclk = &sysclk;
>> +       };
>> +
>> +       memory@80000000 {
>> +               device_type = "memory";
>> +               reg = <0x0 0x80000000 0x0 0x20000000>;
>> +       };
>> +
>>
>
>
>One more thing: these should all go into the board specific files.
>
>The installed memory is almost always a property of the board, not the SoC,
>and a lot of boards only connect a subset of the serial ports, or they may
>have them in a different order.
>
>In particular, you only provide aliases for the six out of the ten
>available uarts, which seems arbitrary.
>
>	Arnd

The memory size info will be fixed up in u-boot before booting the kernel image,
so I add the memory node in the SoC level device tree and keep only one copy. 
The lpuart derives the line number from the node's alias id, 8250 serial driver
doesn't rely on it, so only aliases for the lpuart are added, not arbitrary.
Thanks.

Best Regards,
Jingchang
Suresh Gupta Sept. 11, 2014, 8:41 a.m. UTC | #5
> -----Original Message-----
> From: Jingchang Lu [mailto:jingchang.lu@freescale.com]
> Sent: Tuesday, September 09, 2014 2:42 PM
> To: Guo Shawn-R65073
> Cc: linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; Lu
> Jingchang-B35083; Badola Nikhil-B46172; Zhao Chenhui-B35336; Gupta Suresh-
> B42813; Leekha Shaveta-B20052; Gupta Ruchika-R66431; Sharma Bhupesh-
> B45370; Fu Chao-B44548; Xiubo Li-B47053; Lu Jingchang-B35083
> Subject: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
> 
> From: Jingchang Lu <b35083@freescale.com>
> 
> Add Freescale LS1021A SoC device tree support
> 
> +
> +		usb@3100000 {
> +			compatible = "fsl,fsl-dwc3";
> +			#address-cells = <2>;
> +			#size-cells = <2>;
> +			ranges;
> +
> +			dwc3 {
> +				compatible = "snps,dwc3";
> +				reg = <0x0 0x3100000 0x0 0x10000>;
> +				interrupts = <GIC_SPI 93
> IRQ_TYPE_LEVEL_HIGH>;
> +				dr_mode = "host";
> +				maximum-speed = "high-speed";
> +			};
> +		};
> +	};
> +
> +
[SuresH]  Can you please pick this node form ls1-linux -> ls1-dev branch
This node should look like


	usb3@3100000 {
                        compatible = "snps,dwc3";
                        reg = <0x0 0x3100000 0x0 0x10000>;
                        interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
                        dr_mode = "host";
                };
Jingchang Lu Sept. 11, 2014, 8:58 a.m. UTC | #6
>-----Original Message-----
>From: Gupta Suresh-B42813
>Sent: Thursday, September 11, 2014 4:42 PM
>To: Lu Jingchang-B35083; Guo Shawn-R65073
>Cc: linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; Lu
>Jingchang-B35083; Badola Nikhil-B46172; Zhao Chenhui-B35336; Leekha
>Shaveta-B20052; Gupta Ruchika-R66431; Sharma Bhupesh-B45370; Fu Chao-
>B44548; Xiubo Li-B47053; Lu Jingchang-B35083
>Subject: RE: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for
>LS1021A
>
>
>
>> -----Original Message-----
>> From: Jingchang Lu [mailto:jingchang.lu@freescale.com]
>> Sent: Tuesday, September 09, 2014 2:42 PM
>> To: Guo Shawn-R65073
>> Cc: linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org;
>> Lu Jingchang-B35083; Badola Nikhil-B46172; Zhao Chenhui-B35336; Gupta
>> Suresh- B42813; Leekha Shaveta-B20052; Gupta Ruchika-R66431; Sharma
>> Bhupesh- B45370; Fu Chao-B44548; Xiubo Li-B47053; Lu Jingchang-B35083
>> Subject: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for
>> LS1021A
>>
>> From: Jingchang Lu <b35083@freescale.com>
>>
>> Add Freescale LS1021A SoC device tree support
>>
>> +
>> +		usb@3100000 {
>> +			compatible = "fsl,fsl-dwc3";
>> +			#address-cells = <2>;
>> +			#size-cells = <2>;
>> +			ranges;
>> +
>> +			dwc3 {
>> +				compatible = "snps,dwc3";
>> +				reg = <0x0 0x3100000 0x0 0x10000>;
>> +				interrupts = <GIC_SPI 93
>> IRQ_TYPE_LEVEL_HIGH>;
>> +				dr_mode = "host";
>> +				maximum-speed = "high-speed";
>> +			};
>> +		};
>> +	};
>> +
>> +
>[SuresH]  Can you please pick this node form ls1-linux -> ls1-dev branch
>This node should look like
>
>
>	usb3@3100000 {
>                        compatible = "snps,dwc3";
>                        reg = <0x0 0x3100000 0x0 0x10000>;
>                        interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
>                        dr_mode = "host";
>                };

Ok, I will update it in the next version.

Best Regards,
Jingchang
nikhil.badola@freescale.com Sept. 11, 2014, 10:10 a.m. UTC | #7
>-----Original Message-----
>From: Jingchang Lu [mailto:jingchang.lu@freescale.com]
>Sent: Tuesday, September 09, 2014 2:42 PM
>To: Guo Shawn-R65073
>Cc: linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; Lu
>Jingchang-B35083; Badola Nikhil-B46172; Zhao Chenhui-B35336; Gupta Suresh-
>B42813; Leekha Shaveta-B20052; Gupta Ruchika-R66431; Sharma Bhupesh-
>B45370; Fu Chao-B44548; Xiubo Li-B47053; Lu Jingchang-B35083
>Subject: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
>
>From: Jingchang Lu <b35083@freescale.com>
>
>Add Freescale LS1021A SoC device tree support
>+
>+		usb@8600000 {
>+			compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
>+			reg = <0x0 0x8600000 0x0 0x1000>;
>+			#address-cells = <1>;
>+			#size-cells = <0>;
>+			interrupts = <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>;
>+			dr_mode = "host";
>+			phy_type = "ulpi";
>+		};
>+

Please remove following from the above node :  
			#address-cells = <1>;
			#size-cells = <0>;
Arnd Bergmann Sept. 11, 2014, 10:36 a.m. UTC | #8
On Thursday 11 September 2014 08:21:58 Jingchang Lu wrote:
> >One more thing: these should all go into the board specific files.
> >
> >The installed memory is almost always a property of the board, not the SoC,
> >and a lot of boards only connect a subset of the serial ports, or they may
> >have them in a different order.
> >
> >In particular, you only provide aliases for the six out of the ten
> >available uarts, which seems arbitrary.
> >
> 
> The memory size info will be fixed up in u-boot before booting the kernel image,
> so I add the memory node in the SoC level device tree and keep only one copy. 

Right. I wonder if it would make sense to just leave a placeholder in there
that does not look like a plausible memory size. I believe the common case today
is that we actually want to have the correct memory size in the board-level
dts file because the boot loader does not change that value. If your boot loader
does it, we probably don't want any default that may confuse users at all,
in particular in the per-soc file.

> The lpuart derives the line number from the node's alias id, 8250 serial driver
> doesn't rely on it, so only aliases for the lpuart are added, not arbitrary.

This is really bad though, for two reasons:

a) you are relying on current behavior of two kernel drivers that we may want to
change in the future. Unfortunately the two drivers don't do this consistently
today, but that's something we should fix in the kernel, not work around in
the hardware description.

b) for the lpuart case, you put a fixed device order in the soc-specific file,
without any guarantee that the board uses just the first x devices rather than
another random subset. The alias values are really meant to to correspond to
how the machine calls things, not how the SoC sees it.

	Arnd
Sascha Hauer Sept. 11, 2014, 11:12 a.m. UTC | #9
On Thu, Sep 11, 2014 at 12:36:50PM +0200, Arnd Bergmann wrote:
> On Thursday 11 September 2014 08:21:58 Jingchang Lu wrote:
> > >One more thing: these should all go into the board specific files.
> > >
> > >The installed memory is almost always a property of the board, not the SoC,
> > >and a lot of boards only connect a subset of the serial ports, or they may
> > >have them in a different order.
> > >
> > >In particular, you only provide aliases for the six out of the ten
> > >available uarts, which seems arbitrary.
> > >
> > 
> > The memory size info will be fixed up in u-boot before booting the kernel image,
> > so I add the memory node in the SoC level device tree and keep only one copy. 
> 
> Right. I wonder if it would make sense to just leave a placeholder in there
> that does not look like a plausible memory size.

The placeholder is already in skeleton.dtsi, no need to add it at SoC
level.

> I believe the common case today
> is that we actually want to have the correct memory size in the board-level
> dts file because the boot loader does not change that value. If your boot loader
> does it, we probably don't want any default that may confuse users at all,
> in particular in the per-soc file.
> 
> > The lpuart derives the line number from the node's alias id, 8250 serial driver
> > doesn't rely on it, so only aliases for the lpuart are added, not arbitrary.
> 
> This is really bad though, for two reasons:
> 
> a) you are relying on current behavior of two kernel drivers that we may want to
> change in the future. Unfortunately the two drivers don't do this consistently
> today, but that's something we should fix in the kernel, not work around in
> the hardware description.
> 
> b) for the lpuart case, you put a fixed device order in the soc-specific file,
> without any guarantee that the board uses just the first x devices rather than
> another random subset. The alias values are really meant to to correspond to
> how the machine calls things, not how the SoC sees it.

All i.MX SoCs have the aliases defined how the SoC sees the devices and
i.MX is not alone here.

I know that some people rather like to see the aliases correspond to the
numbers printed on the case or PCB, thus dropping the aliases from the
SoC dtsi and putting them into the board dts instead.

I think both the UART number from the datasheet and the number printed
on the case are valuable informations, we should come up with a way to
express both informations instead of argueing about the meaning of the
'serialx' alias. This shouldn't even be too hard, we could create
multiple aliases for the same device and let udev create links for
all of them.

Sascha
Jingchang Lu Sept. 12, 2014, 1:46 a.m. UTC | #10
>-----Original Message-----
>From: Badola Nikhil-B46172
>Sent: Thursday, September 11, 2014 6:11 PM
>To: Lu Jingchang-B35083; Guo Shawn-R65073
>Cc: linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; Lu
>Jingchang-B35083; Zhao Chenhui-B35336; Gupta Suresh-B42813; Leekha
>Shaveta-B20052; Gupta Ruchika-R66431; Sharma Bhupesh-B45370; Fu Chao-
>B44548; Xiubo Li-B47053; Lu Jingchang-B35083
>Subject: RE: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for
>LS1021A
>
>>-----Original Message-----
>>From: Jingchang Lu [mailto:jingchang.lu@freescale.com]
>>Sent: Tuesday, September 09, 2014 2:42 PM
>>To: Guo Shawn-R65073
>>Cc: linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org;
>>Lu Jingchang-B35083; Badola Nikhil-B46172; Zhao Chenhui-B35336; Gupta
>>Suresh- B42813; Leekha Shaveta-B20052; Gupta Ruchika-R66431; Sharma
>>Bhupesh- B45370; Fu Chao-B44548; Xiubo Li-B47053; Lu Jingchang-B35083
>>Subject: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for
>>LS1021A
>>
>>From: Jingchang Lu <b35083@freescale.com>
>>
>>Add Freescale LS1021A SoC device tree support
>>+
>>+		usb@8600000 {
>>+			compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
>>+			reg = <0x0 0x8600000 0x0 0x1000>;
>>+			#address-cells = <1>;
>>+			#size-cells = <0>;
>>+			interrupts = <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>;
>>+			dr_mode = "host";
>>+			phy_type = "ulpi";
>>+		};
>>+
>
>Please remove following from the above node :
>			#address-cells = <1>;
>			#size-cells = <0>;

Ok, thanks.



Best Regards,
Jingchang
Jingchang Lu Sept. 12, 2014, 9:59 a.m. UTC | #11
>-----Original Message-----
>From: Sascha Hauer [mailto:s.hauer@pengutronix.de]
>Sent: Thursday, September 11, 2014 7:12 PM
>To: Arnd Bergmann
>Cc: Lu Jingchang-B35083; linux-arm-kernel@lists.infradead.org; Guo Shawn-
>R65073; devicetree@vger.kernel.org; Zhao Chenhui-B35336; Fu Chao-B44548;
>Leekha Shaveta-B20052; Gupta Suresh-B42813; Sharma Bhupesh-B45370; Xiubo
>Li-B47053; Gupta Ruchika-R66431; Badola Nikhil-B46172
>Subject: Re: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for
>LS1021A
>
>On Thu, Sep 11, 2014 at 12:36:50PM +0200, Arnd Bergmann wrote:
>> On Thursday 11 September 2014 08:21:58 Jingchang Lu wrote:
>> > >One more thing: these should all go into the board specific files.
>> > >
>> > >The installed memory is almost always a property of the board, not
>> > >the SoC, and a lot of boards only connect a subset of the serial
>> > >ports, or they may have them in a different order.
>> > >
>> > >In particular, you only provide aliases for the six out of the ten
>> > >available uarts, which seems arbitrary.
>> > >
>> >
>> > The memory size info will be fixed up in u-boot before booting the
>> > kernel image, so I add the memory node in the SoC level device tree
>and keep only one copy.
>>
>> Right. I wonder if it would make sense to just leave a placeholder in
>> there that does not look like a plausible memory size.
>
>The placeholder is already in skeleton.dtsi, no need to add it at SoC
>level.
Thanks, I will remove the node in the SoC dtsi and use just that in
the skeleton64.dtsi instead.

>
>> I believe the common case today
>> is that we actually want to have the correct memory size in the
>> board-level dts file because the boot loader does not change that
>> value. If your boot loader does it, we probably don't want any default
>> that may confuse users at all, in particular in the per-soc file.
>>
>> > The lpuart derives the line number from the node's alias id, 8250
>> > serial driver doesn't rely on it, so only aliases for the lpuart are
>added, not arbitrary.
>>
>> This is really bad though, for two reasons:
>>
>> a) you are relying on current behavior of two kernel drivers that we
>> may want to change in the future. Unfortunately the two drivers don't
>> do this consistently today, but that's something we should fix in the
>> kernel, not work around in the hardware description.
>>
>> b) for the lpuart case, you put a fixed device order in the
>> soc-specific file, without any guarantee that the board uses just the
>> first x devices rather than another random subset. The alias values
>> are really meant to to correspond to how the machine calls things, not
>how the SoC sees it.
>
>All i.MX SoCs have the aliases defined how the SoC sees the devices and
>i.MX is not alone here.
>
>I know that some people rather like to see the aliases correspond to the
>numbers printed on the case or PCB, thus dropping the aliases from the SoC
>dtsi and putting them into the board dts instead.
>
>I think both the UART number from the datasheet and the number printed on
>the case are valuable informations, we should come up with a way to
>express both informations instead of argueing about the meaning of the
>'serialx' alias. This shouldn't even be too hard, we could create multiple
>aliases for the same device and let udev create links for all of them.
>
>Sascha

Then I will keep the only alias for the lpuart to make them working well currently.
Thanks.

Best Regards,
Jingchang
diff mbox

Patch

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
new file mode 100644
index 0000000..bc6ac30
--- /dev/null
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -0,0 +1,670 @@ 
+/*
+ * Copyright 2013-2014 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include "skeleton64.dtsi"
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	compatible = "fsl,ls1021a";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		serial0 = &lpuart0;
+		serial1 = &lpuart1;
+		serial2 = &lpuart2;
+		serial3 = &lpuart3;
+		serial4 = &lpuart4;
+		serial5 = &lpuart5;
+		ethernet0 = &enet0;
+		ethernet1 = &enet1;
+		ethernet2 = &enet2;
+		sysclk = &sysclk;
+	};
+
+	memory@80000000 {
+		device_type = "memory";
+		reg = <0x0 0x80000000 0x0 0x20000000>;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@f00 {
+			compatible = "arm,cortex-a7";
+			device_type = "cpu";
+			reg = <0xf00>;
+		};
+
+		cpu@f01 {
+			compatible = "arm,cortex-a7";
+			device_type = "cpu";
+			reg = <0xf01>;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts = 	<GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+				<GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+				<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+				<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
+	};
+
+	pmu {
+		compatible = "arm,cortex-a7-pmu";
+		interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>,
+				<GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		interrupt-parent = <&gic>;
+		ranges;
+
+		gic: interrupt-controller@1400000 {
+			compatible = "arm,cortex-a7-gic";
+			#interrupt-cells = <3>;
+			interrupt-controller;
+			reg = <0x0 0x1401000 0x0 0x1000>,
+				<0x0 0x1402000 0x0 0x1000>,
+				<0x0 0x1404000 0x0 0x2000>,
+				<0x0 0x1406000 0x0 0x2000>;
+			interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
+
+		};
+
+		ifc: ifc@1530000 {
+			compatible = "fsl,ifc", "simple-bus";
+			reg = <0x0 0x1530000 0x0 0x10000>;
+			interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		dcfg: dcfg@1ee0000 {
+			compatible = "fsl,ls1021a-dcfg";
+			reg = <0x0 0x1ee0000 0x0 0x10000>;
+		};
+
+		esdhc: esdhc@1560000 {
+			compatible = "fsl,esdhc";
+			reg = <0x0 0x1560000 0x0 0x10000>;
+			interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+			clock-frequency = <0>;
+			voltage-ranges = <1800 1800 3300 3300>;
+			sdhci,auto-cmd12;
+			big-endian;
+			bus-width = <4>;
+			status = "disabled";
+		};
+
+		scfg: scfg@1570000 {
+			compatible = "fsl,ls1021a-scfg";
+			reg = <0x0 0x1570000 0x0 0x10000>;
+		};
+
+		crypto: crypto@1700000 {
+			compatible = "fsl,sec-v5.3", "fsl,sec-v5.0", "fsl,sec-v4.0";
+			fsl,sec-era = <4>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg		 = <0x0 0x1700000 0x0 0x100000>;
+			ranges		 = <0x0 0x0 0x1700000 0x100000>;
+			interrupts	 = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
+
+			sec_jr0: jr@10000 {
+				compatible = "fsl,sec-v5.3-job-ring",
+				     "fsl,sec-v5.0-job-ring",
+				     "fsl,sec-v4.0-job-ring";
+				reg = <0x10000 0x10000>;
+				interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+			sec_jr1: jr@20000 {
+				compatible = "fsl,sec-v5.3-job-ring",
+				     "fsl,sec-v5.0-job-ring",
+				     "fsl,sec-v4.0-job-ring";
+				reg = <0x20000 0x10000>;
+				interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+			sec_jr2: jr@30000 {
+				compatible = "fsl,sec-v5.3-job-ring",
+				     "fsl,sec-v5.0-job-ring",
+				     "fsl,sec-v4.0-job-ring";
+				reg = <0x30000 0x10000>;
+				interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+			sec_jr3: jr@40000 {
+				compatible = "fsl,sec-v5.3-job-ring",
+				     "fsl,sec-v5.0-job-ring",
+				     "fsl,sec-v4.0-job-ring";
+				reg = <0x40000 0x10000>;
+				interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+		};
+
+		clockgen: clocking@1ee1000 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0x0 0x0 0x1ee1000 0x10000>;
+
+			sysclk: sysclk {
+				compatible = "fixed-clock";
+				#clock-cells = <0>;
+				clock-frequency = <100000000>;
+				clock-output-names = "sysclk";
+			};
+
+			cga_pll1: pll1@800 {
+				compatible = "fsl,qoriq-core-pll-2.0";
+				#clock-cells = <1>;
+				reg = <0x800 0x10>;
+				clocks = <&sysclk>;
+				clock-output-names = "cga-pll1", "cga-pll1-div2",
+						"cga-pll1-div3", "cga-pll1-div4";
+			};
+
+			platform_clk: pll@c00 {
+				compatible = "fsl,qoriq-core-pll-2.0";
+				#clock-cells = <1>;
+				reg = <0xc00 0x10>;
+				clocks = <&sysclk>;
+				clock-output-names = "platform-clk", "platform-clk-div2";
+			};
+
+			cluster1_clk: clk0c0@0 {
+				compatible = "fsl,qoriq-core-mux-2.0";
+				#clock-cells = <1>;
+				reg = <0x0 0x10>;
+				clock-names = "pll1cga", "pll1cga-div2";
+				clocks = <&cga_pll1 0>, <&cga_pll1 2>;
+				clock-output-names = "cluster1-clk";
+
+			};
+		};
+
+		dspi0: dspi@2100000 {
+			compatible = "fsl,vf610-dspi";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x0 0x2100000 0x0 0x10000>;
+			interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "dspi";
+			clocks = <&platform_clk 1>;
+			spi-num-chipselects = <5>;
+			big-endian;
+			status = "disabled";
+		};
+
+		dspi1: dspi@2110000 {
+			compatible = "fsl,vf610-dspi";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x0 0x2110000 0x0 0x10000>;
+			interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "dspi";
+			clocks = <&platform_clk 1>;
+			spi-num-chipselects = <5>;
+			big-endian;
+			status = "disabled";
+		};
+
+		i2c0: i2c@2180000 {
+			compatible = "fsl,vf610-i2c";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x0 0x2180000 0x0 0x10000>;
+			interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "i2c";
+			clocks = <&platform_clk 1>;
+			status = "disabled";
+		};
+
+		i2c1: i2c@2190000 {
+			compatible = "fsl,vf610-i2c";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x0 0x2190000 0x0 0x10000>;
+			interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "i2c";
+			clocks = <&platform_clk 1>;
+			status = "disabled";
+		};
+
+		i2c2: i2c@21a0000 {
+			compatible = "fsl,vf610-i2c";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x0 0x21a0000 0x0 0x10000>;
+			interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "i2c";
+			clocks = <&platform_clk 1>;
+			status = "disabled";
+		};
+
+		uart0: serial@21c0500 {
+			compatible = "fsl,16550-FIFO64", "ns16550a";
+			reg = <0x0 0x21c0500 0x0 0x100>;
+			interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+			clock-frequency = <0>;
+			fifo-size = <15>;
+			status = "disabled";
+		};
+
+		uart1: serial@21c0600 {
+			compatible = "fsl,16550-FIFO64", "ns16550a";
+			reg = <0x0 0x21c0600 0x0 0x100>;
+			interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+			clock-frequency = <0>;
+			fifo-size = <15>;
+			status = "disabled";
+		};
+
+		uart2: serial@21d0500 {
+			compatible = "fsl,16550-FIFO64", "ns16550a";
+			reg = <0x0 0x21d0500 0x0 0x100>;
+			interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+			clock-frequency = <0>;
+			fifo-size = <15>;
+			status = "disabled";
+		};
+
+		uart3: serial@21d0600 {
+			compatible = "fsl,16550-FIFO64", "ns16550a";
+			reg = <0x0 0x21d0600 0x0 0x100>;
+			interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+			clock-frequency = <0>;
+			fifo-size = <15>;
+			status = "disabled";
+		};
+
+		lpuart0: serial@2950000 {
+			compatible = "fsl,ls1021a-lpuart";
+			reg = <0x0 0x2950000 0x0 0x1000>;
+			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&sysclk>;
+			clock-names = "ipg";
+			status = "disabled";
+		};
+
+		lpuart1: serial@2960000 {
+			compatible = "fsl,ls1021a-lpuart";
+			reg = <0x0 0x2960000 0x0 0x1000>;
+			interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&platform_clk 1>;
+			clock-names = "ipg";
+			status = "disabled";
+		};
+
+		lpuart2: serial@2970000 {
+			compatible = "fsl,ls1021a-lpuart";
+			reg = <0x0 0x2970000 0x0 0x1000>;
+			interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&platform_clk 1>;
+			clock-names = "ipg";
+			status = "disabled";
+		};
+
+		lpuart3: serial@2980000 {
+			compatible = "fsl,ls1021a-lpuart";
+			reg = <0x0 0x2980000 0x0 0x1000>;
+			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&platform_clk 1>;
+			clock-names = "ipg";
+			status = "disabled";
+		};
+
+		lpuart4: serial@2990000 {
+			compatible = "fsl,ls1021a-lpuart";
+			reg = <0x0 0x2990000 0x0 0x1000>;
+			interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&platform_clk 1>;
+			clock-names = "ipg";
+			status = "disabled";
+		};
+
+		lpuart5: serial@29a0000 {
+			compatible = "fsl,ls1021a-lpuart";
+			reg = <0x0 0x29a0000 0x0 0x1000>;
+			interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&platform_clk 1>;
+			clock-names = "ipg";
+			status = "disabled";
+		};
+
+		ftm0_1: ftm0_1@29d0000 {
+			compatible = "fsl,ftm-timer";
+			reg = <0x0 0x29d0000 0x0 0x10000>,
+				<0x0 0x29e0000 0x0 0x10000>;
+			interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "ftm-evt", "ftm-src",
+			        "ftm-evt-counter-en", "ftm-src-counter-en";
+			clocks = <&platform_clk 1>, <&platform_clk 1>,
+			       <&platform_clk 1>, <&platform_clk 1>;
+			big-endian;
+			status = "disabled";
+		};
+
+		pwm3: ftm@2a00000 {
+			compatible = "fsl,vf610-ftm-pwm";
+			#pwm-cells = <3>;
+			reg = <0x0 0x2a00000 0x0 0x10000>;
+			interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "ftm_sys", "ftm_ext",
+				"ftm_fix", "ftm_cnt_clk_en";
+			clocks = <&platform_clk 1>, <&platform_clk 1>,
+				<&platform_clk 1>, <&platform_clk 1>;
+			big-endian;
+			status = "disabled";
+		};
+
+		pwm6: ftm@2a30000 {
+			compatible = "fsl,vf610-ftm-pwm";
+			#pwm-cells = <3>;
+			reg = <0x0 0x2a30000 0x0 0x10000>;
+			interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "ftm_sys", "ftm_ext",
+				"ftm_fix", "ftm_cnt_clk_en";
+			clocks = <&platform_clk 1>, <&platform_clk 1>,
+				<&platform_clk 1>, <&platform_clk 1>;
+			big-endian;
+			status = "disabled";
+		};
+
+		pwm7: ftm@2a40000 {
+			compatible = "fsl,vf610-ftm-pwm";
+			#pwm-cells = <3>;
+			reg = <0x0 0x2a40000 0x0 0x10000>;
+			interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "ftm_sys", "ftm_ext",
+				"ftm_fix", "ftm_cnt_clk_en";
+			clocks = <&platform_clk 1>, <&platform_clk 1>,
+				<&platform_clk 1>, <&platform_clk 1>;
+			big-endian;
+			status = "disabled";
+		};
+
+		wdog0: wdog@2ad0000 {
+			compatible = "fsl,imx21-wdt";
+			reg = <0x0 0x2ad0000 0x0 0x10000>;
+			interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&platform_clk 1>;
+			clock-names = "wdog";
+			big-endian;
+		};
+
+		sai1: sai@2b50000 {
+			compatible = "fsl,vf610-sai";
+			reg = <0x0 0x2b50000 0x0 0x10000>;
+			interrupts = <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&platform_clk 1>;
+			clock-names = "sai";
+			dma-names = "tx", "rx";
+			dmas = <&edma0 1 47>,
+				<&edma0 1 46>;
+			big-endian-regs;
+			status = "disabled";
+		};
+
+		sai2: sai@2b60000 {
+			compatible = "fsl,vf610-sai";
+			reg = <0x0 0x2b60000 0x0 0x10000>;
+			interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&platform_clk 1>;
+			clock-names = "sai";
+			dma-names = "tx", "rx";
+			dmas = <&edma0 1 45>,
+				<&edma0 1 44>;
+			big-endian-regs;
+			status = "disabled";
+		};
+
+		edma0: edma@2c00000 {
+			#dma-cells = <2>;
+			compatible = "fsl,vf610-edma";
+			reg = <0x0 0x2c00000 0x0 0x10000>,
+				<0x0 0x2c10000 0x0 0x10000>,
+				<0x0 0x2c20000 0x0 0x10000>;
+			interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "edma-tx", "edma-err";
+			dma-channels = <32>;
+			big-endian;
+			clock-names = "dmamux0", "dmamux1";
+			clocks = <&platform_clk 1>,
+				<&platform_clk 1>;
+		};
+
+		mdio0: mdio@2d24000 {
+			compatible = "gianfar";
+			device_type = "mdio";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x0 0x2d24000 0x0 0x4000>;
+		};
+
+		enet0: ethernet@2d10000 {
+			compatible = "fsl,etsec2";
+			device_type = "network";
+			#address-cells = <2>;
+			#size-cells = <2>;
+			interrupt-parent = <&gic>;
+			model = "eTSEC";
+			fsl,dma-endian-le;
+			fsl,num_rx_queues = <0x1>;
+			fsl,num_tx_queues = <0x1>;
+			ranges;
+
+			queue-group@0 {
+				#address-cells = <1>;
+				#size-cells = <1>;
+				reg = <0x0 0x2d10000 0x0 0x8000>;
+				fsl,rx-bit-map = <0xff>;
+				fsl,tx-bit-map = <0xff>;
+				interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+		};
+
+		enet1: ethernet@2d50000 {
+			compatible = "fsl,etsec2";
+			device_type = "network";
+			#address-cells = <2>;
+			#size-cells = <2>;
+			interrupt-parent = <&gic>;
+			model = "eTSEC";
+			fsl,dma-endian-le;
+			fsl,num_rx_queues = <0x1>;
+			fsl,num_tx_queues = <0x1>;
+			ranges;
+
+			queue-group@0 {
+				#address-cells = <1>;
+				#size-cells = <1>;
+				reg = <0x0 0x2d50000 0x0 0x8000>;
+				fsl,rx-bit-map = <0xff>;
+				fsl,tx-bit-map = <0xff>;
+				interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+		};
+
+		enet2: ethernet@2d90000 {
+			compatible = "fsl,etsec2";
+			device_type = "network";
+			#address-cells = <2>;
+			#size-cells = <2>;
+			interrupt-parent = <&gic>;
+			model = "eTSEC";
+			fsl,dma-endian-le;
+			fsl,num_rx_queues = <0x1>;
+			fsl,num_tx_queues = <0x1>;
+			ranges;
+
+			queue-group@0 {
+				#address-cells = <1>;
+				#size-cells = <1>;
+				reg = <0x0 0x2d90000 0x0 0x8000>;
+				fsl,rx-bit-map = <0xff>;
+				fsl,tx-bit-map = <0xff>;
+				interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>;
+			};
+		};
+
+		usb@8600000 {
+			compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
+			reg = <0x0 0x8600000 0x0 0x1000>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			interrupts = <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>;
+			dr_mode = "host";
+			phy_type = "ulpi";
+		};
+
+		usb@3100000 {
+			compatible = "fsl,fsl-dwc3";
+			#address-cells = <2>;
+			#size-cells = <2>;
+			ranges;
+
+			dwc3 {
+				compatible = "snps,dwc3";
+				reg = <0x0 0x3100000 0x0 0x10000>;
+				interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
+				dr_mode = "host";
+				maximum-speed = "high-speed";
+			};
+		};
+	};
+
+	dcsr {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "fsl,dcsr", "simple-bus";
+
+		ranges = <0x0 0x0 0x20000000 0x1000000>;
+
+		dcsr-epu@0 {
+			compatible = "fsl,ls1021a-dcsr-epu";
+			reg = <0x0 0x10000>;
+		};
+
+		dcsr-gdi@100000 {
+			compatible = "fsl,ls1021a-dcsr-gdi";
+			reg = <0x100000 0x10000>;
+		};
+
+		dcsr-dddi@120000 {
+			compatible = "fsl,ls1021a-dcsr-dddi";
+			reg = <0x120000 0x10000>;
+		};
+
+		dcsr-dcfg@220000 {
+			compatible = "fsl,ls1021a-dcsr-dcfg";
+			reg = <0x220000 0x1000>;
+		};
+
+		dcsr-clock@221000 {
+			compatible = "fsl,ls1021a-dcsr-clock";
+			reg = <0x221000 0x1000>;
+		};
+
+		dcsr-rcpm@222000 {
+			compatible = "fsl,ls1021a-dcsr-rcpm";
+			reg = <0x222000 0x1000 0x223000 0x1000>;
+		};
+
+		dcsr-ccp@225000 {
+			compatible = "fsl,ls1021a-dcsr-ccp";
+			reg = <0x225000 0x1000>;
+		};
+
+		dcsr-fusectrl@226000 {
+			compatible = "fsl,ls1021a-dcsr-fusectrl";
+			reg = <0x226000 0x1000>;
+		};
+
+		dcsr-dap@300000 {
+			compatible = "fsl,ls1021a-dcsr-dap";
+			reg = <0x300000 0x10000>;
+		};
+
+		dcsr-cstf@350000 {
+			compatible = "fsl,ls1021a-dcsr-cstf";
+			reg = <0x350000 0x1000 0x3a7000 0x1000>;
+		};
+
+		dcsr-a7rom@360000 {
+			compatible = "fsl,ls1021a-dcsr-a7rom";
+			reg = <0x360000 0x10000>;
+		};
+
+		dcsr-a7cpu@370000 {
+			compatible = "fsl,ls1021a-dcsr-a7cpu";
+			reg = <0x370000 0x8000>;
+		};
+
+		dcsr-a7cti@378000 {
+			compatible = "fsl,ls1021a-dcsr-a7cti";
+			reg = <0x378000 0x4000>;
+		};
+
+		dcsr-etm@37c000 {
+			compatible = "fsl,ls1021a-dcsr-etm";
+			reg = <0x37c000 0x1000 0x37d000 0x3000>;
+		};
+
+		dcsr-hugorom@3a0000 {
+			compatible = "fsl,ls1021a-dcsr-hugorom";
+			reg = <0x3a0000 0x1000>;
+		};
+
+		dcsr-etf@3a1000 {
+			compatible = "fsl,ls1021a-dcsr-etf";
+			reg = <0x3a1000 0x1000 0x3a2000 0x1000>;
+		};
+
+		dcsr-etr@3a3000 {
+			compatible = "fsl,ls1021a-dcsr-etr";
+			reg = <0x3a3000 0x1000>;
+		};
+
+		dcsr-cti@3a4000 {
+			compatible = "fsl,ls1021a-dcsr-cti";
+			reg = <0x3a4000 0x1000 0x3a5000 0x1000 0x3a6000 0x1000>;
+		};
+
+		dcsr-atbrepl@3a8000 {
+			compatible = "fsl,ls1021a-dcsr-atbrepl";
+			reg = <0x3a8000 0x1000>;
+		};
+
+		dcsr-tsgen-ctrl@3a9000 {
+			compatible = "fsl,ls1021a-dcsr-tsgen-ctrl";
+			reg = <0x3a9000 0x1000>;
+		};
+
+		dcsr-tsgen-read@3aa000 {
+			compatible = "fsl,ls1021a-dcsr-tsgen-read";
+			reg = <0x3aa000 0x1000>;
+		};
+	};
+};