* Re: [PATCH 2/5] [POWERPC][NET] ucc_geth_mii and users: get rid of device_type
From: Kumar Gala @ 2008-01-24 15:52 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev list
In-Reply-To: <20080124154001.GB23246@localhost.localdomain>
On Jan 24, 2008, at 9:40 AM, Anton Vorontsov wrote:
> device_type property is bogus, thus use proper compatible.
>
> Also change compatible property to "fsl,ucc-mdio".
>
> Per http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048388.html
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
can we look at using "fsl,gianfar-mdio" ? Meaning my understanding
the programming model for the UCC mdio is identical to gianfar MDIO
programming.
- k
^ permalink raw reply
* Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
From: Timur Tabi @ 2008-01-24 15:55 UTC (permalink / raw)
To: avorontsov
Cc: Poonam_Aggrwal-b10812, michael.barkowski, netdev, kumar.gala,
linux-kernel, rubini, linuxppc-dev, ashish.kalra, rich.cutler,
akpm
In-Reply-To: <20080124154804.GA22178@localhost.localdomain>
Anton Vorontsov wrote:
> Can we not introduce new pio-maps in the device trees? There
> were debates regarding this, and if I understood everything
> correctly, pio-maps considered as a bad taste. Better
> do bunch of par_io_config_pin() in the board file. Better
> yet fixup the firmware (u-boot) to set up dedicated pins
> correctly.
I'm on the fence with respect to pio-maps vs. par_io_config_pin() calls. The
problem is that the configuration of these pins is board-specific, but pins are
used by devices. A device driver can't call par_io_config_pin(), because the
calls are different depending on which SoC and which UCC you're using. The
platform code can't call par_io_config_pin(), because that configuration depends
on which drivers are loaded.
In other words, the pin configurations are dependent on the UCC configurations,
and the UCC configurations are stored in the device tree. So it makes sense to
put the pin configurations in the device tree, too.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 2/5] [POWERPC][NET] ucc_geth_mii and users: get rid of device_type
From: Anton Vorontsov @ 2008-01-24 16:11 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <53D750AF-AC04-47F6-8537-4F17206CC279@kernel.crashing.org>
On Thu, Jan 24, 2008 at 09:52:14AM -0600, Kumar Gala wrote:
>
> On Jan 24, 2008, at 9:40 AM, Anton Vorontsov wrote:
>
> >device_type property is bogus, thus use proper compatible.
> >
> >Also change compatible property to "fsl,ucc-mdio".
> >
> >Per http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048388.html
> >
> >Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>
> can we look at using "fsl,gianfar-mdio" ? Meaning my understanding
> the programming model for the UCC mdio is identical to gianfar MDIO
> programming.
I didn't look much into gianfar mii driver, so I can't tell.
Would "fsl,ucc-mdio", "fsl,gianfar-mdio" work for us? That way
we'll match on "fsl,ucc-mdio" today, and "fsl,gianfar-mdio" when/if
drivers are merged?
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] IB/ehca: Prevent sending UD packets to QP0
From: Joachim Fenkes @ 2008-01-24 16:59 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier, OF-EWG
Cc: Stefan Roscher, Christoph Raisch
IB spec doesn't allow packets to QP0 sent on any other VL than VL15.
Hardware doesn't filter those packets on the send side, so we need to do
this in the driver and firmware.
As eHCA doesn't support QP0, we can just filter out all traffic going to
QP0, regardless of SL or VL.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_reqs.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_reqs.c b/drivers/infiniband/hw/ehca/ehca_reqs.c
index 3aacc8c..2ce8cff 100644
--- a/drivers/infiniband/hw/ehca/ehca_reqs.c
+++ b/drivers/infiniband/hw/ehca/ehca_reqs.c
@@ -209,6 +209,10 @@ static inline int ehca_write_swqe(struct ehca_qp *qp,
ehca_gen_err("wr.ud.ah is NULL. qp=%p", qp);
return -EINVAL;
}
+ if (unlikely(send_wr->wr.ud.remote_qpn == 0)) {
+ ehca_gen_err("dest QP# is 0. qp=%x", qp->real_qp_num);
+ return -EINVAL;
+ }
my_av = container_of(send_wr->wr.ud.ah, struct ehca_av, ib_ah);
wqe_p->u.ud_av.ud_av = my_av->av;
--
1.5.2
^ permalink raw reply related
* Re: how to handle TARGET_CPM in cuboot-85xx?
From: Scott Wood @ 2008-01-24 16:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <0802475D-30B4-4954-96D9-39522FACCDBD@kernel.crashing.org>
On Thu, Jan 24, 2008 at 08:24:42AM -0600, Kumar Gala wrote:
> diff --git a/arch/powerpc/boot/cuboot-85xx.c b/arch/powerpc/boot/
> cuboot-85xx.c
> index 6776a1a..e2616f2 100644
> --- a/arch/powerpc/boot/cuboot-85xx.c
> +++ b/arch/powerpc/boot/cuboot-85xx.c
> @@ -15,6 +15,7 @@
> #include "cuboot.h"
>
> #define TARGET_85xx
> +#define TARGET_CPM2
> #include "ppcboot.h"
>
> static bd_t bd;
>
>
> --
>
> however it varies which boards need this. Should I just duplicate
> cuboot-85xx.c into cuboot-<boardname>.c as the way to handle this
> right now?
I don't think we need to go that fine grained -- one cuboot-85xx and one
cuboot-85xx-cpm2 should suffice.
-Scott
^ permalink raw reply
* [PATCH] powerpc: reduce code duplication in legacy_serial, add UART parent types
From: Paul Gortmaker @ 2008-01-24 17:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, Paul Gortmaker, arnd
In-Reply-To: <200801172335.48817.arnd@arndb.de>
The legacy_serial was treating each UART parent in a separate code block.
Rather than continue this trend for the new parent IDs, this condenses
all (soc, tsi, opb, plus two more new types) into one of_device_id array.
The new types are wrs,epld-localbus for the Wind River sbc8560, and a
more generic "simple-bus" as requested by Scott Wood.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/kernel/legacy_serial.c | 45 +++++++++++++---------------------
1 files changed, 17 insertions(+), 28 deletions(-)
diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index 4bfff88..523a9d4 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -4,6 +4,7 @@
#include <linux/serial_core.h>
#include <linux/console.h>
#include <linux/pci.h>
+#include <linux/of_device.h>
#include <asm/io.h>
#include <asm/mmu.h>
#include <asm/prom.h>
@@ -31,6 +32,15 @@ static struct legacy_serial_info {
int irq_check_parent;
phys_addr_t taddr;
} legacy_serial_infos[MAX_LEGACY_SERIAL_PORTS];
+
+static struct __init of_device_id parents[] = {
+ {.type = "soc",},
+ {.type = "tsi-bridge",},
+ {.type = "opb", .compatible = "ibm,opb",},
+ {.compatible = "simple-bus",},
+ {.compatible = "wrs,epld-localbus",},
+};
+
static unsigned int legacy_serial_count;
static int legacy_serial_console = -1;
@@ -306,18 +316,20 @@ void __init find_legacy_serial_ports(void)
DBG(" no linux,stdout-path !\n");
}
- /* First fill our array with SOC ports */
+ /* Iterate over all the 16550 ports, looking for known parents */
for_each_compatible_node(np, "serial", "ns16550") {
- struct device_node *soc = of_get_parent(np);
- if (soc && !strcmp(soc->type, "soc")) {
+ struct device_node *parent = of_get_parent(np);
+ if (!parent)
+ continue;
+ if (of_match_node(parents, parent) != NULL) {
index = add_legacy_soc_port(np, np);
if (index >= 0 && np == stdout)
legacy_serial_console = index;
}
- of_node_put(soc);
+ of_node_put(parent);
}
- /* First fill our array with ISA ports */
+ /* Next, fill our array with ISA ports */
for_each_node_by_type(np, "serial") {
struct device_node *isa = of_get_parent(np);
if (isa && !strcmp(isa->name, "isa")) {
@@ -328,29 +340,6 @@ void __init find_legacy_serial_ports(void)
of_node_put(isa);
}
- /* First fill our array with tsi-bridge ports */
- for_each_compatible_node(np, "serial", "ns16550") {
- struct device_node *tsi = of_get_parent(np);
- if (tsi && !strcmp(tsi->type, "tsi-bridge")) {
- index = add_legacy_soc_port(np, np);
- if (index >= 0 && np == stdout)
- legacy_serial_console = index;
- }
- of_node_put(tsi);
- }
-
- /* First fill our array with opb bus ports */
- for_each_compatible_node(np, "serial", "ns16550") {
- struct device_node *opb = of_get_parent(np);
- if (opb && (!strcmp(opb->type, "opb") ||
- of_device_is_compatible(opb, "ibm,opb"))) {
- index = add_legacy_soc_port(np, np);
- if (index >= 0 && np == stdout)
- legacy_serial_console = index;
- }
- of_node_put(opb);
- }
-
#ifdef CONFIG_PCI
/* Next, try to locate PCI ports */
for (np = NULL; (np = of_find_all_nodes(np));) {
--
1.5.0.rc1.gf4b6c
^ permalink raw reply related
* DTC 1.1.0 Release!
From: Jon Loeliger @ 2008-01-24 16:45 UTC (permalink / raw)
To: linuxppc-dev
Folks,
I have tagged and released a DTC 1.1.0.
You may find it using git here:
git://www.jdl.com/software/dtc
A tarball snap-shot is also available here:
http://www.jdl.com/software/dtc-1.1.0.tgz
Please let me know if there are problems with it!
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
From: Anton Vorontsov @ 2008-01-24 16:23 UTC (permalink / raw)
To: Timur Tabi
Cc: Poonam_Aggrwal-b10812, michael.barkowski, netdev, kumar.gala,
linux-kernel, rubini, linuxppc-dev, ashish.kalra, rich.cutler,
akpm
In-Reply-To: <4798B4F3.2010101@freescale.com>
On Thu, Jan 24, 2008 at 09:55:31AM -0600, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> >Can we not introduce new pio-maps in the device trees? There
> >were debates regarding this, and if I understood everything
> >correctly, pio-maps considered as a bad taste. Better
> >do bunch of par_io_config_pin() in the board file. Better
> >yet fixup the firmware (u-boot) to set up dedicated pins
> >correctly.
>
> I'm on the fence with respect to pio-maps vs. par_io_config_pin() calls.
> The problem is that the configuration of these pins is board-specific, but
> pins are used by devices. A device driver can't call par_io_config_pin(),
> because the calls are different depending on which SoC and which UCC you're
> using. The platform code can't call par_io_config_pin(), because that
> configuration depends on which drivers are loaded.
Are you saying that TDM is sharing same pins with the other QE device,
and we can choose to use/not use some device depending on which driver
is loaded? I think this particular board and patch isn't that case.
Even if someday there will be the case when drivers are mutually
exclusive, i.e. presence of some driver should trigger pins
reconfiguration, then anyway this should be handled differently.
That is, we should not _register_ two mutually exclusive devices
in the first place, so drivers will not probe them. That's board
setup code authority, and pins configuration still should happen
there.
[ Irrelevant to UCCs and this particular case: lately I've
encountered one interesting case of Par IO usage. FHCI USB needs
switching between pin's dedicated functions and GPIO functions.
So, firstly it is using pins as dedicated, and later (at the bus
reset) driver turns them to act as GPIOs. This is still handled
without pio-map though, via gpios = <> property for that driver. ]
> In other words, the pin configurations are dependent on the UCC
> configurations, and the UCC configurations are stored in the device tree.
> So it makes sense to put the pin configurations in the device tree, too.
In that particular case UCC configuration is static, for every UCC.
So, we can set up all pins in the firmware/board file.
Please correct me if I'm wrong.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
From: Anton Vorontsov @ 2008-01-24 17:23 UTC (permalink / raw)
To: Timur Tabi
Cc: Poonam_Aggrwal-b10812, michael.barkowski, netdev, kumar.gala,
linux-kernel, rubini, linuxppc-dev, ashish.kalra, rich.cutler,
akpm
In-Reply-To: <4798BDEB.2010501@freescale.com>
On Thu, Jan 24, 2008 at 10:33:47AM -0600, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> >Are you saying that TDM is sharing same pins with the other QE device,
> >and we can choose to use/not use some device depending on which driver
> >is loaded?
>
> No. I'd have to closely examine the DTS, but I don't think that UCC
> devices share pins at all. But that isn't my point.
>
> >In that particular case UCC configuration is static, for every UCC.
> >So, we can set up all pins in the firmware/board file.
>
> Yes, but deciding what the UCC does might not be static. At what point do
> we declare, "UCC5 is for eth0 and eth0 only"?
>
> The advantage of putting the pin configurations in the device tree is that
> they now become configurable. I can envision a scenario where UCC5 could
> be either an Ethernet or a UART, depending on the setting of some jumpers
> on the board. That's what the QE was designed for: any UCC can do any task,
> and you can even have a UCC change its purpose while the system is running.
> So I don't want the pin configurations hard-coded into the kernel. Having
> them in the device tree gives me some flexibility.
If hardware configuration is selected at the bootup time, by jumpers
or switches, it's even easier to do it right. Without pio-map.
> For instance, I have a plan (that I keep postponing) to introduce a new
> feature in U-Boot where U-Boot can determine the settings of some board
> jumpers and modify the device tree accordingly. The instructions on how to
> modify the device tree would be embedded in the tree itself.
Why you need to modify the device tree for that? Let the U-Boot simply
setup pins for the kernel. Regarding kernel overwriting pins
configuration...
> I can't
> support this feature if the kernel calls par_io_config_pin() regardless of
> what's in the device tree.
What I've understood from the previous debates, is that ideally kernel
should not touch pins' configuration. Today we're using pio-map solely
to fix up some old firmware misconfiguration. And we can do this in the
board file still. To determine if we need to fixup the firmware or not,
we can use some device tree property instead (firmware version?).
p.s.
I'm neither for pio-map nor against. I just want some consequence
regarding this. Last thread ended with consequence that pio-map is a
bad thing to use...
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
From: Timur Tabi @ 2008-01-24 16:33 UTC (permalink / raw)
To: avorontsov
Cc: Poonam_Aggrwal-b10812, michael.barkowski, netdev, kumar.gala,
linux-kernel, rubini, linuxppc-dev, ashish.kalra, rich.cutler,
akpm
In-Reply-To: <20080124162345.GA27359@localhost.localdomain>
Anton Vorontsov wrote:
> Are you saying that TDM is sharing same pins with the other QE device,
> and we can choose to use/not use some device depending on which driver
> is loaded?
No. I'd have to closely examine the DTS, but I don't think that UCC devices
share pins at all. But that isn't my point.
> In that particular case UCC configuration is static, for every UCC.
> So, we can set up all pins in the firmware/board file.
Yes, but deciding what the UCC does might not be static. At what point do we
declare, "UCC5 is for eth0 and eth0 only"?
The advantage of putting the pin configurations in the device tree is that they
now become configurable. I can envision a scenario where UCC5 could be either
an Ethernet or a UART, depending on the setting of some jumpers on the board.
That's what the QE was designed for: any UCC can do any task, and you can even
have a UCC change its purpose while the system is running. So I don't want the
pin configurations hard-coded into the kernel. Having them in the device tree
gives me some flexibility.
For instance, I have a plan (that I keep postponing) to introduce a new feature
in U-Boot where U-Boot can determine the settings of some board jumpers and
modify the device tree accordingly. The instructions on how to modify the
device tree would be embedded in the tree itself. I can't support this feature
if the kernel calls par_io_config_pin() regardless of what's in the device tree.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v5 0/5] device_type/compatible cleanups
From: Anton Vorontsov @ 2008-01-24 17:35 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080124151850.GA15190@localhost.localdomain>
On Thu, Jan 24, 2008 at 06:18:50PM +0300, Anton Vorontsov wrote:
[..]
> Documentation/powerpc/booting-without-of.txt | 26 +--
> arch/powerpc/boot/dts/mpc832x_mds.dts | 11 -
> arch/powerpc/boot/dts/mpc832x_rdb.dts | 11 -
> arch/powerpc/boot/dts/mpc836x_mds.dts | 11 -
> arch/powerpc/boot/dts/mpc836x_rdk.dts | 10 -
> arch/powerpc/boot/dts/mpc8568mds.dts | 10 -
> arch/powerpc/sysdev/fsl_soc.c | 191 +++++++++++++++----------
> b/Documentation/powerpc/booting-without-of.txt | 11 -
> b/arch/powerpc/boot/dts/mpc8313erdb.dts | 4
> b/arch/powerpc/boot/dts/mpc832x_mds.dts | 9 -
> b/arch/powerpc/boot/dts/mpc832x_rdb.dts | 10 -
> b/arch/powerpc/boot/dts/mpc8349emitx.dts | 4
> b/arch/powerpc/boot/dts/mpc8349emitxgp.dts | 4
> b/arch/powerpc/boot/dts/mpc834x_mds.dts | 4
> b/arch/powerpc/boot/dts/mpc836x_mds.dts | 10 -
> b/arch/powerpc/boot/dts/mpc836x_rdk.dts | 1
> b/arch/powerpc/boot/dts/mpc8568mds.dts | 10 -
> b/arch/powerpc/kernel/legacy_serial.c | 3
> b/arch/powerpc/platforms/83xx/mpc832x_mds.c | 11 -
> b/arch/powerpc/platforms/83xx/mpc832x_rdb.c | 11 -
> b/arch/powerpc/platforms/83xx/mpc836x_mds.c | 11 -
> b/arch/powerpc/platforms/85xx/mpc85xx_mds.c | 32 ++--
> b/arch/powerpc/sysdev/fsl_soc.c | 5
> b/arch/powerpc/sysdev/qe_lib/qe.c | 64 +++++---
> b/drivers/net/ucc_geth_mii.c | 4
> b/drivers/spi/spi_mpc83xx.c | 10 -
> 26 files changed, 284 insertions(+), 204 deletions(-)
Heh. `git-format-patch --stdout -5 | diffstat` doesn't work correctly.
Once I've already stumbled against this, but obviously forgot.
Here is correct diffstat summary:
Documentation/powerpc/booting-without-of.txt | 37 +++----
arch/powerpc/boot/dts/mpc8313erdb.dts | 4
arch/powerpc/boot/dts/mpc832x_mds.dts | 20 +--
arch/powerpc/boot/dts/mpc832x_rdb.dts | 21 ++-
arch/powerpc/boot/dts/mpc8349emitx.dts | 4
arch/powerpc/boot/dts/mpc8349emitxgp.dts | 4
arch/powerpc/boot/dts/mpc834x_mds.dts | 4
arch/powerpc/boot/dts/mpc836x_mds.dts | 21 ++-
arch/powerpc/boot/dts/mpc836x_rdk.dts | 11 --
arch/powerpc/boot/dts/mpc8568mds.dts | 20 ++-
arch/powerpc/kernel/legacy_serial.c | 3
arch/powerpc/platforms/83xx/mpc832x_mds.c | 11 +-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 11 +-
arch/powerpc/platforms/83xx/mpc836x_mds.c | 11 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 32 +++---
arch/powerpc/sysdev/fsl_soc.c | 142 ++++++++++++++++++---------
arch/powerpc/sysdev/qe_lib/qe.c | 63 ++++++++---
drivers/net/ucc_geth_mii.c | 3
drivers/spi/spi_mpc83xx.c | 6 -
19 files changed, 258 insertions(+), 170 deletions(-)
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH v5 0/5] device_type/compatible cleanups
From: Jon Loeliger @ 2008-01-24 18:26 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080124173511.GA16288@localhost.localdomain>
> Heh. `git-format-patch --stdout -5 | diffstat` doesn't work correctly.
> Once I've already stumbled against this, but obviously forgot.
Might try:
git diff --stat HEAD~4
or such!
Enjoy,
jdl
^ permalink raw reply
* Re: [PATCH UCC TDM 3/3 ] Modified Documentation to explain dts entries for TDM driver
From: Scott Wood @ 2008-01-24 20:12 UTC (permalink / raw)
To: Poonam_Aggrwal-b10812
Cc: michael.barkowski, netdev, kumar.gala, linux-kernel, rubini,
linuxppc-dev, ashish.kalra, rich.cutler, akpm, timur
In-Reply-To: <Pine.LNX.4.64.0801241022070.27491@linux121>
On Thu, Jan 24, 2008 at 10:24:13AM +0530, Poonam_Aggrwal-b10812 wrote:
> + ix) Baud Rate Generator (BRG)
> +
> + Required properties:
> + - compatible : shpuld be "fsl,cpm-brg"
> + - fsl,brg-sources : define the input clock for all 16 BRGs. The input
> + clock source could be 1 to 24 for CLK1 to CLK24. Zero means that the
> + particular BRG will be driven by QE clock(BRGCLK).
Should also have a clock-frequency property to specify what BRGCLK is.
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Port STX GP3 board over from arch/ppc
From: Scott Wood @ 2008-01-24 20:19 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0801240041530.22238@blarg.am.freescale.net>
On Thu, Jan 24, 2008 at 12:43:38AM -0600, Kumar Gala wrote:
> + d-cache-size = <0x8000>; // L1, 32K
> + i-cache-size = <0x8000>; // L1, 32K
> + timebase-frequency = <0x4ead9a0>;
> + bus-frequency = <0x13ab6680>;
> + clock-frequency = <0x312c8040>;
Decimal, please.
> + soc8560@fdf00000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + ranges = <0 0xfdf00000 0x100000>;
> + reg = <0xfdf00000 0x1000>;
compatible = "fsl,mpc8560-immr", "simple-bus".
Also add "simple-bus" to the CPM node.
> + bus-frequency = <0x13ab6680>;
Decimal, please -- if it needs to exist at all.
> @@ -49,7 +57,7 @@ config MPC8540
> config MPC8560
> bool
> select CPM2
> - default y if MPC8560_ADS
> + default y if MPC8560_ADS || STX_GP3
Can we select this from 8560 boards, instead of a default y list?
> +static struct of_device_id __initdata of_bus_ids[] = {
> + { .name = "soc", },
> + { .type = "soc", },
> + { .name = "cpm", },
> + { .name = "localbus", },
> + {},
> +};
compatible = "simple-bus".
> +/*
> + * Called very early, device-tree isn't unflattened
> + */
> +static int __init stx_gp3_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> +
> + return of_flat_dt_is_compatible(root, "stx,gp3-8560");
> +}
Tabs, not spaces.
-Scott
^ permalink raw reply
* Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
From: Scott Wood @ 2008-01-24 20:24 UTC (permalink / raw)
To: Timur Tabi
Cc: Poonam_Aggrwal-b10812, michael.barkowski, netdev, kumar.gala,
linux-kernel, rubini, linuxppc-dev, ashish.kalra, rich.cutler,
akpm
In-Reply-To: <4798BDEB.2010501@freescale.com>
On Thu, Jan 24, 2008 at 10:33:47AM -0600, Timur Tabi wrote: Yes, but
> deciding what the UCC does might not be static. At what point do we
> declare, "UCC5 is for eth0 and eth0 only"?
When the board designer decides to hook eth0 up to UCC5.
If the board designer decides to hook multiple devices up to UCC5, we first
smack the board designer, and then set it up to whichever configuration has
been jumpered.
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] MPC8360E-RDK: device tree, board file and defconfig
From: Stephen Rothwell @ 2008-01-24 20:58 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080124132900.GA25982@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]
Hi Anton,
On Thu, 24 Jan 2008 16:29:01 +0300 Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> On Thu, Jan 24, 2008 at 01:22:01PM +1100, Stephen Rothwell wrote:
> > On Wed, 23 Jan 2008 23:45:07 +0300 Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> > >
> > > +++ b/arch/powerpc/platforms/83xx/mpc836x_rdk.c
> > > +static int __init mpc836x_rdk_declare_of_platform_devices(void)
> > > +{
> > > + const struct of_device_id mpc836x_rdk_ids[] = {
> >
> > Please change this to static, __initdata and not const, thanks. These
> > arrays are usually defined outside a function, but that is not really a
> > problem.
>
> Pity... we don't need these _ids anywhere outside that function. But
> looking into objdump output I see the problem now.
>
> Will change this back, thanks.
>
> > > +static void __init mpc836x_rdk_setup_arch(void)
> > > +{
> > > + struct device_node *np;
> >
> > !defined(CONFIG_PCI) && !defined(CONFIG_QUICC_ENGINE) will produce a
> > warning here.
>
> Good catch, thanks.
>
> > > + if (ppc_md.progress)
> > > + ppc_md.progress("mpc836x_rdk_setup_arch()", 0);
> > > +
> > > +#ifdef CONFIG_PCI
> > > + for_each_compatible_node(np, "pci", "fsl,mpc8349-pci")
> > > + mpc83xx_add_bridge(np);
> > > +#endif
> > > +
> > > +#ifdef CONFIG_QUICC_ENGINE
> > > + qe_reset();
> > > +
> > > + np = of_find_compatible_node(NULL, NULL, "fsl,qe-pario");
> > > + if (!np) {
> > > + pr_warning("QE PIO not initialized!\n");
> > > + return;
> >
> > You need an of_node_put(np) before the return.
>
> Hm, really? I think I don't. But if you insist... :-)
Sorry, I don't know what I was thinking - of course you don't need it.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Failed to mount rootfs
From: Bizhan Gholikhamseh (bgholikh) @ 2008-01-24 21:53 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 12945 bytes --]
Hi All,
Our custom board is leveraged from MPC8541cds from freescale.
We have been running Linux 2.6.11 on it recently I have tried to boot
the system with the latest Linux 2.6.22-rc4 from PowerPC git tree.
I did ported the libfdt to our older version of the uboot and were able
to
resolve the device tree. After downloading the uImage, dtb file and
ramdisk
I use the bootm command to boot the linux, but it failes..
........................................................................
...................
driver initialized: 16 RAM disks of 4096K size 1024 blocksize
VFS: Cannot open root device "<NULL>" or unknown-block(0,0) Please
append a correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0) Rebooting in 180 seconds..
........................................................................
...............
During boot I observeed that the "kernel Command Line:" is empty, is
this parameter should be supplied by fdt also?
I have copied the boot log and dump of the device tree below, Any help
greatly appreicate it.
Thanks,
Last Reset Type: Power On
FLASH: 8 MB
L2 cache 256KB:enabled
In: serial
Out: serial
Err: serial
Net: TSEC0.
IDE: Compact Flash: Bus 0: OK
Device 0: Model: STI Flash 7.4.0 Firm: 01.25.06 Ser#: STI
J106306241050439
Type: Hard Disk
Capacity: 245.0 MB = 0.2 GB (501760 x 512) System watchdog: is now
stopped.
=> printenv
bootcmd=setenv bootargs root=/dev/hda2 rw console=$consoledev,$baudrate
$othbootargs;setenv autostart yes;diskboot $l; nfsboot=setenv bootargs
root=/dev/nfs rw nfsroot=$serverip:$rootpath
ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostnar
bootdelay=2
baudrate=115200
loads_echo=1
rootpath=/nfsroot
hostname=unknown
loadaddr=1000000
netdev=eth0
consoledev=ttyS1
ramdiskaddr=1000000
ramdiskfile=ramdisk.UBoot
ethact=TSEC0
firstboot=no
bootargs=root=/dev/ram rw console=ttyS1,115200 fdfile=biz3.dtb
bootfile=uImage
ramboot=setenv bootargs root=/dev/ram rw console=ttyS1,115200
filesize=80000 fileaddr=100000
ipaddr=172.28.176.13
serverip=172.28.176.140
stdin=serial
stdout=serial
stderr=serial
ethaddr=00:18:18:8f:a6:ac
eth1addr=00:18:18:8f:a6:ad
eth2addr=00:18:18:8f:a6:ae
pid=CTS-CODEC-PRIM=
serial=FSJC0537522
ver_id=V01
hwver=0400
ver=U-boot 1.1.2(pq3-20050113-0) (Jan 20 2008 - 18:03:58)
Environment size: 1050/8188 bytes
=> tftp 100000 uImage
Using TSEC0 device
TFTP from server 172.28.176.140; our IP address is 172.28.176.13
Filename 'uImage'.
Load address: 0x100000
Loading:
#################################################################
###########################################################
done
Bytes transferred = 629989 (99ce5 hex)
=> tftp 2000000 ramdisk.u-boot
Using TSEC0 device
TFTP from server 172.28.176.140; our IP address is 172.28.176.13
Filename 'ramdisk.u-boot'.
Load address: 0x2000000
Loading:
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
done
Bytes transferred = 15622378 (ee60ea hex) => tftp c00000 board.dtb Using
TSEC0 device TFTP from server 172.28.176.140; our IP address is
172.28.176.13 Filename 'board.dtb'.
Load address: 0xc00000
Loading: #
done
Bytes transferred = 4273 (10b1 hex)
=> bootm 100000 2000000 c00000
## Booting image at 00100000 ...
Image Name: Linux-2.6.22-rc4-geff2ebd2-dirty
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 629925 Bytes = 615.2 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
>>> inside do_bootm_linux <<<<
## Loading RAMDisk Image at 02000000 ...
Image Name: MPC85xxCDS MTWKS Ramdisk
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 15622314 Bytes = 14.9 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Booting using flat device tree at 0xc00000
Loading Ramdisk to 1ef33000, end 1fe190aa ... OK vfpga watchdog not
supported in this CTS version. Keeping watchdog disabled System
watchdog: is now stopped.
## Transferring control to Kernel (at address 00000000) ...
Using MPC85xx CDS machine description
Memory CAM mapping: CAM0=256Mb, CAM1=256Mb, CAM2=0Mb residual: 0Mb Linux
version 2.6.22-rc4-geff2ebd2-dirty (bizhan@bizhanhost.cisco.com) (gcc
version 3.4.3) #6 Sun Jan 20 22:51:26 PST8
setup_arch: bootmem
mpc85xx_cds_setup_arch()
CDS Version = 0xff in slot 4
Found MPC85xx PCI host bridge at 0x00000000e0008000. Firmware bus
number: 0->0 Found MPC85xx PCI host bridge at 0x00000000e0009000.
Firmware bus number: 0->0
arch: exit
Zone PFN ranges:
DMA 0 -> 131072
Normal 131072 -> 131072
early_node_map[1] active PFN ranges
0: 0 -> 131072
Built 1 zonelists. Total pages: 130048
Kernel command line:
mpic: Setting up MPIC " OpenPIC " version 1.2 at e0040000, max 1 CPUs
mpic: ISU size: 4, shift: 2, mask: 3
mpic: Initializing for 60 sources
PID hash table entries: 2048 (order: 11, 8192 bytes) Dentry cache hash
table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table
entries: 32768 (order: 5, 131072 bytes)
Memory: 502528k/524288k available (1224k kernel code, 21196k reserved,
64k data, 108k bss, 116k init) Mount-cache hash table entries: 512
device-tree: Duplicate name in /, renamed to "chosen#1"
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of device 0000:00:16.0
PCI: Cannot allocate resource region 1 of device 0000:00:16.0
PCI: Cannot allocate resource region 0 of device 0000:00:19.0
PCI: Cannot allocate resource region 2 of device 0000:00:19.0
PCI: Cannot allocate resource region 0 of device 0001:00:15.0
PCI: Cannot allocate resource region 1 of device 0001:00:15.0
PCI: Cannot allocate resource region 2 of device 0001:00:15.0 io
scheduler noop registered (default)
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 26) is a 16550A....?50.0:
ttyS1 at MMIO 0xe0004600 (irq = 26) is a 16 A
] RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
VFS: Cannot open root device "<NULL>" or unknown-block(0,0) Please
append a correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0) Rebooting in 180 seconds..
And here is the device tree:
/memreserve/ a 0;
{
model = "MPC8541CDS";
compatible = [4d 50 43 38 35 34 31 43 44 53 00 4d 50 43 38 35 78 78
43 44 53 00];
#address-cells = <1>;
#size-cells = <1>;
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8541@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>;
i-cache-line-size = <20>;
d-cache-size = <8000>;
i-cache-size = <8000>;
timebase-frequency = <1f78a40>;
bus-frequency = <fbc5200>;
clock-frequency = <1f78a400>;
32-bit;
};
};
memory {
device_type = "memory";
reg = <8>;
};
soc8541@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "soc";
ranges = [00 00 00 00 e0 00 00 00 00 10 00 00];
reg = <8>;
bus-frequency = <0>;
memory-controller@2000 {
compatible = "fsl,8541-memory-controller";
reg = <8>;
interrupt-parent = <1>;
interrupts = <8>;
};
l2-cache-controller@20000 {
compatible = "fsl,8541-l2-cache-controller";
reg = <8>;
cache-line-size = <20>;
cache-size = <40000>;
interrupt-parent = <1>;
interrupts = <8>;
};
i2c@3000 {
device_type = "i2c";
compatible = "fsl-i2c";
reg = <8>;
interrupts = <8>;
interrupt-parent = <1>;
dfsrr;
};
mdio@24520 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "mdio";
compatible = "gianfar";
reg = <8>;
ethernet-phy@0 {
interrupt-parent = <1>;
interrupts = <8>;
reg = <0>;
device_type = "ethernet-phy";
linux,phandle = <2>;
};
ethernet-phy@1 {
interrupt-parent = <1>;
interrupts = <8>;
reg = <1>;
device_type = "ethernet-phy";
};
};
ethernet@24000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <8>;
local-mac-address = [00 18 18 8f a6 ac];
interrupts = [00 00 00 0d 00 00 00 02 00 00 00 0e 00 00 00
02 00 00 00 12 00 00 00 02];
interrupt-parent = <1>;
phy-handle = <2>;
};
serial@4500 {
device_type = "serial";
compatible = "ns16550";
reg = <8>;
clock-frequency = <fbc5200>;
interrupts = <8>;
interrupt-parent = <1>;
};
serial@4600 {
device_type = "serial";
compatible = "ns16550";
reg = <8>;
clock-frequency = <fbc5200>;
interrupts = <8>;
interrupt-parent = <1>;
};
pci@8000 {
interrupt-map-mask = [00 01 f8 00 00 00 00 00 00 00 00 00 00
00 00 07];
interrupt-map = [00 00 80 00 00 00 00 00 00 00 00 00 00 00
00 04 00 00 00 01 00 00 00 30 00 00 00 01 00 0;
interrupt-parent = <1>;
interrupts = <8>;
bus-range = <8>;
ranges = [02 00 00 00 00 00 00 00 80 00 00 00 80 00 00 00 00
00 00 00 20 00 00 00 01 00 00 00 00 00 00 00;
clock-frequency = <3f940aa>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <8>;
compatible = "85xx";
device_type = "pci";
linux,phandle = <3>;
i8259@19000 {
clock-frequency = <0>;
interrupt-controller;
device_type = "interrupt-controller";
reg = [00 01 90 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 01];
#address-cells = <0>;
#interrupt-cells = <2>;
built-in;
compatible = "chrp,iic";
big-endian;
interrupts = <1>;
interrupt-parent = <3>;
};
};
pci@9000 {
interrupt-map-mask = [00 00 f8 00 00 00 00 00 00 00 00 00 00
00 00 07];
interrupt-map = [00 00 a8 00 00 00 00 00 00 00 00 00 00 00
00 01 00 00 00 01 00 00 00 3b 00 00 00 01 00 0;
interrupt-parent = <1>;
interrupts = <8>;
bus-range = <8>;
ranges = [02 00 00 00 00 00 00 00 a0 00 00 00 a0 00 00 00 00
00 00 00 20 00 00 00 01 00 00 00 00 00 00 00;
clock-frequency = <3f940aa>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <8>;
compatible = "85xx";
device_type = "pci";
};
pic@40000 {
clock-frequency = <0>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <8>;
built-in;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
linux,phandle = <1>;
};
};
chosen {
linux,stdout-path = "/soc8541@e0000000/serial@4600";
};
chosen {
name = "chosen";
bootargs = "root=/dev/ram rw console=ttyS1,115200";
linux,platform = <600>;
linux,initrd-start = <1ef33000>;
linux,initrd-end = <1fe190aa>;
linux,stdout-path = "/soc8541@e0000000/serial@4600";
};
};
[-- Attachment #2: Type: text/html, Size: 31020 bytes --]
^ permalink raw reply
* Re: Failed to mount rootfs
From: Jochen Friedrich @ 2008-01-24 22:12 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA911279641502D1A9F4@xmb-sjc-212.amer.cisco.com>
Hi Bizhan,
> device-tree: Duplicate name in /, renamed to "chosen#1"
> And here is the device tree:
> chosen {
> linux,stdout-path = "/soc8541@e0000000/serial@4600";
> };
> chosen {
> name = "chosen";
> bootargs = "root=/dev/ram rw console=ttyS1,115200";
> linux,platform = <600>;
> linux,initrd-start = <1ef33000>;
> linux,initrd-end = <1fe190aa>;
> linux,stdout-path = "/soc8541@e0000000/serial@4600";
> };
you can't have two chosen nodes. Linux renames the second one to chosen#1 and thus can't find the kernel arguments.
Thanks,
Jochen
^ permalink raw reply
* Re: [i2c] [PATCH] mpc i2c driver, compare to NO_IRQ instead of zero
From: Jon Smirl @ 2008-01-24 22:32 UTC (permalink / raw)
To: i2c, linuxppc-dev
In-Reply-To: <20080121200740.13800.20524.stgit@terra.home>
Ben, do you approve of this? How should error be checked for, is
<NO_IRQ right? The current code in the kernel looks to be broken
because of these checks, the ppc build is wrong and powerpc polled
mode doesn't work.
On 1/21/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> Alter the mpc i2c driver to use the NO_IRQ symbol instead of the constant zero when checking for valid interrupts. NO_IRQ=-1 on ppc and NO_IRQ=0 on powerpc so the checks against zero are not correct.
>
> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
> ---
>
> drivers/i2c/busses/i2c-mpc.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
>
> diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
> index bbe787b..d20959d 100644
> --- a/drivers/i2c/busses/i2c-mpc.c
> +++ b/drivers/i2c/busses/i2c-mpc.c
> @@ -99,7 +99,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
> u32 x;
> int result = 0;
>
> - if (i2c->irq == 0)
> + if (i2c->irq == NO_IRQ)
> {
> while (!(readb(i2c->base + MPC_I2C_SR) & CSR_MIF)) {
> schedule();
> @@ -329,7 +329,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> i2c->irq = platform_get_irq(pdev, 0);
> - if (i2c->irq < 0) {
> + if (i2c->irq < NO_IRQ) {
> result = -ENXIO;
> goto fail_get_irq;
> }
> @@ -344,7 +344,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> goto fail_map;
> }
>
> - if (i2c->irq != 0)
> + if (i2c->irq != NO_IRQ)
> if ((result = request_irq(i2c->irq, mpc_i2c_isr,
> IRQF_SHARED, "i2c-mpc", i2c)) < 0) {
> printk(KERN_ERR
> @@ -367,7 +367,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> return result;
>
> fail_add:
> - if (i2c->irq != 0)
> + if (i2c->irq != NO_IRQ)
> free_irq(i2c->irq, i2c);
> fail_irq:
> iounmap(i2c->base);
> @@ -384,7 +384,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
> i2c_del_adapter(&i2c->adap);
> platform_set_drvdata(pdev, NULL);
>
> - if (i2c->irq != 0)
> + if (i2c->irq != NO_IRQ)
> free_irq(i2c->irq, i2c);
>
> iounmap(i2c->base);
>
>
> _______________________________________________
> i2c mailing list
> i2c@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/i2c
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* RE: Failed to mount rootfs
From: Bizhan Gholikhamseh (bgholikh) @ 2008-01-24 22:25 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-embedded
In-Reply-To: <47990D51.9080803@scram.de>
Hi Jochen,=20
>=20
> > device-tree: Duplicate name in /, renamed to "chosen#1"
>=20
> > And here is the device tree:
> > chosen {
> > linux,stdout-path =3D "/soc8541@e0000000/serial@4600";
> > };
> > chosen {
> > name =3D "chosen";
> > bootargs =3D "root=3D/dev/ram rw console=3DttyS1,115200";
> > linux,platform =3D <600>;
> > linux,initrd-start =3D <1ef33000>;
> > linux,initrd-end =3D <1fe190aa>;
> > linux,stdout-path =3D "/soc8541@e0000000/serial@4600";
> > };
>=20
> you can't have two chosen nodes. Linux renames the second one=20
> to chosen#1 and thus can't find the kernel arguments.
>
I do not know why it is creating two chosen node. In my dts file I have
placed one empty chosen node:=20
chosen{
};
If I do not do this, I get the following error during boot process:
libfdt: FDT_ERR_TRUNCATED
Failed creating the /chosen node (0x00C00000), aborting.
Any reason??
=20
Thanks,
Bizhan
^ permalink raw reply
* Re: [i2c] [PATCH] mpc i2c driver, compare to NO_IRQ instead of zero
From: Benjamin Herrenschmidt @ 2008-01-24 22:35 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, i2c
In-Reply-To: <9e4733910801241432r4424d41ayd5e41e57bc3e052b@mail.gmail.com>
On Thu, 2008-01-24 at 17:32 -0500, Jon Smirl wrote:
> Ben, do you approve of this? How should error be checked for, is
> <NO_IRQ right? The current code in the kernel looks to be broken
> because of these checks, the ppc build is wrong and powerpc polled
> mode doesn't work.
== 0 should work on powerpc since NO_IRQ is defined to be 0 there no ?
Anyway, using the symbolic constant is always nicer I suppose.
Ben.
> On 1/21/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> > Alter the mpc i2c driver to use the NO_IRQ symbol instead of the constant zero when checking for valid interrupts. NO_IRQ=-1 on ppc and NO_IRQ=0 on powerpc so the checks against zero are not correct.
> >
> > Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
> > ---
> >
> > drivers/i2c/busses/i2c-mpc.c | 10 +++++-----
> > 1 files changed, 5 insertions(+), 5 deletions(-)
> >
> >
> > diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
> > index bbe787b..d20959d 100644
> > --- a/drivers/i2c/busses/i2c-mpc.c
> > +++ b/drivers/i2c/busses/i2c-mpc.c
> > @@ -99,7 +99,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
> > u32 x;
> > int result = 0;
> >
> > - if (i2c->irq == 0)
> > + if (i2c->irq == NO_IRQ)
> > {
> > while (!(readb(i2c->base + MPC_I2C_SR) & CSR_MIF)) {
> > schedule();
> > @@ -329,7 +329,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> > return -ENOMEM;
> >
> > i2c->irq = platform_get_irq(pdev, 0);
> > - if (i2c->irq < 0) {
> > + if (i2c->irq < NO_IRQ) {
> > result = -ENXIO;
> > goto fail_get_irq;
> > }
> > @@ -344,7 +344,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> > goto fail_map;
> > }
> >
> > - if (i2c->irq != 0)
> > + if (i2c->irq != NO_IRQ)
> > if ((result = request_irq(i2c->irq, mpc_i2c_isr,
> > IRQF_SHARED, "i2c-mpc", i2c)) < 0) {
> > printk(KERN_ERR
> > @@ -367,7 +367,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> > return result;
> >
> > fail_add:
> > - if (i2c->irq != 0)
> > + if (i2c->irq != NO_IRQ)
> > free_irq(i2c->irq, i2c);
> > fail_irq:
> > iounmap(i2c->base);
> > @@ -384,7 +384,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
> > i2c_del_adapter(&i2c->adap);
> > platform_set_drvdata(pdev, NULL);
> >
> > - if (i2c->irq != 0)
> > + if (i2c->irq != NO_IRQ)
> > free_irq(i2c->irq, i2c);
> >
> > iounmap(i2c->base);
> >
> >
> > _______________________________________________
> > i2c mailing list
> > i2c@lm-sensors.org
> > http://lists.lm-sensors.org/mailman/listinfo/i2c
> >
>
>
^ permalink raw reply
* Re: [PATCH] powerpc: reduce code duplication in legacy_serial, add UART parent types
From: Paul Gortmaker @ 2008-01-24 22:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, arnd
In-Reply-To: <12011947821738-git-send-email-paul.gortmaker@windriver.com>
In message: [PATCH] powerpc: reduce code duplication in legacy_serial, add UART parent types
on 24/01/2008 Paul Gortmaker wrote:
> @@ -31,6 +32,15 @@ static struct legacy_serial_info {
> int irq_check_parent;
> phys_addr_t taddr;
> } legacy_serial_infos[MAX_LEGACY_SERIAL_PORTS];
> +
> +static struct __init of_device_id parents[] = {
Oops, that should have been __initdata to be 100% correct...
P.
---
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Thu, 24 Jan 2008 11:59:12 -0500
Subject: [PATCH] powerpc: reduce code duplication in legacy_serial, add UART parent types
The legacy_serial was treating each UART parent in a separate code block.
Rather than continue this trend for the new parent IDs, this condenses
all (soc, tsi, opb, plus two more new types) into one of_device_id array.
The new types are wrs,epld-localbus for the Wind River sbc8560, and a
more generic "simple-bus" as requested by Scott Wood.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/kernel/legacy_serial.c | 45 +++++++++++++---------------------
1 files changed, 17 insertions(+), 28 deletions(-)
diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index 4bfff88..76b862b 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -4,6 +4,7 @@
#include <linux/serial_core.h>
#include <linux/console.h>
#include <linux/pci.h>
+#include <linux/of_device.h>
#include <asm/io.h>
#include <asm/mmu.h>
#include <asm/prom.h>
@@ -31,6 +32,15 @@ static struct legacy_serial_info {
int irq_check_parent;
phys_addr_t taddr;
} legacy_serial_infos[MAX_LEGACY_SERIAL_PORTS];
+
+static struct __initdata of_device_id parents[] = {
+ {.type = "soc",},
+ {.type = "tsi-bridge",},
+ {.type = "opb", .compatible = "ibm,opb",},
+ {.compatible = "simple-bus",},
+ {.compatible = "wrs,epld-localbus",},
+};
+
static unsigned int legacy_serial_count;
static int legacy_serial_console = -1;
@@ -306,18 +316,20 @@ void __init find_legacy_serial_ports(void)
DBG(" no linux,stdout-path !\n");
}
- /* First fill our array with SOC ports */
+ /* Iterate over all the 16550 ports, looking for known parents */
for_each_compatible_node(np, "serial", "ns16550") {
- struct device_node *soc = of_get_parent(np);
- if (soc && !strcmp(soc->type, "soc")) {
+ struct device_node *parent = of_get_parent(np);
+ if (!parent)
+ continue;
+ if (of_match_node(parents, parent) != NULL) {
index = add_legacy_soc_port(np, np);
if (index >= 0 && np == stdout)
legacy_serial_console = index;
}
- of_node_put(soc);
+ of_node_put(parent);
}
- /* First fill our array with ISA ports */
+ /* Next, fill our array with ISA ports */
for_each_node_by_type(np, "serial") {
struct device_node *isa = of_get_parent(np);
if (isa && !strcmp(isa->name, "isa")) {
@@ -328,29 +340,6 @@ void __init find_legacy_serial_ports(void)
of_node_put(isa);
}
- /* First fill our array with tsi-bridge ports */
- for_each_compatible_node(np, "serial", "ns16550") {
- struct device_node *tsi = of_get_parent(np);
- if (tsi && !strcmp(tsi->type, "tsi-bridge")) {
- index = add_legacy_soc_port(np, np);
- if (index >= 0 && np == stdout)
- legacy_serial_console = index;
- }
- of_node_put(tsi);
- }
-
- /* First fill our array with opb bus ports */
- for_each_compatible_node(np, "serial", "ns16550") {
- struct device_node *opb = of_get_parent(np);
- if (opb && (!strcmp(opb->type, "opb") ||
- of_device_is_compatible(opb, "ibm,opb"))) {
- index = add_legacy_soc_port(np, np);
- if (index >= 0 && np == stdout)
- legacy_serial_console = index;
- }
- of_node_put(opb);
- }
-
#ifdef CONFIG_PCI
/* Next, try to locate PCI ports */
for (np = NULL; (np = of_find_all_nodes(np));) {
--
1.5.0.rc1.gf4b6c
^ permalink raw reply related
* [PATCH] [POWERPC] Add a cuboot wrapper for 85xx w/CPM2
From: Kumar Gala @ 2008-01-24 22:44 UTC (permalink / raw)
To: linuxppc-dev
The bd info struct changes if we have CPM2 enabled in u-boot.
---
arch/powerpc/boot/Makefile | 6 +++-
arch/powerpc/boot/cuboot-85xx-cpm2.c | 61 ++++++++++++++++++++++++++++++++++
2 files changed, 66 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/cuboot-85xx-cpm2.c
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 1e20aca..1a42970 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -62,7 +62,8 @@ src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c holly.c
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c \
fixed-head.S ep88xc.c cuboot-hpc2.c ep405.c cuboot-taishan.c \
- cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c
+ cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
+ cuboot-85xx-cpm2.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -200,6 +201,9 @@ image-$(CONFIG_PPC_MPC52xx) += cuImage.52xx
image-$(CONFIG_STORCENTER) += cuImage.824x
image-$(CONFIG_PPC_83xx) += cuImage.83xx
image-$(CONFIG_PPC_85xx) += cuImage.85xx
+ifeq ($(CONFIG_CPM2),y)
+image-$(CONFIG_PPC_85xx) += cuImage.85xx-cpm2
+endif
image-$(CONFIG_MPC7448HPC2) += cuImage.hpc2
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
image-$(CONFIG_BAMBOO) += treeImage.bamboo cuImage.bamboo
diff --git a/arch/powerpc/boot/cuboot-85xx-cpm2.c b/arch/powerpc/boot/cuboot-85xx-cpm2.c
new file mode 100644
index 0000000..e2616f2
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-85xx-cpm2.c
@@ -0,0 +1,61 @@
+/*
+ * Old U-boot compatibility for 85xx
+ *
+ * Author: Scott Wood <scottwood@freescale.com>
+ *
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "cuboot.h"
+
+#define TARGET_85xx
+#define TARGET_CPM2
+#include "ppcboot.h"
+
+static bd_t bd;
+
+static void platform_fixups(void)
+{
+ void *soc;
+
+ dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+ dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
+ dt_fixup_mac_address_by_alias("ethernet1", bd.bi_enet1addr);
+ dt_fixup_mac_address_by_alias("ethernet2", bd.bi_enet2addr);
+ dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 8, bd.bi_busfreq);
+
+ /* Unfortunately, the specific model number is encoded in the
+ * soc node name in existing dts files -- once that is fixed,
+ * this can do a simple path lookup.
+ */
+ soc = find_node_by_devtype(NULL, "soc");
+ if (soc) {
+ void *serial = NULL;
+
+ setprop(soc, "bus-frequency", &bd.bi_busfreq,
+ sizeof(bd.bi_busfreq));
+
+ while ((serial = find_node_by_devtype(serial, "serial"))) {
+ if (get_parent(serial) != soc)
+ continue;
+
+ setprop(serial, "clock-frequency", &bd.bi_busfreq,
+ sizeof(bd.bi_busfreq));
+ }
+ }
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+ fdt_init(_dtb_start);
+ serial_console_init();
+ platform_ops.fixups = platform_fixups;
+}
--
1.5.3.7
^ permalink raw reply related
* Re: [i2c] [PATCH] mpc i2c driver, compare to NO_IRQ instead of zero
From: Jon Smirl @ 2008-01-24 23:07 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, i2c
In-Reply-To: <1201214138.6815.107.camel@pasglop>
On 1/24/08, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Thu, 2008-01-24 at 17:32 -0500, Jon Smirl wrote:
> > Ben, do you approve of this? How should error be checked for, is
> > <NO_IRQ right? The current code in the kernel looks to be broken
> > because of these checks, the ppc build is wrong and powerpc polled
> > mode doesn't work.
>
> == 0 should work on powerpc since NO_IRQ is defined to be 0 there no ?
The driver being patched is used in both the powerpc and ppc builds.
>
> Anyway, using the symbolic constant is always nicer I suppose.
>
> Ben.
>
> > On 1/21/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > Alter the mpc i2c driver to use the NO_IRQ symbol instead of the constant zero when checking for valid interrupts. NO_IRQ=-1 on ppc and NO_IRQ=0 on powerpc so the checks against zero are not correct.
> > >
> > > Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
> > > ---
> > >
> > > drivers/i2c/busses/i2c-mpc.c | 10 +++++-----
> > > 1 files changed, 5 insertions(+), 5 deletions(-)
> > >
> > >
> > > diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
> > > index bbe787b..d20959d 100644
> > > --- a/drivers/i2c/busses/i2c-mpc.c
> > > +++ b/drivers/i2c/busses/i2c-mpc.c
> > > @@ -99,7 +99,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
> > > u32 x;
> > > int result = 0;
> > >
> > > - if (i2c->irq == 0)
> > > + if (i2c->irq == NO_IRQ)
> > > {
> > > while (!(readb(i2c->base + MPC_I2C_SR) & CSR_MIF)) {
> > > schedule();
> > > @@ -329,7 +329,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> > > return -ENOMEM;
> > >
> > > i2c->irq = platform_get_irq(pdev, 0);
> > > - if (i2c->irq < 0) {
> > > + if (i2c->irq < NO_IRQ) {
> > > result = -ENXIO;
> > > goto fail_get_irq;
> > > }
> > > @@ -344,7 +344,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> > > goto fail_map;
> > > }
> > >
> > > - if (i2c->irq != 0)
> > > + if (i2c->irq != NO_IRQ)
> > > if ((result = request_irq(i2c->irq, mpc_i2c_isr,
> > > IRQF_SHARED, "i2c-mpc", i2c)) < 0) {
> > > printk(KERN_ERR
> > > @@ -367,7 +367,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> > > return result;
> > >
> > > fail_add:
> > > - if (i2c->irq != 0)
> > > + if (i2c->irq != NO_IRQ)
> > > free_irq(i2c->irq, i2c);
> > > fail_irq:
> > > iounmap(i2c->base);
> > > @@ -384,7 +384,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
> > > i2c_del_adapter(&i2c->adap);
> > > platform_set_drvdata(pdev, NULL);
> > >
> > > - if (i2c->irq != 0)
> > > + if (i2c->irq != NO_IRQ)
> > > free_irq(i2c->irq, i2c);
> > >
> > > iounmap(i2c->base);
> > >
> > >
> > > _______________________________________________
> > > i2c mailing list
> > > i2c@lm-sensors.org
> > > http://lists.lm-sensors.org/mailman/listinfo/i2c
> > >
> >
> >
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Failed to mount rootfs
From: Andy Fleming @ 2008-01-24 23:39 UTC (permalink / raw)
To: Bizhan Gholikhamseh; +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA911279641502D1A9F6@xmb-sjc-212.amer.cisco.com>
>>
> I do not know why it is creating two chosen node. In my dts file I
> have
> placed one empty chosen node:
> chosen{
> };
> If I do not do this, I get the following error during boot process:
>
> libfdt: FDT_ERR_TRUNCATED
> Failed creating the /chosen node (0x00C00000), aborting.
>
> Any reason??
Are you adding padding to your dtb?
Try adding "-p 1024" to your dtc command line
Andy
^ 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