* Re: [PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHYlayer functionality
From: Anton Vorontsov @ 2007-12-02 12:13 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: linuxppc-dev, netdev, 'Jeff Garzik', linux-kernel
In-Reply-To: <051e01c834da$1cce82f0$5267a8c0@Jocke>
On Sun, Dec 02, 2007 at 12:54:36PM +0100, Joakim Tjernlund wrote:
> [SNIP]
> > ^^ the correct solution is to implement arch_initcall function
> > which will create fixed PHYs, and then leave only
> > snprintf(fpi->bus_id, 16, PHY_ID_FMT, 0, *data); part in the
> > fs_enet's find_phy().
> >
> > Try add something like this to the fsl_soc.c (compile untested):
> >
> > - - - -
> > static int __init of_add_fixed_phys(void)
> > {
> > struct device_node *np;
> > const u32 *prop;
> > struct fixed_phy_status status = {};
> >
> > while ((np = of_find_node_by_name(NULL, "ethernet"))) {
> > data = of_get_property(np, "fixed-link", NULL);
> > if (!data)
> > continue;
> >
> > status.link = 1;
> > status.duplex = data[1];
> > status.speed = data[2];
>
> What about Pause and Asym_Pause?
Will be addressed in the next respin of these patches. Let's
hope on Monday.
> Dunno why so few, if any, eth drivers
> impl. it, but the PHY lib supports it.
> Even if fixed PHYs doesn't support it directly I think the OF interface
> should have it.
>
> - fixed-link : <a b c d e> where a is emulated phy id - choose any,
> but unique to the all specified fixed-links, b is duplex - 0 half,
> 1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no pause,
> 1 pause, d asym_pause - 0 no asym_pause, 1 asym_pause.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 24/24] powerpc: Base support for 440SPe "Katmai" eval board
From: Stefan Roese @ 2007-12-02 12:23 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071130061209.497F3DE03A@ozlabs.org>
Hi Ben,
On Friday 30 November 2007, Benjamin Herrenschmidt wrote:
> This adds base support for the Katmai board, including PCI-X and
> PCI-Express (but no RTC, nvram, etc... yet).
Please see comments below.
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> As for Taishan, the bootwrapper code can be simplified. In fact,
> we probably don't need to probe clocks & memsize off the chip and
> just trust what uboot tells us.
>
> arch/powerpc/boot/44x.h | 1
> arch/powerpc/boot/Makefile | 7
> arch/powerpc/boot/cuboot-katmai.c | 35 +++
> arch/powerpc/boot/dts/katmai.dts | 392
> ++++++++++++++++++++++++++++++++++++ arch/powerpc/boot/katmai.c |
> 64 +++++
> arch/powerpc/platforms/44x/Kconfig | 12 +
> arch/powerpc/platforms/44x/Makefile | 3
> arch/powerpc/platforms/44x/katmai.c | 63 +++++
> 8 files changed, 574 insertions(+), 3 deletions(-)
>
> Index: linux-work/arch/powerpc/platforms/44x/Kconfig
> ===================================================================
> --- linux-work.orig/arch/powerpc/platforms/44x/Kconfig 2007-11-30
> 13:51:48.000000000 +1100 +++
> linux-work/arch/powerpc/platforms/44x/Kconfig 2007-11-30 13:51:48.000000000
> +1100 @@ -30,6 +30,14 @@ config TAISHAN
> help
> This option enables support for the IBM PPC440GX "Taishan" evaluation
> board.
>
> +config KATMAI
> + bool "Katmai"
> + depends on 44x
> + default n
> + select 440SPe
> + help
> + This option enables support for the AMCC PPC440SPe evaluation board.
> +
> #config LUAN
> # bool "Luan"
> # depends on 44x
> @@ -74,6 +82,10 @@ config 440GX
> config 440SP
> bool
>
> +config 440SPe
> + select IBM_NEW_EMAC_EMAC4
> + bool
> +
> # 44x errata/workaround config symbols, selected by the CPU models above
> config IBM440EP_ERR42
> bool
> Index: linux-work/arch/powerpc/platforms/44x/Makefile
> ===================================================================
> --- linux-work.orig/arch/powerpc/platforms/44x/Makefile 2007-11-30
> 13:51:48.000000000 +1100 +++
> linux-work/arch/powerpc/platforms/44x/Makefile 2007-11-30
> 13:51:48.000000000 +1100 @@ -1,5 +1,6 @@
> obj-$(CONFIG_44x) := misc_44x.o
> obj-$(CONFIG_EBONY) += ebony.o
> obj-$(CONFIG_TAISHAN) += taishan.o
> -obj-$(CONFIG_BAMBOO) += bamboo.o
> +obj-$(CONFIG_BAMBOO) += bamboo.o
> obj-$(CONFIG_SEQUOIA) += sequoia.o
> +obj-$(CONFIG_KATMAI) += katmai.o
> Index: linux-work/arch/powerpc/boot/dts/katmai.dts
> ===================================================================
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ linux-work/arch/powerpc/boot/dts/katmai.dts 2007-11-30
> 14:46:02.000000000 +1100 @@ -0,0 +1,392 @@
> +/*
> + * Device Tree Source for AMCC Bamboo
> + *
> + * Copyright (c) 2006, 2007 IBM Corp.
> + * Benjamin Herrenschmidt <benh@kernel.crashing.org>
> + *
> + * Copyright (c) 2006, 2007 IBM Corp.
> + * Josh Boyer <jwboyer@linux.vnet.ibm.com>
> + *
> + * FIXME: Draft only!
> + *
> + * 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 = <2>;
> + #size-cells = <1>;
> + model = "amcc,katmai";
> + compatible = "amcc,katmai";
> + dcr-parent = <&/cpus/PowerPC,440SPe@0>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,440SPe@0 {
> + device_type = "cpu";
> + reg = <0>;
> + clock-frequency = <0>; /* Filled in by zImage */
> + timebase-frequency = <0>; /* Filled in by zImage */
> + i-cache-line-size = <20>;
> + d-cache-line-size = <20>;
> + i-cache-size = <20000>;
> + d-cache-size = <20000>;
> + dcr-controller;
> + dcr-access-method = "native";
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0 0 0>; /* Filled in by zImage */
> + };
> +
> + UIC0: interrupt-controller0 {
> + compatible = "ibm,uic-440spe","ibm,uic";
> + interrupt-controller;
> + cell-index = <0>;
> + dcr-reg = <0c0 009>;
> + #address-cells = <0>;
> + #size-cells = <0>;
> + #interrupt-cells = <2>;
> + };
> +
> + UIC1: interrupt-controller1 {
> + compatible = "ibm,uic-440spe","ibm,uic";
> + interrupt-controller;
> + cell-index = <1>;
> + dcr-reg = <0d0 009>;
> + #address-cells = <0>;
> + #size-cells = <0>;
> + #interrupt-cells = <2>;
> + interrupts = <1e 4 1f 4>; /* cascade */
> + interrupt-parent = <&UIC0>;
> + };
> +
> + UIC2: interrupt-controller2 {
> + compatible = "ibm,uic-440spe","ibm,uic";
> + interrupt-controller;
> + cell-index = <2>;
> + dcr-reg = <0e0 009>;
> + #address-cells = <0>;
> + #size-cells = <0>;
> + #interrupt-cells = <2>;
> + interrupts = <a 4 b 4>; /* cascade */
> + interrupt-parent = <&UIC0>;
> + };
> +
> + UIC3: interrupt-controller3 {
> + compatible = "ibm,uic-440spe","ibm,uic";
> + interrupt-controller;
> + cell-index = <3>;
> + dcr-reg = <0f0 009>;
> + #address-cells = <0>;
> + #size-cells = <0>;
> + #interrupt-cells = <2>;
> + interrupts = <10 4 11 4>; /* cascade */
> + interrupt-parent = <&UIC0>;
> + };
> +
> + SDR0: sdr {
> + compatible = "ibm,sdr-440spe";
> + dcr-reg = <00e 002>;
> + };
> +
> + CPR0: cpr {
> + compatible = "ibm,cpr-440spe";
> + dcr-reg = <00c 002>;
> + };
> +
> + plb {
> + compatible = "ibm,plb-440spe", "ibm,plb-440gp", "ibm,plb4";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges;
> + clock-frequency = <0>; /* Filled in by zImage */
> +
> + SDRAM0: sdram {
> + compatible = "ibm,sdram-440spe", "ibm,sdram-405gp";
> + dcr-reg = <010 2>;
> + };
> +
> + MAL0: mcmal {
> + compatible = "ibm,mcmal-440spe", "ibm,mcmal2";
> + dcr-reg = <180 62>;
> + num-tx-chans = <2>;
> + num-rx-chans = <1>;
> + interrupt-parent = <&MAL0>;
> + interrupts = <0 1 2 3 4>;
> + #interrupt-cells = <1>;
> + #address-cells = <0>;
> + #size-cells = <0>;
> + interrupt-map = </*TXEOB*/ 0 &UIC1 6 4
> + /*RXEOB*/ 1 &UIC1 7 4
> + /*SERR*/ 2 &UIC1 1 4
> + /*TXDE*/ 3 &UIC1 2 4
> + /*RXDE*/ 4 &UIC1 3 4>;
> + };
> +
> + POB0: opb {
> + compatible = "ibm,opb-440spe", "ibm,opb-440gp", "ibm,opb";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <00000000 4 e0000000 20000000>;
> + clock-frequency = <0>; /* Filled in by zImage */
> +
> + EBC0: ebc {
> + compatible = "ibm,ebc-440spe", "ibm,ebc-440gp", "ibm,ebc";
> + dcr-reg = <012 2>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + clock-frequency = <0>; /* Filled in by zImage */
> + ranges;
> + interrupts = <5 1>;
> + interrupt-parent = <&UIC1>;
> + };
> +
> + UART0: serial@10000200 {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <10000200 8>;
> + virtual-reg = <a0000200>;
> + clock-frequency = <0>; /* Filled in by zImage */
> + current-speed = <1c200>;
> + interrupt-parent = <&UIC0>;
> + interrupts = <0 4>;
> + };
> +
> + UART1: serial@10000300 {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <10000300 8>;
> + virtual-reg = <a0000300>;
> + clock-frequency = <0>;
> + current-speed = <0>;
> + interrupt-parent = <&UIC0>;
> + interrupts = <1 4>;
> + };
> +
> +
> + UART2: serial@10000600 {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <10000600 8>;
> + virtual-reg = <a0000600>;
> + clock-frequency = <0>;
> + current-speed = <0>;
> + interrupt-parent = <&UIC1>;
> + interrupts = <5 4>;
> + };
> +
> + IIC0: i2c@10000400 {
> + device_type = "i2c";
> + compatible = "ibm,iic-440spe", "ibm,iic-440gp", "ibm,iic";
> + reg = <10000400 14>;
> + interrupt-parent = <&UIC0>;
> + interrupts = <2 4>;
> + };
> +
> + IIC1: i2c@10000500 {
> + device_type = "i2c";
> + compatible = "ibm,iic-440spe", "ibm,iic-440gp", "ibm,iic";
> + reg = <10000500 14>;
> + interrupt-parent = <&UIC0>;
> + interrupts = <3 4>;
> + };
> +
> + EMAC0: ethernet@10000800 {
> + linux,network-index = <0>;
> + device_type = "network";
> + compatible = "ibm,emac-440spe", "ibm,emac4";
> + interrupt-parent = <&UIC1>;
> + interrupts = <1c 4 1d 4>;
> + reg = <10000800 70>;
> + local-mac-address = [000000000000];
> + mal-device = <&MAL0>;
> + mal-tx-channel = <0>;
> + mal-rx-channel = <0>;
> + cell-index = <0>;
> + max-frame-size = <5dc>;
> + rx-fifo-size = <1000>;
> + tx-fifo-size = <800>;
> + phy-mode = "gmii";
> + phy-map = <00000000>;
> + has-inverted-stacr-oc;
> + has-new-stacr-staopc;
> + };
> + };
> +
> + PCIX0: pci@c0ec00000 {
> + device_type = "pci";
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + compatible = "ibm,plb-pcix-440spe", "ibm,plb-pcix";
> + primary;
> + large-inbound-windows;
> + enable-msi-hole;
> + reg = <c 0ec00000 8 /* Config space access */
> + 0 0 0 /* no IACK cycles */
> + c 0ed00000 4 /* Special cycles */
> + c 0ec80000 100 /* Internal registers */
> + c 0ec80100 fc>; /* Internal messaging registers */
> +
> + /* Outbound ranges, one memory and one IO,
> + * later cannot be changed
> + */
> + ranges = <02000000 0 80000000 0000000d 80000000 0 80000000
> + 01000000 0 00000000 0000000c 08000000 0 00010000>;
> +
> + /* Inbound 2GB range starting at 0 */
> + dma-ranges = <42000000 0 0 0 0 0 80000000>;
> +
> + /* This drives busses 0 to 0xf */
> + bus-range = <0 f>;
> +
> + /*
> + * On Katmai, the following PCI-X interrupts signals
> + * have to be enabled via jumpers (only INTA is
> + * enabled per default):
> + *
> + * INTB: J3: 1-2
> + * INTC: J2: 1-2
> + * INTD: J1: 1-2
> + */
> + interrupt-map-mask = <f800 0 0 7>;
> + interrupt-map = <
> + /* IDSEL 1 */
> + 0800 0 0 1 &UIC1 14 8
> + 0800 0 0 2 &UIC1 13 8
> + 0800 0 0 3 &UIC1 12 8
> + 0800 0 0 4 &UIC1 11 8
> + >;
> + };
> +
> + PCIE0: pciex@d00000000 {
> + device_type = "pci";
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + compatible = "ibm,plb-pciex-440speB", "ibm,plb-pciex";
> + primary;
> + port = <0>; /* port number */
port = <1>;
> + reg = <d 00000000 20000000 /* Config space access */
> + c 10000000 00001000>; /* Registers */
> + dcr-reg = <100 020>;
> + sdr-base = <300>;
> +
> + /* Outbound ranges, one memory and one IO,
> + * later cannot be changed
> + */
> + ranges = <02000000 0 80000000 0000000e 00000000 0 80000000
> + 01000000 0 00000000 0000000f 80000000 0 00010000>;
> +
> + /* Inbound 2GB range starting at 0 */
> + dma-ranges = <42000000 0 0 0 0 0 80000000>;
> +
> + /* This drives busses 10 to 0x1f */
> + bus-range = <10 1f>;
> +
> + /* Legacy interrupts (note the weird polarity). We are
> + * de-swizzling here because the numbers are actually for
> + * port of the root complex virtual P2P bridge. But I want
> + * to avoid putting a node for it in the tree, so the numbers
> + * below are basically de-swizzled numbers. The real slot is
> + * on idsel 1, so the swizzling is new_pin = (pin % 4) + 1
> + */
> + interrupt-map-mask = <0000 0 0 7>;
> + interrupt-map = <
> + 0000 0 0 2 &UIC3 0 4 /* swizzled int A */
> + 0000 0 0 3 &UIC3 1 4 /* swizzled int B */
> + 0000 0 0 4 &UIC3 2 4 /* swizzled int C */
> + 0000 0 0 1 &UIC3 3 4 /* swizzled int D */>;
> + };
> +
> + PCIE1: pciex@d20000000 {
> + device_type = "pci";
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + compatible = "ibm,plb-pciex-440speB", "ibm,plb-pciex";
> + primary;
> + port = <0>; /* port number */
port = <2>;
You might want to add a defconfig file for Katmai too.
BTW: I'm starting to "play" with all this new stuff in
Josh's "2.6.25-candidates" branch and experience some problems with PCIe.
Will post first response soon.
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 24/24] powerpc: Base support for 440SPe "Katmai" eval board
From: Stefan Roese @ 2007-12-02 12:35 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200712021323.17821.sr@denx.de>
On Sunday 02 December 2007, Stefan Roese wrote:
> > + PCIE0: pciex@d00000000 {
> > + device_type = "pci";
> > + #interrupt-cells = <1>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
> > + compatible = "ibm,plb-pciex-440speB", "ibm,plb-pciex";
> > + primary;
> > + port = <0>; /* port number */
>
> port = <1>;
Ups, sorry. <0> is correct here of course. "PCIE1" and "PCIE2" need different
numbers though.
> > + reg = <d 00000000 20000000 /* Config space access */
> > + c 10000000 00001000>; /* Registers */
> > + dcr-reg = <100 020>;
> > + sdr-base = <300>;
> > +
> > + /* Outbound ranges, one memory and one IO,
> > + * later cannot be changed
> > + */
> > + ranges = <02000000 0 80000000 0000000e 00000000 0 80000000
> > + 01000000 0 00000000 0000000f 80000000 0 00010000>;
> > +
> > + /* Inbound 2GB range starting at 0 */
> > + dma-ranges = <42000000 0 0 0 0 0 80000000>;
> > +
> > + /* This drives busses 10 to 0x1f */
> > + bus-range = <10 1f>;
> > +
> > + /* Legacy interrupts (note the weird polarity). We are
> > + * de-swizzling here because the numbers are actually for
> > + * port of the root complex virtual P2P bridge. But I want
> > + * to avoid putting a node for it in the tree, so the numbers
> > + * below are basically de-swizzled numbers. The real slot is
> > + * on idsel 1, so the swizzling is new_pin = (pin % 4) + 1
> > + */
> > + interrupt-map-mask = <0000 0 0 7>;
> > + interrupt-map = <
> > + 0000 0 0 2 &UIC3 0 4 /* swizzled int A */
> > + 0000 0 0 3 &UIC3 1 4 /* swizzled int B */
> > + 0000 0 0 4 &UIC3 2 4 /* swizzled int C */
> > + 0000 0 0 1 &UIC3 3 4 /* swizzled int D */>;
> > + };
> > +
> > + PCIE1: pciex@d20000000 {
> > + device_type = "pci";
> > + #interrupt-cells = <1>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
> > + compatible = "ibm,plb-pciex-440speB", "ibm,plb-pciex";
> > + primary;
> > + port = <0>; /* port number */
>
> port = <2>;
That should be <1> now. And PCIE2 has this problem too.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 12/24] powerpc: 4xx PLB to PCI Express support
From: Stefan Roese @ 2007-12-02 12:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071130061155.41D71DDF5F@ozlabs.org>
Hi Ben,
On Friday 30 November 2007, Benjamin Herrenschmidt wrote:
> This adds to the previous 2 patches the support for the 4xx PCI Express
> cells as found in the 440SPe revA, revB and 405EX.
>
> Unfortunately, due to significant differences between these, and other
> interesting "features" of those pieces of HW, the code isn't as simple
> as it is for PCI and PCI-X and some of the functions differ significantly
> between the 3 implementations. Thus, not only this code can only support
> those 3 implementations for now and will refuse to operate on any other,
> but there are added ifdef's to avoid the bloat of building a fairly large
> amount of code on platforms that don't need it.
>
> Also, this code currently only supports fully initializing root complex
> nodes, not endpoint. Some more code will have to be lifted from the
> arch/ppc implementation to add the endpoint support, though it's mostly
> differences in memory mapping, and the question on how to represent
> endpoint mode PCI in the device-tree is thus open.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> 440SPeA is untested, 440SPeB is slightly tested (with a sky2 network card
> on port 0 only for now) and 405EX is untested.
As already mentioned I'm experiencing some problems with this current version.
At least what's available in Josh's 2.6.25-candidates branch. The kernel
crashes in the first ppc4xx_pciex_read_config() call upon (after I fixed the
small problem mentioned further down below):
BUG_ON(hose != port->hose);
So before digging into this deeper, I wanted to check if you don't have a
slightly "better" version which passed your tests with the sky2 PCIe card.
One further comment below.
> arch/powerpc/Kconfig | 1
> arch/powerpc/sysdev/Kconfig | 8
> arch/powerpc/sysdev/ppc4xx_pci.c | 927
> ++++++++++++++++++++++++++++++++++++++- arch/powerpc/sysdev/ppc4xx_pci.h |
> 237 +++++++++
> 4 files changed, 1172 insertions(+), 1 deletion(-)
>
> Index: linux-work/arch/powerpc/sysdev/ppc4xx_pci.c
<snip>
> +static void __init ppc4xx_pciex_port_setup_hose(struct ppc4xx_pciex_port
> *port) +{
> + struct resource dma_window;
> + struct pci_controller *hose = NULL;
> + const int *bus_range;
> + int primary, busses;
> + void __iomem *mbase = NULL, *cfg_data = NULL;
> +
> + /* XXX FIXME: Handle endpoint mode properly */
> + if (port->endpoint)
> + return;
> +
> + /* Check if primary bridge */
> + if (of_get_property(port->node, "primary", NULL))
> + primary = 1;
> +
> + /* Get bus range if any */
> + bus_range = of_get_property(port->node, "bus-range", NULL);
> +
> + /* Allocate the host controller data structure */
> + hose = pcibios_alloc_controller(port->node);
> + if (!hose)
> + goto fail;
> +
> + /* We stick the port number in "indirect_type" so the config space
> + * ops can retrieve the port data structure easily
> + */
> + hose->indirect_type = port->index;
> +
> + /* Get bus range */
> + hose->first_busno = bus_range ? bus_range[0] : 0x0;
> + hose->last_busno = bus_range ? bus_range[1] : 0xff;
> +
> + /* Because of how big mapping the config space is (1M per bus), we
> + * limit how many busses we support. In the long run, we could replace
> + * that with something akin to kmap_atomic instead. We set aside 1 bus
> + * for the host itself too.
> + */
> + busses = hose->last_busno - hose->first_busno; /* This is off by 1 */
> + if (busses > MAX_PCIE_BUS_MAPPED) {
> + busses = MAX_PCIE_BUS_MAPPED;
> + hose->last_busno = hose->first_busno + busses;
> + }
> +
> + /* We map the external config space in cfg_data and the host config
> + * space in cfg_addr. External space is 1M per bus, internal space
> + * is 4K
> + */
> + cfg_data = ioremap(port->cfg_space.start +
> + (hose->first_busno + 1) * 0x100000,
> + busses * 0x100000);
> + mbase = ioremap(port->cfg_space.start + 0x10000000, 0x1000);
> + if (cfg_data == NULL || mbase == NULL) {
> + printk(KERN_ERR "%s: Can't map config space !",
> + port->node->full_name);
> + goto fail;
> + }
> +
> + hose->cfg_data = cfg_data;
> + hose->cfg_addr = mbase;
> +
> +#ifdef CONFIG_40x
> + /*
> + * 405EX needs this offset in the PCIe config cycles
> + * need a little more debugging to see if this can be handled
> + * differently. sr, 2007-10
> + */
> + if (of_device_is_compatible(port->node, "ibm,plb-pciex-405ex"))
> + hose->cfg_data -= 0x8000;
> +#endif /* CONFIG_40x */
> +
> + pr_debug("PCIE %s, bus %d..%d\n", port->node->full_name,
> + hose->first_busno, hose->last_busno);
> + pr_debug(" config space mapped at: root @0x%p, other @0x%p\n",
> + hose->cfg_addr, hose->cfg_data);
> +
> + /* Setup config space */
> + hose->ops = &ppc4xx_pciex_pci_ops;
> + port->hose = hose;
> + mbase = (void __iomem *)hose->cfg_addr;
> +
> + /*
> + * Set bus numbers on our root port
> + */
> + out_8(mbase + PCI_PRIMARY_BUS, hose->first_busno);
> + out_8(mbase + PCI_SECONDARY_BUS, hose->first_busno + 1);
> + out_8(mbase + PCI_SUBORDINATE_BUS, hose->last_busno);
> +
> + /*
> + * OMRs are already reset, also disable PIMs
> + */
> + out_le32(mbase + PECFG_PIMEN, 0);
> +
> + /* Parse outbound mapping resources */
> + pci_process_bridge_OF_ranges(hose, port->node, primary);
> +
> + /* Parse inbound mapping resources */
> + if (ppc4xx_parse_dma_ranges(hose, mbase, &dma_window) != 0)
> + goto fail;
> +
> + /* Configure outbound ranges POMs */
> + ppc4xx_configure_pciex_POMs(port, hose, mbase);
> +
> + /* Configure inbound ranges PIMs */
> + ppc4xx_configure_pciex_PIMs(port, hose, mbase, &dma_window);
> +
> + /* The root complex doesn't show up if we don't set some vendor
> + * and device IDs into it. Those are the same bogus one that the
> + * initial code in arch/ppc add. We might want to change that.
> + */
> + out_le16(mbase + 0x200, 0xaaa0 + port->index);
> + out_le16(mbase + 0x202, 0xbed0 + port->index);
> +
> + /* Set Class Code to PCI-PCI bridge and Revision Id to 1 */
> + out_le32(mbase + 0x208, 0x06040001);
> +
> + printk(KERN_INFO "PCIE%d: successfully set as root-complex\n",
> + port->index);
> + return;
> + fail:
> + if (hose)
> + pcibios_free_controller(hose);
> + if (fg_data)
Should be "cfg_data". I suspect you you have a newer version that compiles
clean.
Thanks.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* Re: [PATCH 12/24] powerpc: 4xx PLB to PCI Express support
From: Josh Boyer @ 2007-12-02 14:17 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200712021332.29074.sr@denx.de>
On Sun, 2 Dec 2007 13:32:28 +0100
Stefan Roese <sr@denx.de> wrote:
> Hi Ben,
>
> On Friday 30 November 2007, Benjamin Herrenschmidt wrote:
> > This adds to the previous 2 patches the support for the 4xx PCI Express
> > cells as found in the 440SPe revA, revB and 405EX.
> >
> > Unfortunately, due to significant differences between these, and other
> > interesting "features" of those pieces of HW, the code isn't as simple
> > as it is for PCI and PCI-X and some of the functions differ significantly
> > between the 3 implementations. Thus, not only this code can only support
> > those 3 implementations for now and will refuse to operate on any other,
> > but there are added ifdef's to avoid the bloat of building a fairly large
> > amount of code on platforms that don't need it.
> >
> > Also, this code currently only supports fully initializing root complex
> > nodes, not endpoint. Some more code will have to be lifted from the
> > arch/ppc implementation to add the endpoint support, though it's mostly
> > differences in memory mapping, and the question on how to represent
> > endpoint mode PCI in the device-tree is thus open.
> >
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > ---
> >
> > 440SPeA is untested, 440SPeB is slightly tested (with a sky2 network card
> > on port 0 only for now) and 405EX is untested.
>
> As already mentioned I'm experiencing some problems with this current version.
> At least what's available in Josh's 2.6.25-candidates branch. The kernel
> crashes in the first ppc4xx_pciex_read_config() call upon (after I fixed the
> small problem mentioned further down below):
>
> BUG_ON(hose != port->hose);
>
> So before digging into this deeper, I wanted to check if you don't have a
> slightly "better" version which passed your tests with the sky2 PCIe card.
These should be the latest versions that Ben sent out. I plan on
applying newer versions to that branch as they come out, which means
the git branch will probably reset often for a bit.
I have some other patches I want to pull into there as well anyway.
josh
^ permalink raw reply
* Re: [PATCH 0/3] OF-platform PATA driver
From: Olof Johansson @ 2007-12-02 15:45 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linux-ide, Paul Mundt, Jeff Garzik, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20071202114617.GA2923@zarina>
On Sun, Dec 02, 2007 at 02:46:17PM +0300, Anton Vorontsov wrote:
> On Sat, Dec 01, 2007 at 09:57:55PM -0600, Olof Johansson wrote:
> > On Sun, Dec 02, 2007 at 02:58:10AM +0300, Anton Vorontsov wrote:
> > > On Sat, Dec 01, 2007 at 05:54:49PM -0500, Jeff Garzik wrote:
> > > while (1) {
> > > send_patches();
> > >
> > > if (ack_collected(PaulM) && ack_collected(PowerPC_people))
> > > break;
> > >
> > > sleep(wait_for_comments_timeout); <-- currently here.
> >
> > I still haven't seen you address the compatible comments (that
> > pata-platform is suboptimal). Or did I miss some respin of the patches?
>
> I didn't resend these patches yet. You started the thread, but you hid
> away from the discussion (you had been Cc'ed to every mail).
>
> 1. Arnd suggested {p,s}ata-pio-{1,2,3,..} or ata-{1,2,3,..} compatible
> scheme;
> 2. Sergei verbosely explained that that there is no reason to
> complicate compatible property. He suggested ata-generic, or
> ata-simple;
>
> Mainly I was awaiting for your further comments. By now I tend to
> follow Sergei's comments and rename compatible stuff to ata-generic.
> Are you fine with it?
Ah, sorry about that. The discussion got a bit noisy so I tuned it out.
Yes, I agree with Sergei: I don't think the pio/ata mode belongs there,
"ata-generic" (or "generic-ata") sounds good to me. If firmwares want to
specify pata/sata stuff as more specific compatible fields, then they are
free to, but the driver shouldn't depend on it as long as "ata-generic"
is in the list.
ATA/PIO modes could be communicated with separate properties as well,
but I don't see a need for it right now. Tuning PIO modes normally
involves changing bus parameters/cycle times, etc, and that' hardly
generic enough to be handled by this driver in the first place.
I will need to add a compatible field to it myself (our firmware uses
"electra-ide") + some minor changes, but I will do that on top of this
patch once it goes in since it involves removing the old code from
arch/powerpc/platforms/pasemi.
-Olof
^ permalink raw reply
* Re: [BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions
From: Kamalesh Babulal @ 2007-12-02 15:55 UTC (permalink / raw)
To: Jan Kara; +Cc: samba-technical, linux-kernel, linuxppc-dev, nfs, Andrew Morton
In-Reply-To: <20071129144030.GE16558@duck.suse.cz>
Jan Kara wrote:
> On Thu 29-11-07 17:27:08, Kamalesh Babulal wrote:
>> Andrew Morton wrote:
>>> On Thu, 29 Nov 2007 14:30:14 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>>>
>>>> Hi Andrew,
>>>>
>>>> While running file system stress on nfs and cifs mounted partitions, the machine
>>>> drops to xmon
>>>>
>>>> 1:mon> e
>>>> cpu 0x1: Vector: 300 (Data Access) at [c000000080a9f880]
>>>> pc: c0000000001392c8: .inotify_inode_queue_event+0x50/0x158
>>>> lr: c0000000001074d0: .vfs_link+0x204/0x298
>>>> sp: c000000080a9fb00
>>>> msr: 8000000000009032
>>>> dar: 280
>>>> dsisr: 40010000
>>>> current = 0xc0000000c8e6f670
>>>> paca = 0xc000000000512c00
>>>> pid = 2848, comm = fsstress
>>>> 1:mon> t
>>>> [c000000080a9fbd0] c0000000001074d0 .vfs_link+0x204/0x298
>>>> [c000000080a9fc70] c00000000010b6e0 .sys_linkat+0x134/0x1b4
>>>> [c000000080a9fe30] c00000000000872c syscall_exit+0x0/0x40
>>>> --- Exception: c00 (System Call) at 000000000ff1bdfc
>>>> SP (ffeaed10) is in userspace
>>>> 1:mon> r
>>>> R00 = c0000000001074d0 R16 = 0000000000000000
>>>> R01 = c000000080a9fb00 R17 = 0000000000000000
>>>> R02 = c00000000060c380 R18 = 0000000000000000
>>>> R03 = 0000000000000000 R19 = 0000000000000000
>>>> R04 = 0000000000000004 R20 = 0000000000000000
>>>> R05 = 0000000000000000 R21 = 0000000000000000
>>>> R06 = 0000000000000000 R22 = 0000000000000000
>>>> R07 = 0000000000000000 R23 = 0000000000000004
>>>> R08 = 0000000000000000 R24 = 0000000000000280
>>>> R09 = 0000000000000000 R25 = fffffffffffff000
>>>> R10 = 0000000000000001 R26 = c000000082827790
>>>> R11 = c0000000003963e8 R27 = c0000000828275a0
>>>> R12 = d000000000deec78 R28 = 0000000000000000
>>>> R13 = c000000000512c00 R29 = c00000007b18fcf0
>>>> R14 = 0000000000000000 R30 = c0000000005bc088
>>>> R15 = 0000000000000000 R31 = 0000000000000000
>>>> pc = c0000000001392c8 .inotify_inode_queue_event+0x50/0x158
>>>> lr = c0000000001074d0 .vfs_link+0x204/0x298
>>>> msr = 8000000000009032 cr = 24000882
>>>> ctr = c0000000003963e8 xer = 0000000000000000 trap = 300
>>>> dar = 0000000000000280 dsisr = 40010000
>>>>
>>>>
>>>> The gdb output shows
>>>>
>>>> 0xc0000000001076d4 is in vfs_symlink (include/linux/fsnotify.h:108).
>>>> 103 * fsnotify_create - 'name' was linked in
>>>> 104 */
>>>> 105 static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
>>>> 106 {
>>>> 107 inode_dir_notify(inode, DN_CREATE);
>>>> 108 inotify_inode_queue_event(inode, IN_CREATE, 0, dentry->d_name.name,
>>>> 109 dentry->d_inode);
>>>> 110 audit_inode_child(dentry->d_name.name, dentry, inode);
>>>> 111 }
>>>> 112
>>>>
>>> If it is reproducible can you please try reverting
>>> inotify-send-in_attrib-events-when-link-count-changes.patch?
>> Hi Andrew,
>>
>> reverting the patch inotify-send-in_attrib-events-when-link-count-changes.patch, the
>> bug is not reproduced.
> OK, it's a problem with CIFS. Its cifs_hardlink() function doesn't call
> d_instantiate() and thus returns a dentry with d_inode set to NULL. I'm not
> sure if such behavior is really correct but anyway, attached is a new
> version of the patch which should handle it gracefully. Kamalesh, can you
> please give it a try? Thanks.
>
> Honza
Hi Jan,
Thanks, the patch fixes the bug.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [PATCH v2 2/2] [POWERPC] Use new machine_xxx_initcall hooks in platform code
From: Olof Johansson @ 2007-12-02 19:15 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20071202061033.21193.64818.stgit@trillian.secretlab.ca>
On Sat, Dec 01, 2007 at 11:10:33PM -0700, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> This patch makes the platform code use the new machine-specific initcall
> hooks. This has the advantage of not needing to explicitly test
> machine_is() at the top of every initcall function.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
PA Semi parts:
Acked-by: Olof Johansson <olof@lixom.net>
Overall I approve of the approach as well, looks like a good idea.
I tried building all defconfigs, they pass.
-Olof
^ permalink raw reply
* Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Olof Johansson @ 2007-12-02 20:25 UTC (permalink / raw)
To: Clemens Koller; +Cc: Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <47501A4F.8050400@anagramm.de>
On Fri, Nov 30, 2007 at 03:12:31PM +0100, Clemens Koller wrote:
> Hello, Alessandro!
>
> Alessandro Zummo schrieb:
> > It's just to see if there's any timing issue like
> module-coming-up-before-bus-and/or-rtc.
> > it should work anyway, but who knows...
>
> Here comes more debugging output:
>
> Please note that I have now _two_ almost identical systems up and running
> with the
> latest kernel. One machine (ecam) with an pcf8563 RTC on I2C and another
> one (fox_1)
> with an DS1337. Both RTCs work, but the kernel doesn't get the time right.
ds1307 requires you to register i2c_board_info for it to probe properly.
Does your platform do so?
-Olof
^ permalink raw reply
* Re: [PATCH 12/24] powerpc: 4xx PLB to PCI Express support
From: Benjamin Herrenschmidt @ 2007-12-02 20:33 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200712021332.29074.sr@denx.de>
On Sun, 2007-12-02 at 13:32 +0100, Stefan Roese wrote:
> As already mentioned I'm experiencing some problems with this current
> version.
> At least what's available in Josh's 2.6.25-candidates branch. The
> kernel
> crashes in the first ppc4xx_pciex_read_config() call upon (after I
> fixed the
> small problem mentioned further down below):
>
> BUG_ON(hose != port->hose);
>
> So before digging into this deeper, I wanted to check if you don't
> have a
> slightly "better" version which passed your tests with the sky2 PCIe
> card.
Yup, looks I forgot a quilt ref or something. I'll check. I'll also give
port 1 and 2 a go (after fixing the DT).
I also want to change the config space code to use some fixmap type
direct mapping/unmapping to remove bus number limitations as soon as
Kumar has implemented the fixmap stuff, since he seems to be working on
it now.
Ben.
^ permalink raw reply
* Problem compiling sequoia using DENX kernel. Xenomai-patch required?
From: Niklaus Giger @ 2007-12-02 20:41 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]
Hi
I tried with (tags DENX-v2.6.23.9, DENX-v.2.6.23, master) to build a kernel
for the sequoia board.
I am using ELDK 4.1. I did a
git checkout -b copy-master master
make ARCH=powerpc CROSS_COMPILE=ppc_4xx- CFLAGS=-g sequoia_defconfig
make ARCH=powerpc CROSS_COMPILE=ppc_4xx- CFLAGS=-g zImage
First I stumbled about problem compiling arch/powerpc/platforms/44x/ppc4xx*.c
file with errors like
arch/powerpc/platforms/44x/ppc4xx-pci.c: In function 'ppc4xx_setup_pci':
arch/powerpc/platforms/44x/ppc4xx-pci.c:62: sorry, unimplemented: inlining
failed in call to 'pci_cfg_out': function body not available
arch/powerpc/platforms/44x/ppc4xx-pci.c:98: sorry, unimplemented: called from
here
After applying the at attached patch I got farther till
CC kernel/softirq.o
kernel/softirq.c: In function 'raise_softirq':
kernel/softirq.c:319: sorry, unimplemented: inlining failed in call
to 'raise_softirq_irqoff': function body not available
kernel/softirq.c:342: sorry, unimplemented: called from here
make[2]: *** [kernel/softirq.o] Fehler 1
I thought that denx compiled images for the sequoia using 2.6.23.
Do they only work after having applied the Xenomai patch? Because if I apply
the Xenomai patch, the kernel compiles cleanly. In this case I think it
would be nice to get somewhere a hint (or did I missed it somewhere) that
this is a requirement. I lost quite a few hours as I wanted to first compile
a "normal" kernel and afterwars apply the xenomai patch.
Any clarifikation would be appreciated.
Best regards
--
Niklaus Giger
[-- Attachment #2: powerpc.diff --]
[-- Type: text/x-diff, Size: 1942 bytes --]
diff --git a/arch/powerpc/platforms/44x/ppc4xx-nand.c b/arch/powerpc/platforms/44x/ppc4xx-nand.c
index 2fb553b..0574d2c 100644
--- a/arch/powerpc/platforms/44x/ppc4xx-nand.c
+++ b/arch/powerpc/platforms/44x/ppc4xx-nand.c
@@ -29,8 +29,6 @@
#include <linux/mtd/nand.h>
#include <linux/mtd/ndfc.h>
-#include <mm/mmu_decl.h>
-
#include <asm/system.h>
#include <asm/atomic.h>
#include <asm/prom.h>
diff --git a/arch/powerpc/platforms/44x/ppc4xx-pci.c b/arch/powerpc/platforms/44x/ppc4xx-pci.c
index 4666250..137555f 100644
--- a/arch/powerpc/platforms/44x/ppc4xx-pci.c
+++ b/arch/powerpc/platforms/44x/ppc4xx-pci.c
@@ -26,8 +26,6 @@
#include <linux/module.h>
#include <linux/io.h>
-#include <mm/mmu_decl.h>
-
#include <asm/system.h>
#include <asm/atomic.h>
#include <asm/pci-bridge.h>
@@ -44,6 +42,7 @@
#endif
#ifdef CONFIG_PCI
+extern unsigned long total_memory;
int ppc4xx_exclude_device(struct pci_controller *hose, u_char bus,
u_char devfn)
@@ -53,21 +52,6 @@ int ppc4xx_exclude_device(struct pci_controller *hose, u_char bus,
return PCIBIOS_SUCCESSFUL;
}
-inline void pci_writel(void *pci_reg_base, u32 offset, unsigned int val)
-{
- writel(val, pci_reg_base + offset);
-}
-
-inline void pci_cfg_out(void *cfg, u32 offset, unsigned int value)
-{
- out_le32((void *)((u32) cfg + offset), value);
-}
-
-inline u32 pci_cfg_in(void *cfg, u32 offset)
-{
- return in_le32((void *)((u32) cfg + offset));
-}
-
static void __init ppc4xx_setup_pci(struct pci_controller *hose,
void *pci_reg_base, void *pci_cfg_base)
{
diff --git a/arch/powerpc/platforms/44x/ppc4xx-usb.c b/arch/powerpc/platforms/44x/ppc4xx-usb.c
index 1b07689..87e87e6 100644
--- a/arch/powerpc/platforms/44x/ppc4xx-usb.c
+++ b/arch/powerpc/platforms/44x/ppc4xx-usb.c
@@ -25,8 +25,6 @@
#include <linux/module.h>
#include <linux/io.h>
-#include <mm/mmu_decl.h>
-
#include <asm/system.h>
#include <asm/atomic.h>
#include <asm/prom.h>
^ permalink raw reply related
* Re: [PATCH 12/24] powerpc: 4xx PLB to PCI Express support
From: Stefan Roese @ 2007-12-02 22:01 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1196627621.13230.156.camel@pasglop>
On Sunday 02 December 2007, Benjamin Herrenschmidt wrote:
> > So before digging into this deeper, I wanted to check if you don't
> > have a
> > slightly "better" version which passed your tests with the sky2 PCIe
> > card.
>
> Yup, looks I forgot a quilt ref or something. I'll check. I'll also give
> port 1 and 2 a go (after fixing the DT).
>
> I also want to change the config space code to use some fixmap type
> direct mapping/unmapping to remove bus number limitations as soon as
> Kumar has implemented the fixmap stuff, since he seems to be working on
> it now.
Great, thanks.
Best regards,
Stefan
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-12-02 23:12 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
There are two commits there; one reverts a patch which was causing
some machines to fail to come back up when rebooting, and the other
only touches a couple of defconfigs.
Thanks,
Paul.
arch/powerpc/kernel/rtas.c | 12 ++++++------
arch/powerpc/platforms/pseries/setup.c | 3 +--
arch/ppc/configs/ml300_defconfig | 2 +-
arch/ppc/configs/ml403_defconfig | 2 +-
include/asm-powerpc/rtas.h | 3 +--
5 files changed, 10 insertions(+), 12 deletions(-)
Grant Likely (1):
[POWERPC] Remove xmon from ml300 and ml403 defconfig in arch/ppc
Paul Mackerras (1):
Revert "[POWERPC] Fix RTAS os-term usage on kernel panic"
^ permalink raw reply
* Re: [PATCH 0/3] OF-platform PATA driver
From: Arnd Bergmann @ 2007-12-02 23:40 UTC (permalink / raw)
To: Olof Johansson
Cc: linuxppc-dev, Anton Vorontsov, Paul Mundt, Jeff Garzik, linux-ide
In-Reply-To: <20071202154539.GA12415@lixom.net>
On Sunday 02 December 2007, Olof Johansson wrote:
> Yes, I agree with Sergei: I don't think the pio/ata mode belongs there,
> "ata-generic" (or "generic-ata") sounds good to me. If firmwares want to
> specify pata/sata stuff as more specific compatible fields, then they are
> free to, but the driver shouldn't depend on it as long as "ata-generic"
> is in the list.
Yes, that makes sense. Let me just make it clear that I no longer think
we should have the PIO mode or the ATA level in the compatible property.
The PIO modes should really have their own property, if any, and the ATA
standard would need to be a property of the attached device, not a property
of the controller.
I can see a point in listing the ATA devices themselves in the device tree,
but it's probably not really worth it for the fdt setup, since they
can easily be probed at runtime.
> I will need to add a compatible field to it myself (our firmware uses
> "electra-ide") + some minor changes, but I will do that on top of this
> patch once it goes in since it involves removing the old code from
> arch/powerpc/platforms/pasemi.
I'd suggest to also have electra-ide hardcoded in the driver alongside
ata-generic, as a special case for backwards compatibility.
Arnd <><
^ permalink raw reply
* Re: [PATCH 0/3] OF-platform PATA driver
From: Olof Johansson @ 2007-12-02 23:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, Anton Vorontsov, Paul Mundt, Jeff Garzik, linux-ide
In-Reply-To: <200712030040.22701.arnd@arndb.de>
On Mon, Dec 03, 2007 at 12:40:21AM +0100, Arnd Bergmann wrote:
> On Sunday 02 December 2007, Olof Johansson wrote:
>
> > Yes, I agree with Sergei: I don't think the pio/ata mode belongs there,
> > "ata-generic" (or "generic-ata") sounds good to me. If firmwares want to
> > specify pata/sata stuff as more specific compatible fields, then they are
> > free to, but the driver shouldn't depend on it as long as "ata-generic"
> > is in the list.
>
> Yes, that makes sense. Let me just make it clear that I no longer think
> we should have the PIO mode or the ATA level in the compatible property.
> The PIO modes should really have their own property, if any, and the ATA
> standard would need to be a property of the attached device, not a property
> of the controller.
Right. And configuring PIO modes is something quite hardware specific,
which defeats the purpose of having a "generic" driver as a catch-all
for "simple" configs in the first place. If the hardware needs (much)
tuning it probably makes more sense to do it as a separate driver.
> I can see a point in listing the ATA devices themselves in the device tree,
> but it's probably not really worth it for the fdt setup, since they
> can easily be probed at runtime.
If the firmware probes them and/or knows about them. It's the kind of
thing that can change quite often. We don't list USB devices under the usb
controllers either, since they're quite volatile and the device tree is
(fairly) static on the DTS-based platforms.
> > I will need to add a compatible field to it myself (our firmware uses
> > "electra-ide") + some minor changes, but I will do that on top of this
> > patch once it goes in since it involves removing the old code from
> > arch/powerpc/platforms/pasemi.
>
> I'd suggest to also have electra-ide hardcoded in the driver alongside
> ata-generic, as a special case for backwards compatibility.
Yep, that's my plan, I'll do that when I move it over.
-Olof
^ permalink raw reply
* Re: Please pull powerpc.git merge branch
From: Josh Boyer @ 2007-12-03 0:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18259.15345.627820.551644@cargo.ozlabs.ibm.com>
On Mon, 3 Dec 2007 10:12:49 +1100
Paul Mackerras <paulus@samba.org> wrote:
> Linus,
>
> Please do
>
> git pull \
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
>
> There are two commits there; one reverts a patch which was causing
> some machines to fail to come back up when rebooting, and the other
> only touches a couple of defconfigs.
>
> Thanks,
> Paul.
>
> arch/powerpc/kernel/rtas.c | 12 ++++++------
> arch/powerpc/platforms/pseries/setup.c | 3 +--
> arch/ppc/configs/ml300_defconfig | 2 +-
> arch/ppc/configs/ml403_defconfig | 2 +-
> include/asm-powerpc/rtas.h | 3 +--
> 5 files changed, 10 insertions(+), 12 deletions(-)
>
> Grant Likely (1):
> [POWERPC] Remove xmon from ml300 and ml403 defconfig in arch/ppc
Thanks Paul. I had this one queued for you to pull, but you beat me to
it.
josh
^ permalink raw reply
* Re: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
From: David Gibson @ 2007-12-03 0:48 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: Jon Loeliger, microblaze-uclinux, Michal Simek, linuxppc-dev, git
In-Reply-To: <20071126214459.627E7AB004D@mail132-cpk.bigfish.com>
On Mon, Nov 26, 2007 at 01:44:02PM -0800, Stephen Neuendorffer wrote:
[snip]
> > > reg = < 81c00000 40 >;
> >
> > If these registers are addressable, then the parent needs a
> > 'ranges' property.
>
> I thought ranges weren't necessary in a 1:1 mapping?
You were misinformed. If there is no ranges property, the child nodes
are not directly addressable from the bus above. If the ranges
property is present, but empty, then there is an identity mapping
between parent and child bus addresses. So you probably want to add
ranges;
to the parent node.
--
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
* Re: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
From: David Gibson @ 2007-12-03 0:55 UTC (permalink / raw)
To: Grant Likely
Cc: Jon Loeliger, microblaze-uclinux, Michal Simek, linuxppc-dev, git
In-Reply-To: <fa686aa40711251447t57f96dd4iba51d68e1c9a9c5c@mail.gmail.com>
On Sun, Nov 25, 2007 at 03:47:12PM -0700, Grant Likely wrote:
> On 11/24/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
[snip]
> > So: the mpmc generates a 'memory' node, corresponding to it's memory
> > interface. It also gets a separate entry which contains the (optional, not
> > present in this example) slave management interface (for ECC and performance
> > information), and any sdma ports. In this case, this node is mpmc@90000000,
> > because there is no management interface. If a management interface was
> > present, then it would be @ the management address.
>
> I don't think this is right; but I'm not sure. I don't know what the
> best naming convention is for the case of no management interface, but
> mpmc@90000000 doesn't feel right.
>
> Segher, David; what's your opinion?
If a node is present, but has no reg property, then it should not have
a unit address either. AFAICT what you're doing here is having one
node to represent the actual memory space (/memory@XXX, as it should
be) and another to represent the memory controller's control
interface. That's reasonable, but the unit address of the control
interface should be the address of the control registers, not the
address of the memory. If there is no control interface, there should
be no node for it at all.
[snip]
> > The temac works similarly, although the temac itself doesn't have a slave
> > interface, so no compatible node for it. The sub nodes get the compatible
> > string for the ll_temac driver. In this case, there is only one temac port
> > active. Some of the parameters are specific to port 0, in which case the
> > parameter names (e.g. phyaddr) are generated by stripping off the complete
> > C_TEMAC0 prefix. Other parameters (e.g. phy-type) are common to both sub
> > nodes, but are duplicated to make it easier for the driver to get the
> > information out. At runtime, the driver has to follow the llink-connected
> > path to find what it is connected to, and use the dma code, or the fifo
> > code.
> >
> > the xps-ll-fifo structure is a bit simpler, with llink-connected pointing
> > to the fifo, which looks like a 'normal' peripheral.
> >
> > Points for comment:
> > 1) I don't like the "PIM3" label, which is artificial (i.e. it doesn't
> > correspond to a name in the .mhs) and not guaranteed to be unique. However,
> > in the BSP generator it seems awkward to generate path references easily in
> > a single pass. What I'd might prefer is:
> > DDR2_SDRAM: mpmc@90000000 {
> > sdma@3 {
> >
> > and refer to the sdma port using something like <&DDR2_SDRAM/sdma@3>, but I
> > don't think you can do that in dtc?
>
> If not, it is possible to extend the dtc syntax. Jon, David? Thoughts?
&label/relative/path is not currently allowable in dtc. I suppose
it's possible to add it, but there are complications. I'm already
making some patches to deal with lexical ambiguities in the
&/full/path syntax, and the new syntax would make things more
complicated to deal with. I'll think about it.
--
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
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
From: David Gibson @ 2007-12-03 1:50 UTC (permalink / raw)
To: Andrei Dolnikov; +Cc: linuxppc-dev
In-Reply-To: <20071129152836.GB13751@ru.mvista.com>
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
* Re: [PATCH] Add IPIC MSI interrupt support
From: David Gibson @ 2007-12-03 1:52 UTC (permalink / raw)
To: Li Li; +Cc: linuxppc-dev, Kumar Gala
In-Reply-To: <1196394519.29683.8.camel@Guyver>
On Fri, Nov 30, 2007 at 11:48:39AM +0800, Li Li wrote:
> The IPIC MSI is introduced on MPC837x chip.
> Implements the IPIC MSI as two level interrupt controller.
>
> Signed-off-by: Tony Li <tony.li@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8377_mds.dts | 14 ++
> arch/powerpc/boot/dts/mpc8378_mds.dts | 14 ++
> arch/powerpc/boot/dts/mpc8379_mds.dts | 14 ++
> arch/powerpc/platforms/83xx/Kconfig | 6 +
> arch/powerpc/platforms/83xx/mpc837x_mds.c | 11 +
> arch/powerpc/sysdev/Makefile | 1 +
> arch/powerpc/sysdev/ipic_msi.c | 359 +++++++++++++++++++++++++++++
> include/asm-powerpc/ipic_msi.h | 54 +++++
> 8 files changed, 473 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/sysdev/ipic_msi.c
> create mode 100644 include/asm-powerpc/ipic_msi.h
>
> diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts b/arch/powerpc/boot/dts/mpc8377_mds.dts
> index 1f7819e..1068fe2 100644
> --- a/arch/powerpc/boot/dts/mpc8377_mds.dts
> +++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
> @@ -210,6 +210,20 @@
> #interrupt-cells = <2>;
> reg = <700 100>;
> };
> +
> + ipic-msi@7c0 {
> + compatible = "fsl,ipic-msi";
> + reg = <7c0 40>;
> + interrupts = < 43 8
> + 4 8
> + 51 8
> + 52 8
> + 56 8
> + 57 8
> + 58 8
> + 59 8 >;
> + interrupt-parent = < &ipic >;
> + };
I'm not sure why the MSI needs a device node of its own. What actual
piece of hardware is this representing?
--
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
* Re: [PATCH 2/2] powerpc: make 64K huge pages more reliable
From: David Gibson @ 2007-12-03 2:06 UTC (permalink / raw)
To: kniht; +Cc: linuxppc-dev, Linux Memory Management List
In-Reply-To: <474CF694.8040700@us.ibm.com>
On Tue, Nov 27, 2007 at 11:03:16PM -0600, Jon Tollefson wrote:
> This patch adds reliability to the 64K huge page option by making use of
> the PMD for 64K huge pages when base pages are 4k. So instead of a 12
> bit pte it would be 7 bit pmd and a 5 bit pte. The pgd and pud offsets
> would continue as 9 bits and 7 bits respectively. This will allow the
> pgtable to fit in one base page. This patch would have to be applied
> after part 1.
Hrm.. shouldn't we just ban 64K hugepages on a 64K base page size
setup? There's not a whole lot of point to it, after all...
--
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
* RE: [PATCH 1/3] [POWERPC] Add docs for Freescale 83xx SATA device tree nodes
From: Li Yang @ 2007-12-03 2:37 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711202312130.24220@blarg.am.freescale.net>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Wednesday, November 21, 2007 1:13 PM
> To: linuxppc-dev@ozlabs.org
> Cc: Segher Boessenkool; Li Yang
> Subject: [PATCH 1/3] [POWERPC] Add docs for Freescale 83xx=20
> SATA device tree nodes
>=20
> ---
> Documentation/powerpc/booting-without-of.txt | 23=20
> +++++++++++++++++++++++
> 1 files changed, 23 insertions(+), 0 deletions(-)
>=20
> diff --git a/Documentation/powerpc/booting-without-of.txt=20
> b/Documentation/powerpc/booting-without-of.txt
> index e9a3cb1..eb14dd5 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2514,6 +2514,29 @@ platforms are moved over to use the=20
> flattened-device-tree model.
> Requred properties:
> - current-speed : Baud rate of uartlite
>=20
> + * Freescale 8xxx/3.0 Gb/s SATA nodes
> +
> + SATA nodes are defined to describe on-chip Serial ATA=20
> controllers.
> + Each SATA port should have its own node.
> +
> + Required properties:
> + - compatible : compatible list, contains 2=20
> entries, first is
> + "fsl,sata-CHIP", where CHIP is the processor
Should be "fsl,CHIP-sata"
> + (mpc8315, mpc8379, etc.) and the second is
> + "fsl,sata-pq2pro"
Why not use "pq2pro-sata" to be consistent with the CHIP version?
> + - interrupts : <interrupt mapping for SATA IRQ>
> + - interrupt-parent : optional, if needed for interrupt mapping
> + - reg : <registers mapping>
> +
> + Example:
> +
> + sata@19000 {
> + compatible =3D "fsl,mpc8315-sata", "fsl,sata-pq2pro;
Quotation mark missing.
- Leo
^ permalink raw reply
* Re: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
From: Grant Likely @ 2007-12-03 2:47 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: Jon Loeliger, microblaze-uclinux, Michal Simek, linuxppc-dev, git,
David Gibson
In-Reply-To: <20071126214459.627E7AB004D@mail132-cpk.bigfish.com>
Bah; I wrote this email about a week ago, but never sent it. Sorry.
g.
On 11/26/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
> I've pushed the current state up to
> git://git.xilinx.com/gen-mhs-devtree.git for your perusing. Comments
> below.
>
> > -----Original Message-----
> > From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On
> > Behalf Of Grant Likely
> > Sent: Sunday, November 25, 2007 2:47 PM
> > To: Stephen Neuendorffer; Segher Boessenkool; David Gibson;
> > Jon Loeliger
> > Cc: microblaze-uclinux@itee.uq.edu.au;
> > linuxppc-dev@ozlabs.org; Michal Simek; git
> > Subject: Re: Xilinx EDK BSP generation of device trees for
> > microblaze and PowerPC
> >
> > On 11/24/07, Stephen Neuendorffer
> > <stephen.neuendorffer@xilinx.com> wrote:
> > >
> >
> > Thanks for all this work; comments below.
> >
> > >
> > > Here's what I've gotten so far:
> > >
> > > Hard_Ethernet_MAC: xps-ll-temac@81c00000 {
> > > #address-cells = <1>;
> > > #size-cells = <1>;
> > > network@81c00000 {
> > > compatible =
> > "xlnx,xps-ll-temac-1.00.a",
> > > "xlnx,xps-ll-temac";
> >
> > Drop "xlnx,xps-ll-temac"; it's 100% made up. This should be simply:
> > compatible = "xlnx,xps-ll-temac-1.00.a" for version 1.00.a and
> > compatible =
> > "xlnx,xps-ll-temac-<version>","xlnx,xps-ll-temac-1.00.a" for a future
> > version if it maintains register level compatibility.
> >
> > "xlnx,xps-ll-temac" is far to ambiguous.
>
> What if it was: compatible = "xlnx,xps-ll-temac-1.00.a",
> "xlnx,xps-ll-temac-1"?
Here's what I've learned: There is no such thing as a perfect device
tree. Either hardware bugs will be discovered at a later date which
make compatible inaccurate, or a better understanding of the device
will come along which will change the understood best practices for
describing the device.
My opinion is the best strategy against claiming something that's not
true, or won't be true in the fucture, is to strive for uniqueness and
describe only what you are certain of. Be conservative instead of
liberal in the compatible case; ie. it's easier to teach the driver
about other versions it can bind against than it is to teach it about
exceptions to certain versions of the hardware (when binding).
In this particular case the problem still stands that the VHDL
engineer may make a non backward compatible change in version
xlnx,xps-ll-temac-1.00.c or -1.03.c. You just don't know until it
happens. Stick with what is known and don't try to extrapolate to a
'generic' version when there is no guarantee that it will remain
generic.
When sticking with real version numbers, it is quite safe to claim
compatibility with an older version number because you've probably
tested it; something which isn't so safe when you attempt to make up
generic versions.
>
> Basically, I don't want to be responsible for declaring what versions of
> IP are backward compatible with ll-temac-1.00.a, and I think it's bad
> software design to put that list into the dts generator anyway. In
> theory, at least, all ip with the same major version should be
> compatible.
Yes, but at the point of releasing, you've probably tested it so the
risk is very low.
>
> > > interrupt-parent = <&xps_intc_0>;
> > > interrupts = < 3 0 >;
> > > llink-connected = <&PIM3>;
> >
> > What's this property for?
>
> So that the ll_temac knows whether to use dma or fifo code and where the
> dma or fifo control/interrupts are.
>
> >
> > > reg = < 81c00000 40 >;
> >
> > If these registers are addressable, then the parent needs a
> > 'ranges' property.
>
> I thought ranges weren't necessary in a 1:1 mapping?
At the very least there needs to be an empty 'ranges' property in
order for it to work
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PPC BOOT] Create otheros.bld next to specified output file, not in $object directory.
From: David Woodhouse @ 2007-12-03 2:48 UTC (permalink / raw)
To: linuxppc-dev
The bootwrapper script currently generates an 'otheros.bld' file in
addition to the file specified by the -o option, when asked to build a
wrapper for PS3.
It should do that in the same directory as the output, not the directory
where the wrapper objects are kept (which might potentially not be
writable when the script runs).
Arguably, the 'otheros.bld' ought to be created with the filename
specified as the -o argument. But that's a more intrusive change.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -287,8 +289,6 @@ ps3)
overlay_dest="256"
overlay_size="256"
- rm -f "$object/otheros.bld"
-
${CROSS}objcopy -O binary "$ofile" "$ofile.bin"
dd if="$ofile.bin" of="$ofile.bin" conv=notrunc \
@@ -299,6 +299,8 @@ ps3)
skip=$system_reset_overlay seek=$overlay_dest \
count=$overlay_size bs=1
- gzip --force -9 --stdout "$ofile.bin" > "$object/otheros.bld"
+ odir="$(dirname "$ofile.bin")"
+ rm -f "$odir/otheros.bld"
+ gzip --force -9 --stdout "$ofile.bin" > "$odir/otheros.bld"
;;
esac
--
dwmw2
^ permalink raw reply
* [PPC BOOT] Find device-tree source file in default directory.
From: David Woodhouse @ 2007-12-03 2:49 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1196650083.13978.113.camel@pmac.infradead.org>
If a .dts file is given to the bootwrapper script without a full path
name, look in a sensible place for it.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -116,6 +118,9 @@ while [ "$#" -gt 0 ]; do
done
if [ -n "$dts" ]; then
+ if [ ! -r "$dts" -a -r "$object/dts/$dts" ]; then
+ dts="$object/dts/$dts"
+ fi
if [ -z "$dtb" ]; then
dtb="$platform.dtb"
fi
--
dwmw2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox