Re: [PATCH v2 5/9] ARM: dts: Move all Cygnus peripherals into soc bus

2015-09-23 Thread Ray Jui


On 9/23/2015 2:55 PM, Ray Jui wrote:
> 
> 
> On 9/23/2015 2:29 PM, Arnd Bergmann wrote:
>> On Friday 18 September 2015 15:11:27 Ray Jui wrote:
>>> On 9/18/2015 2:34 PM, Arnd Bergmann wrote:
 On Friday 18 September 2015 14:24:10 Ray Jui wrote:
> +   soc {
> +   compatible = "simple-bus";
> +   ranges;
> +   #address-cells = <1>;
> +   #size-cells = <1>;

> +   pinctrl: pinctrl@0301d0c8 {
>

 Similarly to the core bus, this seems to have address ranges 0x03xx and
 0x18xx on it, so put those into the ranges.

>>>
>>> Okay we have an issue here. For whatever reason, the Cygnus ASIC team
>>> decided to put registers for the same block in random locations. We see
>>> similar issues in all of our other iProc based SoCs. We have
>>> communicated this to our ASIC team, and hopefully they can revert the
>>> trend for the next SoC.
>>>
>>> For example, the gpio_ccm has registers in the following regions:
>>>
>>> gpio_ccm: gpio@1800a000 {
>>> compatible = "brcm,cygnus-ccm-gpio";
>>> reg = <0x1800a000 0x50>,
>>>   <0x0301d164 0x20>;
>>>
>>> NAND is worse, it has registers in 3 different separate regions:
>>>
>>> nand: nand@18046000 {
>>> compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1",
>>>  "brcm,brcmnand";
>>> reg = <0x18046000 0x600>, <0xf8105408 0x600>,
>>>   <0x18046f00 0x20>;
>>>
>>> As you can see, this makes it impossible to define a proper address
>>> range for the bus; therefore, I'll have to keep the ranges undefined and
>>> a simple 1:1 mapping under this bus.
>>
>> Hmm, you could still try to list them as non-overlapping with other
>> buses on the root node like
>>
>>  ranges = <0x0300 0x0300 0x0100>,
>>   <0x1800 0x1800 0x0100>,
>>   <0xf800 0xf800 0x0100>;
>>
>> which clarifies how the bus is wired up in hardware.
>>
>> Alternatively, you could make a more elaborate mapping, if there
>> are in fact multiple hardware ranges, like
>>
>>  #address-cells = <2>; # space:offset
>>  ranges = <1 0  0x0300 0x0100>,
>>   <2 0  0x1800 0x0100>,
>>   <3 0  0xf800 0x0100>;
>>
>> It really depends on what the hardware designers were thinking. If
>> the AXI bus actually decodes the entire 32-bit address range and devices
>> are just located at random addresses in there, your current scheme is
>> probably closest to reality.
>>
> 
> I see. Let me talk to our ASIC team to get this clarified. If in the end
> the AXI bus decodes the entire 32-bit address space, no change will be
> made. Otherwise, I'll submit another patch to list the actual address
> space that the AXI bus decodes.
> 
> Thanks for the review. It's very helpful!
> 
> Ray
> 

I just got feedback from our ASIC team. The NIC-301 is the main AXI
fabric that decodes the entire 32-bit address space on Cygnus.

I'll keep this as it is for now.

Thanks,

Ray
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 5/9] ARM: dts: Move all Cygnus peripherals into soc bus

2015-09-23 Thread Ray Jui


On 9/23/2015 2:29 PM, Arnd Bergmann wrote:
> On Friday 18 September 2015 15:11:27 Ray Jui wrote:
>> On 9/18/2015 2:34 PM, Arnd Bergmann wrote:
>>> On Friday 18 September 2015 14:24:10 Ray Jui wrote:
 +   soc {
 +   compatible = "simple-bus";
 +   ranges;
 +   #address-cells = <1>;
 +   #size-cells = <1>;
>>>
 +   pinctrl: pinctrl@0301d0c8 {

>>>
>>> Similarly to the core bus, this seems to have address ranges 0x03xx and
>>> 0x18xx on it, so put those into the ranges.
>>>
>>
>> Okay we have an issue here. For whatever reason, the Cygnus ASIC team
>> decided to put registers for the same block in random locations. We see
>> similar issues in all of our other iProc based SoCs. We have
>> communicated this to our ASIC team, and hopefully they can revert the
>> trend for the next SoC.
>>
>> For example, the gpio_ccm has registers in the following regions:
>>
>> gpio_ccm: gpio@1800a000 {
>> compatible = "brcm,cygnus-ccm-gpio";
>> reg = <0x1800a000 0x50>,
>>   <0x0301d164 0x20>;
>>
>> NAND is worse, it has registers in 3 different separate regions:
>>
>> nand: nand@18046000 {
>> compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1",
>>  "brcm,brcmnand";
>> reg = <0x18046000 0x600>, <0xf8105408 0x600>,
>>   <0x18046f00 0x20>;
>>
>> As you can see, this makes it impossible to define a proper address
>> range for the bus; therefore, I'll have to keep the ranges undefined and
>> a simple 1:1 mapping under this bus.
> 
> Hmm, you could still try to list them as non-overlapping with other
> buses on the root node like
> 
>   ranges = <0x0300 0x0300 0x0100>,
><0x1800 0x1800 0x0100>,
><0xf800 0xf800 0x0100>;
> 
> which clarifies how the bus is wired up in hardware.
> 
> Alternatively, you could make a more elaborate mapping, if there
> are in fact multiple hardware ranges, like
> 
>   #address-cells = <2>; # space:offset
>   ranges = <1 0  0x0300 0x0100>,
><2 0  0x1800 0x0100>,
><3 0  0xf800 0x0100>;
> 
> It really depends on what the hardware designers were thinking. If
> the AXI bus actually decodes the entire 32-bit address range and devices
> are just located at random addresses in there, your current scheme is
> probably closest to reality.
> 

I see. Let me talk to our ASIC team to get this clarified. If in the end
the AXI bus decodes the entire 32-bit address space, no change will be
made. Otherwise, I'll submit another patch to list the actual address
space that the AXI bus decodes.

Thanks for the review. It's very helpful!

Ray
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 5/9] ARM: dts: Move all Cygnus peripherals into soc bus

2015-09-23 Thread Arnd Bergmann
On Friday 18 September 2015 15:11:27 Ray Jui wrote:
> On 9/18/2015 2:34 PM, Arnd Bergmann wrote:
> > On Friday 18 September 2015 14:24:10 Ray Jui wrote:
> >> +   soc {
> >> +   compatible = "simple-bus";
> >> +   ranges;
> >> +   #address-cells = <1>;
> >> +   #size-cells = <1>;
> > 
> >> +   pinctrl: pinctrl@0301d0c8 {
> >>
> > 
> > Similarly to the core bus, this seems to have address ranges 0x03xx and
> > 0x18xx on it, so put those into the ranges.
> >
> 
> Okay we have an issue here. For whatever reason, the Cygnus ASIC team
> decided to put registers for the same block in random locations. We see
> similar issues in all of our other iProc based SoCs. We have
> communicated this to our ASIC team, and hopefully they can revert the
> trend for the next SoC.
> 
> For example, the gpio_ccm has registers in the following regions:
> 
> gpio_ccm: gpio@1800a000 {
> compatible = "brcm,cygnus-ccm-gpio";
> reg = <0x1800a000 0x50>,
>   <0x0301d164 0x20>;
> 
> NAND is worse, it has registers in 3 different separate regions:
> 
> nand: nand@18046000 {
> compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1",
>  "brcm,brcmnand";
> reg = <0x18046000 0x600>, <0xf8105408 0x600>,
>   <0x18046f00 0x20>;
> 
> As you can see, this makes it impossible to define a proper address
> range for the bus; therefore, I'll have to keep the ranges undefined and
> a simple 1:1 mapping under this bus.

Hmm, you could still try to list them as non-overlapping with other
buses on the root node like

ranges = <0x0300 0x0300 0x0100>,
 <0x1800 0x1800 0x0100>,
 <0xf800 0xf800 0x0100>;

which clarifies how the bus is wired up in hardware.

Alternatively, you could make a more elaborate mapping, if there
are in fact multiple hardware ranges, like

#address-cells = <2>; # space:offset
ranges = <1 0  0x0300 0x0100>,
 <2 0  0x1800 0x0100>,
 <3 0  0xf800 0x0100>;

It really depends on what the hardware designers were thinking. If
the AXI bus actually decodes the entire 32-bit address range and devices
are just located at random addresses in there, your current scheme is
probably closest to reality.

> > It probably also makes sense to name the bus according to what kind of
> > bus (axi, ahb, plb, ...) is used here. If the soc has nested buses
> > (e.g. an ahb connected to an axi bus,) then model both of them in the DT.
> 
> Based on the block diagram from the ASIC team, it looks like all of them
> are connected to one major AXI fabric. I can rename the bus to AXI.

Ok.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 5/9] ARM: dts: Move all Cygnus peripherals into soc bus

2015-09-23 Thread Ray Jui


On 9/23/2015 2:55 PM, Ray Jui wrote:
> 
> 
> On 9/23/2015 2:29 PM, Arnd Bergmann wrote:
>> On Friday 18 September 2015 15:11:27 Ray Jui wrote:
>>> On 9/18/2015 2:34 PM, Arnd Bergmann wrote:
 On Friday 18 September 2015 14:24:10 Ray Jui wrote:
> +   soc {
> +   compatible = "simple-bus";
> +   ranges;
> +   #address-cells = <1>;
> +   #size-cells = <1>;

> +   pinctrl: pinctrl@0301d0c8 {
>

 Similarly to the core bus, this seems to have address ranges 0x03xx and
 0x18xx on it, so put those into the ranges.

>>>
>>> Okay we have an issue here. For whatever reason, the Cygnus ASIC team
>>> decided to put registers for the same block in random locations. We see
>>> similar issues in all of our other iProc based SoCs. We have
>>> communicated this to our ASIC team, and hopefully they can revert the
>>> trend for the next SoC.
>>>
>>> For example, the gpio_ccm has registers in the following regions:
>>>
>>> gpio_ccm: gpio@1800a000 {
>>> compatible = "brcm,cygnus-ccm-gpio";
>>> reg = <0x1800a000 0x50>,
>>>   <0x0301d164 0x20>;
>>>
>>> NAND is worse, it has registers in 3 different separate regions:
>>>
>>> nand: nand@18046000 {
>>> compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1",
>>>  "brcm,brcmnand";
>>> reg = <0x18046000 0x600>, <0xf8105408 0x600>,
>>>   <0x18046f00 0x20>;
>>>
>>> As you can see, this makes it impossible to define a proper address
>>> range for the bus; therefore, I'll have to keep the ranges undefined and
>>> a simple 1:1 mapping under this bus.
>>
>> Hmm, you could still try to list them as non-overlapping with other
>> buses on the root node like
>>
>>  ranges = <0x0300 0x0300 0x0100>,
>>   <0x1800 0x1800 0x0100>,
>>   <0xf800 0xf800 0x0100>;
>>
>> which clarifies how the bus is wired up in hardware.
>>
>> Alternatively, you could make a more elaborate mapping, if there
>> are in fact multiple hardware ranges, like
>>
>>  #address-cells = <2>; # space:offset
>>  ranges = <1 0  0x0300 0x0100>,
>>   <2 0  0x1800 0x0100>,
>>   <3 0  0xf800 0x0100>;
>>
>> It really depends on what the hardware designers were thinking. If
>> the AXI bus actually decodes the entire 32-bit address range and devices
>> are just located at random addresses in there, your current scheme is
>> probably closest to reality.
>>
> 
> I see. Let me talk to our ASIC team to get this clarified. If in the end
> the AXI bus decodes the entire 32-bit address space, no change will be
> made. Otherwise, I'll submit another patch to list the actual address
> space that the AXI bus decodes.
> 
> Thanks for the review. It's very helpful!
> 
> Ray
> 

I just got feedback from our ASIC team. The NIC-301 is the main AXI
fabric that decodes the entire 32-bit address space on Cygnus.

I'll keep this as it is for now.

Thanks,

Ray
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 5/9] ARM: dts: Move all Cygnus peripherals into soc bus

2015-09-23 Thread Arnd Bergmann
On Friday 18 September 2015 15:11:27 Ray Jui wrote:
> On 9/18/2015 2:34 PM, Arnd Bergmann wrote:
> > On Friday 18 September 2015 14:24:10 Ray Jui wrote:
> >> +   soc {
> >> +   compatible = "simple-bus";
> >> +   ranges;
> >> +   #address-cells = <1>;
> >> +   #size-cells = <1>;
> > 
> >> +   pinctrl: pinctrl@0301d0c8 {
> >>
> > 
> > Similarly to the core bus, this seems to have address ranges 0x03xx and
> > 0x18xx on it, so put those into the ranges.
> >
> 
> Okay we have an issue here. For whatever reason, the Cygnus ASIC team
> decided to put registers for the same block in random locations. We see
> similar issues in all of our other iProc based SoCs. We have
> communicated this to our ASIC team, and hopefully they can revert the
> trend for the next SoC.
> 
> For example, the gpio_ccm has registers in the following regions:
> 
> gpio_ccm: gpio@1800a000 {
> compatible = "brcm,cygnus-ccm-gpio";
> reg = <0x1800a000 0x50>,
>   <0x0301d164 0x20>;
> 
> NAND is worse, it has registers in 3 different separate regions:
> 
> nand: nand@18046000 {
> compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1",
>  "brcm,brcmnand";
> reg = <0x18046000 0x600>, <0xf8105408 0x600>,
>   <0x18046f00 0x20>;
> 
> As you can see, this makes it impossible to define a proper address
> range for the bus; therefore, I'll have to keep the ranges undefined and
> a simple 1:1 mapping under this bus.

Hmm, you could still try to list them as non-overlapping with other
buses on the root node like

ranges = <0x0300 0x0300 0x0100>,
 <0x1800 0x1800 0x0100>,
 <0xf800 0xf800 0x0100>;

which clarifies how the bus is wired up in hardware.

Alternatively, you could make a more elaborate mapping, if there
are in fact multiple hardware ranges, like

#address-cells = <2>; # space:offset
ranges = <1 0  0x0300 0x0100>,
 <2 0  0x1800 0x0100>,
 <3 0  0xf800 0x0100>;

It really depends on what the hardware designers were thinking. If
the AXI bus actually decodes the entire 32-bit address range and devices
are just located at random addresses in there, your current scheme is
probably closest to reality.

> > It probably also makes sense to name the bus according to what kind of
> > bus (axi, ahb, plb, ...) is used here. If the soc has nested buses
> > (e.g. an ahb connected to an axi bus,) then model both of them in the DT.
> 
> Based on the block diagram from the ASIC team, it looks like all of them
> are connected to one major AXI fabric. I can rename the bus to AXI.

Ok.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 5/9] ARM: dts: Move all Cygnus peripherals into soc bus

2015-09-23 Thread Ray Jui


On 9/23/2015 2:29 PM, Arnd Bergmann wrote:
> On Friday 18 September 2015 15:11:27 Ray Jui wrote:
>> On 9/18/2015 2:34 PM, Arnd Bergmann wrote:
>>> On Friday 18 September 2015 14:24:10 Ray Jui wrote:
 +   soc {
 +   compatible = "simple-bus";
 +   ranges;
 +   #address-cells = <1>;
 +   #size-cells = <1>;
>>>
 +   pinctrl: pinctrl@0301d0c8 {

>>>
>>> Similarly to the core bus, this seems to have address ranges 0x03xx and
>>> 0x18xx on it, so put those into the ranges.
>>>
>>
>> Okay we have an issue here. For whatever reason, the Cygnus ASIC team
>> decided to put registers for the same block in random locations. We see
>> similar issues in all of our other iProc based SoCs. We have
>> communicated this to our ASIC team, and hopefully they can revert the
>> trend for the next SoC.
>>
>> For example, the gpio_ccm has registers in the following regions:
>>
>> gpio_ccm: gpio@1800a000 {
>> compatible = "brcm,cygnus-ccm-gpio";
>> reg = <0x1800a000 0x50>,
>>   <0x0301d164 0x20>;
>>
>> NAND is worse, it has registers in 3 different separate regions:
>>
>> nand: nand@18046000 {
>> compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1",
>>  "brcm,brcmnand";
>> reg = <0x18046000 0x600>, <0xf8105408 0x600>,
>>   <0x18046f00 0x20>;
>>
>> As you can see, this makes it impossible to define a proper address
>> range for the bus; therefore, I'll have to keep the ranges undefined and
>> a simple 1:1 mapping under this bus.
> 
> Hmm, you could still try to list them as non-overlapping with other
> buses on the root node like
> 
>   ranges = <0x0300 0x0300 0x0100>,
><0x1800 0x1800 0x0100>,
><0xf800 0xf800 0x0100>;
> 
> which clarifies how the bus is wired up in hardware.
> 
> Alternatively, you could make a more elaborate mapping, if there
> are in fact multiple hardware ranges, like
> 
>   #address-cells = <2>; # space:offset
>   ranges = <1 0  0x0300 0x0100>,
><2 0  0x1800 0x0100>,
><3 0  0xf800 0x0100>;
> 
> It really depends on what the hardware designers were thinking. If
> the AXI bus actually decodes the entire 32-bit address range and devices
> are just located at random addresses in there, your current scheme is
> probably closest to reality.
> 

I see. Let me talk to our ASIC team to get this clarified. If in the end
the AXI bus decodes the entire 32-bit address space, no change will be
made. Otherwise, I'll submit another patch to list the actual address
space that the AXI bus decodes.

Thanks for the review. It's very helpful!

Ray
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 5/9] ARM: dts: Move all Cygnus peripherals into soc bus

2015-09-18 Thread Ray Jui


On 9/18/2015 2:34 PM, Arnd Bergmann wrote:
> On Friday 18 September 2015 14:24:10 Ray Jui wrote:
>> +   soc {
>> +   compatible = "simple-bus";
>> +   ranges;
>> +   #address-cells = <1>;
>> +   #size-cells = <1>;
> 
>> +   pinctrl: pinctrl@0301d0c8 {
>>
> 
> Similarly to the core bus, this seems to have address ranges 0x03xx and
> 0x18xx on it, so put those into the ranges.
>

Okay we have an issue here. For whatever reason, the Cygnus ASIC team
decided to put registers for the same block in random locations. We see
similar issues in all of our other iProc based SoCs. We have
communicated this to our ASIC team, and hopefully they can revert the
trend for the next SoC.

For example, the gpio_ccm has registers in the following regions:

gpio_ccm: gpio@1800a000 {
compatible = "brcm,cygnus-ccm-gpio";
reg = <0x1800a000 0x50>,
  <0x0301d164 0x20>;

NAND is worse, it has registers in 3 different separate regions:

nand: nand@18046000 {
compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1",
 "brcm,brcmnand";
reg = <0x18046000 0x600>, <0xf8105408 0x600>,
  <0x18046f00 0x20>;

As you can see, this makes it impossible to define a proper address
range for the bus; therefore, I'll have to keep the ranges undefined and
a simple 1:1 mapping under this bus.

> It probably also makes sense to name the bus according to what kind of
> bus (axi, ahb, plb, ...) is used here. If the soc has nested buses
> (e.g. an ahb connected to an axi bus,) then model both of them in the DT.

Based on the block diagram from the ASIC team, it looks like all of them
are connected to one major AXI fabric. I can rename the bus to AXI.

> 
>   Arnd
> 

Thanks,

Ray
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 5/9] ARM: dts: Move all Cygnus peripherals into soc bus

2015-09-18 Thread Arnd Bergmann
On Friday 18 September 2015 14:24:10 Ray Jui wrote:
> +   soc {
> +   compatible = "simple-bus";
> +   ranges;
> +   #address-cells = <1>;
> +   #size-cells = <1>;

> +   pinctrl: pinctrl@0301d0c8 {
> 

Similarly to the core bus, this seems to have address ranges 0x03xx and
0x18xx on it, so put those into the ranges.

It probably also makes sense to name the bus according to what kind of
bus (axi, ahb, plb, ...) is used here. If the soc has nested buses
(e.g. an ahb connected to an axi bus,) then model both of them in the DT.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 5/9] ARM: dts: Move all Cygnus peripherals into soc bus

2015-09-18 Thread Ray Jui
Move all Cygnus peripherals to be under the "soc" bus node of type
"simple-bus"

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi | 275 +++---
 1 file changed, 138 insertions(+), 137 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index d4e2d04..3d29b77 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -88,171 +88,172 @@
};
};
 
-   pinctrl: pinctrl@0x0301d0c8 {
-   compatible = "brcm,cygnus-pinmux";
-   reg = <0x0301d0c8 0x30>,
- <0x0301d24c 0x2c>;
-   };
+   soc {
+   compatible = "simple-bus";
+   ranges;
+   #address-cells = <1>;
+   #size-cells = <1>;
 
-   gpio_crmu: gpio@03024800 {
-   compatible = "brcm,cygnus-crmu-gpio";
-   reg = <0x03024800 0x50>,
- <0x03024008 0x18>;
-   #gpio-cells = <2>;
-   gpio-controller;
-   };
+   pinctrl: pinctrl@0301d0c8 {
+   compatible = "brcm,cygnus-pinmux";
+   reg = <0x0301d0c8 0x30>,
+ <0x0301d24c 0x2c>;
+   };
 
-   gpio_ccm: gpio@1800a000 {
-   compatible = "brcm,cygnus-ccm-gpio";
-   reg = <0x1800a000 0x50>,
- <0x0301d164 0x20>;
-   #gpio-cells = <2>;
-   gpio-controller;
-   interrupts = ;
-   interrupt-controller;
-   };
+   gpio_crmu: gpio@03024800 {
+   compatible = "brcm,cygnus-crmu-gpio";
+   reg = <0x03024800 0x50>,
+ <0x03024008 0x18>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   };
 
-   gpio_asiu: gpio@180a5000 {
-   compatible = "brcm,cygnus-asiu-gpio";
-   reg = <0x180a5000 0x668>;
-   #gpio-cells = <2>;
-   gpio-controller;
+   gpio_ccm: gpio@1800a000 {
+   compatible = "brcm,cygnus-ccm-gpio";
+   reg = <0x1800a000 0x50>,
+ <0x0301d164 0x20>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   interrupts = ;
+   interrupt-controller;
+   };
 
-   pinmux = <>;
+   gpio_asiu: gpio@180a5000 {
+   compatible = "brcm,cygnus-asiu-gpio";
+   reg = <0x180a5000 0x668>;
+   #gpio-cells = <2>;
+   gpio-controller;
 
-   interrupt-controller;
-   interrupts = ;
-   };
+   pinmux = <>;
 
-   amba {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "arm,amba-bus", "simple-bus";
-   interrupt-parent = <>;
-   ranges;
+   interrupt-controller;
+   interrupts = ;
+   };
 
-   wdt@18009000 {
-compatible = "arm,sp805" , "arm,primecell";
-reg = <0x18009000 0x1000>;
-interrupts = ;
-clocks = <_clk>;
-clock-names = "apb_pclk";
+   wdt0: wdt@18009000 {
+   compatible = "arm,sp805" , "arm,primecell";
+   reg = <0x18009000 0x1000>;
+   interrupts = ;
+   clocks = <_clk>;
+   clock-names = "apb_pclk";
};
-   };
 
-   i2c0: i2c@18008000 {
-   compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
-   reg = <0x18008000 0x100>;
-   #address-cells = <1>;
-   #size-cells = <0>;
-   interrupts = ;
-   clock-frequency = <10>;
-   status = "disabled";
-   };
+   i2c0: i2c@18008000 {
+   compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
+   reg = <0x18008000 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clock-frequency = <10>;
+   status = "disabled";
+   };
 
-   i2c1: i2c@1800b000 {
-   compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
-   reg = <0x1800b000 0x100>;
-   #address-cells = <1>;
-   #size-cells = <0>;
-   interrupts = ;
-   clock-frequency = <10>;
-   status = "disabled";
-   };
+   i2c1: i2c@1800b000 {
+  

[PATCH v2 5/9] ARM: dts: Move all Cygnus peripherals into soc bus

2015-09-18 Thread Ray Jui
Move all Cygnus peripherals to be under the "soc" bus node of type
"simple-bus"

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi | 275 +++---
 1 file changed, 138 insertions(+), 137 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index d4e2d04..3d29b77 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -88,171 +88,172 @@
};
};
 
-   pinctrl: pinctrl@0x0301d0c8 {
-   compatible = "brcm,cygnus-pinmux";
-   reg = <0x0301d0c8 0x30>,
- <0x0301d24c 0x2c>;
-   };
+   soc {
+   compatible = "simple-bus";
+   ranges;
+   #address-cells = <1>;
+   #size-cells = <1>;
 
-   gpio_crmu: gpio@03024800 {
-   compatible = "brcm,cygnus-crmu-gpio";
-   reg = <0x03024800 0x50>,
- <0x03024008 0x18>;
-   #gpio-cells = <2>;
-   gpio-controller;
-   };
+   pinctrl: pinctrl@0301d0c8 {
+   compatible = "brcm,cygnus-pinmux";
+   reg = <0x0301d0c8 0x30>,
+ <0x0301d24c 0x2c>;
+   };
 
-   gpio_ccm: gpio@1800a000 {
-   compatible = "brcm,cygnus-ccm-gpio";
-   reg = <0x1800a000 0x50>,
- <0x0301d164 0x20>;
-   #gpio-cells = <2>;
-   gpio-controller;
-   interrupts = ;
-   interrupt-controller;
-   };
+   gpio_crmu: gpio@03024800 {
+   compatible = "brcm,cygnus-crmu-gpio";
+   reg = <0x03024800 0x50>,
+ <0x03024008 0x18>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   };
 
-   gpio_asiu: gpio@180a5000 {
-   compatible = "brcm,cygnus-asiu-gpio";
-   reg = <0x180a5000 0x668>;
-   #gpio-cells = <2>;
-   gpio-controller;
+   gpio_ccm: gpio@1800a000 {
+   compatible = "brcm,cygnus-ccm-gpio";
+   reg = <0x1800a000 0x50>,
+ <0x0301d164 0x20>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   interrupts = ;
+   interrupt-controller;
+   };
 
-   pinmux = <>;
+   gpio_asiu: gpio@180a5000 {
+   compatible = "brcm,cygnus-asiu-gpio";
+   reg = <0x180a5000 0x668>;
+   #gpio-cells = <2>;
+   gpio-controller;
 
-   interrupt-controller;
-   interrupts = ;
-   };
+   pinmux = <>;
 
-   amba {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "arm,amba-bus", "simple-bus";
-   interrupt-parent = <>;
-   ranges;
+   interrupt-controller;
+   interrupts = ;
+   };
 
-   wdt@18009000 {
-compatible = "arm,sp805" , "arm,primecell";
-reg = <0x18009000 0x1000>;
-interrupts = ;
-clocks = <_clk>;
-clock-names = "apb_pclk";
+   wdt0: wdt@18009000 {
+   compatible = "arm,sp805" , "arm,primecell";
+   reg = <0x18009000 0x1000>;
+   interrupts = ;
+   clocks = <_clk>;
+   clock-names = "apb_pclk";
};
-   };
 
-   i2c0: i2c@18008000 {
-   compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
-   reg = <0x18008000 0x100>;
-   #address-cells = <1>;
-   #size-cells = <0>;
-   interrupts = ;
-   clock-frequency = <10>;
-   status = "disabled";
-   };
+   i2c0: i2c@18008000 {
+   compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
+   reg = <0x18008000 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clock-frequency = <10>;
+   status = "disabled";
+   };
 
-   i2c1: i2c@1800b000 {
-   compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
-   reg = <0x1800b000 0x100>;
-   #address-cells = <1>;
-   #size-cells = <0>;
-   interrupts = ;
-   clock-frequency = <10>;
-   status = "disabled";
-   };
+ 

Re: [PATCH v2 5/9] ARM: dts: Move all Cygnus peripherals into soc bus

2015-09-18 Thread Arnd Bergmann
On Friday 18 September 2015 14:24:10 Ray Jui wrote:
> +   soc {
> +   compatible = "simple-bus";
> +   ranges;
> +   #address-cells = <1>;
> +   #size-cells = <1>;

> +   pinctrl: pinctrl@0301d0c8 {
> 

Similarly to the core bus, this seems to have address ranges 0x03xx and
0x18xx on it, so put those into the ranges.

It probably also makes sense to name the bus according to what kind of
bus (axi, ahb, plb, ...) is used here. If the soc has nested buses
(e.g. an ahb connected to an axi bus,) then model both of them in the DT.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 5/9] ARM: dts: Move all Cygnus peripherals into soc bus

2015-09-18 Thread Ray Jui


On 9/18/2015 2:34 PM, Arnd Bergmann wrote:
> On Friday 18 September 2015 14:24:10 Ray Jui wrote:
>> +   soc {
>> +   compatible = "simple-bus";
>> +   ranges;
>> +   #address-cells = <1>;
>> +   #size-cells = <1>;
> 
>> +   pinctrl: pinctrl@0301d0c8 {
>>
> 
> Similarly to the core bus, this seems to have address ranges 0x03xx and
> 0x18xx on it, so put those into the ranges.
>

Okay we have an issue here. For whatever reason, the Cygnus ASIC team
decided to put registers for the same block in random locations. We see
similar issues in all of our other iProc based SoCs. We have
communicated this to our ASIC team, and hopefully they can revert the
trend for the next SoC.

For example, the gpio_ccm has registers in the following regions:

gpio_ccm: gpio@1800a000 {
compatible = "brcm,cygnus-ccm-gpio";
reg = <0x1800a000 0x50>,
  <0x0301d164 0x20>;

NAND is worse, it has registers in 3 different separate regions:

nand: nand@18046000 {
compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1",
 "brcm,brcmnand";
reg = <0x18046000 0x600>, <0xf8105408 0x600>,
  <0x18046f00 0x20>;

As you can see, this makes it impossible to define a proper address
range for the bus; therefore, I'll have to keep the ranges undefined and
a simple 1:1 mapping under this bus.

> It probably also makes sense to name the bus according to what kind of
> bus (axi, ahb, plb, ...) is used here. If the soc has nested buses
> (e.g. an ahb connected to an axi bus,) then model both of them in the DT.

Based on the block diagram from the ASIC team, it looks like all of them
are connected to one major AXI fabric. I can rename the bus to AXI.

> 
>   Arnd
> 

Thanks,

Ray
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/