* Re: how to apply a PowerPC patch to linux 2.4 kernel and port to memec board with vertex II pro FPGA?
From: Ameet Patil @ 2006-08-11 16:23 UTC (permalink / raw)
To: Ujwal, linuxppc-embedded
In-Reply-To: <b47d45990608110817u2d4ac4d9na4e23af44a92bb09@mail.gmail.com>
Hi Ujwal,
Linux has support for Xilinx Virtex II Pro FPGA with PPC405. I am
sure you can compile for your specific board (MEMEC). Long time back I
had come across a doc. related to Linux on MEMEC. Try googling for it...
may be its still there.
The key is to configure (or set the defines of) the Linux BSP parameters
that are specific to your board!
cheers,
-Ameet
Ujwal wrote:
> hi amit,
> which are the common development/evaluation boards does this PowerPC
> work ???
>
> can i use the MEMEC design board with Virtex II Pro FPGA and run the
> crosscompiled image of linux for powerpc on this board?????
>
>
> pls reply .... as im right now bowled out .
>
> Thanks,
> Ujwal
>
>
>
>
> On 8/11/06, *Ameet Patil* < ammubhai@gmail.com
> <mailto:ammubhai@gmail.com>> wrote:
>
> Ujwal,
>
> Have a look at:
> http://splish.ee.byu.edu/projects/LinuxFPGA/configuring.htm
> http://www.crhc.uiuc.edu/IMPACT/gsrc/hardwarelab/docs/kernel-HOWTO.html
> http://linux.get2knowmore.com/
>
> U might get some idea.
>
> -Ameet
>
> Ujwal wrote:
> >
> >
> > hi all,
> >
> > im new to porting of Linux to PowerPC . Could anyone let me know
> >
> > 1) the procedure of how to Port a linux OS to PowerPC for a
> VirtexII Pro
> > memec board??
> >
> > whats are the steps that i need to follow?
> >
> > 2) where can i find the power-pc patch for linux 2.4 kernel?
> >
> >
> > Thanks and Regards,
> > Ujwal
> >
> >
> >
> ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org <mailto:Linuxppc-embedded@ozlabs.org>
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> <https://ozlabs.org/mailman/listinfo/linuxppc-embedded>
>
>
^ permalink raw reply
* RE: Debugging with no serial port
From: Martin, Tim @ 2006-08-11 16:30 UTC (permalink / raw)
To: bwarren; +Cc: linuxppc-embedded
=20
> > =09
> > I tried this as well and have the same GDB synchronization=20
> problem e.g.
> >=20
> > break log_stuff
> > commands
> > silent
> > if (variable_logging_enabled)
> > printf "(%d,%d)\n",stuff1_variable,stuff2_variable
> > end
> > cont
> > end
> >=20
> That's too bad. I wonder if you could run gdb from expect or=20
> some other auto-scripting language and have it issue the=20
> 'cont' once all data is printed (Have your code spit out a=20
> special 'end of data' delimiter).=20
>=20
> Just a thought - no idea if it would work. =20
>=20
What a brilliant idea! I tried this and it works perfectly. Having no
previous expect experience, I was able to generate and modify the expect
script with "autoexpect" in about 10 minutes.
Thanks!
Tim
^ permalink raw reply
* [PATCH 0/4]: powerpc/cell spidernet ethernet driver fixes
From: Linas Vepstas @ 2006-08-11 17:03 UTC (permalink / raw)
To: netdev, linux-kernel, linuxppc-dev
Cc: James K Lewis, Arnd Bergmann, Jens Osterkamp
The following series of patches implement some fixes and performance
improvements for the Spedernet ethernet device driver. The high point
of the patch series is some code to implement a low-watermark interrupt
on the transmit queue. The bundle of patches raises transmit performance
from some embarassingly low value to a reasonable 730 Megabits per
second for 1500 byte packets.
Please note that the spider is an ethernet controller that is
integrated into the south bridge, and is thus available only on
Cell-based platforms.
These have been well-tested over the last few weeks. Please apply.
--linas
^ permalink raw reply
* [PATCH 1/4]: powerpc/cell spidernet burst alignment patch.
From: Linas Vepstas @ 2006-08-11 17:06 UTC (permalink / raw)
To: netdev, linux-kernel, linuxppc-dev
Cc: Jens Osterkamp, James K Lewis, Arnd Bergmann
In-Reply-To: <20060811170337.GH10638@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 about 100Mbps to 300-400Mbps.
Signed-off-by: James K Lewis <jklewis@us.ibm.com>
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: Utz Bacher <utz.bacher@de.ibm.com>
Cc: Jens Osterkamp <Jens.Osterkamp@de.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-rc3-mm2/drivers/net/spider_net.h
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net.h 2006-08-07 14:37:10.000000000 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net.h 2006-08-11 11:09:57.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 2/4]: powerpc/cell spidernet low watermark patch.
From: Linas Vepstas @ 2006-08-11 17:08 UTC (permalink / raw)
To: netdev, linux-kernel, linuxppc-dev
Cc: Jens Osterkamp, James K Lewis, Arnd Bergmann
In-Reply-To: <20060811170337.GH10638@austin.ibm.com>
Implement basic low-watermark support for the transmit queue.
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 he 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.
This is accomplished 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 te flag
at about 3/4's of the way into the queue.
This patch boosts driver performance from about
300-400Mbps for 1500 byte packets, to about 710-740Mbps.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: James K Lewis <jklewis@us.ibm.com>
Cc: Utz Bacher <utz.bacher@de.ibm.com>
Cc: Jens Osterkamp <Jens.Osterkamp@de.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-rc3-mm2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net.c 2006-08-07 14:39:38.000000000 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net.c 2006-08-11 11:23:24.000000000 -0500
@@ -700,6 +700,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
@@ -717,6 +750,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);
@@ -729,8 +763,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) */
@@ -747,12 +783,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;
}
/**
@@ -1453,6 +1492,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);
@@ -1615,6 +1658,9 @@ spider_net_open(struct net_device *netde
card->descr,
PCI_DMA_TODEVICE, tx_descriptors))
goto alloc_tx_failed;
+
+ card->low_watermark = NULL;
+
if (spider_net_init_chain(card, &card->rx_chain,
card->descr + tx_descriptors,
PCI_DMA_FROMDEVICE, rx_descriptors))
Index: linux-2.6.18-rc3-mm2/drivers/net/spider_net.h
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net.h 2006-08-11 11:09:57.000000000 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net.h 2006-08-11 11:19:47.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 */
@@ -424,6 +425,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 3/4]: powerpc/cell spidernet stop error printing patch.
From: Linas Vepstas @ 2006-08-11 17:09 UTC (permalink / raw)
To: netdev, linux-kernel, linuxppc-dev
Cc: Jens Osterkamp, James K Lewis, Arnd Bergmann
In-Reply-To: <20060811170337.GH10638@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: Utz Bacher <utz.bacher@de.ibm.com>
Cc: Jens Osterkamp <Jens.Osterkamp@de.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-rc3-mm2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net.c 2006-08-11 11:23:24.000000000 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net.c 2006-08-11 11:34:16.000000000 -0500
@@ -1275,12 +1275,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;
@@ -1339,9 +1342,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 */
@@ -1455,8 +1459,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 4/4]: powerpc/cell spidernet ethtool -i version number info.
From: Linas Vepstas @ 2006-08-11 17:11 UTC (permalink / raw)
To: netdev, linux-kernel, linuxppc-dev
Cc: Jens Osterkamp, James K Lewis, Arnd Bergmann
In-Reply-To: <20060811170337.GH10638@austin.ibm.com>
This patch adds version information as reported by
ethtool -i to the Spidernet driver.
Signed-off-by: James K Lewis <jklewis@us.ibm.com>
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: Utz Bacher <utz.bacher@de.ibm.com>
Cc: Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
----
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-rc3-mm2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net.c 2006-08-11 11:34:16.000000000 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net.c 2006-08-11 11:38:48.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;
@@ -2293,6 +2294,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-rc3-mm2/drivers/net/spider_net.h
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net.h 2006-08-11 11:19:47.000000000 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net.h 2006-08-11 11:38:48.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-rc3-mm2/drivers/net/spider_net_ethtool.c
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net_ethtool.c 2006-06-17 20:49:35.000000000 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net_ethtool.c 2006-08-11 11:38:48.000000000 -0500
@@ -55,7 +55,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
* Re: Reg. Serial and Virtual consoles
From: Linas Vepstas @ 2006-08-11 17:18 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev
In-Reply-To: <3115522870674b0dc514.719885386.miltonm@bga.com>
On Thu, Aug 10, 2006 at 11:51:46AM -0500, Milton Miller wrote:
> It sounds to me that you want all input and output on the serial line to be echoed to the vga screen both user and kernel. Do you also require keyboard input?
I missed the start of the conversation, so the following suggestion may
be irrelevent. However, if the goal is to get kernel messages displayed
in lots of different places, this is easily done by running syslogd, and
adding the following to /etc/syslog.conf:
kern.*;*.err *
If you don' want them slatered everywhere, but only on
the console, then:
kern.*;*.err |/dev/console
--linas
^ permalink raw reply
* Re: [PATCH 0/4]: powerpc/cell spidernet ethernet driver fixes
From: jschopp @ 2006-08-11 17:42 UTC (permalink / raw)
To: Linas Vepstas
Cc: Arnd Bergmann, netdev, James K Lewis, linux-kernel, linuxppc-dev,
Jens Osterkamp
In-Reply-To: <20060811170337.GH10638@austin.ibm.com>
Linas Vepstas wrote:
> The following series of patches implement some fixes and performance
> improvements for the Spedernet ethernet device driver. The high point
> of the patch series is some code to implement a low-watermark interrupt
> on the transmit queue. The bundle of patches raises transmit performance
> from some embarassingly low value to a reasonable 730 Megabits per
> second for 1500 byte packets.
>
> Please note that the spider is an ethernet controller that is
> integrated into the south bridge, and is thus available only on
> Cell-based platforms.
>
> These have been well-tested over the last few weeks. Please apply.
With these patches the spidernet driver performance goes from bad to usable. They are all
good changes. I'd expect some more bottlnecks to be identified now that these are
cleared. Maybe Jim and Linas can get the driver performance up from usable to good next.
Acked-by: Joel Schopp <jschopp@austin.ibm.com>
^ permalink raw reply
* Re: [PATCH 0/4]: powerpc/cell spidernet ethernet driver fixes
From: Sam Ravnborg @ 2006-08-11 17:44 UTC (permalink / raw)
To: Linas Vepstas
Cc: Arnd Bergmann, netdev, James K Lewis, linux-kernel, linuxppc-dev,
Jens Osterkamp
In-Reply-To: <20060811170337.GH10638@austin.ibm.com>
On Fri, Aug 11, 2006 at 12:03:37PM -0500, Linas Vepstas wrote:
>
> The following series of patches implement some fixes and performance
> improvements for the Spedernet ethernet device driver. The high point
> of the patch series is some code to implement a low-watermark interrupt
> on the transmit queue. The bundle of patches raises transmit performance
> from some embarassingly low value to a reasonable 730 Megabits per
> second for 1500 byte packets.
>
> Please note that the spider is an ethernet controller that is
> integrated into the south bridge, and is thus available only on
> Cell-based platforms.
>
> These have been well-tested over the last few weeks. Please apply.
Hi Linas.
Just noticed a nit-pick detail.
The general rule is to add your Signed-off-by: at the bottom of the
patch, so the top-most Signed-of-by: is also the original author whereas
the last Signed-of-by: is the one that added this patch to the kernel.
Likewise you add Cc: before your Signed-off-by: line.
See patches from for example Andrew Morton for examples.
Sam
^ permalink raw reply
* Re: [RFC PATCH 1/4] powerpc 2.6.16-rt17: to build on powerpc w/ RT
From: john stultz @ 2006-08-11 17:56 UTC (permalink / raw)
To: Tsutomu OWA; +Cc: linuxppc-dev, mingo, Paul Mackerras, linux-kernel, tglx
In-Reply-To: <yyiac6biz3c.wl@forest.swc.toshiba.co.jp>
On Fri, 2006-08-11 at 15:08 +0900, Tsutomu OWA wrote:
> > On Fri, 11 Aug 2006 15:11:47 +1000
> > Paul Mackerras <paulus@samba.org> said:
>
> > I would be very surprised if this is all that is required for
> > CONFIG_GENERIC_TIME to work correctly on powerpc. Have you verified
> > that the CONFIG_GENERIC_TIME stuff works correctly on powerpc and
> > provides all the features provided by the current implementation?
>
> Well, probably no as you say so.
>
> What I did for CONFIG_GENERIC_TIME is just to fix a compile
> error and to see if the kernel boots or not. As I mentioned,
> it's experimental and is posted to see whether I'm moving in the
> right direction or not.
>
> I'm afraid I have not yet looked into any generic time related
> features/implementations. Looks like generic time related things
> should be on the ToDo list.
You might take a peek at the patch set here:
http://sr71.net/~jstultz/tod/ for a somewhat rough powerpc conversion to
CONFIG_GENERIC_TIME.
thanks
-john
^ permalink raw reply
* Re: [PATCH 4/4]: powerpc/cell spidernet ethtool -i version number info.
From: Olof Johansson @ 2006-08-11 18:00 UTC (permalink / raw)
To: Linas Vepstas
Cc: Arnd Bergmann, netdev, James K Lewis, linux-kernel, linuxppc-dev,
Jens Osterkamp
In-Reply-To: <20060811171117.GL10638@austin.ibm.com>
On Fri, Aug 11, 2006 at 12:11:17PM -0500, Linas Vepstas wrote:
> This patch adds version information as reported by
> ethtool -i to the Spidernet driver.
Why does a driver that's in the mainline kernel need to have a version
number besides the kernel version?
I can understand it for drivers like e1000 that Intel maintain outside
of the kernel as well. But spidernet is a fully mainline maintained
driver, right?
-Olof
^ permalink raw reply
* RE: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : differentoutputs
From: Haruki Dai-r35557 @ 2006-08-11 18:08 UTC (permalink / raw)
To: Kumar Gala, Prashant Yendigeri; +Cc: linuxppc-embedded
In-Reply-To: <CFF33627-951D-495D-8DBB-B0AC7F9D13D7@kernel.crashing.org>
Why there are three TSEC on the MPC8540??=20
Dai
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+dai.haruki=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+dai.haruki=3Dfreescale.com@ozl
> abs.org] On Behalf Of Kumar Gala
> Sent: Friday, August 11, 2006 7:38 AM
> To: Prashant Yendigeri
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6=20
> : differentoutputs
>=20
>=20
> On Aug 11, 2006, at 6:21 AM, Prashant Yendigeri wrote:
>=20
> >
> > Hi,
> >
> > Downloaded 2.6.16.26 and booted up and got this :
> >
> > / # ifconfig eth0 172.28.8.254 up
> > [ 34.034596] 0:00 not found
> > [ 34.037330] eth0: Could not attach to PHY
> > [ 34.041809] 0:00 not found
> > SIOCSIFFLAGS: No[ 34.044526] eth0: Could not attach to PHY
> > such device
> > SIOCSIFFLAGS: No such device
> >
> > I had enabled all the PHY devices in .config and also tried only =20
> > with Marvell phy enabled.
>=20
>=20
> Are you doing this on a custom board? If so what is the PHY address =20
> for the Marvell phy you are using?
>=20
> - k
>=20
> >
> > Kernel boot messages :
> > [ 2.296555] Gianfar MII Bus: probed
> > [ 2.301789] eth0: Gianfar Ethernet Controller Version 1.2, =20
> > 00:01:af:07:9b:8a
> >
> > [ 2.309039] eth0: Running with NAPI disabled
> > [ 2.313307] eth0: 64/64 RX/TX BD ring size
> > [ 2.318498] eth1: Gianfar Ethernet Controller Version 1.2, =20
> > 00:00:00:00:72:6f
> >
> > [ 2.325738] eth1: Running with NAPI disabled
> > [ 2.330006] eth1: 64/64 RX/TX BD ring size
> > [ 2.335198] eth2: Gianfar Ethernet Controller Version 1.2, 6f:=20
> > 74:3d:2f:64:65
> >
> > [ 2.342377] eth2: Running with NAPI disabled
> > [ 2.346662] eth2: 64/64 RX/TX BD ring size
> > [ 2.351586] Marvell 88E1101: Registered new driver
> > [ 2.357010] Davicom DM9161E: Registered new driver
> > [ 2.362443] Davicom DM9131: Registered new driver
> > [ 2.367775] Cicada Cis8204: Registered new driver
> > [ 2.373136] LXT970: Registered new driver
> > [ 2.377794] LXT971: Registered new driver
> > [ 2.382461] QS6612: Registered new driver
> >
> >
> > Regards,
> > Prashant
> >
> >
> >
> >
> >
> > Kumar Gala <galak@kernel.crashing.org>
> > 08/11/2006 09:40 AM
> >
> > To
> > Prashant Yendigeri <Prashant.Yendigeri@lntinfotech.com>
> > cc
> > linuxppc-embedded@ozlabs.org
> > Subject
> > Re: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : different =20
> > outputs
> >
> >
> >
> >
> >
> >
> > On Aug 10, 2006, at 6:18 AM, Prashant Yendigeri wrote:
> >
> > >
> > > Hi,
> > >
> > > The gianfar driver of 2.6.12 and 2.4.20 give different outputs on
> > > the same PPC 8540 board.
> > >
> > > What could be the reason ?
> > >
> > > Output on 2.4.20 :
> > > /root # ifconfig eth0 172.28.8.254 up
> > > eth0: PHY is Marvell 88E1011S (1410c62)
> > > eth0: Auto-negotiation done
> > > eth0: Half Duplex
> > > eth0: Speed 10BT
> > > eth0: Link is up
> > >
> > > Output on 2.6.12
> > > / # ifconfig eth0 172.28.8.254 up
> > > eth0: PHY is Generic MII (ffffffff)
> >
> > It looks like your 2.6.12 kernel isn't handling the PHY correctly.
> > I'd recommend upgrading to something newer which has the phylib
> > (can't remember which 2.6 that went into).
> >
> > - kumar
> >
> >=20
> ______________________________________________________________________
> >
> >
> >=20
> ______________________________________________________________________
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* Re: [RFC] asm code for Hypervisor Call Instrumentation
From: Mike Kravetz @ 2006-08-11 18:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17622.56592.41532.206800@cargo.ozlabs.ibm.com>
On Mon, Aug 07, 2006 at 04:26:24PM +1000, Paul Mackerras wrote:
> Hmmm, doing the update in assembly would avoid the need to create a
> stack frame, which would be nice... Maybe we need to add some macros
> to include/asm-powerpc/percpu.h to make it easier to access per-cpu
> variables from assembly code.
>
> Alternatively, we could put a pointer to the hcall_stats array for
> each cpu in its paca. That's very easily accessed from assembly code.
I finally got around to doing the update in assembly. I have attached
the code in question below. Macros were added (elsewhere) for things like
stat structure and offsets within the structure. No macros for per-cpu
data. Rather, I just used some existing definitions and based code on
descriptions in asm-powerpc/percpu.h. Let me know if this introduces too
many (unchecked at compile time assumptions) into the code.
The many comments are mostly for my benefit. :)
Thanks,
--
Mike
#define STK_PARM(i) (48 + ((i)-3)*8)
#ifdef CONFIG_HCALL_STATS
/*
* precall must preserve all registers. use unused STK_PARM()
* areas to save snapshots and opcode.
*/
#define HCALL_INST_PRECALL \
std r3,STK_PARM(r3)(r1); /* save opcode */ \
mftb r3; /* get timebase and */ \
std r3,STK_PARM(r5)(r1); /* save for later */ \
BEGIN_FTR_SECTION; \
mfspr r3,SPRN_PURR; /* get PURR and */ \
END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
std r3,STK_PARM(r6)(r1); /* save for later */ \
ld r3,STK_PARM(r3)(r1); /* opcode back in r3 */
/*
* postcall is performed immediately before function return which
* allows liberal use of non-volital registers.
*/
#define HCALL_INST_POSTCALL \
/* get time and PURR snapshots after hcall */ \
mftb r7; /* timebase after */ \
BEGIN_FTR_SECTION; \
mfspr r8,SPRN_PURR; /* PURR after */ \
END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
\
/* calculate time and PURR deltas for call */ \
ld r5,STK_PARM(r5)(r1); /* timebase before */ \
subf r5,r5,r7; \
ld r6,STK_PARM(r6)(r1); /* PURR before */ \
subf r6,r6,r8; \
\
/* calculate address of stat structure */ \
ld r4,STK_PARM(r3)(r1); /* use opcode as */ \
rldicl r4,r4,62,2; /* index into array */ \
mulli r4,r4,HCALL_STAT_SIZE; \
LOAD_REG_ADDR(r7, per_cpu__hcall_stats); \
add r4,r4,r7; \
ld r7,PACA_DATA_OFFSET(r13); /* per cpu offset */ \
add r4,r4,r7; \
\
/* update stats */ \
ld r7,HCALL_STAT_CALLS(r4); /* count */ \
addi r7,r7,1; \
std r7,HCALL_STAT_CALLS(r4); \
ld r7,HCALL_STAT_TB(r4); /* timebase */ \
add r7,r7,r5; \
std r7,HCALL_STAT_TB(r4); \
ld r7,HCALL_STAT_PURR(r4); /* PURR */ \
add r7,r7,r6; \
std r7,HCALL_STAT_PURR(r4);
#else
#define HCALL_INST_PRECALL
#define HCALL_INST_POSTCALL
#endif
^ permalink raw reply
* Re: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : differentoutputs
From: Matt Porter @ 2006-08-11 18:35 UTC (permalink / raw)
To: Haruki Dai-r35557; +Cc: Prashant Yendigeri, linuxppc-embedded
In-Reply-To: <18AEF66AFDF06F4CAAA1D419D000FD3380B85B@az33exm24.fsl.freescale.net>
On Fri, Aug 11, 2006 at 11:08:59AM -0700, Haruki Dai-r35557 wrote:
> Why there are three TSEC on the MPC8540??
There aren't. There are two TSECs and one FEC on the MPC8540.
gianfar drives them all (all the non-CPM enets, that is).
-Matt
^ permalink raw reply
* Re: [PATCH 4/4]: powerpc/cell spidernet ethtool -i version number info.
From: James K Lewis @ 2006-08-11 18:50 UTC (permalink / raw)
To: Olof Johansson
Cc: Arnd Bergmann, Jens Osterkamp, linux-kernel, linuxppc-dev, netdev
In-Reply-To: <20060811180013.GB6550@pb15.lixom.net>
[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]
Hi Olof,
There are several reasons why an Ethernet driver should have an up to
date version number:
1. Customers like to see they are really getting a new version.
2. It makes it easier for support personnel (me in this case) to see which
driver they have. Sure, sometimes I can talk them thru doing a "sum" on
the .ko and all that, but why not just use the version number? That's what
it is for. And no, you can't just assume they have the version that came
with the kernel they are running. It doesn't work that way.
3. It makes bug reporting easier.
4. I have already run into too many problems and wasted too much time
working with drivers when the number was NOT getting updated.
Jim Lewis
Advisory Software Engineer
IBM Linux Technology Center
512-838-7754
Olof Johansson <olof@lixom.net>
08/11/2006 01:00 PM
To
Linas Vepstas <linas@austin.ibm.com>
cc
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, Jens Osterkamp <Jens.Osterkamp@de.ibm.com>, James
K Lewis/Austin/IBM@ibmus, Arnd Bergmann <arnd@arndb.de>
Subject
Re: [PATCH 4/4]: powerpc/cell spidernet ethtool -i version number info.
On Fri, Aug 11, 2006 at 12:11:17PM -0500, Linas Vepstas wrote:
> This patch adds version information as reported by
> ethtool -i to the Spidernet driver.
Why does a driver that's in the mainline kernel need to have a version
number besides the kernel version?
I can understand it for drivers like e1000 that Intel maintain outside
of the kernel as well. But spidernet is a fully mainline maintained
driver, right?
-Olof
[-- Attachment #2: Type: text/html, Size: 2701 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4]: powerpc/cell spidernet ethernet driver fixes
From: Linas Vepstas @ 2006-08-11 19:31 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Arnd Bergmann, netdev, James K Lewis, linux-kernel, linuxppc-dev,
Jens Osterkamp
In-Reply-To: <20060811174439.GA30191@mars.ravnborg.org>
On Fri, Aug 11, 2006 at 07:44:39PM +0200, Sam Ravnborg wrote:
> >
> > These have been well-tested over the last few weeks. Please apply.
> Hi Linas.
> Just noticed a nit-pick detail.
> The general rule is to add your Signed-off-by: at the bottom of the
> patch, so the top-most Signed-of-by: is also the original author whereas
> the last Signed-of-by: is the one that added this patch to the kernel.
I put my name at the top when I was the primary author.
I put Jim's name at the top when he was the primary author.
Both names are there because I sat in Jim's office and used
his keyboard. I got him to compile and run the tests on
his hardware, and we'd then debate the results.
> Likewise you add Cc: before your Signed-off-by: line.
The patches I ave from akpm have the CC's after the
signed-off by line, not before.
--linas
^ permalink raw reply
* Re: [RFC] consolidated libdt proposal
From: Jon Loeliger @ 2006-08-11 19:33 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Cc: linuxppc-embedded, xen-ppc-devel@lists.xensource.com
In-Reply-To: <1155064370.5572.11.camel@localhost>
On Tue, 2006-08-08 at 14:12, Matthew McClintock wrote:
> This is a patch to u-boot with the changes.
>
> * Patch to modify ft_build.c to update flat device trees in place
> Patch by Matthew McClintock 26-June-2006
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
Also FYI, I have assembled all Matt's 85xx related U-Boot patches,
along with the corresponding 86xx updates, into the u-boot-86xx.git
tree on:
http://jdl.com/git_repos/
This U-Boot separates out the DTS files, but allows the DTB
to be downloaded. It can then update it and hand it off to
either an 85xx or 86xx linux kernel.
I use these commands, roughly:
# build U-boot and Linux as usual
$ dtc -f -V 0x10 -I dts -O dtb \
linux-2.6-86xx/arch/powerpc/boot/dts/mpc8641_hpcn.dts \
mpc8641_hpcn.dtb
In U-boot now:
> tftp 1000000 loeliger/uImage.8641
> tftp 900000 loeliger/mpc8641_hpcn.dtb
> bootm 1000000 - 900000
Enjoy,
jdl
^ permalink raw reply
* Re: [PATCH 4/4]: powerpc/cell spidernet ethtool -i version number info.
From: Linas Vepstas @ 2006-08-11 19:46 UTC (permalink / raw)
To: Olof Johansson
Cc: Arnd Bergmann, Jens Osterkamp, James K Lewis, linux-kernel,
linuxppc-dev, netdev
In-Reply-To: <OF934FE4E3.EEC44FDD-ON872571C7.00668651-862571C7.00677A44@us.ibm.com>
Hi Olof,
Olof Johansson <olof@lixom.net> writes:
> On Fri, Aug 11, 2006 at 12:11:17PM -0500, Linas Vepstas wrote:
>
> > This patch adds version information as reported by
> > ethtool -i to the Spidernet driver.
>
> Why does a driver that's in the mainline kernel need to have a version
> number besides the kernel version?
I'll let Jim be the primary defender. From what I can tell, "that's the
way its done". For example:
linux-2.6.18-rc3-mm2 $ grep MODULE_VERSION */*/*.c |wc
164 245 9081
> I can understand it for drivers like e1000 that Intel maintain outside
> of the kernel as well. But spidernet is a fully mainline maintained
> driver, right?
Yes, the spidernet is a Linux-kernel only driver.
--linas
p.s. very strange, but I did not see your original email;
only saw Jim's reply.
^ permalink raw reply
* Re: [PATCH 0/4]: powerpc/cell spidernet ethernet driver fixes
From: Arnd Bergmann @ 2006-08-11 20:27 UTC (permalink / raw)
To: Linas Vepstas
Cc: netdev, James K Lewis, linux-kernel, linuxppc-dev, Sam Ravnborg,
Jens Osterkamp
In-Reply-To: <20060811193102.GN10638@austin.ibm.com>
On Friday 11 August 2006 21:31, Linas Vepstas wrote:
> I put my name at the top when I was the primary author.
> I put Jim's name at the top when he was the primary author.
>
> Both names are there because I sat in Jim's office and used
> his keyboard. I got him to compile and run the tests on
> his hardware, and we'd then debate the results.
When the patch gets added to a git repository, they end up
having your name on it, because the author is determined
from the person who sent the patch.
For the patches where Jim is the main author, you should put a
From: James K Lewis <jklewis@us.ibm.com>
into the first line of the email body. That will make the
scripts do the right thing. The order of the Signed-off-by:
lines is used is independant from authorship and should
list the name of the submitter last.
Arnd <><
^ permalink raw reply
* [PATCH] fix gettimeofday vs. update_gtod race
From: Nathan Lynch @ 2006-08-11 20:41 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
Userspace can (very, very) occasionally get bogus time values due to
a tiny race between powerpc's do_gettimeofday and timer interrupt:
1. do_gettimeofday does get_tb()
2. decrementer exception on boot cpu which runs timer_recalc_offset,
which also samples the timebase and updates the do_gtod structure
with a greater timebase value.
3. do_gettimeofday calls __do_gettimeofday, which leads to the
negative result from tb_val - temp_varp->tb_orig_stamp.
The fix is to ensure that do_gettimeofday samples the timebase only
after loading do_gtod.varp.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 774c0a3..6b690df 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -417,7 +417,7 @@ static __inline__ void timer_check_rtc(v
/*
* This version of gettimeofday has microsecond resolution.
*/
-static inline void __do_gettimeofday(struct timeval *tv, u64 tb_val)
+static inline void __do_gettimeofday(struct timeval *tv)
{
unsigned long sec, usec;
u64 tb_ticks, xsec;
@@ -431,7 +431,12 @@ static inline void __do_gettimeofday(str
* without a divide (and in fact, without a multiply)
*/
temp_varp = do_gtod.varp;
- tb_ticks = tb_val - temp_varp->tb_orig_stamp;
+
+ /* Sampling the time base must be done after loading
+ * do_gtod.varp in order to avoid racing with update_gtod.
+ */
+ rmb();
+ tb_ticks = get_tb() - temp_varp->tb_orig_stamp;
temp_tb_to_xs = temp_varp->tb_to_xs;
temp_stamp_xsec = temp_varp->stamp_xsec;
xsec = temp_stamp_xsec + mulhdu(tb_ticks, temp_tb_to_xs);
@@ -464,7 +469,7 @@ void do_gettimeofday(struct timeval *tv)
tv->tv_usec = usec;
return;
}
- __do_gettimeofday(tv, get_tb());
+ __do_gettimeofday(tv);
}
EXPORT_SYMBOL(do_gettimeofday);
^ permalink raw reply related
* Re: [PATCH 1/6] ehea: interface to network stack
From: Anton Blanchard @ 2006-08-11 20:56 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <44D99EFC.3000105@de.ibm.com>
Hi,
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_main.c 1969-12-31
> +#define DEB_PREFIX "main"
Doesnt appear to be used.
> +static struct net_device_stats *ehea_get_stats(struct net_device *dev)
...
> + cb2 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
I cant see where this gets freed.
> +
> + skb_index = ((index - i
> + + port_res->skb_arr_sq_len)
> + % port_res->skb_arr_sq_len);
This is going to force an expensive divide. Its much better to change
this to the simpler and quicker:
i++;
if (i > max)
i = 0;
There are a few places in the driver can be changed to do this.
> +static int ehea_setup_single_port(struct ehea_adapter *adapter,A
> + int portnum, struct device_node *dn)
...
> + cb4 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
I cant see where this is freed.
Anton
^ permalink raw reply
* Re: [RFC] Adding MTD to device tree
From: Arnd Bergmann @ 2006-08-11 21:10 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <44DCA2BF.1030002@ru.mvista.com>
On Friday 11 August 2006 17:31, Sergei Shtylyov wrote:
> + =A0 h) MTD nodes
> +
> + =A0 Memory Technology Devices are flash, ROM, and similar chips, often =
used
> + =A0 for solid state file systems on embedded devices.
> +
> + =A0 Required properties:
> +
> + =A0 =A0- device_type : has to be "mtd"
> + =A0 =A0- compatible : Should be the name of the MTD driver. Currently, =
this is
> + =A0 =A0 =A0most likely to be "physmap".
> + =A0 =A0- reg : Offset and length of the register set for the device.
I would prefer to call them something different in the device tree.
The name 'mtd' is very specific to Linux, but the device tree
is a more generic concept.
I understand that the booting-without-of.txt file is by definition
Linux specific as well, but we should be prepared for making parts
of it a OS independent binding at the point where we put the same
device nodes into actual OF implementations that able to boot
different operating systems.
I would prefer a naming that has=20
Required properties:
- device_type : one of "nand-flash", "nor-flash", or "rom".
- model : an identifier for the actual controller chip used.
- compatible : Should be the name of the MTD driver. For
type "rom", this is most likely "physmap".
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/6] ehea: pHYP interface
From: Anton Blanchard @ 2006-08-11 21:13 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <44D99F1A.4080905@de.ibm.com>
Hi,
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_phyp.c 1969-12-31 16:00:00.000000000 -0800
> +u64 ehea_h_alloc_resource_eq(const u64 hcp_adapter_handle,
...
> +u64 hipz_h_reregister_pmr(const u64 adapter_handle,
...
> +static inline int hcp_galpas_ctor(struct h_galpas *galpas,
Be nice to have some consistent names, hipz_ and hcp_ is kind of
cryptic.
> +#define H_QP_CR_STATE_RESET 0x0000010000000000 /* Reset */
Probably want ULL on here and the other 64bit constants.
Anton
^ permalink raw reply
* Re: [PATCH 2/6] ehea: pHYP interface
From: Nathan Lynch @ 2006-08-11 21:19 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <44D99F1A.4080905@de.ibm.com>
Hi-
Jan-Bernd Themann wrote:
> +static inline long ehea_hcall_9arg_9ret(unsigned long opcode,
> + unsigned long arg1,
> + unsigned long arg2,
> + unsigned long arg3,
> + unsigned long arg4,
> + unsigned long arg5,
> + unsigned long arg6,
> + unsigned long arg7,
> + unsigned long arg8,
> + unsigned long arg9,
> + unsigned long *out1,
> + unsigned long *out2,
> + unsigned long *out3,
> + unsigned long *out4,
> + unsigned long *out5,
> + unsigned long *out6,
> + unsigned long *out7,
> + unsigned long *out8,
> + unsigned long *out9)
> +{
> + long hret = H_SUCCESS;
> + int i, sleep_msecs;
> +
> + EDEB_EN(7, "opcode=%lx arg1=%lx arg2=%lx arg3=%lx arg4=%lx "
> + "arg5=%lx arg6=%lx arg7=%lx arg8=%lx arg9=%lx",
> + opcode, arg1, arg2, arg3, arg4, arg5, arg6, arg7,
> + arg8, arg9);
> +
> +
> + for (i = 0; i < 5; i++) {
> + hret = plpar_hcall_9arg_9ret(opcode,
> + arg1, arg2, arg3, arg4,
> + arg5, arg6, arg7, arg8,
> + arg9,
> + out1, out2, out3, out4,
> + out5, out6, out7, out8,
> + out9);
> +
> + if (H_IS_LONG_BUSY(hret)) {
> + sleep_msecs = get_longbusy_msecs(hret);
> + msleep_interruptible(sleep_msecs);
> + continue;
> + }
Looping five times before giving up seems arbitrary and failure-prone
on busy systems.
Is msleep_interruptible (as opposed to msleep) really appropriate?
Hope all the callers of this function are in non-atomic context (but I
wasn't able to find any callers?).
And this function is too big to be inline.
^ 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