* RE: [PATCH] Adding PCI-E support for 460SX based redwood board.
From: Tirumala Reddy Marri @ 2009-12-10 2:22 UTC (permalink / raw)
To: tmarr, benh; +Cc: linuxppc-dev
In-Reply-To: <1259615732-20272-1-git-send-email-tmarr@amcc.com>
Testing and other information for this patch.
1. Kernel version: 2.6.32-rc6=20
2. Board: AMCC redwood validation board.
3. tests
a. Configured redwood boards PCI-E ports as root ports. And plugged
in 2 HBA sas cards with 8 drives each. XDD and IO =20
meter tests were ran. No issues found.
b. Configured redwood board PCI-E port as Endpoint and configured
second board as root complex. Boards were interconnected using PCI-E
cable. Then did lspci on root complex configured redwood board to see if
the endpoint can be scanned. Also using BDI I was able to do read and
writes to & from root complex as well as endpoint.
Regards,
Marri
-----Original Message-----
From: tmarr@amcc.com [mailto:tmarr@amcc.com]=20
Sent: Monday, November 30, 2009 1:16 PM
To: benh@kernel.crashing.org
Cc: linuxppc-dev@ozlabs.org; Tirumala Reddy Marri
Subject: [PATCH] Adding PCI-E support for 460SX based redwood board.
From: Tirumala Marri <tmarri@amcc.com>
This patch would add PCI-E support for AMCC 460SX processor based=20
redwood board.
Signed-off-by: Tirumala Marri <tmarri@amcc.com>
---
arch/powerpc/boot/dts/redwood.dts | 122
+++++++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/ppc4xx_pci.c | 119
++++++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/ppc4xx_pci.h | 58 +++++++++++++++++
3 files changed, 299 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/redwood.dts
b/arch/powerpc/boot/dts/redwood.dts
index ad402c4..9eeec28 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -233,6 +233,128 @@
has-inverted-stacr-oc;
has-new-stacr-staopc;
};
+ PCIE0: pciex@d00000000 {
+ device_type =3D "pci";
+ #interrupt-cells =3D <1>;
+ #size-cells =3D <2>;
+ #address-cells =3D <3>;
+ compatible =3D "ibm,plb-pciex-460sx",
"ibm,plb-pciex";
+ primary;
+ port =3D <0x0>; /* port number */
+ reg =3D <0x0000000d 0x00000000 0x20000000
/* Config space access */
+ 0x0000000c 0x10000000
0x00001000>; /* Registers */
+ dcr-reg =3D <0x100 0x020>;
+ sdr-base =3D <0x300>;
+
+ /* Outbound ranges, one memory and one
IO,
+ * later cannot be changed
+ */
+ ranges =3D <0x02000000 0x00000000
0x80000000 0x0000000e 0x00000000 0x00000000 0x80000000
+ 0x01000000 0x00000000
0x00000000 0x0000000f 0x80000000 0x00000000 0x00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges =3D <0x42000000 0x0 0x0 0x0 0x0
0x0 0x80000000>;
+
+ /* This drives busses 10 to 0x1f */
+ bus-range =3D <0x10 0x1f>;
+
+ /* Legacy interrupts (note the weird
polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * 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 0, so the
swizzling is 1:1
+ */
+ interrupt-map-mask =3D <0x0 0x0 0x0 0x7>;
+ interrupt-map =3D <
+ 0x0 0x0 0x0 0x1 &UIC3 0x0 0x4 /*
swizzled int A */
+ 0x0 0x0 0x0 0x2 &UIC3 0x1 0x4 /*
swizzled int B */
+ 0x0 0x0 0x0 0x3 &UIC3 0x2 0x4 /*
swizzled int C */
+ 0x0 0x0 0x0 0x4 &UIC3 0x3 0x4 /*
swizzled int D */>;
+ };
+
+ PCIE1: pciex@d20000000 {
+ device_type =3D "pci";
+ #interrupt-cells =3D <1>;
+ #size-cells =3D <2>;
+ #address-cells =3D <3>;
+ compatible =3D "ibm,plb-pciex-460sx",
"ibm,plb-pciex";
+ primary;
+ port =3D <0x1>; /* port number */
+ reg =3D <0x0000000d 0x20000000 0x20000000
/* Config space access */
+ 0x0000000c 0x10001000
0x00001000>; /* Registers */
+ dcr-reg =3D <0x120 0x020>;
+ sdr-base =3D <0x340>;
+
+ /* Outbound ranges, one memory and one
IO,
+ * later cannot be changed
+ */
+ ranges =3D <0x02000000 0x00000000
0x80000000 0x0000000e 0x80000000 0x00000000 0x80000000
+ 0x01000000 0x00000000
0x00000000 0x0000000f 0x80010000 0x00000000 0x00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges =3D <0x42000000 0x0 0x0 0x0 0x0
0x0 0x80000000>;
+
+ /* This drives busses 10 to 0x1f */
+ bus-range =3D <0x20 0x2f>;
+
+ /* Legacy interrupts (note the weird
polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * 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 0, so the
swizzling is 1:1
+ */
+ interrupt-map-mask =3D <0x0 0x0 0x0 0x7>;
+ interrupt-map =3D <
+ 0x0 0x0 0x0 0x1 &UIC3 0x4 0x4 /*
swizzled int A */
+ 0x0 0x0 0x0 0x2 &UIC3 0x5 0x4 /*
swizzled int B */
+ 0x0 0x0 0x0 0x3 &UIC3 0x6 0x4 /*
swizzled int C */
+ 0x0 0x0 0x0 0x4 &UIC3 0x7 0x4 /*
swizzled int D */>;
+ };
+
+ PCIE2: pciex@d40000000 {
+ device_type =3D "pci";
+ #interrupt-cells =3D <1>;
+ #size-cells =3D <2>;
+ #address-cells =3D <3>;
+ compatible =3D "ibm,plb-pciex-460sx",
"ibm,plb-pciex";
+ primary;
+ port =3D <0x2>; /* port number */
+ reg =3D <0x0000000d 0x40000000 0x20000000
/* Config space access */
+ 0x0000000c 0x10002000
0x00001000>; /* Registers */
+ dcr-reg =3D <0x140 0x020>;
+ sdr-base =3D <0x370>;
+
+ /* Outbound ranges, one memory and one
IO,
+ * later cannot be changed
+ */
+ ranges =3D <0x02000000 0x00000000
0x80000000 0x0000000f 0x00000000 0x00000000 0x80000000
+ 0x01000000 0x00000000
0x00000000 0x0000000f 0x80020000 0x00000000 0x00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges =3D <0x42000000 0x0 0x0 0x0 0x0
0x0 0x80000000>;
+
+ /* This drives busses 10 to 0x1f */
+ bus-range =3D <0x30 0x3f>;
+
+ /* Legacy interrupts (note the weird
polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * 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 0, so the
swizzling is 1:1
+ */
+ interrupt-map-mask =3D <0x0 0x0 0x0 0x7>;
+ interrupt-map =3D <
+ 0x0 0x0 0x0 0x1 &UIC3 0x8 0x4 /*
swizzled int A */
+ 0x0 0x0 0x0 0x2 &UIC3 0x9 0x4 /*
swizzled int B */
+ 0x0 0x0 0x0 0x3 &UIC3 0xa 0x4 /*
swizzled int C */
+ 0x0 0x0 0x0 0x4 &UIC3 0xb 0x4 /*
swizzled int D */>;
+ };
=20
};
=20
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c
b/arch/powerpc/sysdev/ppc4xx_pci.c
index 6ff9d71..64cd020 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -972,6 +972,123 @@ static struct ppc4xx_pciex_hwops
ppc460ex_pcie_hwops __initdata =3D
.setup_utl =3D ppc460ex_pciex_init_utl,
};
=20
+static int __init ppc460sx_pciex_core_init(struct device_node *np)
+{
+ /* HSS drive amplitude */
+ mtdcri(SDR0, PESDR0_460SX_HSSL0DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR0_460SX_HSSL1DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR0_460SX_HSSL2DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR0_460SX_HSSL3DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR0_460SX_HSSL4DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR0_460SX_HSSL5DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR0_460SX_HSSL6DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR0_460SX_HSSL7DAMP, 0xB9843211);
+
+ mtdcri(SDR0, PESDR1_460SX_HSSL0DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR1_460SX_HSSL1DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR1_460SX_HSSL2DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR1_460SX_HSSL3DAMP, 0xB9843211);
+
+ mtdcri(SDR0, PESDR2_460SX_HSSL0DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR2_460SX_HSSL1DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR2_460SX_HSSL2DAMP, 0xB9843211);
+ mtdcri(SDR0, PESDR2_460SX_HSSL3DAMP, 0xB9843211);
+
+ /* HSS TX pre-emphasis */
+ mtdcri(SDR0, PESDR0_460SX_HSSL0COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR0_460SX_HSSL1COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR0_460SX_HSSL2COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR0_460SX_HSSL3COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR0_460SX_HSSL4COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR0_460SX_HSSL5COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR0_460SX_HSSL6COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR0_460SX_HSSL7COEFA, 0xDCB98987);
+
+ mtdcri(SDR0, PESDR1_460SX_HSSL0COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR1_460SX_HSSL1COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR1_460SX_HSSL2COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR1_460SX_HSSL3COEFA, 0xDCB98987);
+
+ mtdcri(SDR0, PESDR2_460SX_HSSL0COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR2_460SX_HSSL1COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR2_460SX_HSSL2COEFA, 0xDCB98987);
+ mtdcri(SDR0, PESDR2_460SX_HSSL3COEFA, 0xDCB98987);
+
+ /* HSS TX calibration control */
+ mtdcri(SDR0, PESDR0_460SX_HSSL1CALDRV, 0x22222222);
+ mtdcri(SDR0, PESDR1_460SX_HSSL1CALDRV, 0x22220000);
+ mtdcri(SDR0, PESDR2_460SX_HSSL1CALDRV, 0x22220000);
+
+ /* HSS TX slew control */
+ mtdcri(SDR0, PESDR0_460SX_HSSSLEW, 0xFFFFFFFF);
+ mtdcri(SDR0, PESDR1_460SX_HSSSLEW, 0xFFFF0000);
+ mtdcri(SDR0, PESDR2_460SX_HSSSLEW, 0xFFFF0000);
+
+ udelay(100);
+
+ /* De-assert PLLRESET */
+ dcri_clrset(SDR0, PESDR0_PLLLCT2, 0x00000100, 0);
+
+ /* Reset DL, UTL, GPL before configuration */
+ mtdcri(SDR0, PESDR0_460SX_RCSSET,
+ PESDRx_RCSSET_RSTDL | PESDRx_RCSSET_RSTGU);
+ mtdcri(SDR0, PESDR1_460SX_RCSSET,
+ PESDRx_RCSSET_RSTDL | PESDRx_RCSSET_RSTGU);
+ mtdcri(SDR0, PESDR2_460SX_RCSSET,
+ PESDRx_RCSSET_RSTDL | PESDRx_RCSSET_RSTGU);
+
+ udelay(100);
+
+ /*
+ * If bifurcation is not enabled, u-boot would have disabled the
+ * third PCIe port
+ */
+ if (((mfdcri(SDR0, PESDR1_460SX_HSSCTLSET) & 0x00000001) =3D=3D
+ 0x00000001)) {
+ printk(KERN_INFO "PCI: PCIE bifurcation setup
successfully.\n");
+ printk(KERN_INFO "PCI: Total 3 PCIE ports are
present\n");
+ return 3;
+ }
+
+ printk(KERN_INFO "PCI: Total 2 PCIE ports are present\n");
+ return 2;
+}
+
+static int ppc460sx_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
+{
+
+ if (port->endpoint)
+ dcri_clrset(SDR0, port->sdr_base + PESDRn_UTLSET2,
+ 0x01000000, 0);
+ else
+ dcri_clrset(SDR0, port->sdr_base + PESDRn_UTLSET2,
+ 0, 0x01000000);
+
+ /*Gen-1*/
+ mtdcri(SDR0, port->sdr_base + PESDRn_460SX_RCEI, 0x08000000);
+
+ dcri_clrset(SDR0, port->sdr_base + PESDRn_RCSSET,
+ (PESDRx_RCSSET_RSTGU | PESDRx_RCSSET_RSTDL),
+ PESDRx_RCSSET_RSTPYN);
+
+ port->has_ibpre =3D 1;
+
+ return 0;
+}
+
+static int ppc460sx_pciex_init_utl(struct ppc4xx_pciex_port *port)
+{
+ /* Max 128 Bytes */
+ out_be32 (port->utl_base + PEUTL_PBBSZ, 0x00000000);
+ return 0;
+}
+
+static struct ppc4xx_pciex_hwops ppc460sx_pcie_hwops __initdata =3D {
+ .core_init =3D ppc460sx_pciex_core_init,
+ .port_init_hw =3D ppc460sx_pciex_init_port_hw,
+ .setup_utl =3D ppc460sx_pciex_init_utl,
+};
+
#endif /* CONFIG_44x */
=20
#ifdef CONFIG_40x
@@ -1087,6 +1204,8 @@ static int __init
ppc4xx_pciex_check_core_init(struct device_node *np)
}
if (of_device_is_compatible(np, "ibm,plb-pciex-460ex"))
ppc4xx_pciex_hwops =3D &ppc460ex_pcie_hwops;
+ if (of_device_is_compatible(np, "ibm,plb-pciex-460sx"))
+ ppc4xx_pciex_hwops =3D &ppc460sx_pcie_hwops;
#endif /* CONFIG_44x */
#ifdef CONFIG_40x
if (of_device_is_compatible(np, "ibm,plb-pciex-405ex"))
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.h
b/arch/powerpc/sysdev/ppc4xx_pci.h
index d04e40b..56d9e5d 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.h
+++ b/arch/powerpc/sysdev/ppc4xx_pci.h
@@ -324,6 +324,64 @@
#define PESDR0_460EX_IHS2 0x036D
=20
/*
+ * 460SX addtional DCRs
+ */
+#define PESDRn_460SX_RCEI 0x02
+
+#define PESDR0_460SX_HSSL0DAMP 0x320
+#define PESDR0_460SX_HSSL1DAMP 0x321
+#define PESDR0_460SX_HSSL2DAMP 0x322
+#define PESDR0_460SX_HSSL3DAMP 0x323
+#define PESDR0_460SX_HSSL4DAMP 0x324
+#define PESDR0_460SX_HSSL5DAMP 0x325
+#define PESDR0_460SX_HSSL6DAMP 0x326
+#define PESDR0_460SX_HSSL7DAMP 0x327
+
+#define PESDR1_460SX_HSSL0DAMP 0x354
+#define PESDR1_460SX_HSSL1DAMP 0x355
+#define PESDR1_460SX_HSSL2DAMP 0x356
+#define PESDR1_460SX_HSSL3DAMP 0x357
+
+#define PESDR2_460SX_HSSL0DAMP 0x384
+#define PESDR2_460SX_HSSL1DAMP 0x385
+#define PESDR2_460SX_HSSL2DAMP 0x386
+#define PESDR2_460SX_HSSL3DAMP 0x387
+
+#define PESDR0_460SX_HSSL0COEFA 0x328
+#define PESDR0_460SX_HSSL1COEFA 0x329
+#define PESDR0_460SX_HSSL2COEFA 0x32A
+#define PESDR0_460SX_HSSL3COEFA 0x32B
+#define PESDR0_460SX_HSSL4COEFA 0x32C
+#define PESDR0_460SX_HSSL5COEFA 0x32D
+#define PESDR0_460SX_HSSL6COEFA 0x32E
+#define PESDR0_460SX_HSSL7COEFA 0x32F
+
+#define PESDR1_460SX_HSSL0COEFA 0x358
+#define PESDR1_460SX_HSSL1COEFA 0x359
+#define PESDR1_460SX_HSSL2COEFA 0x35A
+#define PESDR1_460SX_HSSL3COEFA 0x35B
+
+#define PESDR2_460SX_HSSL0COEFA 0x388
+#define PESDR2_460SX_HSSL1COEFA 0x389
+#define PESDR2_460SX_HSSL2COEFA 0x38A
+#define PESDR2_460SX_HSSL3COEFA 0x38B
+
+#define PESDR0_460SX_HSSL1CALDRV 0x339
+#define PESDR1_460SX_HSSL1CALDRV 0x361
+#define PESDR2_460SX_HSSL1CALDRV 0x391
+
+#define PESDR0_460SX_HSSSLEW 0x338
+#define PESDR1_460SX_HSSSLEW 0x360
+#define PESDR2_460SX_HSSSLEW 0x390
+
+#define PESDR0_460SX_HSSCTLSET 0x31E
+#define PESDR1_460SX_HSSCTLSET 0x352
+#define PESDR2_460SX_HSSCTLSET 0x382
+
+#define PESDR0_460SX_RCSSET 0x304
+#define PESDR1_460SX_RCSSET 0x344
+#define PESDR2_460SX_RCSSET 0x374
+/*
* Of the above, some are common offsets from the base
*/
#define PESDRn_UTLSET1 0x00
--=20
1.6.3.3
^ permalink raw reply related
* Re: Deprecating of_platform, the path from here...
From: Benjamin Herrenschmidt @ 2009-12-10 1:45 UTC (permalink / raw)
To: David Miller; +Cc: devicetree-discuss, linuxppc-dev, paulus, jk
In-Reply-To: <20091209.161550.168794100.davem@davemloft.net>
On Wed, 2009-12-09 at 16:15 -0800, David Miller wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Wed, 9 Dec 2009 15:06:29 -0700
>
> > 1) of_platform will be deprecated in preference of the platform bus.
>
> What a shame, it's one of the cleanest driver probing models
> in the tree.
It is indeed. However, I'm not 100% convinced it requires keeping a
separate bus & device type, if we can make the base platform_device
benefit from it transparently.
So here's a (long) email summarizing my thoughts in those matters. I
would really appreciate if you took the time to read it through, think
it through and then speak your mind. As you will notice, I'm not myself
completely sold on the way to go there myself and some of your ideas do
tempt me very much indeed :-)
First let's clearly separate the two different aspects of this
discussion for the sake of lurkers :-) One is the probing & matching
mechanism. The other one is how the driver retrieves it's various
parameters, either from a device node, or from pdata. From our IRC
discussion you have valid points on both aspect of the argument so I'll
try to discuss this here separately and we'll see what others think too.
First the probing because that's the real important issue, I believe the
other one is mostly academic and can be dealt on a per driver basis
(I'll discuss it later too).
I'm not totally sold on the idea of the table that Grant proposed. I
think I proposed it initially in a discussion we had on IRC as one
possible option and in fact it was suggested by Paulus so don't
completely blame Grant for it though. It does mean that either platform
code or core code will have some kind of big table that associates a
whole pile of of_device_id with a platform device name. It somewhat
sucks when I think more about it and it does feel like a step backward
from of_platform_device.
If we could make platform_driver grow an of_device_id match list it
would be indeed nicer. Of course you'll reply to that "let's just use
of_platform" instead :-)
I would then argue that I don't like having two different bus types,
platform and of_platform for "generic platform" devices that aren't
typed on a bus type. There's a lot of existing "platform device" and it
would be quite hard to convert them all. Especially since a lot of them
are used today on archs that don't have device trees and may never grow
one.
IE. I believe it's going to be an easier path to grow platform_device
into something that has the of_device probing functionality rather than
turn everything into of_platform. (I'm not talking here about the pdata
and retrieval of informations from the tree, this is the second part of
the discussion, discussed below).
The main problem with moving existing platform_device to of_platform is
how do we deal with archs that don't have the device-tree infrastructure
and use those drivers today ?
We could I suppose create a helper that looks a lot like the current
platform device creation one, which would create an of_platform device
instead, along with a struct device_node attached (which isn't part of a
tree) to it, and create a single "compatible" property whose content is
the platform data name.
But that means that for every driver we want to be able to use a
device-tree probing for, we would have to convert all archs & platforms
that may instanciate it to use the new helpers, in addition to replacing
whatever pdata they have statically stored into a device node (see the
second part of the discussion).
It's possible I suppose. I just feel that it's going to be a tougher
sell to the rest of the world.
There's one nit to be careful of. Some drivers (sadly) have the fact
that they appear under /sys/bus/platform/ as a userspace ABI thingy. Sad
but a fact. This is one of the reasons why rather than actually
converting to of_platform I'd rather find a way to add the of_device_id
match mechanism to the existing platform_device and deprecate the pdata
over time.
It will also provide with an easier transition. Basically transform
platform_device into of_platform_device by first adding the missing bits
and -then- trimming the crufty remains.
Now let's move to the second part of the discussion which is the
retrieval of various configuration informations by the driver.
Here too, our model is better, I think there's little argument there. A
named list of properties is just so much more flexible than a statically
data structure that has to be in sync between the driver and all
platforms using it leaves little room for improvement or adding platform
specific attributes which some drivers might need, etc...
Grant proposal is to have drivers create the pdata from the device-tree.
This is something I believe we both disagree with, though you more
vehemently than me I suppose :-)
There are various things at play here:
First, let me make it clear that imho, the device type
(of_platform_device vs. platform_device) is irrelevant to that aspect of
the problem since nowadays we have the ability to carry a device node
pointer in any descendant of struct device (and we use that heavily for
devices using specific bus types already).
If you take an existing platform driver that you want to use on a
device-tree enabled platform (other than just creating it and pdata from
arch code which we all agree sucks), the two choices have different
consequences:
In one case, converting to of_platform_device, you pretty much _have_ to
get rid of pdata, and convert the driver into using of_get_property()
instead. This is probably not a bad thing in the long run, except that
this means you also -have- to convert all platforms in all archs that
use that specific platform driver to also generate a device node
(possibly statically in many cases).
This can be a lot of code churn deep into platform code for things like
ARM which can be pretty nasty, for which none of us have any way to test
on the relevant hardware. Other arch people will (maybe rightfully so)
protest especially if they have no intent to use the device-tree stuff
in their architecture or not yet anyways. And that for each platform
driver involved.
On the other case, converting to platform_device, adding the device
node, we have the ability to do an easier transition and easier to sell.
yes, we do take the risk of getting in that limbo land where drivers end
up forever in the "transition" state though. That's a con of this
approach, I do admit.
I don't agree with grant idea however that just converting the content
of the device node into properties is the way to go.
I do prefer your proposed approach (from our IRC discussion) which is
instead to allocate a struct device-node, convert pdata into properties,
and modify the drier to use these properties.
The main difference thus between the two type of conversions (convert to
of_platform vs convert to platform) is that in the first case, you have
to convert the driver to use properties -and- convert all platforms in
all archs including gory ARM cell phone stuff you really don't want to
go anywhere near. In the second case, you still convert the driver to
use properties natively, but you keep a "wart" to turn pdata into a
device-node -inside the driver-, protected by a CONFIG option maybe, so
that those archs can be left alone until it becomes so obvious to
everybody what approach is better that they'll end up being converted
too and the wart can go.
I believe the second approach, while less "clean" in the absolute is a
more realistic path to take.
Now, orthogonally to that, I do believe it's still nice to provide a way
to statically lay out a device node in platform code, to allow archs
that don't otherwise have the device-tree to replace pdata with
something nicer and get rid of the wart quicker.
We could either find a way with macros to layout an actual struct
device_node statically along with all the properties etc... but that
sounds a tad hard.
We could have something that convert an entirely ASCII representation
into a struct device_node, but that would be akin of having dtc in the
kernel, might be a bit bloated no ? Though it could be made simpler and
more restrictive.
Or we could find an in-between .. .A different struct type that is more
suitable for being laid out statically (a name, a type, and an enum of
structs for various property "types", ie, strings, words, bytes, ...)
with a little helper function that conver that into a device node at
runtime ?
What do you think ?
Cheers,
Ben.
^ permalink raw reply
* Re: Deprecating of_platform, the path from here...
From: David Miller @ 2009-12-10 0:21 UTC (permalink / raw)
To: grant.likely; +Cc: devicetree-discuss, linuxppc-dev, paulus, jk
In-Reply-To: <20091209.161550.168794100.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 09 Dec 2009 16:15:50 -0800 (PST)
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Wed, 9 Dec 2009 15:06:29 -0700
>
>> 1) of_platform will be deprecated in preference of the platform bus.
>
> What a shame, it's one of the cleanest driver probing models
> in the tree.
And BTW, have you folks who "decided" this considered at all the fact
that it is much easier to describe represent platform devices using
of OF devices rather than the other way around?
The platform device pdata mechanism requires data structure changes
and is not dynamically extensible, whereas OF devices are
fundamentally so.
I don't like the idea to get rid of of_platform devices at all.
OF devices are really clean, much like netlink messages, where
arbitrary named attributes can be added or removed without any data
structure changes at all.
^ permalink raw reply
* Re: Deprecating of_platform, the path from here...
From: David Miller @ 2009-12-10 0:15 UTC (permalink / raw)
To: grant.likely; +Cc: devicetree-discuss, linuxppc-dev, paulus, jk
In-Reply-To: <fa686aa40912091406i2ef4e1b2u25c9f46b20786245@mail.gmail.com>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Wed, 9 Dec 2009 15:06:29 -0700
> 1) of_platform will be deprecated in preference of the platform bus.
What a shame, it's one of the cleanest driver probing models
in the tree.
^ permalink raw reply
* Re: ucc_geth: Fix the wrong the Rx/Tx FIFO size
From: Anton Vorontsov @ 2009-12-09 23:00 UTC (permalink / raw)
To: Dave Liu; +Cc: linuxppc-dev, David Miller, netdev
In-Reply-To: <1259309803-5474-1-git-send-email-daveliu@freescale.com>
On Fri, Nov 27, 2009 at 04:16:43PM +0800, Dave Liu wrote:
> current the Rx/Tx FIFO size settings cause problem
> when four UEC ethernets work simultaneously.
>
> eg: GETH1, UEM-J15, GETH2, UEC-J5 on 8569MDS board
>
> $ ifconfig eth0 10.193.20.166
> $ ifconfig eth1 10.193.20.167
> $ ifconfig eth2 10.193.20.168
> then
> $ ifconfig eth3 10.193.20.169
>
> The fourth ethernet will cause all of interface broken,
> you cann't ping successfully any more.
> The patch fix this issue for MPC8569 Rev1.0 and Rev2.0
>
> Signed-off-by: Dave Liu <daveliu@freescale.com>
Acked-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Thanks Dave! I see that the new values actually match the QEIWRM
spec (except UTFS... spec recommends 2048, but it also says that
it might differ for different memory setups, though that's a
separate issue).
And FWIW, I did some quick netperf tests on MPC8360, and the
patch doesn't cause any problems.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 6/8] Use proper types for do_div
From: Mark Wielaard @ 2009-12-09 22:47 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, systemtap
In-Reply-To: <20091209160941.GA8539@oksana.dev.rtsoft.ru>
Hi Anton,
On Wed, 2009-12-09 at 19:09 +0300, Anton Vorontsov wrote:
> I think this should be fixed by this patch:
>
> http://sourceware.org/ml/systemtap/2009-q4/msg00800.html
>
> Can you try it? With this patch I see no new regressions on x86_64.
Yes, that fixes everything. Sorry I didn't see that patch earlier. I see
Wenji also tested it already. I have pushed it for you.
Thanks,
Mark
^ permalink raw reply
* Re: dts file for MPC8343EA - cuImage doesn't boot , but uImage with DTS shows serial output
From: Junita Ajith @ 2009-12-09 22:08 UTC (permalink / raw)
To: Lee, Eric; +Cc: Linuxppc-dev@lists.ozlabs.org
In-Reply-To: <507B57E36B7C3A48BD1B90EFA80A782E5372EE795D@GVW0433EXB.americas.hpqcorp.net>
[-- Attachment #1: Type: text/plain, Size: 19528 bytes --]
Eric,
1. I did try building with MDS configuration.
2. Removed BCSR section
3. Set u-boot environment variable.
The code boots up in the MPC8349 reference platform and not in the custom
board.
Also I am wondering why the cuImage would not give out any serial output
even, whereas I do see serial out with DTB file passed from u-boot?!!
Screen-shot:
==========
Bytes transferred = 12288 (3000 hex)
SC3000> bootm 0x2000000 - 0x3000000
## Booting image at 02000000 ...
Image Name: Linux-2.6.27.18
Created: 2009-12-09 21:57:32 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1464261 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x0FF9BD48 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF25
bd address = 0x0FF9BFC4
memstart = 0x00000000
memsize = 0x10000000
flashstart = 0xFE000000
flashsize = 0x00080000
flashoffset = 0x00034000
sramstart = 0x00000000
sramsize = 0x00000000
bootflags = 0x00000001
intfreq = 399.999 MHz
busfreq = 266.666 MHz
ethaddr = 00:E0:0C:00:8C:01
IP addr = 192.168.201.199
baudrate = 115200 bps
Skipping initrd
Booting using the fdt at 0x3000000
No initrd
## device tree at 0x03000000 ... 0x03002FFF (len=12288=0x3000)
Loading Device Tree to 007fc000, end 007fefff ... OK
Updating property '/soc8349@e0000000/ethernet@24000/mac-address' = 00 e0 0c
00 81Updating property '/soc8349@e0000000/ethernet@24000/local-mac-address'
= 00 e0 01Updating property 'timebase-frequency' = 03 f9 40 aa
Updating property 'bus-frequency' = 0f e5 02 a8
Updating property 'clock-frequency' = 17 d7 83 fc
Updating property 'bus-frequency' = 0f e5 02 a8
Updating property 'clock-frequency' = 0f e5 02 a8
## Transferring control to Linux (at address 00000000) ...
Using MPC834x MDS machine description
Linux version 2.6.27.18 (root@localhost.localdomain) (gcc version 4.1.2) #4
Wed D9Found legacy serial port 0 for /soc8349@e0000000/serial@4500
mem=e0004500, taddr=e0004500, irq=0, clk=266666664, speed=0
Found legacy serial port 1 for /soc8349@e0000000/serial@4600
mem=e0004600, taddr=e0004600, irq=0, clk=266666664, speed=0
console [udbg0] enabled
setup_arch: bootmem
mpc834x_mds_setup_arch()
Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bus number:
0->0
PCI host bridge /pci@e0008500 (primary) ranges:
MEM 0x0000000090000000..0x000000009fffffff -> 0x0000000090000000
MEM 0x0000000080000000..0x000000008fffffff -> 0x0000000080000000 Prefetch
IO 0x00000000e2000000..0x00000000e20fffff -> 0x0000000000000000
Found MPC83xx PCI host bridge at 0x00000000e0008600. Firmware bus number:
0->0
PCI host bridge /pci@e0008600 ranges:
MEM 0x00000000b0000000..0x00000000bfffffff -> 0x00000000b0000000
MEM 0x00000000a0000000..0x00000000afffffff -> 0x00000000a0000000 Prefetch
IO 0x00000000e2100000..0x00000000e21fffff -> 0x0000000000000000
arch: exit
Top of RAM: 0x10000000, Total RAM: 0x10000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0x00000000 -> 0x00010000
Normal 0x00010000 -> 0x00010000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00010000
On node 0 totalpages: 65536
free_area_init_node: node 0, pgdat c02ed470, node_mem_map c030f180
DMA zone: 65024 pages, LIFO batch:15
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/ram rw console=ttyS0,115200
IPIC (128 IRQ sources) at fddfa700
PID hash table entries: 1024 (order: 10, 4096 bytes)
time_init: decrementer frequency = 66.666666 MHz
time_init: processor frequency = 399.999996 MHz
clocksource: timebase mult[3c00001] shift[22] registered
clockevent: decrementer mult[1111] shift[16] cpu[0]
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
On 12/9/09, Lee, Eric <eric.lee@hp.com> wrote:
>
> two things; I had better luck with the mpc8349mds (? don’t remember exact
> file name) dts as opposed to the itx. I had to remove the bcsr section or
> else the kernel hung during initialization . also, your u-boot is not
> passing the correct kernel commandline:
>
>
>
> “Kernel command line: root=/dev/nfs rw nfsroot=192.168.200.230:/nfsroot/rootfs
> i0IPIC (128 IRQ sources) at fdffc700”
>
>
>
> you’re trying to run a ramdisk and with tty I expect:
>
>
>
> “root=/dev/ram rw console=ttyS0,115200 “
>
>
>
> check your environment variable bootargs in u-boot
>
>
>
>
>
>
>
> *From:* Junita Ajith [mailto:ajijuni@gmail.com]
> *Sent:* Wednesday, December 09, 2009 10:58 AM
> *To:* Lee, Eric
> *Cc:* Linuxppc-dev@lists.ozlabs.org
> *Subject:* dts file for MPC8343EA - cuImage doesn't boot , but uImage with
> DTS shows serial output
>
>
>
> Hi Eric,
>
> I am building the linux kernel V-2.6.27 based on MPC8349miTXGP dts file.
> I am still not able to boot the cuImage.
>
> But, I see serial outuput from kernel when I try to boot with <kernel>
> <ramdisk> <dtb file>
>
> Still the kernel hangs after "Dentry cache hash table entries: 32768
> (order: 5, 131072 bytes)".
>
> Any clues ..?? We have DDR2 in this board and we are initializing it in
> U-Boot.
>
> Please find the screen dump below:
>
> Thanks,
> Junita
>
> Screen shot:
> ===========
> u-boot> bootm 0x2000000 0x3000000 0x4000000
> ## Booting image at 02000000 ...
> Image Name: Linux-2.6.27.18-svn52-dirty8
> Created: 2009-12-08 23:49:28 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1416039 Bytes = 1.4 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> ## Current stack ends at 0x0FF9BD48 => set upper limit to 0x00800000
> ## cmdline at 0x007FFF00 ... 0x007FFFA6
> bd address = 0x0FF9BFC4
> memstart = 0x00000000
> memsize = 0x10000000
> flashstart = 0xFE000000
> flashsize = 0x00080000
> flashoffset = 0x00034000
> sramstart = 0x00000000
> sramsize = 0x00000000
> bootflags = 0x00000001
> intfreq = 399.999 MHz
> busfreq = 266.666 MHz
> ethaddr = 00:E0:0C:00:8C:01
> IP addr = 192.168.201.199
> baudrate = 115200 bps
> Not skipping initrd
> ## Loading RAMDisk Image at 03000000 ...
> Image Name: uboot ext2 ramdisk rootfs
> Created: 2009-10-30 20:15:22 UTC
> Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
> Data Size: 3889103 Bytes = 3.7 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Booting using the fdt at 0x4000000
> ## initrd at 0x03000040 ... 0x033B580E (len=3889103=0x3B57CF)
> Loading Ramdisk to 0fbe5000, end 0ff9a7cf ... OK
> ## device tree at 0x04000000 ... 0x04002FFF (len=12288=0x3000)
> Loading Device Tree to 007fc000, end 007fefff ... OK
> Updating property '/soc8349@e0000000/ethernet@24000/mac-address' = 00 e0
> 0c 001Updating property '/soc8349@e0000000/ethernet@24000/local-mac-address'
> = 00 e01Updating property 'timebase-frequency' = 03 f9 40 aa
> Updating property 'bus-frequency' = 0f e5 02 a8
> Updating property 'clock-frequency' = 17 d7 83 fc
> Updating property 'bus-frequency' = 0f e5 02 a8
> Updating property 'clock-frequency' = 0f e5 02 a8
> ## Transferring control to Linux (at address 00000000) ...
> Using MPC834x ITX machine description
> Linux version 2.6.27.18-svn52-dirty8 (root@localhost.localdomain) (gcc
> version 9Found initrd at 0xcfbe5000:0xcff9a7cf
> console [udbg0] enabled
> setup_arch: bootmem
> mpc834x_itx_setup_arch()
> arch: exit
> Zone PFN ranges:
> DMA 0x00000000 -> 0x00010000
> Normal 0x00010000 -> 0x00010000
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0x00000000 -> 0x00010000
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
> Kernel command line: root=/dev/nfs rw nfsroot=192.168.200.230:/nfsroot/rootfs
> i0IPIC (128 IRQ sources) at fdffc700
> PID hash table entries: 1024 (order: 10, 4096 bytes)
> clocksource: timebase mult[3c00001] shift[22] registered
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
>
>
>
>
> On 12/9/09, *Lee, Eric* <eric.lee@hp.com> wrote:
>
> I would probably remove the bcsr region. this was some cpld I believe on a
> reference board. with this dts it'll try to write to some hardware
> registers that do not exist or are not mapped to the same area.
>
>
>
>
> -----Original Message-----
> From: linuxppc-dev-bounces+eric.lee=hp.com@lists.ozlabs.org [mailto:
> linuxppc-dev-bounces+eric.lee <linuxppc-dev-bounces%2Beric.lee>=hp.com@
> lists.ozlabs.org] On Behalf Of ajijuni@gmail.com
> Sent: Sunday, December 06, 2009 11:41 PM
> To: Linuxppc-dev@lists.ozlabs.org
> Subject: dts file for MPC8343EA
>
> Hi
>
> We have an MPC8343EA based custom board.
>
> I am not able to get Linux up and running in this. No serial output to
> debug further.
> U-boot shows correct 'bdinfo' & 'clocks' output.
> inux hangs at machine_probe.
>
>
> I doubt the DTS file in Linux. anyone has DTS file for MPC8343??
>
> u-boot version - 1.3.2
> linux-2.6.27
> The board base files are drived from MPC8349Imtx-GP since we have the
> reference board in which we tested the linux image.
>
> My current DTS file
> /dts-v1/;
>
> / {
> model = "MPC8343";
> compatible = "MPC8349EMDS", "MPC834xMDS", "MPC83xxMDS";
> linux,phandle = <0x100>;
> #size-cells = <0x1>;
> #address-cells = <0x1>;
>
> aliases {
> ethernet0 = &enet0;
> ethernet1 = &enet1;
> serial0 = &serial0;
> serial1 = &serial1;
> pci0 = &pci0;
> pci1 = &pci1;
> };
> cpus {
> linux,phandle = <0x200>;
> #cpus = <0x1>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> PowerPC,8343EA@0 {
> device_type = "cpu";
> reg = <0x0>;
> d-cache-line-size = <20>;
> i-cache-line-size = <20>;
> d-cache-size = <8000>;
> i-cache-size = <8000>;
> timebase-frequency = <0>; // from bootloader
> bus-frequency = <0>; // from bootloader
> clock-frequency = <0>; // from bootloader
> 32-bit;
> };
> };
>
>
> memory {
> device_type = "memory";
> reg = <0x00000000 0x10000000>; // 256MB at 0
> };
>
> bcsr@e2400000 {
> device_type = "board-control";
> reg = <0xe2400000 0x8000>;
> };
> soc8343@e0000000 {
> bus-frequency = <0x1>;
> reg = <0xe0000000 0x200>;
> ranges = <0x0 0xe0000000 0x100000>;
> device_type = "soc";
> #interrupt-cells = <0x2>;
> #size-cells = <0x1>;
> #address-cells = <0x1>;
>
> wdt@200 {
> device_type = "watchdog";
> compatible = "mpc83xx_wdt";
> reg = <0x200 0x100>;
> };
>
> i2c@3000 {
> #address-cells = <1>;
> #size-cells = <0>;
> cell-index = <0>;
> compatible = "fsl-i2c";
> reg = <0x3000 0x100>;
> interrupts = <14 0x8>;
> interrupt-parent = <&ipic>;
> dfsrr;
>
> rtc@68 {
> compatible = "dallas,ds1374";
> reg = <0x68>;
> };
> };
>
> i2c@3100 {
> #address-cells = <1>;
> #size-cells = <0>;
> cell-index = <1>;
> compatible = "fsl-i2c";
> reg = <0x3100 0x100>;
> interrupts = <15 0x8>;
> interrupt-parent = <&ipic>;
> dfsrr;
> };
>
> spi@7000 {
> cell-index = <0>;
> compatible = "fsl,spi";
> reg = <0x7000 0x1000>;
> interrupts = <16 0x8>;
> interrupt-parent = <&ipic>;
> mode = "cpu";
> };
>
> dma@82a8 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "fsl,mpc8349-dma", "fsl,elo-dma";
> reg = <0x82a8 4>;
> ranges = <0 0x8100 0x1a8>;
> interrupt-parent = <&ipic>;
> interrupts = <71 8>;
> cell-index = <0>;
> dma-channel@0 {
> compatible = "fsl,mpc8349-dma-channel",
> "fsl,elo-dma-channel";
> reg = <0 0x80>;
> interrupt-parent = <&ipic>;
> interrupts = <71 8>;
> };
> dma-channel@80 {
> compatible = "fsl,mpc8349-dma-channel",
> "fsl,elo-dma-channel";
> reg = <0x80 0x80>;
> interrupt-parent = <&ipic>;
> interrupts = <71 8>;
> };
> dma-channel@100 {
> compatible = "fsl,mpc8349-dma-channel",
> "fsl,elo-dma-channel";
> reg = <0x100 0x80>;
> interrupt-parent = <&ipic>;
> interrupts = <71 8>;
> };
> dma-channel@180 {
> compatible = "fsl,mpc8349-dma-channel",
> "fsl,elo-dma-channel";
> reg = <0x180 0x28>;
> interrupt-parent = <&ipic>;
> interrupts = <71 8>;
> };
> };
> /* phy type (ULPI or SERIAL) are only types supported for MPH */
> /* port = 0 or 1 */
> usb@22000 {
> compatible = "fsl-usb2-mph";
> reg = <0x22000 0x1000>;
> #address-cells = <1>;
> #size-cells = <0>;
> interrupt-parent = <&ipic>;
> interrupts = <39 0x8>;
> phy_type = "ulpi";
> port1;
> };
> /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
> usb@23000 {
> compatible = "fsl-usb2-dr";
> reg = <0x23000 0x1000>;
> #address-cells = <1>;
> #size-cells = <0>;
> interrupt-parent = <&ipic>;
> interrupts = <38 0x8>;
> dr_mode = "otg";
> phy_type = "ulpi";
> };
>
> mdio@24520 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "fsl,gianfar-mdio";
> reg = <0x24520 0x20>;
>
> phy0: ethernet-phy@0 {
> interrupt-parent = <&ipic>;
> interrupts = <17 0x8>;
> reg = <0x0>;
> device_type = "ethernet-phy";
> };
> phy1: ethernet-phy@1 {
> interrupt-parent = <&ipic>;
> interrupts = <18 0x8>;
> reg = <0x1>;
> device_type = "ethernet-phy";
> };
> enet0: ethernet@24000 {
> cell-index = <0>;
> device_type = "network";
> model = "TSEC";
> compatible = "gianfar";
> reg = <0x24000 0x1000>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> interrupts = <32 0x8 33 0x8 34 0x8>;
> interrupt-parent = <&ipic>;
> phy-handle = <&phy0>;
> linux,network-index = <0>;
> };
>
> enet1: ethernet@25000 {
> cell-index = <1>;
> device_type = "network";
> model = "TSEC";
> compatible = "gianfar";
> reg = <0x25000 0x1000>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> interrupts = <35 0x8 36 0x8 37 0x8>;
> interrupt-parent = <&ipic>;
> phy-handle = <&phy1>;
> linux,network-index = <1>;
> };
>
> serial0: serial@4500 {
> cell-index = <0>;
> device_type = "serial";
> compatible = "ns16550";
> reg = <0x4500 0x100>;
> clock-frequency = <0>;
> interrupts = <9 0x8>;
> interrupt-parent = <&ipic>;
> };
>
> serial1: serial@4600 {
> cell-index = <1>;
> device_type = "serial";
> compatible = "ns16550";
> reg = <0x4600 0x100>;
> clock-frequency = <0>;
> interrupts = <10 0x8>;
> interrupt-parent = <&ipic>;
> };
>
> crypto@30000 {
> compatible = "fsl,sec2.0";
> reg = <0x30000 0x10000>;
> interrupts = <11 0x8>;
> interrupt-parent = <&ipic>;
> fsl,num-channels = <4>;
> fsl,channel-fifo-len = <24>;
> fsl,exec-units-mask = <0x7e>;
> fsl,descriptor-types-mask = <0x01010ebf>;
> };
>
> Thanks,
> agnel
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
>
[-- Attachment #2: Type: text/html, Size: 24569 bytes --]
^ permalink raw reply
* Deprecating of_platform, the path from here...
From: Grant Likely @ 2009-12-09 22:06 UTC (permalink / raw)
To: devicetree-discuss, Benjamin Herrenschmidt, Josh Boyer,
Jeremy Kerr, Segher Boessenkool, Paul Mackerras, linuxppc-dev,
David Miller
Hi all,
This is a summary of a discussion we had on #mklinux last night.
On PowerPC, SPARC and Microblaze, most system (non-discoverable)
devices are registered on the of_platform bus. In the rest of the
kernel, the same kind of devices are registered on the platform bus.
The of_platform and platform busses essentially perform the same task;
proved a method for platform code to register a device that will be
bound to a driver at a later point in time. The most significant
difference is that the of_platform bus understands how probe drivers
The OF Way using the 'compatible' property. In the OF way, more than
one driver could match the device and the OS is responsible to choose
the best one.
The platform bus only supports matching a device to a driver based on
the device's name. It has no mechanism for capturing the OF binding
model.
Maintaining of_platform comes at a cost. Many device drivers end up
with two bus bindings, both of_platform_driver and platform_driver.
In practice this means a bunch of duplicated boilerplate and some ugly
#ifdef blocks. Device driver authors don't seem thrilled to have
of_platform stuff "invade" their platform drivers. Also, the
of_platform/platform split doesn't match the pattern used for other
bus subsystems (i2c, spi, mdio, etc). On other busses, the same
driver is used regardless of whether the device was allocated
statically in platform code, obtained from the device tree, or
something else entirely.
So, the desire is to deprecate of_platform bus and use platform bus
for system devices in the device tree. However, doing this requires
two problems to be solved:
1) device to driver matching - Given an OF style compatible list, how
is the device matched to the correct platform driver?
2) data translation - how and where is the device tree data
transformed into something usable by the platform driver?
The 2nd problem is the easy one to solve. In most cases, any code to
translate device tree data into a driver platform_data structure is
driver specific. A hook can be added to the top of the driver's
.probe() routine. If no pdata pointer is set in the driver structure,
then it can call out to a helper function to create one from the
device tree data. Something along the lines of:
pdata = pdev->dev.platform_data;
if (!pdata)
pdata = pdriver_get_of_pdata(pdev);
It makes sense for this code to be called from the driver itself so
that the translation code only gets run when the device is actually
used. By running the translators at probe time (instead of device
registration time) it means the translators don't need to be built
into the kernel. On a kernel config with a lot of of-enabled drivers
this would be significant.
To solve the 1st problem the possibility was discussed is to add
compatible list parsing to both the platform bus and modutils. Doing
so would make it easy to create platform devices from nodes in the
device tree, but it would be hard to get 'right'. There is a risk
that it would break existing modutils (completely unacceptable). It
is unclear how to make sure Linux probes the correct driver. ie. If
a compatible driver is loaded, but a 'better' driver is available,
then how is the kernel prevented from binding against the 'worse'
driver before the better driver is loaded? Finally, while it may
solve the problem for the platform bus, the exact same problem needs
to also be solved for i2c, spi, mdio, etc.
In the end, the decision was to just use a simple lookup table of
compatible values to driver names. When registering devices, platform
code will use the table to choose the best name. Existing platform
devices can then bind against them as-is. The downside is that the
table must be statically compiled into the kernel. However, the
solution is simple and the table can probably be put into an initdata
section to be discarded after boot. At a later date something more
sophisticated can be designed.
So, to summarize the decisions made:
1) of_platform will be deprecated in preference of the platform bus.
2) platform code will register platform devices at boot time
- A lookup table will be used to translate 'compatible' values to
driver names used by the kernel
- If no suitable compatible values exist in the table, then choose a
name programatically (ie. of_modalias_node()). Userspace can force
bind to a driver after boot if desirable.
- helper functions to be written to make registration simple (ie.
of_platform_bus_probe())
- helper functions will fill in common resources (memory ranges and
irqs) but leave complex stuff to the driver
3) platform drivers will probe the same way they are probed now. No
changes to the platform bus.
4) If drivers needs extra platform_data, then a call will be added to
the top of the .probe() hook to go and create one.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2] cpm2_pic: Allow correct flow_types for port C interrupts
From: Scott Wood @ 2009-12-09 21:57 UTC (permalink / raw)
To: avorontsov; +Cc: Linuxppc-dev Development, Mark Ware
In-Reply-To: <20091209215334.GA536@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
>> + if ((flow_type != IRQ_TYPE_EDGE_BOTH) &&
>> + (flow_type != IRQ_TYPE_EDGE_FALLING)) {
>
> I'd place one more tab here.
Or better, align one "flow_type" with the other.
-Scott
^ permalink raw reply
* Re: [PATCH] cardbus: Add a fixup hook and fix powerpc
From: Dominik Brodowski @ 2009-12-09 21:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-pci, linux-kernel@vger.kernel.org, Jesse Barnes, blofeldus,
Olof Johansson, linuxppc-dev
In-Reply-To: <1260341533.16132.20.camel@pasglop>
Hey Benjamin,
On Wed, Dec 09, 2009 at 05:52:13PM +1100, Benjamin Herrenschmidt wrote:
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.net> (for PCMCIA)
> Note: In the long run we might want to streamline the hooks for fixing
> up new devices vs. new busses and make some stuff common between cardbus
> and PCI hotplug which is actually a mess.
... though I'd prefer such a generic approach.
Best,
Dominik
^ permalink raw reply
* Re: [PATCH v2] cpm2_pic: Allow correct flow_types for port C interrupts
From: Anton Vorontsov @ 2009-12-09 21:53 UTC (permalink / raw)
To: Mark Ware; +Cc: Scott Wood, Linuxppc-dev Development
In-Reply-To: <4B1EF3E9.8050005@elphinstone.net>
On Wed, Dec 09, 2009 at 11:48:41AM +1100, Mark Ware wrote:
> Port C interrupts can be either falling edge, or either edge.
> Other external interrupts are either falling edge or active low.
>
> Signed-Off-By: Mark Ware <mware@elphinstone.net>
Looks correct (checked with 8272 and 8555 specs).
Reviewed-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Cosmetic nitpicks below. I tend to think they don't desire
another resend, but I couldn't resist making them anyway. ;-)
[...]
> + if (src >= CPM2_IRQ_PORTC15 && src <= CPM2_IRQ_PORTC0) {
> + if (flow_type == IRQ_TYPE_NONE)
> + flow_type = IRQ_TYPE_EDGE_BOTH;
> +
> + if ((flow_type != IRQ_TYPE_EDGE_BOTH) &&
> + (flow_type != IRQ_TYPE_EDGE_FALLING)) {
I'd place one more tab here. And parenthesis aren't actually needed.
> + printk(KERN_ERR "CPM2 PIC: sense type 0x%x not supported\n",
> + flow_type);
> + return -EINVAL;
> + }
> + } else {
> + if (flow_type == IRQ_TYPE_NONE)
> + flow_type = IRQ_TYPE_LEVEL_LOW;
> +
> + if (flow_type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_LEVEL_HIGH)) {
> + printk(KERN_ERR "CPM2 PIC: sense type 0x%x not supported\n",
> + flow_type);
pr_err is shorter. Also, this message is duplicated. Would be better
to do something like:
if (somethingwrong)
goto err_sense;
...
return 0;
err_sense:
pr_err("CPM2 PIC: sense type 0x%x not supported\n", flow_type);
return -EINVAL;
}
Or we may don't print any errors at all. For internal interrupts
we don't print them anyway, i.e. the current code has just
return (flow_type & IRQ_TYPE_LEVEL_LOW) ? 0 : -EINVAL;
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [RFC PATCH 2/5] mcu_mpc8349emitx: port to new of gpio interface
From: Anton Vorontsov @ 2009-12-09 21:32 UTC (permalink / raw)
To: Kumar Gala
Cc: Dmitry Eremin-Solenikov, Linuxppc-dev Development,
devicetree-discuss, David Brownell, Paul Mackerras
In-Reply-To: <6C061449-ACBE-4C51-9101-007DFD285F55@kernel.crashing.org>
On Wed, Dec 09, 2009 at 03:16:37PM -0600, Kumar Gala wrote:
> On Nov 17, 2009, at 9:42 AM, Dmitry Eremin-Solenikov wrote:
>
> > Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> > ---
> > arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 11 +++++------
> > 1 files changed, 5 insertions(+), 6 deletions(-)
>
> Minding reviewing for me.
The whole approach was reviewed, and rejected.
http://lists.ozlabs.org/pipermail/devicetree-discuss/2009-November/001330.html
and
http://lists.ozlabs.org/pipermail/devicetree-discuss/2009-November/001328.html
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 4/4] mpc8349emitx: add leds-gpio binding
From: Kumar Gala @ 2009-12-09 21:17 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: linuxppc-dev
In-Reply-To: <1258379934-32352-5-git-send-email-dbaryshkov@gmail.com>
On Nov 16, 2009, at 7:58 AM, Dmitry Eremin-Solenikov wrote:
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> arch/powerpc/boot/dts/mpc8349emitx.dts | 18 ++++++++++++++++++
> 1 files changed, 18 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 3/4] mpc8349emitx: add OF descriptions of LocalBus devices
From: Kumar Gala @ 2009-12-09 21:17 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20091116205120.GA22074@doriath.ww600.siemens.net>
On Nov 16, 2009, at 2:51 PM, Dmitry Eremin-Solenikov wrote:
> Describe all LocalBus chipselects on MPC8349E-MITX board. Also add flash
> bindings.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> arch/powerpc/boot/dts/mpc8349emitx.dts | 21 ++++++++++++++++++++-
> 1 files changed, 20 insertions(+), 1 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 2/4] mpc8349emitx: populate I2C busses
From: Kumar Gala @ 2009-12-09 21:17 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: linuxppc-dev
In-Reply-To: <1258379934-32352-3-git-send-email-dbaryshkov@gmail.com>
On Nov 16, 2009, at 7:58 AM, Dmitry Eremin-Solenikov wrote:
> Add OF descriptions of EEPROM, two GPIO extenders and SPD hanging on I2C
> on this board.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> arch/powerpc/boot/dts/mpc8349emitx.dts | 25 +++++++++++++++++++++++++
> 1 files changed, 25 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 1/4] mpc8349emitx: add gpio controller declarations
From: Kumar Gala @ 2009-12-09 21:17 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: linuxppc-dev
In-Reply-To: <1258379934-32352-2-git-send-email-dbaryshkov@gmail.com>
On Nov 16, 2009, at 7:58 AM, Dmitry Eremin-Solenikov wrote:
> mpc8349 bears two GPIO controllers. Enable support for them.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> arch/powerpc/boot/dts/mpc8349emitx.dts | 18 ++++++++++++++++++
> 1 files changed, 18 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [RFC PATCH 2/5] mcu_mpc8349emitx: port to new of gpio interface
From: Kumar Gala @ 2009-12-09 21:16 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Dmitry Eremin-Solenikov, Linuxppc-dev Development,
devicetree-discuss, David Brownell, Paul Mackerras
In-Reply-To: <1258472546-31343-3-git-send-email-dbaryshkov@gmail.com>
On Nov 17, 2009, at 9:42 AM, Dmitry Eremin-Solenikov wrote:
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 11 +++++------
> 1 files changed, 5 insertions(+), 6 deletions(-)
Minding reviewing for me.
- k
>=20
> diff --git a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c =
b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
> index 82a9bcb..4ba8b16 100644
> --- a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
> +++ b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
> @@ -36,7 +36,7 @@ struct mcu {
> struct mutex lock;
> struct device_node *np;
> struct i2c_client *client;
> - struct of_gpio_chip of_gc;
> + struct gpio_chip gc;
> u8 reg_ctrl;
> };
>=20
> @@ -55,8 +55,7 @@ static void mcu_power_off(void)
>=20
> static void mcu_gpio_set(struct gpio_chip *gc, unsigned int gpio, int =
val)
> {
> - struct of_gpio_chip *of_gc =3D to_of_gpio_chip(gc);
> - struct mcu *mcu =3D container_of(of_gc, struct mcu, of_gc);
> + struct mcu *mcu =3D container_of(gc, struct mcu, gc);
> u8 bit =3D 1 << (4 + gpio);
>=20
> mutex_lock(&mcu->lock);
> @@ -78,8 +77,8 @@ static int mcu_gpio_dir_out(struct gpio_chip *gc, =
unsigned int gpio, int val)
> static int mcu_gpiochip_add(struct mcu *mcu)
> {
> struct device_node *np;
> - struct of_gpio_chip *of_gc =3D &mcu->of_gc;
> - struct gpio_chip *gc =3D &of_gc->gc;
> + struct gpio_chip *gc =3D &mcu->gc;
> + struct of_gpio_chip *of_gc =3D &gc->of_gc;
> int ret;
>=20
> np =3D of_find_compatible_node(NULL, NULL, =
"fsl,mcu-mpc8349emitx");
> @@ -113,7 +112,7 @@ static int mcu_gpiochip_remove(struct mcu *mcu)
> {
> int ret;
>=20
> - ret =3D gpiochip_remove(&mcu->of_gc.gc);
> + ret =3D gpiochip_remove(&mcu->gc);
> if (ret)
> return ret;
> of_node_put(mcu->np);
> --=20
> 1.6.5
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [RFC] doc/powerpc: try to explain why the interrupt numbers are off by 16
From: Kumar Gala @ 2009-12-09 20:51 UTC (permalink / raw)
To: Sebastian Andrzej Siewior; +Cc: Scott Wood, linuxppc-dev, Alemao, linux-kernel
In-Reply-To: <20091206113247.GB9937@Chamillionaire.breakpoint.cc>
On Dec 6, 2009, at 5:32 AM, Sebastian Andrzej Siewior wrote:
> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> ---
> Documentation/powerpc/dts-bindings/fsl/mpic.txt | 42 =
+++++++++++++++++++++++
> 1 files changed, 42 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/fsl/mpic.txt
applied to next
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/fsl_pci: Fix P2P bridge handling for MPC83xx PCIe controllers
From: Kumar Gala @ 2009-12-09 20:51 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, B.J. Buchalter
In-Reply-To: <20091207225435.GA18485@oksana.dev.rtsoft.ru>
On Dec 7, 2009, at 4:54 PM, Anton Vorontsov wrote:
> It appears that we wrongly calculate dev_base for type1 config cycles.
> The thing is: we shouldn't subtract hose->first_busno because PCI core
> sets PCI primary, secondary and subordinate bus numbers, and PCIe
> controller actually takes the registers into account. So we should use
> just bus->number.
>
> Also, according to MPC8315 reference manual, primary bus number should
> always remain 0. We have PPC_INDIRECT_TYPE_SURPRESS_PRIMARY_BUS quirk
> in indirect_pci.c, but since 83xx is somewhat special, it doesn't use
> indirect_pci.c routines, so we have to implement the quirk specifically
> for 83xx PCIe controllers.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
applied to next
- k
^ permalink raw reply
* Re: [PATCH v2] cpm2_pic: Allow correct flow_types for port C interrupts
From: Kumar Gala @ 2009-12-09 20:43 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: Scott Wood, Linuxppc-dev Development, Mark Ware
In-Reply-To: <4B1EF3E9.8050005@elphinstone.net>
On Dec 8, 2009, at 6:48 PM, Mark Ware wrote:
> Port C interrupts can be either falling edge, or either edge.
> Other external interrupts are either falling edge or active low.
>=20
> Signed-Off-By: Mark Ware <mware@elphinstone.net>
> ---
> Changed in v2:
> - Disallow rising edge only on Port C=20
>=20
> arch/powerpc/sysdev/cpm2_pic.c | 30 +++++++++++++++++++++++-------
> 1 files changed, 23 insertions(+), 7 deletions(-)
Anton, mind taking a look at this for me.
- k
>=20
> diff --git a/arch/powerpc/sysdev/cpm2_pic.c =
b/arch/powerpc/sysdev/cpm2_pic.c
> index 78f1f7c..eba5f24 100644
> --- a/arch/powerpc/sysdev/cpm2_pic.c
> +++ b/arch/powerpc/sysdev/cpm2_pic.c
> @@ -141,13 +141,29 @@ static int cpm2_set_irq_type(unsigned int virq, =
unsigned int flow_type)
> struct irq_desc *desc =3D get_irq_desc(virq);
> unsigned int vold, vnew, edibit;
>=20
> - if (flow_type =3D=3D IRQ_TYPE_NONE)
> - flow_type =3D IRQ_TYPE_LEVEL_LOW;
> -
> - if (flow_type & IRQ_TYPE_EDGE_RISING) {
> - printk(KERN_ERR "CPM2 PIC: sense type 0x%x not =
supported\n",
> - flow_type);
> - return -EINVAL;
> + /* Port C interrupts are either IRQ_TYPE_EDGE_FALLING or
> + * IRQ_TYPE_EDGE_BOTH (default). All others are =
IRQ_TYPE_EDGE_FALLING
> + * or IRQ_TYPE_LEVEL_LOW (default)
> + */
> + if (src >=3D CPM2_IRQ_PORTC15 && src <=3D CPM2_IRQ_PORTC0) {
> + if (flow_type =3D=3D IRQ_TYPE_NONE)
> + flow_type =3D IRQ_TYPE_EDGE_BOTH;
> +
> + if ((flow_type !=3D IRQ_TYPE_EDGE_BOTH) &&=20
> + (flow_type !=3D IRQ_TYPE_EDGE_FALLING)) {
> + printk(KERN_ERR "CPM2 PIC: sense type 0x%x not =
supported\n",
> + flow_type);
> + return -EINVAL;
> + }
> + } else {
> + if (flow_type =3D=3D IRQ_TYPE_NONE)
> + flow_type =3D IRQ_TYPE_LEVEL_LOW;
> +
> + if (flow_type & (IRQ_TYPE_EDGE_RISING | =
IRQ_TYPE_LEVEL_HIGH)) {
> + printk(KERN_ERR "CPM2 PIC: sense type 0x%x not =
supported\n",
> + flow_type);
> + return -EINVAL;
> + }
> }
>=20
> desc->status &=3D ~(IRQ_TYPE_SENSE_MASK | IRQ_LEVEL);
> --=20
> 1.5.6.5
^ permalink raw reply
* Re: spi_mpc8xxx.c: chip select polarity problem
From: Grant Likely @ 2009-12-09 17:46 UTC (permalink / raw)
To: Torsten Fleischer; +Cc: avorontsov
In-Reply-To: <200912091649.19380.to-fleischer@t-online.de>
On Wed, Dec 9, 2009 at 8:49 AM, Torsten Fleischer
<to-fleischer@t-online.de> wrote:
> On Thu, Nov 26, 2009 at 20:17:35, =A0Grant Likely wrote:
> [...]
>> spi-cs-high is definitely not a complete solution, but it isn't
>> actively evil either. =A0Plus it is documented and (presumably) in
>> active use. so support for it should not be dropped.
>>
>> Regardless, there needs to be a library function for parsing all the
>> SPI child nodes and returning the active state for each GPIO chip
>> select. =A0All the code for parsing the old spi-cs-high properties can
>> be contained in the same place as a new yet-to-be-defined bus node cs
>> polarity property. =A0The rework to the driver itself is not ugly.
>>
>
> The following patch adds a function to get the active state of the chip s=
elect
> of a SPI device by looking for the 'spi-cs-high' property in the associat=
ed device
> tree node.
> This function is used by the spi_mpc8xxx driver to set a proper initial v=
alue
> to the associated GPIOs.
>
>
> Signed-off-by: Torsten Fleischer <to-fleischer@t-online.de>
I like this better. See comments below.
> ---
>
> diff -ruN linux-2.6.32_orig//drivers/of/of_spi.c linux-2.6.32/drivers/of/=
of_spi.c
> --- linux-2.6.32_orig//drivers/of/of_spi.c =A0 =A0 =A02009-12-03 04:51:21=
.000000000 +0100
> +++ linux-2.6.32/drivers/of/of_spi.c =A0 =A02009-12-09 12:37:01.000000000=
+0100
> @@ -10,6 +10,49 @@
> =A0#include <linux/device.h>
> =A0#include <linux/spi/spi.h>
> =A0#include <linux/of_spi.h>
> +#include <linux/errno.h>
> +
> +/**
> + * of_get_spi_cs_active_state - Gets the chip select's active state of a=
SPI
> + * child devices.
> + * @np: =A0 =A0 =A0 =A0parent node of the SPI device nodes
> + * @index: =A0 =A0 index/address of the SPI device (refers to the 'reg' =
property)
> + * @cs_active: pointer to return the chip select's active state
> + * =A0 =A0 =A0 =A0 =A0 =A0 (true =3D active high; false =3D active low)
> + *
> + * Returns 0 on success; negative errno on failure
> + */
> +int of_get_spi_cs_active_state(struct device_node *np, int index, bool *=
cs_active)
> +{
> + =A0 =A0 =A0 struct device_node *child;
> + =A0 =A0 =A0 const int *prop;
> + =A0 =A0 =A0 int len;
> + =A0 =A0 =A0 bool active =3D 0;
> +
> + =A0 =A0 =A0 /* search for the matching SPI device */
> + =A0 =A0 =A0 for_each_child_of_node(np, child) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 prop =3D of_get_property(child, "reg", &len=
);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!prop || len < sizeof(*prop)) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* property 'reg' not avail=
able (not an error) */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ( *prop =3D=3D index ) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* matching device found */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (of_find_property(child,=
"spi-cs-high", NULL))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 active =3D =
1;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (cs_active)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 *cs_active =
=3D active;
A little odd. If cs_active is NULL, then this routine does nothing,
and the caller is entirely defective. Either test at the top of the
function or not at all. Then *cs_active can be assigned directly.
But even then, this function will probably need to be reworked (see
comments below).
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 return -ENODEV;
> +}
> +EXPORT_SYMBOL(of_get_spi_cs_active_state);
> +
>
> =A0/**
> =A0* of_register_spi_devices - Register child devices onto the SPI bus
> diff -ruN linux-2.6.32_orig//drivers/spi/spi_mpc8xxx.c linux-2.6.32/drive=
rs/spi/spi_mpc8xxx.c
> --- linux-2.6.32_orig//drivers/spi/spi_mpc8xxx.c =A0 =A0 =A0 =A02009-12-0=
3 04:51:21.000000000 +0100
> +++ linux-2.6.32/drivers/spi/spi_mpc8xxx.c =A0 =A0 =A02009-12-09 12:50:36=
.000000000 +0100
> @@ -705,6 +705,7 @@
> =A0 =A0 =A0 =A0for (; i < ngpios; i++) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int gpio;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0enum of_gpio_flags flags;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 bool astate;
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gpio =3D of_get_gpio_flags(np, i, &flags);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!gpio_is_valid(gpio)) {
> @@ -721,8 +722,15 @@
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pinfo->gpios[i] =3D gpio;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pinfo->alow_flags[i] =3D flags & OF_GPIO_A=
CTIVE_LOW;
>
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret =3D of_get_spi_cs_active_state(np, i, &=
astate);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ret) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(dev, "can't get cs =
active state of device "
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "#%d: %d\n"=
, i, ret);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err_loop;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
This is a bit heavy handed in that it expects the device tree to be
fully populated with all SPI devices which isn't always a given. For
example a board that has some unpopulated SPI devices could have some
gaps in the GPIO CS layout. If a node can't be found, then just
ignore it silently and move on to the next. I'd do something like
this:
+ astate =3D of_get_spi_cs_active_state(np, i);
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret =3D gpio_direction_output(pinfo->gpios[i=
],
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 pinfo->alow_flags[i]);
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 pinfo->alow_flags[i] ^ !astate);
BTW, why the xor? The usage is non-obvious enough that I'd like to
see a comment describing the use case.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Ping does not work on my MPC8544 board, using linux2.6.23
From: Scott Wood @ 2009-12-09 19:59 UTC (permalink / raw)
To: 林志平; +Cc: linuxppc-dev
In-Reply-To: <8148211e0912071825t22ffa590va2fe22272f6aaf62@mail.gmail.com>
林志平 wrote:
> > Another question is that I found linux2.6.31 does not support
> > board mpc8544ds,
>
> It should. What problems do you see?
>
> => bootm 0x1000000 0x1800000 0x800000
> ## Booting kernel from Legacy Image at 01000000 ...
> Image Name: Linux-2.6.31
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 2185099 Bytes = 2.1 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> ## Loading init Ramdisk from Legacy Image at 01800000 ...
> Image Name: Simple Embedded Linux Framework
> Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
> Data Size: 1859256 Bytes = 1.8 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 00800000
> Booting using the fdt blob at 0x800000
> Uncompressing Kernel Image ... OK
> Loading Ramdisk to 1fca7000, end 1fe6ceb8 ... OK
> booting kernel using flat tree
> It then stops and never print any more, I use mpc85xx_defconfig, I
> select mpc85xxds in the menuconfig and deselect other options like
> mpc8540ads etc.
Are you using the mpc8544ds device tree from 2.6.31, unchanged? Try
turning on CONFIG_PPC_EARLY_DEBUG.
No need to deselect the others, BTW.
> Does mpc85xx_defconfig not work?
>
> Yes mcp85xx_defconfig does not work, I can see mpc8540ads in the
> menuconfig, but no mpc8544ds.
mpc8544ds is supported by CONFIG_MPC85xx_DS.
-Scott
^ permalink raw reply
* Re: spi_mpc8xxx.c: chip select polarity problem
From: Torsten Fleischer @ 2009-12-09 19:13 UTC (permalink / raw)
To: Grant Likely; +Cc: avorontsov
In-Reply-To: <fa686aa40912090946m12fe293cg2efb043cb7a7f573@mail.gmail.com>
On Wed, Dec 9, 2009 at 18:46:51 Grant Likely wrote:
[...]
> > + ret = of_get_spi_cs_active_state(np, i, &astate);
> > + if (ret) {
> > + dev_err(dev, "can't get cs active state of device
> > " + "#%d: %d\n", i, ret);
> > + goto err_loop;
> > + }
>
> This is a bit heavy handed in that it expects the device tree to be
> fully populated with all SPI devices which isn't always a given. For
> example a board that has some unpopulated SPI devices could have some
> gaps in the GPIO CS layout. If a node can't be found, then just
> ignore it silently and move on to the next. I'd do something like
> this:
>
> + astate = of_get_spi_cs_active_state(np, i);
What should be returned if the node can't be found, 'true' or 'false?
Maybe its better to do the following:
+ ret = of_get_spi_cs_active_state(np, i, &astate);
+ if (ret) {
+ /* Device node not found */
+ continue;
+ }
> ret = gpio_direction_output(pinfo->gpios[i],
> - pinfo->alow_flags[i]);
> + pinfo->alow_flags[i] ^ !astate);
>
> BTW, why the xor? The usage is non-obvious enough that I'd like to
> see a comment describing the use case.
If I understand it right, the alow_flags describe the wiring. If set to 0 the
wiring is non-inverted, if set to 1 its inverted respectively. To take this
into account the active state has to be xor'd with the appropriate alow_flag.
^ permalink raw reply
* RE: dts file for MPC8343EA - cuImage doesn't boot , but uImage with DTS shows serial output
From: Lee, Eric @ 2009-12-09 18:12 UTC (permalink / raw)
To: Junita Ajith; +Cc: Linuxppc-dev@lists.ozlabs.org
In-Reply-To: <72d214170912090957g3743c63bq48836f6faa4b8269@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 14871 bytes --]
two things; I had better luck with the mpc8349mds (? don't remember exact file name) dts as opposed to the itx. I had to remove the bcsr section or else the kernel hung during initialization . also, your u-boot is not passing the correct kernel commandline:
"Kernel command line: root=/dev/nfs rw nfsroot=192.168.200.230:/nfsroot/rootfs i0IPIC (128 IRQ sources) at fdffc700"
you're trying to run a ramdisk and with tty I expect:
"root=/dev/ram rw console=ttyS0,115200 "
check your environment variable bootargs in u-boot
From: Junita Ajith [mailto:ajijuni@gmail.com]
Sent: Wednesday, December 09, 2009 10:58 AM
To: Lee, Eric
Cc: Linuxppc-dev@lists.ozlabs.org
Subject: dts file for MPC8343EA - cuImage doesn't boot , but uImage with DTS shows serial output
Hi Eric,
I am building the linux kernel V-2.6.27 based on MPC8349miTXGP dts file.
I am still not able to boot the cuImage.
But, I see serial outuput from kernel when I try to boot with <kernel> <ramdisk> <dtb file>
Still the kernel hangs after "Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)".
Any clues ..?? We have DDR2 in this board and we are initializing it in U-Boot.
Please find the screen dump below:
Thanks,
Junita
Screen shot:
===========
u-boot> bootm 0x2000000 0x3000000 0x4000000
## Booting image at 02000000 ...
Image Name: Linux-2.6.27.18-svn52-dirty8
Created: 2009-12-08 23:49:28 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1416039 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x0FF9BD48 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFFA6
bd address = 0x0FF9BFC4
memstart = 0x00000000
memsize = 0x10000000
flashstart = 0xFE000000
flashsize = 0x00080000
flashoffset = 0x00034000
sramstart = 0x00000000
sramsize = 0x00000000
bootflags = 0x00000001
intfreq = 399.999 MHz
busfreq = 266.666 MHz
ethaddr = 00:E0:0C:00:8C:01
IP addr = 192.168.201.199
baudrate = 115200 bps
Not skipping initrd
## Loading RAMDisk Image at 03000000 ...
Image Name: uboot ext2 ramdisk rootfs
Created: 2009-10-30 20:15:22 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 3889103 Bytes = 3.7 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Booting using the fdt at 0x4000000
## initrd at 0x03000040 ... 0x033B580E (len=3889103=0x3B57CF)
Loading Ramdisk to 0fbe5000, end 0ff9a7cf ... OK
## device tree at 0x04000000 ... 0x04002FFF (len=12288=0x3000)
Loading Device Tree to 007fc000, end 007fefff ... OK
Updating property '/soc8349@e0000000/ethernet@24000/mac-address' = 00 e0 0c 001Updating property '/soc8349@e0000000/ethernet@24000/local-mac-address' = 00 e01Updating property 'timebase-frequency' = 03 f9 40 aa
Updating property 'bus-frequency' = 0f e5 02 a8
Updating property 'clock-frequency' = 17 d7 83 fc
Updating property 'bus-frequency' = 0f e5 02 a8
Updating property 'clock-frequency' = 0f e5 02 a8
## Transferring control to Linux (at address 00000000) ...
Using MPC834x ITX machine description
Linux version 2.6.27.18-svn52-dirty8 (root@localhost.localdomain) (gcc version 9Found initrd at 0xcfbe5000:0xcff9a7cf
console [udbg0] enabled
setup_arch: bootmem
mpc834x_itx_setup_arch()
arch: exit
Zone PFN ranges:
DMA 0x00000000 -> 0x00010000
Normal 0x00010000 -> 0x00010000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00010000
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/nfs rw nfsroot=192.168.200.230:/nfsroot/rootfs i0IPIC (128 IRQ sources) at fdffc700
PID hash table entries: 1024 (order: 10, 4096 bytes)
clocksource: timebase mult[3c00001] shift[22] registered
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
On 12/9/09, Lee, Eric <eric.lee@hp.com<mailto:eric.lee@hp.com>> wrote:
I would probably remove the bcsr region. this was some cpld I believe on a reference board. with this dts it'll try to write to some hardware registers that do not exist or are not mapped to the same area.
-----Original Message-----
From: linuxppc-dev-bounces+eric.lee=hp.com<http://hp.com>@lists.ozlabs.org<http://lists.ozlabs.org> [mailto:linuxppc-dev-bounces+eric.lee<mailto:linuxppc-dev-bounces%2Beric.lee>=hp.com<http://hp.com>@lists.ozlabs.org<http://lists.ozlabs.org>] On Behalf Of ajijuni@gmail.com<mailto:ajijuni@gmail.com>
Sent: Sunday, December 06, 2009 11:41 PM
To: Linuxppc-dev@lists.ozlabs.org<mailto:Linuxppc-dev@lists.ozlabs.org>
Subject: dts file for MPC8343EA
Hi
We have an MPC8343EA based custom board.
I am not able to get Linux up and running in this. No serial output to debug further.
U-boot shows correct 'bdinfo' & 'clocks' output.
inux hangs at machine_probe.
I doubt the DTS file in Linux. anyone has DTS file for MPC8343??
u-boot version - 1.3.2
linux-2.6.27
The board base files are drived from MPC8349Imtx-GP since we have the reference board in which we tested the linux image.
My current DTS file
/dts-v1/;
/ {
model = "MPC8343";
compatible = "MPC8349EMDS", "MPC834xMDS", "MPC83xxMDS";
linux,phandle = <0x100>;
#size-cells = <0x1>;
#address-cells = <0x1>;
aliases {
ethernet0 = &enet0;
ethernet1 = &enet1;
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
pci1 = &pci1;
};
cpus {
linux,phandle = <0x200>;
#cpus = <0x1>;
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8343EA@0 {
device_type = "cpu";
reg = <0x0>;
d-cache-line-size = <20>;
i-cache-line-size = <20>;
d-cache-size = <8000>;
i-cache-size = <8000>;
timebase-frequency = <0>; // from bootloader
bus-frequency = <0>; // from bootloader
clock-frequency = <0>; // from bootloader
32-bit;
};
};
memory {
device_type = "memory";
reg = <0x00000000 0x10000000>; // 256MB at 0
};
bcsr@e2400000 {
device_type = "board-control";
reg = <0xe2400000 0x8000>;
};
soc8343@e0000000 {
bus-frequency = <0x1>;
reg = <0xe0000000 0x200>;
ranges = <0x0 0xe0000000 0x100000>;
device_type = "soc";
#interrupt-cells = <0x2>;
#size-cells = <0x1>;
#address-cells = <0x1>;
wdt@200 {
device_type = "watchdog";
compatible = "mpc83xx_wdt";
reg = <0x200 0x100>;
};
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl-i2c";
reg = <0x3000 0x100>;
interrupts = <14 0x8>;
interrupt-parent = <&ipic>;
dfsrr;
rtc@68 {
compatible = "dallas,ds1374";
reg = <0x68>;
};
};
i2c@3100 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <1>;
compatible = "fsl-i2c";
reg = <0x3100 0x100>;
interrupts = <15 0x8>;
interrupt-parent = <&ipic>;
dfsrr;
};
spi@7000 {
cell-index = <0>;
compatible = "fsl,spi";
reg = <0x7000 0x1000>;
interrupts = <16 0x8>;
interrupt-parent = <&ipic>;
mode = "cpu";
};
dma@82a8 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8349-dma", "fsl,elo-dma";
reg = <0x82a8 4>;
ranges = <0 0x8100 0x1a8>;
interrupt-parent = <&ipic>;
interrupts = <71 8>;
cell-index = <0>;
dma-channel@0 {
compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
reg = <0 0x80>;
interrupt-parent = <&ipic>;
interrupts = <71 8>;
};
dma-channel@80 {
compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
reg = <0x80 0x80>;
interrupt-parent = <&ipic>;
interrupts = <71 8>;
};
dma-channel@100 {
compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
reg = <0x100 0x80>;
interrupt-parent = <&ipic>;
interrupts = <71 8>;
};
dma-channel@180 {
compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
reg = <0x180 0x28>;
interrupt-parent = <&ipic>;
interrupts = <71 8>;
};
};
/* phy type (ULPI or SERIAL) are only types supported for MPH */
/* port = 0 or 1 */
usb@22000 {
compatible = "fsl-usb2-mph";
reg = <0x22000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
interrupt-parent = <&ipic>;
interrupts = <39 0x8>;
phy_type = "ulpi";
port1;
};
/* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
usb@23000 {
compatible = "fsl-usb2-dr";
reg = <0x23000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
interrupt-parent = <&ipic>;
interrupts = <38 0x8>;
dr_mode = "otg";
phy_type = "ulpi";
};
mdio@24520 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-mdio";
reg = <0x24520 0x20>;
phy0: ethernet-phy@0 {
interrupt-parent = <&ipic>;
interrupts = <17 0x8>;
reg = <0x0>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
interrupt-parent = <&ipic>;
interrupts = <18 0x8>;
reg = <0x1>;
device_type = "ethernet-phy";
};
enet0: ethernet@24000 {
cell-index = <0>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <0x24000 0x1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <32 0x8 33 0x8 34 0x8>;
interrupt-parent = <&ipic>;
phy-handle = <&phy0>;
linux,network-index = <0>;
};
enet1: ethernet@25000 {
cell-index = <1>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <0x25000 0x1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <35 0x8 36 0x8 37 0x8>;
interrupt-parent = <&ipic>;
phy-handle = <&phy1>;
linux,network-index = <1>;
};
serial0: serial@4500 {
cell-index = <0>;
device_type = "serial";
compatible = "ns16550";
reg = <0x4500 0x100>;
clock-frequency = <0>;
interrupts = <9 0x8>;
interrupt-parent = <&ipic>;
};
serial1: serial@4600 {
cell-index = <1>;
device_type = "serial";
compatible = "ns16550";
reg = <0x4600 0x100>;
clock-frequency = <0>;
interrupts = <10 0x8>;
interrupt-parent = <&ipic>;
};
crypto@30000 {
compatible = "fsl,sec2.0";
reg = <0x30000 0x10000>;
interrupts = <11 0x8>;
interrupt-parent = <&ipic>;
fsl,num-channels = <4>;
fsl,channel-fifo-len = <24>;
fsl,exec-units-mask = <0x7e>;
fsl,descriptor-types-mask = <0x01010ebf>;
};
Thanks,
agnel
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org<mailto:Linuxppc-dev@lists.ozlabs.org>
https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 47549 bytes --]
^ permalink raw reply
* dts file for MPC8343EA - cuImage doesn't boot , but uImage with DTS shows serial output
From: Junita Ajith @ 2009-12-09 17:57 UTC (permalink / raw)
To: Lee, Eric; +Cc: Linuxppc-dev@lists.ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 14046 bytes --]
Hi Eric,
I am building the linux kernel V-2.6.27 based on MPC8349miTXGP dts file.
I am still not able to boot the cuImage.
But, I see serial outuput from kernel when I try to boot with <kernel>
<ramdisk> <dtb file>
Still the kernel hangs after "Dentry cache hash table entries: 32768 (order:
5, 131072 bytes)".
Any clues ..?? We have DDR2 in this board and we are initializing it in
U-Boot.
Please find the screen dump below:
Thanks,
Junita
Screen shot:
===========
u-boot> bootm 0x2000000 0x3000000 0x4000000
## Booting image at 02000000 ...
Image Name: Linux-2.6.27.18-svn52-dirty8
Created: 2009-12-08 23:49:28 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1416039 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x0FF9BD48 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFFA6
bd address = 0x0FF9BFC4
memstart = 0x00000000
memsize = 0x10000000
flashstart = 0xFE000000
flashsize = 0x00080000
flashoffset = 0x00034000
sramstart = 0x00000000
sramsize = 0x00000000
bootflags = 0x00000001
intfreq = 399.999 MHz
busfreq = 266.666 MHz
ethaddr = 00:E0:0C:00:8C:01
IP addr = 192.168.201.199
baudrate = 115200 bps
Not skipping initrd
## Loading RAMDisk Image at 03000000 ...
Image Name: uboot ext2 ramdisk rootfs
Created: 2009-10-30 20:15:22 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 3889103 Bytes = 3.7 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Booting using the fdt at 0x4000000
## initrd at 0x03000040 ... 0x033B580E (len=3889103=0x3B57CF)
Loading Ramdisk to 0fbe5000, end 0ff9a7cf ... OK
## device tree at 0x04000000 ... 0x04002FFF (len=12288=0x3000)
Loading Device Tree to 007fc000, end 007fefff ... OK
Updating property '/soc8349@e0000000/ethernet@24000/mac-address' = 00 e0 0c
001Updating property '/soc8349@e0000000/ethernet@24000/local-mac-address' =
00 e01Updating property 'timebase-frequency' = 03 f9 40 aa
Updating property 'bus-frequency' = 0f e5 02 a8
Updating property 'clock-frequency' = 17 d7 83 fc
Updating property 'bus-frequency' = 0f e5 02 a8
Updating property 'clock-frequency' = 0f e5 02 a8
## Transferring control to Linux (at address 00000000) ...
Using MPC834x ITX machine description
Linux version 2.6.27.18-svn52-dirty8 (root@localhost.localdomain) (gcc
version 9Found initrd at 0xcfbe5000:0xcff9a7cf
console [udbg0] enabled
setup_arch: bootmem
mpc834x_itx_setup_arch()
arch: exit
Zone PFN ranges:
DMA 0x00000000 -> 0x00010000
Normal 0x00010000 -> 0x00010000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00010000
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/nfs rw nfsroot=192.168.200.230:/nfsroot/rootfs
i0IPIC (128 IRQ sources) at fdffc700
PID hash table entries: 1024 (order: 10, 4096 bytes)
clocksource: timebase mult[3c00001] shift[22] registered
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
On 12/9/09, Lee, Eric <eric.lee@hp.com> wrote:
>
> I would probably remove the bcsr region. this was some cpld I believe on a
> reference board. with this dts it'll try to write to some hardware
> registers that do not exist or are not mapped to the same area.
>
>
>
>
> -----Original Message-----
> From: linuxppc-dev-bounces+eric.lee=hp.com@lists.ozlabs.org [mailto:
> linuxppc-dev-bounces+eric.lee <linuxppc-dev-bounces%2Beric.lee>=hp.com@
> lists.ozlabs.org] On Behalf Of ajijuni@gmail.com
> Sent: Sunday, December 06, 2009 11:41 PM
> To: Linuxppc-dev@lists.ozlabs.org
> Subject: dts file for MPC8343EA
>
> Hi
>
> We have an MPC8343EA based custom board.
>
> I am not able to get Linux up and running in this. No serial output to
> debug further.
> U-boot shows correct 'bdinfo' & 'clocks' output.
> inux hangs at machine_probe.
>
>
> I doubt the DTS file in Linux. anyone has DTS file for MPC8343??
>
> u-boot version - 1.3.2
> linux-2.6.27
> The board base files are drived from MPC8349Imtx-GP since we have the
> reference board in which we tested the linux image.
>
> My current DTS file
> /dts-v1/;
>
> / {
> model = "MPC8343";
> compatible = "MPC8349EMDS", "MPC834xMDS", "MPC83xxMDS";
> linux,phandle = <0x100>;
> #size-cells = <0x1>;
> #address-cells = <0x1>;
>
> aliases {
> ethernet0 = &enet0;
> ethernet1 = &enet1;
> serial0 = &serial0;
> serial1 = &serial1;
> pci0 = &pci0;
> pci1 = &pci1;
> };
> cpus {
> linux,phandle = <0x200>;
> #cpus = <0x1>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> PowerPC,8343EA@0 {
> device_type = "cpu";
> reg = <0x0>;
> d-cache-line-size = <20>;
> i-cache-line-size = <20>;
> d-cache-size = <8000>;
> i-cache-size = <8000>;
> timebase-frequency = <0>; // from bootloader
> bus-frequency = <0>; // from bootloader
> clock-frequency = <0>; // from bootloader
> 32-bit;
> };
> };
>
>
> memory {
> device_type = "memory";
> reg = <0x00000000 0x10000000>; // 256MB at 0
> };
>
> bcsr@e2400000 {
> device_type = "board-control";
> reg = <0xe2400000 0x8000>;
> };
> soc8343@e0000000 {
> bus-frequency = <0x1>;
> reg = <0xe0000000 0x200>;
> ranges = <0x0 0xe0000000 0x100000>;
> device_type = "soc";
> #interrupt-cells = <0x2>;
> #size-cells = <0x1>;
> #address-cells = <0x1>;
>
> wdt@200 {
> device_type = "watchdog";
> compatible = "mpc83xx_wdt";
> reg = <0x200 0x100>;
> };
>
> i2c@3000 {
> #address-cells = <1>;
> #size-cells = <0>;
> cell-index = <0>;
> compatible = "fsl-i2c";
> reg = <0x3000 0x100>;
> interrupts = <14 0x8>;
> interrupt-parent = <&ipic>;
> dfsrr;
>
> rtc@68 {
> compatible = "dallas,ds1374";
> reg = <0x68>;
> };
> };
>
> i2c@3100 {
> #address-cells = <1>;
> #size-cells = <0>;
> cell-index = <1>;
> compatible = "fsl-i2c";
> reg = <0x3100 0x100>;
> interrupts = <15 0x8>;
> interrupt-parent = <&ipic>;
> dfsrr;
> };
>
> spi@7000 {
> cell-index = <0>;
> compatible = "fsl,spi";
> reg = <0x7000 0x1000>;
> interrupts = <16 0x8>;
> interrupt-parent = <&ipic>;
> mode = "cpu";
> };
>
> dma@82a8 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "fsl,mpc8349-dma", "fsl,elo-dma";
> reg = <0x82a8 4>;
> ranges = <0 0x8100 0x1a8>;
> interrupt-parent = <&ipic>;
> interrupts = <71 8>;
> cell-index = <0>;
> dma-channel@0 {
> compatible = "fsl,mpc8349-dma-channel",
> "fsl,elo-dma-channel";
> reg = <0 0x80>;
> interrupt-parent = <&ipic>;
> interrupts = <71 8>;
> };
> dma-channel@80 {
> compatible = "fsl,mpc8349-dma-channel",
> "fsl,elo-dma-channel";
> reg = <0x80 0x80>;
> interrupt-parent = <&ipic>;
> interrupts = <71 8>;
> };
> dma-channel@100 {
> compatible = "fsl,mpc8349-dma-channel",
> "fsl,elo-dma-channel";
> reg = <0x100 0x80>;
> interrupt-parent = <&ipic>;
> interrupts = <71 8>;
> };
> dma-channel@180 {
> compatible = "fsl,mpc8349-dma-channel",
> "fsl,elo-dma-channel";
> reg = <0x180 0x28>;
> interrupt-parent = <&ipic>;
> interrupts = <71 8>;
> };
> };
> /* phy type (ULPI or SERIAL) are only types supported for MPH */
> /* port = 0 or 1 */
> usb@22000 {
> compatible = "fsl-usb2-mph";
> reg = <0x22000 0x1000>;
> #address-cells = <1>;
> #size-cells = <0>;
> interrupt-parent = <&ipic>;
> interrupts = <39 0x8>;
> phy_type = "ulpi";
> port1;
> };
> /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
> usb@23000 {
> compatible = "fsl-usb2-dr";
> reg = <0x23000 0x1000>;
> #address-cells = <1>;
> #size-cells = <0>;
> interrupt-parent = <&ipic>;
> interrupts = <38 0x8>;
> dr_mode = "otg";
> phy_type = "ulpi";
> };
>
> mdio@24520 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "fsl,gianfar-mdio";
> reg = <0x24520 0x20>;
>
> phy0: ethernet-phy@0 {
> interrupt-parent = <&ipic>;
> interrupts = <17 0x8>;
> reg = <0x0>;
> device_type = "ethernet-phy";
> };
> phy1: ethernet-phy@1 {
> interrupt-parent = <&ipic>;
> interrupts = <18 0x8>;
> reg = <0x1>;
> device_type = "ethernet-phy";
> };
> enet0: ethernet@24000 {
> cell-index = <0>;
> device_type = "network";
> model = "TSEC";
> compatible = "gianfar";
> reg = <0x24000 0x1000>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> interrupts = <32 0x8 33 0x8 34 0x8>;
> interrupt-parent = <&ipic>;
> phy-handle = <&phy0>;
> linux,network-index = <0>;
> };
>
> enet1: ethernet@25000 {
> cell-index = <1>;
> device_type = "network";
> model = "TSEC";
> compatible = "gianfar";
> reg = <0x25000 0x1000>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> interrupts = <35 0x8 36 0x8 37 0x8>;
> interrupt-parent = <&ipic>;
> phy-handle = <&phy1>;
> linux,network-index = <1>;
> };
>
> serial0: serial@4500 {
> cell-index = <0>;
> device_type = "serial";
> compatible = "ns16550";
> reg = <0x4500 0x100>;
> clock-frequency = <0>;
> interrupts = <9 0x8>;
> interrupt-parent = <&ipic>;
> };
>
> serial1: serial@4600 {
> cell-index = <1>;
> device_type = "serial";
> compatible = "ns16550";
> reg = <0x4600 0x100>;
> clock-frequency = <0>;
> interrupts = <10 0x8>;
> interrupt-parent = <&ipic>;
> };
>
> crypto@30000 {
> compatible = "fsl,sec2.0";
> reg = <0x30000 0x10000>;
> interrupts = <11 0x8>;
> interrupt-parent = <&ipic>;
> fsl,num-channels = <4>;
> fsl,channel-fifo-len = <24>;
> fsl,exec-units-mask = <0x7e>;
> fsl,descriptor-types-mask = <0x01010ebf>;
> };
>
> Thanks,
> agnel
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
[-- Attachment #2: Type: text/html, Size: 16657 bytes --]
^ 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