* Re: [PATCH 3/4] Simplify rtas_change_msi() error semantics
From: Benjamin Herrenschmidt @ 2007-10-02 8:37 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1191310825.6593.21.camel@concordia>
On Tue, 2007-10-02 at 17:40 +1000, Michael Ellerman wrote:
>
> rtas_disable_msi() asks firmware to configure 0 MSIs on the device,
> that
> hopefully succeeds. AFAIK configuring 0 MSIs is as close as we can get
> to disabling MSI via RTAS.
>
> Perhaps that should also (re)enable INTX?
Not sure... maybe. RTAS doesn't do it ? Then there,s the question of
what happens on machines that don't support INTx ...
Cheers.
Ben.
^ permalink raw reply
* Re: What's the preferred way to export board information to userspace ?
From: Benjamin Herrenschmidt @ 2007-10-02 8:39 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200710021011.00224.laurentp@cse-semaphore.com>
On Tue, 2007-10-02 at 10:10 +0200, Laurent Pinchart wrote:
> Hi everybody,
>
> it seems linuxppc-embedded is going away. I should have posted this here in
> the first place, so sorry for the cross-post.
>
> I need to export some read-only board-specific information (serial number,
> boot mode jumper configuration, ...) that are collected from various locations
> (CPLD, flash, U-Boot, ...) to userspace applications.
>
> Could anyone advice me on the preferred way to do that ? I can easily add a
> quick&dirty sysfs/procfs based implementation, but I was wondering if there
> was some kind of clean and generic way.
Userspace can read /proc/device-tree no ? :-)
Appart from that, it's common to stick that sort of thing
in /proc/cpuinfo... /sys/firmware may be an option if you have shitloads
of stuff ..
Ben.
^ permalink raw reply
* Re: What's the preferred way to export board information to userspace ?
From: Laurent Pinchart @ 2007-10-02 9:02 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1191314363.22572.9.camel@pasglop>
Hi Ben,
On Tuesday 02 October 2007 10:39, Benjamin Herrenschmidt wrote:
> On Tue, 2007-10-02 at 10:10 +0200, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > it seems linuxppc-embedded is going away. I should have posted this here
> > in the first place, so sorry for the cross-post.
> >
> > I need to export some read-only board-specific information (serial
> > number, boot mode jumper configuration, ...) that are collected from
> > various locations (CPLD, flash, U-Boot, ...) to userspace applications.
> >
> > Could anyone advice me on the preferred way to do that ? I can easily a=
dd
> > a quick&dirty sysfs/procfs based implementation, but I was wondering if
> > there was some kind of clean and generic way.
>
> Userspace can read /proc/device-tree no ? :-)
Except I'm still using ARCH=3Dppc. I know I shouldn't :-) The MPC8272 isn't=
well=20
supported in ARCH=3Dpowerpc. Scott Wood submitted some patches I need befor=
e=20
switching.
> Appart from that, it's common to stick that sort of thing
> in /proc/cpuinfo... /sys/firmware may be an option if you have shitloads
> of stuff ..
It's not really CPU information, but I guess I can stick that in there.
Best regards,
=2D-=20
Laurent Pinchart
CSE Semaphore Belgium
Chauss=C3=A9e de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
=46 +32 (2) 387 42 75
^ permalink raw reply
* Re: [PATCH 2/5] Celleb: Support for Power/Reset buttons
From: Arnd Bergmann @ 2007-10-02 11:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <20071002.172121.-1625870824.kouish@swc.toshiba.co.jp>
On Tuesday 02 October 2007, Ishizaki Kou wrote:
> This is a patch to support Power/Reset buttons on Beat on Celleb.
>
> On Beat, we have an event from Beat if Power button or Reset button
> is pressed. This patch catches the event and convert it to a signal
> to INIT process by calling ctrl_alt_del() function.
>
> /sbin/inittab have no entry to turn the machine power off so we have
> to detect if power button is pressed or not internally in our driver.
> This idea is taken from PS3's event handling subsystem.
>
> Signed-off-by: Kou Ishizaki <Kou.Ishizaki@toshiba.co.jp>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 4/5] Celleb: Serial I/O update
From: Arnd Bergmann @ 2007-10-02 11:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <20071002.172516.-494087187.kouish@swc.toshiba.co.jp>
On Tuesday 02 October 2007, Ishizaki Kou wrote:
> This is an update patch for Serial I/O on Celleb.
> - Detection algorithm has been changed
>
> Signed-off-by: Kou Ishizaki <Kou.Ishizaki@toshiba.co.jp>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 5/5] Celleb: update for PCI
From: Arnd Bergmann @ 2007-10-02 11:30 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <20071002.172653.-1962661557.kouish@swc.toshiba.co.jp>
On Tuesday 02 October 2007, Ishizaki Kou wrote:
> This is a patch kit to support PCI bus on Celleb with new "I/O routines
> for PowerPC." External PCI on Celleb must do explicit synchronization
> with devices (Bus has no automatic synchronization feature).
>
> Signed-off-by: Kou Ishizaki <Kou.Ishizaki@toshiba.co.jp>
Acked-by: Arnd Bergmann <arnd@arndb.de>
The patch is not the final solution, as we discussed before, but it's
a big step in the right direction.
^ permalink raw reply
* mem_init_done (was: Re: [PATCH] [POWERPC] Limit range of __init_ref_ok somewhat)
From: Geert Uytterhoeven @ 2007-10-02 11:42 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus
In-Reply-To: <20071002133753.662397db.sfr@canb.auug.org.au>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1396 bytes --]
On Tue, 2 Oct 2007, Stephen Rothwell wrote:
> +void * __init_refok zalloc_maybe_bootmem(size_t size, gfp_t mask)
> +{
> + void *p;
> +
> + if (mem_init_done)
> + p = kzalloc(size, mask);
> + else {
> + p = alloc_bootmem(size);
> + if (p)
> + memset(p, 0, size);
> + }
> + return p;
> +}
BTW, is this `mem_init_done' flag the recommended(TM) way to handle this?
Or is it just something that always stayed under the radar of the reviewers, as
only PPC has it (and Atari)?
I remember we had something similar globally when __init was introduced,
which was used by the frame buffer code to determine whether to draw the
penguin logo (which is __initdata) or not. This code had to be ripped out (and
was replaced by the FBINFO_MODULE logic), because people didn't like
mem_init_done flags...
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* [PATCH] Fix typo in new EMAC driver.
From: Valentine Barshak @ 2007-10-02 12:01 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1191283028.10089.15.camel@localhost.localdomain>
Fix an obvious typo in emac_xmit_finish.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
drivers/net/ibm_newemac/core.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -ruNp linux-2.6.orig/drivers/net/ibm_newemac/core.c linux-2.6/drivers/net/ibm_newemac/core.c
--- linux-2.6.orig/drivers/net/ibm_newemac/core.c 2007-10-01 17:23:35.000000000 +0400
+++ linux-2.6/drivers/net/ibm_newemac/core.c 2007-10-01 17:44:57.000000000 +0400
@@ -1232,9 +1232,9 @@ static inline int emac_xmit_finish(struc
* instead
*/
if (emac_has_feature(dev, EMAC_FTR_EMAC4))
- out_be32(&p->tmr0, EMAC_TMR0_XMIT);
- else
out_be32(&p->tmr0, EMAC4_TMR0_XMIT);
+ else
+ out_be32(&p->tmr0, EMAC_TMR0_XMIT);
if (unlikely(++dev->tx_cnt == NUM_TX_BUFF)) {
netif_stop_queue(ndev);
^ permalink raw reply
* Re: [PATCH 2/7] [POWERPC] Fix QEIC->MPIC cascading
From: Anton Vorontsov @ 2007-10-02 12:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1191280461.6310.37.camel@pasglop>
On Tue, Oct 02, 2007 at 09:14:21AM +1000, Benjamin Herrenschmidt wrote:
>
> On Tue, 2007-09-25 at 18:34 +0400, Anton Vorontsov wrote:
> > set_irq_chained_handler overwrites MPIC's handle_irq function
> > (handle_fasteoi_irq) thus MPIC never gets eoi event from the
> > cascaded IRQ. This situation hangs MPIC on MPC8568E.
> >
> > Patch adds flow level "end" handler to the MPIC, and QEIC calls
> > it when QEIC's interrupt processing finished.
> >
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>
> Not sure if I already NAKed it on the list, so if I didn't here's it :-)
>
> The proper way of doing that is to have the cascade handler perform the
> EOI call to mpic.
Exactly, this is what that patch is trying to do. QEIC cascade handler is
calling mpic's eoi() (end() actually, as it's flow level, but end == eoi.
Is it main objection? Ok, I can get rid of it, and use chip level eoi()
directly).
> Look at how it's done for i8259 mpic cascade handlers.
void pseries_8259_cascade(unsigned int irq, struct irq_desc *desc)
{
unsigned int cascade_irq = i8259_irq();
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
desc->chip->eoi(irq);
}
...
set_irq_chained_handler(cascade_irq, pseries_8259_cascade);
Quite similar... except that it's written in the board file.
> Basically, when doing a cascade nowadays, you can either just do a
> normal request_irq() of the cascade, in which case your handler don't
> have to care about the parent controller at all, but you get various
> limitations and/or overhead from being a full blown interrupt handler,
Though viable, but not an option.
> or you can use the chained handler mechanism which is a "shortcut" but
> implies that your cascade handler "knows" what needs to be done to the
> parent (and thus is specific to the combination parent/child).
Yup, exactly. Actually, QEIC's cascade handlers do not really know
what needs to be done, but they're good at guessing (if (chip->eoi)).
Sure, I can place board-specific QEIC handlers in the board file, but
that will be quite big code duplication for all machines using QEIC.
> Cheers,
> Ben.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Problem with OF interrupt parsing code
From: Gerhard Pircher @ 2007-10-02 12:38 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1191279244.6310.32.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Tue, 02 Oct 2007 07:39:47 +1000
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: Problem with OF interrupt parsing code
> Part of your problem is that interrupt-parent property. You shouldn't
> have such a property in a PCI host bridge. It's not technically illegal,
> but it's triggering the "loop" you've been experiencing.
Okay, I'll remove this one.
> If you want the parsing to fail for PCI devices (to get the fallback to
> config space values), you need to make sure it does fail.
>
> Another option is to put an empty interrupt-map in there. That will
> guarantee failure.
>
> But that's all very ugly. I don't understand why you don't setup a
> proper map either from your bootloader, zImage wrapper or even prom_init
> or platform code.
I know that it's ugly, but the problem is how to distinguish the boards.
The only real difference I know of is the PCI interrupt mapping. The
northbridges chip revision for example is always the same, but CPU type,
amount of memory and PCI devices can appear in all possible combinations.
The firmware doesn't tell me, which board the kernel is runnning on, so I
would like to rely on this fall back here until I get the chance to
update the firmware (which is beyond my control).
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: Problem with OF interrupt parsing code
From: Gerhard Pircher @ 2007-10-02 12:40 UTC (permalink / raw)
To: benh, segher; +Cc: linuxppc-dev
-------- Original-Nachricht --------
> Datum: Tue, 02 Oct 2007 08:54:04 +1000
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Segher Boessenkool <segher@kernel.crashing.org>
> CC: Gerhard Pircher <gerhard_pircher@gmx.net>, linuxppc-dev@ozlabs.org
> Betreff: Re: Problem with OF interrupt parsing code
> It shoudn't normally happen. The reason it -does- happen in fact is that
> the above node is also missing the #interrupt-cells property, which
> cause the parent-lookup routine to skip it before it gets a chance to
> see that there's an "interrupt-controller" property in there.
>
> I'm not sure whether linux behaviour is a bug or not since I believe we
> are clearly in undefined-land as an interrupt controller should always
> have a #interrupt-cells property.
I think these properties weren't specified in the OF CHRP ISA PIC device
binding document for the PIC node, thus I may have forgotten about them
(CHRP also defines a parent interrupt controller for the PIC, right?).
But the AmigaOne is not a CHRP platform, so I'll add them to the device
tree and then I will see how it works.
Thanks!
Gerhard
^ permalink raw reply
* Re: Problem with OF interrupt parsing code
From: Gerhard Pircher @ 2007-10-02 12:46 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <470165F6.7030505@freescale.com>
-------- Original-Nachricht --------
> Datum: Mon, 01 Oct 2007 16:26:14 -0500
> Von: Scott Wood <scottwood@freescale.com>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: Problem with OF interrupt parsing code
> > Secondly the AmigaOne is a desktop system with 4 PCI/AGP slots,
> > thus I can't specify device nodes for all possible devices. By looking
> > at pci_read_irq_line() in pci_common.c it should be possible for the
> > kernel to fall back to the interrupt settings in the PCI config space
> > of every device.
>
> Those interrupt settings are purely a communication vector from firmware
> to OS. Is your firmware putting i8259 interrupt numbers in there, and
> did you set the default interrupt controller?
Yes, the firmware puts the i8259 interrupt numbers in the PCI interrupt
line register and the PIC is setup as default interrupt controller.
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: [RFC PATCH v0.2] net driver: mpc52xx fec
From: Sascha Hauer @ 2007-10-02 12:49 UTC (permalink / raw)
To: Domen Puncer; +Cc: netdev, linuxppc-embedded
In-Reply-To: <20070902074143.GB2642@nd47.coderock.org>
Hi Domen,
On Sun, Sep 02, 2007 at 09:41:43AM +0200, Domen Puncer wrote:
+ */
> +static void fec_start(struct net_device *dev)
> +{
> + struct fec_priv *priv = netdev_priv(dev);
> + struct mpc52xx_fec __iomem *fec = priv->fec;
> + u32 rcntrl;
> + u32 tcntrl;
> + u32 tmp;
> +
> + /* clear sticky error bits */
> + tmp = FEC_FIFO_STATUS_ERR | FEC_FIFO_STATUS_UF | FEC_FIFO_STATUS_OF;
> + out_be32(&fec->rfifo_status, in_be32(&fec->rfifo_status) & tmp);
> + out_be32(&fec->tfifo_status, in_be32(&fec->tfifo_status) & tmp);
> +
> + /* FIFOs will reset on fec_enable */
> + out_be32(&fec->reset_cntrl, FEC_RESET_CNTRL_ENABLE_IS_RESET);
> +
> + /* Set station address. */
> + fec_set_paddr(dev, dev->dev_addr);
> +
> + fec_set_multicast_list(dev);
> +
> + /* set max frame len, enable flow control, select mii mode */
> + rcntrl = FEC_RX_BUFFER_SIZE << 16; /* max frame length */
> + rcntrl |= FEC_RCNTRL_FCE;
> + rcntrl |= MII_RCNTL_MODE;
> + if (priv->duplex == DUPLEX_FULL)
> + tcntrl = FEC_TCNTRL_FDEN; /* FD enable */
> + else {
> + rcntrl |= FEC_RCNTRL_DRT; /* disable Rx on Tx (HD) */
> + tcntrl = 0;
> + }
> + out_be32(&fec->r_cntrl, rcntrl);
> + out_be32(&fec->x_cntrl, tcntrl);
> +
> + /* Clear any outstanding interrupt. */
> + out_be32(&fec->ievent, 0xffffffff);
> +
> + /* Enable interrupts we wish to service. */
> + out_be32(&fec->imask, FEC_IMASK_ENABLE);
This disables phy interrupts.
> +static int fec_mdio_read(struct mii_bus *bus, int phy_id, int reg)
> +{
> + struct fec_mdio_priv *priv = bus->priv;
> + int tries = 100;
> +
> + u32 request = FEC_MII_READ_FRAME;
> + request |= (phy_id << FEC_MII_DATA_PA_SHIFT) & FEC_MII_DATA_PA_MSK;
> + request |= (reg << FEC_MII_DATA_RA_SHIFT) & FEC_MII_DATA_RA_MSK;
> +
> + out_be32(&priv->regs->mii_data, request);
> +
> + /* wait for it to finish, this takes about 23 us on lite5200b */
> + while (priv->completed == 0 && tries--)
> + udelay(5);
> +
> + priv->completed = 0;
> +
> + if (tries == 0)
> + return -ETIMEDOUT;
This does not work as expected. When a timeout occurs tries is -1 not 0,
so the test above will never trigger.
Using --tries instead of tries-- reveals another bug. We get a timeout
everytime now, because MII interrupts are accidently disabled in
fec_start().
We cannot use a waitqueue or similar for waiting for the mii transfer
because we are atomic here.
A simple fix is provided below. It removes the need for the interrupt
handler in the phy handling routines. Anyway, it might be better to fix
the phy layer not to use atomic contexts, so this patch might not be the
way to go.
Regards,
Sascha
+
> +static int fec_mdio_probe(struct of_device *of, const struct of_device_id *match)
> +{
> + struct device *dev = &of->dev;
>
> [...]
>
> + init_waitqueue_head(&priv->wq);
This waitqueue is never used. wake_up() is called in the interrupt
handler, but noone ever sleeps on the queue.
---
drivers/net/fec_mpc52xx/fec.c | 7 +---
drivers/net/fec_mpc52xx/fec_phy.c | 59 +++++++-------------------------------
2 files changed, 15 insertions(+), 51 deletions(-)
Index: linux-2.6.23-rc8/drivers/net/fec_mpc52xx/fec.c
===================================================================
--- linux-2.6.23-rc8.orig/drivers/net/fec_mpc52xx/fec.c
+++ linux-2.6.23-rc8/drivers/net/fec_mpc52xx/fec.c
@@ -265,7 +265,6 @@ static void fec_phy_hw_init(struct fec_p
return;
out_be32(&fec->mii_speed, priv->phy_speed);
- out_be32(&fec->imask, in_be32(&fec->imask) | FEC_IMASK_MII);
}
static int fec_open(struct net_device *dev)
@@ -654,7 +653,7 @@ static void fec_hw_init(struct net_devic
out_be32(&fec->iaddr1, 0x00000000); /* No individual filter */
out_be32(&fec->iaddr2, 0x00000000); /* No individual filter */
- /* set phy speed and enable MII interrupt
+ /* set phy speed.
* this can't be done in phy driver, since it needs to be called
* before fec stuff (even on resume) */
fec_phy_hw_init(priv);
@@ -730,8 +729,8 @@ static void fec_stop(struct net_device *
struct mpc52xx_fec __iomem *fec = priv->fec;
unsigned long timeout;
- /* disable all but MII interrupt */
- out_be32(&fec->imask, in_be32(&fec->imask) & FEC_IMASK_MII);
+ /* disable all interrupts */
+ out_be32(&fec->imask, 0);
/* Disable the rx task. */
bcom_disable(priv->rx_dmatsk);
Index: linux-2.6.23-rc8/drivers/net/fec_mpc52xx/fec_phy.c
===================================================================
--- linux-2.6.23-rc8.orig/drivers/net/fec_mpc52xx/fec_phy.c
+++ linux-2.6.23-rc8/drivers/net/fec_mpc52xx/fec_phy.c
@@ -18,29 +18,28 @@
#include "fec.h"
struct fec_mdio_priv {
- int completed;
- wait_queue_head_t wq;
struct mpc52xx_fec __iomem *regs;
- int irq;
};
static int fec_mdio_read(struct mii_bus *bus, int phy_id, int reg)
{
struct fec_mdio_priv *priv = bus->priv;
+ struct mpc52xx_fec __iomem *fec;
int tries = 100;
-
u32 request = FEC_MII_READ_FRAME;
+
+ fec = priv->regs;
+ out_be32(&fec->ievent, FEC_IEVENT_MII);
+
request |= (phy_id << FEC_MII_DATA_PA_SHIFT) & FEC_MII_DATA_PA_MSK;
request |= (reg << FEC_MII_DATA_RA_SHIFT) & FEC_MII_DATA_RA_MSK;
out_be32(&priv->regs->mii_data, request);
/* wait for it to finish, this takes about 23 us on lite5200b */
- while (priv->completed == 0 && tries--)
+ while (!(in_be32(&fec->ievent) & FEC_IEVENT_MII) && --tries)
udelay(5);
- priv->completed = 0;
-
if (tries == 0)
return -ETIMEDOUT;
@@ -50,9 +49,13 @@ static int fec_mdio_read(struct mii_bus
static int fec_mdio_write(struct mii_bus *bus, int phy_id, int reg, u16 data)
{
struct fec_mdio_priv *priv = bus->priv;
+ struct mpc52xx_fec __iomem *fec;
u32 value = data;
int tries = 100;
+ fec = priv->regs;
+ out_be32(&fec->ievent, FEC_IEVENT_MII);
+
value |= FEC_MII_WRITE_FRAME;
value |= (phy_id << FEC_MII_DATA_PA_SHIFT) & FEC_MII_DATA_PA_MSK;
value |= (reg << FEC_MII_DATA_RA_SHIFT) & FEC_MII_DATA_RA_MSK;
@@ -60,38 +63,15 @@ static int fec_mdio_write(struct mii_bus
out_be32(&priv->regs->mii_data, value);
/* wait for request to finish */
- while (priv->completed == 0 && tries--)
+ while (!(in_be32(&fec->ievent) & FEC_IEVENT_MII) && --tries)
udelay(5);
- priv->completed = 0;
-
if (tries == 0)
return -ETIMEDOUT;
return 0;
}
-static irqreturn_t fec_mdio_interrupt(int irq, void *dev_id)
-{
- struct fec_mdio_priv *priv = dev_id;
- struct mpc52xx_fec __iomem *fec;
- int ievent;
-
- fec = priv->regs;
- ievent = in_be32(&fec->ievent);
-
- ievent &= FEC_IEVENT_MII;
- if (!ievent)
- return IRQ_NONE;
-
- out_be32(&fec->ievent, ievent);
-
- priv->completed = 1;
- wake_up(&priv->wq);
-
- return IRQ_HANDLED;
-}
-
static int fec_mdio_probe(struct of_device *of, const struct of_device_id *match)
{
struct device *dev = &of->dev;
@@ -143,22 +123,12 @@ static int fec_mdio_probe(struct of_devi
goto out_free;
}
- priv->irq = irq_of_parse_and_map(np, 0);
- err = request_irq(priv->irq, &fec_mdio_interrupt, IRQF_DISABLED | IRQF_SHARED,
- "fec_mdio", priv);
- if (err) {
- printk(KERN_ERR "%s: interrupt request failed with %i\n", __func__, err);
- goto out_unmap;
- }
-
bus->id = res.start;
bus->priv = priv;
bus->dev = dev;
dev_set_drvdata(dev, bus);
- init_waitqueue_head(&priv->wq);
-
/* set MII speed */
out_be32(&priv->regs->mii_speed, ((mpc52xx_find_ipb_freq(of->node) >> 20) / 5) << 1);
@@ -167,13 +137,10 @@ static int fec_mdio_probe(struct of_devi
err = mdiobus_register(bus);
if (err)
- goto out_free_irq;
+ goto out_unmap;
return 0;
- out_free_irq:
- free_irq(priv->irq, dev);
- irq_dispose_mapping(priv->irq);
out_unmap:
iounmap(priv->regs);
out_free:
@@ -197,8 +164,6 @@ static int fec_mdio_remove(struct of_dev
mdiobus_unregister(bus);
dev_set_drvdata(dev, NULL);
- free_irq(priv->irq, dev);
- irq_dispose_mapping(priv->irq);
iounmap(priv->regs);
for (i=0; i<PHY_MAX_ADDR; i++)
if (bus->irq[i])
--
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord http://www.pengutronix.de
^ permalink raw reply
* Please pull from 'for-2.6.24' branch of 4xx tree
From: Josh Boyer @ 2007-10-02 12:54 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul,
Please pull from
master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.24
to pick up a handful of new items for 2.6.24. Initial Virtex support
from Grant, some cpu setup functions for 4xx from Valentine, a compile
fix for the Walnut wrapper, and a small number of arch/ppc fixes for
Xilinx boards.
Grant Likely (15):
[POWERPC] Virtex: Add uartlite bootwrapper driver
[POWERPC] Virtex: Add Kconfig macros for Xilinx Virtex board support
[POWERPC] Virtex: add xilinx interrupt controller driver
[POWERPC] Virtex: Add generic Xilinx Virtex board support
[POWERPC] Add PowerPC Xilinx Virtex entry to maintainers
[POWERPC] Uartlite: Fix reg io to access documented register size
[POWERPC] Uartlite: change name of ports to ulite_ports
[POWERPC] Uartlite: Add macro for uartlite device name
[POWERPC] Uartlite: Separate the bus binding from the driver proper
[POWERPC] Uartlite: Comment block tidy
[POWERPC] Uartlite: Add of-platform-bus binding
[POWERPC] Uartlite: Let the console be initialized earlier
[POWERPC] Uartlite: Flush RX fifo in bootwrapper
[POWERPC] XilinxFB: Move xilinxfb_platform_data definition to a shared hea
[POWERPC] Setup default eth addr in embed_config for Xilinx Virtex platfor
Josh Boyer (2):
[POWERPC] 4xx: Fix Walnut wrapper compile errors
[POWERPC] Add treeImage to .gitignore
Valentine Barshak (3):
[POWERPC] 4xx: Introduce cpu_setup functionality to 44x platform
[POWERPC] 4xx: Move 440EP(x) FPU setup from head_44x to cpu_setup_4xx
[POWERPC] 4xx: 440EPx/GRx incorrect write to DDR SDRAM errata workaround
MAINTAINERS | 7 +
arch/powerpc/boot/.gitignore | 1 +
arch/powerpc/boot/Makefile | 3 +-
arch/powerpc/boot/ops.h | 1 +
arch/powerpc/boot/serial.c | 2 +
arch/powerpc/boot/uartlite.c | 64 +++++++
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/kernel/cpu_setup_44x.S | 56 ++++++
arch/powerpc/kernel/cputable.c | 22 ++-
arch/powerpc/kernel/head_44x.S | 10 -
arch/powerpc/platforms/40x/Kconfig | 38 +++--
arch/powerpc/platforms/40x/Makefile | 1 +
arch/powerpc/platforms/40x/virtex.c | 50 ++++++
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/xilinx_intc.c | 151 ++++++++++++++++
arch/ppc/boot/simple/embed_config.c | 8 +
arch/ppc/boot/simple/misc-embedded.c | 4 +-
arch/ppc/boot/simple/uartlite_tty.c | 8 +
arch/ppc/syslib/virtex_devices.c | 2 +-
arch/ppc/syslib/virtex_devices.h | 8 +-
drivers/serial/uartlite.c | 318 +++++++++++++++++++++++++++-------
drivers/video/xilinxfb.c | 2 +-
include/asm-powerpc/xilinx_intc.h | 20 ++
include/linux/xilinxfb.h | 23 +++
24 files changed, 698 insertions(+), 103 deletions(-)
create mode 100644 arch/powerpc/boot/uartlite.c
create mode 100644 arch/powerpc/kernel/cpu_setup_44x.S
create mode 100644 arch/powerpc/platforms/40x/virtex.c
create mode 100644 arch/powerpc/sysdev/xilinx_intc.c
create mode 100644 include/asm-powerpc/xilinx_intc.h
create mode 100644 include/linux/xilinxfb.h
^ permalink raw reply
* [PATCH 0/3] Few more mpc8568mds and fsl_soc related patches
From: Anton Vorontsov @ 2007-10-02 13:45 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
These patches needed to support PCIe and RTC on the MPC8568E-MDS board.
They're against galak/powerpc.git master branch.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH 1/3] [POWERPC] fsl_soc: fix uninitialized i2c_board_info structure
From: Anton Vorontsov @ 2007-10-02 13:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071002134535.GA17913@localhost.localdomain>
i2c_board_info used semi-initialized, causing garbage in the
info->flags, and that, in turn, causes various symptoms of i2c
malfunctioning, like PEC mismatches.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/fsl_soc.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 4a16456..91987e0 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -363,7 +363,7 @@ static void __init of_register_i2c_devices(struct device_node *adap_node,
struct device_node *node = NULL;
while ((node = of_get_next_child(adap_node, node))) {
- struct i2c_board_info info;
+ struct i2c_board_info info = {};
const u32 *addr;
int len;
@@ -380,7 +380,6 @@ static void __init of_register_i2c_devices(struct device_node *adap_node,
if (of_find_i2c_driver(node, &info) < 0)
continue;
- info.platform_data = NULL;
info.addr = *addr;
i2c_register_board_info(bus_num, &info, 1);
--
1.5.0.6
^ permalink raw reply related
* [PATCH 2/3] [POWERPC] MPC8568E-MDS: add support for ds1374 rtc
From: Anton Vorontsov @ 2007-10-02 13:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071002134535.GA17913@localhost.localdomain>
MPC8568E-MDS have DS1374 chip on the I2C bus, thus let's use it.
This patch also adds #address-cells and #size-cells to the I2C
controllers nodes.
p.s. DS1374 rtc class driver is in the -mm tree, its name is
rtc-rtc-class-driver-for-the-ds1374.patch.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8568mds.dts | 9 +++++++++
arch/powerpc/sysdev/fsl_soc.c | 1 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index 1d082fb..a177dd0 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -72,15 +72,24 @@
};
i2c@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3000 100>;
interrupts = <2b 2>;
interrupt-parent = <&mpic>;
dfsrr;
+
+ rtc@68 {
+ compatible = "dallas,ds1374";
+ reg = <68>;
+ };
};
i2c@3100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3100 100>;
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 91987e0..c765d7a 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -337,6 +337,7 @@ static struct i2c_driver_device i2c_devices[] __initdata = {
{"dallas,ds1339", "rtc-ds1307", "ds1339",},
{"dallas,ds1340", "rtc-ds1307", "ds1340",},
{"stm,m41t00", "rtc-ds1307", "m41t00"},
+ {"dallas,ds1374", "rtc-ds1374", "rtc-ds1374",},
};
static int __init of_find_i2c_driver(struct device_node *node,
--
1.5.0.6
^ permalink raw reply related
* [PATCH 3/3] [POWERPC] mpc8568mds.dts: fix PCIe I/O address space location and size
From: Anton Vorontsov @ 2007-10-02 13:48 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071002134535.GA17913@localhost.localdomain>
According to u-boot/board/mpc8568mds/init.S:
LAW(Local Access Window) configuration:
2) 0xa000_0000 0xbfff_ffff PCIe MEM 512MB
4) 0xe280_0000 0xe2ff_ffff PCIe I/O 8M
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8568mds.dts | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index a177dd0..39ec3c2 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -226,8 +226,8 @@
interrupt-parent = <&mpic>;
interrupts = <1a 2>;
bus-range = <0 ff>;
- ranges = <02000000 0 a0000000 a0000000 0 20000000
- 01000000 0 00000000 e3000000 0 08000000>;
+ ranges = <02000000 0 a0000000 a0000000 0 10000000
+ 01000000 0 00000000 e2800000 0 00800000>;
clock-frequency = <1fca055>;
#interrupt-cells = <1>;
#size-cells = <2>;
--
1.5.0.6
^ permalink raw reply related
* Re: [PATCH v2 2/6] Sysace: Use the established platform bus api
From: Grant Likely @ 2007-10-02 13:52 UTC (permalink / raw)
To: Jens Axboe; +Cc: Christoph Hellwig, paulus, linux-kernel, linuxppc-dev
In-Reply-To: <20071002063523.GM5303@kernel.dk>
On 10/2/07, Jens Axboe <jens.axboe@oracle.com> wrote:
> On Tue, Oct 02 2007, Benjamin Herrenschmidt wrote:
> >
> > On Mon, 2007-10-01 at 13:59 +0200, Jens Axboe wrote:
> > > Just send a fixup patch for that, I'll add your series to the block tree
> > > for 2.6.24.
> >
> > It's actually better off living in the powerpc tree I think as it's
> > really about adding support for a new powerpc platform and somewhat
> > needs to sync with other things in there. Unless you really want the
> > whole thing in your tree :-)
>
> I already included it yesterday, it'll go up once 2.6.24 opens. Let me
> know if you want me to rip it out, though.
No, it's safe. Nothing will break if one goes in before the other.
Please keep it in.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH v2 5/6] Sysace: Move IRQ handler registration to occur after FSM is initialized
From: Grant Likely @ 2007-10-02 13:57 UTC (permalink / raw)
To: benh; +Cc: axboe, linuxppc-dev, paulus, linux-kernel
In-Reply-To: <1191304521.6310.94.camel@pasglop>
On 10/1/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Sun, 2007-09-30 at 16:57 -0600, Grant Likely wrote:
> > val |= ACE_CTRL_DATABUFRDYIRQ | ACE_CTRL_ERRORIRQ;
> > ace_out(ace, ACE_CTRL, val);
> >
> > + /* Now we can hook up the irq handler */
> > + if (ace->irq != NO_IRQ) {
> > + rc = request_irq(ace->irq, ace_interrupt, 0,
> > "systemace", ace);
> > + if (rc) {
> > + /* Failure - fall back to polled mode */
> > + dev_err(ace->dev, "request_irq failed\n");
> > + ace->irq = NO_IRQ;
> > + }
> > + }
> > +
>
> I don't know the HW but from the above, it looks like you enable
> interrupt emission on the HW before you register the handler, which is
> wrong. You should make sure on the contrary that IRQs on the HW are
> disabled until after you have registered a handler.
>
> Only really a problem if you have shared interrupts but still...
Yeah, you're right. Fortunately all current in-tree platforms which
use this do not have shared interrupts, but I'd like to be correct on
this.
I'll tidy this up and send a fixup patch.
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 2 6/7] Uartlite: Add of-platform-bus binding
From: Grant Likely @ 2007-10-02 14:26 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1191304386.6310.92.camel@pasglop>
On 10/1/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Sun, 2007-09-30 at 16:42 -0600, Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > Add of_platform bus binding so this driver can be used with arch/powerpc
>
> Another option is to have a "constructor" in the platform code that
> generates the platform device from the DT. It might even become the
> preferred way one of these days, I'm not too sure at this stage. Anyway,
> do what you prefer.
I've looked at both, and I'm not to fond of the 'constructor'
approach. Here are my reasons:
- Separate constructor code must be written for each driver anyway
(except perhaps for very simple cases which only require 'regs' and
'interrupts' properties). The device tree data must then be mapped
onto a pdata structure; which the driver immediately turns around and
unmaps from pdata to populate it's driver state structure. It ends up
being a lot of indirection to follow.
- Many (but perhaps not all) of these devices will be registered as an
of_device anyway. By having a constructor to generate a
platform_device from that means each device will get probed twice;
once by the of_platform bus and once by the platform bus.
- Writing device drivers with multiple binding is easy and probable
results in smaller simpler code than the two step process of using a
constructor.
For example, here is my of_device binding for the systemace driver:
static int __devinit
ulite_of_probe(struct of_device *op, const struct of_device_id *match)
{
struct resource res;
const unsigned int *id;
int irq, rc;
dev_dbg(&op->dev, "%s(%p, %p)\n", __FUNCTION__, op, match);
rc = of_address_to_resource(op->node, 0, &res);
if (rc) {
dev_err(&op->dev, "invalide address\n");
return rc;
}
irq = irq_of_parse_and_map(op->node, 0);
id = of_get_property(op->node, "port-number", NULL);
return ulite_assign(&op->dev, id ? *id : -1, res.start, irq);
}
That's 3 calls to get data out of the device tree and one call to
setup the device. The final 'ulite_assign()' call is called by both
the of_device and platform_device bindings.
To do the same thing with a constructor requires an additional
allocation and registration of a platform device structure and a pdata
structure. Plus it requires the platform code to explicitly call a
set of helper functions to find and create platform devices for nodes
in the device tree. (Unless you're thinking about leveraging the
of_platform probe code and have the .probe hook to the 'constructor'
bit)
What advantages do you see with the constructor approach?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [RFC PATCH v0.2] net driver: mpc52xx fec
From: Domen Puncer @ 2007-10-02 14:32 UTC (permalink / raw)
To: Sascha Hauer; +Cc: netdev, linuxppc-embedded
In-Reply-To: <20071002124939.GC10481@pengutronix.de>
On 02/10/07 14:49 +0200, Sascha Hauer wrote:
>
> Hi Domen,
Hi Sascha!
>
> On Sun, Sep 02, 2007 at 09:41:43AM +0200, Domen Puncer wrote:
> + */
> > +static void fec_start(struct net_device *dev)
> > +{
> > + struct fec_priv *priv = netdev_priv(dev);
> > + struct mpc52xx_fec __iomem *fec = priv->fec;
> > + u32 rcntrl;
> > + u32 tcntrl;
> > + u32 tmp;
> > +
> > + /* clear sticky error bits */
> > + tmp = FEC_FIFO_STATUS_ERR | FEC_FIFO_STATUS_UF | FEC_FIFO_STATUS_OF;
> > + out_be32(&fec->rfifo_status, in_be32(&fec->rfifo_status) & tmp);
> > + out_be32(&fec->tfifo_status, in_be32(&fec->tfifo_status) & tmp);
> > +
> > + /* FIFOs will reset on fec_enable */
> > + out_be32(&fec->reset_cntrl, FEC_RESET_CNTRL_ENABLE_IS_RESET);
> > +
> > + /* Set station address. */
> > + fec_set_paddr(dev, dev->dev_addr);
> > +
> > + fec_set_multicast_list(dev);
> > +
> > + /* set max frame len, enable flow control, select mii mode */
> > + rcntrl = FEC_RX_BUFFER_SIZE << 16; /* max frame length */
> > + rcntrl |= FEC_RCNTRL_FCE;
> > + rcntrl |= MII_RCNTL_MODE;
> > + if (priv->duplex == DUPLEX_FULL)
> > + tcntrl = FEC_TCNTRL_FDEN; /* FD enable */
> > + else {
> > + rcntrl |= FEC_RCNTRL_DRT; /* disable Rx on Tx (HD) */
> > + tcntrl = 0;
> > + }
> > + out_be32(&fec->r_cntrl, rcntrl);
> > + out_be32(&fec->x_cntrl, tcntrl);
> > +
> > + /* Clear any outstanding interrupt. */
> > + out_be32(&fec->ievent, 0xffffffff);
> > +
> > + /* Enable interrupts we wish to service. */
> > + out_be32(&fec->imask, FEC_IMASK_ENABLE);
>
>
> This disables phy interrupts.
Right, oops.
>
>
> > +static int fec_mdio_read(struct mii_bus *bus, int phy_id, int reg)
> > +{
> > + struct fec_mdio_priv *priv = bus->priv;
> > + int tries = 100;
> > +
> > + u32 request = FEC_MII_READ_FRAME;
> > + request |= (phy_id << FEC_MII_DATA_PA_SHIFT) & FEC_MII_DATA_PA_MSK;
> > + request |= (reg << FEC_MII_DATA_RA_SHIFT) & FEC_MII_DATA_RA_MSK;
> > +
> > + out_be32(&priv->regs->mii_data, request);
> > +
> > + /* wait for it to finish, this takes about 23 us on lite5200b */
> > + while (priv->completed == 0 && tries--)
> > + udelay(5);
> > +
> > + priv->completed = 0;
> > +
> > + if (tries == 0)
> > + return -ETIMEDOUT;
>
> This does not work as expected. When a timeout occurs tries is -1 not 0,
> so the test above will never trigger.
> Using --tries instead of tries-- reveals another bug. We get a timeout
> everytime now, because MII interrupts are accidently disabled in
> fec_start().
Oh, double bug made it work! ;-)
>
> We cannot use a waitqueue or similar for waiting for the mii transfer
> because we are atomic here.
> A simple fix is provided below. It removes the need for the interrupt
> handler in the phy handling routines. Anyway, it might be better to fix
> the phy layer not to use atomic contexts, so this patch might not be the
> way to go.
Doh, looks like this was the problem with wq's, but I forgot to remove
them, when I "fixed" the code.
>
>
> Regards,
> Sascha
>
> +
> > +static int fec_mdio_probe(struct of_device *of, const struct of_device_id *match)
> > +{
> > + struct device *dev = &of->dev;
> >
> > [...]
> >
> > + init_waitqueue_head(&priv->wq);
>
> This waitqueue is never used. wake_up() is called in the interrupt
> handler, but noone ever sleeps on the queue.
>
>
> ---
> drivers/net/fec_mpc52xx/fec.c | 7 +---
> drivers/net/fec_mpc52xx/fec_phy.c | 59 +++++++-------------------------------
> 2 files changed, 15 insertions(+), 51 deletions(-)
The patch looks ok to me.
Domen
^ permalink raw reply
* Re: [PATCH] cpm: Describe multi-user ram in its own device node.
From: Kumar Gala @ 2007-10-02 14:43 UTC (permalink / raw)
To: Scott Wood; +Cc: Timur Tabi, PowerPC dev list
In-Reply-To: <47011BED.8020206@freescale.com>
On Oct 1, 2007, at 11:10 AM, Scott Wood wrote:
> Kumar Gala wrote:
>> On Sep 29, 2007, at 1:49 AM, Vitaly Bordug wrote:
>>> cpms have dpram, qe has muram. these two are the same stuff in
>>> fact. Or you are asking about have QE stuff utilize such a
>>> binding at the same pass?
>> I was asking about both these things.
>
> As stated in the commit message, QE can use this; it just needs a
> compatible entry in the data node.
can some one look at that.
- k
^ permalink raw reply
* Re: [PATCH] cpm: Describe multi-user ram in its own device node.
From: Kumar Gala @ 2007-10-02 14:43 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070928190616.GB20213@loki.buserror.net>
On Sep 28, 2007, at 2:06 PM, Scott Wood wrote:
> The way the current CPM binding describes available multi-user (a.k.a.
> dual-ported) RAM doesn't work well when there are multiple free
> regions,
> and it doesn't work at all if the region doesn't begin at the start of
> the muram area (as the hardware needs to be programmed with offsets
> into
> this area). The latter situation can happen with SMC UARTs on
> CPM2, as its
> parameter RAM is relocatable, u-boot puts it at zero, and the
> kernel doesn't
> support moving it.
>
> It is now described with a muram node, similar to QE. The current CPM
> binding is sufficiently recent (i.e. never appeared in an official
> release)
> that compatibility with existing device trees is not an issue.
>
> The code supporting the new binding is shared between cpm1 and
> cpm2, rather
> than remain separated. QE should be able to use this code as well,
> once
> minor fixes are made to its device trees.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
applied.
- k
^ permalink raw reply
* Re: [PATCH] cpm: Describe multi-user ram in its own device node.
From: Timur Tabi @ 2007-10-02 14:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list
In-Reply-To: <AD243886-65DE-4285-ADD3-1D4C5ABA2E3C@kernel.crashing.org>
Kumar Gala wrote:
>
> On Oct 1, 2007, at 11:10 AM, Scott Wood wrote:
>
>> Kumar Gala wrote:
>>> On Sep 29, 2007, at 1:49 AM, Vitaly Bordug wrote:
>>>> cpms have dpram, qe has muram. these two are the same stuff in fact.
>>>> Or you are asking about have QE stuff utilize such a binding at the
>>>> same pass?
>>> I was asking about both these things.
>>
>> As stated in the commit message, QE can use this; it just needs a
>> compatible entry in the data node.
>
> can some one look at that.
Scott's proposal says this:
muram@0 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 10000>;
data@0 {
compatible = "fsl,cpm-muram-data";
reg = <0 2000 9800 800>;
};
Currently, the QE has this:
muram@10000 {
device_type = "muram";
ranges = <0 00010000 0000c000>;
data-only@0{
reg = <0 c000>;
};
};
The code to process this node is qe_muram_init() in
arch/powerpc/sysdev/qe_lib/qe.c.
if ((np = of_find_node_by_name(NULL, "data-only")) != NULL) {
address = *of_get_address(np, 0, &size, &flags);
of_node_put(np);
rh_attach_region(&qe_muram_info,
(void *)address, (int)size);
}
I think it would be trivial to modify this code to look for a Scott-style
muram node. Heck, it could be modified to look for both, and so we'll
maintain compatibility.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ 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