diff mbox

[v2] powerpc/fsl-booke: Add T1040D4RDB/T1042D4RDB board support

Message ID 1436952655-14910-1-git-send-email-Priyanka.Jain@freescale.com (mailing list archive)
State Superseded
Headers show

Commit Message

Priyanka Jain July 15, 2015, 9:30 a.m. UTC
T1040D4RDB/T1042D4RDB are Freescale Reference Design Board
which can support T1040/T1042 QorIQ Power
Architecture™ processor respectively

T1040D4RDB/T1042D4RDB board Overview
-------------------------------------
- SERDES Connections, 8 lanes supporting:
        - PCI
        - SGMII
        - SATA 2.0
        - QSGMII(only for T1040D4RDB)
    - DDR Controller
        - Supports rates of up to 1600 MHz data-rate
        - Supports one DDR4 UDIMM
    -IFC/Local Bus
        - NAND flash: 1GB 8-bit NAND flash
        - NOR: 128MB 16-bit NOR Flash
    - Ethernet
        - Two on-board RGMII 10/100/1G ethernet ports.
        - PHY #0 remains powered up during deep-sleep
    - CPLD
    - Clocks
        - System and DDR clock (SYSCLK, “DDRCLK”)
        - SERDES clocks
    - Power Supplies
    - USB
        - Supports two USB 2.0 ports with integrated PHYs
        - Two type A ports with 5V@1.5A per port.
    - SDHC
        - SDHC/SDXC connector
    - SPI
        - On-board 64MB SPI flash
    - I2C
        - Devices connected: EEPROM, thermal monitor, VID controller
    - Other IO
        - Two Serial ports
        - ProfiBus port

    Add support for T1040/T1042D4RDB board:
    -add device tree
    -Add entry in corenet_generic.c

Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
---
 Changes for v2:
	Incorporated Scott's comments on device tree

 arch/powerpc/boot/dts/t1040d4rdb.dts          |   46 ++++++
 arch/powerpc/boot/dts/t1042d4rdb.dts          |   53 +++++++
 arch/powerpc/boot/dts/t104xd4rdb.dtsi         |  196 +++++++++++++++++++++++++
 arch/powerpc/platforms/85xx/corenet_generic.c |    2 +
 4 files changed, 297 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/t1040d4rdb.dts
 create mode 100644 arch/powerpc/boot/dts/t1042d4rdb.dts
 create mode 100644 arch/powerpc/boot/dts/t104xd4rdb.dtsi

Comments

Scott Wood July 15, 2015, 5:47 p.m. UTC | #1
On Wed, 2015-07-15 at 15:00 +0530, Priyanka Jain wrote:
> T1040D4RDB/T1042D4RDB are Freescale Reference Design Board
> which can support T1040/T1042 QorIQ Power
> Architecture™ processor respectively
> 
> T1040D4RDB/T1042D4RDB board Overview
> -------------------------------------
> - SERDES Connections, 8 lanes supporting:
>         - PCI
>         - SGMII
>         - SATA 2.0
>         - QSGMII(only for T1040D4RDB)
>     - DDR Controller
>         - Supports rates of up to 1600 MHz data-rate
>         - Supports one DDR4 UDIMM
>     -IFC/Local Bus
>         - NAND flash: 1GB 8-bit NAND flash
>         - NOR: 128MB 16-bit NOR Flash
>     - Ethernet
>         - Two on-board RGMII 10/100/1G ethernet ports.
>         - PHY #0 remains powered up during deep-sleep
>     - CPLD
>     - Clocks
>         - System and DDR clock (SYSCLK, “DDRCLK”)
>         - SERDES clocks
>     - Power Supplies
>     - USB
>         - Supports two USB 2.0 ports with integrated PHYs
>         - Two type A ports with  5V@1.5Aper port.
>     - SDHC
>         - SDHC/SDXC connector
>     - SPI
>         - On-board 64MB SPI flash
>     - I2C
>         - Devices connected: EEPROM, thermal monitor, VID controller
>     - Other IO
>         - Two Serial ports
>         - ProfiBus port
> 
>     Add support for T1040/T1042D4RDB board:
>     -add device tree
>     -Add entry in corenet_generic.c
> 
> Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
> ---
>  Changes for v2:
>       Incorporated Scott's comments on device tree

You didn't respond to the comments on the CPLD node.

+                i2c@118100{
> +                      mux@77{
> +                             compatible = "nxp,pca9546";
> +                             reg = <0x77>;
> +                             #address-cells = <1>;
> +                             #size-cells = <0>;
> +                     };
> +             };

A mux with no nodes under it (and yet it has #address-cells/#size-cells)?  
What is it multiplexing?

-Scott
Priyanka Jain July 16, 2015, 9:34 a.m. UTC | #2
-----Original Message-----
From: Wood Scott-B07421 

Sent: Wednesday, July 15, 2015 11:17 PM
To: Jain Priyanka-B32167
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add T1040D4RDB/T1042D4RDB board support

On Wed, 2015-07-15 at 15:00 +0530, Priyanka Jain wrote:
> T1040D4RDB/T1042D4RDB are Freescale Reference Design Board which can 

> support T1040/T1042 QorIQ Power Architecture™ processor respectively

> 

> T1040D4RDB/T1042D4RDB board Overview

> -------------------------------------

> - SERDES Connections, 8 lanes supporting:

>         - PCI

>         - SGMII

>         - SATA 2.0

>         - QSGMII(only for T1040D4RDB)

>     - DDR Controller

>         - Supports rates of up to 1600 MHz data-rate

>         - Supports one DDR4 UDIMM

>     -IFC/Local Bus

>         - NAND flash: 1GB 8-bit NAND flash

>         - NOR: 128MB 16-bit NOR Flash

>     - Ethernet

>         - Two on-board RGMII 10/100/1G ethernet ports.

>         - PHY #0 remains powered up during deep-sleep

>     - CPLD

>     - Clocks

>         - System and DDR clock (SYSCLK, “DDRCLK”)

>         - SERDES clocks

>     - Power Supplies

>     - USB

>         - Supports two USB 2.0 ports with integrated PHYs

>         - Two type A ports with  5V@1.5Aper port.

>     - SDHC

>         - SDHC/SDXC connector

>     - SPI

>         - On-board 64MB SPI flash

>     - I2C

>         - Devices connected: EEPROM, thermal monitor, VID controller

>     - Other IO

>         - Two Serial ports

>         - ProfiBus port

> 

>     Add support for T1040/T1042D4RDB board:

>     -add device tree

>     -Add entry in corenet_generic.c

> 

> Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>

> ---

>  Changes for v2:

>       Incorporated Scott's comments on device tree


You didn't respond to the comments on the CPLD node.
[Priyanka]
T1042D4RDB,  T1040D4RDB are derivatives of same board , CPLD is same for both.
So, I have moved below node having compatible and reg field together in t104xd4rdb.dtsi.
Is this fine?
		cpld@3,0 {
			compatible = "fsl,t1040d4rdb-cpld";
			reg = <3 0 0x300>;
		};


+                i2c@118100{
> +                      mux@77{

> +                             compatible = "nxp,pca9546";

> +                             reg = <0x77>;

> +                             #address-cells = <1>;

> +                             #size-cells = <0>;

> +                     };

> +             };


A mux with no nodes under it (and yet it has #address-cells/#size-cells)?  
What is it multiplexing?
[Priyanka]: PCA9546 is i2c mux device , to which other i2c devices (up-to 8 ) can be further connected on output channels
On T104xD4RDB,  channel 0, 1, 3 line are connected to PEX device, Channel 2 to hdmi interface (initialization is done in u-boot only), other channels are grounded. So, as such Linux is not using the second level I2C devices connected on this MUX device. So, I have not shown next level hierarchy.
Should I replace 'mux' with some other name? . Please suggest.


-Scott
Scott Wood July 16, 2015, 7:35 p.m. UTC | #3
On Thu, 2015-07-16 at 04:34 -0500, Jain Priyanka-B32167 wrote:
> 
> -----Original Message-----
> From: Wood Scott-B07421 
> Sent: Wednesday, July 15, 2015 11:17 PM
> To: Jain Priyanka-B32167
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add T1040D4RDB/T1042D4RDB board 
> support
> 
> On Wed, 2015-07-15 at 15:00 +0530, Priyanka Jain wrote:
> > T1040D4RDB/T1042D4RDB are Freescale Reference Design Board which can 
> > support T1040/T1042 QorIQ Power Architecture™ processor respectively
> > 
> > T1040D4RDB/T1042D4RDB board Overview
> > -------------------------------------
> > - SERDES Connections, 8 lanes supporting:
> >         - PCI
> >         - SGMII
> >         - SATA 2.0
> >         - QSGMII(only for T1040D4RDB)
> >     - DDR Controller
> >         - Supports rates of up to 1600 MHz data-rate
> >         - Supports one DDR4 UDIMM
> >     -IFC/Local Bus
> >         - NAND flash: 1GB 8-bit NAND flash
> >         - NOR: 128MB 16-bit NOR Flash
> >     - Ethernet
> >         - Two on-board RGMII 10/100/1G ethernet ports.
> >         - PHY #0 remains powered up during deep-sleep
> >     - CPLD
> >     - Clocks
> >         - System and DDR clock (SYSCLK, “DDRCLK”)
> >         - SERDES clocks
> >     - Power Supplies
> >     - USB
> >         - Supports two USB 2.0 ports with integrated PHYs
> >         - Two type A ports with   5V@1.5Aperport.
> >     - SDHC
> >         - SDHC/SDXC connector
> >     - SPI
> >         - On-board 64MB SPI flash
> >     - I2C
> >         - Devices connected: EEPROM, thermal monitor, VID controller
> >     - Other IO
> >         - Two Serial ports
> >         - ProfiBus port
> > 
> >     Add support for T1040/T1042D4RDB board:
> >     -add device tree
> >     -Add entry in corenet_generic.c
> > 
> > Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
> > ---
> >  Changes for v2:
> >       Incorporated Scott's comments on device tree
> 
> You didn't respond to the comments on the CPLD node.
> [Priyanka]
> T1042D4RDB,  T1040D4RDB are derivatives of same board , CPLD is same for 
> both.
> So, I have moved below node having compatible and reg field together in 
> t104xd4rdb.dtsi.
> Is this fine?
>               cpld@3,0 {
>                       compatible = "fsl,t1040d4rdb-cpld";
>                       reg = <3 0 0x300>;
>               };

If the CPLD image is exactly the same on both, this is fine.

> > +                i2c@118100{
> > +                      mux@77{
> > +                             compatible = "nxp,pca9546";
> > +                             reg = <0x77>;
> > +                             #address-cells = <1>;
> > +                             #size-cells = <0>;
> > +                     };
> > +             };
> 
> A mux with no nodes under it (and yet it has #address-cells/#size-cells)?  
> What is it multiplexing?
> [Priyanka]: PCA9546 is i2c mux device , to which other i2c devices (up-to 8 
> ) can be further connected on output channels
> On T104xD4RDB,  channel 0, 1, 3 line are connected to PEX device, Channel 2 
> to hdmi interface (initialization is done in u-boot only), other channels 
> are grounded. So, as such Linux is not using the second level I2C devices 
> connected on this MUX device. So, I have not shown next level hierarchy.
> Should I replace 'mux' with some other name? . Please suggest.

The device tree describes the hardware, not just what Linux uses... but what I
don't understand is why you describe the mux at all if you're not going to 
describe what goes underneath it.

-Scott
Priyanka Jain July 17, 2015, 6:17 a.m. UTC | #4
> -----Original Message-----

> From: Wood Scott-B07421

> Sent: Friday, July 17, 2015 1:06 AM

> To: Jain Priyanka-B32167

> Cc: linuxppc-dev@lists.ozlabs.org

> Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add T1040D4RDB/T1042D4RDB

> board support

> 

> On Thu, 2015-07-16 at 04:34 -0500, Jain Priyanka-B32167 wrote:

> >

> > -----Original Message-----

> > From: Wood Scott-B07421

> > Sent: Wednesday, July 15, 2015 11:17 PM

> > To: Jain Priyanka-B32167

> > Cc: linuxppc-dev@lists.ozlabs.org

> > Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add

> T1040D4RDB/T1042D4RDB

> > board support

> >

> > On Wed, 2015-07-15 at 15:00 +0530, Priyanka Jain wrote:

> > > T1040D4RDB/T1042D4RDB are Freescale Reference Design Board which

> can

> > > support T1040/T1042 QorIQ Power Architecture™ processor respectively

> > >

> > > T1040D4RDB/T1042D4RDB board Overview

> > > -------------------------------------

> > > - SERDES Connections, 8 lanes supporting:

> > >         - PCI

> > >         - SGMII

> > >         - SATA 2.0

> > >         - QSGMII(only for T1040D4RDB)

> > >     - DDR Controller

> > >         - Supports rates of up to 1600 MHz data-rate

> > >         - Supports one DDR4 UDIMM

> > >     -IFC/Local Bus

> > >         - NAND flash: 1GB 8-bit NAND flash

> > >         - NOR: 128MB 16-bit NOR Flash

> > >     - Ethernet

> > >         - Two on-board RGMII 10/100/1G ethernet ports.

> > >         - PHY #0 remains powered up during deep-sleep

> > >     - CPLD

> > >     - Clocks

> > >         - System and DDR clock (SYSCLK, “DDRCLK”)

> > >         - SERDES clocks

> > >     - Power Supplies

> > >     - USB

> > >         - Supports two USB 2.0 ports with integrated PHYs

> > >         - Two type A ports with   5V@1.5Aperport.

> > >     - SDHC

> > >         - SDHC/SDXC connector

> > >     - SPI

> > >         - On-board 64MB SPI flash

> > >     - I2C

> > >         - Devices connected: EEPROM, thermal monitor, VID controller

> > >     - Other IO

> > >         - Two Serial ports

> > >         - ProfiBus port

> > >

> > >     Add support for T1040/T1042D4RDB board:

> > >     -add device tree

> > >     -Add entry in corenet_generic.c

> > >

> > > Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>

> > > ---

> > >  Changes for v2:

> > >       Incorporated Scott's comments on device tree

> >

> > You didn't respond to the comments on the CPLD node.

> > [Priyanka]

> > T1042D4RDB,  T1040D4RDB are derivatives of same board , CPLD is same

> > for both.

> > So, I have moved below node having compatible and reg field together

> > in t104xd4rdb.dtsi.

> > Is this fine?

> >               cpld@3,0 {

> >                       compatible = "fsl,t1040d4rdb-cpld";

> >                       reg = <3 0 0x300>;

> >               };

> 

> If the CPLD image is exactly the same on both, this is fine.

> 

> > > +                i2c@118100{

> > > +                      mux@77{

> > > +                             compatible = "nxp,pca9546";

> > > +                             reg = <0x77>;

> > > +                             #address-cells = <1>;

> > > +                             #size-cells = <0>;

> > > +                     };

> > > +             };

> >

> > A mux with no nodes under it (and yet it has #address-cells/#size-cells)?

> > What is it multiplexing?

> > [Priyanka]: PCA9546 is i2c mux device , to which other i2c devices

> > (up-to 8

> > ) can be further connected on output channels On T104xD4RDB,  channel

> > 0, 1, 3 line are connected to PEX device, Channel 2 to hdmi interface

> > (initialization is done in u-boot only), other channels are grounded.

> > So, as such Linux is not using the second level I2C devices connected

> > on this MUX device. So, I have not shown next level hierarchy.

> > Should I replace 'mux' with some other name? . Please suggest.

> 

> The device tree describes the hardware, not just what Linux uses... but what

> I don't understand is why you describe the mux at all if you're not going to

> describe what goes underneath it.

> 

[Jain Priyanka-B32167] : Is below looks OK?
i2c@118100{
 +                      i2c@77{
 +                             compatible = "nxp,pca9546";
 +                             reg = <0x77>;
 +                             #address-cells = <1>;
 +                             #size-cells = <0>;
 +                     };
 +             };
> -Scott
Scott Wood July 17, 2015, 5:07 p.m. UTC | #5
On Fri, 2015-07-17 at 01:17 -0500, Jain Priyanka-B32167 wrote:
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, July 17, 2015 1:06 AM
> > To: Jain Priyanka-B32167
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add T1040D4RDB/T1042D4RDB
> > board support
> > 
> > > > +                i2c@118100{
> > > > +                      mux@77{
> > > > +                             compatible = "nxp,pca9546";
> > > > +                             reg = <0x77>;
> > > > +                             #address-cells = <1>;
> > > > +                             #size-cells = <0>;
> > > > +                     };
> > > > +             };
> > > 
> > > A mux with no nodes under it (and yet it has #address-cells/#size-
> > > cells)?
> > > What is it multiplexing?
> > > [Priyanka]: PCA9546 is i2c mux device , to which other i2c devices
> > > (up-to 8
> > > ) can be further connected on output channels On T104xD4RDB,  channel
> > > 0, 1, 3 line are connected to PEX device, Channel 2 to hdmi interface
> > > (initialization is done in u-boot only), other channels are grounded.
> > > So, as such Linux is not using the second level I2C devices connected
> > > on this MUX device. So, I have not shown next level hierarchy.
> > > Should I replace 'mux' with some other name? . Please suggest.
> > 
> > The device tree describes the hardware, not just what Linux uses... but 
> > what
> > I don't understand is why you describe the mux at all if you're not going 
> > to
> > describe what goes underneath it.
> > 
> [Jain Priyanka-B32167] : Is below looks OK?
> i2c@118100{
>  +                      i2c@77{
>  +                             compatible = "nxp,pca9546";
>  +                             reg = <0x77>;
>  +                             #address-cells = <1>;
>  +                             #size-cells = <0>;
>  +                     };
>  +             };

Where in my above comment did it appear that I was complaining about the node 
name?

-Scott
Priyanka Jain July 22, 2015, 10:49 a.m. UTC | #6
> -----Original Message-----

> From: Wood Scott-B07421

> Sent: Friday, July 17, 2015 10:37 PM

> To: Jain Priyanka-B32167

> Cc: linuxppc-dev@lists.ozlabs.org

> Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add T1040D4RDB/T1042D4RDB

> board support

> 

> On Fri, 2015-07-17 at 01:17 -0500, Jain Priyanka-B32167 wrote:

> >

> > > -----Original Message-----

> > > From: Wood Scott-B07421

> > > Sent: Friday, July 17, 2015 1:06 AM

> > > To: Jain Priyanka-B32167

> > > Cc: linuxppc-dev@lists.ozlabs.org

> > > Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add

> > > T1040D4RDB/T1042D4RDB board support

> > >

> > > > > +                i2c@118100{

> > > > > +                      mux@77{

> > > > > +                             compatible = "nxp,pca9546";

> > > > > +                             reg = <0x77>;

> > > > > +                             #address-cells = <1>;

> > > > > +                             #size-cells = <0>;

> > > > > +                     };

> > > > > +             };

> > > >

> > > > A mux with no nodes under it (and yet it has #address-cells/#size-

> > > > cells)?

> > > > What is it multiplexing?

> > > > [Priyanka]: PCA9546 is i2c mux device , to which other i2c devices

> > > > (up-to 8

> > > > ) can be further connected on output channels On T104xD4RDB,

> > > > channel 0, 1, 3 line are connected to PEX device, Channel 2 to

> > > > hdmi interface (initialization is done in u-boot only), other channels are

> grounded.

> > > > So, as such Linux is not using the second level I2C devices

> > > > connected on this MUX device. So, I have not shown next level

> hierarchy.

> > > > Should I replace 'mux' with some other name? . Please suggest.

> > >

> > > The device tree describes the hardware, not just what Linux uses...

> > > but what I don't understand is why you describe the mux at all if

> > > you're not going to describe what goes underneath it.

> > >

> > [Jain Priyanka-B32167] : Is below looks OK?

> > i2c@118100{

> >  +                      i2c@77{

> >  +                             compatible = "nxp,pca9546";

> >  +                             reg = <0x77>;

> >  +                             #address-cells = <1>;

> >  +                             #size-cells = <0>;

> >  +                     };

> >  +             };

> 

> Where in my above comment did it appear that I was complaining about the

> node name?

> 

[Jain Priyanka-B32167]
From what I understand:
PCA9546 is a mux device and it would be good if we were able to present the I2C devices on output lines as subnodes like in case of B4qds board and then 'mux' name would have make more sense.
But in case of T1040D4RDB board, output i2c lines are going to PEX slots, PCI connector. I am not aware of how to represents them as sub-nodes in dts.
> -Scott
Scott Wood July 24, 2015, 3:28 p.m. UTC | #7
On Wed, 2015-07-22 at 05:49 -0500, Jain Priyanka-B32167 wrote:
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, July 17, 2015 10:37 PM
> > To: Jain Priyanka-B32167
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add T1040D4RDB/T1042D4RDB
> > board support
> > 
> > On Fri, 2015-07-17 at 01:17 -0500, Jain Priyanka-B32167 wrote:
> > > 
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Friday, July 17, 2015 1:06 AM
> > > > To: Jain Priyanka-B32167
> > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add
> > > > T1040D4RDB/T1042D4RDB board support
> > > > 
> > > > > > +                i2c@118100{
> > > > > > +                      mux@77{
> > > > > > +                             compatible = "nxp,pca9546";
> > > > > > +                             reg = <0x77>;
> > > > > > +                             #address-cells = <1>;
> > > > > > +                             #size-cells = <0>;
> > > > > > +                     };
> > > > > > +             };
> > > > > 
> > > > > A mux with no nodes under it (and yet it has #address-cells/#size-
> > > > > cells)?
> > > > > What is it multiplexing?
> > > > > [Priyanka]: PCA9546 is i2c mux device , to which other i2c devices
> > > > > (up-to 8
> > > > > ) can be further connected on output channels On T104xD4RDB,
> > > > > channel 0, 1, 3 line are connected to PEX device, Channel 2 to
> > > > > hdmi interface (initialization is done in u-boot only), other 
> > > > > channels are
> > grounded.
> > > > > So, as such Linux is not using the second level I2C devices
> > > > > connected on this MUX device. So, I have not shown next level
> > hierarchy.
> > > > > Should I replace 'mux' with some other name? . Please suggest.
> > > > 
> > > > The device tree describes the hardware, not just what Linux uses...
> > > > but what I don't understand is why you describe the mux at all if
> > > > you're not going to describe what goes underneath it.
> > > > 
> > > [Jain Priyanka-B32167] : Is below looks OK?
> > > i2c@118100{
> > >  +                      i2c@77{
> > >  +                             compatible = "nxp,pca9546";
> > >  +                             reg = <0x77>;
> > >  +                             #address-cells = <1>;
> > >  +                             #size-cells = <0>;
> > >  +                     };
> > >  +             };
> > 
> > Where in my above comment did it appear that I was complaining about the
> > node name?
> > 
> [Jain Priyanka-B32167]
> From what I understand:
> PCA9546 is a mux device and it would be good if we were able to present the 
> I2C devices on output lines as subnodes like in case of B4qds board and 
> then 'mux' name would have make more sense.

The name "mux" makes more sense regardless.

> But in case of T1040D4RDB board, output i2c lines are going to PEX slots, 
> PCI connector. I am not aware of how to represents them as sub-nodes in dts.

OK, so you're saying the i2c devices are pluggable (and I'm assuming by "PEX 
slots" you just mean that the physical slot is repurposed, not that the PCI 
express protocol is involved)?  Making a non-runtime-enumerable bus be 
pluggable seems like a bad idea, but if that's really what has been done, 
there needs to be a device tree that represents the entire system, not just 
the motherboard.  This could be done either via a dts file that /include/s 
the motherboard dts, or via firmware dtb edits.  The dts for the motherboard 
should include the mux node with a comment explaining what the situation is.

-Scott
Priyanka Jain July 29, 2015, 9:07 a.m. UTC | #8
> -----Original Message-----

> From: Wood Scott-B07421

> Sent: Friday, July 24, 2015 8:58 PM

> To: Jain Priyanka-B32167

> Cc: linuxppc-dev@lists.ozlabs.org

> Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add T1040D4RDB/T1042D4RDB

> board support

> 

> On Wed, 2015-07-22 at 05:49 -0500, Jain Priyanka-B32167 wrote:

> >

> > > -----Original Message-----

> > > From: Wood Scott-B07421

> > > Sent: Friday, July 17, 2015 10:37 PM

> > > To: Jain Priyanka-B32167

> > > Cc: linuxppc-dev@lists.ozlabs.org

> > > Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add

> > > T1040D4RDB/T1042D4RDB board support

> > >

> > > On Fri, 2015-07-17 at 01:17 -0500, Jain Priyanka-B32167 wrote:

> > > >

> > > > > -----Original Message-----

> > > > > From: Wood Scott-B07421

> > > > > Sent: Friday, July 17, 2015 1:06 AM

> > > > > To: Jain Priyanka-B32167

> > > > > Cc: linuxppc-dev@lists.ozlabs.org

> > > > > Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add

> > > > > T1040D4RDB/T1042D4RDB board support

> > > > >

> > > > > > > +                i2c@118100{

> > > > > > > +                      mux@77{

> > > > > > > +                             compatible = "nxp,pca9546";

> > > > > > > +                             reg = <0x77>;

> > > > > > > +                             #address-cells = <1>;

> > > > > > > +                             #size-cells = <0>;

> > > > > > > +                     };

> > > > > > > +             };

> > > > > >

> > > > > > A mux with no nodes under it (and yet it has

> > > > > > #address-cells/#size- cells)?

> > > > > > What is it multiplexing?

> > > > > > [Priyanka]: PCA9546 is i2c mux device , to which other i2c

> > > > > > devices (up-to 8

> > > > > > ) can be further connected on output channels On T104xD4RDB,

> > > > > > channel 0, 1, 3 line are connected to PEX device, Channel 2 to

> > > > > > hdmi interface (initialization is done in u-boot only), other

> > > > > > channels are

> > > grounded.

> > > > > > So, as such Linux is not using the second level I2C devices

> > > > > > connected on this MUX device. So, I have not shown next level

> > > hierarchy.

> > > > > > Should I replace 'mux' with some other name? . Please suggest.

> > > > >

> > > > > The device tree describes the hardware, not just what Linux uses...

> > > > > but what I don't understand is why you describe the mux at all

> > > > > if you're not going to describe what goes underneath it.

> > > > >

> > > > [Jain Priyanka-B32167] : Is below looks OK?

> > > > i2c@118100{

> > > >  +                      i2c@77{

> > > >  +                             compatible = "nxp,pca9546";

> > > >  +                             reg = <0x77>;

> > > >  +                             #address-cells = <1>;

> > > >  +                             #size-cells = <0>;

> > > >  +                     };

> > > >  +             };

> > >

> > > Where in my above comment did it appear that I was complaining about

> > > the node name?

> > >

> > [Jain Priyanka-B32167]

> > From what I understand:

> > PCA9546 is a mux device and it would be good if we were able to

> > present the I2C devices on output lines as subnodes like in case of

> > B4qds board and then 'mux' name would have make more sense.

> 

> The name "mux" makes more sense regardless.

> 

> > But in case of T1040D4RDB board, output i2c lines are going to PEX

> > slots, PCI connector. I am not aware of how to represents them as sub-

> nodes in dts.

> 

> OK, so you're saying the i2c devices are pluggable (and I'm assuming by "PEX

> slots" you just mean that the physical slot is repurposed, not that the PCI

> express protocol is involved)?  Making a non-runtime-enumerable bus be

> pluggable seems like a bad idea, but if that's really what has been done,

> there needs to be a device tree that represents the entire system, not just

> the motherboard.  This could be done either via a dts file that /include/s the

> motherboard dts, or via firmware dtb edits.  The dts for the motherboard

> should include the mux node with a comment explaining what the situation

> is.

> 

[Jain Priyanka-B32167] Is the below comment looks OK?
"Output I2C data, clock lines (SDO/SC0,SD1/SC1 , SD2/SC2, SD3/SC3) are going mini PCI connector slot1, mini PCI connector slot2, HDMI connector, PEX slot respectively
 The sub-nodes will depend upon the device that will be connected on these slots"

> -Scott
Scott Wood July 29, 2015, 10:14 p.m. UTC | #9
On Wed, 2015-07-29 at 04:07 -0500, Jain Priyanka-B32167 wrote:
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, July 24, 2015 8:58 PM
> > To: Jain Priyanka-B32167
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add T1040D4RDB/T1042D4RDB
> > board support
> > 
> > OK, so you're saying the i2c devices are pluggable (and I'm assuming by 
> > "PEX
> > slots" you just mean that the physical slot is repurposed, not that the 
> > PCI
> > express protocol is involved)?  Making a non-runtime-enumerable bus be
> > pluggable seems like a bad idea, but if that's really what has been done,
> > there needs to be a device tree that represents the entire system, not 
> > just
> > the motherboard.  This could be done either via a dts file that 
> > /include/s the
> > motherboard dts, or via firmware dtb edits.  The dts for the motherboard
> > should include the mux node with a comment explaining what the situation
> > is.
> > 
> [Jain Priyanka-B32167] Is the below comment looks OK?
> "Output I2C data, clock lines (SDO/SC0,SD1/SC1 , SD2/SC2, SD3/SC3) are 
> going mini PCI connector slot1, mini PCI connector slot2, HDMI connector, 
> PEX slot respectively
>  The sub-nodes will depend upon the device that will be connected on these 
> slots"

How about:

"Child nodes depend on which i2c devices are connected via the mini PCI 

connector slot1, the mini PCI connector slot2, the HDMI connector, and the 

PEX slot.  Systems with such devices attached should provide a wrapper .dts 
file that includes this one, and adds those nodes."

-Scott
Priyanka Jain July 30, 2015, 4:55 a.m. UTC | #10
> -----Original Message-----

> From: Wood Scott-B07421

> Sent: Thursday, July 30, 2015 3:45 AM

> To: Jain Priyanka-B32167

> Cc: linuxppc-dev@lists.ozlabs.org

> Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add T1040D4RDB/T1042D4RDB

> board support

> 

> On Wed, 2015-07-29 at 04:07 -0500, Jain Priyanka-B32167 wrote:

> >

> > > -----Original Message-----

> > > From: Wood Scott-B07421

> > > Sent: Friday, July 24, 2015 8:58 PM

> > > To: Jain Priyanka-B32167

> > > Cc: linuxppc-dev@lists.ozlabs.org

> > > Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add

> > > T1040D4RDB/T1042D4RDB board support

> > >

> > > OK, so you're saying the i2c devices are pluggable (and I'm assuming

> > > by "PEX slots" you just mean that the physical slot is repurposed,

> > > not that the PCI express protocol is involved)?  Making a

> > > non-runtime-enumerable bus be pluggable seems like a bad idea, but

> > > if that's really what has been done, there needs to be a device tree

> > > that represents the entire system, not just the motherboard.  This

> > > could be done either via a dts file that /include/s the motherboard

> > > dts, or via firmware dtb edits.  The dts for the motherboard should

> > > include the mux node with a comment explaining what the situation

> > > is.

> > >

> > [Jain Priyanka-B32167] Is the below comment looks OK?

> > "Output I2C data, clock lines (SDO/SC0,SD1/SC1 , SD2/SC2, SD3/SC3) are

> > going mini PCI connector slot1, mini PCI connector slot2, HDMI

> > connector, PEX slot respectively  The sub-nodes will depend upon the

> > device that will be connected on these slots"

> 

> How about:

> 

> "Child nodes depend on which i2c devices are connected via the mini PCI

> 

> connector slot1, the mini PCI connector slot2, the HDMI connector, and the

> 

> PEX slot.  Systems with such devices attached should provide a wrapper .dts

> file that includes this one, and adds those nodes."

> 

[Jain Priyanka-B32167] Thanks, This looks good. I will send the updated patch.
> -Scott
diff mbox

Patch

diff --git a/arch/powerpc/boot/dts/t1040d4rdb.dts b/arch/powerpc/boot/dts/t1040d4rdb.dts
new file mode 100644
index 0000000..2d1315a
--- /dev/null
+++ b/arch/powerpc/boot/dts/t1040d4rdb.dts
@@ -0,0 +1,46 @@ 
+/*
+ * T1040D4RDB Device Tree Source
+ *
+ * Copyright 2015 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *	 notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *	 notice, this list of conditions and the following disclaimer in the
+ *	 documentation and/or other materials provided with the distribution.
+ *     * Neither the name of Freescale Semiconductor nor the
+ *	 names of its contributors may be used to endorse or promote products
+ *	 derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/t104xsi-pre.dtsi"
+/include/ "t104xd4rdb.dtsi"
+
+/ {
+	model = "fsl,T1040D4RDB";
+	compatible = "fsl,T1040D4RDB";
+	#address-cells = <2>;
+	#size-cells = <2>;
+	interrupt-parent = <&mpic>;
+};
+
+/include/ "fsl/t1040si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/t1042d4rdb.dts b/arch/powerpc/boot/dts/t1042d4rdb.dts
new file mode 100644
index 0000000..846f8c8
--- /dev/null
+++ b/arch/powerpc/boot/dts/t1042d4rdb.dts
@@ -0,0 +1,53 @@ 
+/*
+ * T1042D4RDB Device Tree Source
+ *
+ * Copyright 2015 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *	 notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *	 notice, this list of conditions and the following disclaimer in the
+ *	 documentation and/or other materials provided with the distribution.
+ *     * Neither the name of Freescale Semiconductor nor the
+ *	 names of its contributors may be used to endorse or promote products
+ *	 derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/t104xsi-pre.dtsi"
+/include/ "t104xd4rdb.dtsi"
+
+/ {
+	model = "fsl,T1042D4RDB";
+	compatible = "fsl,T1042D4RDB";
+	#address-cells = <2>;
+	#size-cells = <2>;
+	interrupt-parent = <&mpic>;
+
+	ifc: localbus@ffe124000 {
+		cpld@3,0 {
+			compatible = "fsl,t1040d4rdb-cpld",
+					"fsl,deepsleep-cpld";
+		};
+	};
+};
+
+/include/ "fsl/t1040si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/t104xd4rdb.dtsi b/arch/powerpc/boot/dts/t104xd4rdb.dtsi
new file mode 100644
index 0000000..37d2817
--- /dev/null
+++ b/arch/powerpc/boot/dts/t104xd4rdb.dtsi
@@ -0,0 +1,196 @@ 
+/*
+ * T1040D4RDB/T1042D4RDB Device Tree Source
+ *
+ * Copyright 2015 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *	 notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *	 notice, this list of conditions and the following disclaimer in the
+ *	 documentation and/or other materials provided with the distribution.
+ *     * Neither the name of Freescale Semiconductor nor the
+ *	 names of its contributors may be used to endorse or promote products
+ *	 derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/ {
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		bman_fbpr: bman-fbpr {
+			size = <0 0x1000000>;
+			alignment = <0 0x1000000>;
+		};
+		qman_fqd: qman-fqd {
+			size = <0 0x400000>;
+			alignment = <0 0x400000>;
+		};
+		qman_pfdr: qman-pfdr {
+			size = <0 0x2000000>;
+			alignment = <0 0x2000000>;
+		};
+	};
+
+	ifc: localbus@ffe124000 {
+		reg = <0xf 0xfe124000 0 0x2000>;
+		ranges = <0 0 0xf 0xe8000000 0x08000000
+			  2 0 0xf 0xff800000 0x00010000
+			  3 0 0xf 0xffdf0000 0x00008000>;
+
+		nor@0,0 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "cfi-flash";
+			reg = <0x0 0x0 0x8000000>;
+			bank-width = <2>;
+			device-width = <1>;
+		};
+
+		nand@2,0 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "fsl,ifc-nand";
+			reg = <0x2 0x0 0x10000>;
+		};
+
+		cpld@3,0 {
+			compatible = "fsl,t1040d4rdb-cpld";
+			reg = <3 0 0x300>;
+		};
+	};
+
+	memory {
+		device_type = "memory";
+	};
+
+	dcsr: dcsr@f00000000 {
+		ranges = <0x00000000 0xf 0x00000000 0x01072000>;
+	};
+
+	bportals: bman-portals@ff4000000 {
+		ranges = <0x0 0xf 0xf4000000 0x2000000>;
+	};
+
+	qportals: qman-portals@ff6000000 {
+		ranges = <0x0 0xf 0xf6000000 0x2000000>;
+	};
+
+	soc: soc@ffe000000 {
+		ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
+		reg = <0xf 0xfe000000 0 0x00001000>;
+
+		spi@110000 {
+			flash@0 {
+				#address-cells = <1>;
+				#size-cells = <1>;
+				compatible = "micron,n25q512ax3";
+				reg = <0>;
+				/* input clock */
+				spi-max-frequency = <10000000>;
+			};
+		};
+		i2c@118000 {
+			hwmon@4c {
+				compatible = "adi,adt7461";
+				reg = <0x4c>;
+			};
+
+			rtc@68 {
+				compatible = "dallas,ds1337";
+				reg = <0x68>;
+				interrupts = <0x2 0x1 0 0>;
+			};
+		};
+
+		i2c@118100 {
+			mux@77 {
+				compatible = "nxp,pca9546";
+				reg = <0x77>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+			};
+		};
+
+	};
+
+	pci0: pcie@ffe240000 {
+		reg = <0xf 0xfe240000 0 0x10000>;
+		ranges = <0x02000000 0 0xe0000000 0xc 0x0 0x0 0x10000000
+			  0x01000000 0 0x0 0xf 0xf8000000 0x0 0x00010000>;
+		pcie@0 {
+			ranges = <0x02000000 0 0xe0000000
+				  0x02000000 0 0xe0000000
+				  0 0x10000000
+
+				  0x01000000 0 0x00000000
+				  0x01000000 0 0x00000000
+				  0 0x00010000>;
+		};
+	};
+
+	pci1: pcie@ffe250000 {
+		reg = <0xf 0xfe250000 0 0x10000>;
+		ranges = <0x02000000 0 0xe0000000 0xc 0x10000000 0 0x10000000
+			  0x01000000 0 0 0xf 0xf8010000 0 0x00010000>;
+		pcie@0 {
+			ranges = <0x02000000 0 0xe0000000
+				  0x02000000 0 0xe0000000
+				  0 0x10000000
+
+				  0x01000000 0 0x00000000
+				  0x01000000 0 0x00000000
+				  0 0x00010000>;
+		};
+	};
+
+	pci2: pcie@ffe260000 {
+		reg = <0xf 0xfe260000 0 0x10000>;
+		ranges = <0x02000000 0 0xe0000000 0xc 0x20000000 0 0x10000000
+			  0x01000000 0 0x00000000 0xf 0xf8020000 0 0x00010000>;
+		pcie@0 {
+			ranges = <0x02000000 0 0xe0000000
+				  0x02000000 0 0xe0000000
+				  0 0x10000000
+
+				  0x01000000 0 0x00000000
+				  0x01000000 0 0x00000000
+				  0 0x00010000>;
+		};
+	};
+
+	pci3: pcie@ffe270000 {
+		reg = <0xf 0xfe270000 0 0x10000>;
+		ranges = <0x02000000 0 0xe0000000 0xc 0x30000000 0 0x10000000
+			  0x01000000 0 0x00000000 0xf 0xf8030000 0 0x00010000>;
+		pcie@0 {
+			ranges = <0x02000000 0 0xe0000000
+				  0x02000000 0 0xe0000000
+				  0 0x10000000
+
+				  0x01000000 0 0x00000000
+				  0x01000000 0 0x00000000
+				  0 0x00010000>;
+		};
+	};
+};
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index bd839dc..b395571 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -153,6 +153,8 @@  static const char * const boards[] __initconst = {
 	"fsl,T1023RDB",
 	"fsl,T1024QDS",
 	"fsl,T1024RDB",
+	"fsl,T1040D4RDB",
+	"fsl,T1042D4RDB",
 	"fsl,T1040QDS",
 	"fsl,T1042QDS",
 	"fsl,T1040RDB",