* Re: Flash on ep8248e standard motherboards
From: Laurent Pinchart @ 2007-09-12 9:10 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Alan Bennett
In-Reply-To: <bfa0697f0709041108u2c6b719dj600cb2eb25b66a4a@mail.gmail.com>
Hi Alan,
On Tuesday 04 September 2007 20:08, Alan Bennett wrote:
> Please accept my apologies for sending the last email and accept this
> email address and question. without the disclaimer.
> ---------------------------------------------------
>
> Hello;
> We have a custom board based on the ep8248e design from Embedded
> Planet and I'm trying to use something other than codewarrior to flash
> u-boot srec's
>
> I'm not sure where the problem is, but I'm unable to flash the
> u-boot.srec onto the Embedded Planet board (using the BDI2000), let
> alone our custom board.
> 1. Embedded Planet ep8248E
> 64 MB SDRAM
> 64 MB Flash (x2 Am29LV256M)
> 2. Custom
> 128 MB SDRAM
> 128 MB Flash (X2 Spansion S29GL512N)
>
> NOTE: CW successfully flashes both parts, but then again, it's CW.
>
>
> BDI 2000 Config File:
> ; initialize - FLASH BR0 & OR0 (64 Mbyte)
> ;*******************************************
> WM32 0xf0010100 0xfc001801
> WM32 0xf0010104 0xfc0008c2
> [FLASH]
> CHIPTYPE MIRRORX16
> CHIPSIZE 0x2000000
> BUSWIDTH 16
>
> I then attempt to unlock/erase/program
> Check for Sanity (NOTE: using BDI 2000 PROMPT)
> md 0xf0010100 2
> f0010100 : 0xf8001801 - 134211583 ....
> f0010104 : 0xf80008b2 - 134215502 ....
> md 0xfff00000 2
> fff00000 : 0x10101010 269488144 ....
> fff00004 : 0x10101010 269488144 ....
> All looks good. (10101010 is the existing planet core header)
>
> TRY TO UNLOCK
> unlock 0xfff00000 1000
> Unlocking flash at 0xfff00000
> # Invalid parameter for flash programming
>
> TRY TO ERASE
> erase 0xfff00000 UNLOCK 1000
> Erasing flash at 0xfff00000
> # Erasing flash memory failed
> BUT
> erase 0xffff0000 UNLOCK 1000
> Erasing flash at 0xffff0000
> Erasing flash passed
> HOWEVER
> mm 0xffff0000 0xdeadbeef
> md 0xffff0000 1
> ffff0000 : 0xffffffff
> SO it doesn't seem to allow write access afterall...
You need to use the 'prog' command to write to flash. 'md' won't do.
> Is there anyone that has a BDI 2000 config file for flashing the
> ep8248e motherboard the 8MB Flash Version (64 MB flash version)
Regards,
=2D-=20
Laurent Pinchart
CSE Semaphore Belgium
Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
=46 +32 (2) 387 42 75
^ permalink raw reply
* Adeos patch for 2.6.15 ppc kernel
From: Konstantin Boyanov @ 2007-09-12 9:12 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 507 bytes --]
Hello everybody,
I have a simple question - where can I find an Adeos patch for a
2.6.15kernel? I'm trying to integrate Xenomai in it, but as I read in
the
installation notes i first must patch a fresh kernel with a corresponding
adeos patch. I googled around but found nothing of use, only the latest
patches for 2.6.20-2.6.22, and also the denx linux-2.6 git repository. Is
the kernel there already patched wiht adeos?
Any help and guidance are highly apreciated.
With best regards,
Kosntantin Boyanov
[-- Attachment #2: Type: text/html, Size: 624 bytes --]
^ permalink raw reply
* Re: Adeos patch for 2.6.15 ppc kernel
From: Johan Borkhuis @ 2007-09-12 9:33 UTC (permalink / raw)
To: Konstantin Boyanov; +Cc: linuxppc-dev
In-Reply-To: <929bf310709120212y3211a73au791663992965c80e@mail.gmail.com>
Konstantin Boyanov wrote:
> Hello everybody,
>
> I have a simple question - where can I find an Adeos patch for a
> 2.6.15 kernel? I'm trying to integrate Xenomai in it, but as I read in
> the installation notes i first must patch a fresh kernel with a
> corresponding adeos patch. I googled around but found nothing of use,
> only the latest patches for 2.6.20-2.6.22, and also the denx linux-2.6
> git repository. Is the kernel there already patched wiht adeos?
>
> Any help and guidance are highly apreciated.
There are ppc-patches available for kernel 2.6.13, 2.6.14, 2.6.18 and
2.6.19. For powerpc there are patches available for 2.6.20 and newer.
Kind regards,
Johan Borkhuis
^ permalink raw reply
* Z85230 chip
From: raul.moreno @ 2007-09-12 9:22 UTC (permalink / raw)
To: linuxppc-embedded
Hello everybody,
I am interested in using a Z85230 chip. I've seen that the synchronous =
mode
is supported in a driver and there is a comment about the attempt to un=
ify
the asynchronous mode too from 2.5 Linux version.
Does anyone know if the driver z85230.c included both operation modes
currently? Or does another driver exist which merges the asynchronous m=
ode?
Cheers,
Ra=FAl Moreno
***********Internet Email Confidentiality Footer*************
This email and any files transmitted with it are confidential and inten=
ded
solely for the use of the organization or individual to whom they are
addressed. It is expressly forbidden to retransmit or copy email and/o=
r
this attached files without our permission . If you are not the
addressee indicated in this message (or responsible for delivery of the=
message to such person), you may not copy or deliver this message
to anyone. In such case, you should destroy this message and kindly
notify the sender by reply email. Please advise immediately if you or
your employer does not consent to Internet email for messages of this
kind. Opinions, conclusions and other information in this message that=
do not relate to the official business of my firm shall be understood a=
s
neither given nor endorsed by it.=
^ permalink raw reply
* Re: SYSFS: need a noncaching read
From: Greg KH @ 2007-09-12 10:01 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linuxppc-dev, Heiko Schocher, linux-kernel, Detlev Zundel
In-Reply-To: <20070912053207.GH23573@pengutronix.de>
On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
> On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > I have developed a device driver and use the sysFS to export some
> > registers to userspace.
>
> Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
> not to play around with registers from userspace.
>
> > I opened the sysFS File for one register and did some reads from this
> > File, but I alwas becoming the same value from the register, whats not
> > OK, because they are changing. So I found out that the sysFS caches
> > the reads ... :-(
>
> Yes, it does. What you can do is close()ing the file handle between
> accesses, which makes it work but is slow.
Do an lseek back to 0 and then re-read, you will get called in your
driver again.
Not that this is a good thing to do for this kind of thing, as others
have already said.
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH 1/5] Add Freescale DMA and DMA channel to Documentation/powerpc/booting-without-of.txt file.
From: Zhang Wei-r63237 @ 2007-09-12 10:13 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev, paulus, David Gibson
In-Reply-To: <20070911141907.GF1932@ld0162-tx32.am.freescale.net>
> > >=20
> > > On Fri, Sep 07, 2007 at 04:43:35PM +0200, Segher=20
> Boessenkool wrote:
> > > > > + l) Freescale DMA
> > > >=20
> > > > > + - compatible : Should be "fsl,dma".
> > > >=20
> > > > Please choose some more specific name. "fsl,mpc8540-dma" would
> > > > be a reasonable choice perhaps.
> > >=20
> > > More precisely, the compatible property should always=20
> have an specific
> > > entry based on the exact chip the DMA engine resides in,=20
> as well as a
> > > more general entry for any fsl dma engine of this type.
> > >=20
> > There is only difference in DMA channel and not in DMA node=20
> now. Does it
> > need add the precise compatible property name?
>=20
> Yes. First of all, there most likely is a difference -- the=20
> endianness
> of the shared status summary register. Secondly, the device=20
> tree should
> not make assumptions as far as whether the user is going to bind to
> individual channels or the whole controller.
I have a strange issue here. If I rename 'fsl,dma' to 'fsl,mpc8540-dma',
the 'fsl,mpc8540-dma-channel' will be also regarded as DMA device not
DMA channel.
Thanks!
- zw
^ permalink raw reply
* Re: [PATCH] powerpc: add new required termio functions
From: Heiko Carstens @ 2007-09-12 10:20 UTC (permalink / raw)
To: Michael Neuling
Cc: linux-kernel, linuxppc-dev, paulus, Alan Cox, akpm,
Linus Torvalds, David S. Miller, Martin Schwidefsky
In-Reply-To: <8018.1189562679@neuling.org>
On Wed, Sep 12, 2007 at 12:04:39PM +1000, Michael Neuling wrote:
> The "tty: termios locking functions break with new termios type" patch
> (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
> [...]
> I'm guessing other architectures are broken too?
FWIW, the above quoted patch breaks s390 as well.
^ permalink raw reply
* Re: [PATCH] powerpc: add new required termio functions
From: Andrew Morton @ 2007-09-12 11:01 UTC (permalink / raw)
To: Heiko Carstens
Cc: Michael Neuling, linux-kernel, linuxppc-dev, paulus, Alan Cox,
Linus Torvalds, David S. Miller, Martin Schwidefsky
In-Reply-To: <20070912102032.GB7858@osiris.boeblingen.de.ibm.com>
On Wed, 12 Sep 2007 12:20:32 +0200 Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> On Wed, Sep 12, 2007 at 12:04:39PM +1000, Michael Neuling wrote:
> > The "tty: termios locking functions break with new termios type" patch
> > (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
> > [...]
> > I'm guessing other architectures are broken too?
>
> FWIW, the above quoted patch breaks s390 as well.
Does this fix it?
diff -puN drivers/char/tty_ioctl.c~powerpc-add-new-required-termio-functions drivers/char/tty_ioctl.c
--- a/drivers/char/tty_ioctl.c~powerpc-add-new-required-termio-functions
+++ a/drivers/char/tty_ioctl.c
@@ -795,6 +795,19 @@ int n_tty_ioctl(struct tty_struct * tty,
if (L_ICANON(tty))
retval = inq_canon(tty);
return put_user(retval, (unsigned int __user *) arg);
+#ifndef TCGETS2
+ case TIOCGLCKTRMIOS:
+ if (kernel_termios_to_user_termios((struct termios __user *)arg, real_tty->termios_locked))
+ return -EFAULT;
+ return 0;
+
+ case TIOCSLCKTRMIOS:
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+ if (user_termios_to_kernel_termios(real_tty->termios_locked, (struct termios __user *) arg))
+ return -EFAULT;
+ return 0;
+#else
case TIOCGLCKTRMIOS:
if (kernel_termios_to_user_termios_1((struct termios __user *)arg, real_tty->termios_locked))
return -EFAULT;
@@ -806,6 +819,7 @@ int n_tty_ioctl(struct tty_struct * tty,
if (user_termios_to_kernel_termios_1(real_tty->termios_locked, (struct termios __user *) arg))
return -EFAULT;
return 0;
+#endif
case TIOCPKT:
{
_
^ permalink raw reply
* Re: [PATCH 07/15] Don't return -ENOSYS as extra notes size if spufs is not loaded
From: Arnd Bergmann @ 2007-09-12 11:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jeremy Kerr, linux-kernel
In-Reply-To: <628a383203480c3ce59125feccc32168de919014.1189583010.git.michael@ellerman.id.au>
On Wednesday 12 September 2007, Michael Ellerman wrote:
> Because the SPU coredump code might be built as part of a module (spufs),
> we have a stub which is called by the coredump code, this routine then calls
> into spufs if it's loaded.
>
> Unfortunately the stub returns -ENOSYS if spufs is not loaded, which is
> interpreted by the coredump code as an extra note size of -38 bytes. This
> leads to a corrupt core dump.
>
> If spufs is not loaded there will be no SPU ELF notes to write, and so the
> extra notes size will be == 0.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
^ permalink raw reply
* Re: SYSFS: need a noncaching read
From: Heiko Schocher @ 2007-09-12 11:13 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-kernel, Detlev Zundel
In-Reply-To: <20070912100123.GA23182@kroah.com>
Hello Greg
Am Mittwoch, den 12.09.2007, 03:01 -0700 schrieb Greg KH:
> On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
> > On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > > I have developed a device driver and use the sysFS to export some
> > > registers to userspace.
> >
> > Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
> > not to play around with registers from userspace.
> >
> > > I opened the sysFS File for one register and did some reads from this
> > > File, but I alwas becoming the same value from the register, whats not
> > > OK, because they are changing. So I found out that the sysFS caches
> > > the reads ... :-(
> >
> > Yes, it does. What you can do is close()ing the file handle between
> > accesses, which makes it work but is slow.
>
> Do an lseek back to 0 and then re-read, you will get called in your
> driver again.
No thats not true. I thought this too, but if I make a:
seek (fd, 0L, SEEK_SET);
in Userspace, there is no retrigger in the sysFS, my driver is *not*
called again. So I made a own sysfs_seek function, which does retrigger
the driver ...
Is this really wanted in the sysFS, that there is no way to retrigger a
read?
thanks
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH] powerpc: add new required termio functions
From: Michael Neuling @ 2007-09-12 11:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Heiko Carstens, linux-kernel, linuxppc-dev, paulus, Alan Cox,
Linus Torvalds, David S. Miller, Martin Schwidefsky
In-Reply-To: <20070912040109.3f6a9149.akpm@linux-foundation.org>
In message <20070912040109.3f6a9149.akpm@linux-foundation.org> you wrote:
> On Wed, 12 Sep 2007 12:20:32 +0200 Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
>
> > On Wed, Sep 12, 2007 at 12:04:39PM +1000, Michael Neuling wrote:
> > > The "tty: termios locking functions break with new termios type" patch
> > > (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
> > > [...]
> > > I'm guessing other architectures are broken too?
> >
> > FWIW, the above quoted patch breaks s390 as well.
>
> Does this fix it?
FYI it does fix powerpc, but I suspect you were asking about s390 here.
Mikey
>
> diff -puN drivers/char/tty_ioctl.c~powerpc-add-new-required-termio-functions
drivers/char/tty_ioctl.c
> --- a/drivers/char/tty_ioctl.c~powerpc-add-new-required-termio-functions
> +++ a/drivers/char/tty_ioctl.c
> @@ -795,6 +795,19 @@ int n_tty_ioctl(struct tty_struct * tty,
> if (L_ICANON(tty))
> retval = inq_canon(tty);
> return put_user(retval, (unsigned int __user *) arg);
> +#ifndef TCGETS2
> + case TIOCGLCKTRMIOS:
> + if (kernel_termios_to_user_termios((struct termios __us
er *)arg, real_tty->termios_locked))
> + return -EFAULT;
> + return 0;
> +
> + case TIOCSLCKTRMIOS:
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> + if (user_termios_to_kernel_termios(real_tty->termios_lo
cked, (struct termios __user *) arg))
> + return -EFAULT;
> + return 0;
> +#else
> case TIOCGLCKTRMIOS:
> if (kernel_termios_to_user_termios_1((struct termios __
user *)arg, real_tty->termios_locked))
> return -EFAULT;
> @@ -806,6 +819,7 @@ int n_tty_ioctl(struct tty_struct * tty,
> if (user_termios_to_kernel_termios_1(real_tty->termios_
locked, (struct termios __user *) arg))
> return -EFAULT;
> return 0;
> +#endif
>
> case TIOCPKT:
> {
> _
>
^ permalink raw reply
* [PATCH] [POWERPC] ucc_geth: fix compilation
From: Anton Vorontsov @ 2007-09-12 11:24 UTC (permalink / raw)
To: linuxppc-dev
This patch is against paulus/powerpc.git or galak/powerpc.git tree.
Both affected.
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
There is no qe_bd_t typedef any longer, now it's struct qe_bd.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 12e01b2..9a38dfe 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -2148,7 +2148,7 @@ static void ucc_geth_memclean(struct ucc_geth_private *ugeth)
for (j = 0; j < ugeth->ug_info->bdRingLenTx[i]; j++) {
if (ugeth->tx_skbuff[i][j]) {
dma_unmap_single(NULL,
- ((qe_bd_t *)bd)->buf,
+ ((struct qe_bd *)bd)->buf,
(in_be32((u32 *)bd) &
BD_LENGTH_MASK),
DMA_TO_DEVICE);
--
1.5.0.6
^ permalink raw reply related
* [PATCH] [POWERPC] ucc_geth: fix module removal
From: Anton Vorontsov @ 2007-09-12 11:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: netdev
- uccf should be set to NULL to not double-free memory on
subsequent calls;
- ind_hash_q and group_hash_q lists should be initialized in the
probe() function, instead of struct_init() (called by open()),
otherwise there will be an oops if ucc_geth_driver removed
prior 'ifconfig ethX up';
- add unregister_netdev();
- reorder geth_remove() steps.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.c | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 9a38dfe..bc2b3bf 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -2080,8 +2080,10 @@ static void ucc_geth_memclean(struct ucc_geth_private *ugeth)
if (!ugeth)
return;
- if (ugeth->uccf)
+ if (ugeth->uccf) {
ucc_fast_free(ugeth->uccf);
+ ugeth->uccf = NULL;
+ }
if (ugeth->p_thread_data_tx) {
qe_muram_free(ugeth->thread_dat_tx_offset);
@@ -2312,10 +2314,6 @@ static int ucc_struct_init(struct ucc_geth_private *ugeth)
ug_info = ugeth->ug_info;
uf_info = &ug_info->uf_info;
- /* Create CQs for hash tables */
- INIT_LIST_HEAD(&ugeth->group_hash_q);
- INIT_LIST_HEAD(&ugeth->ind_hash_q);
-
if (!((uf_info->bd_mem_part == MEM_PART_SYSTEM) ||
(uf_info->bd_mem_part == MEM_PART_MURAM))) {
if (netif_msg_probe(ugeth))
@@ -3949,6 +3947,10 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
ugeth = netdev_priv(dev);
spin_lock_init(&ugeth->lock);
+ /* Create CQs for hash tables */
+ INIT_LIST_HEAD(&ugeth->group_hash_q);
+ INIT_LIST_HEAD(&ugeth->ind_hash_q);
+
dev_set_drvdata(device, dev);
/* Set the dev->base_addr to the gfar reg region */
@@ -4002,9 +4004,10 @@ static int ucc_geth_remove(struct of_device* ofdev)
struct net_device *dev = dev_get_drvdata(device);
struct ucc_geth_private *ugeth = netdev_priv(dev);
- dev_set_drvdata(device, NULL);
- ucc_geth_memclean(ugeth);
+ unregister_netdev(dev);
free_netdev(dev);
+ ucc_geth_memclean(ugeth);
+ dev_set_drvdata(device, NULL);
return 0;
}
--
1.5.0.6
^ permalink raw reply related
* [PATCH] [POWERPC] ucc_fast: fix debug output
From: Anton Vorontsov @ 2007-09-12 11:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Timur Tabi
Timur, want to take this along with your qe_lib cleanup queue?
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 40 ++++++++++++++++----------------
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_fast.c b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
index 3df202e..ab4b3cf 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
@@ -30,45 +30,45 @@
void ucc_fast_dump_regs(struct ucc_fast_private * uccf)
{
- printk(KERN_INFO "UCC%d Fast registers:", uccf->uf_info->ucc_num);
- printk(KERN_INFO "Base address: 0x%08x", (u32) uccf->uf_regs);
+ printk(KERN_INFO "UCC%d Fast registers:\n", uccf->uf_info->ucc_num);
+ printk(KERN_INFO "Base address: 0x%08x\n", (u32) uccf->uf_regs);
- printk(KERN_INFO "gumr : addr - 0x%08x, val - 0x%08x",
+ printk(KERN_INFO "gumr : addr - 0x%08x, val - 0x%08x\n",
(u32) & uccf->uf_regs->gumr, in_be32(&uccf->uf_regs->gumr));
- printk(KERN_INFO "upsmr : addr - 0x%08x, val - 0x%08x",
+ printk(KERN_INFO "upsmr : addr - 0x%08x, val - 0x%08x\n",
(u32) & uccf->uf_regs->upsmr, in_be32(&uccf->uf_regs->upsmr));
- printk(KERN_INFO "utodr : addr - 0x%08x, val - 0x%04x",
+ printk(KERN_INFO "utodr : addr - 0x%08x, val - 0x%04x\n",
(u32) & uccf->uf_regs->utodr, in_be16(&uccf->uf_regs->utodr));
- printk(KERN_INFO "udsr : addr - 0x%08x, val - 0x%04x",
+ printk(KERN_INFO "udsr : addr - 0x%08x, val - 0x%04x\n",
(u32) & uccf->uf_regs->udsr, in_be16(&uccf->uf_regs->udsr));
- printk(KERN_INFO "ucce : addr - 0x%08x, val - 0x%08x",
+ printk(KERN_INFO "ucce : addr - 0x%08x, val - 0x%08x\n",
(u32) & uccf->uf_regs->ucce, in_be32(&uccf->uf_regs->ucce));
- printk(KERN_INFO "uccm : addr - 0x%08x, val - 0x%08x",
+ printk(KERN_INFO "uccm : addr - 0x%08x, val - 0x%08x\n",
(u32) & uccf->uf_regs->uccm, in_be32(&uccf->uf_regs->uccm));
- printk(KERN_INFO "uccs : addr - 0x%08x, val - 0x%02x",
+ printk(KERN_INFO "uccs : addr - 0x%08x, val - 0x%02x\n",
(u32) & uccf->uf_regs->uccs, uccf->uf_regs->uccs);
- printk(KERN_INFO "urfb : addr - 0x%08x, val - 0x%08x",
+ printk(KERN_INFO "urfb : addr - 0x%08x, val - 0x%08x\n",
(u32) & uccf->uf_regs->urfb, in_be32(&uccf->uf_regs->urfb));
- printk(KERN_INFO "urfs : addr - 0x%08x, val - 0x%04x",
+ printk(KERN_INFO "urfs : addr - 0x%08x, val - 0x%04x\n",
(u32) & uccf->uf_regs->urfs, in_be16(&uccf->uf_regs->urfs));
- printk(KERN_INFO "urfet : addr - 0x%08x, val - 0x%04x",
+ printk(KERN_INFO "urfet : addr - 0x%08x, val - 0x%04x\n",
(u32) & uccf->uf_regs->urfet, in_be16(&uccf->uf_regs->urfet));
- printk(KERN_INFO "urfset: addr - 0x%08x, val - 0x%04x",
+ printk(KERN_INFO "urfset: addr - 0x%08x, val - 0x%04x\n",
(u32) & uccf->uf_regs->urfset,
in_be16(&uccf->uf_regs->urfset));
- printk(KERN_INFO "utfb : addr - 0x%08x, val - 0x%08x",
+ printk(KERN_INFO "utfb : addr - 0x%08x, val - 0x%08x\n",
(u32) & uccf->uf_regs->utfb, in_be32(&uccf->uf_regs->utfb));
- printk(KERN_INFO "utfs : addr - 0x%08x, val - 0x%04x",
+ printk(KERN_INFO "utfs : addr - 0x%08x, val - 0x%04x\n",
(u32) & uccf->uf_regs->utfs, in_be16(&uccf->uf_regs->utfs));
- printk(KERN_INFO "utfet : addr - 0x%08x, val - 0x%04x",
+ printk(KERN_INFO "utfet : addr - 0x%08x, val - 0x%04x\n",
(u32) & uccf->uf_regs->utfet, in_be16(&uccf->uf_regs->utfet));
- printk(KERN_INFO "utftt : addr - 0x%08x, val - 0x%04x",
+ printk(KERN_INFO "utftt : addr - 0x%08x, val - 0x%04x\n",
(u32) & uccf->uf_regs->utftt, in_be16(&uccf->uf_regs->utftt));
- printk(KERN_INFO "utpt : addr - 0x%08x, val - 0x%04x",
+ printk(KERN_INFO "utpt : addr - 0x%08x, val - 0x%04x\n",
(u32) & uccf->uf_regs->utpt, in_be16(&uccf->uf_regs->utpt));
- printk(KERN_INFO "urtry : addr - 0x%08x, val - 0x%08x",
+ printk(KERN_INFO "urtry : addr - 0x%08x, val - 0x%08x\n",
(u32) & uccf->uf_regs->urtry, in_be32(&uccf->uf_regs->urtry));
- printk(KERN_INFO "guemr : addr - 0x%08x, val - 0x%02x",
+ printk(KERN_INFO "guemr : addr - 0x%08x, val - 0x%02x\n",
(u32) & uccf->uf_regs->guemr, uccf->uf_regs->guemr);
}
EXPORT_SYMBOL(ucc_fast_dump_regs);
--
1.5.0.6
^ permalink raw reply related
* [PATCH] [POWERPC] mpc8568e_mds: UCC0's PHY is at 0x7, not 0x1
From: Anton Vorontsov @ 2007-09-12 11:25 UTC (permalink / raw)
To: linuxppc-dev
There was probably a typo in the documentation, or it's hw errata.
Recent u-boot also using 0x7.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8568mds.dts | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index b1dcfbe..719929c 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -97,10 +97,10 @@
device_type = "mdio";
compatible = "gianfar";
reg = <24520 20>;
- phy0: ethernet-phy@0 {
+ phy0: ethernet-phy@7 {
interrupt-parent = <&mpic>;
interrupts = <1 1>;
- reg = <0>;
+ reg = <7>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
@@ -417,10 +417,10 @@
/* These are the same PHYs as on
* gianfar's MDIO bus */
- qe_phy0: ethernet-phy@00 {
+ qe_phy0: ethernet-phy@07 {
interrupt-parent = <&mpic>;
interrupts = <1 1>;
- reg = <0>;
+ reg = <7>;
device_type = "ethernet-phy";
};
qe_phy1: ethernet-phy@01 {
--
1.5.0.6
^ permalink raw reply related
* [PATCH] phy: implement release function
From: Anton Vorontsov @ 2007-09-12 11:26 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev
Lately I've got this nice badness on mdio bus removal:
Device 'e0103120:06' does not have a release() function, it is broken and must be fixed.
------------[ cut here ]------------
Badness at drivers/base/core.c:107
NIP: c015c1a8 LR: c015c1a8 CTR: c0157488
REGS: c34bdcf0 TRAP: 0700 Not tainted (2.6.23-rc5-g9ebadfbb-dirty)
MSR: 00029032 <EE,ME,IR,DR> CR: 24088422 XER: 00000000
...
[c34bdda0] [c015c1a8] device_release+0x78/0x80 (unreliable)
[c34bddb0] [c01354cc] kobject_cleanup+0x80/0xbc
[c34bddd0] [c01365f0] kref_put+0x54/0x6c
[c34bdde0] [c013543c] kobject_put+0x24/0x34
[c34bddf0] [c015c384] put_device+0x1c/0x2c
[c34bde00] [c0180e84] mdiobus_unregister+0x2c/0x58
...
Though actually there is nothing broken, it just device
subsystem core expects another "pattern" of resource managment.
This patch implement phy device's release function, thus
we're getting rid of this badness.
Also small hidden bug fixed, hope none other introduced. ;-)
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/phy/mdio_bus.c | 9 +++++----
drivers/net/phy/phy_device.c | 13 +++++++++++++
include/linux/phy.h | 1 +
3 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index fc2f0e6..c30196d 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -91,9 +91,12 @@ int mdiobus_register(struct mii_bus *bus)
err = device_register(&phydev->dev);
- if (err)
+ if (err) {
printk(KERN_ERR "phy %d failed to register\n",
i);
+ phy_device_free(phydev);
+ phydev = NULL;
+ }
}
bus->phy_map[i] = phydev;
@@ -110,10 +113,8 @@ void mdiobus_unregister(struct mii_bus *bus)
int i;
for (i = 0; i < PHY_MAX_ADDR; i++) {
- if (bus->phy_map[i]) {
+ if (bus->phy_map[i])
device_unregister(&bus->phy_map[i]->dev);
- kfree(bus->phy_map[i]);
- }
}
}
EXPORT_SYMBOL(mdiobus_unregister);
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index e275df8..80c283c 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -44,6 +44,17 @@ static struct phy_driver genphy_driver;
extern int mdio_bus_init(void);
extern void mdio_bus_exit(void);
+void phy_device_free(struct phy_device *phydev)
+{
+ kfree(phydev);
+}
+EXPORT_SYMBOL(phy_device_free);
+
+static void phy_device_release(struct device *dev)
+{
+ phy_device_free(to_phy_device(dev));
+}
+
struct phy_device* phy_device_create(struct mii_bus *bus, int addr, int phy_id)
{
struct phy_device *dev;
@@ -54,6 +65,8 @@ struct phy_device* phy_device_create(struct mii_bus *bus, int addr, int phy_id)
if (NULL == dev)
return (struct phy_device*) PTR_ERR((void*)-ENOMEM);
+ dev->dev.release = phy_device_release;
+
dev->speed = 0;
dev->duplex = -1;
dev->pause = dev->asym_pause = 0;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 2a65978..9ec1363 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -398,6 +398,7 @@ int phy_mii_ioctl(struct phy_device *phydev,
int phy_start_interrupts(struct phy_device *phydev);
void phy_print_status(struct phy_device *phydev);
struct phy_device* phy_device_create(struct mii_bus *bus, int addr, int phy_id);
+void phy_device_free(struct phy_device *phydev);
extern struct bus_type mdio_bus_type;
#endif /* __PHY_H */
--
1.5.0.6
^ permalink raw reply related
* Re: [PATCH 06/15] Correctly calculate the size of the local-store to dump
From: Arnd Bergmann @ 2007-09-12 11:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jeremy Kerr, linux-kernel
In-Reply-To: <895526252184eee5548e553d1cfec642b7fc68b8.1189583010.git.michael@ellerman.id.au>
On Wednesday 12 September 2007, Michael Ellerman wrote:
> The routine to dump the local store, __spufs_mem_read(), does not take the
> spu_lslr_RW value into account - so we shouldn't check it when we're
> calculating the size either.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
^ permalink raw reply
* Re: [PATCH] powerpc: add new required termio functions
From: Christoph Hellwig @ 2007-09-12 11:34 UTC (permalink / raw)
To: Andrew Morton
Cc: Michael Neuling, Heiko Carstens, linux-kernel, linuxppc-dev,
paulus, Alan Cox, Linus Torvalds, David S. Miller,
Martin Schwidefsky
In-Reply-To: <20070912040109.3f6a9149.akpm@linux-foundation.org>
On Wed, Sep 12, 2007 at 04:01:09AM -0700, Andrew Morton wrote:
> On Wed, 12 Sep 2007 12:20:32 +0200 Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
>
> > On Wed, Sep 12, 2007 at 12:04:39PM +1000, Michael Neuling wrote:
> > > The "tty: termios locking functions break with new termios type" patch
> > > (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
> > > [...]
> > > I'm guessing other architectures are broken too?
> >
> > FWIW, the above quoted patch breaks s390 as well.
>
> Does this fix it?
I might be missing something, but the the right fix is probably to
apply the arch patches from Alan to powerpc and s390. We don't want to
be left over without all the nice termios features on these platforms,
do we?
^ permalink raw reply
* Re: SYSFS: need a noncaching read
From: Greg KH @ 2007-09-12 11:39 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev, linux-kernel, Detlev Zundel
In-Reply-To: <1189595612.6659.23.camel@Zeus.EmbLux>
On Wed, Sep 12, 2007 at 01:13:32PM +0200, Heiko Schocher wrote:
> Hello Greg
>
> Am Mittwoch, den 12.09.2007, 03:01 -0700 schrieb Greg KH:
> > On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
> > > On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > > > I have developed a device driver and use the sysFS to export some
> > > > registers to userspace.
> > >
> > > Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
> > > not to play around with registers from userspace.
> > >
> > > > I opened the sysFS File for one register and did some reads from this
> > > > File, but I alwas becoming the same value from the register, whats not
> > > > OK, because they are changing. So I found out that the sysFS caches
> > > > the reads ... :-(
> > >
> > > Yes, it does. What you can do is close()ing the file handle between
> > > accesses, which makes it work but is slow.
> >
> > Do an lseek back to 0 and then re-read, you will get called in your
> > driver again.
>
> No thats not true. I thought this too, but if I make a:
>
> seek (fd, 0L, SEEK_SET);
>
> in Userspace, there is no retrigger in the sysFS, my driver is *not*
> called again. So I made a own sysfs_seek function, which does retrigger
> the driver ...
Hm, are you sure? Otherwise the poll() stuff would not work at all.
> Is this really wanted in the sysFS, that there is no way to retrigger a
> read?
Yes, use the sysfs poll/select stuff to do that.
And "sysfs" has no upper-case letters :)
thanks,
greg k-h
^ permalink raw reply
* resume crashes with active cpufreq_userspace
From: Olaf Hering @ 2007-09-12 11:51 UTC (permalink / raw)
To: linuxppc-dev
2.6.22.5 crashes on resume on an iBook G3 600MHz. when cpufreq_userspace is
active. System is PowerBook4,3, 750FX revision 2.3
2.6.18 crashed also on resume, but I dont know if this was the same bug.
The oopes differ. Once I get an 'Unrecoverable FP Unavailable
Exception 801' in audit_log_vformat, hald-addon-cpuf was the active task.
Only the first two function were printed in the oops backtrace.
Another one was during a pagefault in cpufreq code, while events/0 was
the active task.
Most of the time, the screen stays black with only the cursor in the
upper left corner, sometimes not even that.
Resume seems to work ok on other models, like my own ibook with 745/755
cpu, revision 51.17, PowerBook4,1
^ permalink raw reply
* Re: [PATCH] powerpc: add new required termio functions
From: Heiko Carstens @ 2007-09-12 11:52 UTC (permalink / raw)
To: Christoph Hellwig, Andrew Morton, Michael Neuling, Linus Torvalds,
paulus, Alan Cox, David S. Miller, linux-kernel, linuxppc-dev,
Martin Schwidefsky
In-Reply-To: <20070912113409.GA7253@infradead.org>
On Wed, Sep 12, 2007 at 12:34:09PM +0100, Christoph Hellwig wrote:
> On Wed, Sep 12, 2007 at 04:01:09AM -0700, Andrew Morton wrote:
> > On Wed, 12 Sep 2007 12:20:32 +0200 Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> >
> > > On Wed, Sep 12, 2007 at 12:04:39PM +1000, Michael Neuling wrote:
> > > > The "tty: termios locking functions break with new termios type" patch
> > > > (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
> > > > [...]
> > > > I'm guessing other architectures are broken too?
> > >
> > > FWIW, the above quoted patch breaks s390 as well.
> >
> > Does this fix it?
Yes, it does.
> I might be missing something, but the the right fix is probably to
> apply the arch patches from Alan to powerpc and s390. We don't want to
> be left over without all the nice termios features on these platforms,
> do we?
But not in rc6 timeframe, I would guess?
^ permalink raw reply
* Re: SYSFS: need a noncaching read
From: Heiko Schocher @ 2007-09-12 11:59 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-kernel, Detlev Zundel
In-Reply-To: <20070912113907.GA24087@kroah.com>
Hello Greg,
Am Mittwoch, den 12.09.2007, 04:39 -0700 schrieb Greg KH:
> > > Do an lseek back to 0 and then re-read, you will get called in your
> > > driver again.
> >
> > No thats not true. I thought this too, but if I make a:
> >
> > seek (fd, 0L, SEEK_SET);
> >
> > in Userspace, there is no retrigger in the sysFS, my driver is *not*
> > called again. So I made a own sysfs_seek function, which does retrigger
> > the driver ...
>
> Hm, are you sure? Otherwise the poll() stuff would not work at all.
Yes.
Sysfs uses generic_file_llseek (). And in sysfs_read_file ()
buffer->needs_read_fill must be 1, to reread from the driver.
generic_file_llseek () doesnt change this variable.
Best regards
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* [PATCH] IB/ehca: Make sure user pages are from hugetlb before using MR large pages
From: Joachim Fenkes @ 2007-09-12 12:39 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier, OF-EWG
Cc: Stefan Roscher, Christoph Raisch
From: Hoang-Nam Nguyen <hnguyen@de.ibm.com>
...because, on virtualized hardware like System p, we can't be sure that the
physical pages behind them are contiguous.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
Another patch for 2.6.24 that will apply cleanly on top of my previous
patchset. Please review and apply. Thanks!
drivers/infiniband/hw/ehca/ehca_classes.h | 8 ++--
drivers/infiniband/hw/ehca/ehca_mrmw.c | 82 +++++++++++++++++++++++++----
2 files changed, 75 insertions(+), 15 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h b/drivers/infiniband/hw/ehca/ehca_classes.h
index 206d4eb..c2edd4c 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -99,10 +99,10 @@ struct ehca_sport {
struct ehca_sma_attr saved_attr;
};
-#define HCA_CAP_MR_PGSIZE_4K 1
-#define HCA_CAP_MR_PGSIZE_64K 2
-#define HCA_CAP_MR_PGSIZE_1M 4
-#define HCA_CAP_MR_PGSIZE_16M 8
+#define HCA_CAP_MR_PGSIZE_4K 0x80000000
+#define HCA_CAP_MR_PGSIZE_64K 0x40000000
+#define HCA_CAP_MR_PGSIZE_1M 0x20000000
+#define HCA_CAP_MR_PGSIZE_16M 0x10000000
struct ehca_shca {
struct ib_device ib_device;
diff --git a/drivers/infiniband/hw/ehca/ehca_mrmw.c b/drivers/infiniband/hw/ehca/ehca_mrmw.c
index 4c8f3b3..1bb9d23 100644
--- a/drivers/infiniband/hw/ehca/ehca_mrmw.c
+++ b/drivers/infiniband/hw/ehca/ehca_mrmw.c
@@ -41,6 +41,8 @@
*/
#include <asm/current.h>
+#include <linux/mm.h>
+#include <linux/hugetlb.h>
#include <rdma/ib_umem.h>
@@ -51,6 +53,7 @@
#define NUM_CHUNKS(length, chunk_size) \
(((length) + (chunk_size - 1)) / (chunk_size))
+
/* max number of rpages (per hcall register_rpages) */
#define MAX_RPAGES 512
@@ -279,6 +282,52 @@ reg_phys_mr_exit0:
} /* end ehca_reg_phys_mr() */
/*----------------------------------------------------------------------*/
+static int ehca_is_mem_hugetlb(unsigned long addr, unsigned long size)
+{
+ struct vm_area_struct **vma_list;
+ unsigned long cur_base;
+ unsigned long npages;
+ int ret, i;
+
+ vma_list = (struct vm_area_struct **) __get_free_page(GFP_KERNEL);
+ if (!vma_list) {
+ ehca_gen_err("Can not alloc vma_list");
+ return -ENOMEM;
+ }
+
+ down_write(¤t->mm->mmap_sem);
+ npages = PAGE_ALIGN(size + (addr & ~PAGE_MASK)) >> PAGE_SHIFT;
+ cur_base = addr & PAGE_MASK;
+
+ while (npages) {
+ ret = get_user_pages(current, current->mm, cur_base,
+ min_t(int, npages,
+ PAGE_SIZE / sizeof (*vma_list)),
+ 1, 0, NULL, vma_list);
+
+ if (ret < 0) {
+ ehca_gen_err("get_user_pages() failed "
+ "ret=%x cur_base=%lx", ret, cur_base);
+ goto is_hugetlb_out;
+ }
+
+ for (i = 0; i < ret; ++i)
+ if (!is_vm_hugetlb_page(vma_list[i])) {
+ ret = 0;
+ goto is_hugetlb_out;
+ }
+
+ cur_base += ret * PAGE_SIZE;
+ npages -= ret;
+ }
+ ret = 1;
+
+is_hugetlb_out:
+ up_write(¤t->mm->mmap_sem);
+ free_page((unsigned long) vma_list);
+
+ return ret;
+}
struct ib_mr *ehca_reg_user_mr(struct ib_pd *pd, u64 start, u64 length,
u64 virt, int mr_access_flags,
@@ -346,18 +395,29 @@ struct ib_mr *ehca_reg_user_mr(struct ib_pd *pd, u64 start, u64 length,
num_kpages = NUM_CHUNKS((virt % PAGE_SIZE) + length, PAGE_SIZE);
/* select proper hw_pgsize */
if (ehca_mr_largepage &&
- (shca->hca_cap_mr_pgsize & HCA_CAP_MR_PGSIZE_16M)) {
- if (length <= EHCA_MR_PGSIZE4K
- && PAGE_SIZE == EHCA_MR_PGSIZE4K)
- hwpage_size = EHCA_MR_PGSIZE4K;
- else if (length <= EHCA_MR_PGSIZE64K)
- hwpage_size = EHCA_MR_PGSIZE64K;
- else if (length <= EHCA_MR_PGSIZE1M)
- hwpage_size = EHCA_MR_PGSIZE1M;
- else
- hwpage_size = EHCA_MR_PGSIZE16M;
+ shca->hca_cap_mr_pgsize & HCA_CAP_MR_PGSIZE_16M) {
+ ret = ehca_is_mem_hugetlb(virt, length);
+ switch (ret) {
+ case 0: /* mem is not from hugetlb */
+ hwpage_size = PAGE_SIZE;
+ break;
+ case 1:
+ if (length <= EHCA_MR_PGSIZE4K
+ && PAGE_SIZE == EHCA_MR_PGSIZE4K)
+ hwpage_size = EHCA_MR_PGSIZE4K;
+ else if (length <= EHCA_MR_PGSIZE64K)
+ hwpage_size = EHCA_MR_PGSIZE64K;
+ else if (length <= EHCA_MR_PGSIZE1M)
+ hwpage_size = EHCA_MR_PGSIZE1M;
+ else
+ hwpage_size = EHCA_MR_PGSIZE16M;
+ break;
+ default: /* out of mem */
+ ib_mr = ERR_PTR(-ENOMEM);
+ goto reg_user_mr_exit1;
+ }
} else
- hwpage_size = EHCA_MR_PGSIZE4K;
+ hwpage_size = EHCA_MR_PGSIZE4K; /* ehca1 can only 4k */
ehca_dbg(pd->device, "hwpage_size=%lx", hwpage_size);
reg_user_mr_fallback:
--
1.5.2
^ permalink raw reply related
* Re: new NAPI interface broken for POWER architecture?
From: Christoph Raisch @ 2007-09-12 13:10 UTC (permalink / raw)
To: David Miller
Cc: ossthema, Paul Mackerras, netdev, Jan-Bernd Themann, linuxppc-dev,
Arnd Bergmann, Michael Ellerman, shemminger
In-Reply-To: <20070912.055004.88490155.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote on 12.09.2007 14:50:04:
> From: Jan-Bernd Themann <ossthema@de.ibm.com>
> Date: Fri, 7 Sep 2007 11:37:02 +0200
>
> > 2) On SMP systems: after netif_rx_complete has been called on CPU1
> > (+interruts enabled), netif_rx_schedule could be called on CPU2
> > (irq handler) before net_rx_action on CPU1 has checked
NAPI_STATE_SCHED.
> > In that case the device would be added to poll lists of CPU1 and
CPU2
> > as net_rx_action would see NAPI_STATE_SCHED set.
> > This must not happen. It will be caught when netif_rx_complete is
> > called the second time (BUG() called)
> >
> > This would mean we have a problem on all SMP machines right now.
>
> This is not a correct statement.
>
> Only on your platform do network device interrupts get moved
> around, no other platform does this.
>
> Sparc64 doesn't, all interrupts stay in one location after
> the cpu is initially choosen.
>
> x86 and x86_64 specifically do not move around network
> device interrupts, even though other device types do
> get dynamic IRQ cpu distribution.
>
> That's why you are the only person seeing this problem.
>
> I agree that it should be fixed, but we should also fix the IRQ
> distribution scheme used on powerpc platforms which is totally
> broken in these cases.
This is definitely not something we can change in the HEA device driver
alone.
It could also affect any other networking cards on POWER (e1000,s2io...).
Paul, Michael, Arndt, what is your opinion here?
Gruss / Regards
Christoph Raisch
^ permalink raw reply
* Re: new NAPI interface broken for POWER architecture?
From: David Miller @ 2007-09-12 13:27 UTC (permalink / raw)
To: RAISCH
Cc: ossthema, pmac, netdev, THEMANN, linuxppc-dev, ARNDB, ellerman,
shemminger
In-Reply-To: <OF2D6ED296.BDB04FBF-ONC1257354.00473703-C1257354.0048406C@de.ibm.com>
From: Christoph Raisch <RAISCH@de.ibm.com>
Date: Wed, 12 Sep 2007 15:10:08 +0200
> This is definitely not something we can change in the HEA device driver
> alone.
And it shouldn't be, x86 implements the policy in irq balance
daemon, powerpc should do it wherever it would be appropriate
there.
> Paul, Michael, Arndt, what is your opinion here?
I'm all ears too :)
^ 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