* Re: [PATCH] 8250: add workaround for MPC8[356]xx UART break IRQ storm
From: Paul Gortmaker @ 2010-02-26 20:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <EB2B2912-24C3-46C9-B894-0A84D593570F@kernel.crashing.org>
On 10-02-26 02:42 PM, Kumar Gala wrote:
>
> On Feb 26, 2010, at 1:25 PM, Paul Gortmaker wrote:
>
[...]
>>
>> + if ((up->bugs& UART_BUG_PPC)&& (status == UART_LSR_RFE_ERROR_BITS)) {
>> + spin_unlock_irqrestore(&up->port.lock, flags);
>> + return;
>> + }
>> +
[...]
>
> is there harm caused if we have SERIAL_8250_PPC_BUG set and dont need it?
In theory, no -- strip away all the window dressing and we are
left with the above change. So, you'd have to have some UART
implementation that was setting those bits and still relying
on its interrupt event to be processed normally. But since
there are so many different 8250 implementations out there,
I was being cautious and taking the absolute safe approach.
P.
>
> - k
^ permalink raw reply
* Re: [PATCH] 8250: add workaround for MPC8[356]xx UART break IRQ storm
From: Scott Wood @ 2010-02-26 20:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: Paul Gortmaker, linuxppc-dev, linux-serial
In-Reply-To: <EB2B2912-24C3-46C9-B894-0A84D593570F@kernel.crashing.org>
On Fri, Feb 26, 2010 at 01:42:39PM -0600, Kumar Gala wrote:
>
> On Feb 26, 2010, at 1:25 PM, Paul Gortmaker wrote:
>
> > Sending a break on the SOC UARTs found in some MPC83xx/85xx/86xx
> > chips seems to cause a short lived IRQ storm (/proc/interrupts
> > typically shows somewhere between 300 and 1500 events). Unfortunately
> > this renders SysRQ over the serial console completely inoperable.
> > Testing with obvious things like ACKing the event doesn't seem to
> > change anything vs. a completely dumb approach of just ignoring
> > it and waiting for it to stop, so that is what is implemented here.
> >
> > Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> > ---
> >
> > This is a refresh of a patch I'd done earlier -- I've tried to make
> > the bug support as generic as possible to minimize having board
> > specific ifdef crap in 8250.c -- any suggestions on how to further
> > improve it are welcome.
> >
> > drivers/serial/8250.c | 6 ++++++
> > drivers/serial/8250.h | 20 ++++++++++++++++++++
> > drivers/serial/Kconfig | 14 ++++++++++++++
> > include/linux/serial_reg.h | 2 ++
> > 4 files changed, 42 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
> > index e9b15c3..850b0e9 100644
> > --- a/drivers/serial/8250.c
> > +++ b/drivers/serial/8250.c
> > @@ -1531,6 +1531,11 @@ static void serial8250_handle_port(struct uart_8250_port *up)
> >
> > status = serial_inp(up, UART_LSR);
> >
> > + if ((up->bugs & UART_BUG_PPC) && (status == UART_LSR_RFE_ERROR_BITS)) {
> > + spin_unlock_irqrestore(&up->port.lock, flags);
> > + return;
> > + }
Will LSR always be 0xf1 when this problem hits? At least the transmit bits
shouldn't be relevant.
This has been listed as an erratum in some of the newer chips (e.g.
mpc8568).
The suggested as workaround is to, upon seeing a break condition:
- read RBR
- delay at least one character period
- read RBR again
If I'm interpreting this correctly, it could be implemented by doing the
normal break handling on the first interrupt, plus setting a flag so that the
next interrupt simply reads RBR, clears the flag, and returns, without ever
reading LSR.
-Scott
^ permalink raw reply
* [PATCH] 8250: add workaround for MPC8[356]xx UART break IRQ storm
From: Paul Gortmaker @ 2010-02-26 19:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-serial
Sending a break on the SOC UARTs found in some MPC83xx/85xx/86xx
chips seems to cause a short lived IRQ storm (/proc/interrupts
typically shows somewhere between 300 and 1500 events). Unfortunately
this renders SysRQ over the serial console completely inoperable.
Testing with obvious things like ACKing the event doesn't seem to
change anything vs. a completely dumb approach of just ignoring
it and waiting for it to stop, so that is what is implemented here.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
This is a refresh of a patch I'd done earlier -- I've tried to make
the bug support as generic as possible to minimize having board
specific ifdef crap in 8250.c -- any suggestions on how to further
improve it are welcome.
drivers/serial/8250.c | 6 ++++++
drivers/serial/8250.h | 20 ++++++++++++++++++++
drivers/serial/Kconfig | 14 ++++++++++++++
include/linux/serial_reg.h | 2 ++
4 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index e9b15c3..850b0e9 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -1531,6 +1531,11 @@ static void serial8250_handle_port(struct uart_8250_port *up)
status = serial_inp(up, UART_LSR);
+ if ((up->bugs & UART_BUG_PPC) && (status == UART_LSR_RFE_ERROR_BITS)) {
+ spin_unlock_irqrestore(&up->port.lock, flags);
+ return;
+ }
+
DEBUG_INTR("status = %x...", status);
if (status & (UART_LSR_DR | UART_LSR_BI))
@@ -1948,6 +1953,7 @@ static int serial8250_startup(struct uart_port *port)
up->capabilities = uart_config[up->port.type].flags;
up->mcr = 0;
+ up->bugs |= UART_KNOWN_BUGS;
if (up->port.iotype != up->cur_iotype)
set_io_from_upio(port);
diff --git a/drivers/serial/8250.h b/drivers/serial/8250.h
index 6e19ea3..2074ce1 100644
--- a/drivers/serial/8250.h
+++ b/drivers/serial/8250.h
@@ -49,6 +49,7 @@ struct serial8250_config {
#define UART_BUG_TXEN (1 << 1) /* UART has buggy TX IIR status */
#define UART_BUG_NOMSR (1 << 2) /* UART has buggy MSR status bits (Au1x00) */
#define UART_BUG_THRE (1 << 3) /* UART has buggy THRE reassertion */
+#define UART_BUG_PPC (1 << 4) /* UART has buggy PPC break IRQ storm */
#define PROBE_RSA (1 << 0)
#define PROBE_ANY (~0)
@@ -78,3 +79,22 @@ struct serial8250_config {
#else
#define ALPHA_KLUDGE_MCR 0
#endif
+
+/*
+ * The following UART bugs are currently dynamically detected and not
+ * required to be contingent on any particular compile time options.
+ */
+#define HAS_BUG_QUOT 0 /* assign UART_BUG_QUOT to enable */
+#define HAS_BUG_TXEN 0 /* assign UART_BUG_TXEN to enable */
+#define HAS_BUG_NOMSR 0 /* assign UART_BUG_NOMSR to enable */
+#define HAS_BUG_THRE 0 /* assign UART_BUG_THRE to enable */
+
+#ifdef CONFIG_SERIAL_8250_PPC_BUG
+#define HAS_BUG_PPC UART_BUG_PPC
+#else
+#define HAS_BUG_PPC 0
+#endif
+
+#define UART_KNOWN_BUGS (HAS_BUG_QUOT | HAS_BUG_TXEN | HAS_BUG_NOMSR | \
+ HAS_BUG_THRE | HAS_BUG_PPC)
+
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 9ff47db..e01a411 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -70,6 +70,20 @@ config SERIAL_8250_CONSOLE
If unsure, say N.
+config SERIAL_8250_PPC_BUG
+ bool "Fix 8250/16550 to handle IRQ storm after receipt of a break"
+ depends on SERIAL_8250 && PPC32
+ ---help---
+ If you say Y here, addional checks will be added in the handling of
+ interrupts on the serial ports which will prevent ill effects of
+ an interrupt storm triggered by a break on the serial line. Without
+ this enabled, a Sysrq via the serial console can be unusable on
+ some systems.
+
+ This is commonly observed on PPC32 MPC83xx/85xx/86xx based boards.
+
+ If unsure, say N.
+
config FIX_EARLYCON_MEM
bool
depends on X86
diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h
index cf9327c..010174f 100644
--- a/include/linux/serial_reg.h
+++ b/include/linux/serial_reg.h
@@ -111,6 +111,7 @@
#define UART_MCR_DTR 0x01 /* DTR complement */
#define UART_LSR 5 /* In: Line Status Register */
+#define UART_LSR_RFE 0x80 /* Rx FIFO Error (BE, FE, or PE) */
#define UART_LSR_TEMT 0x40 /* Transmitter empty */
#define UART_LSR_THRE 0x20 /* Transmit-hold-register empty */
#define UART_LSR_BI 0x10 /* Break interrupt indicator */
@@ -119,6 +120,7 @@
#define UART_LSR_OE 0x02 /* Overrun error indicator */
#define UART_LSR_DR 0x01 /* Receiver data ready */
#define UART_LSR_BRK_ERROR_BITS 0x1E /* BI, FE, PE, OE bits */
+#define UART_LSR_RFE_ERROR_BITS 0xF1 /* RFE, TEMT, THRE, BI, DR bits */
#define UART_MSR 6 /* In: Modem Status Register */
#define UART_MSR_DCD 0x80 /* Data Carrier Detect */
--
1.6.5.2
^ permalink raw reply related
* Re: [net-next-2.6 PATCH v2 0/3] Support for MPC512x FEC
From: David Miller @ 2010-02-26 20:48 UTC (permalink / raw)
To: agust; +Cc: wd, dzu, netdev, linuxppc-dev
In-Reply-To: <20100226211808.37931258@wker>
From: Anatolij Gustschin <agust@denx.de>
Date: Fri, 26 Feb 2010 21:18:08 +0100
> Hi David,
>
> On Mon, 22 Feb 2010 03:44:52 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Anatolij Gustschin <agust@denx.de>
>> Date: Mon, 22 Feb 2010 12:37:24 +0100
>>
>> > Could you please comment on this patch series.
>>
>> It's in the net-next-2.6 tree.
>>
>> If you need to make any more changes, they need to be relative
>> to what went into my tree.
>
> I've pulled your net-next-2.6 tree again and I don't see them
> in net-next-2.6 tree. Could you please check it again. Thanks!
Strange, please resubmit your patches.
Thanks.
^ permalink raw reply
* Re: Gianfar driver failing on MPC8641D based board
From: Anton Vorontsov @ 2010-02-26 21:38 UTC (permalink / raw)
To: Paul Gortmaker
Cc: netdev, linux-kernel, Martyn Welch, linuxppc-dev list,
Sandeep Gopalpet, davem
In-Reply-To: <4B87F67E.5070601@windriver.com>
On Fri, Feb 26, 2010 at 11:27:42AM -0500, Paul Gortmaker wrote:
> On 10-02-26 11:10 AM, Anton Vorontsov wrote:
> > On Fri, Feb 26, 2010 at 03:34:07PM +0000, Martyn Welch wrote:
> > [...]
> >> Out of 10 boot attempts, 7 failed.
> >
> > OK, I see why. With ip=on (dhcp boot) it's much harder to trigger
> > it. With static ip config can I see the same.
>
> I'd kind of expected to see us stuck in gianfar on that lock, but
> the SysRQ-T doesn't show us hung up anywhere in gianfar itself.
> [This was on a base 2.6.33, with just a small sysrq fix patch]
> [df841a30] [c0009fc4] __switch_to+0x8c/0xf8
> [df841a50] [c0350160] schedule+0x354/0x92c
> [df841ae0] [c0331394] rpc_wait_bit_killable+0x2c/0x54
> [df841af0] [c0350eb0] __wait_on_bit+0x9c/0x108
> [df841b10] [c0350fc0] out_of_line_wait_on_bit+0xa4/0xb4
> [df841b40] [c0331cf0] __rpc_execute+0x16c/0x398
> [df841b90] [c0329abc] rpc_run_task+0x48/0x9c
> [df841ba0] [c0329c40] rpc_call_sync+0x54/0x88
> [df841bd0] [c015e780] nfs_proc_lookup+0x94/0xe8
> [df841c20] [c014eb60] nfs_lookup+0x12c/0x230
> [df841d50] [c00b9680] do_lookup+0x118/0x288
> [df841d80] [c00bb904] link_path_walk+0x194/0x1118
> [df841df0] [c00bcb08] path_walk+0x8c/0x168
> [df841e20] [c00bcd6c] do_path_lookup+0x74/0x7c
> [df841e40] [c00be148] do_filp_open+0x5d4/0xba4
> [df841f10] [c00abe94] do_sys_open+0xac/0x190
Yeah, I don't think this is gianfar-related. It must be something
else triggered by the fact that gianfar no longer sends stuff.
OK, I think I found what's happening in gianfar.
Some background...
start_xmit() prepares new skb for transmitting, generally it does
three things:
1. sets up all BDs (marks them ready to send), except the first one.
2. stores skb into tx_queue->tx_skbuff so that clean_tx_ring()
would cleanup it later.
3. sets up the first BD, i.e. marks it ready.
Here is what clean_tx_ring() does:
1. reads skbs from tx_queue->tx_skbuff
2. Checks if the *last* BD is ready. If it's still ready [to send]
then it it isn't transmitted, so clean_tx_ring() returns.
Otherwise it actually cleanups BDs. All is OK.
Now, if there is just one BD, code flow:
- start_xmit(): stores skb into tx_skbuff. Note that the first BD
(which is also the last one) isn't marked as ready, yet.
- clean_tx_ring(): sees that skb is not null, *and* its lstatus
says that it is NOT ready (like if BD was sent), so it cleans
it up (bad!)
- start_xmit(): marks BD as ready [to send], but it's too late.
We can fix this simply by reordering lstatus/tx_skbuff writes.
It works flawlessly on my p2020, please try it.
Thanks!
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 8bd3c9f..cccb409 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -2021,7 +2021,6 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
}
/* setup the TxBD length and buffer pointer for the first BD */
- tx_queue->tx_skbuff[tx_queue->skb_curtx] = skb;
txbdp_start->bufPtr = dma_map_single(&priv->ofdev->dev, skb->data,
skb_headlen(skb), DMA_TO_DEVICE);
@@ -2053,6 +2052,10 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
txbdp_start->lstatus = lstatus;
+ eieio(); /* force lstatus write before tx_skbuff */
+
+ tx_queue->tx_skbuff[tx_queue->skb_curtx] = skb;
+
/* Update the current skb pointer to the next entry we will use
* (wrapping if necessary) */
tx_queue->skb_curtx = (tx_queue->skb_curtx + 1) &
^ permalink raw reply related
* [net-next-2.6 PATCH v3 0/3] Support for MPC512x FEC
From: Anatolij Gustschin @ 2010-02-26 22:00 UTC (permalink / raw)
To: netdev
Cc: Wolfgang Denk, Detlev Zundel, linuxppc-dev, Anatolij Gustschin,
David S. Miller
These patches attempt to provide support for the Freescale MPC512x
FEC in the fs_enet driver. The first cleanup patch replaces printk
by dev_xxx. The second and third attemt to support MPC5121 FEC
in the FEC driver.
Changes since previous version:
- don't attempt to provide runtime selection of
MPC5121 FEC support in the driver since it doesn't
make sense. Select MPC5121 FEC support at compile time.
- fix tx buffer alignment workaround patch to align
only misaligned buffers.
- address Eric's comments:
ratelimit warning message and
use 4-byte aligned skb->len for new properly
aligned skb.
The patches are based on net-next-2.6 and has been
tested on the:
- Freescale/STX "MPC5121ADS" board (board rev. 4) with
a MPC5121e Rev. 2.
- TQM860L and TQM855 boards.
Anatolij Gustschin (3):
fs_enet: use dev_xxx instead of printk
fs_enet: Add support for MPC512x to fs_enet driver
fs_enet: add FEC TX buffer alignment workaround for MPC5121
drivers/net/fs_enet/Kconfig | 10 +++-
drivers/net/fs_enet/fs_enet-main.c | 93 ++++++++++++++++++++++++++---------
drivers/net/fs_enet/fs_enet.h | 49 ++++++++++++++++++-
drivers/net/fs_enet/mac-fcc.c | 5 +-
drivers/net/fs_enet/mac-fec.c | 58 ++++++++++++++--------
drivers/net/fs_enet/mac-scc.c | 9 ++--
drivers/net/fs_enet/mii-fec.c | 4 +-
7 files changed, 169 insertions(+), 59 deletions(-)
^ permalink raw reply
* [net-next-2.6 PATCH v3 1/3] fs_enet: use dev_xxx instead of printk
From: Anatolij Gustschin @ 2010-02-26 22:00 UTC (permalink / raw)
To: netdev
Cc: Wolfgang Denk, Detlev Zundel, linuxppc-dev, Anatolij Gustschin,
David S. Miller
In-Reply-To: <1267221649-22754-1-git-send-email-agust@denx.de>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/net/fs_enet/fs_enet-main.c | 39 +++++++++++++----------------------
drivers/net/fs_enet/mac-fcc.c | 5 ++-
drivers/net/fs_enet/mac-fec.c | 12 ++++------
drivers/net/fs_enet/mac-scc.c | 9 +++----
4 files changed, 27 insertions(+), 38 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index ec2f503..c34a7e0 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -108,9 +108,7 @@ static int fs_enet_rx_napi(struct napi_struct *napi, int budget)
* the last indicator should be set.
*/
if ((sc & BD_ENET_RX_LAST) == 0)
- printk(KERN_WARNING DRV_MODULE_NAME
- ": %s rcv is not +last\n",
- dev->name);
+ dev_warn(fep->dev, "rcv is not +last\n");
/*
* Check for errors.
@@ -178,9 +176,8 @@ static int fs_enet_rx_napi(struct napi_struct *napi, int budget)
received++;
netif_receive_skb(skb);
} else {
- printk(KERN_WARNING DRV_MODULE_NAME
- ": %s Memory squeeze, dropping packet.\n",
- dev->name);
+ dev_warn(fep->dev,
+ "Memory squeeze, dropping packet.\n");
fep->stats.rx_dropped++;
skbn = skb;
}
@@ -242,9 +239,7 @@ static int fs_enet_rx_non_napi(struct net_device *dev)
* the last indicator should be set.
*/
if ((sc & BD_ENET_RX_LAST) == 0)
- printk(KERN_WARNING DRV_MODULE_NAME
- ": %s rcv is not +last\n",
- dev->name);
+ dev_warn(fep->dev, "rcv is not +last\n");
/*
* Check for errors.
@@ -313,9 +308,8 @@ static int fs_enet_rx_non_napi(struct net_device *dev)
received++;
netif_rx(skb);
} else {
- printk(KERN_WARNING DRV_MODULE_NAME
- ": %s Memory squeeze, dropping packet.\n",
- dev->name);
+ dev_warn(fep->dev,
+ "Memory squeeze, dropping packet.\n");
fep->stats.rx_dropped++;
skbn = skb;
}
@@ -388,10 +382,10 @@ static void fs_enet_tx(struct net_device *dev)
} else
fep->stats.tx_packets++;
- if (sc & BD_ENET_TX_READY)
- printk(KERN_WARNING DRV_MODULE_NAME
- ": %s HEY! Enet xmit interrupt and TX_READY.\n",
- dev->name);
+ if (sc & BD_ENET_TX_READY) {
+ dev_warn(fep->dev,
+ "HEY! Enet xmit interrupt and TX_READY.\n");
+ }
/*
* Deferred means some collisions occurred during transmit,
@@ -511,9 +505,8 @@ void fs_init_bds(struct net_device *dev)
for (i = 0, bdp = fep->rx_bd_base; i < fep->rx_ring; i++, bdp++) {
skb = dev_alloc_skb(ENET_RX_FRSIZE);
if (skb == NULL) {
- printk(KERN_WARNING DRV_MODULE_NAME
- ": %s Memory squeeze, unable to allocate skb\n",
- dev->name);
+ dev_warn(fep->dev,
+ "Memory squeeze, unable to allocate skb\n");
break;
}
skb_align(skb, ENET_RX_ALIGN);
@@ -610,8 +603,7 @@ static int fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
* Ooops. All transmit buffers are full. Bail out.
* This should not happen, since the tx queue should be stopped.
*/
- printk(KERN_WARNING DRV_MODULE_NAME
- ": %s tx queue full!.\n", dev->name);
+ dev_warn(fep->dev, "tx queue full!.\n");
return NETDEV_TX_BUSY;
}
@@ -788,8 +780,7 @@ static int fs_enet_open(struct net_device *dev)
r = request_irq(fep->interrupt, fs_enet_interrupt, IRQF_SHARED,
"fs_enet-mac", dev);
if (r != 0) {
- printk(KERN_ERR DRV_MODULE_NAME
- ": %s Could not allocate FS_ENET IRQ!", dev->name);
+ dev_err(fep->dev, "Could not allocate FS_ENET IRQ!");
if (fep->fpi->use_napi)
napi_disable(&fep->napi);
return -EINVAL;
@@ -1053,7 +1044,7 @@ static int __devinit fs_enet_probe(struct of_device *ofdev,
if (ret)
goto out_free_bd;
- printk(KERN_INFO "%s: fs_enet: %pM\n", ndev->name, ndev->dev_addr);
+ pr_info("%s: fs_enet: %pM\n", ndev->name, ndev->dev_addr);
return 0;
diff --git a/drivers/net/fs_enet/mac-fcc.c b/drivers/net/fs_enet/mac-fcc.c
index a761d31..cf4f674 100644
--- a/drivers/net/fs_enet/mac-fcc.c
+++ b/drivers/net/fs_enet/mac-fcc.c
@@ -476,8 +476,9 @@ static void clear_int_events(struct net_device *dev, u32 int_events)
static void ev_error(struct net_device *dev, u32 int_events)
{
- printk(KERN_WARNING DRV_MODULE_NAME
- ": %s FS_ENET ERROR(s) 0x%x\n", dev->name, int_events);
+ struct fs_enet_private *fep = netdev_priv(dev);
+
+ dev_warn(fep->dev, "FS_ENET ERROR(s) 0x%x\n", int_events);
}
static int get_regs(struct net_device *dev, void *p, int *sizep)
diff --git a/drivers/net/fs_enet/mac-fec.c b/drivers/net/fs_enet/mac-fec.c
index ca806d1..8a632f6 100644
--- a/drivers/net/fs_enet/mac-fec.c
+++ b/drivers/net/fs_enet/mac-fec.c
@@ -257,8 +257,7 @@ static void restart(struct net_device *dev)
r = whack_reset(fep->fec.fecp);
if (r != 0)
- printk(KERN_ERR DRV_MODULE_NAME
- ": %s FEC Reset FAILED!\n", dev->name);
+ dev_err(fep->dev, "FEC Reset FAILED!\n");
/*
* Set station address.
*/
@@ -355,9 +354,7 @@ static void stop(struct net_device *dev)
udelay(1);
if (i == FEC_RESET_DELAY)
- printk(KERN_WARNING DRV_MODULE_NAME
- ": %s FEC timeout on graceful transmit stop\n",
- dev->name);
+ dev_warn(fep->dev, "FEC timeout on graceful transmit stop\n");
/*
* Disable FEC. Let only MII interrupts.
*/
@@ -433,8 +430,9 @@ static void clear_int_events(struct net_device *dev, u32 int_events)
static void ev_error(struct net_device *dev, u32 int_events)
{
- printk(KERN_WARNING DRV_MODULE_NAME
- ": %s FEC ERROR(s) 0x%x\n", dev->name, int_events);
+ struct fs_enet_private *fep = netdev_priv(dev);
+
+ dev_warn(fep->dev, "FEC ERROR(s) 0x%x\n", int_events);
}
static int get_regs(struct net_device *dev, void *p, int *sizep)
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
index 5bfc99b..c490a46 100644
--- a/drivers/net/fs_enet/mac-scc.c
+++ b/drivers/net/fs_enet/mac-scc.c
@@ -367,9 +367,7 @@ static void stop(struct net_device *dev)
udelay(1);
if (i == SCC_RESET_DELAY)
- printk(KERN_WARNING DRV_MODULE_NAME
- ": %s SCC timeout on graceful transmit stop\n",
- dev->name);
+ dev_warn(fep->dev, "SCC timeout on graceful transmit stop\n");
W16(sccp, scc_sccm, 0);
C32(sccp, scc_gsmrl, SCC_GSMRL_ENR | SCC_GSMRL_ENT);
@@ -429,8 +427,9 @@ static void clear_int_events(struct net_device *dev, u32 int_events)
static void ev_error(struct net_device *dev, u32 int_events)
{
- printk(KERN_WARNING DRV_MODULE_NAME
- ": %s SCC ERROR(s) 0x%x\n", dev->name, int_events);
+ struct fs_enet_private *fep = netdev_priv(dev);
+
+ dev_warn(fep->dev, "SCC ERROR(s) 0x%x\n", int_events);
}
static int get_regs(struct net_device *dev, void *p, int *sizep)
--
1.6.3.3
^ permalink raw reply related
* [net-next-2.6 PATCH v3 2/3] fs_enet: Add support for MPC512x to fs_enet driver
From: Anatolij Gustschin @ 2010-02-26 22:00 UTC (permalink / raw)
To: netdev
Cc: Wolfgang Denk, Detlev Zundel, linuxppc-dev, Anatolij Gustschin,
David S. Miller, Piotr Ziecik
In-Reply-To: <1267221649-22754-1-git-send-email-agust@denx.de>
Extend the fs_enet driver to support MPC512x FEC.
Enable it with CONFIG_FS_ENET_MPC5121_FEC option.
Signed-off-by: John Rigby <jcrigby@gmail.com>
Signed-off-by: Piotr Ziecik <kosmo@semihalf.com>
Signed-off-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/net/fs_enet/Kconfig | 10 +++++--
drivers/net/fs_enet/fs_enet-main.c | 7 +++++
drivers/net/fs_enet/fs_enet.h | 49 +++++++++++++++++++++++++++++++++++-
drivers/net/fs_enet/mac-fec.c | 46 ++++++++++++++++++++++-----------
drivers/net/fs_enet/mii-fec.c | 4 +-
5 files changed, 95 insertions(+), 21 deletions(-)
diff --git a/drivers/net/fs_enet/Kconfig b/drivers/net/fs_enet/Kconfig
index 562ea68..fc073b5 100644
--- a/drivers/net/fs_enet/Kconfig
+++ b/drivers/net/fs_enet/Kconfig
@@ -1,9 +1,13 @@
config FS_ENET
tristate "Freescale Ethernet Driver"
- depends on CPM1 || CPM2
+ depends on CPM1 || CPM2 || PPC_MPC512x
select MII
select PHYLIB
+config FS_ENET_MPC5121_FEC
+ def_bool y if (FS_ENET && PPC_MPC512x)
+ select FS_ENET_HAS_FEC
+
config FS_ENET_HAS_SCC
bool "Chip has an SCC usable for ethernet"
depends on FS_ENET && (CPM1 || CPM2)
@@ -16,13 +20,13 @@ config FS_ENET_HAS_FCC
config FS_ENET_HAS_FEC
bool "Chip has an FEC usable for ethernet"
- depends on FS_ENET && CPM1
+ depends on FS_ENET && (CPM1 || FS_ENET_MPC5121_FEC)
select FS_ENET_MDIO_FEC
default y
config FS_ENET_MDIO_FEC
tristate "MDIO driver for FEC"
- depends on FS_ENET && CPM1
+ depends on FS_ENET && (CPM1 || FS_ENET_MPC5121_FEC)
config FS_ENET_MDIO_FCC
tristate "MDIO driver for FCC"
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index c34a7e0..4297021 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -1094,11 +1094,18 @@ static struct of_device_id fs_enet_match[] = {
},
#endif
#ifdef CONFIG_FS_ENET_HAS_FEC
+#ifdef CONFIG_FS_ENET_MPC5121_FEC
+ {
+ .compatible = "fsl,mpc5121-fec",
+ .data = (void *)&fs_fec_ops,
+ },
+#else
{
.compatible = "fsl,pq1-fec-enet",
.data = (void *)&fs_fec_ops,
},
#endif
+#endif
{}
};
MODULE_DEVICE_TABLE(of, fs_enet_match);
diff --git a/drivers/net/fs_enet/fs_enet.h b/drivers/net/fs_enet/fs_enet.h
index ef01e09..1ece4b1 100644
--- a/drivers/net/fs_enet/fs_enet.h
+++ b/drivers/net/fs_enet/fs_enet.h
@@ -13,9 +13,56 @@
#ifdef CONFIG_CPM1
#include <asm/cpm1.h>
+#endif
+
+#if defined(CONFIG_FS_ENET_HAS_FEC)
+#include <asm/cpm.h>
+
+#if defined(CONFIG_FS_ENET_MPC5121_FEC)
+/* MPC5121 FEC has different register layout */
+struct fec {
+ u32 fec_reserved0;
+ u32 fec_ievent; /* Interrupt event reg */
+ u32 fec_imask; /* Interrupt mask reg */
+ u32 fec_reserved1;
+ u32 fec_r_des_active; /* Receive descriptor reg */
+ u32 fec_x_des_active; /* Transmit descriptor reg */
+ u32 fec_reserved2[3];
+ u32 fec_ecntrl; /* Ethernet control reg */
+ u32 fec_reserved3[6];
+ u32 fec_mii_data; /* MII manage frame reg */
+ u32 fec_mii_speed; /* MII speed control reg */
+ u32 fec_reserved4[7];
+ u32 fec_mib_ctrlstat; /* MIB control/status reg */
+ u32 fec_reserved5[7];
+ u32 fec_r_cntrl; /* Receive control reg */
+ u32 fec_reserved6[15];
+ u32 fec_x_cntrl; /* Transmit Control reg */
+ u32 fec_reserved7[7];
+ u32 fec_addr_low; /* Low 32bits MAC address */
+ u32 fec_addr_high; /* High 16bits MAC address */
+ u32 fec_opd; /* Opcode + Pause duration */
+ u32 fec_reserved8[10];
+ u32 fec_hash_table_high; /* High 32bits hash table */
+ u32 fec_hash_table_low; /* Low 32bits hash table */
+ u32 fec_grp_hash_table_high; /* High 32bits hash table */
+ u32 fec_grp_hash_table_low; /* Low 32bits hash table */
+ u32 fec_reserved9[7];
+ u32 fec_x_wmrk; /* FIFO transmit water mark */
+ u32 fec_reserved10;
+ u32 fec_r_bound; /* FIFO receive bound reg */
+ u32 fec_r_fstart; /* FIFO receive start reg */
+ u32 fec_reserved11[11];
+ u32 fec_r_des_start; /* Receive descriptor ring */
+ u32 fec_x_des_start; /* Transmit descriptor ring */
+ u32 fec_r_buff_size; /* Maximum receive buff size */
+ u32 fec_reserved12[26];
+ u32 fec_dma_control; /* DMA Endian and other ctrl */
+};
+#endif
struct fec_info {
- fec_t __iomem *fecp;
+ struct fec __iomem *fecp;
u32 mii_speed;
};
#endif
diff --git a/drivers/net/fs_enet/mac-fec.c b/drivers/net/fs_enet/mac-fec.c
index 8a632f6..cd2c6cc 100644
--- a/drivers/net/fs_enet/mac-fec.c
+++ b/drivers/net/fs_enet/mac-fec.c
@@ -80,7 +80,7 @@
*/
#define FEC_RESET_DELAY 50
-static int whack_reset(fec_t __iomem *fecp)
+static int whack_reset(struct fec __iomem *fecp)
{
int i;
@@ -168,7 +168,7 @@ static void cleanup_data(struct net_device *dev)
static void set_promiscuous_mode(struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
- fec_t __iomem *fecp = fep->fec.fecp;
+ struct fec __iomem *fecp = fep->fec.fecp;
FS(fecp, r_cntrl, FEC_RCNTRL_PROM);
}
@@ -216,7 +216,7 @@ static void set_multicast_one(struct net_device *dev, const u8 *mac)
static void set_multicast_finish(struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
- fec_t __iomem *fecp = fep->fec.fecp;
+ struct fec __iomem *fecp = fep->fec.fecp;
/* if all multi or too many multicasts; just enable all */
if ((dev->flags & IFF_ALLMULTI) != 0 ||
@@ -246,7 +246,7 @@ static void set_multicast_list(struct net_device *dev)
static void restart(struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
- fec_t __iomem *fecp = fep->fec.fecp;
+ struct fec __iomem *fecp = fep->fec.fecp;
const struct fs_platform_info *fpi = fep->fpi;
dma_addr_t rx_bd_base_phys, tx_bd_base_phys;
int r;
@@ -280,7 +280,11 @@ static void restart(struct net_device *dev)
* Set maximum receive buffer size.
*/
FW(fecp, r_buff_size, PKT_MAXBLR_SIZE);
+#ifdef CONFIG_FS_ENET_MPC5121_FEC
+ FW(fecp, r_cntrl, PKT_MAXBUF_SIZE << 16);
+#else
FW(fecp, r_hash, PKT_MAXBUF_SIZE);
+#endif
/* get physical address */
rx_bd_base_phys = fep->ring_mem_addr;
@@ -297,7 +301,11 @@ static void restart(struct net_device *dev)
/*
* Enable big endian and don't care about SDMA FC.
*/
+#ifdef CONFIG_FS_ENET_MPC5121_FEC
+ FS(fecp, dma_control, 0xC0000000);
+#else
FW(fecp, fun_code, 0x78000000);
+#endif
/*
* Set MII speed.
@@ -308,9 +316,17 @@ static void restart(struct net_device *dev)
* Clear any outstanding interrupt.
*/
FW(fecp, ievent, 0xffc0);
+#ifndef CONFIG_FS_ENET_MPC5121_FEC
FW(fecp, ivec, (virq_to_hw(fep->interrupt) / 2) << 29);
FW(fecp, r_cntrl, FEC_RCNTRL_MII_MODE); /* MII enable */
+#else
+ /*
+ * Only set MII mode - do not touch maximum frame length
+ * configured before.
+ */
+ FS(fecp, r_cntrl, FEC_RCNTRL_MII_MODE);
+#endif
/*
* adjust to duplex mode
*/
@@ -339,7 +355,7 @@ static void stop(struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
const struct fs_platform_info *fpi = fep->fpi;
- fec_t __iomem *fecp = fep->fec.fecp;
+ struct fec __iomem *fecp = fep->fec.fecp;
struct fec_info* feci= fep->phydev->bus->priv;
@@ -375,7 +391,7 @@ static void stop(struct net_device *dev)
static void napi_clear_rx_event(struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
- fec_t __iomem *fecp = fep->fec.fecp;
+ struct fec __iomem *fecp = fep->fec.fecp;
FW(fecp, ievent, FEC_NAPI_RX_EVENT_MSK);
}
@@ -383,7 +399,7 @@ static void napi_clear_rx_event(struct net_device *dev)
static void napi_enable_rx(struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
- fec_t __iomem *fecp = fep->fec.fecp;
+ struct fec __iomem *fecp = fep->fec.fecp;
FS(fecp, imask, FEC_NAPI_RX_EVENT_MSK);
}
@@ -391,7 +407,7 @@ static void napi_enable_rx(struct net_device *dev)
static void napi_disable_rx(struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
- fec_t __iomem *fecp = fep->fec.fecp;
+ struct fec __iomem *fecp = fep->fec.fecp;
FC(fecp, imask, FEC_NAPI_RX_EVENT_MSK);
}
@@ -399,7 +415,7 @@ static void napi_disable_rx(struct net_device *dev)
static void rx_bd_done(struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
- fec_t __iomem *fecp = fep->fec.fecp;
+ struct fec __iomem *fecp = fep->fec.fecp;
FW(fecp, r_des_active, 0x01000000);
}
@@ -407,7 +423,7 @@ static void rx_bd_done(struct net_device *dev)
static void tx_kickstart(struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
- fec_t __iomem *fecp = fep->fec.fecp;
+ struct fec __iomem *fecp = fep->fec.fecp;
FW(fecp, x_des_active, 0x01000000);
}
@@ -415,7 +431,7 @@ static void tx_kickstart(struct net_device *dev)
static u32 get_int_events(struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
- fec_t __iomem *fecp = fep->fec.fecp;
+ struct fec __iomem *fecp = fep->fec.fecp;
return FR(fecp, ievent) & FR(fecp, imask);
}
@@ -423,7 +439,7 @@ static u32 get_int_events(struct net_device *dev)
static void clear_int_events(struct net_device *dev, u32 int_events)
{
struct fs_enet_private *fep = netdev_priv(dev);
- fec_t __iomem *fecp = fep->fec.fecp;
+ struct fec __iomem *fecp = fep->fec.fecp;
FW(fecp, ievent, int_events);
}
@@ -439,17 +455,17 @@ static int get_regs(struct net_device *dev, void *p, int *sizep)
{
struct fs_enet_private *fep = netdev_priv(dev);
- if (*sizep < sizeof(fec_t))
+ if (*sizep < sizeof(struct fec))
return -EINVAL;
- memcpy_fromio(p, fep->fec.fecp, sizeof(fec_t));
+ memcpy_fromio(p, fep->fec.fecp, sizeof(struct fec));
return 0;
}
static int get_regs_len(struct net_device *dev)
{
- return sizeof(fec_t);
+ return sizeof(struct fec);
}
static void tx_restart(struct net_device *dev)
diff --git a/drivers/net/fs_enet/mii-fec.c b/drivers/net/fs_enet/mii-fec.c
index 96eba42..5944b65 100644
--- a/drivers/net/fs_enet/mii-fec.c
+++ b/drivers/net/fs_enet/mii-fec.c
@@ -52,7 +52,7 @@
static int fs_enet_fec_mii_read(struct mii_bus *bus , int phy_id, int location)
{
struct fec_info* fec = bus->priv;
- fec_t __iomem *fecp = fec->fecp;
+ struct fec __iomem *fecp = fec->fecp;
int i, ret = -1;
BUG_ON((in_be32(&fecp->fec_r_cntrl) & FEC_RCNTRL_MII_MODE) == 0);
@@ -75,7 +75,7 @@ static int fs_enet_fec_mii_read(struct mii_bus *bus , int phy_id, int location)
static int fs_enet_fec_mii_write(struct mii_bus *bus, int phy_id, int location, u16 val)
{
struct fec_info* fec = bus->priv;
- fec_t __iomem *fecp = fec->fecp;
+ struct fec __iomem *fecp = fec->fecp;
int i;
/* this must never happen */
--
1.6.3.3
^ permalink raw reply related
* [net-next-2.6 PATCH v3 3/3] fs_enet: add FEC TX buffer alignment workaround for MPC5121
From: Anatolij Gustschin @ 2010-02-26 22:00 UTC (permalink / raw)
To: netdev
Cc: Wolfgang Denk, Detlev Zundel, linuxppc-dev, Anatolij Gustschin,
David S. Miller, Piotr Ziecik
In-Reply-To: <1267221649-22754-1-git-send-email-agust@denx.de>
MPC5121 FEC requeries 4-byte alignmnent for TX data buffers.
This patch is a work around that copies misaligned tx packets
to an aligned skb before sending.
Signed-off-by: John Rigby <jcrigby@gmail.com>
Signed-off-by: Piotr Ziecik <kosmo@semihalf.com>
Signed-off-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
Changes since v2:
- ratelimit warning message
- use skb->len + 4 as size for allocation of the new skb
with aligned buffer.
drivers/net/fs_enet/fs_enet-main.c | 47 ++++++++++++++++++++++++++++++++++++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index 4297021..0770e2f 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -580,6 +580,40 @@ void fs_cleanup_bds(struct net_device *dev)
/**********************************************************************************/
+#ifdef CONFIG_FS_ENET_MPC5121_FEC
+/*
+ * MPC5121 FEC requeries 4-byte alignment for TX data buffer!
+ */
+static struct sk_buff *tx_skb_align_workaround(struct net_device *dev,
+ struct sk_buff *skb)
+{
+ struct sk_buff *new_skb;
+ struct fs_enet_private *fep = netdev_priv(dev);
+
+ /* Alloc new skb */
+ new_skb = dev_alloc_skb(skb->len + 4);
+ if (!new_skb) {
+ if (net_ratelimit()) {
+ dev_warn(fep->dev,
+ "Memory squeeze, dropping tx packet.\n");
+ }
+ return NULL;
+ }
+
+ /* Make sure new skb is properly aligned */
+ skb_align(new_skb, 4);
+
+ /* Copy data to new skb ... */
+ skb_copy_from_linear_data(skb, new_skb->data, skb->len);
+ skb_put(new_skb, skb->len);
+
+ /* ... and free an old one */
+ dev_kfree_skb_any(skb);
+
+ return new_skb;
+}
+#endif
+
static int fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
@@ -588,6 +622,19 @@ static int fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
u16 sc;
unsigned long flags;
+#ifdef CONFIG_FS_ENET_MPC5121_FEC
+ if (((unsigned long)skb->data) & 0x3) {
+ skb = tx_skb_align_workaround(dev, skb);
+ if (!skb) {
+ /*
+ * We have lost packet due to memory allocation error
+ * in tx_skb_align_workaround(). Hopefully original
+ * skb is still valid, so try transmit it later.
+ */
+ return NETDEV_TX_BUSY;
+ }
+ }
+#endif
spin_lock_irqsave(&fep->tx_lock, flags);
/*
--
1.6.3.3
^ permalink raw reply related
* Re: Gianfar driver failing on MPC8641D based board
From: Paul Gortmaker @ 2010-02-26 22:12 UTC (permalink / raw)
To: avorontsov
Cc: netdev, linux-kernel, Martyn Welch, linuxppc-dev list,
Sandeep Gopalpet, davem
In-Reply-To: <20100226213825.GA32363@oksana.dev.rtsoft.ru>
On 10-02-26 04:38 PM, Anton Vorontsov wrote:
> OK, I think I found what's happening in gianfar.
>
> Some background...
>
> start_xmit() prepares new skb for transmitting, generally it does
> three things:
>
> 1. sets up all BDs (marks them ready to send), except the first one.
> 2. stores skb into tx_queue->tx_skbuff so that clean_tx_ring()
> would cleanup it later.
> 3. sets up the first BD, i.e. marks it ready.
>
> Here is what clean_tx_ring() does:
>
> 1. reads skbs from tx_queue->tx_skbuff
> 2. Checks if the *last* BD is ready. If it's still ready [to send]
> then it it isn't transmitted, so clean_tx_ring() returns.
> Otherwise it actually cleanups BDs. All is OK.
>
> Now, if there is just one BD, code flow:
>
> - start_xmit(): stores skb into tx_skbuff. Note that the first BD
> (which is also the last one) isn't marked as ready, yet.
> - clean_tx_ring(): sees that skb is not null, *and* its lstatus
> says that it is NOT ready (like if BD was sent), so it cleans
> it up (bad!)
> - start_xmit(): marks BD as ready [to send], but it's too late.
>
> We can fix this simply by reordering lstatus/tx_skbuff writes.
>
> It works flawlessly on my p2020, please try it.
I've skipped right to the test part (I'll think about the description
more later) and it passed 5 out of 5 boot tests on NFSroot sbc8641d.
Looks like you've got a solution.
Paul.
>
> Thanks!
>
>
> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
> index 8bd3c9f..cccb409 100644
> --- a/drivers/net/gianfar.c
> +++ b/drivers/net/gianfar.c
> @@ -2021,7 +2021,6 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
> }
>
> /* setup the TxBD length and buffer pointer for the first BD */
> - tx_queue->tx_skbuff[tx_queue->skb_curtx] = skb;
> txbdp_start->bufPtr = dma_map_single(&priv->ofdev->dev, skb->data,
> skb_headlen(skb), DMA_TO_DEVICE);
>
> @@ -2053,6 +2052,10 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
>
> txbdp_start->lstatus = lstatus;
>
> + eieio(); /* force lstatus write before tx_skbuff */
> +
> + tx_queue->tx_skbuff[tx_queue->skb_curtx] = skb;
> +
> /* Update the current skb pointer to the next entry we will use
> * (wrapping if necessary) */
> tx_queue->skb_curtx = (tx_queue->skb_curtx + 1)&
^ permalink raw reply
* Proposal to move PCI out of arch/powerpc and into drivers/of
From: John Linn @ 2010-02-26 23:07 UTC (permalink / raw)
To: linux-kernel, devicetree-discuss, linuxppc-dev,
microblaze-uclinux
Cc: michal.simek, John Williams
Hi all,
We are in the process of putting PCI/PCIe into the microblaze
architecture. =
In order to not duplicate/fork the PCI code in Powerpc, we're proposing
to move the PCI code from arch/powerpc into drivers/of such that it
would be common code for Powerpc and MicroBlaze.
This would be the 1st part of a refactoring that would occur with the
PCI code.
Ben H., would you mind if that happened (move arch/powerpc/kernel/pci*
to drivers/of/*)?
Thanks,
John
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: Proposal to move PCI out of arch/powerpc and into drivers/of
From: Jesse Barnes @ 2010-02-26 23:44 UTC (permalink / raw)
To: John Linn
Cc: devicetree-discuss, michal.simek, microblaze-uclinux,
linux-kernel, linuxppc-dev, John Williams
In-Reply-To: <27bab769-0788-4b48-96a7-ced65e40144c@SG2EHSMHS007.ehs.local>
On Fri, 26 Feb 2010 16:07:59 -0700
John Linn <John.Linn@xilinx.com> wrote:
> Hi all,
>
> We are in the process of putting PCI/PCIe into the microblaze
> architecture.
>
> In order to not duplicate/fork the PCI code in Powerpc, we're
> proposing to move the PCI code from arch/powerpc into drivers/of such
> that it would be common code for Powerpc and MicroBlaze.
>
> This would be the 1st part of a refactoring that would occur with the
> PCI code.
>
> Ben H., would you mind if that happened (move arch/powerpc/kernel/pci*
> to drivers/of/*)?
Dave and Ben have been talking about this for awhile; seems like a good
excuse to do it. IIRC they had even thought about just dumping the
code directly into drivers/pci so that API updates won't get missed...
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: Proposal to move PCI out of arch/powerpc and into drivers/of
From: Kumar Gala @ 2010-02-26 23:50 UTC (permalink / raw)
To: John Linn
Cc: devicetree-discuss, michal.simek, microblaze-uclinux,
linux-kernel, linuxppc-dev, John Williams
In-Reply-To: <27bab769-0788-4b48-96a7-ced65e40144c@SG2EHSMHS007.ehs.local>
On Feb 26, 2010, at 5:07 PM, John Linn wrote:
> Hi all,
>=20
> We are in the process of putting PCI/PCIe into the microblaze
> architecture. =20
>=20
> In order to not duplicate/fork the PCI code in Powerpc, we're =
proposing
> to move the PCI code from arch/powerpc into drivers/of such that it
> would be common code for Powerpc and MicroBlaze.
>=20
> This would be the 1st part of a refactoring that would occur with the
> PCI code.
>=20
> Ben H., would you mind if that happened (move arch/powerpc/kernel/pci*
> to drivers/of/*)?
>=20
> Thanks,
> John
John,
Does MicroBlaze firmware produce full OF style PCI device tree's or do =
what we do on embedded systems and just have the root and leave the =
probing to the kernel? I haven't looked at the OF side of what we do in =
PPC in a while but I know we have some major differences between PPC32 & =
PPC64 because of assumptions about what the firmware provides (or =
doesnt).
As well as features on the PPC64 side to not re-probe PCI and build =
internal kernel data structures purely from the OF tree.
I think moving the code and sharing it between everyone is a good thing, =
just point out some issues I know we are aware of.
- k=
^ permalink raw reply
* Re: Proposal to move PCI out of arch/powerpc and into drivers/of
From: Grant Likely @ 2010-02-27 0:17 UTC (permalink / raw)
To: Kumar Gala
Cc: devicetree-discuss, michal.simek, microblaze-uclinux,
linux-kernel, linuxppc-dev, John Linn, John Williams
In-Reply-To: <CDF924F6-56F9-4F3D-9CF9-BF321437C3B5@kernel.crashing.org>
On Fri, Feb 26, 2010 at 4:50 PM, Kumar Gala <galak@kernel.crashing.org> wro=
te:
>
> On Feb 26, 2010, at 5:07 PM, John Linn wrote:
>
>> Hi all,
>>
>> We are in the process of putting PCI/PCIe into the microblaze
>> architecture.
>>
>> In order to not duplicate/fork the PCI code in Powerpc, we're proposing
>> to move the PCI code from arch/powerpc into drivers/of such that it
>> would be common code for Powerpc and MicroBlaze.
>>
>> This would be the 1st part of a refactoring that would occur with the
>> PCI code.
>>
>> Ben H., would you mind if that happened (move arch/powerpc/kernel/pci*
>> to drivers/of/*)?
>>
>> Thanks,
>> John
>
> John,
>
> Does MicroBlaze firmware produce full OF style PCI device tree's or do wh=
at we do on embedded systems and just have the root and leave the probing t=
o the kernel?
Mostly like we do on ppc embedded. Let the kernel do the probing.
I'm also going to want to be able to do the same think on ARM, so I
also would like to make the code common.
> =A0I haven't looked at the OF side of what we do in PPC in a while but I =
know we have some major differences between PPC32 & PPC64 because of assump=
tions about what the firmware provides (or doesnt).
I'm not too worried about this. I did some work on ppc32 to allow
both probing and static PCI device definition on the same bus segment
(although I didn't get all of it merged). There are difference
between ppc32 & ppc64, but it seemed to me that the divergence was
more just a matter of convenience rather than any particular technical
hurdles preventing a common approach. I think the 32 and 64 bit paths
can be mostly merged.
g.
^ permalink raw reply
* Re: Does Linux 2.6.32 support NAND flash connect with MPC8247 through localbus with GPCM mode?
From: Peter Pan @ 2010-02-27 1:12 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20100226183559.GA17941@loki.buserror.net>
2010/2/27 Scott Wood <scottwood@freescale.com>:
> On Fri, Feb 26, 2010 at 10:08:09AM +0800, Peter Pan wrote:
> There isn't one. =A0I was not under the impression that such a configurat=
ion
> was even possible (how do you control ALE/CLE, for example?). =A0There is=
a
> NAND driver that uses UPM, though -- perhaps you could use that?
>
> How specifically is NAND connected to the SoC on your board? =A0What abou=
t it
> suggests GPCM?
>
> -Scott
>
Our custom board is originally running VxWorks, and there is a full
solution on NAND
flash connected through GPCM. Because of this, our Linux can only try
to adapt to this.
I'm now writing GPCM NAND driver from the UPM NAND driver. Most function ca=
n be
copied from our U-Boot port. Now the NAND flash can be recognized, but ther=
e is
some bug in my driver, the kernel will oops for access 0x00000000, I
will continue
writing the driver next monday.
^ permalink raw reply
* Re: [PATCH] hvc_console: Fix a race between hvc_close and hvc_remove
From: Alan Cox @ 2010-02-27 1:33 UTC (permalink / raw)
To: Amit Shah; +Cc: linuxppc-dev, Rusty Russell, linux-kernel
In-Reply-To: <1267184786-4377-1-git-send-email-amit.shah@redhat.com>
> + tty_kref_get(hp->tty);
> spin_lock_irqsave(&hp->lock, flags);
> tty = hp->tty;
>
> @@ -830,7 +833,9 @@ int hvc_remove(struct hvc_struct *hp)
> * cleaned up the hvc_struct.
> */
> if (tty)
> - tty_hangup(tty);
> + tty_vhangup(tty);
> +
> + tty_kref_put(hp->tty);
You need to deref hp->tty, take the kref under the lock (and indeed do
all assignments to it that way too), then tty_kref_put(tty), otherwise
what stops hp->tty changing during the remove ?
Take a look how tty_port_tty_get() and tty_port.c does it ...
Alan
^ permalink raw reply
* PCI NIC for powerpc system
From: John Linn @ 2010-02-27 1:57 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I should apologize ahead of time for my lack of knowledge with PCI.
I'm trying to better understand if I can run a standard off the shelf
PCI NIC with a powerpc kernel as the PCI with device tree is not clear
to me.
I don't see many Ethernet drivers having OF support in them so maybe
devices on the PCI bus are discovered by the kernel such that the
drivers don't need to be OF aware.
Any advice is appreciated.
Thanks,
John
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* [git pull] Please pull powerpc.git next branch
From: Benjamin Herrenschmidt @ 2010-02-27 3:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here's your batch of powerpc stuff for 2.6.34. As you can see, it's
reasonably small this time around. There's a pile of scalability
improvements from Anton, a batch of raw_spinlock conversion from Thomas,
and a few more bits and pieces.
Cheers,
Ben.
The following changes since commit 6ebdc661b608671e9ca572af8bb42d58108cc008:
Linus Torvalds (1):
Merge branch 'next-devicetree' of git://git.secretlab.ca/git/linux-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next
Amit Shah (1):
hvc_console: Remove __devinit annotation from hvc_alloc
Anatolij Gustschin (10):
powerpc/mpc5121: avoid using arch_initcall for clock init
powerpc/mpc5121: Add machine restart support
rtc: Add MPC5121 Real time clock driver
powerpc/mpc5121: create and register NFC device
powerpc/mpc5121: update mpc5121ads DTS
powerpc/mpc5121: Add default config for MPC5121
serial: mpc52xx_uart: re-enable mpc5121 PSC UART support
powerpc: doc/dts-bindings: document mpc5121 psc uart dts-bindings
powerpc/mpc5121: enable support for more PSC UARTs
powerpc/mpc5121: correct DIU compatible property
Anton Blanchard (25):
powerpc: Replace per_cpu(, smp_processor_id()) with __get_cpu_var()
powerpc: Mark some variables in the page fault path __read_mostly
powerpc: Increase NR_IRQS Kconfig maximum to 32768
powerpc/pseries: Quieten cede latency printk
powerpc: Reduce differences between pseries and ppc64 defconfigs
powerpc: Add last sysfs file and dump of ftrace buffer to oops printout
powerpc: Convert mmu context allocator from idr to ida
powerpc: Reformat SD_NODE_INIT to match x86
powerpc: Make powerpc_firmware_features __read_mostly
powerpc: Clear MSR_RI during RTAS calls
powerpc: Only print clockevent settings once
powerpc: Reduce footprint of irq_stat
powerpc: Reduce footprint of xics_ipi_struct
powerpc: Rework /proc/interrupts
powerpc: Remove whitespace in irq chip name fields
powerpc: Add timer, performance monitor and machine check counts to /proc/interrupts
powerpc: Convert global "BAD" interrupt to per cpu spurious
powerpc: Use lwarx hint in spinlocks
powerpc: Use lwarx/ldarx hint in bit locks
powerpc: Convert open coded native hashtable bit lock
powerpc: Rename LWSYNC_ON_SMP to PPC_RELEASE_BARRIER, ISYNC_ON_SMP to PPC_ACQUIRE_BARRIER
powerpc: Fix lwsync patching code on 64bit
powerpc: Use lwsync for acquire barrier if CPU supports it
powerpc: Pair loads and stores in copy_4k_page
powerpc: Improve 64bit copy_tofrom_user
Anton Vorontsov (1):
powerpc/85xx: Add NOR, LEDs and PIB support for MPC8568E-MDS boards
Benjamin Herrenschmidt (6):
powerpc/pseries: Pass more accurate number of supported cores to firmware
Merge commit 'origin/master' into next
Merge commit 'jwb/next' into next
Merge commit 'gcl/next' into next
Merge commit 'origin/master' into next
powerpc: Fix lwsync feature fixup vs. modules on 64-bit
Breno Leitao (1):
powerpc/eeh: Fix a bug when pci structure is null
Corey Minyard (1):
powerpc: Add coherent_dma_mask to mv64x60 devices
Dave Kleikamp (4):
powerpc/booke: Introduce new CONFIG options for advanced debug registers
powerpc: Extended ptrace interface
powerpc/booke: Add definitions for advanced debug registers
powerpc/booke: Add support for advanced debug registers
Ernst Schwab (1):
powerpc/of: added documentation for spi chipselects
Frans Pop (1):
powerpc: Remove trailing space in messages
Jean Delvare (2):
macintosh/therm_adt746x: Fix sysfs attributes lifetime
macintosh/hwmon/ams: Fix device removal sequence
Joe Perches (2):
powerpc/viodasd: Remove VIOD_KERN_<level> macros for printks
arch/powerpc: Fix continuation line formats
Malcolm Crossley (3):
powerpc/86xx: Fix GE SBC310 XMC site support
powerpc/86xx: Add MSI section to GE SBC610 DTS
powerpc/86xx: Add MSI section to GE PPC9A DTS
Martyn Welch (5):
powerpc/86xx: Add MSI section to GE SBC310 DTS
powerpc/86xx: Basic flash support for GE SBC610
powerpc/86xx: Switch on highmem support on GE SBC610
powerpc/86xx: Enable VME driver on the GE PPC9A
powerpc/86xx: Enable VME driver on the GE SBC610
Michael Ellerman (1):
lmb: Add lmb_free()
Peter Tyser (1):
powerpc/85xx: Fix SMP when "cpu-release-addr" is in lowmem
Robert P. J. Day (1):
powerpc: Simplify param.h by including <asm-generic/param.h>
Rusty Russell (1):
hvc_console: Make the ops pointer const.
Sebastian Andrzej Siewior (1):
powerpc/fsl-booke: replace a hardcoded constant
Stefan Roese (6):
powerpc/44x: Fix L2-cache support for 460GT
powerpc/44x: Add MTD support (NOR FLASH) to Katmai dts
powerpc/44x: Update Arches dts
powerpc/44x: Update Glacier dts
powerpc/44x: Add MTD support to katmai defconfig
powerpc/40x: Add support for PPC40x boards with > 512MB SDRAM
Thadeu Lima de Souza Cascardo (1):
powerpc: Fix typo s/leve/level/ in TLB code
Thomas Gleixner (15):
powerpc: Convert context_lock to raw_spinlock
powerpc: Convert nv_lock to raw_spinlock
powerpc: Convert beatic_irq_mask_lock to raw_spinlock
powerpc: Convert native_tlbie_lock to raw_spinlock
powerpc: Convert ipic_lock to raw_spinlock
powerpc: Convert confirm_error_lock to raw_spinlock
powerpc: Convert beat_htab_lock to raw_spinlock
powerpc: Convert i8259_lock to raw_spinlock
powerpc: Convert feature_lock to raw_spinlock
powerpc: Convert big_irq_lock to raw_spinlock
powerpc: Convert pmac_pic_lock to raw_spinlock
powerpc: Convert mpic locks to raw_spinlock
powerpc: Convert tlbivax_lock to raw_spinlock
powerpc: Convert die.lock to raw_spinlock
powerpc: Convert pmc_owner_lock to raw_spinlock
Will Schmidt (1):
powerpc/pseries: Hypervisor call tracepoints hcall_stats touchup
jschopp@austin.ibm.com (1):
powerpc: Add static fields to ibm,client-architecture call
.../powerpc/dts-bindings/fsl/mpc5121-psc.txt | 70 +
Documentation/powerpc/dts-bindings/fsl/spi.txt | 7 +
Documentation/powerpc/ptrace.txt | 134 ++
arch/powerpc/Kconfig | 29 +-
arch/powerpc/boot/dts/arches.dts | 12 +
arch/powerpc/boot/dts/gef_ppc9a.dts | 16 +
arch/powerpc/boot/dts/gef_sbc310.dts | 19 +-
arch/powerpc/boot/dts/gef_sbc610.dts | 66 +-
arch/powerpc/boot/dts/glacier.dts | 76 +-
arch/powerpc/boot/dts/katmai.dts | 71 +-
arch/powerpc/boot/dts/mpc5121ads.dts | 55 +-
arch/powerpc/boot/dts/mpc8568mds.dts | 65 +-
arch/powerpc/configs/44x/katmai_defconfig | 94 +-
arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 47 +-
arch/powerpc/configs/86xx/gef_sbc610_defconfig | 65 +-
arch/powerpc/configs/mpc512x_defconfig | 1694 ++++++++++++++++++++
arch/powerpc/configs/ppc64_defconfig | 75 +-
arch/powerpc/configs/pseries_defconfig | 63 +-
arch/powerpc/include/asm/asm-compat.h | 5 +-
arch/powerpc/include/asm/atomic.h | 48 +-
arch/powerpc/include/asm/bitops.h | 56 +-
arch/powerpc/include/asm/cputable.h | 4 +-
arch/powerpc/include/asm/cputime.h | 7 +-
arch/powerpc/include/asm/feature-fixups.h | 2 +-
arch/powerpc/include/asm/futex.h | 6 +-
arch/powerpc/include/asm/hardirq.h | 30 +-
arch/powerpc/include/asm/local.h | 12 +-
arch/powerpc/include/asm/mpc5121.h | 24 +
arch/powerpc/include/asm/mpc52xx_psc.h | 4 +
arch/powerpc/include/asm/mpic.h | 2 +-
arch/powerpc/include/asm/mutex.h | 6 +-
arch/powerpc/include/asm/param.h | 23 +-
arch/powerpc/include/asm/pmac_feature.h | 2 +-
arch/powerpc/include/asm/ppc-opcode.h | 18 +
arch/powerpc/include/asm/ppc-pci.h | 5 +
arch/powerpc/include/asm/processor.h | 36 +-
arch/powerpc/include/asm/ptrace.h | 77 +
arch/powerpc/include/asm/reg_booke.h | 96 ++-
arch/powerpc/include/asm/spinlock.h | 32 +-
arch/powerpc/include/asm/synch.h | 12 +-
arch/powerpc/include/asm/system.h | 21 +-
arch/powerpc/include/asm/topology.h | 48 +-
arch/powerpc/kernel/entry_64.S | 3 +-
arch/powerpc/kernel/firmware.c | 2 +-
arch/powerpc/kernel/head_fsl_booke.S | 4 +-
arch/powerpc/kernel/irq.c | 140 ++-
arch/powerpc/kernel/kgdb.c | 2 +-
arch/powerpc/kernel/kprobes.c | 4 +-
arch/powerpc/kernel/lparcfg.c | 10 +-
arch/powerpc/kernel/nvram_64.c | 6 +-
arch/powerpc/kernel/pci_of_scan.c | 2 +-
arch/powerpc/kernel/pmc.c | 10 +-
arch/powerpc/kernel/process.c | 116 ++-
arch/powerpc/kernel/prom_init.c | 81 +-
arch/powerpc/kernel/ptrace.c | 516 ++++++-
arch/powerpc/kernel/signal.c | 6 +-
arch/powerpc/kernel/signal_32.c | 16 +-
arch/powerpc/kernel/time.c | 10 +-
arch/powerpc/kernel/traps.c | 128 ++-
arch/powerpc/lib/copypage_64.S | 28 +-
arch/powerpc/lib/copyuser_64.S | 80 +-
arch/powerpc/lib/feature-fixups.c | 3 +-
arch/powerpc/mm/40x_mmu.c | 4 +-
arch/powerpc/mm/hash_native_64.c | 19 +-
arch/powerpc/mm/mmu_context_hash64.c | 10 +-
arch/powerpc/mm/mmu_context_nohash.c | 14 +-
arch/powerpc/mm/tlb_low_64e.S | 2 +-
arch/powerpc/mm/tlb_nohash.c | 6 +-
arch/powerpc/platforms/512x/clock.c | 6 +-
arch/powerpc/platforms/512x/mpc5121_ads.c | 3 +-
arch/powerpc/platforms/512x/mpc5121_ads_cpld.c | 2 +-
arch/powerpc/platforms/512x/mpc5121_generic.c | 3 +-
arch/powerpc/platforms/512x/mpc512x.h | 3 +
arch/powerpc/platforms/512x/mpc512x_shared.c | 43 +
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 3 +
arch/powerpc/platforms/85xx/socrates_fpga_pic.c | 2 +-
arch/powerpc/platforms/85xx/stx_gp3.c | 2 +-
arch/powerpc/platforms/cell/beat_htab.c | 24 +-
arch/powerpc/platforms/cell/beat_interrupt.c | 20 +-
arch/powerpc/platforms/cell/interrupt.c | 4 +-
arch/powerpc/platforms/cell/spider-pic.c | 2 +-
arch/powerpc/platforms/iseries/irq.c | 2 +-
arch/powerpc/platforms/iseries/proc.c | 2 +-
arch/powerpc/platforms/iseries/setup.c | 2 +-
arch/powerpc/platforms/powermac/bootx_init.c | 4 +-
arch/powerpc/platforms/powermac/feature.c | 6 +-
arch/powerpc/platforms/powermac/nvram.c | 14 +-
arch/powerpc/platforms/powermac/pfunc_base.c | 24 +-
arch/powerpc/platforms/powermac/pic.c | 40 +-
arch/powerpc/platforms/pseries/eeh.c | 18 +-
arch/powerpc/platforms/pseries/eeh_driver.c | 10 +-
arch/powerpc/platforms/pseries/eeh_event.c | 2 +-
arch/powerpc/platforms/pseries/hotplug-cpu.c | 22 +-
arch/powerpc/platforms/pseries/hvCall_inst.c | 4 +-
arch/powerpc/platforms/pseries/pci_dlpar.c | 2 +-
arch/powerpc/platforms/pseries/phyp_dump.c | 6 +-
arch/powerpc/platforms/pseries/smp.c | 4 +-
arch/powerpc/platforms/pseries/xics.c | 32 +-
arch/powerpc/sysdev/cpm1.c | 2 +-
arch/powerpc/sysdev/cpm2_pic.c | 2 +-
arch/powerpc/sysdev/fsl_msi.c | 2 +-
arch/powerpc/sysdev/i8259.c | 24 +-
arch/powerpc/sysdev/ipic.c | 22 +-
arch/powerpc/sysdev/mpc8xx_pic.c | 2 +-
arch/powerpc/sysdev/mpic.c | 40 +-
arch/powerpc/sysdev/mpic_pasemi_msi.c | 2 +-
arch/powerpc/sysdev/mv64x60_dev.c | 3 +
arch/powerpc/sysdev/ppc4xx_soc.c | 3 +-
arch/powerpc/sysdev/qe_lib/qe_ic.c | 4 +-
arch/powerpc/sysdev/qe_lib/qe_io.c | 8 +-
arch/powerpc/sysdev/uic.c | 2 +-
arch/powerpc/xmon/xmon.c | 2 +-
drivers/block/viodasd.c | 86 +-
drivers/char/hvc_console.c | 6 +-
drivers/char/hvc_console.h | 4 +-
drivers/hwmon/ams/ams-core.c | 11 +-
drivers/hwmon/ams/ams-i2c.c | 2 +
drivers/hwmon/ams/ams-pmu.c | 2 +
drivers/hwmon/ams/ams.h | 1 +
drivers/macintosh/therm_adt746x.c | 36 +-
drivers/ps3/ps3av.c | 2 +-
drivers/rtc/Kconfig | 10 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-mpc5121.c | 387 +++++
drivers/serial/mpc52xx_uart.c | 251 +++-
drivers/video/fsl-diu-fb.c | 5 +
include/linux/lmb.h | 1 +
lib/lmb.c | 13 +-
128 files changed, 4900 insertions(+), 803 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/fsl/mpc5121-psc.txt
create mode 100644 Documentation/powerpc/ptrace.txt
create mode 100644 arch/powerpc/configs/mpc512x_defconfig
create mode 100644 arch/powerpc/include/asm/mpc5121.h
create mode 100644 drivers/rtc/rtc-mpc5121.c
^ permalink raw reply
* Re: PCI NIC for powerpc system
From: Grant Likely @ 2010-02-27 4:30 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <8f766422-4c34-416e-9ae1-95fac2586cdb@SG2EHSMHS006.ehs.local>
On Fri, Feb 26, 2010 at 6:57 PM, John Linn <John.Linn@xilinx.com> wrote:
> Hi,
>
> I should apologize ahead of time for my lack of knowledge with PCI.
>
> I'm trying to better understand if I can run a standard off the shelf
> PCI NIC with a powerpc kernel as the PCI with device tree is not clear
> to me.
yes.
> I don't see many Ethernet drivers having OF support in them so maybe
> devices on the PCI bus are discovered by the kernel such that the
> drivers don't need to be OF aware.
PCI can be probed, so PCI drivers don't need to be OF aware.
g.
^ permalink raw reply
* RE: Gianfar driver failing on MPC8641D based board
From: Kumar Gopalpet-B05799 @ 2010-02-27 5:35 UTC (permalink / raw)
To: avorontsov, Paul Gortmaker
Cc: Martyn Welch, netdev, davem, linux-kernel, linuxppc-dev list
In-Reply-To: <20100226213825.GA32363@oksana.dev.rtsoft.ru>
=20
>-----Original Message-----
>From: Anton Vorontsov [mailto:avorontsov@ru.mvista.com]=20
>Sent: Saturday, February 27, 2010 3:08 AM
>To: Paul Gortmaker
>Cc: Martyn Welch; netdev@vger.kernel.org;=20
>linux-kernel@vger.kernel.org; linuxppc-dev list; Kumar=20
>Gopalpet-B05799; davem@davemloft.net
>Subject: Re: Gianfar driver failing on MPC8641D based board
>
>On Fri, Feb 26, 2010 at 11:27:42AM -0500, Paul Gortmaker wrote:
>> On 10-02-26 11:10 AM, Anton Vorontsov wrote:
>> > On Fri, Feb 26, 2010 at 03:34:07PM +0000, Martyn Welch wrote:
>> > [...]
>> >> Out of 10 boot attempts, 7 failed.
>> >=20
>> > OK, I see why. With ip=3Don (dhcp boot) it's much harder to trigger =
>> > it. With static ip config can I see the same.
>>=20
>> I'd kind of expected to see us stuck in gianfar on that=20
>lock, but the=20
>> SysRQ-T doesn't show us hung up anywhere in gianfar itself.
>> [This was on a base 2.6.33, with just a small sysrq fix patch]
>
>> [df841a30] [c0009fc4] __switch_to+0x8c/0xf8 =20
> =20
>> [df841a50] [c0350160] schedule+0x354/0x92c =20
> =20
>> [df841ae0] [c0331394] rpc_wait_bit_killable+0x2c/0x54 =20
> =20
>> [df841af0] [c0350eb0] __wait_on_bit+0x9c/0x108 =20
> =20
>> [df841b10] [c0350fc0] out_of_line_wait_on_bit+0xa4/0xb4 =20
> =20
>> [df841b40] [c0331cf0] __rpc_execute+0x16c/0x398 =20
> =20
>> [df841b90] [c0329abc] rpc_run_task+0x48/0x9c =20
> =20
>> [df841ba0] [c0329c40] rpc_call_sync+0x54/0x88 =20
> =20
>> [df841bd0] [c015e780] nfs_proc_lookup+0x94/0xe8 =20
> =20
>> [df841c20] [c014eb60] nfs_lookup+0x12c/0x230 =20
> =20
>> [df841d50] [c00b9680] do_lookup+0x118/0x288 =20
> =20
>> [df841d80] [c00bb904] link_path_walk+0x194/0x1118 =20
> =20
>> [df841df0] [c00bcb08] path_walk+0x8c/0x168 =20
> =20
>> [df841e20] [c00bcd6c] do_path_lookup+0x74/0x7c =20
> =20
>> [df841e40] [c00be148] do_filp_open+0x5d4/0xba4 =20
> =20
>> [df841f10] [c00abe94] do_sys_open+0xac/0x190 =20
> =20
>
>Yeah, I don't think this is gianfar-related. It must be=20
>something else triggered by the fact that gianfar no longer=20
>sends stuff.
>
>OK, I think I found what's happening in gianfar.
>
>Some background...
>
>start_xmit() prepares new skb for transmitting, generally it=20
>does three things:
>
>1. sets up all BDs (marks them ready to send), except the first one.
>2. stores skb into tx_queue->tx_skbuff so that clean_tx_ring()
> would cleanup it later.
>3. sets up the first BD, i.e. marks it ready.
>
>Here is what clean_tx_ring() does:
>
>1. reads skbs from tx_queue->tx_skbuff
>2. Checks if the *last* BD is ready. If it's still ready [to send]
> then it it isn't transmitted, so clean_tx_ring() returns.
> Otherwise it actually cleanups BDs. All is OK.
>
>Now, if there is just one BD, code flow:
>
>- start_xmit(): stores skb into tx_skbuff. Note that the first BD
> (which is also the last one) isn't marked as ready, yet.
>- clean_tx_ring(): sees that skb is not null, *and* its lstatus
> says that it is NOT ready (like if BD was sent), so it cleans
> it up (bad!)
>- start_xmit(): marks BD as ready [to send], but it's too late.
>
>We can fix this simply by reordering lstatus/tx_skbuff writes.
>
>It works flawlessly on my p2020, please try it.
Anton,
Understood, and thanks for the explanation. Am I correct in saying that
this is
due to the out-of-order execution capability on powerpc ?
I have one more question, why don't we use use atomic_t for num_txbdfree
and
completely do away with spin_locks in gfar_clean_tx_ring() and
gfar_start_xmit().
In an non-SMP, scenario I would feel there is absolutely no requirement
of spin_locks
and in case of SMP atomic operation would be much more safer on powerpc
rather than spin_locks.
What is your suggestion ?
--
Thanks
Sandeep
>
>Thanks!
>
>
>diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c=20
>index 8bd3c9f..cccb409 100644
>--- a/drivers/net/gianfar.c
>+++ b/drivers/net/gianfar.c
>@@ -2021,7 +2021,6 @@ static int gfar_start_xmit(struct=20
>sk_buff *skb, struct net_device *dev)
> }
>=20
> /* setup the TxBD length and buffer pointer for the first BD */
>- tx_queue->tx_skbuff[tx_queue->skb_curtx] =3D skb;
> txbdp_start->bufPtr =3D dma_map_single(&priv->ofdev->dev,=20
>skb->data,
> skb_headlen(skb), DMA_TO_DEVICE);
>=20
>@@ -2053,6 +2052,10 @@ static int gfar_start_xmit(struct=20
>sk_buff *skb, struct net_device *dev)
>=20
> txbdp_start->lstatus =3D lstatus;
>=20
>+ eieio(); /* force lstatus write before tx_skbuff */
>+
>+ tx_queue->tx_skbuff[tx_queue->skb_curtx] =3D skb;
>+
> /* Update the current skb pointer to the next entry we will use
> * (wrapping if necessary) */
> tx_queue->skb_curtx =3D (tx_queue->skb_curtx + 1) &
>
>
^ permalink raw reply
* Re: [PATCHv4 2/2] powerpc: implement arch_scale_smt_power for Power7
From: Michael Neuling @ 2010-02-27 10:21 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Ingo Molnar, linuxppc-dev, linux-kernel, ego
In-Reply-To: <11927.1267010024@neuling.org>
In message <11927.1267010024@neuling.org> you wrote:
> > > If there's less the group will normally be balanced and we fall out and
> > > end up in check_asym_packing().
> > >
> > > So what I tried doing with that loop is detect if there's a hole in the
> > > packing before busiest. Now that I think about it, what we need to check
> > > is if this_cpu (the removed cpu argument) is idle and less than busiest.
> > >
> > > So something like:
> > >
> > > static int check_asym_pacing(struct sched_domain *sd,
> > > struct sd_lb_stats *sds,
> > > int this_cpu, unsigned long *imbalance)
> > > {
> > > int busiest_cpu;
> > >
> > > if (!(sd->flags & SD_ASYM_PACKING))
> > > return 0;
> > >
> > > if (!sds->busiest)
> > > return 0;
> > >
> > > busiest_cpu = group_first_cpu(sds->busiest);
> > > if (cpu_rq(this_cpu)->nr_running || this_cpu > busiest_cpu)
> > > return 0;
> > >
> > > *imbalance = (sds->max_load * sds->busiest->cpu_power) /
> > > SCHED_LOAD_SCALE;
> > > return 1;
> > > }
> > >
> > > Does that make sense?
> >
> > I think so.
> >
> > I'm seeing check_asym_packing do the right thing with the simple SMT2
> > with 1 process case. It marks cpu0 as imbalanced when cpu0 is idle and
> > cpu1 is busy.
> >
> > Unfortunately the process doesn't seem to be get migrated down though.
> > Do we need to give *imbalance a higher value?
>
> So with ego help, I traced this down a bit more.
>
> In my simple test case (SMT2, t0 idle, t1 active) if f_b_g() hits our
> new case in check_asym_packing(), load_balance then runs f_b_q().
> f_b_q() has this:
>
> if (capacity && rq->nr_running == 1 && wl > imbalance)
> continue;
>
> when check_asym_packing() hits, wl = 1783 and imbalance = 1024, so we
> continue and busiest remains NULL.
>
> load_balance then does "goto out_balanced" and it doesn't attempt to
> move the task.
>
> Based on this and on egos suggestion I pulled in Suresh Siddha patch
> from: http://lkml.org/lkml/2010/2/12/352. This fixes the problem. The
> process is moved down to t0.
>
> I've only tested SMT2 so far.
I'm finding this SMT2 result to be unreliable. Sometimes it doesn't work
for the simple 1 process case. It seems to change boot to boot.
Sometimes it works as expected with t0 busy and t1 idle, but other times
it's the other way around.
When it doesn't work, check_asym_packing() is still marking processes to
be pulled down but only gets run about 1 in every 4 calls to
load_balance().
For 2 of the other calls to load_balance, idle is CPU_NEWLY_IDLE and
hence check_asym_packing() doesn't get called. This results in
sd->nr_balance_failed being reset. When load_balance is next called and
check_asym_packing() hits, need_active_balance() returns 0 as
sd->nr_balance_failed is too small. This means the migration thread on
t1 is not woken and the process remains there.
So why does thread0 change from NEWLY_IDLE to IDLE and visa versa, when
there is nothing running on it? Is this expected?
This is with next-20100225 which pulled in Ingos tip at
407b4844f2af416cd8c9edd7c44d1545c93a4938 (from 24/2/2010)
Mikey
^ permalink raw reply
* Re: [net-next-2.6 PATCH v3 0/3] Support for MPC512x FEC
From: David Miller @ 2010-02-27 10:34 UTC (permalink / raw)
To: agust; +Cc: wd, dzu, netdev, linuxppc-dev
In-Reply-To: <1267221649-22754-1-git-send-email-agust@denx.de>
From: Anatolij Gustschin <agust@denx.de>
Date: Fri, 26 Feb 2010 23:00:46 +0100
> These patches attempt to provide support for the Freescale MPC512x
> FEC in the fs_enet driver. The first cleanup patch replaces printk
> by dev_xxx. The second and third attemt to support MPC5121 FEC
> in the FEC driver.
Applied, for real this time! :-)
Thanks.
^ permalink raw reply
* Re: [PATCH 1/4] 8xx: Optimze TLB Miss handlers
From: Joakim Tjernlund @ 2010-02-27 15:23 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20100226195018.GA26867@loki.buserror.net>
Scott Wood <scottwood@freescale.com> wrote on 2010/02/26 20:50:18:
>
> On Fri, Feb 26, 2010 at 09:29:40AM +0100, Joakim Tjernlund wrote:
> > This removes a couple of insn's from the TLB Miss
> > handlers whithout changing functionality.
> > ---
>
> Did a quick test of the patchset, seems to work OK (without CONFIG_SWAP or
> CONFIG_MODULES). Didn't try with CONFIG_8xx_CPU6.
Cool, thanks a lot!
Not sure anyone is using 2.6 with CPU6 errata. Seems it was fixed years ago.
Should I resend the whole series with SOB line or just include it here?
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
^ permalink raw reply
* Re: [PATCH 1/4] 8xx: Optimze TLB Miss handlers
From: Joakim Tjernlund @ 2010-02-27 15:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <C13A88EA-3A60-41BB-BB26-C1DC9CF37422@kernel.crashing.org>
Kumar Gala <galak@kernel.crashing.org> wrote on 2010/02/26 21:10:31:
>
>
> On Feb 26, 2010, at 2:29 AM, Joakim Tjernlund wrote:
>
> > li r11, 0x00f0
> > - rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
> > + rlwimi r10, r11, 0, 0x07f8 /* Set 24-27, clear 21-23,28 */
> > DO_8xx_CPU6(0x2d80, r3)
> > mtspr SPRN_MI_RPN, r10 /* Update TLB entry */
>
> Cool, didn't know 'as' supported this notation.
Yeah, it was Scott who gave me the clue and from what I can tell it
is an official syntax form. I find much easier to understand.
Jocke
^ permalink raw reply
* [PATCH 44/66] arch/powerpc/sysdev/cpm2_pic.h: Checkpatch cleanup
From: Andrea Gelmini @ 2010-02-27 16:51 UTC (permalink / raw)
To: linux-kernel; +Cc: Andrea Gelmini, Paul Mackerras, linuxppc-dev
In-Reply-To: <1267289508-31031-1-git-send-email-andrea.gelmini@gelma.net>
arch/powerpc/sysdev/cpm2_pic.h:6: ERROR: "(foo*)" should be "(foo *)"
Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>
---
arch/powerpc/sysdev/cpm2_pic.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/cpm2_pic.h b/arch/powerpc/sysdev/cpm2_pic.h
index 30e5828..2c5f70c 100644
--- a/arch/powerpc/sysdev/cpm2_pic.h
+++ b/arch/powerpc/sysdev/cpm2_pic.h
@@ -3,6 +3,6 @@
extern unsigned int cpm2_get_irq(void);
-extern void cpm2_pic_init(struct device_node*);
+extern void cpm2_pic_init(struct device_node *);
#endif /* _PPC_KERNEL_CPM2_H */
--
1.7.0.90.g251a4
^ permalink raw reply related
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