* Re: [PATCH] move drivers/macintosh variables to BSS
From: Paul Mackerras @ 2006-09-30 0:41 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060926201554.GA886@aepfle.de>
Olaf Hering writes:
> --- linux-2.6.18.orig/drivers/macintosh/ans-lcd.c
> +++ linux-2.6.18/drivers/macintosh/ans-lcd.c
> @@ -21,8 +21,8 @@
> #define ANSLCD_CTRL_IX 0x00
> #define ANSLCD_DATA_IX 0x10
>
> -static unsigned long anslcd_short_delay = 80;
> -static unsigned long anslcd_long_delay = 3280;
> +static unsigned long anslcd_short_delay;
> +static unsigned long anslcd_long_delay;
> static volatile unsigned char __iomem *anslcd_ptr;
>
> #undef DEBUG
> @@ -164,6 +164,8 @@ anslcd_init(void)
> printk(KERN_DEBUG "LCD: init\n");
> #endif
>
> + anslcd_short_delay = 80;
> + anslcd_long_delay = 3280;
What's the point of this? I can understand removing redundant "= 0"
initializers, but why fatten the code by 3 instructions just to remove
1 word from the data section?
Paul.
^ permalink raw reply
* [PATCH 6/6]: powerpc/cell spidernet refine locking
From: Linas Vepstas @ 2006-09-29 23:29 UTC (permalink / raw)
To: jeff, akpm
Cc: netdev, James K Lewis, linux-kernel, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20060929230552.GG6433@austin.ibm.com>
The transmit side of the spider ethernet driver currently
places locks around some very large chunks of code. This
results in a fair amount of lock contention is some cases.
This patch makes the locks much more fine-grained, protecting
only the cirtical sections. One lock is used to protect
three locations: the queue head and tail pointers, and the
queue low-watermark location.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: James K Lewis <jklewis@us.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
----
drivers/net/spider_net.c | 77 ++++++++++++++++++++---------------------------
1 file changed, 34 insertions(+), 43 deletions(-)
Index: linux-2.6.18-mm2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.c 2006-09-29 17:39:06.000000000 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.c 2006-09-29 17:41:19.000000000 -0500
@@ -646,8 +646,9 @@ static int
spider_net_prepare_tx_descr(struct spider_net_card *card,
struct sk_buff *skb)
{
- struct spider_net_descr *descr = card->tx_chain.head;
+ struct spider_net_descr *descr;
dma_addr_t buf;
+ unsigned long flags;
buf = pci_map_single(card->pdev, skb->data, skb->len, PCI_DMA_TODEVICE);
if (pci_dma_mapping_error(buf)) {
@@ -658,6 +659,10 @@ spider_net_prepare_tx_descr(struct spide
return -ENOMEM;
}
+ spin_lock_irqsave(&card->tx_chain.lock, flags);
+ descr = card->tx_chain.head;
+ card->tx_chain.head = card->tx_chain.head->next;
+
descr->buf_addr = buf;
descr->buf_size = skb->len;
descr->next_descr_addr = 0;
@@ -666,6 +671,8 @@ spider_net_prepare_tx_descr(struct spide
descr->dmac_cmd_status =
SPIDER_NET_DESCR_CARDOWNED | SPIDER_NET_DMAC_NOCS;
+ spin_unlock_irqrestore(&card->tx_chain.lock, flags);
+
if (skb->protocol == htons(ETH_P_IP))
switch (skb->nh.iph->protocol) {
case IPPROTO_TCP:
@@ -676,37 +683,16 @@ spider_net_prepare_tx_descr(struct spide
break;
}
+ /* Chain the bus address, so that the DMA engine finds this descr. */
descr->prev->next_descr_addr = descr->bus_addr;
return 0;
}
-/**
- * spider_net_release_tx_descr - processes a used tx descriptor
- * @card: card structure
- * @descr: descriptor to release
- *
- * releases a used tx descriptor (unmapping, freeing of skb)
- */
-static inline void
-spider_net_release_tx_descr(struct spider_net_card *card)
-{
- struct spider_net_descr *descr = card->tx_chain.tail;
- struct sk_buff *skb;
-
- card->tx_chain.tail = card->tx_chain.tail->next;
- descr->dmac_cmd_status |= SPIDER_NET_DESCR_NOT_IN_USE;
-
- /* unmap the skb */
- skb = descr->skb;
- pci_unmap_single(card->pdev, descr->buf_addr, skb->len,
- PCI_DMA_TODEVICE);
- dev_kfree_skb_any(skb);
-}
-
static void
spider_net_set_low_watermark(struct spider_net_card *card)
{
+ unsigned long flags;
int status;
int cnt=0;
int i;
@@ -730,11 +716,13 @@ spider_net_set_low_watermark(struct spid
descr = descr->next;
/* Set the new watermark, clear the old wtermark */
+ spin_lock_irqsave(&card->tx_chain.lock, flags);
descr->dmac_cmd_status |= SPIDER_NET_DESCR_TXDESFLG;
if (card->low_watermark && card->low_watermark != descr)
card->low_watermark->dmac_cmd_status =
card->low_watermark->dmac_cmd_status & ~SPIDER_NET_DESCR_TXDESFLG;
card->low_watermark = descr;
+ spin_unlock_irqrestore(&card->tx_chain.lock, flags);
}
/**
@@ -753,22 +741,30 @@ static int
spider_net_release_tx_chain(struct spider_net_card *card, int brutal)
{
struct spider_net_descr_chain *chain = &card->tx_chain;
+ struct spider_net_descr *descr;
+ struct sk_buff *skb;
+ u32 buf_addr;
+ unsigned long flags;
int status;
int rc=0;
spider_net_read_reg(card, SPIDER_NET_GDTDMACCNTR);
while (chain->tail != chain->head) {
- status = spider_net_get_descr_status(chain->tail);
+ spin_lock_irqsave(&chain->lock, flags);
+ descr = chain->tail;
+
+ status = spider_net_get_descr_status(descr);
switch (status) {
case SPIDER_NET_DESCR_COMPLETE:
card->netdev_stats.tx_packets++;
- card->netdev_stats.tx_bytes += chain->tail->skb->len;
+ card->netdev_stats.tx_bytes += descr->skb->len;
break;
case SPIDER_NET_DESCR_CARDOWNED:
if (!brutal) {
rc = 1;
+ spin_unlock_irqrestore(&chain->lock, flags);
goto done;
}
/* fallthrough, if we release the descriptors
@@ -788,9 +784,19 @@ spider_net_release_tx_chain(struct spide
default:
card->netdev_stats.tx_dropped++;
rc = 1;
+ spin_unlock_irqrestore(&chain->lock, flags);
goto done;
}
- spider_net_release_tx_descr(card);
+
+ chain->tail = chain->tail->next;
+ descr->dmac_cmd_status |= SPIDER_NET_DESCR_NOT_IN_USE;
+ skb = descr->skb;
+ buf_addr = descr->buf_addr;
+ spin_unlock_irqrestore(&chain->lock, flags);
+
+ /* unmap the skb */
+ pci_unmap_single(card->pdev, buf_addr, skb->len, PCI_DMA_TODEVICE);
+ dev_kfree_skb_any(skb);
}
done:
if (rc == 1)
@@ -847,11 +853,8 @@ spider_net_xmit(struct sk_buff *skb, str
struct spider_net_card *card = netdev_priv(netdev);
struct spider_net_descr_chain *chain = &card->tx_chain;
struct spider_net_descr *descr = chain->head;
- unsigned long flags;
int result;
- spin_lock_irqsave(&chain->lock, flags);
-
spider_net_release_tx_chain(card, 0);
if (chain->head->next == chain->tail->prev) {
@@ -873,12 +876,9 @@ spider_net_xmit(struct sk_buff *skb, str
}
result = NETDEV_TX_OK;
-
spider_net_kick_tx_dma(card);
- card->tx_chain.head = card->tx_chain.head->next;
out:
- spin_unlock_irqrestore(&chain->lock, flags);
netif_wake_queue(netdev);
return result;
}
@@ -895,15 +895,9 @@ out:
static void
spider_net_cleanup_tx_ring(struct spider_net_card *card)
{
- unsigned long flags;
-
- spin_lock_irqsave(&card->tx_chain.lock, flags);
-
if ((spider_net_release_tx_chain(card, 0) != 0) &&
(card->netdev->flags & IFF_UP))
spider_net_kick_tx_dma(card);
-
- spin_unlock_irqrestore(&card->tx_chain.lock, flags);
}
/**
@@ -1930,10 +1924,7 @@ spider_net_stop(struct net_device *netde
spider_net_disable_rxdmac(card);
/* release chains */
- if (spin_trylock(&card->tx_chain.lock)) {
- spider_net_release_tx_chain(card, 1);
- spin_unlock(&card->tx_chain.lock);
- }
+ spider_net_release_tx_chain(card, 1);
spider_net_free_chain(card, &card->tx_chain);
spider_net_free_chain(card, &card->rx_chain);
^ permalink raw reply
* [PATCH 5/6]: powerpc/cell spidernet ethtool -i version number
From: Linas Vepstas @ 2006-09-29 23:26 UTC (permalink / raw)
To: jeff, akpm
Cc: netdev, James K Lewis, linux-kernel, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20060929230552.GG6433@austin.ibm.com>
Jim, as the official maintainer, you should explicitly ack this patch.
--linas
This patch moves transmit queue cleanup code out of the
interrupt context, and into the NAPI polling routine.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: James K Lewis <jklewis@us.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
----
drivers/net/spider_net.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
Index: linux-2.6.18-mm2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.c 2006-09-29 17:01:39.000000000 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.c 2006-09-29 17:39:06.000000000 -0500
@@ -887,9 +887,10 @@ out:
* spider_net_cleanup_tx_ring - cleans up the TX ring
* @card: card structure
*
- * spider_net_cleanup_tx_ring is called by the tx_timer (as we don't use
- * interrupts to cleanup our TX ring) and returns sent packets to the stack
- * by freeing them
+ * spider_net_cleanup_tx_ring is called by either the tx_timer
+ * or from the NAPI polling routine.
+ * This routine releases resources associted with transmitted
+ * packets, including updating the queue tail pointer.
*/
static void
spider_net_cleanup_tx_ring(struct spider_net_card *card)
@@ -1093,6 +1094,7 @@ spider_net_poll(struct net_device *netde
int packets_to_do, packets_done = 0;
int no_more_packets = 0;
+ spider_net_cleanup_tx_ring(card);
packets_to_do = min(*budget, netdev->quota);
while (packets_to_do) {
@@ -1505,10 +1507,8 @@ spider_net_interrupt(int irq, void *ptr,
spider_net_rx_irq_off(card);
netif_rx_schedule(netdev);
}
- if (status_reg & SPIDER_NET_TXINT ) {
- spider_net_cleanup_tx_ring(card);
- netif_wake_queue(netdev);
- }
+ if (status_reg & SPIDER_NET_TXINT)
+ netif_rx_schedule(netdev);
if (status_reg & SPIDER_NET_ERRINT )
spider_net_handle_error_irq(card, status_reg);
^ permalink raw reply
* Re: [PATCH 2/2] enable generic rtc hook for the MPC8349 mITX
From: Tom Rini @ 2006-09-29 23:25 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20060927234304.0cf4d22d.kim.phillips@freescale.com>
On Wed, Sep 27, 2006 at 11:43:04PM -0500, Kim Phillips wrote:
> On Wed, 27 Sep 2006 08:58:53 -0700
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > On Tue, Sep 26, 2006 at 11:34:43PM -0500, Kumar Gala wrote:
> > > On Sep 26, 2006, at 5:46 PM, Kim Phillips wrote:
> > [snip]
> > > > diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/
> > > > powerpc/platforms/83xx/mpc834x_itx.c
> > > > index 969fbb6..8c676d7 100644
> > > > --- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > > > +++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > > > @@ -109,6 +109,10 @@ static int __init mpc834x_itx_probe(void
> > > > return 1;
> > > > }
> > > >
> > > > +#ifdef CONFIG_RTC_CLASS
> > > > +late_initcall(rtc_class_hookup);
> > > > +#endif
> > >
> > > Any reason we can't just do this in setup_arch?
> >
> > I think because of rtc-over-i2c and similar where we need the whole rest
> > of the system 'up' before we can try and use the RTC (which might not be
> > the case for this specific board, but for consistency it looks like a
> > good thing to always do it like this).
> >
> this is indeed the case, as with the static assignment of the ppc_md rtc_time functions in define_machine. In the early assignment case, the kernel oopses early in rtc_class_open().
>
> During testing I noticed hwclock get/set operations worked even without hooking up with the ppc_md rtc_time functions. Turns out this rtc_class provides access to the RTC to the whole kernel and userspace:
>
> http://lkml.org/lkml/2005/12/20/220
>
> so, both of these patches are really unnecessary, unless there's a genuine consumer in arch/powerpc that I can't find (I'm assuming get_boot_time() isn't one of them since it gets called way too early in the rtc-over-i2c based platform case).
>
> So we should just configure RTC_CLASS and the specific chip and we're done. :)
Does this mean we can then rip out some existing code, so long as
there's associated cleanup / rtc class support additions?
--
Tom Rini
^ permalink raw reply
* [PATCH 4/6]: powerpc/cell spidernet ethtool -i version number info.
From: Linas Vepstas @ 2006-09-29 23:21 UTC (permalink / raw)
To: jeff, akpm
Cc: netdev, James K Lewis, linux-kernel, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20060929230552.GG6433@austin.ibm.com>
This patch adds version information as reported by
ethtool -i to the Spidernet driver.
From: James K Lewis <jklewis@us.ibm.com>
Signed-off-by: James K Lewis <jklewis@us.ibm.com>
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
----
drivers/net/spider_net.c | 3 +++
drivers/net/spider_net.h | 2 ++
drivers/net/spider_net_ethtool.c | 2 +-
3 files changed, 6 insertions(+), 1 deletion(-)
Index: linux-2.6.18-mm2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.c 2006-09-29 15:05:05.000000000 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.c 2006-09-29 16:33:39.000000000 -0500
@@ -55,6 +55,7 @@ MODULE_AUTHOR("Utz Bacher <utz.bacher@de
"<Jens.Osterkamp@de.ibm.com>");
MODULE_DESCRIPTION("Spider Southbridge Gigabit Ethernet driver");
MODULE_LICENSE("GPL");
+MODULE_VERSION(VERSION);
static int rx_descriptors = SPIDER_NET_RX_DESCRIPTORS_DEFAULT;
static int tx_descriptors = SPIDER_NET_TX_DESCRIPTORS_DEFAULT;
@@ -2303,6 +2304,8 @@ static struct pci_driver spider_net_driv
*/
static int __init spider_net_init(void)
{
+ printk("spidernet Version %s.\n",VERSION);
+
if (rx_descriptors < SPIDER_NET_RX_DESCRIPTORS_MIN) {
rx_descriptors = SPIDER_NET_RX_DESCRIPTORS_MIN;
pr_info("adjusting rx descriptors to %i.\n", rx_descriptors);
Index: linux-2.6.18-mm2/drivers/net/spider_net.h
===================================================================
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.h 2006-09-29 15:01:55.000000000 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.h 2006-09-29 15:18:12.000000000 -0500
@@ -24,6 +24,8 @@
#ifndef _SPIDER_NET_H
#define _SPIDER_NET_H
+#define VERSION "1.1 A"
+
#include "sungem_phy.h"
extern int spider_net_stop(struct net_device *netdev);
Index: linux-2.6.18-mm2/drivers/net/spider_net_ethtool.c
===================================================================
--- linux-2.6.18-mm2.orig/drivers/net/spider_net_ethtool.c 2006-09-29 14:11:18.000000000 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net_ethtool.c 2006-09-29 15:18:12.000000000 -0500
@@ -76,7 +76,7 @@ spider_net_ethtool_get_drvinfo(struct ne
/* clear and fill out info */
memset(drvinfo, 0, sizeof(struct ethtool_drvinfo));
strncpy(drvinfo->driver, spider_net_driver_name, 32);
- strncpy(drvinfo->version, "0.1", 32);
+ strncpy(drvinfo->version, VERSION, 32);
strcpy(drvinfo->fw_version, "no information");
strncpy(drvinfo->bus_info, pci_name(card->pdev), 32);
}
^ permalink raw reply
* [PATCH 3/6]: powerpc/cell spidernet stop error printing patch.
From: Linas Vepstas @ 2006-09-29 23:19 UTC (permalink / raw)
To: jeff, akpm
Cc: netdev, James K Lewis, linux-kernel, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20060929230552.GG6433@austin.ibm.com>
Turn off mis-interpretation of the queue-empty interrupt
status bit as an error. This bit is set as a part of
the previous low-watermark patch.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: James K Lewis <jklewis@us.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
----
drivers/net/spider_net.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
Index: linux-2.6.18-mm2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.c 2006-09-29 15:01:55.000000000 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.c 2006-09-29 16:33:43.000000000 -0500
@@ -1282,12 +1282,15 @@ spider_net_handle_error_irq(struct spide
case SPIDER_NET_PHYINT:
case SPIDER_NET_GMAC2INT:
case SPIDER_NET_GMAC1INT:
- case SPIDER_NET_GIPSINT:
case SPIDER_NET_GFIFOINT:
case SPIDER_NET_DMACINT:
case SPIDER_NET_GSYSINT:
break; */
+ case SPIDER_NET_GIPSINT:
+ show_error = 0;
+ break;
+
case SPIDER_NET_GPWOPCMPINT:
/* PHY write operation completed */
show_error = 0;
@@ -1346,9 +1349,10 @@ spider_net_handle_error_irq(struct spide
case SPIDER_NET_GDTDCEINT:
/* chain end. If a descriptor should be sent, kick off
* tx dma
- if (card->tx_chain.tail == card->tx_chain.head)
+ if (card->tx_chain.tail != card->tx_chain.head)
spider_net_kick_tx_dma(card);
- show_error = 0; */
+ */
+ show_error = 0;
break;
/* case SPIDER_NET_G1TMCNTINT: not used. print a message */
@@ -1462,8 +1466,9 @@ spider_net_handle_error_irq(struct spide
}
if ((show_error) && (netif_msg_intr(card)))
- pr_err("Got error interrupt, GHIINT0STS = 0x%08x, "
+ pr_err("Got error interrupt on %s, GHIINT0STS = 0x%08x, "
"GHIINT1STS = 0x%08x, GHIINT2STS = 0x%08x\n",
+ card->netdev->name,
status_reg, error_reg1, error_reg2);
/* clear interrupt sources */
^ permalink raw reply
* [PATCH 2/6]: powerpc/cell spidernet low watermark patch.
From: Linas Vepstas @ 2006-09-29 23:17 UTC (permalink / raw)
To: jeff, akpm
Cc: netdev, James K Lewis, linux-kernel, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20060929230552.GG6433@austin.ibm.com>
Implement basic low-watermark support for the transmit queue.
Hardware low-watermarks allow a properly configured kernel
to continously stream data to a device and not have to handle
any interrupts at all in doing so. Correct zero-interrupt
operation can be actually observed for this driver, when the
socket buffer is made large enough.
The basic idea of a low-watermark interrupt is as follows.
The device driver queues up a bunch of packets for the hardware
to transmit, and then kicks the hardware to get it started.
As the hardware drains the queue of pending, untransmitted
packets, the device driver will want to know when the queue
is almost empty, so that it can queue some more packets.
If the queue drains down to the low waterark, then an interrupt
will be generated. However, if the kernel/driver continues
to add enough packets to keep the queue partially filled,
no interrupt will actually be generated, and the hardware
can continue streaming packets indefinitely in this mode.
The impelmentation is done by setting the DESCR_TXDESFLG flag
in one of the packets. When the hardware sees this flag, it will
interrupt the device driver. Because this flag is on a fixed
packet, rather than at fixed location in the queue, the
code below needs to move the flag as more packets are
queued up. This implementation attempts to keep the flag
at about 1/4 from "empty".
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: James K Lewis <jklewis@us.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
----
drivers/net/spider_net.c | 56 ++++++++++++++++++++++++++++++++++++++++++-----
drivers/net/spider_net.h | 6 +++--
2 files changed, 55 insertions(+), 7 deletions(-)
Index: linux-2.6.18-mm2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.c 2006-09-29 14:11:20.000000000 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.c 2006-09-29 16:33:46.000000000 -0500
@@ -703,6 +703,39 @@ spider_net_release_tx_descr(struct spide
dev_kfree_skb_any(skb);
}
+static void
+spider_net_set_low_watermark(struct spider_net_card *card)
+{
+ int status;
+ int cnt=0;
+ int i;
+ struct spider_net_descr *descr = card->tx_chain.tail;
+
+ /* Measure the length of the queue. */
+ while (descr != card->tx_chain.head) {
+ status = descr->dmac_cmd_status & SPIDER_NET_DESCR_NOT_IN_USE;
+ if (status == SPIDER_NET_DESCR_NOT_IN_USE)
+ break;
+ descr = descr->next;
+ cnt++;
+ }
+ if (cnt == 0)
+ return;
+
+ /* Set low-watermark 3/4th's of the way into the queue. */
+ descr = card->tx_chain.tail;
+ cnt = (cnt*3)/4;
+ for (i=0;i<cnt; i++)
+ descr = descr->next;
+
+ /* Set the new watermark, clear the old wtermark */
+ descr->dmac_cmd_status |= SPIDER_NET_DESCR_TXDESFLG;
+ if (card->low_watermark && card->low_watermark != descr)
+ card->low_watermark->dmac_cmd_status =
+ card->low_watermark->dmac_cmd_status & ~SPIDER_NET_DESCR_TXDESFLG;
+ card->low_watermark = descr;
+}
+
/**
* spider_net_release_tx_chain - processes sent tx descriptors
* @card: adapter structure
@@ -720,6 +753,7 @@ spider_net_release_tx_chain(struct spide
{
struct spider_net_descr_chain *chain = &card->tx_chain;
int status;
+ int rc=0;
spider_net_read_reg(card, SPIDER_NET_GDTDMACCNTR);
@@ -732,8 +766,10 @@ spider_net_release_tx_chain(struct spide
break;
case SPIDER_NET_DESCR_CARDOWNED:
- if (!brutal)
- return 1;
+ if (!brutal) {
+ rc = 1;
+ goto done;
+ }
/* fallthrough, if we release the descriptors
* brutally (then we don't care about
* SPIDER_NET_DESCR_CARDOWNED) */
@@ -750,12 +786,15 @@ spider_net_release_tx_chain(struct spide
default:
card->netdev_stats.tx_dropped++;
- return 1;
+ rc = 1;
+ goto done;
}
spider_net_release_tx_descr(card);
}
-
- return 0;
+done:
+ if (rc == 1)
+ spider_net_set_low_watermark(card);
+ return rc;
}
/**
@@ -1460,6 +1499,10 @@ spider_net_interrupt(int irq, void *ptr,
spider_net_rx_irq_off(card);
netif_rx_schedule(netdev);
}
+ if (status_reg & SPIDER_NET_TXINT ) {
+ spider_net_cleanup_tx_ring(card);
+ netif_wake_queue(netdev);
+ }
if (status_reg & SPIDER_NET_ERRINT )
spider_net_handle_error_irq(card, status_reg);
@@ -1621,6 +1664,9 @@ spider_net_open(struct net_device *netde
if (spider_net_init_chain(card, &card->tx_chain, card->descr,
PCI_DMA_TODEVICE, card->tx_desc))
goto alloc_tx_failed;
+
+ card->low_watermark = NULL;
+
if (spider_net_init_chain(card, &card->rx_chain,
card->descr + card->rx_desc,
PCI_DMA_FROMDEVICE, card->rx_desc))
Index: linux-2.6.18-mm2/drivers/net/spider_net.h
===================================================================
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.h 2006-09-29 14:47:50.000000000 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.h 2006-09-29 16:33:43.000000000 -0500
@@ -47,7 +47,7 @@ extern char spider_net_driver_name[];
#define SPIDER_NET_TX_DESCRIPTORS_MIN 16
#define SPIDER_NET_TX_DESCRIPTORS_MAX 512
-#define SPIDER_NET_TX_TIMER 20
+#define SPIDER_NET_TX_TIMER (HZ/5)
#define SPIDER_NET_RX_CSUM_DEFAULT 1
@@ -209,7 +209,7 @@ extern char spider_net_driver_name[];
#define SPIDER_NET_DMA_RX_FEND_VALUE 0x00030003
/* to set TX_DMA_EN */
#define SPIDER_NET_TX_DMA_EN 0x80000000
-#define SPIDER_NET_GDTDCEIDIS 0x00000302
+#define SPIDER_NET_GDTDCEIDIS 0x00000300
#define SPIDER_NET_DMA_TX_VALUE SPIDER_NET_TX_DMA_EN | \
SPIDER_NET_GDTDCEIDIS
#define SPIDER_NET_DMA_TX_FEND_VALUE 0x00030003
@@ -349,6 +349,7 @@ enum spider_net_int2_status {
#define SPIDER_NET_DESCR_FORCE_END 0x50000000 /* used in rx and tx */
#define SPIDER_NET_DESCR_CARDOWNED 0xA0000000 /* used in rx and tx */
#define SPIDER_NET_DESCR_NOT_IN_USE 0xF0000000
+#define SPIDER_NET_DESCR_TXDESFLG 0x00800000
struct spider_net_descr {
/* as defined by the hardware */
@@ -433,6 +434,7 @@ struct spider_net_card {
struct spider_net_descr_chain tx_chain;
struct spider_net_descr_chain rx_chain;
+ struct spider_net_descr *low_watermark;
struct net_device_stats netdev_stats;
^ permalink raw reply
* [PATCH 1/6]: powerpc/cell spidernet burst alignment patch.
From: Linas Vepstas @ 2006-09-29 23:15 UTC (permalink / raw)
To: jeff, akpm
Cc: netdev, James K Lewis, linux-kernel, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20060929230552.GG6433@austin.ibm.com>
This patch increases the Burst Address alignment from 64 to 1024 in the
Spidernet driver. This improves transmit performance for large packets.
From: James K Lewis <jklewis@us.ibm.com>
Signed-off-by: James K Lewis <jklewis@us.ibm.com>
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
----
drivers/net/spider_net.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.18-mm2/drivers/net/spider_net.h
===================================================================
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.h 2006-09-29 14:11:21.000000000 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.h 2006-09-29 16:33:49.000000000 -0500
@@ -209,7 +209,7 @@ extern char spider_net_driver_name[];
#define SPIDER_NET_DMA_RX_FEND_VALUE 0x00030003
/* to set TX_DMA_EN */
#define SPIDER_NET_TX_DMA_EN 0x80000000
-#define SPIDER_NET_GDTDCEIDIS 0x00000002
+#define SPIDER_NET_GDTDCEIDIS 0x00000302
#define SPIDER_NET_DMA_TX_VALUE SPIDER_NET_TX_DMA_EN | \
SPIDER_NET_GDTDCEIDIS
#define SPIDER_NET_DMA_TX_FEND_VALUE 0x00030003
^ permalink raw reply
* [PATCH 0/6]: powerpc/cell spidernet ethernet patches
From: Linas Vepstas @ 2006-09-29 23:05 UTC (permalink / raw)
To: jeff, akpm
Cc: netdev, James K Lewis, linux-kernel, Arnd Bergmann, linuxppc-dev
Please apply and forward upstream as appropriate.
Although these patches have not been baking in
any -mm tree, they have been tested and are
generally available as a part of the Cell SDK 2.0
overseen by Arnd Bergmann. (Arnd, if you want
to lend a voice of authority here, or to correct
me, please do so...)
The following sequence of six patches implement a
series of changes to the transmit side of the
spidernet ethernet device driver, significantly
improving performance for large packets.
This series of patches is almost identical to
those previously mailed on 18-20 August, with one
critical change: NAPI polling is used instead of
homegrown polling.
Although these patches improve things, I am not
satisfied with how this driver behaves, and so
plan to do additional work next week.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: James K Lewis <jklewis@us.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
--linas
^ permalink raw reply
* RE: Need help on PPC8343E bringup
From: Mathews, Phil @ 2006-09-29 22:43 UTC (permalink / raw)
To: Michael Galassi, Reeve Yang; +Cc: linuxppc-embedded
In-Reply-To: <200609292214.k8TMEZfw006857@penguin.ncube.com>
[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]
From: linuxppc-embedded-bounces+phil.mathews=innocon.com@ozlabs.org on behalf of Michael Galassi
Sent: Fri 9/29/2006 6:14 PM
To: Reeve Yang
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Need help on PPC8343E bringup
>Thanks Machael.
>
>On my flash data sheet, there are some command about security:
>
>Lock Block | Block Address | 0060h | Block Address | 0001h
>Unlock Block|Block Address| 0060h | Block Address | 00d0h
>
>So I guess it needs two write cycle to perfomr the command, and the unlock
>command should be 006000d0. I tried that but still get the same error. Bad!
>:(
>
>Another questions is that is there any way to change CPU register directy?
>For 8343E all registers are mapped to 1m starting from 0xff400000. I want to
>change on 0Xff400c08, but visionclick reject me to write on that address.
>
>- Reeve
Actually no, I made the assumption that you have two 16 bit wide flash
parts, one providing bits 0:15, the other 16:31. Most PPC projects end
up doing this. The write 0x00600060 ends up sending a 0x60 to the flash
on the low bits and another 0x60 to the flash part on the high bits.
The second write of 0x00d000d0 likewise sends a single 0xd0 to each
flash part.
If your tool gave you a command called mw which had a usage somewhat
like:
mw <size> <address> <data>
where size is b/byte, w/word, l/longword you might you might try:
mw l 0x00600060 0xff000000
mw l 0x00d000d0 0xff000000
Does that make sense to you?
PS: some people here have nothing better to do than whine about
top-posting, safe yourself the grief and respond bellow the
post.
PS: Technicaly this is not a Linux topic, I'm responding here
because this does turn out to be of general interest.
-michael
Actually the comands should be:
mw l 0xff000000 0x00600060
mw l 0xff000000 0x00d000d0
BTW - you don't have to bellow the post, you can just type them quietly :-)
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 2988 bytes --]
^ permalink raw reply
* Re: Need help on PPC8343E bringup
From: Michael Galassi @ 2006-09-29 22:14 UTC (permalink / raw)
To: Reeve Yang; +Cc: linuxppc-embedded
In-Reply-To: <198592450609291503s7be0200ehf72925c2cae07787@mail.gmail.com>
>Thanks Machael.
>
>On my flash data sheet, there are some command about security:
>
>Lock Block | Block Address | 0060h | Block Address | 0001h
>Unlock Block|Block Address| 0060h | Block Address | 00d0h
>
>So I guess it needs two write cycle to perfomr the command, and the unlock
>command should be 006000d0. I tried that but still get the same error. Bad!
>:(
>
>Another questions is that is there any way to change CPU register directy?
>For 8343E all registers are mapped to 1m starting from 0xff400000. I want to
>change on 0Xff400c08, but visionclick reject me to write on that address.
>
>- Reeve
Actually no, I made the assumption that you have two 16 bit wide flash
parts, one providing bits 0:15, the other 16:31. Most PPC projects end
up doing this. The write 0x00600060 ends up sending a 0x60 to the flash
on the low bits and another 0x60 to the flash part on the high bits.
The second write of 0x00d000d0 likewise sends a single 0xd0 to each
flash part.
If your tool gave you a command called mw which had a usage somewhat
like:
mw <size> <address> <data>
where size is b/byte, w/word, l/longword you might you might try:
mw l 0x00600060 0xff000000
mw l 0x00d000d0 0xff000000
Does that make sense to you?
PS: some people here have nothing better to do than whine about
top-posting, safe yourself the grief and respond bellow the
post.
PS: Technicaly this is not a Linux topic, I'm responding here
because this does turn out to be of general interest.
-michael
^ permalink raw reply
* Re: Need help on PPC8343E bringup
From: Reeve Yang @ 2006-09-29 22:03 UTC (permalink / raw)
To: Michael Galassi; +Cc: linuxppc-embedded
In-Reply-To: <200609292139.k8TLdV10081103@penguin.ncube.com>
[-- Attachment #1: Type: text/plain, Size: 2273 bytes --]
Thanks Machael.
On my flash data sheet, there are some command about security:
Lock Block | Block Address | 0060h | Block Address | 0001h
Unlock Block|Block Address| 0060h | Block Address | 00d0h
So I guess it needs two write cycle to perfomr the command, and the unlock
command should be 006000d0. I tried that but still get the same error. Bad!
:(
Another questions is that is there any way to change CPU register directy?
For 8343E all registers are mapped to 1m starting from 0xff400000. I want to
change on 0Xff400c08, but visionclick reject me to write on that address.
- Reeve
On 9/29/06, Michael Galassi <mgalassi@c-cor.com> wrote:
>
>
> >>Hello linux-ppc experts,
> >>
> >>I'm trying to use using wind river jtag probe to download uboot to our
> >>switching box which is with PPC8343E/Intel 28F128J3D memory flash(16M).
> >>Memory mapping is starting from 0xFF000000 to 0xFFFFFFFF which is 16M.
> The
> >>JTAG software I'm using is visionclick8.
> >>
> >>The problem now is that I even couldn't erash flash, with following
> error
> >>message:
> >>
> >>TF ERASE FFF00000..FFFFFFFF INTEL 28F128Jx ( 8192 x 16 ) 1 Device
> >>Erasing Flash(s) ... Failed
> >>!ERROR! - [msg100000] Failed while erasing the device(s)
> >>>BKM>
> >>!HALT! - [msg90009] Target Stopped : CheckStop taken; PC = 0x00007404
> [EVENT
> >>Taken]
> >>>BKM>
> >>
> >>Does anyone has experiece to bring up this CPU, and could shed some
> lights
> >>on it? Thank you in advance.
> >>
> >>- Reeve
> >
> >Your flash part[s] are almost certainly write-protected, or part of them
> >is. Get the data-sheet for them and find what combination to write to
> >them to un-protect them and try again. For the parts I'm using (micron
> >MT28F128J3) writing 0x00600060 followed by 0x00d000d0 to the part does
> >the trick.
> >
> >-michael
>
> I must be lonely, responding to my own email :-).
>
> The other option you have is re-build u-boot to run from ram (presumably
> at some lower address), then use u-boot itself to clear the write
> protect bits on your flash. U-boot's makefile has config targets for
> ram & flash for some target boards which you may be able to take
> advantage of. My first solution is probably still quicker if you're not
> trying to debug u-boot itself.
>
> -michael
>
[-- Attachment #2: Type: text/html, Size: 2865 bytes --]
^ permalink raw reply
* [PATCH] Add DOS partition support to mpc834x_itx_defconfig
From: timur @ 2006-09-29 21:42 UTC (permalink / raw)
To: linuxppc-dev
From: Timur Tabi <timur@freescale.com>
The default configuration file for the MPC8349E-mITX reference board,
mpc834x_itx_defconfig, did not include support for DOS partition types.
This support is necessary because the hard drive that comes with the ITX
is formatted with this partition type. Without this config option,
the drive cannot be mounted.
---
arch/powerpc/configs/mpc834x_itx_defconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/configs/mpc834x_itx_defconfig b/arch/powerpc/configs/mpc834x_itx_defconfig
index cd3535e..0561b73 100644
--- a/arch/powerpc/configs/mpc834x_itx_defconfig
+++ b/arch/powerpc/configs/mpc834x_itx_defconfig
@@ -1248,7 +1248,7 @@ # CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
-# CONFIG_MSDOS_PARTITION is not set
+CONFIG_MSDOS_PARTITION=y
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
--
1.4.2.1
^ permalink raw reply related
* Re: Need help on PPC8343E bringup
From: Michael Galassi @ 2006-09-29 21:39 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <200609292133.k8TLXUUv072654@penguin.ncube.com>
>>Hello linux-ppc experts,
>>
>>I'm trying to use using wind river jtag probe to download uboot to our
>>switching box which is with PPC8343E/Intel 28F128J3D memory flash(16M).
>>Memory mapping is starting from 0xFF000000 to 0xFFFFFFFF which is 16M. The
>>JTAG software I'm using is visionclick8.
>>
>>The problem now is that I even couldn't erash flash, with following error
>>message:
>>
>>TF ERASE FFF00000..FFFFFFFF INTEL 28F128Jx ( 8192 x 16 ) 1 Device
>>Erasing Flash(s) ... Failed
>>!ERROR! - [msg100000] Failed while erasing the device(s)
>>>BKM>
>>!HALT! - [msg90009] Target Stopped : CheckStop taken; PC = 0x00007404 [EVENT
>>Taken]
>>>BKM>
>>
>>Does anyone has experiece to bring up this CPU, and could shed some lights
>>on it? Thank you in advance.
>>
>>- Reeve
>
>Your flash part[s] are almost certainly write-protected, or part of them
>is. Get the data-sheet for them and find what combination to write to
>them to un-protect them and try again. For the parts I'm using (micron
>MT28F128J3) writing 0x00600060 followed by 0x00d000d0 to the part does
>the trick.
>
>-michael
I must be lonely, responding to my own email :-).
The other option you have is re-build u-boot to run from ram (presumably
at some lower address), then use u-boot itself to clear the write
protect bits on your flash. U-boot's makefile has config targets for
ram & flash for some target boards which you may be able to take
advantage of. My first solution is probably still quicker if you're not
trying to debug u-boot itself.
-michael
^ permalink raw reply
* Re: Need help on PPC8343E bringup
From: Michael Galassi @ 2006-09-29 21:33 UTC (permalink / raw)
To: Reeve Yang; +Cc: linuxppc-embedded
In-Reply-To: <198592450609291408w2dbf7e5ckf5e4cf7023d2000@mail.gmail.com>
>Hello linux-ppc experts,
>
>I'm trying to use using wind river jtag probe to download uboot to our
>switching box which is with PPC8343E/Intel 28F128J3D memory flash(16M).
>Memory mapping is starting from 0xFF000000 to 0xFFFFFFFF which is 16M. The
>JTAG software I'm using is visionclick8.
>
>The problem now is that I even couldn't erash flash, with following error
>message:
>
>TF ERASE FFF00000..FFFFFFFF INTEL 28F128Jx ( 8192 x 16 ) 1 Device
>Erasing Flash(s) ... Failed
>!ERROR! - [msg100000] Failed while erasing the device(s)
>>BKM>
>!HALT! - [msg90009] Target Stopped : CheckStop taken; PC = 0x00007404 [EVENT
>Taken]
>>BKM>
>
>Does anyone has experiece to bring up this CPU, and could shed some lights
>on it? Thank you in advance.
>
>- Reeve
Your flash part[s] are almost certainly write-protected, or part of them
is. Get the data-sheet for them and find what combination to write to
them to un-protect them and try again. For the parts I'm using (micron
MT28F128J3) writing 0x00600060 followed by 0x00d000d0 to the part does
the trick.
-michael
^ permalink raw reply
* Need help on PPC8343E bringup
From: Reeve Yang @ 2006-09-29 21:08 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
Hello linux-ppc experts,
I'm trying to use using wind river jtag probe to download uboot to our
switching box which is with PPC8343E/Intel 28F128J3D memory flash(16M).
Memory mapping is starting from 0xFF000000 to 0xFFFFFFFF which is 16M. The
JTAG software I'm using is visionclick8.
The problem now is that I even couldn't erash flash, with following error
message:
TF ERASE FFF00000..FFFFFFFF INTEL 28F128Jx ( 8192 x 16 ) 1 Device
Erasing Flash(s) ... Failed
!ERROR! - [msg100000] Failed while erasing the device(s)
>BKM>
!HALT! - [msg90009] Target Stopped : CheckStop taken; PC = 0x00007404 [EVENT
Taken]
>BKM>
Does anyone has experiece to bring up this CPU, and could shed some lights
on it? Thank you in advance.
- Reeve
[-- Attachment #2: Type: text/html, Size: 822 bytes --]
^ permalink raw reply
* Re: SATA: "unknown partition table" error, fdisk can't fix, works in 2.6.13
From: Chris Boot @ 2006-09-29 20:20 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <451D7DE8.8020504@freescale.com>
Timur,
fdisk manipulates DOS-style partition maps. Have you compiled these
into your latest kernel? You don't actually have any errors in the
below messages, other than the partition map being unreadable...
Chris
On 29 Sep 2006, at 21:11, Timur Tabi wrote:
> I have a SATA drive attached to a PowerPC 8349E board, using the
> SIL 3114 controller. I'm running the latest code from Paul
> Mackerras (PowerPC maintainer) (2.6.18-blabla).
>
> I'm experiencing a number of I/O errors with the SATA drive. fdisk
> can see the partition table, but when I issue the "w" command, I
> get this output:
>
> Calling ioctl() to re-read partition table.
> SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
> sda: Write Protect is off
> SCSI device sda: drive cache: write back
> sda: unknown partition table
> SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
> sda: Write Protect is off
> SCSI device sda: drive cache: write back
> sda: unknown partition table
> Syncing disks.
>
> I cannot mount any partitions. On boot, I see this:
>
> sata_sil 0000:00:10.0: Applying R_ERR on DMA activate FIS errata fix
> ata1: SATA max UDMA/100 cmd 0xD100E080 ctl 0xD100E08A bmdma
> 0xD100E000 irq 22
> ata2: SATA max UDMA/100 cmd 0xD100E0C0 ctl 0xD100E0CA bmdma
> 0xD100E008 irq 22
> ata3: SATA max UDMA/100 cmd 0xD100E280 ctl 0xD100E28A bmdma
> 0xD100E200 irq 22
> ata4: SATA max UDMA/100 cmd 0xD100E2C0 ctl 0xD100E2CA bmdma
> 0xD100E208 irq 22
> scsi0 : sata_sil
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> ata1.00: ATA-7, max UDMA/133, 321672960 sectors: LBA48 NCQ (depth
> 0/32)
> ata1.00: ata1: dev 0 multi count 0
> ata1.00: configured for UDMA/100
> scsi1 : sata_sil
> ata2: SATA link down (SStatus 0 SControl 310)
> scsi2 : sata_sil
> ata3: SATA link down (SStatus 0 SControl 310)
> scsi3 : sata_sil
> ata4: SATA link down (SStatus 0 SControl 310)
> scsi 0:0:0:0: Direct-Access ATA HDT722516DLA380 V43O PQ:
> 0 ANSI: 5
> SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
> sda: Write Protect is off
> SCSI device sda: drive cache: write back
> SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
> sda: Write Protect is off
> SCSI device sda: drive cache: write back
> sda: unknown partition table
> sd 0:0:0:0: Attached scsi disk sda
> sd 0:0:0:0: Attached scsi generic sg0 type 0
>
> The odd thing is that this works in 2.6.13, so something is
> broken. I don't know if it's a bug in the sata_sil driver, or a
> configuration issue. Can anyone help?
>
> --
> Timur Tabi
> Linux Kernel Developer @ Freescale
> -
> To unsubscribe from this list: send the line "unsubscribe linux-
> kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Chris Boot
bootc@bootc.net
http://www.bootc.net/
^ permalink raw reply
* Re: SATA: "unknown partition table" error, fdisk can't fix, works in 2.6.13
From: Timur Tabi @ 2006-09-29 20:29 UTC (permalink / raw)
To: Chris Boot; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <BA55C0C9-B58F-473E-9412-B582411D017A@bootc.net>
Chris Boot wrote:
> Timur,
>
> fdisk manipulates DOS-style partition maps. Have you compiled these into
> your latest kernel? You don't actually have any errors in the below
> messages, other than the partition map being unreadable...
Yes, that was it! Thank you very much. All I had to do was select "PC BIOS (MSDOS partition tables) support" configuration option, and that was it.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: SATA: "unknown partition table" error, fdisk can't fix, works in 2.6.13
From: Olof Johansson @ 2006-09-29 20:20 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <451D7DE8.8020504@freescale.com>
On Fri, 29 Sep 2006 15:11:20 -0500 Timur Tabi <timur@freescale.com> wrote:
> I have a SATA drive attached to a PowerPC 8349E board, using the SIL 3114 controller. I'm running the latest code from Paul Mackerras (PowerPC maintainer) (2.6.18-blabla).
>
> I'm experiencing a number of I/O errors with the SATA drive. fdisk can see the partition table, but when I issue the "w" command, I get this output:
>
> The odd thing is that this works in 2.6.13, so something is broken. I don't know if it's a bug in the sata_sil driver, or a configuration issue. Can anyone help?
>
Do you use MSDOS or MAC partition (or other) type? Make sure you have
the one you use in the config.
It looks like the arch/powerpc/configs/mpc83* defconfigs enable neither.
-Olof
^ permalink raw reply
* Re: no map ! Using irq line 0 from PCI config
From: Timur Tabi @ 2006-09-29 20:15 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <451C365B.8090300@freescale.com>
Timur Tabi wrote:
> I'm having a problem with a SATA PCI device on an 8349E board. The SATA driver is timing out when trying to query the drive. I believe this is happening because interrupts aren't being routed correctly.
Never mind ... my interrupt-map node was completely wrong.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* SATA: "unknown partition table" error, fdisk can't fix, works in 2.6.13
From: Timur Tabi @ 2006-09-29 20:11 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
I have a SATA drive attached to a PowerPC 8349E board, using the SIL 3114 controller. I'm running the latest code from Paul Mackerras (PowerPC maintainer) (2.6.18-blabla).
I'm experiencing a number of I/O errors with the SATA drive. fdisk can see the partition table, but when I issue the "w" command, I get this output:
Calling ioctl() to re-read partition table.
SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write back
sda: unknown partition table
SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write back
sda: unknown partition table
Syncing disks.
I cannot mount any partitions. On boot, I see this:
sata_sil 0000:00:10.0: Applying R_ERR on DMA activate FIS errata fix
ata1: SATA max UDMA/100 cmd 0xD100E080 ctl 0xD100E08A bmdma 0xD100E000 irq 22
ata2: SATA max UDMA/100 cmd 0xD100E0C0 ctl 0xD100E0CA bmdma 0xD100E008 irq 22
ata3: SATA max UDMA/100 cmd 0xD100E280 ctl 0xD100E28A bmdma 0xD100E200 irq 22
ata4: SATA max UDMA/100 cmd 0xD100E2C0 ctl 0xD100E2CA bmdma 0xD100E208 irq 22
scsi0 : sata_sil
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: ATA-7, max UDMA/133, 321672960 sectors: LBA48 NCQ (depth 0/32)
ata1.00: ata1: dev 0 multi count 0
ata1.00: configured for UDMA/100
scsi1 : sata_sil
ata2: SATA link down (SStatus 0 SControl 310)
scsi2 : sata_sil
ata3: SATA link down (SStatus 0 SControl 310)
scsi3 : sata_sil
ata4: SATA link down (SStatus 0 SControl 310)
scsi 0:0:0:0: Direct-Access ATA HDT722516DLA380 V43O PQ: 0 ANSI: 5
SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write back
SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write back
sda: unknown partition table
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
The odd thing is that this works in 2.6.13, so something is broken. I don't know if it's a bug in the sata_sil driver, or a configuration issue. Can anyone help?
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] IBM GPIO driver for PowerPC 4xx is back from the dead
From: Eugene Surovegin @ 2006-09-29 16:46 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Jean-Baptiste Maneyrol, linuxppc-embedded
In-Reply-To: <200609291106.20987.arnd.bergmann@de.ibm.com>
On Fri, Sep 29, 2006 at 11:06:19AM +0200, Arnd Bergmann wrote:
>
> > +{
> > + u32 cfg_reg;
> > +
> > + if (device != 0)
> > + return -ENXIO;
> > +
> > +#ifdef CONFIG_40x
> > +#ifdef DCRN_CHCR0
> > + /*
> > + * PPC405 uses CPC0_CR0 to select multiplexed GPIO pins.
> > + */
> > + cfg_reg = mfdcr(DCRN_CHCR0);
> > + cfg_reg = (cfg_reg & ~mask) | (data & mask);
> > + mtdcr(DCRN_CHCR0, cfg_reg);
> > +#endif
> > +#elif CONFIG_440GP
> > + /*
> > + * PPC440GP uses CPC0_GPIO to select multiplexed GPIO pins.
> > + */
> > + cfg_reg = mfdcr(DCRN_CPC0_GPIO);
> > + cfg_reg = (cfg_reg & ~mask) | (data & mask);
> > + mtdcr(DCRN_CPC0_GPIO, cfg_reg);
> > +#elif CONFIG_440GX
> > + /*
> > + * PPC440GX uses SDR0_PFC0 to select multiplexed GPIO pins
> > + */
> > + cfg_reg = SDR_READ(DCRN_SDR_PFC0);
> > + cfg_reg = (cfg_reg & ~mask) | (data & mask);
> > + SDR_WRITE(DCRN_SDR_PFC0, cfg_reg);
> > +#else
> > +#error This driver is only supported on PPC40x and PPC440 CPUs
> > +#endif
>
> This prevents building a single kernel for multiple 440 version.
> Please use a run-time check, or better get the necessary information
> from the device tree.
440 kernels _are_ built for each particular 440 chip separately, and
not all these defines are even available simultaneously.
So, frankly, I don't understand your complain here. We don't support
single kernel image running on different 440s. Also, last time I
checked, 440 port wasn't using device tree as well.
--
Eugene
^ permalink raw reply
* Re: [PATCH] IBM GPIO driver for PowerPC 4xx is back from the dead
From: Eugene Surovegin @ 2006-09-29 16:42 UTC (permalink / raw)
To: Jean-Baptiste Maneyrol; +Cc: linuxppc-embedded
In-Reply-To: <1159515965.5613.4.camel@jb-portable>
On Fri, Sep 29, 2006 at 09:46:04AM +0200, Jean-Baptiste Maneyrol wrote:
> Here is a patch for linux 2.6.18 that makes come back the old ibm gpio
> driver from 2.6.10.
>
> It is mainly useful for compatibility with old linux 2.4 from Montavista
> I think, because direct memory access seems the new way to go.
In my opinion it should stay dead. And no, direct memory access isn't
a way to go - how are you gonna provide synchronization in this case?
Think about different processes mucking with GPIO registers.
I think such low-level functionality should never be exported to the
user-space in the first place. If your user-space needs such access
make it explicit through procfs/sysfs (e.g.
/proc/sys/dev/my_board/reset_that_device for GPIO pin wired to some
chip reset) or just make a specific driver for your hardware.
--
Eugene
^ permalink raw reply
* Re: [PATCH 0/9] Add support for QE and 8360EMDS board -v3
From: Li Yang @ 2006-09-29 14:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <65774A0C-1AD2-4E72-9D89-ACC77BE9CEB4@kernel.crashing.org>
On 9/29/06, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Sep 29, 2006, at 5:34 AM, Li Yang wrote:
>
> > Paul,
> >
> > The series of patches add generic QE infrastructure called
> > qe_lib, and MPC8360EMDS board support. Qe_lib is used by
> > QE device drivers such as ucc_geth driver.
> >
> > This version updates QE interrupt controller to use new irq
> > mapping mechanism, addresses all the comments received with
> > last submission and includes some style fixes.
> >
> > v2: Change to use device tree for BCSR and MURAM;
> > Remove I/O port interrupt handling code as it is not generic
> > enough.
> >
> > v3: Address comments from Kumar; Update definition of several
> > device tree nodes; Copyright style change.
>
> In going through this code some general comments:
> * remove typedef's, its not the normal convention to use typedefs the
> way this code is. Makes it more difficult to read
> * look at use of uint vs u32. I think there are a number of cases
> were you really want u32.
>
> Also, can you provide some high level description of what all this
> code is doing. I understand the port io init, I get the interrupt
> handling. I'm at a loss as that what all the channel ucc_fast/
> ucc_slow code is trying to do and some of the init code.
Well, in brief. There are many flexible options for QE SoC UCC. Such
as clock routing, pin multiplexing, virtual fifo, BD rings, etc. The
ucc code provides generic initialization and configuration routines
for these common options to be reused through drivers. The
encapsulation of register manipulating code also makes the code more
readable.
- Leo
^ permalink raw reply
* Re: [PATCH 0/12] Add support for QE and 8360EMDS board -v2
From: Li Yang @ 2006-09-29 14:28 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <9D891AA8-4F40-4FB5-B2CE-2A974FBF4585@kernel.crashing.org>
On 9/29/06, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Sep 28, 2006, at 10:21 PM, Li Yang-r58472 wrote:
>
> >> -----Original Message-----
> >> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> >> Sent: Friday, September 29, 2006 12:37 AM
> >> To: Li Yang-r58472
> >> Cc: linuxppc-dev@ozlabs.org; paulus@samba.org
> >> Subject: Re: [PATCH 0/12] Add support for QE and 8360EMDS board -v2
> >>
> >>
> >> On Sep 28, 2006, at 11:09 AM, Li Yang wrote:
> >>
> >>> On 9/28/06, Kumar Gala <galak@kernel.crashing.org> wrote:
> >>>>
> >>>> On Sep 28, 2006, at 3:18 AM, Li Yang wrote:
> >>>>
> >>>>> Paul,
> >>>>>
> >>>>> The series of patches add generic QE infrastructure called
> >>>>> qe_lib, and MPC8360EMDS board support. Qe_lib is used by
> >>>>> QE device drivers such as ucc_geth driver.
> >>>>>
> >>>>> This version updates QE interrupt controller to use new irq
> >>>>> mapping mechanism, addresses all the comments received with
> >>>>> last submission and includes some style fixes.
> >>>>>
> >>>>> v2 change: Change to use device tree for BCSR and MURAM;
> >>>>> Remove I/O port interrupt handling code as it is not generic
> >>>>> enough.
> >>>>
> >>>> Before accepting any of this code, I'd like to see what the drivers
> >>>> look like that are using it. Its hard to make significant
> >>>> comments w/
> >>>> o seeing what the consumers of all the 'lib' code look like.
> >>>
> >>> Current in-tree user of the lib is driver/net/ucc_geth.c. There is
> >>> also QE ATM driver which is included in Alex's 8360sar project. QE
> >>> USB host/client drivers are in Freescale LTIB BSP.
> >>
> >> is there a serial driver?
> >
> > No. It is not very necessary to have serial support for QE, as
> > there is
> > separate DUART SoC. We can use 8250 serial driver for that.
>
> Are there any examples of drivers for a UCC slow channel?
No, at present.
^ 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