* Re: 8xx spi completion sometime doesn't generate an interrupt
From: Antonio Di Bacco @ 2006-06-02 22:21 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060602204540.BE50D353A57@atlas.denx.de>
> Yes, this is known problem, especially if you are runnign the SPI bus
> with higher data transfer rates and/or high CPM load ....
I lowered the SPI bus frequency, the interrupt is now always happening but I
have always problems.
I did further investigations, I'm doing spi transfers of 256 bytes both
writing and reading (256 is the size of a page of the chip). I write one time
and then read two times the complete 8Mbit chip. The two reading give me
always the same result, then, the writing is failing in my case. Probably I
have to double check the writing procedure. But it is also worth to note that
changing the PM (prescaler module) and lowering the SPI clock even more the
writing problem is happening less frequently.
Thank you,
Bye,
Antonio.
^ permalink raw reply
* Re: [PATCH 2.6.16.16] sata_sil24: SII3124 sata driver endian problem
From: Andrew Morton @ 2006-06-02 23:30 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, Tejun Heo, jgarzik, linux-kernel, linux-ide
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B0189DE08@ismail.innsys.innovsys.com>
"Rune Torgersen" <runet@innovsys.com> wrote:
>
> > -----Original Message-----
> > From: Rune Torgersen
> > Sent: Thursday, June 01, 2006 16:10
> > To: linuxppc-dev@ozlabs.org
> > Subject: SII3124-2
> >
> > Has anybody been successful in getting a SII3124-2 based SATA
> > controller
> > to work under PPC?
> >
> > I have a eval board that I tried on two different freescale boards (a
> > MPC8266ADS board and a MPC8560ADS board).
> > Kernel 2.6.16.16.
> >
> > Here is the relevant output from the kernel.
> >
> > ata1: SATA max UDMA/100 cmd 0xD1010000 ctl 0x0 bmdma 0x0 irq 115
> > ata2: SATA max UDMA/100 cmd 0xD1012000 ctl 0x0 bmdma 0x0 irq 115
> > ata3: SATA max UDMA/100 cmd 0xD1014000 ctl 0x0 bmdma 0x0 irq 115
> > ata4: SATA max UDMA/100 cmd 0xD1016000 ctl 0x0 bmdma 0x0 irq 115
> > ata1: SATA link down (SStatus 0)
> > scsi0 : sata_sil24
> > ata2: SATA link up 3.0 Gbps (SStatus 123)
> > sata_sil24 ata2: SRST failed, disabling port
> > scsi1 : sata_sil24
> > ata3: SATA link down (SStatus 0)
> > scsi2 : sata_sil24
> > ata4: SATA link down (SStatus 0)
> > scsi3 : sata_sil24
> >
> > I added debug output to see the content of the Command Error register.
> > It is set to 26 which according to the datasheet for the 3124-1 (I am
> > running a -2), is PLDCMDERRORMASTERABORT, "A PCI Master Abort occurred
> > while the SiI3124 was fetching a Port Request Block (PRB) from host
> > memory."
>
> There is an endian issue in the sil24 driver.
> The follwing pathc seems to fix it for me. (it is also attached in case
> the mailer borks it for me)
>
> Signed-off-by: Rune Torgersen <runet@innovsys.com>
>
> Index: linux-innsys-2.6.16.16/drivers/scsi/sata_sil24.c
> ===================================================================
> --- linux-innsys-2.6.16.16/drivers/scsi/sata_sil24.c (revision 101)
> +++ linux-innsys-2.6.16.16/drivers/scsi/sata_sil24.c (working copy)
> @@ -446,7 +446,7 @@
> */
> msleep(10);
>
> - prb->ctrl = PRB_CTRL_SRST;
> + prb->ctrl = cpu_to_le16(PRB_CTRL_SRST);
> prb->fis[1] = 0; /* no PM yet */
>
> writel((u32)paddr, port + PORT_CMD_ACTIVATE);
> @@ -537,9 +537,9 @@
>
> if (qc->tf.protocol != ATA_PROT_ATAPI_NODATA) {
> if (qc->tf.flags & ATA_TFLAG_WRITE)
> - prb->ctrl = PRB_CTRL_PACKET_WRITE;
> + prb->ctrl =
> cpu_to_le16(PRB_CTRL_PACKET_WRITE);
> else
> - prb->ctrl = PRB_CTRL_PACKET_READ;
> + prb->ctrl =
> cpu_to_le16(PRB_CTRL_PACKET_READ);
> } else
> prb->ctrl = 0;
>
This bug has been fixed in the current libata development tree.
This bug is present in 2.6.16 and is present in 2.6.17-rc. Probably we
should merge Rune's above patch into Linus's tree and into 2.6.16.x.
Jeff ack?
^ permalink raw reply
* Re: USB on MPC8349 with MPH controller
From: Randy Vinson @ 2006-06-02 23:02 UTC (permalink / raw)
To: almoeli; +Cc: linuxppc-embedded
In-Reply-To: <447FFD1E.6030208@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]
almoeli@gmx.de wrote:
> Hi,
>
> im using kernel 2.6.16.18 with the ehci-fsl and a patch from this list
> to get USB working.
> So SCCR and SICRL register are set correctly.
> The external connected PHY is a SMSC 3300-EZK which has an ULPI interface.
> If I configure the USB controller of the MPC8349 to use the DR
> controller, port 1 can be used with low, full and high speed devices
> without any errors.
> But if the USB controller is switched to MPH, the port 0 and port 1
> cannot read the device descriptor.
> Error message is:
>
> fsl-usb2-mph: devpath1 ep0in 3strikes
> fsl-usb2-mph: devpath1 ep0in 3strikes
> fsl-usb2-mph: devpath1 ep0in 3strikes
> usb1-1: device decriptor read/64, error -71
>
> Does anyone know this problem or knows a solution?
The 8349 has quirk regarding the port numbering in its queues. The attached patch may resolve your problems. This patch was taken from the powerpc.git tree at git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
Randy Vinson
MontaVista Software
[-- Attachment #2: 834x_usb_quirk.patch --]
[-- Type: text/plain, Size: 3084 bytes --]
commit 8cd42e97bf451bbbb2f54dc571366ae5a72faaea
Author: Kumar Gala <galak@gate.crashing.org>
Date: Fri Jan 20 13:57:52 2006 -0800
[PATCH] USB: EHCI and Freescale 83xx quirk
On the MPC834x processors the multiport host (MPH) EHCI controller has an
erratum in which the port number in the queue head expects to be 0..N-1
instead of 1..N. If we are on one of these chips we subtract one from
the port number before putting it into the queue head.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index c6012d6..59f90f7 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -198,6 +198,16 @@ static void mpc83xx_usb_setup(struct usb
mpc83xx_setup_phy(ehci, pdata->phy_mode, 0);
if (pdata->operating_mode == FSL_USB2_MPH_HOST) {
+ unsigned int chip, rev, svr;
+
+ svr = mfspr(SPRN_SVR);
+ chip = svr >> 16;
+ rev = (svr >> 4) & 0xf;
+
+ /* Deal with USB Erratum #14 on MPC834x Rev 1.0 & 1.1 chips */
+ if ((rev == 1) && (chip >= 0x8050) && (chip <= 0x8055))
+ ehci->has_fsl_port_bug = 1;
+
if (pdata->port_enables & FSL_USB2_PORT0_ENABLED)
mpc83xx_setup_phy(ehci, pdata->phy_mode, 0);
if (pdata->port_enables & FSL_USB2_PORT1_ENABLED)
diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
index 9b13bf2..6e28e59 100644
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -721,7 +721,14 @@ qh_make (
info1 |= maxp << 16;
info2 |= (EHCI_TUNE_MULT_TT << 30);
- info2 |= urb->dev->ttport << 23;
+
+ /* Some Freescale processors have an erratum in which the
+ * port number in the queue head was 0..N-1 instead of 1..N.
+ */
+ if (ehci_has_fsl_portno_bug(ehci))
+ info2 |= (urb->dev->ttport-1) << 23;
+ else
+ info2 |= urb->dev->ttport << 23;
/* set the address of the TT; for TDI's integrated
* root hub tt, leave it zeroed.
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index 86af41c..679c1cd 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -88,8 +88,11 @@ #define DEFAULT_I_TDPS 1024 /* some HC
unsigned long next_statechange;
u32 command;
+ /* SILICON QUIRKS */
unsigned is_tdi_rh_tt:1; /* TDI roothub with TT */
unsigned no_selective_suspend:1;
+ unsigned has_fsl_port_bug:1; /* FreeScale */
+
u8 sbrn; /* packed release number */
/* irq statistics */
@@ -639,6 +642,18 @@ #endif
/*-------------------------------------------------------------------------*/
+#ifdef CONFIG_PPC_83xx
+/* Some Freescale processors have an erratum in which the TT
+ * port number in the queue head was 0..N-1 instead of 1..N.
+ */
+#define ehci_has_fsl_portno_bug(e) ((e)->has_fsl_port_bug)
+#else
+#define ehci_has_fsl_portno_bug(e) (0)
+#endif
+
+
+/*-------------------------------------------------------------------------*/
+
#ifndef DEBUG
#define STUB_DEBUG_FILES
#endif /* DEBUG */
^ permalink raw reply related
* Re: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Benjamin Herrenschmidt @ 2006-06-03 0:36 UTC (permalink / raw)
To: Kumar Gala
Cc: Alexandre.Bounine, Liu Dave-r63238, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390
In-Reply-To: <259AC268-6D75-4EEF-962E-BDBC6D76BC02@kernel.crashing.org>
On Fri, 2006-06-02 at 09:50 -0500, Kumar Gala wrote:
> On Jun 2, 2006, at 3:20 AM, Zang Roy-r61911 wrote:
>
> >
> >> How much RAM do you have ? Maybe you are running out of
> >> virtual space ?
> >>
> >> Ben.
> >>
> >>
> >
> > 512MBytes
>
> If I understand things, there is a 16M region for PCI config space.
> You could look at just doing the ioremap for each chunk when its
> needed via the low level calls.
PCI config access is called with locks held, it can't ioremap.
Ben.
^ permalink raw reply
* Re: [PATCH] [2.6.18] U4 DART improvements
From: Benjamin Herrenschmidt @ 2006-06-03 0:40 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Olof Johansson, linuxppc-dev, paulus
In-Reply-To: <61e1e9d0ada7e9648b8590cfac2b67b9@kernel.crashing.org>
On Fri, 2006-06-02 at 14:44 +0200, Segher Boessenkool wrote:
> Hi Olof,
>
> Looks good. One request:
>
> > +static inline void dart_tlb_invalidate_one(unsigned long bus_rpn)
> > +{
> > + unsigned int reg;
> > + unsigned int l, limit;
> > +
> > + reg = DART_CNTL_U4_ENABLE | DART_CNTL_U4_IONE |
> > + (bus_rpn & DART_CNTL_U4_IONE_MASK);
> > + DART_OUT(DART_CNTL, reg);
> > + mb();
>
> Could you please comment the memory barriers, to say exactly _why_ a
> certain barrier is needed? I can't see why wmb() wouldn't work here,
> for example (note I'm not saying it would -- I just don't see why it
> wouldn't).
>
> Same goes for every single memory barrier in the whole kernel source
> code, but I have to start somewhere, heh.
In fact I doubt we need a barrier at all...
Ben.
^ permalink raw reply
* Re: 8xx spi completion sometime doesn't generate an interrupt
From: Wolfgang Denk @ 2006-06-03 0:51 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200606030021.58892.antonio.dibacco@aruba.it>
In message <200606030021.58892.antonio.dibacco@aruba.it> you wrote:
>
> I lowered the SPI bus frequency, the interrupt is now always happening but I
> have always problems.
Try reducing the CPM load. If you have a serial console on a SMC,
shut it off, etc. Then try again (usually it will be better).
> have to double check the writing procedure. But it is also worth to note that
> changing the PM (prescaler module) and lowering the SPI clock even more the
> writing problem is happening less frequently.
Yeah. At a SPI clock of 0 no errors will happen. The problem is, that
this is not too much useful either ;-)
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Contrary to popular belief, thinking does not cause brain damage.
^ permalink raw reply
* Re: [PATCH] [2.6.18] U4 DART improvements
From: Olof Johansson @ 2006-06-03 3:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <1149295238.7972.12.camel@localhost.localdomain>
On Sat, Jun 03, 2006 at 10:40:38AM +1000, Benjamin Herrenschmidt wrote:
> In fact I doubt we need a barrier at all...
Yeah, I'm not sure what I was thinking. There's need for a barrier
before the invalidation to make sure that a stale entry doesn't get
re-entered into the TLB, and it's already done before the call. I have
no good explanation for why I added that one.
I'll respin, test and repost the patch tomorrow.
-Olof
^ permalink raw reply
* m25pe80 dataflash: put 50 usec between WREN and PW instructions
From: Antonio Di Bacco @ 2006-06-03 8:10 UTC (permalink / raw)
To: linuxppc-embedded
I'm using a m25pe80 8Mbit spi dataflash. The PW (Page write) instruction is
preceded by a WREN instruction but be careful to insert a delay between WREN
and PW otherwise some page couldn't be written. I hope could help someone.
Bye,
Antonio.
^ permalink raw reply
* Making Two ethernet interfaces up in Linux
From: Shantanu Nalage @ 2006-06-03 11:38 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
We are trying to port Linux on Xilinx Board XUPV2Pro which is
similar in most aspects to the Xilinx ML300 board. Linux is up and
running for the original board i.e. having only one ethrnet interface.
Now since we wanted to have the board working as router, we designed a
daughter board with two ethernet phy interfaces. The MACs required for
that are instantiated in Xilinx and corresponding Board support
Packages are also created in Xilinx.
What all changes are required to make both the interfaces
visible in Linux?
Thank you in anticipation.
With regards,
Shantanu.
^ permalink raw reply
* Re: Making Two ethernet interfaces up in Linux
From: Antonio Di Bacco @ 2006-06-03 20:55 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Shantanu Nalage
In-Reply-To: <c91756f0606030438y62772d89ib43f613cd5373739@mail.gmail.com>
> We are trying to port Linux on Xilinx Board XUPV2Pro which is
> similar in most aspects to the Xilinx ML300 board. Linux is up and
> running for the original board i.e. having only one ethrnet interface.
> Now since we wanted to have the board working as router, we designed a
> daughter board with two ethernet phy interfaces. The MACs required for
> that are instantiated in Xilinx ....
You have already the driver for the first MAC, then you should start from that
modifying the init procedure for example and all the others. Your driver
should initialize both the MACs and also create two devices calling
init_etherdev tow times. If you post your driver I can suggest what to
change. It is not so difficult.
Bye,
Antonio.
^ permalink raw reply
* Re: [PATCH 2.6.16.16] sata_sil24: SII3124 sata driver endian problem
From: Alexey Dobriyan @ 2006-06-04 16:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: Tejun Heo, linux-ide, linux-kernel, linuxppc-dev, jgarzik
In-Reply-To: <20060602163035.05ab7c71.akpm@osdl.org>
On Fri, Jun 02, 2006 at 04:30:35PM -0700, Andrew Morton wrote:
> > There is an endian issue in the sil24 driver.
> > The follwing pathc seems to fix it for me. (it is also attached in case
> > the mailer borks it for me)
> >
> > Signed-off-by: Rune Torgersen <runet@innovsys.com>
> >
> > Index: linux-innsys-2.6.16.16/drivers/scsi/sata_sil24.c
> > ===================================================================
> > --- linux-innsys-2.6.16.16/drivers/scsi/sata_sil24.c (revision 101)
> > +++ linux-innsys-2.6.16.16/drivers/scsi/sata_sil24.c (working copy)
> > @@ -446,7 +446,7 @@
> > */
> > msleep(10);
> >
> > - prb->ctrl = PRB_CTRL_SRST;
> > + prb->ctrl = cpu_to_le16(PRB_CTRL_SRST);
> > prb->fis[1] = 0; /* no PM yet */
> >
> > writel((u32)paddr, port + PORT_CMD_ACTIVATE);
> > @@ -537,9 +537,9 @@
> >
> > if (qc->tf.protocol != ATA_PROT_ATAPI_NODATA) {
> > if (qc->tf.flags & ATA_TFLAG_WRITE)
> > - prb->ctrl = PRB_CTRL_PACKET_WRITE;
> > + prb->ctrl =
> > cpu_to_le16(PRB_CTRL_PACKET_WRITE);
> > else
> > - prb->ctrl = PRB_CTRL_PACKET_READ;
> > + prb->ctrl =
> > cpu_to_le16(PRB_CTRL_PACKET_READ);
Are there some other fields that should be marked?
[PATCH] sata_sil24: endian annotations
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
drivers/scsi/sata_sil24.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
--- a/drivers/scsi/sata_sil24.c
+++ b/drivers/scsi/sata_sil24.c
@@ -37,7 +37,7 @@
* Port request block (PRB) 32 bytes
*/
struct sil24_prb {
- u16 ctrl;
+ __le16 ctrl;
u16 prot;
u32 rx_cnt;
u8 fis[6 * 4];
@@ -47,9 +47,9 @@ struct sil24_prb {
* Scatter gather entry (SGE) 16 bytes
*/
struct sil24_sge {
- u64 addr;
- u32 cnt;
- u32 flags;
+ __le64 addr;
+ __le32 cnt;
+ __le32 flags;
};
/*
^ permalink raw reply
* Re: [PATCH 2.6.16.16] sata_sil24: SII3124 sata driver endian problem
From: Tejun Heo @ 2006-06-04 20:24 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: Andrew Morton, linux-ide, linux-kernel, linuxppc-dev, jgarzik
In-Reply-To: <20060604161124.GA7587@martell.zuzino.mipt.ru>
Alexey Dobriyan wrote:
> Are there some other fields that should be marked?
Yeap, prot and rx_cnt of sil24_prb should also be marked __le. Also,
all fields of sil24_port_multiplier
Thanks.
> [PATCH] sata_sil24: endian annotations
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> ---
>
> drivers/scsi/sata_sil24.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> --- a/drivers/scsi/sata_sil24.c
> +++ b/drivers/scsi/sata_sil24.c
> @@ -37,7 +37,7 @@
> * Port request block (PRB) 32 bytes
> */
> struct sil24_prb {
> - u16 ctrl;
> + __le16 ctrl;
> u16 prot;
> u32 rx_cnt;
> u8 fis[6 * 4];
> @@ -47,9 +47,9 @@ struct sil24_prb {
> * Scatter gather entry (SGE) 16 bytes
> */
> struct sil24_sge {
> - u64 addr;
> - u32 cnt;
> - u32 flags;
> + __le64 addr;
> + __le32 cnt;
> + __le32 flags;
> };
>
> /*
--
tejun
^ permalink raw reply
* Re: snd-aoa: using feature calls for GPIOs
From: Benjamin Herrenschmidt @ 2006-06-05 3:11 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <1149187342.7875.9.camel@johannes>
> Anyway, I'm sure I'm doing something stupid in there and just can't find
> it, I even 'disassembled' all the platform functions I have to see what
> happens in them, and they also write 0 or 1 just like the code below...
> Maybe I got some offsets wrong?
The platform function write bit 0 of the register only afaik. Bit 0x4 is
"output enable" so if you clear it, your GPIOs won't do much :)
Also, bit 0x2 is the input data, though it's only useful if "output
enable" is cleared (or it will just reflect the state of the outputs).
Forget about what snd-powermac does, it's bogus anyway.
Ben.
> --- snd-aoa.orig/aoa.h 2006-06-01 20:29:56.252070199 +0200
> +++ snd-aoa/aoa.h 2006-06-01 20:31:03.972070199 +0200
> @@ -125,6 +125,7 @@ extern int aoa_snd_ctl_add(struct snd_kc
>
> /* GPIO stuff */
> extern struct gpio_methods *pmf_gpio_methods;
> +extern struct gpio_methods *ftr_gpio_methods;
> /* extern struct gpio_methods *map_gpio_methods; */
>
> #endif /* __AOA_H */
> --- snd-aoa.orig/core/Makefile 2006-06-01 20:29:56.252070199 +0200
> +++ snd-aoa/core/Makefile 2006-06-01 20:31:03.972070199 +0200
> @@ -1,4 +1,5 @@
> obj-$(CONFIG_SND_AOA) += snd-aoa.o
> snd-aoa-objs := snd-aoa-core.o \
> snd-aoa-alsa.o \
> - snd-aoa-gpio-pmf.o
> + snd-aoa-gpio-pmf.o \
> + snd-aoa-gpio-feature.o
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ snd-aoa/core/snd-aoa-gpio-feature.c 2006-06-01 20:31:03.992070199 +0200
> @@ -0,0 +1,322 @@
> +/*
> + * Apple Onboard Audio feature call GPIO control
> + *
> + * Copyright 2006 Johannes Berg <johannes@sipsolutions.net>
> + *
> + * GPL v2, can be found in COPYING.
> + */
> +
> +#include <asm/pmac_feature.h>
> +#include <linux/interrupt.h>
> +#include "../aoa.h"
> +
> +static int headphone_mute_gpio;
> +static int amp_mute_gpio;
> +static int lineout_mute_gpio;
> +static int hw_reset_gpio;
> +static int lineout_detect_gpio;
> +static int headphone_detect_gpio;
> +static int linein_detect_gpio;
> +
> +static int headphone_mute_gpio_activestate;
> +static int amp_mute_gpio_activestate;
> +static int lineout_mute_gpio_activestate;
> +static int hw_reset_gpio_activestate;
> +static int lineout_detect_gpio_activestate;
> +static int headphone_detect_gpio_activestate;
> +static int linein_detect_gpio_activestate;
> +
> +static int lineout_detect_irq;
> +static int linein_detect_irq;
> +static int headphone_detect_irq;
> +
> +static void get_gpio(char *name, int *gpioptr, int *gpioactiveptr)
> +{
> + struct device_node *np;
> + u32 *reg;
> +
> + *gpioptr = -1;
> +
> + np = of_find_node_by_name(NULL, name);
> + if (!np)
> + return;
> +
> + reg = (u32 *)get_property(np, "reg", NULL);
> + if (!reg)
> + return;
> +
> + *gpioptr = *reg;
> +
> + /* this is a hack, usually the GPIOs 'reg' property
> + * should have the offset based from the GPIO space
> + * which is at 0x50, but apparently not always... */
> + if (*gpioptr < 0x50)
> + *gpioptr += 0x50;
> +
> + reg = (u32 *)get_property(np, "audio-gpio-active-state", NULL);
> + if (!reg)
> + *gpioactiveptr = 1;
> + else
> + *gpioactiveptr = *reg;
> +
> + printk(KERN_DEBUG "gpio %s = %d (active = %d)\n", name, *gpioptr, *gpioactiveptr);
> +}
> +
> +static void get_irq(char *name, int *irqptr)
> +{
> + struct device_node *np;
> +
> + *irqptr = -1;
> + np = of_find_node_by_name(NULL, name);
> + if (!np)
> + return;
> + if (np->n_intrs != 1)
> + return;
> + *irqptr = np->intrs[0].line;
> +
> + printk(KERN_DEBUG "got %s irq = %d\n", name, *irqptr);
> +}
> +
> +#define SWITCH_GPIO(name, on) \
> + ((on)?(name##_gpio_activestate==0?0:1):(name##_gpio_activestate==0?1:0))
> +
> +#define FTR_GPIO(name, bit) \
> +static void ftr_gpio_set_##name(struct gpio_runtime *rt, int on)\
> +{ \
> + if (unlikely(!rt)) return; \
> + \
> + if (name##_mute_gpio < 0) \
> + return; \
> + \
> + pmac_call_feature(PMAC_FTR_WRITE_GPIO, NULL, \
> + name##_mute_gpio, \
> + SWITCH_GPIO(name##_mute, on)); \
> + \
> + rt->implementation_private &= ~(1<<bit); \
> + rt->implementation_private |= (!!on << bit); \
> +} \
> +static int ftr_gpio_get_##name(struct gpio_runtime *rt) \
> +{ \
> + if (unlikely(!rt)) return 0; \
> + return (rt->implementation_private>>bit)&1; \
> +}
> +
> +FTR_GPIO(headphone, 0);
> +FTR_GPIO(amp, 1);
> +FTR_GPIO(lineout, 2);
> +
> +static void ftr_gpio_set_hw_reset(struct gpio_runtime *rt, int on)
> +{
> + if (unlikely(!rt)) return;
> + if (hw_reset_gpio < 0)
> + return;
> +
> + pmac_call_feature(PMAC_FTR_WRITE_GPIO, NULL,
> + hw_reset_gpio, SWITCH_GPIO(hw_reset, on));
> +}
> +
> +static void ftr_gpio_all_amps_off(struct gpio_runtime *rt)
> +{
> + int saved;
> +
> + if (unlikely(!rt)) return;
> + saved = rt->implementation_private;
> + ftr_gpio_set_headphone(rt, 0);
> + ftr_gpio_set_amp(rt, 0);
> + ftr_gpio_set_lineout(rt, 0);
> + rt->implementation_private = saved;
> +}
> +
> +static void ftr_gpio_all_amps_restore(struct gpio_runtime *rt)
> +{
> + int s;
> +
> + if (unlikely(!rt)) return;
> + s = rt->implementation_private;
> + ftr_gpio_set_headphone(rt, (s>>0)&1);
> + ftr_gpio_set_amp(rt, (s>>1)&1);
> + ftr_gpio_set_lineout(rt, (s>>2)&1);
> +}
> +
> +static void ftr_handle_notify(void *data)
> +{
> + struct gpio_notification *notif = data;
> +
> + mutex_lock(¬if->mutex);
> + if (notif->notify)
> + notif->notify(notif->data);
> + mutex_unlock(¬if->mutex);
> +}
> +
> +static void ftr_gpio_init(struct gpio_runtime *rt)
> +{
> + get_gpio("headphone-mute", &headphone_mute_gpio,
> + &headphone_mute_gpio_activestate);
> + get_gpio("amp-mute", &_mute_gpio,
> + &_mute_gpio_activestate);
> + get_gpio("lineout-mute", &lineout_mute_gpio,
> + &lineout_mute_gpio_activestate);
> + get_gpio("hw-reset", &hw_reset_gpio,
> + &hw_reset_gpio_activestate);
> + get_gpio("headphone-detect", &headphone_detect_gpio,
> + &headphone_detect_gpio_activestate);
> + get_gpio("lineout-detect", &lineout_detect_gpio,
> + &lineout_detect_gpio_activestate);
> + get_gpio("linein-detect", &linein_detect_gpio,
> + &linein_detect_gpio_activestate);
> +
> + get_irq("headphone-detect", &headphone_detect_irq);
> + get_irq("lineout-detect", &lineout_detect_irq);
> + get_irq("linein-detect", &linein_detect_irq);
> +
> + ftr_gpio_all_amps_off(rt);
> + rt->implementation_private = 0;
> + INIT_WORK(&rt->headphone_notify.work, ftr_handle_notify, &rt->headphone_notify);
> + INIT_WORK(&rt->line_in_notify.work, ftr_handle_notify, &rt->line_in_notify);
> + INIT_WORK(&rt->line_out_notify.work, ftr_handle_notify, &rt->line_out_notify);
> + mutex_init(&rt->headphone_notify.mutex);
> + mutex_init(&rt->line_in_notify.mutex);
> + mutex_init(&rt->line_out_notify.mutex);
> +}
> +
> +static void ftr_gpio_exit(struct gpio_runtime *rt)
> +{
> + ftr_gpio_all_amps_off(rt);
> + rt->implementation_private = 0;
> + if (rt->headphone_notify.notify)
> + free_irq(headphone_detect_irq, &rt->headphone_notify);
> + if (rt->line_in_notify.gpio_private)
> + free_irq(linein_detect_irq, &rt->line_in_notify);
> + if (rt->line_out_notify.gpio_private)
> + free_irq(lineout_detect_irq, &rt->line_out_notify);
> + cancel_delayed_work(&rt->headphone_notify.work);
> + cancel_delayed_work(&rt->line_in_notify.work);
> + cancel_delayed_work(&rt->line_out_notify.work);
> + flush_scheduled_work();
> + mutex_destroy(&rt->headphone_notify.mutex);
> + mutex_destroy(&rt->line_in_notify.mutex);
> + mutex_destroy(&rt->line_out_notify.mutex);
> +}
> +
> +irqreturn_t ftr_handle_notify_irq(int xx, void *data, struct pt_regs *regs)
> +{
> + struct gpio_notification *notif = data;
> +
> + schedule_work(¬if->work);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int ftr_set_notify(struct gpio_runtime *rt,
> + enum notify_type type,
> + notify_func_t notify,
> + void *data)
> +{
> + struct gpio_notification *notif;
> + notify_func_t old;
> + int irq;
> + char *name;
> + int err = -EBUSY;
> +
> + switch (type) {
> + case AOA_NOTIFY_HEADPHONE:
> + notif = &rt->headphone_notify;
> + name = "headphone-detect";
> + irq = headphone_detect_irq;
> + break;
> + case AOA_NOTIFY_LINE_IN:
> + notif = &rt->line_in_notify;
> + name = "linein-detect";
> + irq = linein_detect_irq;
> + break;
> + case AOA_NOTIFY_LINE_OUT:
> + notif = &rt->line_out_notify;
> + name = "lineout-detect";
> + irq = lineout_detect_irq;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + if (irq == -1)
> + return -ENODEV;
> +
> + mutex_lock(¬if->mutex);
> +
> + old = notif->notify;
> +
> + if (!old && !notify) {
> + err = 0;
> + goto out_unlock;
> + }
> +
> + if (old && notify) {
> + if (old == notify && notif->data == data)
> + err = 0;
> + goto out_unlock;
> + }
> +
> + if (old && !notify) {
> + free_irq(irq, notif);
> + }
> + if (!old && notify) {
> + request_irq(irq, ftr_handle_notify_irq, 0, name, notif);
> + }
> + notif->notify = notify;
> + notif->data = data;
> +
> + err = 0;
> + out_unlock:
> + mutex_unlock(¬if->mutex);
> + return err;
> +}
> +
> +static int ftr_get_detect(struct gpio_runtime *rt,
> + enum notify_type type)
> +{
> + int gpio, ret, active;
> +
> + switch (type) {
> + case AOA_NOTIFY_HEADPHONE:
> + gpio = headphone_detect_gpio;
> + active = headphone_detect_gpio_activestate;
> + break;
> + case AOA_NOTIFY_LINE_IN:
> + gpio = linein_detect_gpio;
> + active = linein_detect_gpio_activestate;
> + break;
> + case AOA_NOTIFY_LINE_OUT:
> + gpio = lineout_detect_gpio;
> + active = lineout_detect_gpio_activestate;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + if (gpio == -1)
> + return -ENODEV;
> +
> + ret = pmac_call_feature(PMAC_FTR_READ_GPIO, NULL, gpio, 0);
> + if (ret < 0)
> + return ret;
> + return ((ret >> 1) & 1) == active;
> +}
> +
> +static struct gpio_methods methods = {
> + .init = ftr_gpio_init,
> + .exit = ftr_gpio_exit,
> + .all_amps_off = ftr_gpio_all_amps_off,
> + .all_amps_restore = ftr_gpio_all_amps_restore,
> + .set_headphone = ftr_gpio_set_headphone,
> + .set_speakers = ftr_gpio_set_amp,
> + .set_lineout = ftr_gpio_set_lineout,
> + .set_hw_reset = ftr_gpio_set_hw_reset,
> + .get_headphone = ftr_gpio_get_headphone,
> + .get_speakers = ftr_gpio_get_amp,
> + .get_lineout = ftr_gpio_get_lineout,
> + .set_notify = ftr_set_notify,
> + .get_detect = ftr_get_detect,
> +};
> +
> +struct gpio_methods *ftr_gpio_methods = &methods;
> +EXPORT_SYMBOL_GPL(ftr_gpio_methods);
>
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 8/10] Add tsi108 8250 serial support
From: Russell King @ 2006-06-05 10:04 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: Alexandre.Bounine, linux-kernel, linuxppc-dev list,
Paul Mackerras, linux-serial, Yang Xin-Xin-r48390
In-Reply-To: <9FCDBA58F226D911B202000BDBAD46730626DE5A@zch01exm40.ap.freescale.net>
On Thu, May 18, 2006 at 12:00:43PM +0800, Zang Roy-r61911 wrote:
>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: 2006???5???17??? 21:26
> To: Zang Roy-r61911
> Cc: Paul Mackerras; linuxppc-dev list; Alexandre.Bounine@tundra.com; Yang Xin-Xin-r48390
> Subject: Re: [PATCH/2.6.17-rc4 8/10] Add tsi108 8250 serial support
>
>
>
> On May 17, 2006, at 5:14 AM, Zang Roy-r61911 wrote:
>
> > This patch contains changes to the serial device driver specific
> > for integrated
> > serial port in Tsi108 Host Bridge.
There's no explaination about why this is required. What is the problem?
Which changes relate directly to this problem and which changes are
related to fixing some other issue not related to the errata?
Plus, every patch line is prefixed by "> "... patch doesn't like that.
> >
> > Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
> > Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> >
> >> From nobody Mon Sep 17 00:00:00 2001
> > From: roy zang <tie-fei.zang@freescale.com>
> > Date: Tue May 16 15:26:02 2006 +0800
> > Subject: [PATCH] Add tsi108 serial support
>
> This patch needs to go to Russell King as uart/8250 driver maintainer.
>
> - kumar
>
> >
> > ---
> >
> > drivers/serial/8250.c | 17 +++++++++++++++++
> > 1 files changed, 17 insertions(+), 0 deletions(-)
> >
> > 6cb950357e9970afa671d59f172dbc4b03f11560
> > diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
> > index bbf78aa..c12f516 100644
> > --- a/drivers/serial/8250.c
> > +++ b/drivers/serial/8250.c
> > @@ -723,7 +723,9 @@ static int broken_efr(struct uart_8250_p
> > static void autoconfig_16550a(struct uart_8250_port *up)
> > {
> > unsigned char status1, status2;
> > +#ifndef CONFIG_TSI108_BRIDGE
> > unsigned int iersave;
> > +#endif
> >
> > up->port.type = PORT_16550A;
> > up->capabilities |= UART_CAP_FIFO;
> > @@ -833,6 +835,7 @@ static void autoconfig_16550a(struct uar
> > * trying to write and read a 1 just to make sure it's not
> > * already a 1 and maybe locked there before we even start start.
> > */
> > +#ifndef CONFIG_TSI108_BRIDGE
> > iersave = serial_in(up, UART_IER);
> > serial_outp(up, UART_IER, iersave & ~UART_IER_UUE);
> > if (!(serial_in(up, UART_IER) & UART_IER_UUE)) {
> > @@ -859,6 +862,7 @@ static void autoconfig_16550a(struct uar
> > DEBUG_AUTOCONF("Couldn't force IER_UUE to 0 ");
> > }
> > serial_outp(up, UART_IER, iersave);
> > +#endif
> > }
> >
> > /*
> > @@ -1348,7 +1352,12 @@ static irqreturn_t serial8250_interrupt(
> >
> > up = list_entry(l, struct uart_8250_port, list);
> >
> > +#ifdef CONFIG_TSI108_BRIDGE /* for TSI108_REV_Z1 errata U2 */
> > + /* read IIR as part of 32-bit word */
> > + iir = (in_be32((u32 *)(up->port.membase + UART_RX)) >> 8) & 0xff;
> > +#else
> > iir = serial_in(up, UART_IIR);
> > +#endif
> > if (!(iir & UART_IIR_NO_INT)) {
> > serial8250_handle_port(up, regs);
> >
> > @@ -1529,7 +1538,9 @@ static int serial8250_startup(struct uar
> > {
> > struct uart_8250_port *up = (struct uart_8250_port *)port;
> > unsigned long flags;
> > +#ifndef CONFIG_TSI108_BRIDGE
> > unsigned char lsr, iir;
> > +#endif
> > int retval;
> >
> > up->capabilities = uart_config[up->port.type].flags;
> > @@ -1567,7 +1578,9 @@ #endif
> > */
> > (void) serial_inp(up, UART_LSR);
> > (void) serial_inp(up, UART_RX);
> > +#ifndef CONFIG_TSI108_BRIDGE /* for TSI108_REV_Z1 errata U2 */
> > (void) serial_inp(up, UART_IIR);
> > +#endif
> > (void) serial_inp(up, UART_MSR);
> >
> > /*
> > @@ -1634,6 +1647,7 @@ #endif
> >
> > serial8250_set_mctrl(&up->port, up->port.mctrl);
> >
> > +#ifndef CONFIG_TSI108_BRIDGE
> > /*
> > * Do a quick test to see if we receive an
> > * interrupt when we enable the TX irq.
> > @@ -1652,6 +1666,7 @@ #endif
> > } else {
> > up->bugs &= ~UART_BUG_TXEN;
> > }
> > +#endif
> >
> > spin_unlock_irqrestore(&up->port.lock, flags);
> >
> > @@ -1678,7 +1693,9 @@ #endif
> > */
> > (void) serial_inp(up, UART_LSR);
> > (void) serial_inp(up, UART_RX);
> > +#ifndef CONFIG_TSI108_BRIDGE /* for TSI108_REV_Z1 errata U2 */
> > (void) serial_inp(up, UART_IIR);
> > +#endif
> > (void) serial_inp(up, UART_MSR);
> >
> > return 0;
> > --
> > 1.3.0
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: snd-aoa: using feature calls for GPIOs
From: Johannes Berg @ 2006-06-05 12:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1149477113.8543.1.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 557 bytes --]
On Mon, 2006-06-05 at 13:11 +1000, Benjamin Herrenschmidt wrote:
> The platform function write bit 0 of the register only afaik. Bit 0x4 is
> "output enable" so if you clear it, your GPIOs won't do much :)
Aha! Yes, I had read the code wrongly, I figured the pmfs only wrote but
in fact there's a read/mask too. Thanks :)
> Also, bit 0x2 is the input data, though it's only useful if "output
> enable" is cleared (or it will just reflect the state of the outputs).
Yeah ok, I'll change/retest the patch during the week.
Thanks,
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Matthew McClintock @ 2006-06-05 20:41 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20060522222227.GR32112@smtp.west.cox.net>
On Mon, 2006-05-22 at 15:22 -0700, Tom Rini wrote:
> And on all architectures (practically) the zlib inflate code is shared
> between kernel and bootstuff. So it's not unprecidented to do the
> ugly
> define abstractions to let you easily share code as needed.
Could you point me at the code you are referring too?
Thanks,
Matthew
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Tom Rini @ 2006-06-05 21:04 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1149540113.8317.93.camel@localhost.localdomain>
On Mon, Jun 05, 2006 at 03:41:53PM -0500, Matthew McClintock wrote:
> On Mon, 2006-05-22 at 15:22 -0700, Tom Rini wrote:
> > And on all architectures (practically) the zlib inflate code is shared
> > between kernel and bootstuff. So it's not unprecidented to do the
> > ugly
> > define abstractions to let you easily share code as needed.
>
> Could you point me at the code you are referring too?
arch/powerpc/boot/Makefile
arch/ppc/boot/lib/Makefile
arch/xtensa/boot/lib/Makefile
And I could have sworn there were other arches (maybe in patches in
-mm?) that switched from lib/inflate.c to lib/zlib_inflate/
--
Tom Rini
^ permalink raw reply
* [PATCH] reorg RTAS delay code
From: John Rose @ 2006-06-05 21:31 UTC (permalink / raw)
To: Nathan Lynch; +Cc: Paul Mackerras, External List
In-Reply-To: <20060602213308.GP8934@localdomain>
This patch attempts to handle RTAS "busy" return codes in a more simple
and consistent manner. Typical callers of RTAS shouldn't have to
manage wait times and delay calls.
This patch also changes the kernel to use msleep() rather than udelay()
when a runtime delay is necessary. This will avoid CPU soft lockups
for extended delay conditions.
Signed-off-by: John Rose <johnrose@austin.ibm.com>
---
Resend - added the suggested might_sleep() and braces.
Thanks-
John
2_6_linus-johnrose/arch/powerpc/kernel/rtas-rtc.c | 30 +++----
2_6_linus-johnrose/arch/powerpc/kernel/rtas.c | 85 ++++++++------------
2_6_linus-johnrose/arch/powerpc/kernel/rtas_flash.c | 25 -----
2_6_linus-johnrose/include/asm-powerpc/rtas.h | 8 -
4 files changed, 57 insertions(+), 91 deletions(-)
diff -puN arch/powerpc/kernel/rtas.c~rtas_delay_reorg arch/powerpc/kernel/rtas.c
--- 2_6_linus/arch/powerpc/kernel/rtas.c~rtas_delay_reorg 2006-06-02 15:09:43.000000000 -0500
+++ 2_6_linus-johnrose/arch/powerpc/kernel/rtas.c 2006-06-05 15:00:03.000000000 -0500
@@ -370,24 +370,36 @@ int rtas_call(int token, int nargs, int
return ret;
}
-/* Given an RTAS status code of 990n compute the hinted delay of 10^n
- * (last digit) milliseconds. For now we bound at n=5 (100 sec).
+/* For RTAS_BUSY (-2), delay for 1 millisecond. For an extended busy status
+ * code of 990n, perform the hinted delay of 10^n (last digit) milliseconds.
*/
-unsigned int rtas_extended_busy_delay_time(int status)
+unsigned int rtas_busy_delay_time(int status)
{
- int order = status - 9900;
- unsigned long ms;
+ int order;
+ unsigned int ms = 0;
- if (order < 0)
- order = 0; /* RTC depends on this for -2 clock busy */
- else if (order > 5)
- order = 5; /* bound */
+ if (status == RTAS_BUSY) {
+ ms = 1;
+ } else if (status >= 9900 && status <= 9905) {
+ order = status - 9900;
+ for (ms = 1; order > 0; order--)
+ ms *= 10;
+ }
+
+ return ms;
+}
+
+/* For an RTAS busy status code, perform the hinted delay. */
+unsigned int rtas_busy_delay(int status)
+{
+ unsigned int ms;
- /* Use microseconds for reasonable accuracy */
- for (ms = 1; order > 0; order--)
- ms *= 10;
+ might_sleep();
+ ms = rtas_busy_delay_time(status);
+ if (ms)
+ msleep(ms);
- return ms;
+ return ms;
}
int rtas_error_rc(int rtas_rc)
@@ -438,22 +450,14 @@ int rtas_get_power_level(int powerdomain
int rtas_set_power_level(int powerdomain, int level, int *setlevel)
{
int token = rtas_token("set-power-level");
- unsigned int wait_time;
int rc;
if (token == RTAS_UNKNOWN_SERVICE)
return -ENOENT;
- while (1) {
+ do {
rc = rtas_call(token, 2, 2, setlevel, powerdomain, level);
- if (rc == RTAS_BUSY)
- udelay(1);
- else if (rtas_is_extended_busy(rc)) {
- wait_time = rtas_extended_busy_delay_time(rc);
- udelay(wait_time * 1000);
- } else
- break;
- }
+ } while (rtas_busy_delay(rc));
if (rc < 0)
return rtas_error_rc(rc);
@@ -463,22 +467,14 @@ int rtas_set_power_level(int powerdomain
int rtas_get_sensor(int sensor, int index, int *state)
{
int token = rtas_token("get-sensor-state");
- unsigned int wait_time;
int rc;
if (token == RTAS_UNKNOWN_SERVICE)
return -ENOENT;
- while (1) {
+ do {
rc = rtas_call(token, 2, 2, state, sensor, index);
- if (rc == RTAS_BUSY)
- udelay(1);
- else if (rtas_is_extended_busy(rc)) {
- wait_time = rtas_extended_busy_delay_time(rc);
- udelay(wait_time * 1000);
- } else
- break;
- }
+ } while (rtas_busy_delay(rc));
if (rc < 0)
return rtas_error_rc(rc);
@@ -488,23 +484,14 @@ int rtas_get_sensor(int sensor, int inde
int rtas_set_indicator(int indicator, int index, int new_value)
{
int token = rtas_token("set-indicator");
- unsigned int wait_time;
int rc;
if (token == RTAS_UNKNOWN_SERVICE)
return -ENOENT;
- while (1) {
+ do {
rc = rtas_call(token, 3, 1, NULL, indicator, index, new_value);
- if (rc == RTAS_BUSY)
- udelay(1);
- else if (rtas_is_extended_busy(rc)) {
- wait_time = rtas_extended_busy_delay_time(rc);
- udelay(wait_time * 1000);
- }
- else
- break;
- }
+ } while (rtas_busy_delay(rc));
if (rc < 0)
return rtas_error_rc(rc);
@@ -555,13 +542,11 @@ void rtas_os_term(char *str)
do {
status = rtas_call(rtas_token("ibm,os-term"), 1, 1, NULL,
__pa(rtas_os_term_buf));
+ } while (rtas_busy_delay(status));
- if (status == RTAS_BUSY)
- udelay(1);
- else if (status != 0)
- printk(KERN_EMERG "ibm,os-term call failed %d\n",
+ if (status != 0)
+ printk(KERN_EMERG "ibm,os-term call failed %d\n",
status);
- } while (status == RTAS_BUSY);
}
static int ibm_suspend_me_token = RTAS_UNKNOWN_SERVICE;
@@ -789,7 +774,7 @@ EXPORT_SYMBOL(rtas_token);
EXPORT_SYMBOL(rtas_call);
EXPORT_SYMBOL(rtas_data_buf);
EXPORT_SYMBOL(rtas_data_buf_lock);
-EXPORT_SYMBOL(rtas_extended_busy_delay_time);
+EXPORT_SYMBOL(rtas_busy_delay_time);
EXPORT_SYMBOL(rtas_get_sensor);
EXPORT_SYMBOL(rtas_get_power_level);
EXPORT_SYMBOL(rtas_set_power_level);
diff -puN arch/powerpc/kernel/rtas-rtc.c~rtas_delay_reorg arch/powerpc/kernel/rtas-rtc.c
--- 2_6_linus/arch/powerpc/kernel/rtas-rtc.c~rtas_delay_reorg 2006-06-02 15:09:43.000000000 -0500
+++ 2_6_linus-johnrose/arch/powerpc/kernel/rtas-rtc.c 2006-06-02 15:09:43.000000000 -0500
@@ -14,19 +14,20 @@
unsigned long __init rtas_get_boot_time(void)
{
int ret[8];
- int error, wait_time;
+ int error;
+ unsigned int wait_time;
u64 max_wait_tb;
max_wait_tb = get_tb() + tb_ticks_per_usec * 1000 * MAX_RTC_WAIT;
do {
error = rtas_call(rtas_token("get-time-of-day"), 0, 8, ret);
- if (error == RTAS_CLOCK_BUSY || rtas_is_extended_busy(error)) {
- wait_time = rtas_extended_busy_delay_time(error);
+
+ wait_time = rtas_busy_delay_time(error);
+ if (wait_time) {
/* This is boot time so we spin. */
udelay(wait_time*1000);
- error = RTAS_CLOCK_BUSY;
}
- } while (error == RTAS_CLOCK_BUSY && (get_tb() < max_wait_tb));
+ } while (wait_time && (get_tb() < max_wait_tb));
if (error != 0 && printk_ratelimit()) {
printk(KERN_WARNING "error: reading the clock failed (%d)\n",
@@ -44,24 +45,25 @@ unsigned long __init rtas_get_boot_time(
void rtas_get_rtc_time(struct rtc_time *rtc_tm)
{
int ret[8];
- int error, wait_time;
+ int error;
+ unsigned int wait_time;
u64 max_wait_tb;
max_wait_tb = get_tb() + tb_ticks_per_usec * 1000 * MAX_RTC_WAIT;
do {
error = rtas_call(rtas_token("get-time-of-day"), 0, 8, ret);
- if (error == RTAS_CLOCK_BUSY || rtas_is_extended_busy(error)) {
+
+ wait_time = rtas_busy_delay_time(error);
+ if (wait_time) {
if (in_interrupt() && printk_ratelimit()) {
memset(rtc_tm, 0, sizeof(struct rtc_time));
printk(KERN_WARNING "error: reading clock"
" would delay interrupt\n");
return; /* delay not allowed */
}
- wait_time = rtas_extended_busy_delay_time(error);
msleep(wait_time);
- error = RTAS_CLOCK_BUSY;
}
- } while (error == RTAS_CLOCK_BUSY && (get_tb() < max_wait_tb));
+ } while (wait_time && (get_tb() < max_wait_tb));
if (error != 0 && printk_ratelimit()) {
printk(KERN_WARNING "error: reading the clock failed (%d)\n",
@@ -88,14 +90,14 @@ int rtas_set_rtc_time(struct rtc_time *t
tm->tm_year + 1900, tm->tm_mon + 1,
tm->tm_mday, tm->tm_hour, tm->tm_min,
tm->tm_sec, 0);
- if (error == RTAS_CLOCK_BUSY || rtas_is_extended_busy(error)) {
+
+ wait_time = rtas_busy_delay_time(error);
+ if (wait_time) {
if (in_interrupt())
return 1; /* probably decrementer */
- wait_time = rtas_extended_busy_delay_time(error);
msleep(wait_time);
- error = RTAS_CLOCK_BUSY;
}
- } while (error == RTAS_CLOCK_BUSY && (get_tb() < max_wait_tb));
+ } while (wait_time && (get_tb() < max_wait_tb));
if (error != 0 && printk_ratelimit())
printk(KERN_WARNING "error: setting the clock failed (%d)\n",
diff -puN include/asm-powerpc/rtas.h~rtas_delay_reorg include/asm-powerpc/rtas.h
--- 2_6_linus/include/asm-powerpc/rtas.h~rtas_delay_reorg 2006-06-02 15:09:43.000000000 -0500
+++ 2_6_linus-johnrose/include/asm-powerpc/rtas.h 2006-06-02 15:09:43.000000000 -0500
@@ -177,12 +177,8 @@ extern unsigned long rtas_get_boot_time(
extern void rtas_get_rtc_time(struct rtc_time *rtc_time);
extern int rtas_set_rtc_time(struct rtc_time *rtc_time);
-/* Given an RTAS status code of 9900..9905 compute the hinted delay */
-unsigned int rtas_extended_busy_delay_time(int status);
-static inline int rtas_is_extended_busy(int status)
-{
- return status >= 9900 && status <= 9909;
-}
+extern unsigned int rtas_busy_delay_time(int status);
+extern unsigned int rtas_busy_delay(int status);
extern void pSeries_log_error(char *buf, unsigned int err_type, int fatal);
diff -puN arch/powerpc/kernel/rtas_flash.c~rtas_delay_reorg arch/powerpc/kernel/rtas_flash.c
--- 2_6_linus/arch/powerpc/kernel/rtas_flash.c~rtas_delay_reorg 2006-06-02 15:09:43.000000000 -0500
+++ 2_6_linus-johnrose/arch/powerpc/kernel/rtas_flash.c 2006-06-05 15:00:44.000000000 -0500
@@ -365,20 +365,12 @@ static int rtas_excl_release(struct inod
static void manage_flash(struct rtas_manage_flash_t *args_buf)
{
- unsigned int wait_time;
s32 rc;
- while (1) {
+ do {
rc = rtas_call(rtas_token("ibm,manage-flash-image"), 1,
1, NULL, args_buf->op);
- if (rc == RTAS_RC_BUSY)
- udelay(1);
- else if (rtas_is_extended_busy(rc)) {
- wait_time = rtas_extended_busy_delay_time(rc);
- udelay(wait_time * 1000);
- } else
- break;
- }
+ } while (rtas_busy_delay(rc));
args_buf->status = rc;
}
@@ -451,27 +443,18 @@ static ssize_t manage_flash_write(struct
static void validate_flash(struct rtas_validate_flash_t *args_buf)
{
int token = rtas_token("ibm,validate-flash-image");
- unsigned int wait_time;
int update_results;
s32 rc;
rc = 0;
- while(1) {
+ do {
spin_lock(&rtas_data_buf_lock);
memcpy(rtas_data_buf, args_buf->buf, VALIDATE_BUF_SIZE);
rc = rtas_call(token, 2, 2, &update_results,
(u32) __pa(rtas_data_buf), args_buf->buf_size);
memcpy(args_buf->buf, rtas_data_buf, VALIDATE_BUF_SIZE);
spin_unlock(&rtas_data_buf_lock);
-
- if (rc == RTAS_RC_BUSY)
- udelay(1);
- else if (rtas_is_extended_busy(rc)) {
- wait_time = rtas_extended_busy_delay_time(rc);
- udelay(wait_time * 1000);
- } else
- break;
- }
+ } while (rtas_busy_delay(rc));
args_buf->status = rc;
args_buf->update_results = update_results;
_
^ permalink raw reply
* RE: MPC85xx PCI transfer disconnect
From: Liu Dave-r63238 @ 2006-06-05 10:33 UTC (permalink / raw)
To: 'Martin, Tim', linuxppc-embedded
> After scaning more logic analyzer captures, I noticed that
> occasionally the MPC85xx inserts additional wait states (by
> deasserting TRDY#) after only 32 bytes have been transferred.
> So it definitely appears that (the way I have things
> configured now) there's a 20-80ns delay after 1 cache line is
> read, and the MPC85xx disconnects transfers that are larger
> than 2 cache lines.
>
There is one description about MRM cmd in the MPC85xx user manual.
[Memory read multiple]
Similar to the memory-read command, but also causes a
prefetch of the next cache line (32 bytes).
How many masters in your PCI system?
Maybe, you can tune the master latency timer of Tsi148 to get more bandwidth.
The latecy timer is locate at configuration space of your master.
Dave
^ permalink raw reply
* Re: [PATCH] reorg RTAS delay code
From: Nathan Lynch @ 2006-06-05 21:54 UTC (permalink / raw)
To: John Rose; +Cc: Paul Mackerras, External List
In-Reply-To: <1149543108.17307.6.camel@sinatra.austin.ibm.com>
John Rose wrote:
> This patch attempts to handle RTAS "busy" return codes in a more simple
> and consistent manner. Typical callers of RTAS shouldn't have to
> manage wait times and delay calls.
>
> This patch also changes the kernel to use msleep() rather than udelay()
> when a runtime delay is necessary. This will avoid CPU soft lockups
> for extended delay conditions.
>
> Signed-off-by: John Rose <johnrose@austin.ibm.com>
>
> ---
>
> Resend - added the suggested might_sleep() and braces.
FWIW:
Acked-by: Nathan Lynch <ntl@pobox.com>
> 2_6_linus-johnrose/arch/powerpc/kernel/rtas-rtc.c | 30 +++----
> 2_6_linus-johnrose/arch/powerpc/kernel/rtas.c | 85 ++++++++------------
> 2_6_linus-johnrose/arch/powerpc/kernel/rtas_flash.c | 25 -----
> 2_6_linus-johnrose/include/asm-powerpc/rtas.h | 8 -
> 4 files changed, 57 insertions(+), 91 deletions(-)
>
> diff -puN arch/powerpc/kernel/rtas.c~rtas_delay_reorg arch/powerpc/kernel/rtas.c
> --- 2_6_linus/arch/powerpc/kernel/rtas.c~rtas_delay_reorg 2006-06-02 15:09:43.000000000 -0500
> +++ 2_6_linus-johnrose/arch/powerpc/kernel/rtas.c 2006-06-05 15:00:03.000000000 -0500
> @@ -370,24 +370,36 @@ int rtas_call(int token, int nargs, int
> return ret;
> }
>
> -/* Given an RTAS status code of 990n compute the hinted delay of 10^n
> - * (last digit) milliseconds. For now we bound at n=5 (100 sec).
> +/* For RTAS_BUSY (-2), delay for 1 millisecond. For an extended busy status
> + * code of 990n, perform the hinted delay of 10^n (last digit) milliseconds.
> */
> -unsigned int rtas_extended_busy_delay_time(int status)
> +unsigned int rtas_busy_delay_time(int status)
> {
> - int order = status - 9900;
> - unsigned long ms;
> + int order;
> + unsigned int ms = 0;
>
> - if (order < 0)
> - order = 0; /* RTC depends on this for -2 clock busy */
> - else if (order > 5)
> - order = 5; /* bound */
> + if (status == RTAS_BUSY) {
> + ms = 1;
> + } else if (status >= 9900 && status <= 9905) {
> + order = status - 9900;
> + for (ms = 1; order > 0; order--)
> + ms *= 10;
> + }
> +
> + return ms;
> +}
> +
> +/* For an RTAS busy status code, perform the hinted delay. */
> +unsigned int rtas_busy_delay(int status)
> +{
> + unsigned int ms;
>
> - /* Use microseconds for reasonable accuracy */
> - for (ms = 1; order > 0; order--)
> - ms *= 10;
> + might_sleep();
> + ms = rtas_busy_delay_time(status);
> + if (ms)
> + msleep(ms);
>
> - return ms;
> + return ms;
> }
>
> int rtas_error_rc(int rtas_rc)
> @@ -438,22 +450,14 @@ int rtas_get_power_level(int powerdomain
> int rtas_set_power_level(int powerdomain, int level, int *setlevel)
> {
> int token = rtas_token("set-power-level");
> - unsigned int wait_time;
> int rc;
>
> if (token == RTAS_UNKNOWN_SERVICE)
> return -ENOENT;
>
> - while (1) {
> + do {
> rc = rtas_call(token, 2, 2, setlevel, powerdomain, level);
> - if (rc == RTAS_BUSY)
> - udelay(1);
> - else if (rtas_is_extended_busy(rc)) {
> - wait_time = rtas_extended_busy_delay_time(rc);
> - udelay(wait_time * 1000);
> - } else
> - break;
> - }
> + } while (rtas_busy_delay(rc));
>
> if (rc < 0)
> return rtas_error_rc(rc);
> @@ -463,22 +467,14 @@ int rtas_set_power_level(int powerdomain
> int rtas_get_sensor(int sensor, int index, int *state)
> {
> int token = rtas_token("get-sensor-state");
> - unsigned int wait_time;
> int rc;
>
> if (token == RTAS_UNKNOWN_SERVICE)
> return -ENOENT;
>
> - while (1) {
> + do {
> rc = rtas_call(token, 2, 2, state, sensor, index);
> - if (rc == RTAS_BUSY)
> - udelay(1);
> - else if (rtas_is_extended_busy(rc)) {
> - wait_time = rtas_extended_busy_delay_time(rc);
> - udelay(wait_time * 1000);
> - } else
> - break;
> - }
> + } while (rtas_busy_delay(rc));
>
> if (rc < 0)
> return rtas_error_rc(rc);
> @@ -488,23 +484,14 @@ int rtas_get_sensor(int sensor, int inde
> int rtas_set_indicator(int indicator, int index, int new_value)
> {
> int token = rtas_token("set-indicator");
> - unsigned int wait_time;
> int rc;
>
> if (token == RTAS_UNKNOWN_SERVICE)
> return -ENOENT;
>
> - while (1) {
> + do {
> rc = rtas_call(token, 3, 1, NULL, indicator, index, new_value);
> - if (rc == RTAS_BUSY)
> - udelay(1);
> - else if (rtas_is_extended_busy(rc)) {
> - wait_time = rtas_extended_busy_delay_time(rc);
> - udelay(wait_time * 1000);
> - }
> - else
> - break;
> - }
> + } while (rtas_busy_delay(rc));
>
> if (rc < 0)
> return rtas_error_rc(rc);
> @@ -555,13 +542,11 @@ void rtas_os_term(char *str)
> do {
> status = rtas_call(rtas_token("ibm,os-term"), 1, 1, NULL,
> __pa(rtas_os_term_buf));
> + } while (rtas_busy_delay(status));
>
> - if (status == RTAS_BUSY)
> - udelay(1);
> - else if (status != 0)
> - printk(KERN_EMERG "ibm,os-term call failed %d\n",
> + if (status != 0)
> + printk(KERN_EMERG "ibm,os-term call failed %d\n",
> status);
> - } while (status == RTAS_BUSY);
> }
>
> static int ibm_suspend_me_token = RTAS_UNKNOWN_SERVICE;
> @@ -789,7 +774,7 @@ EXPORT_SYMBOL(rtas_token);
> EXPORT_SYMBOL(rtas_call);
> EXPORT_SYMBOL(rtas_data_buf);
> EXPORT_SYMBOL(rtas_data_buf_lock);
> -EXPORT_SYMBOL(rtas_extended_busy_delay_time);
> +EXPORT_SYMBOL(rtas_busy_delay_time);
> EXPORT_SYMBOL(rtas_get_sensor);
> EXPORT_SYMBOL(rtas_get_power_level);
> EXPORT_SYMBOL(rtas_set_power_level);
> diff -puN arch/powerpc/kernel/rtas-rtc.c~rtas_delay_reorg arch/powerpc/kernel/rtas-rtc.c
> --- 2_6_linus/arch/powerpc/kernel/rtas-rtc.c~rtas_delay_reorg 2006-06-02 15:09:43.000000000 -0500
> +++ 2_6_linus-johnrose/arch/powerpc/kernel/rtas-rtc.c 2006-06-02 15:09:43.000000000 -0500
> @@ -14,19 +14,20 @@
> unsigned long __init rtas_get_boot_time(void)
> {
> int ret[8];
> - int error, wait_time;
> + int error;
> + unsigned int wait_time;
> u64 max_wait_tb;
>
> max_wait_tb = get_tb() + tb_ticks_per_usec * 1000 * MAX_RTC_WAIT;
> do {
> error = rtas_call(rtas_token("get-time-of-day"), 0, 8, ret);
> - if (error == RTAS_CLOCK_BUSY || rtas_is_extended_busy(error)) {
> - wait_time = rtas_extended_busy_delay_time(error);
> +
> + wait_time = rtas_busy_delay_time(error);
> + if (wait_time) {
> /* This is boot time so we spin. */
> udelay(wait_time*1000);
> - error = RTAS_CLOCK_BUSY;
> }
> - } while (error == RTAS_CLOCK_BUSY && (get_tb() < max_wait_tb));
> + } while (wait_time && (get_tb() < max_wait_tb));
>
> if (error != 0 && printk_ratelimit()) {
> printk(KERN_WARNING "error: reading the clock failed (%d)\n",
> @@ -44,24 +45,25 @@ unsigned long __init rtas_get_boot_time(
> void rtas_get_rtc_time(struct rtc_time *rtc_tm)
> {
> int ret[8];
> - int error, wait_time;
> + int error;
> + unsigned int wait_time;
> u64 max_wait_tb;
>
> max_wait_tb = get_tb() + tb_ticks_per_usec * 1000 * MAX_RTC_WAIT;
> do {
> error = rtas_call(rtas_token("get-time-of-day"), 0, 8, ret);
> - if (error == RTAS_CLOCK_BUSY || rtas_is_extended_busy(error)) {
> +
> + wait_time = rtas_busy_delay_time(error);
> + if (wait_time) {
> if (in_interrupt() && printk_ratelimit()) {
> memset(rtc_tm, 0, sizeof(struct rtc_time));
> printk(KERN_WARNING "error: reading clock"
> " would delay interrupt\n");
> return; /* delay not allowed */
> }
> - wait_time = rtas_extended_busy_delay_time(error);
> msleep(wait_time);
> - error = RTAS_CLOCK_BUSY;
> }
> - } while (error == RTAS_CLOCK_BUSY && (get_tb() < max_wait_tb));
> + } while (wait_time && (get_tb() < max_wait_tb));
>
> if (error != 0 && printk_ratelimit()) {
> printk(KERN_WARNING "error: reading the clock failed (%d)\n",
> @@ -88,14 +90,14 @@ int rtas_set_rtc_time(struct rtc_time *t
> tm->tm_year + 1900, tm->tm_mon + 1,
> tm->tm_mday, tm->tm_hour, tm->tm_min,
> tm->tm_sec, 0);
> - if (error == RTAS_CLOCK_BUSY || rtas_is_extended_busy(error)) {
> +
> + wait_time = rtas_busy_delay_time(error);
> + if (wait_time) {
> if (in_interrupt())
> return 1; /* probably decrementer */
> - wait_time = rtas_extended_busy_delay_time(error);
> msleep(wait_time);
> - error = RTAS_CLOCK_BUSY;
> }
> - } while (error == RTAS_CLOCK_BUSY && (get_tb() < max_wait_tb));
> + } while (wait_time && (get_tb() < max_wait_tb));
>
> if (error != 0 && printk_ratelimit())
> printk(KERN_WARNING "error: setting the clock failed (%d)\n",
> diff -puN include/asm-powerpc/rtas.h~rtas_delay_reorg include/asm-powerpc/rtas.h
> --- 2_6_linus/include/asm-powerpc/rtas.h~rtas_delay_reorg 2006-06-02 15:09:43.000000000 -0500
> +++ 2_6_linus-johnrose/include/asm-powerpc/rtas.h 2006-06-02 15:09:43.000000000 -0500
> @@ -177,12 +177,8 @@ extern unsigned long rtas_get_boot_time(
> extern void rtas_get_rtc_time(struct rtc_time *rtc_time);
> extern int rtas_set_rtc_time(struct rtc_time *rtc_time);
>
> -/* Given an RTAS status code of 9900..9905 compute the hinted delay */
> -unsigned int rtas_extended_busy_delay_time(int status);
> -static inline int rtas_is_extended_busy(int status)
> -{
> - return status >= 9900 && status <= 9909;
> -}
> +extern unsigned int rtas_busy_delay_time(int status);
> +extern unsigned int rtas_busy_delay(int status);
>
> extern void pSeries_log_error(char *buf, unsigned int err_type, int fatal);
>
> diff -puN arch/powerpc/kernel/rtas_flash.c~rtas_delay_reorg arch/powerpc/kernel/rtas_flash.c
> --- 2_6_linus/arch/powerpc/kernel/rtas_flash.c~rtas_delay_reorg 2006-06-02 15:09:43.000000000 -0500
> +++ 2_6_linus-johnrose/arch/powerpc/kernel/rtas_flash.c 2006-06-05 15:00:44.000000000 -0500
> @@ -365,20 +365,12 @@ static int rtas_excl_release(struct inod
>
> static void manage_flash(struct rtas_manage_flash_t *args_buf)
> {
> - unsigned int wait_time;
> s32 rc;
>
> - while (1) {
> + do {
> rc = rtas_call(rtas_token("ibm,manage-flash-image"), 1,
> 1, NULL, args_buf->op);
> - if (rc == RTAS_RC_BUSY)
> - udelay(1);
> - else if (rtas_is_extended_busy(rc)) {
> - wait_time = rtas_extended_busy_delay_time(rc);
> - udelay(wait_time * 1000);
> - } else
> - break;
> - }
> + } while (rtas_busy_delay(rc));
>
> args_buf->status = rc;
> }
> @@ -451,27 +443,18 @@ static ssize_t manage_flash_write(struct
> static void validate_flash(struct rtas_validate_flash_t *args_buf)
> {
> int token = rtas_token("ibm,validate-flash-image");
> - unsigned int wait_time;
> int update_results;
> s32 rc;
>
> rc = 0;
> - while(1) {
> + do {
> spin_lock(&rtas_data_buf_lock);
> memcpy(rtas_data_buf, args_buf->buf, VALIDATE_BUF_SIZE);
> rc = rtas_call(token, 2, 2, &update_results,
> (u32) __pa(rtas_data_buf), args_buf->buf_size);
> memcpy(args_buf->buf, rtas_data_buf, VALIDATE_BUF_SIZE);
> spin_unlock(&rtas_data_buf_lock);
> -
> - if (rc == RTAS_RC_BUSY)
> - udelay(1);
> - else if (rtas_is_extended_busy(rc)) {
> - wait_time = rtas_extended_busy_delay_time(rc);
> - udelay(wait_time * 1000);
> - } else
> - break;
> - }
> + } while (rtas_busy_delay(rc));
>
> args_buf->status = rc;
> args_buf->update_results = update_results;
>
> _
>
>
^ permalink raw reply
* FW: process starvation with 2.6 scheduler
From: Kallol Biswas @ 2006-06-05 22:08 UTC (permalink / raw)
To: linuxppc-dev
-----Original Message-----
From: Kallol Biswas
Sent: Monday, June 05, 2006 2:30 PM
To: Kallol Biswas; linux-kernel@vger.kernel.org
Subject: RE: process starvation with 2.6 scheduler
I have checked the per processor run queue data structure (we have only one).
The active process is the in the queue list 118 of the of array[0] and the
starved process is the queue list 120 of the array[0]. The pointer, active points to array[0] and expired points to array[1].
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Kallol Biswas
Sent: Monday, June 05, 2006 1:47 PM
To: linux-kernel@vger.kernel.org
Subject: process starvation with 2.6 scheduler
From: Kallol Biswas
Sent: Monday, June 05, 2006 12:49 PM
To: 'linux-kernel@vger.kernel.org'
Subject: process starvation with 2.6 scheduler
Hello,
We have a process starvation problem with our 2.6.11 kernel running on a ppc-440 based system.
We have a storage SOC based on PPC-440. The SOC is emulated on a system emulator called Palladium. It is from Cadence. The system runs at 400KHz speed. It has three Ethernet ports; they are connected to outside lab network with a speed bridge.
The netperf server netserver runs on the emulated system (2.6.11 kernel on Palladium). There are netperf linux clients running on a x86 box.
If netperf request response (TCP_RR) traffic is run on all three ports; after sometime only one port remains active, the application (netperf client) on other two ports wait for a long time and eventually time out.
The netserver code has been instrumented. For one of the starved netserver processes it has been found that the TCP_RR request from the netperf client on linux x86 box has been received by the server, it has issued send() call to send back reply but send() never returns.
With an ICE connected to the Palladium (emulator) I have dumped the kernel data structures of the starved process and the active process.
For Active Process:
Time_slice 84
Policy : SCHED_NORMAL
Dynamic priority: 118
Static priority: 120
Preempt_count: 0x20100
Flags = 0
State = 0 (TASK_RUNNING)
For Starved Process:
Time slice: 77
Policy: SCHED_NORMAL
Dynamic priority: 120
Static priority: 120
Preempt_count: 0x10000000 (PREEMPT_ACTIVE is set)
Flags = 0
State = 0 (TASK_RUNNING)
CONFIG_PREEMPT is not set.
The system has single CPU.
Any help to debug the problem is welcome.
Kallol
^ permalink raw reply
* RE: process starvation with 2.6 scheduler
From: Kallol Biswas @ 2006-06-05 23:05 UTC (permalink / raw)
To: linuxppc-dev
Some more information:
For the active process:
Last_ran 0x190458787
Timestamp: 0x190458787
For the starved process:
Last_ran: 0x14dc18cfd
Timestamp: 0x14dc18cfd
-----Original Message-----
From: Kallol Biswas
Sent: Monday, June 05, 2006 3:09 PM
To: 'linuxppc-dev@ozlabs.org'
Subject: FW: process starvation with 2.6 scheduler
-----Original Message-----
From: Kallol Biswas
Sent: Monday, June 05, 2006 2:30 PM
To: Kallol Biswas; linux-kernel@vger.kernel.org
Subject: RE: process starvation with 2.6 scheduler
I have checked the per processor run queue data structure (we have only one).
The active process is the in the queue list 118 of the of array[0] and the
starved process is the queue list 120 of the array[0]. The pointer, active points to array[0] and expired points to array[1].
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Kallol Biswas
Sent: Monday, June 05, 2006 1:47 PM
To: linux-kernel@vger.kernel.org
Subject: process starvation with 2.6 scheduler
From: Kallol Biswas
Sent: Monday, June 05, 2006 12:49 PM
To: 'linux-kernel@vger.kernel.org'
Subject: process starvation with 2.6 scheduler
Hello,
We have a process starvation problem with our 2.6.11 kernel running on a ppc-440 based system.
We have a storage SOC based on PPC-440. The SOC is emulated on a system emulator called Palladium. It is from Cadence. The system runs at 400KHz speed. It has three Ethernet ports; they are connected to outside lab network with a speed bridge.
The netperf server netserver runs on the emulated system (2.6.11 kernel on Palladium). There are netperf linux clients running on a x86 box.
If netperf request response (TCP_RR) traffic is run on all three ports; after sometime only one port remains active, the application (netperf client) on other two ports wait for a long time and eventually time out.
The netserver code has been instrumented. For one of the starved netserver processes it has been found that the TCP_RR request from the netperf client on linux x86 box has been received by the server, it has issued send() call to send back reply but send() never returns.
With an ICE connected to the Palladium (emulator) I have dumped the kernel data structures of the starved process and the active process.
For Active Process:
Time_slice 84
Policy : SCHED_NORMAL
Dynamic priority: 118
Static priority: 120
Preempt_count: 0x20100
Thread_info->flags = 0
State = 0 (TASK_RUNNING)
For Starved Process:
Time slice: 77
Policy: SCHED_NORMAL
Dynamic priority: 120
Static priority: 120
Preempt_count: 0x10000000 (PREEMPT_ACTIVE is set)
Thread_info->flags = 0
State = 0 (TASK_RUNNING)
CONFIG_PREEMPT is not set.
The system has single CPU.
Any help to debug the problem is welcome.
Kallol
^ permalink raw reply
* ppc85xx DMA
From: Naru Sundar @ 2006-06-06 0:55 UTC (permalink / raw)
To: linuxppc-embedded
Dear sirs,
I am trying to add a DMA transfer component to my driver on linux 2.6 on a
ppc 8541. Following the steps listed in the reference manual, I write the
SAR, SATR, DAR, DATR and BCR registers before cycling the bit in the MR
register to start the transfer.
The SR register though indicates a transfer error as soon as I write the
DAR register. Clearly I've gotten the mapping wrong. I know what the
address I am trying to write to in kernel space is, what is unclear is
what address the DAR register is expecting.
Any help would be appreciated
-naru
^ permalink raw reply
* RE: ppc85xx DMA
From: Liu Dave-r63238 @ 2006-06-06 1:39 UTC (permalink / raw)
To: 'Naru Sundar', linuxppc-embedded
> Dear sirs,
>
> I am trying to add a DMA transfer component to my driver on
> linux 2.6 on a ppc 8541. Following the steps listed in the
> reference manual, I write the SAR, SATR, DAR, DATR and BCR
> registers before cycling the bit in the MR register to start
> the transfer.
>
What is the DMA transfer mode? Is direct or chaining mode?
> The SR register though indicates a transfer error as soon as
> I write the DAR register. Clearly I've gotten the mapping
> wrong. I know what the address I am trying to write to in
> kernel space is, what is unclear is what address the DAR
> register is expecting.
>
Did you ioremap the DMA register space?
The DAR register need the physical address
Dave
^ permalink raw reply
* Re: Making Two ethernet interfaces up in Linux
From: Andy Fleming @ 2006-06-05 15:12 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: Shantanu Nalage, linuxppc-embedded
In-Reply-To: <200606032255.05997.antonio.dibacco@aruba.it>
On Jun 3, 2006, at 15:55, Antonio Di Bacco wrote:
>> We are trying to port Linux on Xilinx Board XUPV2Pro
>> which is
>> similar in most aspects to the Xilinx ML300 board. Linux is up and
>> running for the original board i.e. having only one ethrnet
>> interface.
>> Now since we wanted to have the board working as router, we
>> designed a
>> daughter board with two ethernet phy interfaces. The MACs required
>> for
>> that are instantiated in Xilinx ....
>
> You have already the driver for the first MAC, then you should
> start from that
> modifying the init procedure for example and all the others. Your
> driver
> should initialize both the MACs and also create two devices calling
> init_etherdev tow times. If you post your driver I can suggest what to
> change. It is not so difficult.
Generally, it's better to modify the driver so it can be used to
control any number of instances of the same ethernet hardware. Then
instantiate 2 (or how many you like) instances of the device, using
the device layer (typically done in the board-specific code).
^ 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