* [PATCH 0/1] PowerPC 74xx: Add Emerson Katana Qp support @ 2007-11-16 15:43 Andrei Dolnikov 2007-11-16 16:12 ` [PATCH 1/5] PowerPC 74xx: Katana Qp device tree Andrei Dolnikov 2007-11-16 16:31 ` [PATCH 4/5] PowerPC 74xx: Katana Qp base support Andrei Dolnikov 0 siblings, 2 replies; 27+ messages in thread From: Andrei Dolnikov @ 2007-11-16 15:43 UTC (permalink / raw) To: linuxppc-dev Hello folks, The following patch sequence is intended to add support for the Emerson Katana Qp ATCA board based on MPC7448 CPU and Marvell 64460 chipset. The patches are incremental to minor mv64x60 code fixups sent by Mark A. Greer on 11/08/07. Thanks, Andrei. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-11-16 15:43 [PATCH 0/1] PowerPC 74xx: Add Emerson Katana Qp support Andrei Dolnikov @ 2007-11-16 16:12 ` Andrei Dolnikov 2007-11-21 18:08 ` Vitaly Bordug 2007-11-16 16:31 ` [PATCH 4/5] PowerPC 74xx: Katana Qp base support Andrei Dolnikov 1 sibling, 1 reply; 27+ messages in thread From: Andrei Dolnikov @ 2007-11-16 16:12 UTC (permalink / raw) To: linuxppc-dev Device tree source file for the Emerson Katana Qp board Signed-off-by: Andrei Dolnikov <adolnikov@ru.mvisa.com> --- arch/powerpc/boot/dts/katanaqp.dts | 357 +++++++++++++++++++++++++++++++++++++ 1 files changed, 357 insertions(+) diff --git a/arch/powerpc/boot/dts/katanaqp.dts b/arch/powerpc/boot/dts/katanaqp.dts new file mode 100644 index 0000000..9273c4e --- /dev/null +++ b/arch/powerpc/boot/dts/katanaqp.dts @@ -0,0 +1,357 @@ +/* Device Tree Source for Emerson Katana Qp + * + * Authors: Vladislav Buzov <vbuzov@ru.mvista.com> + * Andrei Dolnikov <adolnikov@ru.mvista.com> + * + * Based on prpmc8200.dts by Mark A. Greer <mgreer@mvista.com> + * + * 2007 (c) MontaVista, Software, Inc. This file is licensed under + * the terms of the GNU General Public License version 2. This program + * is licensed "as is" without any warranty of any kind, whether express + * or implied. + * + */ + +/ { + #address-cells = <1>; + #size-cells = <1>; + model = "Katana-Qp"; /* Default */ + compatible = "emerson,Katana-Qp"; + coherency-off; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + PowerPC,7448@0 { + device_type = "cpu"; + reg = <0>; + clock-frequency = <0>; /* From U-boot */ + bus-frequency = <0>; /* From U-boot */ + timebase-frequency = <0>; /* From U-boot */ + i-cache-line-size = <20>; + d-cache-line-size = <20>; + i-cache-size = <8000>; + d-cache-size = <8000>; + }; + }; + + memory { + device_type = "memory"; + reg = <00000000 20000000>; /* Default (512MB) */ + }; + + mv64x60@f8100000 { /* Marvell Discovery */ + #address-cells = <1>; + #size-cells = <1>; + model = "mv64460"; /* Default */ + compatible = "marvell,mv64x60"; + clock-frequency = <7f28155>; /* 133.333333 MHz */ + reg = <f8100000 00010000>; + virtual-reg = <f8100000>; + ranges = <c1000000 c1000000 01000000 /* PCI 1 I/O Space */ + 90000000 90000000 30000000 /* PCI 1 MEM Space */ + e8000000 e8000000 04000000 /* User FLASH: Up to 64Mb */ + 00000000 f8100000 00010000 /* Bridge's regs */ + f8500000 f8500000 00040000>; /* Integrated SRAM */ + + flash@e8000000 { + compatible = "cfi-flash"; + reg = <e8000000 1000000>; /* Default (16MB) */ + probe-type = "CFI"; + bank-width = <4>; + + partition@0 { + label = "Primary Monitor"; + reg = <0 100000>; /* 1Mb */ + read-only; + }; + + partition@100000 { + label = "Primary Kernel"; + reg = <100000 200000>; /* 2 Mb */ + }; + + partition@300000 { + label = "Primary FS"; + reg = <300000 d00000>; /* 13 Mb */ + }; + + }; + + cpld@f8200000 { + compatible = "altera,maxii"; + reg = <f8200000 40000>; + virtual-reg = <f8200000>; + }; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + compatible = "marvell,mv64x60-mdio"; + ethernet-phy@0 { + block-index = <0>; + compatible = "marvell,mv88e1111"; + reg = <a>; + }; + ethernet-phy@1 { + compatible = "marvell,mv88e1111"; + block-index = <1>; + reg = <d>; + }; + ethernet-phy@2 { + compatible = "marvell,mv88e1111"; + block-index = <2>; + reg = <6>; + }; + }; + + ethernet@2000 { + reg = <2000 2000>; + eth0 { + device_type = "network"; + compatible = "marvell,mv64x60-eth"; + block-index = <0>; + interrupts = <20>; + interrupt-parent = <&/mv64x60/pic>; + phy = <&/mv64x60/mdio/ethernet-phy@0>; + speed = <3e8>; + duplex = <1>; + tx_queue_size = <320>; + rx_queue_size = <190>; + local-mac-address = [ 00 00 00 00 00 00 ]; + }; + eth1 { + device_type = "network"; + compatible = "marvell,mv64x60-eth"; + block-index = <1>; + interrupts = <21>; + interrupt-parent = <&/mv64x60/pic>; + phy = <&/mv64x60/mdio/ethernet-phy@1>; + speed = <3e8>; + duplex = <1>; + tx_queue_size = <320>; + rx_queue_size = <190>; + local-mac-address = [ 00 00 00 00 00 00 ]; + }; + eth2 { + device_type = "network"; + compatible = "marvell,mv64x60-eth"; + block-index = <2>; + interrupts = <22>; + interrupt-parent = <&/mv64x60/pic>; + phy = <&/mv64x60/mdio/ethernet-phy@2>; + speed = <3e8>; + duplex = <1>; + tx_queue_size = <320>; + rx_queue_size = <190>; + local-mac-address = [ 00 00 00 00 00 00 ]; + }; + }; + + sdma@4000 { + compatible = "marvell,mv64x60-sdma"; + reg = <4000 c18>; + virtual-reg = <f8104000>; + interrupt-base = <0>; + interrupts = <24>; + interrupt-parent = <&/mv64x60/pic>; + }; + + sdma@6000 { + compatible = "marvell,mv64x60-sdma"; + reg = <6000 c18>; + virtual-reg = <f8106000>; + interrupt-base = <0>; + interrupts = <26>; + interrupt-parent = <&/mv64x60/pic>; + }; + + brg@b200 { + compatible = "marvell,mv64x60-brg"; + reg = <b200 8>; + clock-src = <8>; + clock-frequency = <7ed6b40>; + current-speed = <2580>; + bcr = <0>; + }; + + brg@b208 { + compatible = "marvell,mv64x60-brg"; + reg = <b208 8>; + clock-src = <8>; + clock-frequency = <7ed6b40>; + current-speed = <2580>; + bcr = <0>; + }; + + cunit@f200 { + reg = <f200 200>; + }; + + mpscrouting@b400 { + reg = <b400 c>; + }; + + mpscintr@b800 { + reg = <b800 100>; + virtual-reg = <f810b800>; + }; + + mpsc@8000 { + device_type = "serial"; + compatible = "marvell,mpsc"; + reg = <8000 38>; + virtual-reg = <f8108000>; + sdma = <&/mv64x60/sdma@4000>; + brg = <&/mv64x60/brg@b200>; + cunit = <&/mv64x60/cunit@f200>; + mpscrouting = <&/mv64x60/mpscrouting@b400>; + mpscintr = <&/mv64x60/mpscintr@b800>; + block-index = <0>; + max_idle = <28>; + chr_1 = <0>; + chr_2 = <0>; + chr_10 = <3>; + mpcr = <0>; + interrupts = <28>; + interrupt-parent = <&/mv64x60/pic>; + }; + + mpsc@9000 { + device_type = "serial"; + compatible = "marvell,mpsc"; + reg = <9000 38>; + virtual-reg = <f8109000>; + sdma = <&/mv64x60/sdma@6000>; + brg = <&/mv64x60/brg@b208>; + cunit = <&/mv64x60/cunit@f200>; + mpscrouting = <&/mv64x60/mpscrouting@b400>; + mpscintr = <&/mv64x60/mpscintr@b800>; + block-index = <1>; + max_idle = <28>; + chr_1 = <0>; + chr_2 = <0>; + chr_10 = <3>; + mpcr = <0>; + interrupts = <29>; + interrupt-parent = <&/mv64x60/pic>; + }; + + wdt@b410 { /* watchdog timer */ + compatible = "marvell,mv64x60-wdt"; + reg = <b410 8>; + timeout = <a>; /* wdt timeout in seconds */ + }; + + i2c@c000 { + compatible = "marvell,mv64x60-i2c"; + reg = <c000 20>; + virtual-reg = <f810c000>; + freq_m = <8>; + freq_n = <3>; + timeout = <3e8>; /* 1000 = 1 second */ + retries = <1>; + interrupts = <25>; + interrupt-parent = <&/mv64x60/pic>; + }; + + pic { + #interrupt-cells = <1>; + #address-cells = <0>; + compatible = "marvell,mv64x60-pic"; + reg = <0000 88>; + interrupt-controller; + }; + + mpp@f000 { + compatible = "marvell,mv64x60-mpp"; + reg = <f000 10>; + }; + + gpp@f100 { + compatible = "marvell,mv64x60-gpp"; + reg = <f100 20>; + }; + + pci@90000000 { + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + device_type = "pci"; + compatible = "marvell,mv64x60-pci"; + reg = <0c78 8>; + ranges = <01000000 0 0 c1000000 0 01000000 + 02000000 0 90000000 90000000 0 30000000>; + bus-range = <0 ff>; + clock-frequency = <3EF1480>; + interrupt-pci-iack = <0c34>; + interrupt-parent = <&/mv64x60/pic>; + interrupt-map-mask = <f800 0 0 7>; + interrupt-map = < + /* IDSEL 0x1 */ + 0800 0 0 1 &/mv64x60/pic 5a + 0800 0 0 2 &/mv64x60/pic 5b + 0800 0 0 3 &/mv64x60/pic 5e + 0800 0 0 4 &/mv64x60/pic 5f + + /* IDSEL 0x2 */ + 1000 0 0 1 &/mv64x60/pic 5b + 1000 0 0 2 &/mv64x60/pic 5e + 1000 0 0 3 &/mv64x60/pic 5f + 1000 0 0 4 &/mv64x60/pic 5a + + /* IDSEL 0x3 */ + 1800 0 0 1 &/mv64x60/pic 5e + 1800 0 0 2 &/mv64x60/pic 5f + 1800 0 0 3 &/mv64x60/pic 5a + 1800 0 0 4 &/mv64x60/pic 5b + + /* IDSEL 0x4 */ + 2000 0 0 1 &/mv64x60/pic 5f + 2000 0 0 2 &/mv64x60/pic 5a + 2000 0 0 3 &/mv64x60/pic 5b + 2000 0 0 4 &/mv64x60/pic 5e + + /* IDSEL 0x6 */ + 3000 0 0 1 &/mv64x60/pic 5b + 3000 0 0 2 &/mv64x60/pic 5e + 3000 0 0 3 &/mv64x60/pic 5f + 3000 0 0 4 &/mv64x60/pic 5a + >; + }; + + cpu-error@0070 { + compatible = "marvell,mv64x60-cpu-error"; + reg = <0070 10 0128 28>; + interrupts = <03>; + interrupt-parent = <&/mv64x60/pic>; + }; + + sram-ctrl@0380 { + compatible = "marvell,mv64x60-sram-ctrl"; + reg = <0380 80>; + interrupts = <0d>; + interrupt-parent = <&/mv64x60/pic>; + }; + + pci-error@1d40 { + compatible = "marvell,mv64x60-pci-error"; + reg = <1d40 40 0c28 4>; + interrupts = <0c>; + interrupt-parent = <&/mv64x60/pic>; + }; + + mem-ctrl@1400 { + compatible = "marvell,mv64x60-mem-ctrl"; + reg = <1400 60>; + interrupts = <11>; + interrupt-parent = <&/mv64x60/pic>; + }; + }; + + chosen { + bootargs = "ip=on"; + linux,stdout-path = "/mv64x60@f8100000/mpsc@8000"; + }; +}; ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-11-16 16:12 ` [PATCH 1/5] PowerPC 74xx: Katana Qp device tree Andrei Dolnikov @ 2007-11-21 18:08 ` Vitaly Bordug 0 siblings, 0 replies; 27+ messages in thread From: Vitaly Bordug @ 2007-11-21 18:08 UTC (permalink / raw) To: Andrei Dolnikov; +Cc: linuxppc-dev On Fri, 16 Nov 2007 19:12:53 +0300 Andrei Dolnikov wrote: > Device tree source file for the Emerson Katana Qp board > > Signed-off-by: Andrei Dolnikov <adolnikov@ru.mvisa.com> > > --- > arch/powerpc/boot/dts/katanaqp.dts | 357 > +++++++++++++++++++++++++++++++++++++ 1 files changed, 357 > insertions(+) > > diff --git a/arch/powerpc/boot/dts/katanaqp.dts > b/arch/powerpc/boot/dts/katanaqp.dts new file mode 100644 > index 0000000..9273c4e > --- /dev/null > +++ b/arch/powerpc/boot/dts/katanaqp.dts > @@ -0,0 +1,357 @@ > +/* Device Tree Source for Emerson Katana Qp > + * > + * Authors: Vladislav Buzov <vbuzov@ru.mvista.com> > + * Andrei Dolnikov <adolnikov@ru.mvista.com> > + * > + * Based on prpmc8200.dts by Mark A. Greer <mgreer@mvista.com> > + * > + * 2007 (c) MontaVista, Software, Inc. This file is licensed under > + * the terms of the GNU General Public License version 2. This > program > + * is licensed "as is" without any warranty of any kind, whether > express > + * or implied. > + * > + */ > + > +/ { > + #address-cells = <1>; > + #size-cells = <1>; > + model = "Katana-Qp"; /* Default */ > + compatible = "emerson,Katana-Qp"; > + coherency-off; > + > + cpus { > + #address-cells = <1>; > + #size-cells = <0>; > + > + PowerPC,7448@0 { > + device_type = "cpu"; > + reg = <0>; > + clock-frequency = <0>; /* > From U-boot */ > + bus-frequency = <0>; /* From > U-boot */ > + timebase-frequency = <0>; /* From > U-boot */ > + i-cache-line-size = <20>; > + d-cache-line-size = <20>; > + i-cache-size = <8000>; > + d-cache-size = <8000>; > + }; > + }; > + > + memory { > + device_type = "memory"; > + reg = <00000000 20000000>; /* Default (512MB) > */ > + }; > + shouldn't this come from the firmware if possible? > + mv64x60@f8100000 { /* Marvell Discovery */ > + #address-cells = <1>; > + #size-cells = <1>; > + model = "mv64460"; /* Default > */ > + compatible = "marvell,mv64x60"; > + clock-frequency = <7f28155>; /* > 133.333333 MHz */ This should be updated somewhere in fw or bootwrapper.. Or is it hardcoded value that is not going to change? > + reg = <f8100000 00010000>; > + virtual-reg = <f8100000>; > + ranges = <c1000000 c1000000 01000000 /* PCI 1 > I/O Space */ > + 90000000 90000000 30000000 /* PCI 1 > MEM Space */ > + e8000000 e8000000 04000000 /* User > FLASH: Up to 64Mb */ > + 00000000 f8100000 00010000 /* > Bridge's regs */ > + f8500000 f8500000 00040000>; /* > Integrated SRAM */ + > + flash@e8000000 { > + compatible = "cfi-flash"; > + reg = <e8000000 1000000>; /* Default (16MB) > */ > + probe-type = "CFI"; > + bank-width = <4>; > + > + partition@0 { > + label = "Primary Monitor"; > + reg = <0 100000>; /* 1Mb */ > + read-only; > + }; > + > + partition@100000 { > + label = "Primary Kernel"; > + reg = <100000 200000>; /* 2 Mb */ > + }; > + > + partition@300000 { > + label = "Primary FS"; > + reg = <300000 d00000>; /* 13 Mb */ > + }; > + > + }; > + > + cpld@f8200000 { > + compatible = "altera,maxii"; > + reg = <f8200000 40000>; > + virtual-reg = <f8200000>; > + }; > + > + mdio { > + #address-cells = <1>; > + #size-cells = <0>; > + compatible = "marvell,mv64x60-mdio"; > + ethernet-phy@0 { > + block-index = <0>; > + compatible = "marvell,mv88e1111"; > + reg = <a>; > + }; > + ethernet-phy@1 { > + compatible = "marvell,mv88e1111"; > + block-index = <1>; > + reg = <d>; > + }; > + ethernet-phy@2 { > + compatible = "marvell,mv88e1111"; > + block-index = <2>; > + reg = <6>; > + }; > + }; > + > + ethernet@2000 { > + reg = <2000 2000>; > + eth0 { > + device_type = "network"; > + compatible = "marvell,mv64x60-eth"; > + block-index = <0>; > + interrupts = <20>; > + interrupt-parent = <&/mv64x60/pic>; > + phy = > <&/mv64x60/mdio/ethernet-phy@0>; > + speed = <3e8>; > + duplex = <1>; > + tx_queue_size = <320>; > + rx_queue_size = <190>; > + local-mac-address = [ 00 00 00 00 00 > 00 ]; > + }; > + eth1 { > + device_type = "network"; > + compatible = "marvell,mv64x60-eth"; > + block-index = <1>; > + interrupts = <21>; > + interrupt-parent = <&/mv64x60/pic>; > + phy = > <&/mv64x60/mdio/ethernet-phy@1>; > + speed = <3e8>; > + duplex = <1>; > + tx_queue_size = <320>; > + rx_queue_size = <190>; > + local-mac-address = [ 00 00 00 00 00 > 00 ]; here and in other places: you need to add a note that stuff is being rewritten/updated by fw and/or bootwrapper. > + }; > + eth2 { > + device_type = "network"; > + compatible = "marvell,mv64x60-eth"; > + block-index = <2>; > + interrupts = <22>; > + interrupt-parent = <&/mv64x60/pic>; > + phy = > <&/mv64x60/mdio/ethernet-phy@2>; > + speed = <3e8>; > + duplex = <1>; > + tx_queue_size = <320>; > + rx_queue_size = <190>; > + local-mac-address = [ 00 00 00 00 00 > 00 ]; > + }; > + }; > + > + sdma@4000 { > + compatible = "marvell,mv64x60-sdma"; > + reg = <4000 c18>; > + virtual-reg = <f8104000>; > + interrupt-base = <0>; > + interrupts = <24>; > + interrupt-parent = <&/mv64x60/pic>; > + }; > + > + sdma@6000 { > + compatible = "marvell,mv64x60-sdma"; > + reg = <6000 c18>; > + virtual-reg = <f8106000>; > + interrupt-base = <0>; > + interrupts = <26>; > + interrupt-parent = <&/mv64x60/pic>; > + }; > + > + brg@b200 { > + compatible = "marvell,mv64x60-brg"; > + reg = <b200 8>; > + clock-src = <8>; > + clock-frequency = <7ed6b40>; > + current-speed = <2580>; > + bcr = <0>; > + }; > + > + brg@b208 { > + compatible = "marvell,mv64x60-brg"; > + reg = <b208 8>; > + clock-src = <8>; > + clock-frequency = <7ed6b40>; > + current-speed = <2580>; > + bcr = <0>; > + }; > + > + cunit@f200 { > + reg = <f200 200>; > + }; > + > + mpscrouting@b400 { > + reg = <b400 c>; > + }; > + > + mpscintr@b800 { > + reg = <b800 100>; > + virtual-reg = <f810b800>; > + }; > + > + mpsc@8000 { > + device_type = "serial"; > + compatible = "marvell,mpsc"; > + reg = <8000 38>; > + virtual-reg = <f8108000>; > + sdma = <&/mv64x60/sdma@4000>; > + brg = <&/mv64x60/brg@b200>; > + cunit = <&/mv64x60/cunit@f200>; > + mpscrouting = <&/mv64x60/mpscrouting@b400>; > + mpscintr = <&/mv64x60/mpscintr@b800>; > + block-index = <0>; > + max_idle = <28>; > + chr_1 = <0>; > + chr_2 = <0>; > + chr_10 = <3>; > + mpcr = <0>; > + interrupts = <28>; > + interrupt-parent = <&/mv64x60/pic>; > + }; > + > + mpsc@9000 { > + device_type = "serial"; > + compatible = "marvell,mpsc"; > + reg = <9000 38>; > + virtual-reg = <f8109000>; > + sdma = <&/mv64x60/sdma@6000>; > + brg = <&/mv64x60/brg@b208>; > + cunit = <&/mv64x60/cunit@f200>; > + mpscrouting = <&/mv64x60/mpscrouting@b400>; > + mpscintr = <&/mv64x60/mpscintr@b800>; > + block-index = <1>; > + max_idle = <28>; > + chr_1 = <0>; > + chr_2 = <0>; > + chr_10 = <3>; > + mpcr = <0>; > + interrupts = <29>; > + interrupt-parent = <&/mv64x60/pic>; > + }; > + > + wdt@b410 { /* watchdog timer > */ > + compatible = "marvell,mv64x60-wdt"; > + reg = <b410 8>; > + timeout = <a>; /* wdt timeout > in seconds */ > + }; > + > + i2c@c000 { > + compatible = "marvell,mv64x60-i2c"; > + reg = <c000 20>; > + virtual-reg = <f810c000>; > + freq_m = <8>; > + freq_n = <3>; > + timeout = <3e8>; /* 1000 = 1 > second */ > + retries = <1>; > + interrupts = <25>; > + interrupt-parent = <&/mv64x60/pic>; > + }; > + > + pic { > + #interrupt-cells = <1>; > + #address-cells = <0>; > + compatible = "marvell,mv64x60-pic"; > + reg = <0000 88>; > + interrupt-controller; > + }; > + > + mpp@f000 { > + compatible = "marvell,mv64x60-mpp"; > + reg = <f000 10>; > + }; > + > + gpp@f100 { > + compatible = "marvell,mv64x60-gpp"; > + reg = <f100 20>; > + }; > + > + pci@90000000 { > + #address-cells = <3>; > + #size-cells = <2>; > + #interrupt-cells = <1>; > + device_type = "pci"; > + compatible = "marvell,mv64x60-pci"; > + reg = <0c78 8>; > + ranges = <01000000 0 0 c1000000 0 > 01000000 > + 02000000 0 90000000 90000000 0 > 30000000>; > + bus-range = <0 ff>; > + clock-frequency = <3EF1480>; > + interrupt-pci-iack = <0c34>; > + interrupt-parent = <&/mv64x60/pic>; > + interrupt-map-mask = <f800 0 0 7>; > + interrupt-map = < > + /* IDSEL 0x1 */ > + 0800 0 0 1 &/mv64x60/pic 5a > + 0800 0 0 2 &/mv64x60/pic 5b > + 0800 0 0 3 &/mv64x60/pic 5e > + 0800 0 0 4 &/mv64x60/pic 5f > + > + /* IDSEL 0x2 */ > + 1000 0 0 1 &/mv64x60/pic 5b > + 1000 0 0 2 &/mv64x60/pic 5e > + 1000 0 0 3 &/mv64x60/pic 5f > + 1000 0 0 4 &/mv64x60/pic 5a > + > + /* IDSEL 0x3 */ > + 1800 0 0 1 &/mv64x60/pic 5e > + 1800 0 0 2 &/mv64x60/pic 5f > + 1800 0 0 3 &/mv64x60/pic 5a > + 1800 0 0 4 &/mv64x60/pic 5b > + > + /* IDSEL 0x4 */ > + 2000 0 0 1 &/mv64x60/pic 5f > + 2000 0 0 2 &/mv64x60/pic 5a > + 2000 0 0 3 &/mv64x60/pic 5b > + 2000 0 0 4 &/mv64x60/pic 5e > + > + /* IDSEL 0x6 */ > + 3000 0 0 1 &/mv64x60/pic 5b > + 3000 0 0 2 &/mv64x60/pic 5e > + 3000 0 0 3 &/mv64x60/pic 5f > + 3000 0 0 4 &/mv64x60/pic 5a > + >; > + }; > + > + cpu-error@0070 { > + compatible = "marvell,mv64x60-cpu-error"; > + reg = <0070 10 0128 28>; > + interrupts = <03>; > + interrupt-parent = <&/mv64x60/pic>; > + }; > + > + sram-ctrl@0380 { > + compatible = "marvell,mv64x60-sram-ctrl"; > + reg = <0380 80>; > + interrupts = <0d>; > + interrupt-parent = <&/mv64x60/pic>; > + }; > + > + pci-error@1d40 { > + compatible = "marvell,mv64x60-pci-error"; > + reg = <1d40 40 0c28 4>; > + interrupts = <0c>; > + interrupt-parent = <&/mv64x60/pic>; > + }; > + > + mem-ctrl@1400 { > + compatible = "marvell,mv64x60-mem-ctrl"; > + reg = <1400 60>; > + interrupts = <11>; > + interrupt-parent = <&/mv64x60/pic>; > + }; > + }; > + > + chosen { > + bootargs = "ip=on"; > + linux,stdout-path = "/mv64x60@f8100000/mpsc@8000"; > + }; Not sure it is required. At least if u-boot would have OF support, it'll rewrite chosen... > +}; > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Sincerely, Vitaly ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 4/5] PowerPC 74xx: Katana Qp base support 2007-11-16 15:43 [PATCH 0/1] PowerPC 74xx: Add Emerson Katana Qp support Andrei Dolnikov 2007-11-16 16:12 ` [PATCH 1/5] PowerPC 74xx: Katana Qp device tree Andrei Dolnikov @ 2007-11-16 16:31 ` Andrei Dolnikov 2007-11-21 16:30 ` Vitaly Bordug 2007-11-24 18:51 ` Arnd Bergmann 1 sibling, 2 replies; 27+ messages in thread From: Andrei Dolnikov @ 2007-11-16 16:31 UTC (permalink / raw) To: linuxppc-dev Emerson Katana Qp platform specific code Signed-off-by: Andrei Dolnikov <adolnikov@ru.mvista.com> --- arch/powerpc/platforms/embedded6xx/Kconfig | 9 + arch/powerpc/platforms/embedded6xx/Makefile | 1 arch/powerpc/platforms/embedded6xx/katanaqp.c | 180 ++++++++++++++++++++++++++ 3 files changed, 190 insertions(+) diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig index 8924095..33190bd 100644 --- a/arch/powerpc/platforms/embedded6xx/Kconfig +++ b/arch/powerpc/platforms/embedded6xx/Kconfig @@ -46,6 +46,15 @@ config PPC_PRPMC2800 help This option enables support for the Motorola PrPMC2800 board +config PPC_KATANAQP + bool "Emerson-Katana Qp" + depends on EMBEDDED6xx + select MV64X60 + select NOT_COHERENT_CACHE + select WANT_DEVICE_TREE + help + This option enables support for the Emerson Katana Qp board + config TSI108_BRIDGE bool depends on MPC7448HPC2 || PPC_HOLLY diff --git a/arch/powerpc/platforms/embedded6xx/Makefile b/arch/powerpc/platforms/embedded6xx/Makefile index 844947c..c83558f 100644 --- a/arch/powerpc/platforms/embedded6xx/Makefile +++ b/arch/powerpc/platforms/embedded6xx/Makefile @@ -5,3 +5,4 @@ obj-$(CONFIG_MPC7448HPC2) += mpc7448_hpc2.o obj-$(CONFIG_LINKSTATION) += linkstation.o ls_uart.o obj-$(CONFIG_PPC_HOLLY) += holly.o obj-$(CONFIG_PPC_PRPMC2800) += prpmc2800.o +obj-$(CONFIG_PPC_KATANAQP) += katanaqp.o diff --git a/arch/powerpc/platforms/embedded6xx/katanaqp.c b/arch/powerpc/platforms/embedded6xx/katanaqp.c new file mode 100644 index 0000000..c0a8469 --- /dev/null +++ b/arch/powerpc/platforms/embedded6xx/katanaqp.c @@ -0,0 +1,180 @@ +/* + * Board setup routines for the Emerson Katana Qp + * + * Authors: Vladislav Buzov <vbuzov@ru.mvista.com> + * Andrei Dolnikov <adolnikov@ru.mvista.com> + * + * Based on prpmc2800.c by Dale Farnsworth <dale@farnsworth.org> + * + * 2007 (c) MontaVista, Software, Inc. This file is licensed under + * the terms of the GNU General Public License version 2. This program + * is licensed "as is" without any warranty of any kind, whether express + * or implied. + */ + +#include <linux/stddef.h> +#include <linux/kernel.h> +#include <linux/delay.h> +#include <linux/interrupt.h> +#include <linux/seq_file.h> +#include <linux/of_platform.h> +#include <linux/pci.h> + +#include <asm/machdep.h> +#include <asm/prom.h> +#include <asm/system.h> +#include <asm/time.h> +#include <asm/kexec.h> + +#include <mm/mmu_decl.h> + +#include <sysdev/mv64x60.h> + +#define PLATFORM_NAME_MAX 64 + +/* CPLD registers definitions */ +#define KATANAQP_CPLD_RCR 0x0004 /* Reset command */ +#define KATANAQP_CPLD_RCR_CPUHR (1 << 7) + +#define KATANAQP_CPLD_HVR 0x0020 + +#define KATANAQP_CPLD_PSR 0x0030 /* PCI status */ +#define KATANAQP_CPLD_PSR_PMCM (1 << 1) + +#define KATANAQP_CPLD_HCR 0x0044 + +static char katanaqp_platform_name[PLATFORM_NAME_MAX]; + +static void __iomem *cpld_base; + +int katanaqp_exclude_device(struct pci_controller *hose, u_char bus, + u_char devfn) +{ + if (bus == 0 && PCI_SLOT(devfn) == 0) + return PCIBIOS_DEVICE_NOT_FOUND; + else + return PCIBIOS_SUCCESSFUL; +} + +static int __init katanaqp_is_monarch(void) +{ + return !(in_8((volatile char *)(cpld_base + KATANAQP_CPLD_PSR)) & + KATANAQP_CPLD_PSR_PMCM); +} + +static void __init katanaqp_setup_arch(void) +{ + struct device_node *cpld; + const unsigned int *reg; + + /* + * ioremap cpld registers in case they are later + * needed by katanaqp_reset_board(). + */ + cpld = of_find_node_by_path("/mv64x60@f8100000/cpld@f8200000"); + reg = of_get_property(cpld, "reg", NULL); + of_node_put(cpld); + cpld_base = ioremap(reg[0], reg[1]); + +#ifdef CONFIG_PCI + if (katanaqp_is_monarch()) { + mv64x60_pci_init(); + ppc_md.pci_exclude_device = katanaqp_exclude_device; + } +#endif + + printk("Emerson Network Power %s\n", katanaqp_platform_name); +} + +static void katanaqp_reset_board(void) +{ + local_irq_disable(); + + /* issue hard reset to the reset command register */ + out_8((volatile char *)(cpld_base + KATANAQP_CPLD_RCR), + KATANAQP_CPLD_RCR_CPUHR); + for (;;) ; +} + +static void katanaqp_restart(char *cmd) +{ + katanaqp_reset_board(); +} + +#ifdef CONFIG_NOT_COHERENT_CACHE +#define KATANAQP_COHERENCY_SETTING "off" +#else +#define KATANAQP_COHERENCY_SETTING "on" +#endif + +void katanaqp_show_cpuinfo(struct seq_file *m) +{ + uint memsize = total_memory; + + seq_printf(m, "vendor\t\t: Emerson Network Power\n"); + + seq_printf(m, "hardware rev\t: %d\n", + in_8((volatile char *)(cpld_base + KATANAQP_CPLD_HVR))); + + seq_printf(m, "hardware config\t: %d\n", + in_8((volatile char *)(cpld_base + KATANAQP_CPLD_HCR))); + + seq_printf(m, "memory size\t: %d MB\n", memsize / (1024 * 1024)); + + seq_printf(m, "voherency\t: %s\n", KATANAQP_COHERENCY_SETTING); + + seq_printf(m, "PCI\t\t: %sMonarch\n", + katanaqp_is_monarch() ? "" : "Non-"); +} + +static int __init katanaqp_of_init(void) +{ + struct device_node *np; + + np = of_find_compatible_node(NULL, NULL, "cfi-flash"); + if (np) + of_platform_device_create(np, "of-flash", NULL); + + return 0; +} + +device_initcall(katanaqp_of_init); + +/* + * Called very early, device-tree isn't unflattened + */ +static int __init katanaqp_probe(void) +{ + unsigned long root = of_get_flat_dt_root(); + unsigned long len = PLATFORM_NAME_MAX; + void *m; + + if (!of_flat_dt_is_compatible(root, "emerson,Katana-Qp")) + return 0; + + /* Update ppc_md.name with name from dt */ + m = of_get_flat_dt_prop(root, "model", &len); + if (m) + strncpy(katanaqp_platform_name, m, + min((int)len, PLATFORM_NAME_MAX - 1)); + + return 1; +} + +define_machine(katanaqp) +{ + .name = katanaqp_platform_name, + .probe = katanaqp_probe, + .setup_arch = katanaqp_setup_arch, + .init_early = mv64x60_init_early, + .show_cpuinfo = katanaqp_show_cpuinfo, + .init_IRQ = mv64x60_init_irq, + .get_irq = mv64x60_get_irq, + .restart = katanaqp_restart, + .calibrate_decr = generic_calibrate_decr, +#ifdef CONFIG_KEXEC + .machine_kexec = default_machine_kexec, + .machine_kexec_prepare = default_machine_kexec_prepare, + .machine_crash_shutdown = default_machine_crash_shutdown, +#endif +}; ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH 4/5] PowerPC 74xx: Katana Qp base support 2007-11-16 16:31 ` [PATCH 4/5] PowerPC 74xx: Katana Qp base support Andrei Dolnikov @ 2007-11-21 16:30 ` Vitaly Bordug 2007-11-24 18:51 ` Arnd Bergmann 1 sibling, 0 replies; 27+ messages in thread From: Vitaly Bordug @ 2007-11-21 16:30 UTC (permalink / raw) To: Andrei Dolnikov; +Cc: linuxppc-dev Hi Andrei, Looks okay in general, some notes below... On Fri, 16 Nov 2007 19:31:16 +0300 Andrei Dolnikov wrote: > Emerson Katana Qp platform specific code > > Signed-off-by: Andrei Dolnikov <adolnikov@ru.mvista.com> > > --- > arch/powerpc/platforms/embedded6xx/Kconfig | 9 + > arch/powerpc/platforms/embedded6xx/Makefile | 1 > arch/powerpc/platforms/embedded6xx/katanaqp.c | 180 > ++++++++++++++++++++++++++ 3 files changed, 190 insertions(+) > > diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig > b/arch/powerpc/platforms/embedded6xx/Kconfig index 8924095..33190bd > 100644 --- a/arch/powerpc/platforms/embedded6xx/Kconfig > +++ b/arch/powerpc/platforms/embedded6xx/Kconfig > @@ -46,6 +46,15 @@ config PPC_PRPMC2800 > help > This option enables support for the Motorola PrPMC2800 > board > +config PPC_KATANAQP > + bool "Emerson-Katana Qp" > + depends on EMBEDDED6xx > + select MV64X60 > + select NOT_COHERENT_CACHE > + select WANT_DEVICE_TREE > + help > + This option enables support for the Emerson Katana Qp board > + > config TSI108_BRIDGE > bool > depends on MPC7448HPC2 || PPC_HOLLY > diff --git a/arch/powerpc/platforms/embedded6xx/Makefile > b/arch/powerpc/platforms/embedded6xx/Makefile index 844947c..c83558f > 100644 --- a/arch/powerpc/platforms/embedded6xx/Makefile > +++ b/arch/powerpc/platforms/embedded6xx/Makefile > @@ -5,3 +5,4 @@ obj-$(CONFIG_MPC7448HPC2) += mpc7448_hpc2.o > obj-$(CONFIG_LINKSTATION) += linkstation.o ls_uart.o > obj-$(CONFIG_PPC_HOLLY) += holly.o > obj-$(CONFIG_PPC_PRPMC2800) += prpmc2800.o > +obj-$(CONFIG_PPC_KATANAQP) += katanaqp.o > diff --git a/arch/powerpc/platforms/embedded6xx/katanaqp.c > b/arch/powerpc/platforms/embedded6xx/katanaqp.c new file mode 100644 > index 0000000..c0a8469 > --- /dev/null > +++ b/arch/powerpc/platforms/embedded6xx/katanaqp.c > @@ -0,0 +1,180 @@ > +/* > + * Board setup routines for the Emerson Katana Qp > + * > + * Authors: Vladislav Buzov <vbuzov@ru.mvista.com> > + * Andrei Dolnikov <adolnikov@ru.mvista.com> > + * > + * Based on prpmc2800.c by Dale Farnsworth <dale@farnsworth.org> > + * > + * 2007 (c) MontaVista, Software, Inc. This file is licensed under > + * the terms of the GNU General Public License version 2. This > program > + * is licensed "as is" without any warranty of any kind, whether > express > + * or implied. > + */ > + > +#include <linux/stddef.h> > +#include <linux/kernel.h> > +#include <linux/delay.h> > +#include <linux/interrupt.h> > +#include <linux/seq_file.h> > +#include <linux/of_platform.h> > +#include <linux/pci.h> > + > +#include <asm/machdep.h> > +#include <asm/prom.h> > +#include <asm/system.h> > +#include <asm/time.h> > +#include <asm/kexec.h> > + > +#include <mm/mmu_decl.h> > + > +#include <sysdev/mv64x60.h> > + > +#define PLATFORM_NAME_MAX 64 > + > +/* CPLD registers definitions */ > +#define KATANAQP_CPLD_RCR 0x0004 /* Reset command */ > +#define KATANAQP_CPLD_RCR_CPUHR (1 << 7) > + > +#define KATANAQP_CPLD_HVR 0x0020 > + > +#define KATANAQP_CPLD_PSR 0x0030 /* PCI status */ > +#define KATANAQP_CPLD_PSR_PMCM (1 << 1) > + > +#define KATANAQP_CPLD_HCR 0x0044 > + > +static char katanaqp_platform_name[PLATFORM_NAME_MAX]; > + > +static void __iomem *cpld_base; > + > +int katanaqp_exclude_device(struct pci_controller *hose, u_char bus, > + u_char devfn) > +{ > + if (bus == 0 && PCI_SLOT(devfn) == 0) > + return PCIBIOS_DEVICE_NOT_FOUND; > + else > + return PCIBIOS_SUCCESSFUL; > +} > + > +static int __init katanaqp_is_monarch(void) > +{ > + return !(in_8((volatile char *)(cpld_base + > KATANAQP_CPLD_PSR)) & > + KATANAQP_CPLD_PSR_PMCM); > +} > + > +static void __init katanaqp_setup_arch(void) > +{ > + struct device_node *cpld; > + const unsigned int *reg; > + > + /* > + * ioremap cpld registers in case they are later > + * needed by katanaqp_reset_board(). > + */ > + cpld = > of_find_node_by_path("/mv64x60@f8100000/cpld@f8200000"); > + reg = of_get_property(cpld, "reg", NULL); > + of_node_put(cpld); > + cpld_base = ioremap(reg[0], reg[1]); > + use of_iomap here? > +#ifdef CONFIG_PCI > + if (katanaqp_is_monarch()) { > + mv64x60_pci_init(); > + ppc_md.pci_exclude_device = katanaqp_exclude_device; > + } > +#endif > + > + printk("Emerson Network Power %s\n", katanaqp_platform_name); > +} > + > +static void katanaqp_reset_board(void) > +{ > + local_irq_disable(); > + > + /* issue hard reset to the reset command register */ > + out_8((volatile char *)(cpld_base + KATANAQP_CPLD_RCR), > + KATANAQP_CPLD_RCR_CPUHR); > + for (;;) ; > +} > + > +static void katanaqp_restart(char *cmd) > +{ > + katanaqp_reset_board(); > +} > + > +#ifdef CONFIG_NOT_COHERENT_CACHE > +#define KATANAQP_COHERENCY_SETTING "off" > +#else > +#define KATANAQP_COHERENCY_SETTING "on" > +#endif > + Does it mean this HW supports both coherent and non-coherent case? I don't think we need to add this just "for the future" if QP doesn't have it. If it does, I dont' see how it's being handled - defconfig just enables noncoherent upper. > +void katanaqp_show_cpuinfo(struct seq_file *m) > +{ > + uint memsize = total_memory; > + > + seq_printf(m, "vendor\t\t: Emerson Network Power\n"); > + > + seq_printf(m, "hardware rev\t: %d\n", > + in_8((volatile char *)(cpld_base + > KATANAQP_CPLD_HVR))); + > + seq_printf(m, "hardware config\t: %d\n", > + in_8((volatile char *)(cpld_base + > KATANAQP_CPLD_HCR))); + > + seq_printf(m, "memory size\t: %d MB\n", memsize / (1024 * > 1024)); + > + seq_printf(m, "voherency\t: %s\n", > KATANAQP_COHERENCY_SETTING); + > + seq_printf(m, "PCI\t\t: %sMonarch\n", > + katanaqp_is_monarch() ? "" : "Non-"); > +} > + > +static int __init katanaqp_of_init(void) > +{ > + struct device_node *np; > + > + np = of_find_compatible_node(NULL, NULL, "cfi-flash"); > + if (np) > + of_platform_device_create(np, "of-flash", NULL); > + Why not using of_device for physmap? > + return 0; > +} > + > +device_initcall(katanaqp_of_init); > + > +/* > + * Called very early, device-tree isn't unflattened > + */ > +static int __init katanaqp_probe(void) > +{ > + unsigned long root = of_get_flat_dt_root(); > + unsigned long len = PLATFORM_NAME_MAX; not needed - get-prop will rewrite it anyway. > + void *m; > + > + if (!of_flat_dt_is_compatible(root, "emerson,Katana-Qp")) > + return 0; > + > + /* Update ppc_md.name with name from dt */ > + m = of_get_flat_dt_prop(root, "model", &len); > + if (m) > + strncpy(katanaqp_platform_name, m, > + min((int)len, PLATFORM_NAME_MAX - 1)); > + > + return 1; > +} > + > +define_machine(katanaqp) > +{ > + .name = katanaqp_platform_name, > + .probe = katanaqp_probe, > + .setup_arch = katanaqp_setup_arch, > + .init_early = mv64x60_init_early, > + .show_cpuinfo = katanaqp_show_cpuinfo, > + .init_IRQ = mv64x60_init_irq, > + .get_irq = mv64x60_get_irq, > + .restart = katanaqp_restart, > + .calibrate_decr = generic_calibrate_decr, > +#ifdef CONFIG_KEXEC > + .machine_kexec = default_machine_kexec, > + .machine_kexec_prepare = > default_machine_kexec_prepare, > + .machine_crash_shutdown = > default_machine_crash_shutdown, +#endif > +}; > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Sincerely, Vitaly ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 4/5] PowerPC 74xx: Katana Qp base support 2007-11-16 16:31 ` [PATCH 4/5] PowerPC 74xx: Katana Qp base support Andrei Dolnikov 2007-11-21 16:30 ` Vitaly Bordug @ 2007-11-24 18:51 ` Arnd Bergmann 2007-11-24 22:28 ` Benjamin Herrenschmidt 1 sibling, 1 reply; 27+ messages in thread From: Arnd Bergmann @ 2007-11-24 18:51 UTC (permalink / raw) To: linuxppc-dev On Friday 16 November 2007, Andrei Dolnikov wrote: > +static int __init katanaqp_is_monarch(void) > +{ > + return !(in_8((volatile char *)(cpld_base + KATANAQP_CPLD_PSR)) & > + KATANAQP_CPLD_PSR_PMCM); > +} The pointer here needs to be __iomem, not volatile. Same in other places. Please use 'sparse' to check your code for bugs like this. > + > +static void __init katanaqp_setup_arch(void) > +{ > + struct device_node *cpld; > + const unsigned int *reg; > + > + /* > + * ioremap cpld registers in case they are later > + * needed by katanaqp_reset_board(). > + */ > + cpld = of_find_node_by_path("/mv64x60@f8100000/cpld@f8200000"); It doesn't sounds good to hardcode the path for this device. Instead, it would be much better to look for the 'compatible' property here. > +static int __init katanaqp_of_init(void) > +{ > + struct device_node *np; > + > + np = of_find_compatible_node(NULL, NULL, "cfi-flash"); > + if (np) > + of_platform_device_create(np, "of-flash", NULL); > + > + return 0; > +} > + > +device_initcall(katanaqp_of_init); This should be done automatically using of_platform_bus_probe(). Arnd <>< ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 4/5] PowerPC 74xx: Katana Qp base support 2007-11-24 18:51 ` Arnd Bergmann @ 2007-11-24 22:28 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 27+ messages in thread From: Benjamin Herrenschmidt @ 2007-11-24 22:28 UTC (permalink / raw) To: Arnd Bergmann; +Cc: linuxppc-dev On Sat, 2007-11-24 at 19:51 +0100, Arnd Bergmann wrote: > > This should be done automatically using of_platform_bus_probe(). Not necessarily. of_platform_bus_probe() is an optional facility that is common used by SoCs that have lots of otherwise non-probable on chip devices, but for platforms with more classic setups, it's totally acceptable to have the platform code explicitely register only those devices it wants exposed. Ben. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 0/5] PowerPC 74xx: Add Emerson Katana Qp support
@ 2007-11-29 15:07 Andrei Dolnikov
2007-11-29 15:28 ` [PATCH 1/5] PowerPC 74xx: Katana Qp device tree Andrei Dolnikov
0 siblings, 1 reply; 27+ messages in thread
From: Andrei Dolnikov @ 2007-11-29 15:07 UTC (permalink / raw)
To: linuxppc-dev
Hello folks,
The following patch sequence is Emerson KatanaQp board support reworked after initial review/discussion.
The patches are incremental to minor mv64x60 code fixups sent by
Mark A. Greer on 11/08/07.
Let me know if you think that some updates/changes needed.
As for Vitaly's and Arnd's questions:
Vitaly Bordug wrote:
>> + clock-frequency = <7f28155>; /*
>> 133.333333 MHz */
>This should be updated somewhere in fw or bootwrapper.. Or is it hardcoded
>value that is not going to change?
Yep, it is :)
About cfi-flash: I leave this code as is, according to Benjamin comment.
Thanks,
Andrei.
^ permalink raw reply [flat|nested] 27+ messages in thread* [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-11-29 15:07 [PATCH 0/5] PowerPC 74xx: Add Emerson Katana Qp support Andrei Dolnikov @ 2007-11-29 15:28 ` Andrei Dolnikov 2007-12-03 1:50 ` David Gibson 2007-12-03 20:52 ` Benjamin Herrenschmidt 0 siblings, 2 replies; 27+ messages in thread From: Andrei Dolnikov @ 2007-11-29 15:28 UTC (permalink / raw) To: linuxppc-dev Device tree source file for the Emerson Katana Qp board Signed-off-by: Andrei Dolnikov <adolnikov@ru.mvisa.com> --- katanaqp.dts | 360 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 360 insertions(+) diff --git a/arch/powerpc/boot/dts/katanaqp.dts b/arch/powerpc/boot/dts/katanaqp.dts new file mode 100644 index 0000000..98257a2 --- /dev/null +++ b/arch/powerpc/boot/dts/katanaqp.dts @@ -0,0 +1,360 @@ +/* Device Tree Source for Emerson Katana Qp + * + * Authors: Vladislav Buzov <vbuzov@ru.mvista.com> + * Andrei Dolnikov <adolnikov@ru.mvista.com> + * + * Based on prpmc8200.dts by Mark A. Greer <mgreer@mvista.com> + * + * 2007 (c) MontaVista, Software, Inc. This file is licensed under + * the terms of the GNU General Public License version 2. This program + * is licensed "as is" without any warranty of any kind, whether express + * or implied. + * + */ + +/ { + #address-cells = <1>; + #size-cells = <1>; + model = "Katana-Qp"; /* Default */ + compatible = "emerson,Katana-Qp"; + coherency-off; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + PowerPC,7448@0 { + device_type = "cpu"; + reg = <0>; + clock-frequency = <0>; /* From U-boot */ + bus-frequency = <0>; /* From U-boot */ + timebase-frequency = <0>; /* From U-boot */ + i-cache-line-size = <20>; + d-cache-line-size = <20>; + i-cache-size = <8000>; + d-cache-size = <8000>; + }; + }; + + memory { + device_type = "memory"; + reg = <00000000 00000000>; /* Filled in by bootwrapper */ + }; + + mv64x60@f8100000 { /* Marvell Discovery */ + #address-cells = <1>; + #size-cells = <1>; + model = "mv64460"; /* Default */ + compatible = "marvell,mv64x60"; + clock-frequency = <7f28155>; /* 133.333333 MHz */ + reg = <f8100000 00010000>; + virtual-reg = <f8100000>; + ranges = <c1000000 c1000000 01000000 /* PCI 1 I/O Space */ + 90000000 90000000 30000000 /* PCI 1 MEM Space */ + e8000000 e8000000 04000000 /* User FLASH: Up to 64Mb */ + 00000000 f8100000 00010000 /* Bridge's regs */ + f8500000 f8500000 00040000>; /* Integrated SRAM */ + + flash@e8000000 { + compatible = "cfi-flash"; + reg = <e8000000 1000000>; /* Default (16MB) */ + probe-type = "CFI"; + bank-width = <4>; + + partition@0 { + label = "Primary Monitor"; + reg = <0 100000>; /* 1Mb */ + read-only; + }; + + partition@100000 { + label = "Primary Kernel"; + reg = <100000 200000>; /* 2 Mb */ + }; + + partition@300000 { + label = "Primary FS"; + reg = <300000 d00000>; /* 13 Mb */ + }; + + }; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + compatible = "marvell,mv64x60-mdio"; + ethernet-phy@0 { + block-index = <0>; + compatible = "marvell,mv88e1111"; + reg = <a>; + }; + ethernet-phy@1 { + compatible = "marvell,mv88e1111"; + block-index = <1>; + reg = <d>; + }; + ethernet-phy@2 { + compatible = "marvell,mv88e1111"; + block-index = <2>; + reg = <6>; + }; + }; + + ethernet@2000 { + reg = <2000 2000>; + eth0 { + device_type = "network"; + compatible = "marvell,mv64x60-eth"; + block-index = <0>; + interrupts = <20>; + interrupt-parent = <&/mv64x60/pic>; + phy = <&/mv64x60/mdio/ethernet-phy@0>; + speed = <3e8>; + duplex = <1>; + tx_queue_size = <320>; + rx_queue_size = <190>; + local-mac-address = [ 00 00 00 00 00 00 ]; + /* Mac address filled in by bootwrapper */ + }; + eth1 { + device_type = "network"; + compatible = "marvell,mv64x60-eth"; + block-index = <1>; + interrupts = <21>; + interrupt-parent = <&/mv64x60/pic>; + phy = <&/mv64x60/mdio/ethernet-phy@1>; + speed = <3e8>; + duplex = <1>; + tx_queue_size = <320>; + rx_queue_size = <190>; + local-mac-address = [ 00 00 00 00 00 00 ]; + /* Mac address filled in by bootwrapper */ + }; + eth2 { + device_type = "network"; + compatible = "marvell,mv64x60-eth"; + block-index = <2>; + interrupts = <22>; + interrupt-parent = <&/mv64x60/pic>; + phy = <&/mv64x60/mdio/ethernet-phy@2>; + speed = <3e8>; + duplex = <1>; + tx_queue_size = <320>; + rx_queue_size = <190>; + local-mac-address = [ 00 00 00 00 00 00 ]; + /* Mac address filled in by bootwrapper */ + }; + }; + + sdma@4000 { + compatible = "marvell,mv64x60-sdma"; + reg = <4000 c18>; + virtual-reg = <f8104000>; + interrupt-base = <0>; + interrupts = <24>; + interrupt-parent = <&/mv64x60/pic>; + }; + + sdma@6000 { + compatible = "marvell,mv64x60-sdma"; + reg = <6000 c18>; + virtual-reg = <f8106000>; + interrupt-base = <0>; + interrupts = <26>; + interrupt-parent = <&/mv64x60/pic>; + }; + + brg@b200 { + compatible = "marvell,mv64x60-brg"; + reg = <b200 8>; + clock-src = <8>; + clock-frequency = <7ed6b40>; + current-speed = <2580>; + bcr = <0>; + }; + + brg@b208 { + compatible = "marvell,mv64x60-brg"; + reg = <b208 8>; + clock-src = <8>; + clock-frequency = <7ed6b40>; + current-speed = <2580>; + bcr = <0>; + }; + + cunit@f200 { + reg = <f200 200>; + }; + + mpscrouting@b400 { + reg = <b400 c>; + }; + + mpscintr@b800 { + reg = <b800 100>; + virtual-reg = <f810b800>; + }; + + mpsc@8000 { + device_type = "serial"; + compatible = "marvell,mpsc"; + reg = <8000 38>; + virtual-reg = <f8108000>; + sdma = <&/mv64x60/sdma@4000>; + brg = <&/mv64x60/brg@b200>; + cunit = <&/mv64x60/cunit@f200>; + mpscrouting = <&/mv64x60/mpscrouting@b400>; + mpscintr = <&/mv64x60/mpscintr@b800>; + block-index = <0>; + max_idle = <28>; + chr_1 = <0>; + chr_2 = <0>; + chr_10 = <3>; + mpcr = <0>; + interrupts = <28>; + interrupt-parent = <&/mv64x60/pic>; + }; + + mpsc@9000 { + device_type = "serial"; + compatible = "marvell,mpsc"; + reg = <9000 38>; + virtual-reg = <f8109000>; + sdma = <&/mv64x60/sdma@6000>; + brg = <&/mv64x60/brg@b208>; + cunit = <&/mv64x60/cunit@f200>; + mpscrouting = <&/mv64x60/mpscrouting@b400>; + mpscintr = <&/mv64x60/mpscintr@b800>; + block-index = <1>; + max_idle = <28>; + chr_1 = <0>; + chr_2 = <0>; + chr_10 = <3>; + mpcr = <0>; + interrupts = <29>; + interrupt-parent = <&/mv64x60/pic>; + }; + + wdt@b410 { /* watchdog timer */ + compatible = "marvell,mv64x60-wdt"; + reg = <b410 8>; + timeout = <a>; /* wdt timeout in seconds */ + }; + + i2c@c000 { + compatible = "marvell,mv64x60-i2c"; + reg = <c000 20>; + virtual-reg = <f810c000>; + freq_m = <8>; + freq_n = <3>; + timeout = <3e8>; /* 1000 = 1 second */ + retries = <1>; + interrupts = <25>; + interrupt-parent = <&/mv64x60/pic>; + }; + + pic { + #interrupt-cells = <1>; + #address-cells = <0>; + compatible = "marvell,mv64x60-pic"; + reg = <0000 88>; + interrupt-controller; + }; + + mpp@f000 { + compatible = "marvell,mv64x60-mpp"; + reg = <f000 10>; + }; + + gpp@f100 { + compatible = "marvell,mv64x60-gpp"; + reg = <f100 20>; + }; + + pci@90000000 { + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + device_type = "pci"; + compatible = "marvell,mv64x60-pci"; + reg = <0c78 8>; + ranges = <01000000 0 0 c1000000 0 01000000 + 02000000 0 90000000 90000000 0 30000000>; + bus-range = <0 ff>; + clock-frequency = <3EF1480>; + interrupt-pci-iack = <0c34>; + interrupt-parent = <&/mv64x60/pic>; + interrupt-map-mask = <f800 0 0 7>; + interrupt-map = < + /* IDSEL 0x1 */ + 0800 0 0 1 &/mv64x60/pic 5a + 0800 0 0 2 &/mv64x60/pic 5b + 0800 0 0 3 &/mv64x60/pic 5e + 0800 0 0 4 &/mv64x60/pic 5f + + /* IDSEL 0x2 */ + 1000 0 0 1 &/mv64x60/pic 5b + 1000 0 0 2 &/mv64x60/pic 5e + 1000 0 0 3 &/mv64x60/pic 5f + 1000 0 0 4 &/mv64x60/pic 5a + + /* IDSEL 0x3 */ + 1800 0 0 1 &/mv64x60/pic 5e + 1800 0 0 2 &/mv64x60/pic 5f + 1800 0 0 3 &/mv64x60/pic 5a + 1800 0 0 4 &/mv64x60/pic 5b + + /* IDSEL 0x4 */ + 2000 0 0 1 &/mv64x60/pic 5f + 2000 0 0 2 &/mv64x60/pic 5a + 2000 0 0 3 &/mv64x60/pic 5b + 2000 0 0 4 &/mv64x60/pic 5e + + /* IDSEL 0x6 */ + 3000 0 0 1 &/mv64x60/pic 5b + 3000 0 0 2 &/mv64x60/pic 5e + 3000 0 0 3 &/mv64x60/pic 5f + 3000 0 0 4 &/mv64x60/pic 5a + >; + }; + + cpu-error@0070 { + compatible = "marvell,mv64x60-cpu-error"; + reg = <0070 10 0128 28>; + interrupts = <03>; + interrupt-parent = <&/mv64x60/pic>; + }; + + sram-ctrl@0380 { + compatible = "marvell,mv64x60-sram-ctrl"; + reg = <0380 80>; + interrupts = <0d>; + interrupt-parent = <&/mv64x60/pic>; + }; + + pci-error@1d40 { + compatible = "marvell,mv64x60-pci-error"; + reg = <1d40 40 0c28 4>; + interrupts = <0c>; + interrupt-parent = <&/mv64x60/pic>; + }; + + mem-ctrl@1400 { + compatible = "marvell,mv64x60-mem-ctrl"; + reg = <1400 60>; + interrupts = <11>; + interrupt-parent = <&/mv64x60/pic>; + }; + }; + + cpld@f8200000 { + compatible = "altera,maxii"; + reg = <f8200000 40000>; + virtual-reg = <f8200000>; + }; + + chosen { + bootargs = "ip=on"; + linux,stdout-path = "/mv64x60@f8100000/mpsc@8000"; + }; +}; ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-11-29 15:28 ` [PATCH 1/5] PowerPC 74xx: Katana Qp device tree Andrei Dolnikov @ 2007-12-03 1:50 ` David Gibson 2007-12-03 19:26 ` Jon Loeliger ` (2 more replies) 2007-12-03 20:52 ` Benjamin Herrenschmidt 1 sibling, 3 replies; 27+ messages in thread From: David Gibson @ 2007-12-03 1:50 UTC (permalink / raw) To: Andrei Dolnikov; +Cc: linuxppc-dev On Thu, Nov 29, 2007 at 06:28:36PM +0300, Andrei Dolnikov wrote: > Device tree source file for the Emerson Katana Qp board > > Signed-off-by: Andrei Dolnikov <adolnikov@ru.mvisa.com> > > --- > katanaqp.dts | 360 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 360 insertions(+) > > diff --git a/arch/powerpc/boot/dts/katanaqp.dts b/arch/powerpc/boot/dts/katanaqp.dts > new file mode 100644 > index 0000000..98257a2 > --- /dev/null > +++ b/arch/powerpc/boot/dts/katanaqp.dts > @@ -0,0 +1,360 @@ > +/* Device Tree Source for Emerson Katana Qp > + * > + * Authors: Vladislav Buzov <vbuzov@ru.mvista.com> > + * Andrei Dolnikov <adolnikov@ru.mvista.com> > + * > + * Based on prpmc8200.dts by Mark A. Greer <mgreer@mvista.com> > + * > + * 2007 (c) MontaVista, Software, Inc. This file is licensed under > + * the terms of the GNU General Public License version 2. This program > + * is licensed "as is" without any warranty of any kind, whether express > + * or implied. > + * > + */ > + > +/ { > + #address-cells = <1>; > + #size-cells = <1>; > + model = "Katana-Qp"; /* Default */ > + compatible = "emerson,Katana-Qp"; > + coherency-off; What is this property for? > + > + cpus { > + #address-cells = <1>; > + #size-cells = <0>; > + > + PowerPC,7448@0 { > + device_type = "cpu"; > + reg = <0>; > + clock-frequency = <0>; /* From U-boot */ > + bus-frequency = <0>; /* From U-boot */ > + timebase-frequency = <0>; /* From U-boot */ > + i-cache-line-size = <20>; > + d-cache-line-size = <20>; > + i-cache-size = <8000>; > + d-cache-size = <8000>; > + }; > + }; > + > + memory { > + device_type = "memory"; > + reg = <00000000 00000000>; /* Filled in by bootwrapper */ > + }; > + > + mv64x60@f8100000 { /* Marvell Discovery */ > + #address-cells = <1>; > + #size-cells = <1>; > + model = "mv64460"; /* Default */ > + compatible = "marvell,mv64x60"; Compatible properties should not have "x" asn in 64x60 here. If there's a suitable name for the general register interface use that, otherwise use the specific model number of the earliest device to implement this register interface. Later models should have a compatible property which lists their specific model, followed by the earlier model number with which they're compatible. > + clock-frequency = <7f28155>; /* 133.333333 MHz */ You can use <d# 133333333> to avoid the ugly hex. > + reg = <f8100000 00010000>; > + virtual-reg = <f8100000>; > + ranges = <c1000000 c1000000 01000000 /* PCI 1 I/O Space */ > + 90000000 90000000 30000000 /* PCI 1 MEM Space */ > + e8000000 e8000000 04000000 /* User FLASH: Up to 64Mb */ > + 00000000 f8100000 00010000 /* Bridge's regs */ > + f8500000 f8500000 00040000>; /* Integrated SRAM */ These ranges look kind of weird, but I'd have to think about them harder to say something more specific. > + flash@e8000000 { > + compatible = "cfi-flash"; > + reg = <e8000000 1000000>; /* Default (16MB) */ > + probe-type = "CFI"; You're using the new-style binding (compatible == "cfi-flash"), so the obsolete probe-tyope property should not be included. > + bank-width = <4>; > + > + partition@0 { > + label = "Primary Monitor"; > + reg = <0 100000>; /* 1Mb */ > + read-only; > + }; > + > + partition@100000 { > + label = "Primary Kernel"; > + reg = <100000 200000>; /* 2 Mb */ > + }; > + > + partition@300000 { > + label = "Primary FS"; > + reg = <300000 d00000>; /* 13 Mb */ > + }; > + > + }; > + > + mdio { There must be some way of actuall accessing the mdio bus, so this node ought to have a 'reg' property and unit address. > + #address-cells = <1>; > + #size-cells = <0>; > + compatible = "marvell,mv64x60-mdio"; > + ethernet-phy@0 { > + block-index = <0>; > + compatible = "marvell,mv88e1111"; > + reg = <a>; > + }; > + ethernet-phy@1 { > + compatible = "marvell,mv88e1111"; > + block-index = <1>; > + reg = <d>; > + }; > + ethernet-phy@2 { > + compatible = "marvell,mv88e1111"; > + block-index = <2>; > + reg = <6>; > + }; > + }; > + > + ethernet@2000 { > + reg = <2000 2000>; Are the registers for the 3 ethernets really all together? This bank can't be subdivided into seperate register blocks for each MAC? > + eth0 { > + device_type = "network"; > + compatible = "marvell,mv64x60-eth"; > + block-index = <0>; This block-index thing is crap. If you really need to subindex nodes like this, use "reg", with an appropriate #address-cells in the parent, then the nodes will also get sensible unit addresses. > + interrupts = <20>; > + interrupt-parent = <&/mv64x60/pic>; You should use a label for the PIC to make things more readable. > + phy = <&/mv64x60/mdio/ethernet-phy@0>; > + speed = <3e8>; > + duplex = <1>; > + tx_queue_size = <320>; > + rx_queue_size = <190>; > + local-mac-address = [ 00 00 00 00 00 00 ]; > + /* Mac address filled in by bootwrapper */ > + }; > + eth1 { > + device_type = "network"; > + compatible = "marvell,mv64x60-eth"; > + block-index = <1>; > + interrupts = <21>; > + interrupt-parent = <&/mv64x60/pic>; > + phy = <&/mv64x60/mdio/ethernet-phy@1>; > + speed = <3e8>; > + duplex = <1>; > + tx_queue_size = <320>; > + rx_queue_size = <190>; > + local-mac-address = [ 00 00 00 00 00 00 ]; > + /* Mac address filled in by bootwrapper */ > + }; > + eth2 { > + device_type = "network"; > + compatible = "marvell,mv64x60-eth"; > + block-index = <2>; > + interrupts = <22>; > + interrupt-parent = <&/mv64x60/pic>; > + phy = <&/mv64x60/mdio/ethernet-phy@2>; > + speed = <3e8>; > + duplex = <1>; > + tx_queue_size = <320>; > + rx_queue_size = <190>; > + local-mac-address = [ 00 00 00 00 00 00 ]; > + /* Mac address filled in by bootwrapper */ > + }; > + }; > + > + sdma@4000 { > + compatible = "marvell,mv64x60-sdma"; > + reg = <4000 c18>; > + virtual-reg = <f8104000>; Why does this node have virtual-reg? > + interrupt-base = <0>; > + interrupts = <24>; > + interrupt-parent = <&/mv64x60/pic>; > + }; > + > + sdma@6000 { > + compatible = "marvell,mv64x60-sdma"; > + reg = <6000 c18>; > + virtual-reg = <f8106000>; And again. > + interrupt-base = <0>; > + interrupts = <26>; > + interrupt-parent = <&/mv64x60/pic>; > + }; > + > + brg@b200 { > + compatible = "marvell,mv64x60-brg"; > + reg = <b200 8>; > + clock-src = <8>; > + clock-frequency = <7ed6b40>; > + current-speed = <2580>; > + bcr = <0>; > + }; > + > + brg@b208 { > + compatible = "marvell,mv64x60-brg"; > + reg = <b208 8>; > + clock-src = <8>; > + clock-frequency = <7ed6b40>; > + current-speed = <2580>; > + bcr = <0>; > + }; > + > + cunit@f200 { > + reg = <f200 200>; > + }; > + > + mpscrouting@b400 { > + reg = <b400 c>; > + }; > + > + mpscintr@b800 { > + reg = <b800 100>; > + virtual-reg = <f810b800>; > + }; > + > + mpsc@8000 { > + device_type = "serial"; > + compatible = "marvell,mpsc"; > + reg = <8000 38>; > + virtual-reg = <f8108000>; > + sdma = <&/mv64x60/sdma@4000>; > + brg = <&/mv64x60/brg@b200>; > + cunit = <&/mv64x60/cunit@f200>; > + mpscrouting = <&/mv64x60/mpscrouting@b400>; > + mpscintr = <&/mv64x60/mpscintr@b800>; > + block-index = <0>; What is this block-index thing about here? Since the devices are disambiguated by their register address, why do you need it? > + max_idle = <28>; > + chr_1 = <0>; > + chr_2 = <0>; > + chr_10 = <3>; > + mpcr = <0>; > + interrupts = <28>; > + interrupt-parent = <&/mv64x60/pic>; > + }; > + > + mpsc@9000 { > + device_type = "serial"; > + compatible = "marvell,mpsc"; > + reg = <9000 38>; > + virtual-reg = <f8109000>; > + sdma = <&/mv64x60/sdma@6000>; > + brg = <&/mv64x60/brg@b208>; > + cunit = <&/mv64x60/cunit@f200>; > + mpscrouting = <&/mv64x60/mpscrouting@b400>; > + mpscintr = <&/mv64x60/mpscintr@b800>; > + block-index = <1>; > + max_idle = <28>; > + chr_1 = <0>; > + chr_2 = <0>; > + chr_10 = <3>; > + mpcr = <0>; > + interrupts = <29>; > + interrupt-parent = <&/mv64x60/pic>; > + }; > + > + wdt@b410 { /* watchdog timer */ > + compatible = "marvell,mv64x60-wdt"; > + reg = <b410 8>; > + timeout = <a>; /* wdt timeout in seconds */ Uh... that looks like it should be a configuration parameter, not a device tree property. > + }; > + > + i2c@c000 { > + compatible = "marvell,mv64x60-i2c"; > + reg = <c000 20>; > + virtual-reg = <f810c000>; > + freq_m = <8>; > + freq_n = <3>; > + timeout = <3e8>; /* 1000 = 1 second */ > + retries = <1>; > + interrupts = <25>; > + interrupt-parent = <&/mv64x60/pic>; > + }; > + > + pic { Needs a unit address. > + #interrupt-cells = <1>; > + #address-cells = <0>; > + compatible = "marvell,mv64x60-pic"; > + reg = <0000 88>; > + interrupt-controller; > + }; > + > + mpp@f000 { > + compatible = "marvell,mv64x60-mpp"; > + reg = <f000 10>; > + }; > + > + gpp@f100 { > + compatible = "marvell,mv64x60-gpp"; > + reg = <f100 20>; > + }; > + > + pci@90000000 { > + #address-cells = <3>; > + #size-cells = <2>; > + #interrupt-cells = <1>; > + device_type = "pci"; > + compatible = "marvell,mv64x60-pci"; > + reg = <0c78 8>; > + ranges = <01000000 0 0 c1000000 0 01000000 > + 02000000 0 90000000 90000000 0 30000000>; > + bus-range = <0 ff>; > + clock-frequency = <3EF1480>; > + interrupt-pci-iack = <0c34>; > + interrupt-parent = <&/mv64x60/pic>; > + interrupt-map-mask = <f800 0 0 7>; > + interrupt-map = < > + /* IDSEL 0x1 */ > + 0800 0 0 1 &/mv64x60/pic 5a > + 0800 0 0 2 &/mv64x60/pic 5b > + 0800 0 0 3 &/mv64x60/pic 5e > + 0800 0 0 4 &/mv64x60/pic 5f > + > + /* IDSEL 0x2 */ > + 1000 0 0 1 &/mv64x60/pic 5b > + 1000 0 0 2 &/mv64x60/pic 5e > + 1000 0 0 3 &/mv64x60/pic 5f > + 1000 0 0 4 &/mv64x60/pic 5a > + > + /* IDSEL 0x3 */ > + 1800 0 0 1 &/mv64x60/pic 5e > + 1800 0 0 2 &/mv64x60/pic 5f > + 1800 0 0 3 &/mv64x60/pic 5a > + 1800 0 0 4 &/mv64x60/pic 5b > + > + /* IDSEL 0x4 */ > + 2000 0 0 1 &/mv64x60/pic 5f > + 2000 0 0 2 &/mv64x60/pic 5a > + 2000 0 0 3 &/mv64x60/pic 5b > + 2000 0 0 4 &/mv64x60/pic 5e > + > + /* IDSEL 0x6 */ > + 3000 0 0 1 &/mv64x60/pic 5b > + 3000 0 0 2 &/mv64x60/pic 5e > + 3000 0 0 3 &/mv64x60/pic 5f > + 3000 0 0 4 &/mv64x60/pic 5a > + >; > + }; > + > + cpu-error@0070 { The unit address should notr include leading zeroes. > + compatible = "marvell,mv64x60-cpu-error"; > + reg = <0070 10 0128 28>; > + interrupts = <03>; > + interrupt-parent = <&/mv64x60/pic>; > + }; > + > + sram-ctrl@0380 { > + compatible = "marvell,mv64x60-sram-ctrl"; > + reg = <0380 80>; > + interrupts = <0d>; > + interrupt-parent = <&/mv64x60/pic>; > + }; > + > + pci-error@1d40 { > + compatible = "marvell,mv64x60-pci-error"; > + reg = <1d40 40 0c28 4>; > + interrupts = <0c>; > + interrupt-parent = <&/mv64x60/pic>; > + }; > + > + mem-ctrl@1400 { > + compatible = "marvell,mv64x60-mem-ctrl"; > + reg = <1400 60>; > + interrupts = <11>; > + interrupt-parent = <&/mv64x60/pic>; > + }; > + }; > + > + cpld@f8200000 { > + compatible = "altera,maxii"; > + reg = <f8200000 40000>; > + virtual-reg = <f8200000>; > + }; > + > + chosen { > + bootargs = "ip=on"; > + linux,stdout-path = "/mv64x60@f8100000/mpsc@8000"; > + }; > +}; -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-12-03 1:50 ` David Gibson @ 2007-12-03 19:26 ` Jon Loeliger 2007-12-04 0:33 ` David Gibson 2007-12-04 2:10 ` Mark A. Greer 2007-12-10 21:18 ` Dale Farnsworth 2 siblings, 1 reply; 27+ messages in thread From: Jon Loeliger @ 2007-12-03 19:26 UTC (permalink / raw) To: David Gibson; +Cc: linuxppc-dev@ozlabs.org On Sun, 2007-12-02 at 19:50, David Gibson wrote: > > + clock-frequency = <7f28155>; /* 133.333333 MHz */ > You can use <d# 133333333> to avoid the ugly hex. Better still, blaze a new trail, convert it to /dts-v1/ and use clock-frequency = <133333333> straight up! jdl ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-12-03 19:26 ` Jon Loeliger @ 2007-12-04 0:33 ` David Gibson 2007-12-04 13:14 ` Jon Loeliger 0 siblings, 1 reply; 27+ messages in thread From: David Gibson @ 2007-12-04 0:33 UTC (permalink / raw) To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org On Mon, Dec 03, 2007 at 01:26:34PM -0600, Jon Loeliger wrote: > On Sun, 2007-12-02 at 19:50, David Gibson wrote: > > > > + clock-frequency = <7f28155>; /* 133.333333 MHz */ > > You can use <d# 133333333> to avoid the ugly hex. > > Better still, blaze a new trail, convert it to /dts-v1/ and > use clock-frequency = <133333333> straight up! Hrm.. probably best to wait for dtc to go into the kernel for that. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-12-04 0:33 ` David Gibson @ 2007-12-04 13:14 ` Jon Loeliger 0 siblings, 0 replies; 27+ messages in thread From: Jon Loeliger @ 2007-12-04 13:14 UTC (permalink / raw) To: Jon Loeliger, linuxppc-dev@ozlabs.org David Gibson wrote: > On Mon, Dec 03, 2007 at 01:26:34PM -0600, Jon Loeliger wrote: >> On Sun, 2007-12-02 at 19:50, David Gibson wrote: >> >>>> + clock-frequency = <7f28155>; /* 133.333333 MHz */ >>> You can use <d# 133333333> to avoid the ugly hex. >> Better still, blaze a new trail, convert it to /dts-v1/ and >> use clock-frequency = <133333333> straight up! > > Hrm.. probably best to wait for dtc to go into the kernel for that. > I disagree. jdl ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-12-03 1:50 ` David Gibson 2007-12-03 19:26 ` Jon Loeliger @ 2007-12-04 2:10 ` Mark A. Greer 2007-12-04 2:50 ` David Gibson 2007-12-10 21:18 ` Dale Farnsworth 2 siblings, 1 reply; 27+ messages in thread From: Mark A. Greer @ 2007-12-04 2:10 UTC (permalink / raw) To: Andrei Dolnikov, linuxppc-dev On Mon, Dec 03, 2007 at 12:50:18PM +1100, David Gibson wrote: > On Thu, Nov 29, 2007 at 06:28:36PM +0300, Andrei Dolnikov wrote: > > Device tree source file for the Emerson Katana Qp board > > > > Signed-off-by: Andrei Dolnikov <adolnikov@ru.mvisa.com> > > > > --- > > katanaqp.dts | 360 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 files changed, 360 insertions(+) > > > > diff --git a/arch/powerpc/boot/dts/katanaqp.dts b/arch/powerpc/boot/dts/katanaqp.dts > > new file mode 100644 > > index 0000000..98257a2 > > --- /dev/null > > +++ b/arch/powerpc/boot/dts/katanaqp.dts > > @@ -0,0 +1,360 @@ > > +/* Device Tree Source for Emerson Katana Qp > > + * > > + * Authors: Vladislav Buzov <vbuzov@ru.mvista.com> > > + * Andrei Dolnikov <adolnikov@ru.mvista.com> > > + * > > + * Based on prpmc8200.dts by Mark A. Greer <mgreer@mvista.com> > > + * > > + * 2007 (c) MontaVista, Software, Inc. This file is licensed under > > + * the terms of the GNU General Public License version 2. This program > > + * is licensed "as is" without any warranty of any kind, whether express > > + * or implied. > > + * > > + */ > > + > > +/ { > > + #address-cells = <1>; > > + #size-cells = <1>; > > + model = "Katana-Qp"; /* Default */ > > + compatible = "emerson,Katana-Qp"; > > + coherency-off; > > What is this property for? Its needed to tell the bootwrapper that the platform does not have coherency enabled (since our policy is that you can't use a CONFIG_ option). The bootwrapper needs to know that if/when it sets up the windows for its I/O devices (e.g., enet, mpsc) to system memory. I needed to do this on the prpmc2800 because the firmware didn't set up those windows correctly. I don't know if the Katana Qp's firmware sets the up correctly or not. > > + mv64x60@f8100000 { /* Marvell Discovery */ > > + #address-cells = <1>; > > + #size-cells = <1>; > > + model = "mv64460"; /* Default */ > > + compatible = "marvell,mv64x60"; > > Compatible properties should not have "x" asn in 64x60 here. If > there's a suitable name for the general register interface use that, > otherwise use the specific model number of the earliest device to > implement this register interface. Later models should have a > compatible property which lists their specific model, followed by the > earlier model number with which they're compatible. This came from the prpmc2800's dts which has become out-of-date. Both dts files need to be updated. > > + ethernet@2000 { > > + reg = <2000 2000>; > > Are the registers for the 3 ethernets really all together? This bank > can't be subdivided into seperate register blocks for each MAC? Unfortunately there are some registers that are shared so you can't divide them up nicely. > > + eth0 { > > + device_type = "network"; > > + compatible = "marvell,mv64x60-eth"; > > + block-index = <0>; > > This block-index thing is crap. If you really need to subindex nodes > like this, use "reg", with an appropriate #address-cells in the > parent, then the nodes will also get sensible unit addresses. So how would that work for the "PHY Address Register 0x2000", say, where bits 0-4 set the device addr for PHY 0; bits 5-9 set the device addr for PHY 1; bts 10-14 set the devce addr for PHY 2? > > + interrupts = <20>; > > + interrupt-parent = <&/mv64x60/pic>; > > You should use a label for the PIC to make things more readable. More that needs to be updated in prpmc2800. :( > > + sdma@4000 { > > + compatible = "marvell,mv64x60-sdma"; > > + reg = <4000 c18>; > > + virtual-reg = <f8104000>; > > Why does this node have virtual-reg? "virtual-reg" is a special property that doesn't get translated thru the parent mappings. It should never be used in the kernel. Its purpose is to give code in the bootwrapper the exact address that it should use to access a register or block of registers or ... Its needed here because the MPSC (serial) driver uses the SDMA unit to perform console I/O in the bootwrapper (e.g., cmdline editing, printf's). Yes, this needs to be documented. > > + mpsc@8000 { > > + device_type = "serial"; > > + compatible = "marvell,mpsc"; > > + reg = <8000 38>; > > + virtual-reg = <f8108000>; > > + sdma = <&/mv64x60/sdma@4000>; > > + brg = <&/mv64x60/brg@b200>; > > + cunit = <&/mv64x60/cunit@f200>; > > + mpscrouting = <&/mv64x60/mpscrouting@b400>; > > + mpscintr = <&/mv64x60/mpscintr@b800>; > > + block-index = <0>; > > What is this block-index thing about here? Since the devices are > disambiguated by their register address, why do you need it? This particular one is needed to access the correct MPSC interrupt reg. Maybe it would be better to make a new property for this but it was only one reg and block-index was already there and basically served that purpose so I used it. I'd be happy to use an alternative if you have something you think is better. > > + pic { > > Needs a unit address. Okay. > > + cpu-error@0070 { > > The unit address should notr include leading zeroes. Okay. Mark ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-12-04 2:10 ` Mark A. Greer @ 2007-12-04 2:50 ` David Gibson 2007-12-04 5:30 ` Mark A. Greer 2007-12-06 23:27 ` Mark A. Greer 0 siblings, 2 replies; 27+ messages in thread From: David Gibson @ 2007-12-04 2:50 UTC (permalink / raw) To: Mark A. Greer; +Cc: linuxppc-dev On Mon, Dec 03, 2007 at 07:10:26PM -0700, Mark A. Greer wrote: > On Mon, Dec 03, 2007 at 12:50:18PM +1100, David Gibson wrote: > > On Thu, Nov 29, 2007 at 06:28:36PM +0300, Andrei Dolnikov wrote: [snip] > > > + ethernet@2000 { > > > + reg = <2000 2000>; > > > > Are the registers for the 3 ethernets really all together? This bank > > can't be subdivided into seperate register blocks for each MAC? > > Unfortunately there are some registers that are shared so you can't > divide them up nicely. Ok, fair enough then. But, see below.. > > > + eth0 { > > > + device_type = "network"; > > > + compatible = "marvell,mv64x60-eth"; > > > + block-index = <0>; > > > > This block-index thing is crap. If you really need to subindex nodes > > like this, use "reg", with an appropriate #address-cells in the > > parent, then the nodes will also get sensible unit addresses. > > So how would that work for the "PHY Address Register 0x2000", say, > where bits 0-4 set the device addr for PHY 0; bits 5-9 set the device > addr for PHY 1; bts 10-14 set the devce addr for PHY 2? So use 'reg' to do the indexing. As long as you have no 'ranges' property in the parent 'ethernet' node, which you don't, you can use 'reg' as a private index. That's basically what non-translatable reg values are about. Incidentally you should probably call the subnodes "ethernet@0" etc. and the parent one "multiethernet" or something. It's the subnodes that represent an individual ethernet interface, so they should take the "ethernet" name and not the parent, by generic names conventions. [snip] > > > + sdma@4000 { > > > + compatible = "marvell,mv64x60-sdma"; > > > + reg = <4000 c18>; > > > + virtual-reg = <f8104000>; > > > > Why does this node have virtual-reg? > > "virtual-reg" is a special property that doesn't get translated thru > the parent mappings. It should never be used in the kernel. Its > purpose is to give code in the bootwrapper the exact address that it > should use to access a register or block of registers or ... > Its needed here because the MPSC (serial) driver uses the SDMA unit > to perform console I/O in the bootwrapper (e.g., cmdline editing, printf's). > > Yes, this needs to be documented. Ok. "it's used for serial in the bootwrapper" would have sufficed - I questioned it because it wasn't obvious that this was needed to use the mpsc. > > > > + mpsc@8000 { > > > + device_type = "serial"; > > > + compatible = "marvell,mpsc"; > > > + reg = <8000 38>; > > > + virtual-reg = <f8108000>; > > > + sdma = <&/mv64x60/sdma@4000>; > > > + brg = <&/mv64x60/brg@b200>; > > > + cunit = <&/mv64x60/cunit@f200>; > > > + mpscrouting = <&/mv64x60/mpscrouting@b400>; > > > + mpscintr = <&/mv64x60/mpscintr@b800>; > > > + block-index = <0>; > > > > What is this block-index thing about here? Since the devices are > > disambiguated by their register address, why do you need it? > > This particular one is needed to access the correct MPSC interrupt reg. > Maybe it would be better to make a new property for this but it was only > one reg and block-index was already there and basically served that > purpose so I used it. I'd be happy to use an alternative if you have > something you think is better. No, that's an acceptable use for something like this, except that "cell-index" seems to be the name we've standardised on for other similar cases. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-12-04 2:50 ` David Gibson @ 2007-12-04 5:30 ` Mark A. Greer 2007-12-06 23:27 ` Mark A. Greer 1 sibling, 0 replies; 27+ messages in thread From: Mark A. Greer @ 2007-12-04 5:30 UTC (permalink / raw) To: Mark A. Greer, Andrei Dolnikov, linuxppc-dev On Tue, Dec 04, 2007 at 01:50:32PM +1100, David Gibson wrote: > On Mon, Dec 03, 2007 at 07:10:26PM -0700, Mark A. Greer wrote: > > On Mon, Dec 03, 2007 at 12:50:18PM +1100, David Gibson wrote: > > > On Thu, Nov 29, 2007 at 06:28:36PM +0300, Andrei Dolnikov wrote: > > > > + eth0 { > > > > + device_type = "network"; > > > > + compatible = "marvell,mv64x60-eth"; > > > > + block-index = <0>; > > > > > > This block-index thing is crap. If you really need to subindex nodes > > > like this, use "reg", with an appropriate #address-cells in the > > > parent, then the nodes will also get sensible unit addresses. > > > > So how would that work for the "PHY Address Register 0x2000", say, > > where bits 0-4 set the device addr for PHY 0; bits 5-9 set the device > > addr for PHY 1; bts 10-14 set the devce addr for PHY 2? > > So use 'reg' to do the indexing. As long as you have no 'ranges' > property in the parent 'ethernet' node, which you don't, you can use > 'reg' as a private index. That's basically what non-translatable reg > values are about. > > Incidentally you should probably call the subnodes "ethernet@0" > etc. and the parent one "multiethernet" or something. It's the > subnodes that represent an individual ethernet interface, so they > should take the "ethernet" name and not the parent, by generic names > conventions. Okay, thanks for the advice. I'll fix the prpmc2800 dts file. Presumably Andrei will fix his. > [snip] > > > > + sdma@4000 { > > > > + compatible = "marvell,mv64x60-sdma"; > > > > + reg = <4000 c18>; > > > > + virtual-reg = <f8104000>; > > > > > > Why does this node have virtual-reg? > > > > "virtual-reg" is a special property that doesn't get translated thru > > the parent mappings. It should never be used in the kernel. Its > > purpose is to give code in the bootwrapper the exact address that it > > should use to access a register or block of registers or ... > > Its needed here because the MPSC (serial) driver uses the SDMA unit > > to perform console I/O in the bootwrapper (e.g., cmdline editing, printf's). > > > > Yes, this needs to be documented. > > Ok. "it's used for serial in the bootwrapper" would have sufficed - I > questioned it because it wasn't obvious that this was needed to use > the mpsc. Sorry :) > > > > > > + mpsc@8000 { > > > > + device_type = "serial"; > > > > + compatible = "marvell,mpsc"; > > > > + reg = <8000 38>; > > > > + virtual-reg = <f8108000>; > > > > + sdma = <&/mv64x60/sdma@4000>; > > > > + brg = <&/mv64x60/brg@b200>; > > > > + cunit = <&/mv64x60/cunit@f200>; > > > > + mpscrouting = <&/mv64x60/mpscrouting@b400>; > > > > + mpscintr = <&/mv64x60/mpscintr@b800>; > > > > + block-index = <0>; > > > > > > What is this block-index thing about here? Since the devices are > > > disambiguated by their register address, why do you need it? > > > > This particular one is needed to access the correct MPSC interrupt reg. > > Maybe it would be better to make a new property for this but it was only > > one reg and block-index was already there and basically served that > > purpose so I used it. I'd be happy to use an alternative if you have > > something you think is better. > > No, that's an acceptable use for something like this, except that > "cell-index" seems to be the name we've standardised on for other > similar cases. Yeah, I realize that but block-index was here first! More seriously, I don't like "cell" because it isn't a cell, its a block or an instance or an...I dunno but its not a cell IMHO. Anyway, I'll think about changing it to cell but I already feel dirty just thinking about it. Mark ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-12-04 2:50 ` David Gibson 2007-12-04 5:30 ` Mark A. Greer @ 2007-12-06 23:27 ` Mark A. Greer 2007-12-08 1:33 ` David Gibson 1 sibling, 1 reply; 27+ messages in thread From: Mark A. Greer @ 2007-12-06 23:27 UTC (permalink / raw) To: David Gibson; +Cc: linuxppc-dev David, et. al., This is a big blob patch of what I've changed for the prpmc2800. It includes the necessary changes in the kernel which you can probably ignore but they're there for reference. If you like the dts, then I'll split the blob up into logical pieces and Andrei can make similar changes for the Katana Qp. Let me know what you think. Mark --- This patch is based on the latest powerpc.git tree (44032af0e7d5467b12f998dbf2f1cd23c5324fd5) with the following patches applied: http://patchwork.ozlabs.org/linuxppc/patch?id=14339 http://patchwork.ozlabs.org/linuxppc/patch?id=14397 http://patchwork.ozlabs.org/linuxppc/patch?id=14396 http://patchwork.ozlabs.org/linuxppc/patch?id=14631 http://patchwork.ozlabs.org/linuxppc/patch?id=14632 http://patchwork.ozlabs.org/linuxppc/patch?id=14633 http://patchwork.ozlabs.org/linuxppc/patch?id=15007 arch/powerpc/boot/dts/prpmc2800.dts | 320 +++++++-------- arch/powerpc/boot/mpsc.c | 2 arch/powerpc/boot/serial.c | 2 arch/powerpc/platforms/embedded6xx/prpmc2800.c | 4 arch/powerpc/sysdev/mv64x60_dev.c | 29 - arch/powerpc/sysdev/mv64x60_pci.c | 6 arch/powerpc/sysdev/mv64x60_pic.c | 4 arch/powerpc/sysdev/mv64x60_udbg.c | 4 8 files changed, 181 insertions(+), 190 deletions(-) diff --git a/arch/powerpc/boot/dts/prpmc2800.dts b/arch/powerpc/boot/dts/prpmc2800.dts index 24944ca..080130e 100644 --- a/arch/powerpc/boot/dts/prpmc2800.dts +++ b/arch/powerpc/boot/dts/prpmc2800.dts @@ -11,6 +11,8 @@ * if it can determine the exact PrPMC type. */ +/dts-v1/; + / { #address-cells = <1>; #size-cells = <1>; @@ -25,64 +27,64 @@ PowerPC,7447 { device_type = "cpu"; reg = <0>; - clock-frequency = <2bb0b140>; /* Default (733 MHz) */ - bus-frequency = <7f28155>; /* 133.333333 MHz */ - timebase-frequency = <1fca055>; /* 33.333333 MHz */ - i-cache-line-size = <20>; - d-cache-line-size = <20>; - i-cache-size = <8000>; - d-cache-size = <8000>; + clock-frequency = <733333333>; /* Default */ + bus-frequency = <133333333>; + timebase-frequency = <33333333>; + i-cache-line-size = <0x20>; + d-cache-line-size = <0x20>; + i-cache-size = <0x8000>; + d-cache-size = <0x8000>; }; }; memory { device_type = "memory"; - reg = <00000000 20000000>; /* Default (512MB) */ + reg = <0x00000000 0x20000000>; /* Default (512MB) */ }; mv64x60@f1000000 { /* Marvell Discovery */ #address-cells = <1>; #size-cells = <1>; model = "mv64360"; /* Default */ - compatible = "marvell,mv64x60"; - clock-frequency = <7f28155>; /* 133.333333 MHz */ - reg = <f1000000 00010000>; - virtual-reg = <f1000000>; - ranges = <88000000 88000000 01000000 /* PCI 0 I/O Space */ - 80000000 80000000 08000000 /* PCI 0 MEM Space */ - a0000000 a0000000 04000000 /* User FLASH */ - 00000000 f1000000 00010000 /* Bridge's regs */ - f2000000 f2000000 00040000>; /* Integrated SRAM */ + compatible = "marvell,mv64360"; + clock-frequency = <133333333>; + reg = <0xf1000000 0x00010000>; + virtual-reg = <0xf1000000>; + ranges = <0x88000000 0x88000000 0x01000000 /* PCI 0 I/O Space */ + 0x80000000 0x80000000 0x08000000 /* PCI 0 MEM Space */ + 0xa0000000 0xa0000000 0x04000000 /* User FLASH */ + 0x00000000 0xf1000000 0x00010000 /* Bridge's regs */ + 0xf2000000 0xf2000000 0x00040000>;/* Integrated SRAM*/ flash@a0000000 { compatible = "cfi-flash"; - reg = <a0000000 04000000>; + reg = <0xa0000000 0x04000000>; bank-width = <4>; device-width = <2>; #address-cells = <1>; #size-cells = <1>; fw@0 { label = "FW Image A"; - reg = <00000000 00100000>; + reg = <0x00000000 0x00100000>; read-only; }; cfg@100000 { label = "FW Config Data"; /* RW */ - reg = <00100000 00040000>; + reg = <0x00100000 0x00040000>; }; kernel@140000 { label = "Kernel Image"; - reg = <00140000 00400000>; + reg = <0x00140000 0x00400000>; read-only; }; fs@540000 { label = "Filesystem"; - reg = <00540000 039c0000>; + reg = <0x00540000 0x039c0000>; read-only; }; fw@3f00000 { label = "FW Image B"; - reg = <03f00000 00100000>; + reg = <0x03f00000 0x00100000>; read-only; }; }; @@ -91,171 +93,167 @@ #address-cells = <1>; #size-cells = <0>; device_type = "mdio"; - compatible = "marvell,mv64x60-mdio"; - ethernet-phy@1 { + compatible = "marvell,mv64360-mdio"; + phy0: ethernet-phy@1 { device_type = "ethernet-phy"; compatible = "broadcom,bcm5421"; - interrupts = <4c>; /* GPP 12 */ - interrupt-parent = <&/mv64x60/pic>; + interrupts = <76>; /* GPP 12 */ + interrupt-parent = <&pic>; reg = <1>; }; - ethernet-phy@3 { + phy1: ethernet-phy@3 { device_type = "ethernet-phy"; compatible = "broadcom,bcm5421"; - interrupts = <4c>; /* GPP 12 */ - interrupt-parent = <&/mv64x60/pic>; + interrupts = <76>; /* GPP 12 */ + interrupt-parent = <&pic>; reg = <3>; }; }; - ethernet@2000 { - reg = <2000 2000>; - eth0 { + multiethernet@2000 { + reg = <0x2000 0x2000>; + ethernet@0 { device_type = "network"; - compatible = "marvell,mv64x60-eth"; - block-index = <0>; - interrupts = <20>; - interrupt-parent = <&/mv64x60/pic>; - phy = <&/mv64x60/mdio/ethernet-phy@1>; + compatible = "marvell,mv64360-eth"; + reg = <0>; + interrupts = <32>; + interrupt-parent = <&pic>; + phy = <&phy0>; local-mac-address = [ 00 00 00 00 00 00 ]; }; - eth1 { + ethernet@1 { device_type = "network"; - compatible = "marvell,mv64x60-eth"; - block-index = <1>; - interrupts = <21>; - interrupt-parent = <&/mv64x60/pic>; - phy = <&/mv64x60/mdio/ethernet-phy@3>; + compatible = "marvell,mv64360-eth"; + reg = <1>; + interrupts = <33>; + interrupt-parent = <&pic>; + phy = <&phy1>; local-mac-address = [ 00 00 00 00 00 00 ]; }; }; - sdma@4000 { - device_type = "dma"; - compatible = "marvell,mv64x60-sdma"; - reg = <4000 c18>; - virtual-reg = <f1004000>; + sdma0: sdma@4000 { + compatible = "marvell,mv64360-sdma"; + reg = <0x4000 0xc18>; + virtual-reg = <0xf1004000>; interrupt-base = <0>; - interrupts = <24>; - interrupt-parent = <&/mv64x60/pic>; + interrupts = <36>; + interrupt-parent = <&pic>; }; - sdma@6000 { - device_type = "dma"; - compatible = "marvell,mv64x60-sdma"; - reg = <6000 c18>; - virtual-reg = <f1006000>; + sdma1: sdma@6000 { + compatible = "marvell,mv64360-sdma"; + reg = <0x6000 0xc18>; + virtual-reg = <0xf1006000>; interrupt-base = <0>; - interrupts = <26>; - interrupt-parent = <&/mv64x60/pic>; + interrupts = <38>; + interrupt-parent = <&pic>; }; - brg@b200 { - compatible = "marvell,mv64x60-brg"; - reg = <b200 8>; + brg0: brg@b200 { + compatible = "marvell,mv64360-brg"; + reg = <0xb200 0x8>; clock-src = <8>; - clock-frequency = <7ed6b40>; - current-speed = <2580>; + clock-frequency = <133000000>; + current-speed = <9600>; bcr = <0>; }; - brg@b208 { - compatible = "marvell,mv64x60-brg"; - reg = <b208 8>; + brg1: brg@b208 { + compatible = "marvell,mv64360-brg"; + reg = <0xb208 0x8>; clock-src = <8>; - clock-frequency = <7ed6b40>; - current-speed = <2580>; + clock-frequency = <133000000>; + current-speed = <9600>; bcr = <0>; }; - cunit@f200 { - reg = <f200 200>; + cunit: cunit@f200 { + reg = <0xf200 0x200>; }; - mpscrouting@b400 { - reg = <b400 c>; + mpscrouting: mpscrouting@b400 { + reg = <0xb400 0xc>; }; - mpscintr@b800 { - reg = <b800 100>; - virtual-reg = <f100b800>; + mpscintr: mpscintr@b800 { + reg = <0xb800 0x100>; + virtual-reg = <0xf100b800>; }; - mpsc@8000 { + mpsc0: mpsc@8000 { device_type = "serial"; - compatible = "marvell,mpsc"; - reg = <8000 38>; - virtual-reg = <f1008000>; - sdma = <&/mv64x60/sdma@4000>; - brg = <&/mv64x60/brg@b200>; - cunit = <&/mv64x60/cunit@f200>; - mpscrouting = <&/mv64x60/mpscrouting@b400>; - mpscintr = <&/mv64x60/mpscintr@b800>; - block-index = <0>; - max_idle = <28>; + compatible = "marvell,mv64360-mpsc"; + reg = <0x8000 0x38>; + virtual-reg = <0xf1008000>; + sdma = <&sdma0>; + brg = <&brg0>; + cunit = <&cunit>; + mpscrouting = <&mpscrouting>; + mpscintr = <&mpscintr>; + cell-index = <0>; + max_idle = <40>; chr_1 = <0>; chr_2 = <0>; chr_10 = <3>; mpcr = <0>; - interrupts = <28>; - interrupt-parent = <&/mv64x60/pic>; + interrupts = <40>; + interrupt-parent = <&pic>; }; - mpsc@9000 { + mpsc1: mpsc@9000 { device_type = "serial"; - compatible = "marvell,mpsc"; - reg = <9000 38>; - virtual-reg = <f1009000>; - sdma = <&/mv64x60/sdma@6000>; - brg = <&/mv64x60/brg@b208>; - cunit = <&/mv64x60/cunit@f200>; - mpscrouting = <&/mv64x60/mpscrouting@b400>; - mpscintr = <&/mv64x60/mpscintr@b800>; - block-index = <1>; - max_idle = <28>; + compatible = "marvell,mv64360-mpsc"; + reg = <0x9000 0x38>; + virtual-reg = <0xf1009000>; + sdma = <&sdma1>; + brg = <&brg1>; + cunit = <&cunit>; + mpscrouting = <&mpscrouting>; + mpscintr = <&mpscintr>; + cell-index = <1>; + max_idle = <40>; chr_1 = <0>; chr_2 = <0>; chr_10 = <3>; mpcr = <0>; - interrupts = <2a>; - interrupt-parent = <&/mv64x60/pic>; + interrupts = <42>; + interrupt-parent = <&pic>; }; wdt@b410 { /* watchdog timer */ - compatible = "marvell,mv64x60-wdt"; - reg = <b410 8>; - timeout = <a>; /* wdt timeout in seconds */ + compatible = "marvell,mv64360-wdt"; + reg = <0xb410 0x8>; }; i2c@c000 { device_type = "i2c"; - compatible = "marvell,mv64x60-i2c"; - reg = <c000 20>; - virtual-reg = <f100c000>; + compatible = "marvell,mv64360-i2c"; + reg = <0xc000 0x20>; + virtual-reg = <0xf100c000>; freq_m = <8>; freq_n = <3>; - timeout = <3e8>; /* 1000 = 1 second */ retries = <1>; - interrupts = <25>; - interrupt-parent = <&/mv64x60/pic>; + interrupts = <37>; + interrupt-parent = <&pic>; }; - pic { + pic: pic@0 { #interrupt-cells = <1>; #address-cells = <0>; - compatible = "marvell,mv64x60-pic"; - reg = <0000 88>; + compatible = "marvell,mv64360-pic"; + reg = <0x0000 0x88>; interrupt-controller; }; mpp@f000 { - compatible = "marvell,mv64x60-mpp"; - reg = <f000 10>; + compatible = "marvell,mv64360-mpp"; + reg = <0xf000 0x10>; }; gpp@f100 { - compatible = "marvell,mv64x60-gpp"; - reg = <f100 20>; + compatible = "marvell,mv64360-gpp"; + reg = <0xf100 0x20>; }; pci@80000000 { @@ -263,68 +261,70 @@ #size-cells = <2>; #interrupt-cells = <1>; device_type = "pci"; - compatible = "marvell,mv64x60-pci"; - reg = <0cf8 8>; - ranges = <01000000 0 0 88000000 0 01000000 - 02000000 0 80000000 80000000 0 08000000>; - bus-range = <0 ff>; - clock-frequency = <3EF1480>; - interrupt-pci-iack = <0c34>; - interrupt-parent = <&/mv64x60/pic>; - interrupt-map-mask = <f800 0 0 7>; + compatible = "marvell,mv64360-pci"; + reg = <0x0cf8 0x8>; + ranges = <0x01000000 0x0 0x0 + 0x88000000 0x0 0x01000000 + 0x02000000 0x0 0x80000000 + 0x80000000 0x0 0x08000000>; + bus-range = <0x0 0xff>; + clock-frequency = <66000000>; + interrupt-pci-iack = <0x0c34>; + interrupt-parent = <&pic>; + interrupt-map-mask = <0xf800 0 0 7>; interrupt-map = < /* IDSEL 0x0a */ - 5000 0 0 1 &/mv64x60/pic 50 - 5000 0 0 2 &/mv64x60/pic 51 - 5000 0 0 3 &/mv64x60/pic 5b - 5000 0 0 4 &/mv64x60/pic 5d + 0x5000 0 0 1 &pic 80 + 0x5000 0 0 2 &pic 81 + 0x5000 0 0 3 &pic 91 + 0x5000 0 0 4 &pic 93 /* IDSEL 0x0b */ - 5800 0 0 1 &/mv64x60/pic 5b - 5800 0 0 2 &/mv64x60/pic 5d - 5800 0 0 3 &/mv64x60/pic 50 - 5800 0 0 4 &/mv64x60/pic 51 + 0x5800 0 0 1 &pic 91 + 0x5800 0 0 2 &pic 93 + 0x5800 0 0 3 &pic 80 + 0x5800 0 0 4 &pic 81 /* IDSEL 0x0c */ - 6000 0 0 1 &/mv64x60/pic 5b - 6000 0 0 2 &/mv64x60/pic 5d - 6000 0 0 3 &/mv64x60/pic 50 - 6000 0 0 4 &/mv64x60/pic 51 + 0x6000 0 0 1 &pic 91 + 0x6000 0 0 2 &pic 93 + 0x6000 0 0 3 &pic 80 + 0x6000 0 0 4 &pic 81 /* IDSEL 0x0d */ - 6800 0 0 1 &/mv64x60/pic 5d - 6800 0 0 2 &/mv64x60/pic 50 - 6800 0 0 3 &/mv64x60/pic 51 - 6800 0 0 4 &/mv64x60/pic 5b + 0x6800 0 0 1 &pic 93 + 0x6800 0 0 2 &pic 80 + 0x6800 0 0 3 &pic 81 + 0x6800 0 0 4 &pic 91 >; }; - cpu-error@0070 { - compatible = "marvell,mv64x60-cpu-error"; - reg = <0070 10 0128 28>; - interrupts = <03>; - interrupt-parent = <&/mv64x60/pic>; + cpu-error@70 { + compatible = "marvell,mv64360-cpu-error"; + reg = <0x0070 0x10 0x0128 0x28>; + interrupts = <3>; + interrupt-parent = <&pic>; }; - sram-ctrl@0380 { - compatible = "marvell,mv64x60-sram-ctrl"; - reg = <0380 80>; - interrupts = <0d>; - interrupt-parent = <&/mv64x60/pic>; + sram-ctrl@380 { + compatible = "marvell,mv64360-sram-ctrl"; + reg = <0x0380 0x80>; + interrupts = <13>; + interrupt-parent = <&pic>; }; pci-error@1d40 { - compatible = "marvell,mv64x60-pci-error"; - reg = <1d40 40 0c28 4>; - interrupts = <0c>; - interrupt-parent = <&/mv64x60/pic>; + compatible = "marvell,mv64360-pci-error"; + reg = <0x1d40 0x40 0x0c28 0x4>; + interrupts = <12>; + interrupt-parent = <&pic>; }; mem-ctrl@1400 { - compatible = "marvell,mv64x60-mem-ctrl"; - reg = <1400 60>; - interrupts = <11>; - interrupt-parent = <&/mv64x60/pic>; + compatible = "marvell,mv64360-mem-ctrl"; + reg = <0x1400 0x60>; + interrupts = <17>; + interrupt-parent = <&pic>; }; }; diff --git a/arch/powerpc/boot/mpsc.c b/arch/powerpc/boot/mpsc.c index 802ea53..425ad88 100644 --- a/arch/powerpc/boot/mpsc.c +++ b/arch/powerpc/boot/mpsc.c @@ -141,7 +141,7 @@ int mpsc_console_init(void *devp, struct serial_console_data *scdp) if (mpscintr_base == NULL) goto err_out; - n = getprop(devp, "block-index", &v, sizeof(v)); + n = getprop(devp, "cell-index", &v, sizeof(v)); if (n != sizeof(v)) goto err_out; reg_set = (int)v; diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c index cafeece..cbcbb20 100644 --- a/arch/powerpc/boot/serial.c +++ b/arch/powerpc/boot/serial.c @@ -119,7 +119,7 @@ int serial_console_init(void) if (dt_is_compatible(devp, "ns16550")) rc = ns16550_console_init(devp, &serial_cd); - else if (dt_is_compatible(devp, "marvell,mpsc")) + else if (dt_is_compatible(devp, "marvell,mv64360-mpsc")) rc = mpsc_console_init(devp, &serial_cd); else if (dt_is_compatible(devp, "fsl,cpm1-scc-uart") || dt_is_compatible(devp, "fsl,cpm1-smc-uart") || diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c b/arch/powerpc/platforms/embedded6xx/prpmc2800.c index a01e219..1a1baf9 100644 --- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c +++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c @@ -50,13 +50,13 @@ static void __init prpmc2800_setup_arch(void) * ioremap mpp and gpp registers in case they are later * needed by prpmc2800_reset_board(). */ - np = of_find_compatible_node(NULL, NULL, "marvell,mv64x60-mpp"); + np = of_find_compatible_node(NULL, NULL, "marvell,mv64360-mpp"); reg = of_get_property(np, "reg", NULL); paddr = of_translate_address(np, reg); of_node_put(np); mv64x60_mpp_reg_base = ioremap(paddr, reg[1]); - np = of_find_compatible_node(NULL, NULL, "marvell,mv64x60-gpp"); + np = of_find_compatible_node(NULL, NULL, "marvell,mv64360-gpp"); reg = of_get_property(np, "reg", NULL); paddr = of_translate_address(np, reg); of_node_put(np); diff --git a/arch/powerpc/sysdev/mv64x60_dev.c b/arch/powerpc/sysdev/mv64x60_dev.c index 304056c..aac28ee 100644 --- a/arch/powerpc/sysdev/mv64x60_dev.c +++ b/arch/powerpc/sysdev/mv64x60_dev.c @@ -127,7 +127,7 @@ static int __init mv64x60_mpsc_device_setup(struct device_node *np, int id) if (err) return err; - prop = of_get_property(np, "block-index", NULL); + prop = of_get_property(np, "cell-index", NULL); if (!prop) return -ENODEV; port_number = *(int *)prop; @@ -248,7 +248,7 @@ static int __init mv64x60_eth_device_setup(struct device_node *np, int id) memset(&pdata, 0, sizeof(pdata)); - prop = of_get_property(np, "block-index", NULL); + prop = of_get_property(np, "reg", NULL); if (!prop) return -ENODEV; pdata.port_number = *prop; @@ -344,6 +344,7 @@ static int __init mv64x60_i2c_device_setup(struct device_node *np, int id) of_irq_to_resource(np, 0, &r[1]); memset(&pdata, 0, sizeof(pdata)); + pdata.timeout = 1000; /* Default: 1 second */ prop = of_get_property(np, "freq_m", NULL); if (!prop) @@ -355,12 +356,6 @@ static int __init mv64x60_i2c_device_setup(struct device_node *np, int id) return -ENODEV; pdata.freq_n = *prop; - prop = of_get_property(np, "timeout", NULL); - if (prop) - pdata.timeout = *prop; - else - pdata.timeout = 1000; /* 1 second */ - prop = of_get_property(np, "retries", NULL); if (prop) pdata.retries = *prop; @@ -406,11 +401,7 @@ static int __init mv64x60_wdt_device_setup(struct device_node *np, int id) return err; memset(&pdata, 0, sizeof(pdata)); - - prop = of_get_property(np, "timeout", NULL); - if (!prop) - return -ENODEV; - pdata.timeout = *prop; + pdata.timeout = 10; /* Default: 10 seconds */ np = of_get_parent(np); if (!np) @@ -452,22 +443,22 @@ static int __init mv64x60_device_setup(void) int err; id = 0; - for_each_compatible_node(np, "serial", "marvell,mpsc") + for_each_compatible_node(np, "serial", "marvell,mv64360-mpsc") if ((err = mv64x60_mpsc_device_setup(np, id++))) goto error; id = 0; - for_each_compatible_node(np, "network", "marvell,mv64x60-eth") + for_each_compatible_node(np, "network", "marvell,mv64360-eth") if ((err = mv64x60_eth_device_setup(np, id++))) goto error; id = 0; - for_each_compatible_node(np, "i2c", "marvell,mv64x60-i2c") + for_each_compatible_node(np, "i2c", "marvell,mv64360-i2c") if ((err = mv64x60_i2c_device_setup(np, id++))) goto error; /* support up to one watchdog timer */ - np = of_find_compatible_node(np, NULL, "marvell,mv64x60-wdt"); + np = of_find_compatible_node(np, NULL, "marvell,mv64360-wdt"); if (np) { if ((err = mv64x60_wdt_device_setup(np, id))) goto error; @@ -495,10 +486,10 @@ static int __init mv64x60_add_mpsc_console(void) if (!np) goto not_mpsc; - if (!of_device_is_compatible(np, "marvell,mpsc")) + if (!of_device_is_compatible(np, "marvell,mv64360-mpsc")) goto not_mpsc; - prop = of_get_property(np, "block-index", NULL); + prop = of_get_property(np, "cell-index", NULL); if (!prop) goto not_mpsc; diff --git a/arch/powerpc/sysdev/mv64x60_pci.c b/arch/powerpc/sysdev/mv64x60_pci.c index d21ab8f..1456015 100644 --- a/arch/powerpc/sysdev/mv64x60_pci.c +++ b/arch/powerpc/sysdev/mv64x60_pci.c @@ -86,14 +86,14 @@ static int __init mv64x60_sysfs_init(void) struct platform_device *pdev; const unsigned int *prop; - np = of_find_compatible_node(NULL, NULL, "marvell,mv64x60"); + np = of_find_compatible_node(NULL, NULL, "marvell,mv64360"); if (!np) return 0; prop = of_get_property(np, "hs_reg_valid", NULL); of_node_put(np); - pdev = platform_device_register_simple("marvell,mv64x60", 0, NULL, 0); + pdev = platform_device_register_simple("marvell,mv64360", 0, NULL, 0); if (IS_ERR(pdev)) return PTR_ERR(pdev); @@ -166,6 +166,6 @@ void __init mv64x60_pci_init(void) { struct device_node *np; - for_each_compatible_node(np, "pci", "marvell,mv64x60-pci") + for_each_compatible_node(np, "pci", "marvell,mv64360-pci") mv64x60_add_bridge(np); } diff --git a/arch/powerpc/sysdev/mv64x60_pic.c b/arch/powerpc/sysdev/mv64x60_pic.c index 19e6ef2..2aa4ed0 100644 --- a/arch/powerpc/sysdev/mv64x60_pic.c +++ b/arch/powerpc/sysdev/mv64x60_pic.c @@ -238,13 +238,13 @@ void __init mv64x60_init_irq(void) const unsigned int *reg; unsigned long flags; - np = of_find_compatible_node(NULL, NULL, "marvell,mv64x60-gpp"); + np = of_find_compatible_node(NULL, NULL, "marvell,mv64360-gpp"); reg = of_get_property(np, "reg", &size); paddr = of_translate_address(np, reg); mv64x60_gpp_reg_base = ioremap(paddr, reg[1]); of_node_put(np); - np = of_find_compatible_node(NULL, NULL, "marvell,mv64x60-pic"); + np = of_find_compatible_node(NULL, NULL, "marvell,mv64360-pic"); reg = of_get_property(np, "reg", &size); paddr = of_translate_address(np, reg); mv64x60_irq_reg_base = ioremap(paddr, reg[1]); diff --git a/arch/powerpc/sysdev/mv64x60_udbg.c b/arch/powerpc/sysdev/mv64x60_udbg.c index 35c77c7..2792dc8 100644 --- a/arch/powerpc/sysdev/mv64x60_udbg.c +++ b/arch/powerpc/sysdev/mv64x60_udbg.c @@ -85,7 +85,7 @@ static void mv64x60_udbg_init(void) if (!stdout) return; - for_each_compatible_node(np, "serial", "marvell,mpsc") { + for_each_compatible_node(np, "serial", "marvell,mv64360-mpsc") { if (np == stdout) break; } @@ -94,7 +94,7 @@ static void mv64x60_udbg_init(void) if (!np) return; - block_index = of_get_property(np, "block-index", NULL); + block_index = of_get_property(np, "cell-index", NULL); if (!block_index) goto error; ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-12-06 23:27 ` Mark A. Greer @ 2007-12-08 1:33 ` David Gibson 2007-12-10 17:17 ` Mark A. Greer 0 siblings, 1 reply; 27+ messages in thread From: David Gibson @ 2007-12-08 1:33 UTC (permalink / raw) To: Mark A. Greer; +Cc: linuxppc-dev, David Gibson On Thu, Dec 06, 2007 at 04:27:56PM -0700, Mark A. Greer wrote: > David, et. al., > > This is a big blob patch of what I've changed for the prpmc2800. It > includes the necessary changes in the kernel which you can probably > ignore but they're there for reference. If you like the dts, then I'll > split the blob up into logical pieces and Andrei can make similar > changes for the Katana Qp. > > Let me know what you think. Looks pretty reasonable. I would have preferred that labels be uppercase by convention, to make them easier to pick out by eyeball, but I think that's a lost cause at this stage. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-12-08 1:33 ` David Gibson @ 2007-12-10 17:17 ` Mark A. Greer 0 siblings, 0 replies; 27+ messages in thread From: Mark A. Greer @ 2007-12-10 17:17 UTC (permalink / raw) To: Mark A. Greer, David Gibson, Andrei Dolnikov, linuxppc-dev On Sat, Dec 08, 2007 at 12:33:09PM +1100, David Gibson wrote: > On Thu, Dec 06, 2007 at 04:27:56PM -0700, Mark A. Greer wrote: > > David, et. al., > > > > This is a big blob patch of what I've changed for the prpmc2800. It > > includes the necessary changes in the kernel which you can probably > > ignore but they're there for reference. If you like the dts, then I'll > > split the blob up into logical pieces and Andrei can make similar > > changes for the Katana Qp. > > > > Let me know what you think. > > Looks pretty reasonable. I would have preferred that labels be > uppercase by convention, to make them easier to pick out by eyeball, > but I think that's a lost cause at this stage. I can do that. Thanks for the feedback. I'll break the blob up into pieces and submit with the labels in uppercase. Thanks, Mark ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-12-03 1:50 ` David Gibson 2007-12-03 19:26 ` Jon Loeliger 2007-12-04 2:10 ` Mark A. Greer @ 2007-12-10 21:18 ` Dale Farnsworth 2007-12-16 6:40 ` David Gibson 2 siblings, 1 reply; 27+ messages in thread From: Dale Farnsworth @ 2007-12-10 21:18 UTC (permalink / raw) To: Linuxppc-dev; +Cc: David Gibson David Gibson wrote: > On Thu, Nov 29, 2007 at 06:28:36PM +0300, Andrei Dolnikov wrote: > > Device tree source file for the Emerson Katana Qp board [snip] > > + mv64x60@f8100000 { /* Marvell Discovery */ > > + #address-cells = <1>; > > + #size-cells = <1>; > > + model = "mv64460"; /* Default */ > > + compatible = "marvell,mv64x60"; [snip] > > + mdio { > > There must be some way of actuall accessing the mdio bus, so this node > ought to have a 'reg' property and unit address. There is no way for the cpu to directly access the mdio bus. The mdio bus is internally accessed by the ethernet MAC. That being the case, maybe it makes more sense to move the mdio node inside of the multiethernet node, as follows, but I don't see how we can give it a reg property or a unit address. multiethernet@2000 { reg = <0x2000 0x2000>; ethernet@0 { device_type = "network"; compatible = "marvell,mv64360-eth"; reg = <0>; interrupts = <32>; interrupt-parent = <&PIC>; phy = <&PHY0>; local-mac-address = [ 00 00 00 00 00 00 ]; }; ethernet@1 { device_type = "network"; compatible = "marvell,mv64360-eth"; reg = <1>; interrupts = <33>; interrupt-parent = <&PIC>; phy = <&PHY1>; local-mac-address = [ 00 00 00 00 00 00 ]; }; mdio { #address-cells = <1>; #size-cells = <0>; device_type = "mdio"; compatible = "marvell,mv64360-mdio"; PHY0: ethernet-phy@1 { device_type = "ethernet-phy"; compatible = "broadcom,bcm5421"; interrupts = <76>; /* GPP 12 */ interrupt-parent = <&PIC>; reg = <1>; }; PHY1: ethernet-phy@3 { device_type = "ethernet-phy"; compatible = "broadcom,bcm5421"; interrupts = <76>; /* GPP 12 */ interrupt-parent = <&PIC>; reg = <3>; }; }; }; Look OK? -Dale ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-12-10 21:18 ` Dale Farnsworth @ 2007-12-16 6:40 ` David Gibson 2007-12-18 16:38 ` Dale Farnsworth 0 siblings, 1 reply; 27+ messages in thread From: David Gibson @ 2007-12-16 6:40 UTC (permalink / raw) To: Dale Farnsworth; +Cc: Linuxppc-dev On Mon, Dec 10, 2007 at 02:18:16PM -0700, Dale Farnsworth wrote: > David Gibson wrote: > > On Thu, Nov 29, 2007 at 06:28:36PM +0300, Andrei Dolnikov wrote: > > > Device tree source file for the Emerson Katana Qp board > > [snip] > > > > + mv64x60@f8100000 { /* Marvell Discovery */ > > > + #address-cells = <1>; > > > + #size-cells = <1>; > > > + model = "mv64460"; /* Default */ > > > + compatible = "marvell,mv64x60"; > > [snip] > > > > + mdio { > > > > There must be some way of actuall accessing the mdio bus, so this node > > ought to have a 'reg' property and unit address. > > There is no way for the cpu to directly access the mdio bus. The > mdio bus is internally accessed by the ethernet MAC. That being the > case, maybe it makes more sense to move the mdio node inside of the > multiethernet node, as follows, but I don't see how we can give it > a reg property or a unit address. Ah, I see. If the mdio interface isn't distinct from the other pieces, then it probably shouldn't get a device node at all. Having an explicit mdio bus with the phys hanging off it is convenient for hardware which actually works that way, but it doesn't have to be done like that. Of course, then the question is where to hang the phy nodes, which look like they have information you need. Since you already have a local addressing scheme for the MACs under the multiethernet, what probably makes sense would be to hang the phys directly under the multiethernet, using an encoding scheme for the reg properties so that the MACs and PHYs aren't confused (say, MACs are 0x0, 0x1, 0x2, PHYs are 0x80000000, 0x80000001, 0x80000002). Incidentally, although I suggested it, I'm not all that fond of the "multiethernet" name, it was just the first thing that occurred to me. > > multiethernet@2000 { > reg = <0x2000 0x2000>; > ethernet@0 { > device_type = "network"; > compatible = "marvell,mv64360-eth"; > reg = <0>; > interrupts = <32>; > interrupt-parent = <&PIC>; > phy = <&PHY0>; > local-mac-address = [ 00 00 00 00 00 00 ]; > }; > ethernet@1 { > device_type = "network"; > compatible = "marvell,mv64360-eth"; > reg = <1>; > interrupts = <33>; > interrupt-parent = <&PIC>; > phy = <&PHY1>; > local-mac-address = [ 00 00 00 00 00 00 ]; > }; > mdio { > #address-cells = <1>; > #size-cells = <0>; > device_type = "mdio"; > compatible = "marvell,mv64360-mdio"; > PHY0: ethernet-phy@1 { > device_type = "ethernet-phy"; > compatible = "broadcom,bcm5421"; > interrupts = <76>; /* GPP 12 */ > interrupt-parent = <&PIC>; > reg = <1>; > }; > PHY1: ethernet-phy@3 { > device_type = "ethernet-phy"; > compatible = "broadcom,bcm5421"; > interrupts = <76>; /* GPP 12 */ > interrupt-parent = <&PIC>; > reg = <3>; > }; > }; > }; -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-12-16 6:40 ` David Gibson @ 2007-12-18 16:38 ` Dale Farnsworth 0 siblings, 0 replies; 27+ messages in thread From: Dale Farnsworth @ 2007-12-18 16:38 UTC (permalink / raw) To: Dale Farnsworth, Linuxppc-dev On Sun, Dec 16, 2007 at 05:40:56PM +1100, David Gibson wrote: > On Mon, Dec 10, 2007 at 02:18:16PM -0700, Dale Farnsworth wrote: > > David Gibson wrote: > > > On Thu, Nov 29, 2007 at 06:28:36PM +0300, Andrei Dolnikov wrote: > > > > Device tree source file for the Emerson Katana Qp board > > > > [snip] > > > > > > + mv64x60@f8100000 { /* Marvell Discovery */ > > > > + #address-cells = <1>; > > > > + #size-cells = <1>; > > > > + model = "mv64460"; /* Default */ > > > > + compatible = "marvell,mv64x60"; > > > > [snip] > > > > > > + mdio { > > > > > > There must be some way of actuall accessing the mdio bus, so this node > > > ought to have a 'reg' property and unit address. > > > > There is no way for the cpu to directly access the mdio bus. The > > mdio bus is internally accessed by the ethernet MAC. That being the > > case, maybe it makes more sense to move the mdio node inside of the > > multiethernet node, as follows, but I don't see how we can give it > > a reg property or a unit address. > > Ah, I see. If the mdio interface isn't distinct from the other > pieces, then it probably shouldn't get a device node at all. Having > an explicit mdio bus with the phys hanging off it is convenient for > hardware which actually works that way, but it doesn't have to be done > like that. > > Of course, then the question is where to hang the phy nodes, which > look like they have information you need. Since you already have a > local addressing scheme for the MACs under the multiethernet, what > probably makes sense would be to hang the phys directly under the > multiethernet, using an encoding scheme for the reg properties so that > the MACs and PHYs aren't confused (say, MACs are 0x0, 0x1, 0x2, PHYs > are 0x80000000, 0x80000001, 0x80000002). Ugh. They really are two separate address spaces. One is an intra-register index, and the other really is an mdio address, even though it's only indirectly addressable. Combining them would obfuscate. I'm proceding with an mdio node under the multiethernet node as I posted below. Let me know if you feel strongly that that should be changed. > Incidentally, although I suggested it, I'm not all that fond of the > "multiethernet" name, it was just the first thing that occurred to me. I'm not fond of it either. Sometimes, naming is hard. :) I'll see if we can come up with something better. Thanks, -Dale > > > > multiethernet@2000 { > > reg = <0x2000 0x2000>; > > ethernet@0 { > > device_type = "network"; > > compatible = "marvell,mv64360-eth"; > > reg = <0>; > > interrupts = <32>; > > interrupt-parent = <&PIC>; > > phy = <&PHY0>; > > local-mac-address = [ 00 00 00 00 00 00 ]; > > }; > > ethernet@1 { > > device_type = "network"; > > compatible = "marvell,mv64360-eth"; > > reg = <1>; > > interrupts = <33>; > > interrupt-parent = <&PIC>; > > phy = <&PHY1>; > > local-mac-address = [ 00 00 00 00 00 00 ]; > > }; > > mdio { > > #address-cells = <1>; > > #size-cells = <0>; > > device_type = "mdio"; > > compatible = "marvell,mv64360-mdio"; > > PHY0: ethernet-phy@1 { > > device_type = "ethernet-phy"; > > compatible = "broadcom,bcm5421"; > > interrupts = <76>; /* GPP 12 */ > > interrupt-parent = <&PIC>; > > reg = <1>; > > }; > > PHY1: ethernet-phy@3 { > > device_type = "ethernet-phy"; > > compatible = "broadcom,bcm5421"; > > interrupts = <76>; /* GPP 12 */ > > interrupt-parent = <&PIC>; > > reg = <3>; > > }; > > }; > > }; ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-11-29 15:28 ` [PATCH 1/5] PowerPC 74xx: Katana Qp device tree Andrei Dolnikov 2007-12-03 1:50 ` David Gibson @ 2007-12-03 20:52 ` Benjamin Herrenschmidt 2007-12-04 1:23 ` Mark A. Greer 1 sibling, 1 reply; 27+ messages in thread From: Benjamin Herrenschmidt @ 2007-12-03 20:52 UTC (permalink / raw) To: Andrei Dolnikov; +Cc: linuxppc-dev > #address-cells = <1>; > + #size-cells = <1>; > + model = "Katana-Qp"; /* Default */ > + compatible = "emerson,Katana-Qp"; > + coherency-off; > + What do that mean (coherency-off) ? Somebody is trying again to use a 74xx with non cache coherent DMA ? That isn't going to fly... Ben. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-12-03 20:52 ` Benjamin Herrenschmidt @ 2007-12-04 1:23 ` Mark A. Greer 2007-12-04 2:14 ` Benjamin Herrenschmidt 2007-12-04 17:28 ` Andrei Dolnikov 0 siblings, 2 replies; 27+ messages in thread From: Mark A. Greer @ 2007-12-04 1:23 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: linuxppc-dev On Tue, Dec 04, 2007 at 07:52:50AM +1100, Benjamin Herrenschmidt wrote: > > #address-cells = <1>; > > + #size-cells = <1>; > > + model = "Katana-Qp"; /* Default */ > > + compatible = "emerson,Katana-Qp"; > > + coherency-off; > > + > > What do that mean (coherency-off) ? > > Somebody is trying again to use a 74xx with non cache coherent DMA ? Hi Ben. I suspect Andrei got that from the prpmc2800 dts which I made so I'll jump in. (BTW, this is the same debate we have every year or two. :) By looking at the dts, that board has an mv64460 which has a couple issues when it comes to coherency (depending on the rev of the chip). One is about not being able to use DCBST instructions with coherency on and the other is about limiting the length of one of the traces (which at least one board manufacturer that I know of refuses to implement). The first one is supposed to be fixed by rev A1 of the part and the second is supposed to be fixed by rev B0 of the part. I don't know what rev(s) are on the board(s) Andrei is using. If its B0 or later, in theory, the part should work with coherency on. Andrei, have you tested with coherency on? -- As far as the prpmc2800 (mv64360)... [I don't know what an NDA let's me say or not so I'll just give summaries of the errata. If you or another reader has signed the NDA you/they can look them up.] I don't recall all of the details anymore but these are the errata I saw by quickly scanning the 64360's list. - "FEr CPU-#1": Basically the CPU could read a stale cache line. Supposed to be fixed in rev A2 & B0 but I haven't verified. - "FEr MPSC-#1": The MPSC can't access a coherent memory region. This is pretty much a show stopper for the prpmc2800. There are no plans to fix that erratum. - "FEr PCI-#4" (Detailed by Application Note AN-84): [This isn't strictly a coherency issue but having coherency enabled exacerbates the problem.] Basically, the bridge can let the cpu read a pci device's registers before all of the data the PCI devices has written has actually made it to memory. This and the fact that the device's write data may be stuck in the PCI Slave Write Buffer (which isn't checked for coherency), the cpu can get stale data. There are no plans to fix that erratum. - "FEr PCI-#5" (Detailed by Application Note AN-85): With certain PCI devices and with coherency enabled, some combinations of PCI transactions can cause a deadlock. There is a workaround documented but I've tried it and it didn't work for me (but I can't be sure that was the erratum I was bumping into). There are no plans to fix that erratum. -- So, the answer depends on what part & what rev of the part you have (e.g., the pegasos doesn't use the MPSC and apparently has the other issues worked around so it can turn on coherency but the prpmc2800 doesn't so it needs coherency off). BTW, I haven't forgotten the inherent bug you described when coherency is off (/me too lazy to find link to the email) but AFAIK I've never run into it. However, if I turn on coherency and stress the PCI bus, it hangs (I can't even look at memory thru a bdi). Mark ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-12-04 1:23 ` Mark A. Greer @ 2007-12-04 2:14 ` Benjamin Herrenschmidt 2007-12-04 5:34 ` Mark A. Greer 2007-12-04 17:28 ` Andrei Dolnikov 1 sibling, 1 reply; 27+ messages in thread From: Benjamin Herrenschmidt @ 2007-12-04 2:14 UTC (permalink / raw) To: Mark A. Greer; +Cc: linuxppc-dev .../... (snip scary bunch of errata) > - "FEr PCI-#4" (Detailed by Application Note AN-84): > > [This isn't strictly a coherency issue but having coherency enabled > exacerbates the problem.] Basically, the bridge can let the cpu read > a pci device's registers before all of the data the PCI devices has > written has actually made it to memory. This and the fact that the > device's write data may be stuck in the PCI Slave Write Buffer > (which isn't checked for coherency), the cpu can get stale data. > > There are no plans to fix that erratum. So if I understand correctly, there's no plan to fix a major PCI spec violation which prevent any kind of reliable implementation whatsoever ? Or rather... the part just doesn't work, period. Don't use it. If you do, you're on your own. > - "FEr PCI-#5" (Detailed by Application Note AN-85): > > With certain PCI devices and with coherency enabled, some combinations > of PCI transactions can cause a deadlock. There is a workaround > documented but I've tried it and it didn't work for me (but I can't be > sure that was the erratum I was bumping into). > > There are no plans to fix that erratum. Yeah... great. Oh well, Paul, what about we just don't support people using that chip ? > So, the answer depends on what part & what rev of the part you have > (e.g., the pegasos doesn't use the MPSC and apparently has the other > issues worked around so it can turn on coherency but the prpmc2800 > doesn't so it needs coherency off). > > BTW, I haven't forgotten the inherent bug you described when coherency > is off (/me too lazy to find link to the email) but AFAIK I've never run > into it. However, if I turn on coherency and stress the PCI bus, it > hangs (I can't even look at memory thru a bdi). Well, as it is today, the "classic" MMU code cannot deal with !coherent. The entire linear mapping is always mapped cacheable with BATs, so stuff may be brought into the cache at any time, potentially polluting DMA data. Dealing with that would be hard. It might be possible by using G on the entire linear mapping like we do on 4xx (yuck), and/or by not using D-BATs (the kernel will blow up in various areas without I-BATs). Ben. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-12-04 2:14 ` Benjamin Herrenschmidt @ 2007-12-04 5:34 ` Mark A. Greer 0 siblings, 0 replies; 27+ messages in thread From: Mark A. Greer @ 2007-12-04 5:34 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: linuxppc-dev On Tue, Dec 04, 2007 at 01:14:43PM +1100, Benjamin Herrenschmidt wrote: > > .../... (snip scary bunch of errata) > > > - "FEr PCI-#4" (Detailed by Application Note AN-84): > > > > [This isn't strictly a coherency issue but having coherency enabled > > exacerbates the problem.] Basically, the bridge can let the cpu read > > a pci device's registers before all of the data the PCI devices has > > written has actually made it to memory. This and the fact that the > > device's write data may be stuck in the PCI Slave Write Buffer > > (which isn't checked for coherency), the cpu can get stale data. > > > > There are no plans to fix that erratum. > > So if I understand correctly, there's no plan to fix a major PCI spec > violation which prevent any kind of reliable implementation whatsoever ? That's just for that particular part (e.g., 64360). Newer parts like the 64460 have it fixed. > > So, the answer depends on what part & what rev of the part you have > > (e.g., the pegasos doesn't use the MPSC and apparently has the other > > issues worked around so it can turn on coherency but the prpmc2800 > > doesn't so it needs coherency off). > > > > BTW, I haven't forgotten the inherent bug you described when coherency > > is off (/me too lazy to find link to the email) but AFAIK I've never run > > into it. However, if I turn on coherency and stress the PCI bus, it > > hangs (I can't even look at memory thru a bdi). > > Well, as it is today, the "classic" MMU code cannot deal with !coherent. > The entire linear mapping is always mapped cacheable with BATs, so stuff > may be brought into the cache at any time, potentially polluting DMA > data. > > Dealing with that would be hard. It might be possible by using G on the > entire linear mapping like we do on 4xx (yuck), and/or by not using > D-BATs (the kernel will blow up in various areas without I-BATs). Hrm, I didn't realize it was in such bad shape. I'll have to take a closer look. Mark ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-12-04 1:23 ` Mark A. Greer 2007-12-04 2:14 ` Benjamin Herrenschmidt @ 2007-12-04 17:28 ` Andrei Dolnikov 2007-12-04 17:35 ` Mark A. Greer 1 sibling, 1 reply; 27+ messages in thread From: Andrei Dolnikov @ 2007-12-04 17:28 UTC (permalink / raw) To: Mark A. Greer; +Cc: David.Jenkins, linuxppc-dev Mark A. Greer wrote: > On Tue, Dec 04, 2007 at 07:52:50AM +1100, Benjamin Herrenschmidt wrote: > >>> #address-cells = <1>; >>> + #size-cells = <1>; >>> + model = "Katana-Qp"; /* Default */ >>> + compatible = "emerson,Katana-Qp"; >>> + coherency-off; >>> + >>> >> What do that mean (coherency-off) ? >> >> Somebody is trying again to use a 74xx with non cache coherent DMA ? >> > > Hi Ben. > > I suspect Andrei got that from the prpmc2800 dts which I made so I'll > jump in. (BTW, this is the same debate we have every year or two. :) > > By looking at the dts, that board has an mv64460 which has a couple > issues when it comes to coherency (depending on the rev of the chip). > > One is about not being able to use DCBST instructions with coherency on > and the other is about limiting the length of one of the traces (which > at least one board manufacturer that I know of refuses to implement). > The first one is supposed to be fixed by rev A1 of the part and the second > is supposed to be fixed by rev B0 of the part. I don't know what rev(s) > are on the board(s) Andrei is using. If its B0 or later, in theory, the > part should work with coherency on. > > Andrei, have you tested with coherency on? > Yes, I tested it with "coherency on", but it didn't work. I checked chip revisions on all boards I have and they all are >= mv64_4_60 B0. Emerson team working on U-Boot for KatanaQP (David Jenkins copied in cc) notified that they have newer firmware version which makes "coherency on" functional. At the moment I have no more details on it, but I'll investigate this issue soon and let you know all the details. > -- > [snip errata] > -- > > So, the answer depends on what part & what rev of the part you have > (e.g., the pegasos doesn't use the MPSC and apparently has the other > issues worked around so it can turn on coherency but the prpmc2800 > doesn't so it needs coherency off). > > BTW, I haven't forgotten the inherent bug you described when coherency > is off (/me too lazy to find link to the email) but AFAIK I've never run > into it. However, if I turn on coherency and stress the PCI bus, it > hangs (I can't even look at memory thru a bdi). > > Mark > Thanks, Andrei. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree 2007-12-04 17:28 ` Andrei Dolnikov @ 2007-12-04 17:35 ` Mark A. Greer 0 siblings, 0 replies; 27+ messages in thread From: Mark A. Greer @ 2007-12-04 17:35 UTC (permalink / raw) To: Andrei Dolnikov; +Cc: David.Jenkins, linuxppc-dev On Tue, Dec 04, 2007 at 08:28:57PM +0300, Andrei Dolnikov wrote: > Mark A. Greer wrote: > >On Tue, Dec 04, 2007 at 07:52:50AM +1100, Benjamin Herrenschmidt wrote: > > > >>> #address-cells = <1>; > >>>+ #size-cells = <1>; > >>>+ model = "Katana-Qp"; /* Default */ > >>>+ compatible = "emerson,Katana-Qp"; > >>>+ coherency-off; > >>>+ > >>> > >>What do that mean (coherency-off) ? > >> > >>Somebody is trying again to use a 74xx with non cache coherent DMA ? > >> > > > >Hi Ben. > > > >I suspect Andrei got that from the prpmc2800 dts which I made so I'll > >jump in. (BTW, this is the same debate we have every year or two. :) > > > >By looking at the dts, that board has an mv64460 which has a couple > >issues when it comes to coherency (depending on the rev of the chip). > > > >One is about not being able to use DCBST instructions with coherency on > >and the other is about limiting the length of one of the traces (which > >at least one board manufacturer that I know of refuses to implement). > >The first one is supposed to be fixed by rev A1 of the part and the second > >is supposed to be fixed by rev B0 of the part. I don't know what rev(s) > >are on the board(s) Andrei is using. If its B0 or later, in theory, the > >part should work with coherency on. > > > >Andrei, have you tested with coherency on? > > > Yes, I tested it with "coherency on", but it didn't work. > > I checked chip revisions on all boards I have and they all are >= > mv64_4_60 B0. FWIW, this is consistent with what I see. Mark ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2007-12-18 16:38 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-11-16 15:43 [PATCH 0/1] PowerPC 74xx: Add Emerson Katana Qp support Andrei Dolnikov 2007-11-16 16:12 ` [PATCH 1/5] PowerPC 74xx: Katana Qp device tree Andrei Dolnikov 2007-11-21 18:08 ` Vitaly Bordug 2007-11-16 16:31 ` [PATCH 4/5] PowerPC 74xx: Katana Qp base support Andrei Dolnikov 2007-11-21 16:30 ` Vitaly Bordug 2007-11-24 18:51 ` Arnd Bergmann 2007-11-24 22:28 ` Benjamin Herrenschmidt -- strict thread matches above, loose matches on Subject: below -- 2007-11-29 15:07 [PATCH 0/5] PowerPC 74xx: Add Emerson Katana Qp support Andrei Dolnikov 2007-11-29 15:28 ` [PATCH 1/5] PowerPC 74xx: Katana Qp device tree Andrei Dolnikov 2007-12-03 1:50 ` David Gibson 2007-12-03 19:26 ` Jon Loeliger 2007-12-04 0:33 ` David Gibson 2007-12-04 13:14 ` Jon Loeliger 2007-12-04 2:10 ` Mark A. Greer 2007-12-04 2:50 ` David Gibson 2007-12-04 5:30 ` Mark A. Greer 2007-12-06 23:27 ` Mark A. Greer 2007-12-08 1:33 ` David Gibson 2007-12-10 17:17 ` Mark A. Greer 2007-12-10 21:18 ` Dale Farnsworth 2007-12-16 6:40 ` David Gibson 2007-12-18 16:38 ` Dale Farnsworth 2007-12-03 20:52 ` Benjamin Herrenschmidt 2007-12-04 1:23 ` Mark A. Greer 2007-12-04 2:14 ` Benjamin Herrenschmidt 2007-12-04 5:34 ` Mark A. Greer 2007-12-04 17:28 ` Andrei Dolnikov 2007-12-04 17:35 ` Mark A. Greer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).