Re: ALSA fixes for non-coherent ppc32 again
At Mon, 22 Jun 2009 08:34:38 +1000, Benjamin Herrenschmidt wrote: > > On Sun, 2009-06-21 at 20:18 +0200, Gerhard Pircher wrote: > > Hi, > > > > Takashi Iwai posted patches to make ALSA work on non-coherent PPC32 > > systems (almost exactly) a year ago. See here: > > http://www.nabble.com/-PATCH-0-3--ALSA-fixes-for-non-coherent-ppc32-to17980027.html#a17980027 > > > > As far as I can see these patches never went upstream. Where there any > > objections or did we just forget about them? It would be cool, if the > > patches could be merged now, as at least two platforms need this bugfix > > (namely Sam440 and AmigaOne). > > I definitely forgot about those... Me, too, almost... :) > But I'm fine with what Takashi did > for now, I can always make the powerpc helper for dma_mmap_coherent() > smarter later on if necessary. I updated the patch series for 2.6.31, including sparc32, parisc, mips and sh support. The patches are found in test/dma-fix branch of sound git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git test/dma-fix The old patches for 2.6.30 is found at history/dma-fix-2.6.30 branch there, too. For merging to the upstream, we'll need definitely discussions on linux-arch ML or so, as once James Bottomley suggested. I'll try to make it up once after the merge window. But, it'd be helpful if someone can test the patches above beforehand, of course :) thanks, Takashi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Badness at drivers/char/tty_ldisc.c:210 during shutdown
On Mon, 2009-06-22 at 12:13 +0530, Sachin Sant wrote: > Sachin Sant wrote: > > I came across the following badness message during shutdown on a > > Power6 box. > > This was with 2.6.30-git12(3fe0344faf7fdcb158bd5c1a9aec960a8d70c8e8) > > > > [ cut here ] > > Badness at drivers/char/tty_ldisc.c:210 > The badness message is still present with git18. > > [ cut here ] > Badness at drivers/char/tty_ldisc.c:210 > NIP: c040a3e8 LR: c040a3d0 CTR: > REGS: c0003cf6b7f0 TRAP: 0700 Not tainted (2.6.30-git18) > MSR: 80029032 CR: 24000424 XER: 0001 > TASK = c0003e308660[3846] 'vhangup' THREAD: c0003cf68000 CPU: 1 > <6>GPR00: 0001 c0003cf6ba70 c0ef48c0 0001 > <6>GPR04: 0001 c0003819f000 c0407b60 > <6>GPR08: 0001 c0e1bce8 > <6>GPR12: 44000428 c1002600 > <6>GPR16: 21fd8a50 0002 21fc03b0 > <6>GPR20: c0003d04c700 0001 > <6>GPR24: 0001 c00040007e20 > <6>GPR28: c13ffd38 c0e7e860 c0003cf6ba70 > NIP [c040a3e8] .tty_ldisc_put+0xbc/0xf4 > LR [c040a3d0] .tty_ldisc_put+0xa4/0xf4 > Call Trace: > [c0003cf6ba70] [c040a3d0] .tty_ldisc_put+0xa4/0xf4 (unreliable) > [c0003cf6bb10] [c040a7c8] .tty_ldisc_reinit+0x38/0x80 > [c0003cf6bba0] [c040b1d8] .tty_ldisc_hangup+0x190/0x260 > [c0003cf6bc40] [c0401090] .do_tty_hangup+0x188/0x4c0 > [c0003cf6bd20] [c0401440] .tty_vhangup_self+0x34/0x54 > [c0003cf6bdb0] [c019236c] .sys_vhangup+0x38/0x58 > [c0003cf6be30] [c0008534] syscall_exit+0x0/0x40 > Instruction dump: > 912b0088 4bcd17bd 6000 e87e8008 7f44d378 481c04fd 6000 801b0008 > 7c09fe70 7d200278 7c004850 54000ffe <0b00> 7f63db78 4bd7c98d 6000 Ah right, so this has check has just gone in, and the code in question has been rewritten somewhat just recently. commit 677ca3060c474d7d89941948e32493d9c18c52d2 Author: Alan Cox Date: Tue Jun 16 17:00:53 2009 +0100 ldisc: debug aids Signed-off-by: Linus Torvalds diff --git a/drivers/char/tty_ldisc.c b/drivers/char/tty_ldisc.c index 874c248..a19e935 100644 --- a/drivers/char/tty_ldisc.c +++ b/drivers/char/tty_ldisc.c @@ -207,6 +207,7 @@ static void tty_ldisc_put(struct tty_ldisc *ld) ldo->refcount--; module_put(ldo->owner); spin_unlock_irqrestore(&tty_ldisc_lock, flags); + WARN_ON(ld->refcount); kfree(ld); } I don't grok this code much, but is the WARN racing with something else doing a get? ie. what is the value of ld->refcount before we drop the lock? > Let me know if i can provide any other information. Try enabling TTY_DEBUG_HANGUP in drivers/char/tty_io.c ? cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] fbdev: work around old compiler bug
When building with a 4.1.x compiler on powerpc64 (at least) we get
this error:
drivers/video/logo/logo_linux_mono.c:81: error: logo_linux_mono causes a
section type conflict
This was introduced by commit ae52bb2384f721562f15f719de1acb8e934733cb
("fbdev: move logo externs to header file"). This is a partial revert
of that commit sufficient to not hit the compiler bug.
Signed-off-by: Stephen Rothwell
---
scripts/pnmtologo.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/pnmtologo.c b/scripts/pnmtologo.c
index 64f5ddb..d10c389 100644
--- a/scripts/pnmtologo.c
+++ b/scripts/pnmtologo.c
@@ -237,7 +237,7 @@ static void write_header(void)
fprintf(out, " * Linux logo %s\n", logoname);
fputs(" */\n\n", out);
fputs("#include \n\n", out);
-fprintf(out, "static const unsigned char %s_data[] __initconst = {\n",
+fprintf(out, "static unsigned char %s_data[] __initdata = {\n",
logoname);
}
--
1.6.3.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] fbdev: work around old compiler bug
On Mon, 22 Jun 2009 18:04:20 +1000 Stephen Rothwell wrote: > > When building with a 4.1.x compiler on powerpc64 (at least) we get > this error: Ignore this, it causes more problems: drivers/video/logo/logo_linux_clut224.c:548: error: logo_linux_clut224_clut causes a section type conflict I'll work on a better solution. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpnXlePDq7bG.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Badness at drivers/char/tty_ldisc.c:210 during shutdown
> > [c0003cf6ba70] [c040a3d0] .tty_ldisc_put+0xa4/0xf4 (unreliable) > > [c0003cf6bb10] [c040a7c8] .tty_ldisc_reinit+0x38/0x80 > > [c0003cf6bba0] [c040b1d8] .tty_ldisc_hangup+0x190/0x260 > > [c0003cf6bc40] [c0401090] .do_tty_hangup+0x188/0x4c0 > > [c0003cf6bd20] [c0401440] .tty_vhangup_self+0x34/0x54 > > [c0003cf6bdb0] [c019236c] .sys_vhangup+0x38/0x58 > > [c0003cf6be30] [c0008534] syscall_exit+0x0/0x40 > > Instruction dump: > > 912b0088 4bcd17bd 6000 e87e8008 7f44d378 481c04fd 6000 801b0008 > > 7c09fe70 7d200278 7c004850 54000ffe <0b00> 7f63db78 4bd7c98d 6000 > > Ah right, so this has check has just gone in, and the code in question > has been rewritten somewhat just recently. The check is to catch any cases where a line discipline is being freed up but has a refcount that is non zero. I think I know what is going on here. Alan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)
Hello! Is there any idea for the solution? Thanks: blackluck Laszlo Fekete wrote: Hello! I'm sorry about the annoyances, but I'd welcome all ideas, suggestions to see what needs to be done or should be tested for the solution. Thank you very much! Guennadi Liakhovetski wrote: Ok, first attempt to forward this to scsi was wrong, as pointed out by Matthew Wilcox this does indeed look like an interrupt problem - no interrupts drom SCSI, IDE, keyboar. Might be a known problem, I guess. In any case, I think, the OP would be grateful for any hints. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- Forwarded message -- Date: Sat, 13 Jun 2009 16:22:07 +0200 From: Laszlo Fekete To: debian-powe...@lists.debian.org Subject: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 Resent-Date: Sat, 13 Jun 2009 14:29:55 + (UTC) Resent-From: debian-powe...@lists.debian.org This is a multi-part message in MIME format. Hello! Pls help me with sym scsi driver problem. I have Ibm P610 (and tested it on P630 and P640 too), installed debian etch and upgraded to lenny. But with 2.6.26 or newer kernel it's not booting, it's hang on sym scsi bus scan. Whats the problem with it, or how can I fix this? I attach the output from minicom with 2.6.29, 2.6.26, and the working 2.6.24 kernel booting. Thank you very much! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ALSA fixes for non-coherent ppc32 again
Original-Nachricht > Datum: Mon, 22 Jun 2009 09:12:35 +0200 > Von: Takashi Iwai > An: Benjamin Herrenschmidt > CC: Gerhard Pircher , linuxppc-...@ozlabs.org > Betreff: Re: ALSA fixes for non-coherent ppc32 again > At Mon, 22 Jun 2009 08:34:38 +1000, > Benjamin Herrenschmidt wrote: > > > > On Sun, 2009-06-21 at 20:18 +0200, Gerhard Pircher wrote: > > > Hi, > > > > > > Takashi Iwai posted patches to make ALSA work on non-coherent PPC32 > > > systems (almost exactly) a year ago. See here: > > > > > > http://www.nabble.com/-PATCH-0-3--ALSA-fixes-for-non-coherent-ppc32-to17980027.html#a17980027 > > > > > > As far as I can see these patches never went upstream. Where there > > > any objections or did we just forget about them? It would be cool, > > > if the patches could be merged now, as at least two platforms need > > > this bugfix (namely Sam440 and AmigaOne). > > > > I definitely forgot about those... > > Me, too, almost... :) :) > > But I'm fine with what Takashi did > > for now, I can always make the powerpc helper for dma_mmap_coherent() > > smarter later on if necessary. > > I updated the patch series for 2.6.31, including sparc32, parisc, mips > and sh support. The patches are found in test/dma-fix branch of sound > git tree: > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git > test/dma-fix Thanks! > The old patches for 2.6.30 is found at history/dma-fix-2.6.30 branch > there, too. > > > For merging to the upstream, we'll need definitely discussions on > linux-arch ML or so, as once James Bottomley suggested. I'll try to > make it up once after the merge window. > > But, it'd be helpful if someone can test the patches above beforehand, > of course :) Sure, I'll give it a try until tomorrow. Gerhard -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kilauea/405ex external interrupts
On Friday 19 June 2009 10:00:52 Lada Podivin wrote:
> I'm writing a linux driver that uses an external interrupt (ppc 405ex). I'm
> using GPIO pin 30 (external IRQ 1) connected to UIC1. I'm aware of the
> virtual interrupt stuff, so I added a new node to my device tree in order
> to get proper virtual IRQ number. This node describes an external event and
> its connection to UIC via the mentioned ext. int. Here is a sample of the
> divce-tree:
> EXTEVENT: external_event {
> device_type = "external";
> #address-cells = <0>;
> #size-cells = <0>;
> #interrupt-cells = <2>;
> interrupts = <0x1e 0x1>;
> interrupt-parent = <&UIC1>;
> };
> ...
>
> Then I use function "irq_of_parse_and_map()" which returns the virtual IRQ
> number 22. So, "request_irq()" seems to be satisfied with this number. I
> can see this interrupt in the /proc/interrupts. But! When I connect a
> signal source to the pin 30, nothing happens - the interrupt service
> routine isn't called.
>
> Am I suppose to configure anything else? (e. g. pin multiplexing, further
> device-tree tuning...) Thank you!
Yes, this could very well be a problem of pin multiplexing. From looking at
the Kilauea GPIO/Pin mux configuration in U-Boot, GPIO30 is configured as GPIO
input and not as IRQ1. So this can't work. The easiest way to change this is
in U-Boot (include/configs/kilauea.h).
BTW: Are you using Kilauea or a custom 405EX board?
Best regards,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] fbdev: work around old compiler bug
On Mon, Jun 22, 2009 at 06:34:15PM +1000, Stephen Rothwell wrote: > On Mon, 22 Jun 2009 18:04:20 +1000 Stephen Rothwell > wrote: > > > > When building with a 4.1.x compiler on powerpc64 (at least) we get > > this error: > > Ignore this, it causes more problems: > > drivers/video/logo/logo_linux_clut224.c:548: error: logo_linux_clut224_clut > causes a section type conflict > > I'll work on a better solution. I have no time to experiemnt atm. But I have seen this before. It happens when we mix up const and non-const stuff. I would assume the simple solution is to replace _initconst with _initdata for all users. If you get it to work with powerpc then it works for everyone (or so it is usually). Sam ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kilauea/405ex external interrupts
Thanks for replies! 2009/6/22 Stefan Roese > Yes, this could very well be a problem of pin multiplexing. From looking at > the Kilauea GPIO/Pin mux configuration in U-Boot, GPIO30 is configured as > GPIO > input and not as IRQ1. So this can't work. The easiest way to change this > is > in U-Boot (include/configs/kilauea.h). > Right, the pin multiplexing was the problem. I didn't know that U-BOOT can do that - very useful information, thank you again! > > BTW: Are you using Kilauea or a custom 405EX board? > > Best regards, > Stefan > > Yes, it's the Kilauea board. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Sky CPU: redundant or incorrect tests on unsigned
count is unsigned and cannot be less than 0.
Signed-off-by: Roel Kluin
---
Can these be removed or do we need an `if (count > MAX)' test, and
what should MAX be then?
diff --git a/drivers/misc/hdpuftrs/hdpu_cpustate.c
b/drivers/misc/hdpuftrs/hdpu_cpustate.c
index 176fe4e..35000cf 100644
--- a/drivers/misc/hdpuftrs/hdpu_cpustate.c
+++ b/drivers/misc/hdpuftrs/hdpu_cpustate.c
@@ -121,8 +121,6 @@ static ssize_t cpustate_read(struct file *file, char *buf,
{
unsigned char data;
- if (count < 0)
- return -EFAULT;
if (count == 0)
return 0;
@@ -137,9 +135,6 @@ static ssize_t cpustate_write(struct file *file, const char
*buf,
{
unsigned char data;
- if (count < 0)
- return -EFAULT;
-
if (count == 0)
return 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
AW: PowerPC PCI DMA issues (prefetch/coherency?)
>The other part of the fix is in asm-powerpc/pgtable32.h. _PAGE_BASE >needs _PAGE_COHERENT in order to work correctly, and in fact there is >now a comment in there to that affect in 2.6.29. Backporting that change >has made it work on 2.6.26. Both this patch, and the fix to head_32.S >are needed for it to work correctly on older kernels. > >Chris Hello Chris, sorry for dummy, but if it possible, could you, please, send a corresponding summary patch of backporting you've done for older kernels? or just summary of that changes once again? Many thanks Sergej. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Boot failure on the powerstation with 2.6.30 latest
2.6.30-rc8 worked fine ... unless this is a known problem, I suppose I can begin bisecting. The boot log of the hang is: Please wait, loading kernel... Elf64 kernel loaded... Loading ramdisk... ramdisk loaded at 0250, size: 8280 Kbytes OF stdout device is: /ht/i...@8/ser...@2f8 Preparing to boot Linux version 2.6.30 (j...@claymoor) (gcc version 4.3.3 (Debian 4.3.3-10) ) #1 SMP Mon Jun 22 09:59:35 CDT 2009 command line: root=/dev/sda3 ro console=ttyS0,19200n1 memory layout at init: alloc_bottom : 02d16000 alloc_top: 3000 alloc_top_hi : 8000 rmo_top : 3000 ram_top : 8000 instantiating rtas at 0x2fff5000... done boot cpu hw idx starting cpu hw idx 0001... done starting cpu hw idx 0002... done starting cpu hw idx 0003... done copying OF device tree... Building dt strings... Building dt structure... Device tree strings 0x03117000 -> 0x03117640 Device tree struct 0x03118000 -> 0x0311b000 Calling quiesce... returning from prom_init So it looks like some type of early boot failure or handoff in head_64 James ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Boot failure on the powerstation with 2.6.30 latest
James, I was running into a similar hang on one of my Power boxes as well. Reverting c868d550115b9ccc0027c67265b9520790f05601 allowed by system to boot. It looks like that patch injected a bug where we can end up waiting on an uninitialized mutex: [c09f3c30] c052c7dc .mutex_lock+0x34/0x50 [c09f3cb0] c008b190 .get_online_cpus+0x3c/0x74 [c09f3d40] c0146cd0 .kmem_cache_create+0xcc/0x548 [c09f3e50] c0032ae0 .pgtable_cache_init+0x28/0x6c [c09f3ee0] c0780960 .start_kernel+0x1ec/0x520 [c09f3f90] c00083d8 .start_here_common+0x1c/0x44 The mutex gets initialized in cpu_hotplug_init, which doesn't get called until after pgtable_cache_init. -Brian James Bottomley wrote: > 2.6.30-rc8 worked fine ... unless this is a known problem, I suppose I > can begin bisecting. > > The boot log of the hang is: > > Please wait, loading kernel... >Elf64 kernel loaded... > Loading ramdisk... > ramdisk loaded at 0250, size: 8280 Kbytes > OF stdout device is: /ht/i...@8/ser...@2f8 > Preparing to boot Linux version 2.6.30 (j...@claymoor) (gcc version 4.3.3 > (Debian 4.3.3-10) ) #1 SMP Mon Jun 22 09:59:35 CDT 2009 > command line: root=/dev/sda3 ro console=ttyS0,19200n1 > memory layout at init: > alloc_bottom : 02d16000 > alloc_top: 3000 > alloc_top_hi : 8000 > rmo_top : 3000 > ram_top : 8000 > instantiating rtas at 0x2fff5000... done > boot cpu hw idx > starting cpu hw idx 0001... done > starting cpu hw idx 0002... done > starting cpu hw idx 0003... done > copying OF device tree... > Building dt strings... > Building dt structure... > Device tree strings 0x03117000 -> 0x03117640 > Device tree struct 0x03118000 -> 0x0311b000 > Calling quiesce... > returning from prom_init > > So it looks like some type of early boot failure or handoff in head_64 > > James > > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev -- Brian King Linux on Power Virtualization IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
ppc405ex GPIO mapping
Hi,
I am using kernel 2.6.25.20 on my Kilauea eval board (ppc405ex). I want to
access some GPIO's. I have configured my u-boot to reflect what GPIO
configuration I need. I try to access my GPIO's in my driver. When accessing
GPIO's, I get this error in the kernel <>. 0xef600800 is the base address of GPIO in
the ppc405ex.
It looks like GPIO's are not mapped in my kernel. I have tried to add this
entry in my dts file (under POB0: opb ) but it does not work:
GPIO: g...@ef600800
{
compatible = "ibm,gpio-405ex";
reg = ;
};
Any clues on this issues?
Thanks
Sylvain C.
This electronic message may contain proprietary and confidential information of
Verint Systems Inc., its affiliates and/or subsidiaries.
The information is intended to be for the use of the individual(s) or
entity(ies) named above. If you are not the intended recipient (or authorized
to receive this e-mail for the intended recipient), you may not use, copy,
disclose or distribute to anyone this message or any information contained in
this message. If you have received this electronic message in error, please
notify us by replying to this e-mail.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc405ex GPIO mapping
Hi, I have the same board and I had a similar problem. I use 2.6.30, so I don't know whether 2.6.25 supports the following - however, here's my suggestion. Set these options in your kernel config: CONFIG_GPIOLIB=y and CONFIG_PPC4xx_GPIO=y. Before compilation do "export KCPPFLAGS=-DARCH_NR_GPIOS=32" - you have to let the kernel know, that your GPIO has 32 pins (default value is 255) and compile the kernel. Then change the line compatible = "ibm,gpio-405ex"; to compatible = "ibm,ppc4xx-gpio"; Ok! After this long journey you shoul be able to work with your GPIO pins with functions like gpio_set_value() - from include/linux/gpio.h. Documentation of these functions can be seen at http://www.mjmwired.net/kernel/Documentation/gpio.txt So, this is my solution. Maybe there are better ones, but this works well for me :) Best, Lada Podivin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] spufs: remove redundant test on unsigned
Unsigned `len' cannot be less than 0.
Signed-off-by: Roel Kluin
---
Or should it be `if (!buf || len > MAX)' and what should MAX be then?
diff --git a/arch/powerpc/platforms/cell/spufs/sputrace.c
b/arch/powerpc/platforms/cell/spufs/sputrace.c
index d0b1f3f..8f799ee 100644
--- a/arch/powerpc/platforms/cell/spufs/sputrace.c
+++ b/arch/powerpc/platforms/cell/spufs/sputrace.c
@@ -73,7 +73,7 @@ static ssize_t sputrace_read(struct file *file, char __user
*buf,
{
int error = 0, cnt = 0;
- if (!buf || len < 0)
+ if (!buf)
return -EINVAL;
while (cnt < len) {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/2] fsldma: Add DMA_SLAVE support
On Fri, 2009-06-19 at 12:31 -0700, Ira Snyder wrote: > Use the DMA_SLAVE capability of the DMAEngine API to copy/from a > scatterlist into an arbitrary list of hardware address/length pairs. > > This allows a single DMA transaction to copy data from several different > devices into a scatterlist at the same time. > > This also adds support to enable some controller-specific features such as > external start and external pause for a DMA transaction. > > Signed-off-by: Ira W. Snyder > --- > > This patch depends on the "fsldma: split apart external pause and > request count features" patch. > > After discussion with Dan Williams, this is the third version of the > DMA_SLAVE API for the Freescale DMA controller. I've tested it heavily > with both drivers I have written against this API, an FPGA programmer > and an FPGA data grabber. > > Kumar, Dan asked me to add you to the CC list, so you can have a look at > this patch before he adds it to his tree. > > The other two small patches I posted earlier are very helpful in testing > this functionality. They make the fsldma driver leave the BWC (bandwidth > control) bits alone on the 83xx controller, as well as making the > external start feature available on 83xx. > Kumar, Leo, Can I get your acked-by's for the current state of async_tx.git/next? I just pushed out Ira's latest so it may take a moment to mirror out. Thanks, Dan The following changes since commit f234012f52a37e48f2330e1ca2df69800e797c3b: Linus Torvalds (1): Merge branch 'for-linus' of git://git.kernel.org/.../drzeus/mmc are available in the git repository at: ssh://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx.git next Dan Williams (1): dmaengine: move HIGHMEM64G restriction to ASYNC_TX_DMA Ira Snyder (4): fsldma: enable external start for the 83xx controller fsldma: do not clear bandwidth control bits on the 83xx controller fsldma: split apart external pause and request count features fsldma: Add DMA_SLAVE support Ira W. Snyder (1): fsldma: use PCI Read Multiple command arch/powerpc/include/asm/fsldma.h | 136 + drivers/dma/Kconfig |4 +- drivers/dma/fsldma.c | 287 ++--- drivers/dma/fsldma.h |4 +- 4 files changed, 408 insertions(+), 23 deletions(-) create mode 100644 arch/powerpc/include/asm/fsldma.h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/2] fsldma: Add DMA_SLAVE support
On Mon, 2009-06-22 at 14:20 -0700, Dan Williams wrote: > On Fri, 2009-06-19 at 12:31 -0700, Ira Snyder wrote: > > Use the DMA_SLAVE capability of the DMAEngine API to copy/from a > > scatterlist into an arbitrary list of hardware address/length pairs. > > > > This allows a single DMA transaction to copy data from several different > > devices into a scatterlist at the same time. > > > > This also adds support to enable some controller-specific features such as > > external start and external pause for a DMA transaction. > > > > Signed-off-by: Ira W. Snyder > > --- > > > > This patch depends on the "fsldma: split apart external pause and > > request count features" patch. > > > > After discussion with Dan Williams, this is the third version of the > > DMA_SLAVE API for the Freescale DMA controller. I've tested it heavily > > with both drivers I have written against this API, an FPGA programmer > > and an FPGA data grabber. > > > > Kumar, Dan asked me to add you to the CC list, so you can have a look at > > this patch before he adds it to his tree. > > > > The other two small patches I posted earlier are very helpful in testing > > this functionality. They make the fsldma driver leave the BWC (bandwidth > > control) bits alone on the 83xx controller, as well as making the > > external start feature available on 83xx. > > > > Kumar, Leo, > > Can I get your acked-by's for the current state of async_tx.git/next? I > just pushed out Ira's latest so it may take a moment to mirror out. > > Thanks, > Dan > > The following changes since commit f234012f52a37e48f2330e1ca2df69800e797c3b: > Linus Torvalds (1): > Merge branch 'for-linus' of git://git.kernel.org/.../drzeus/mmc > > are available in the git repository at: > > ssh://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx.git next That should be: git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx.git next ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Boot failure on the powerstation with 2.6.30 latest
On Mon, 2009-06-22 at 11:11 -0500, Brian King wrote: > James, > > I was running into a similar hang on one of my Power boxes as well. > Reverting c868d550115b9ccc0027c67265b9520790f05601 allowed by system > to boot. It looks like that patch injected a bug where we can end up > waiting on an uninitialized mutex: > > [c09f3c30] c052c7dc .mutex_lock+0x34/0x50 > [c09f3cb0] c008b190 .get_online_cpus+0x3c/0x74 > [c09f3d40] c0146cd0 .kmem_cache_create+0xcc/0x548 > [c09f3e50] c0032ae0 .pgtable_cache_init+0x28/0x6c > [c09f3ee0] c0780960 .start_kernel+0x1ec/0x520 > [c09f3f90] c00083d8 .start_here_common+0x1c/0x44 > > The mutex gets initialized in cpu_hotplug_init, which doesn't get called until > after pgtable_cache_init. Actually, no, reverting that one doesn't fix it. A full run of git bisect turns up this commit as the culprit; I'll make a fuss on lkml: 83b519e8b9572c319c8e0c615ee5dd7272856090 is first bad commit commit 83b519e8b9572c319c8e0c615ee5dd7272856090 Author: Pekka Enberg Date: Wed Jun 10 19:40:04 2009 +0300 slab: setup allocators earlier in the boot sequence James ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Boot failure on the powerstation with 2.6.30 latest
On Mon, 2009-06-22 at 11:11 -0500, Brian King wrote: > James, > > I was running into a similar hang on one of my Power boxes as well. > Reverting c868d550115b9ccc0027c67265b9520790f05601 allowed by system > to boot. It looks like that patch injected a bug where we can end up > waiting on an uninitialized mutex: > > [c09f3c30] c052c7dc .mutex_lock+0x34/0x50 > [c09f3cb0] c008b190 .get_online_cpus+0x3c/0x74 > [c09f3d40] c0146cd0 .kmem_cache_create+0xcc/0x548 > [c09f3e50] c0032ae0 .pgtable_cache_init+0x28/0x6c > [c09f3ee0] c0780960 .start_kernel+0x1ec/0x520 > [c09f3f90] c00083d8 .start_here_common+0x1c/0x44 > > The mutex gets initialized in cpu_hotplug_init, which doesn't get called until > after pgtable_cache_init. Ah good, I didn't have a chance to track that one down yet. So the problem here is that we must do pgtable_cache_init there because vmalloc is initialized right after, which relies on allocating page tables and that will need kmem caches on some archs. So I suspect we need to sort out this mutex, either initializing it from elsewhere, moving cpu_hotplug_init() earlier, or avoiding it when the kernel state isn't SYSTEM_RUNNING, I haven't looked in details yet. Cheers, Ben. > -Brian > > James Bottomley wrote: > > 2.6.30-rc8 worked fine ... unless this is a known problem, I suppose I > > can begin bisecting. > > > > The boot log of the hang is: > > > > Please wait, loading kernel... > >Elf64 kernel loaded... > > Loading ramdisk... > > ramdisk loaded at 0250, size: 8280 Kbytes > > OF stdout device is: /ht/i...@8/ser...@2f8 > > Preparing to boot Linux version 2.6.30 (j...@claymoor) (gcc version 4.3.3 > > (Debian 4.3.3-10) ) #1 SMP Mon Jun 22 09:59:35 CDT 2009 > > command line: root=/dev/sda3 ro console=ttyS0,19200n1 > > memory layout at init: > > alloc_bottom : 02d16000 > > alloc_top: 3000 > > alloc_top_hi : 8000 > > rmo_top : 3000 > > ram_top : 8000 > > instantiating rtas at 0x2fff5000... done > > boot cpu hw idx > > starting cpu hw idx 0001... done > > starting cpu hw idx 0002... done > > starting cpu hw idx 0003... done > > copying OF device tree... > > Building dt strings... > > Building dt structure... > > Device tree strings 0x03117000 -> 0x03117640 > > Device tree struct 0x03118000 -> 0x0311b000 > > Calling quiesce... > > returning from prom_init > > > > So it looks like some type of early boot failure or handoff in head_64 > > > > James > > > > > > ___ > > Linuxppc-dev mailing list > > Linuxppc-dev@lists.ozlabs.org > > https://lists.ozlabs.org/listinfo/linuxppc-dev > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Boot failure on the powerstation with 2.6.30 latest
> Actually, no, reverting that one doesn't fix it. > > A full run of git bisect turns up this commit as the culprit; I'll make > a fuss on lkml: I haven't had the full log of that boot failure, but reverting the patch Brian suggested won't work well indeed, as I said, from the moment slab is initialized, page table allocations will use kmem caches which are initialized by pgtable_cache_init(). So the problem does indeed seem to be another fallover of moving the allocator initialization earlier. I'm working from home today but I'll see if I can get somebody in the office to wire up the powerstation (got disconnected for some reason last week) for me so I can have a look. The mutex issue Brian noticed will definitely break _any_ kmem_cache operation anyway, so that's one bug that need fixing at least (well, provided Brian analysis is right, I didn't have a chance to look myself yet :-) Cheers, Ben. > 83b519e8b9572c319c8e0c615ee5dd7272856090 is first bad commit > commit 83b519e8b9572c319c8e0c615ee5dd7272856090 > Author: Pekka Enberg > Date: Wed Jun 10 19:40:04 2009 +0300 > > slab: setup allocators earlier in the boot sequence > > James > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)
On Mon, 2009-06-22 at 11:10 +0200, Laszlo Fekete wrote: > Hello! > > Is there any idea for the solution? Hard to tell yet. Looks indeed like something is wrong with the interrupt controller. Any chance you can bisect that ? I'll also have a look on my side, it's definitely not something obvious. Cheers, Ben. > Thanks: blackluck > > Laszlo Fekete wrote: > > Hello! > > > > I'm sorry about the annoyances, but I'd welcome all ideas, suggestions > > to see what needs to be done or should be tested for the solution. > > > > Thank you very much! > > > > Guennadi Liakhovetski wrote: > >> Ok, first attempt to forward this to scsi was wrong, as pointed out > >> by Matthew Wilcox this does indeed look like an interrupt problem - > >> no interrupts drom SCSI, IDE, keyboar. Might be a known problem, I > >> guess. In any case, I think, the OP would be grateful for any hints. > >> > >> Thanks > >> Guennadi > >> --- > >> Guennadi Liakhovetski, Ph.D. > >> Freelance Open-Source Software Developer > >> http://www.open-technology.de/ > >> > >> -- Forwarded message -- > >> Date: Sat, 13 Jun 2009 16:22:07 +0200 > >> From: Laszlo Fekete > >> To: debian-powe...@lists.debian.org > >> Subject: sym scsi driver problem with 2.6.26 or newer debian kernel > >> on p610 > >> Resent-Date: Sat, 13 Jun 2009 14:29:55 + (UTC) > >> Resent-From: debian-powe...@lists.debian.org > >> > >> This is a multi-part message in MIME format. > >> > >> > >> Hello! > >> > >> > >> > >> > >> > >> Pls help me with sym scsi driver problem. > >> > >> > >> > >> I have Ibm P610 (and tested it on P630 and P640 too), installed debian > >> > >> etch and upgraded to lenny. > >> > >> > >> > >> But with 2.6.26 or newer kernel it's not booting, it's hang on sym scsi > >> > >> bus scan. > >> > >> > >> > >> > >> > >> Whats the problem with it, or how can I fix this? > >> > >> > >> > >> > >> > >> I attach the output from minicom with 2.6.29, 2.6.26, and the working > >> > >> 2.6.24 kernel booting. > >> > >> > >> > >> > >> > >> Thank you very much! > >> > >> > >> > > > > > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/ps3: Use pr_devel() in ps3/mm.c
The non-debug case in ps3/mm.c uses pr_debug(), so that the compiler
still does type checks etc. and doesn't complain about unused
variables in the non-debug case.
However with DEBUG=n and CONFIG_DYNAMIC_DEBUG=y there's still code
generated for those pr_debugs().
size before:
textdata bss dec hex filename
175534112 88 2175354f9 arch/powerpc/platforms/ps3/mm.o
size after:
textdata bss dec hex filename
7377 776 8882412031 arch/powerpc/platforms/ps3/mm.o
Signed-off-by: Michael Ellerman
---
arch/powerpc/platforms/ps3/mm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/mm.c b/arch/powerpc/platforms/ps3/mm.c
index 846eb8b..68f1397 100644
--- a/arch/powerpc/platforms/ps3/mm.c
+++ b/arch/powerpc/platforms/ps3/mm.c
@@ -34,7 +34,7 @@
#if defined(DEBUG)
#define DBG udbg_printf
#else
-#define DBG pr_debug
+#define DBG pr_devel
#endif
enum {
--
1.6.2.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)
On Tue, 2009-06-23 at 11:18 +1000, Benjamin Herrenschmidt wrote: > On Mon, 2009-06-22 at 11:10 +0200, Laszlo Fekete wrote: > > Hello! > > > > Is there any idea for the solution? > > Hard to tell yet. Looks indeed like something is wrong with the > interrupt controller. > > Any chance you can bisect that ? I'll also have a look on my side, > it's definitely not something obvious. I tried on a POWER3 box I have here "IBM,7044-170" and things work fine here with current upstream. (I suspect a much smaller machine). I will really need an actual bisection here... In the meantime, I'll see if I can get my hand on one of these machines here. Cheers, Ben. > Cheers, > Ben. > > > Thanks: blackluck > > > > Laszlo Fekete wrote: > > > Hello! > > > > > > I'm sorry about the annoyances, but I'd welcome all ideas, suggestions > > > to see what needs to be done or should be tested for the solution. > > > > > > Thank you very much! > > > > > > Guennadi Liakhovetski wrote: > > >> Ok, first attempt to forward this to scsi was wrong, as pointed out > > >> by Matthew Wilcox this does indeed look like an interrupt problem - > > >> no interrupts drom SCSI, IDE, keyboar. Might be a known problem, I > > >> guess. In any case, I think, the OP would be grateful for any hints. > > >> > > >> Thanks > > >> Guennadi > > >> --- > > >> Guennadi Liakhovetski, Ph.D. > > >> Freelance Open-Source Software Developer > > >> http://www.open-technology.de/ > > >> > > >> -- Forwarded message -- > > >> Date: Sat, 13 Jun 2009 16:22:07 +0200 > > >> From: Laszlo Fekete > > >> To: debian-powe...@lists.debian.org > > >> Subject: sym scsi driver problem with 2.6.26 or newer debian kernel > > >> on p610 > > >> Resent-Date: Sat, 13 Jun 2009 14:29:55 + (UTC) > > >> Resent-From: debian-powe...@lists.debian.org > > >> > > >> This is a multi-part message in MIME format. > > >> > > >> > > >> Hello! > > >> > > >> > > >> > > >> > > >> > > >> Pls help me with sym scsi driver problem. > > >> > > >> > > >> > > >> I have Ibm P610 (and tested it on P630 and P640 too), installed debian > > >> > > >> etch and upgraded to lenny. > > >> > > >> > > >> > > >> But with 2.6.26 or newer kernel it's not booting, it's hang on sym scsi > > >> > > >> bus scan. > > >> > > >> > > >> > > >> > > >> > > >> Whats the problem with it, or how can I fix this? > > >> > > >> > > >> > > >> > > >> > > >> I attach the output from minicom with 2.6.29, 2.6.26, and the working > > >> > > >> 2.6.24 kernel booting. > > >> > > >> > > >> > > >> > > >> > > >> Thank you very much! > > >> > > >> > > >> > > > > > > > > > > ___ > > Linuxppc-dev mailing list > > Linuxppc-dev@lists.ozlabs.org > > https://lists.ozlabs.org/listinfo/linuxppc-dev > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)
On Sun, 2009-06-14 at 11:10 +0200, Guennadi Liakhovetski wrote: > P610 (and tested it on P630 and P640 too) Also, send me a tarball of /proc/device-tree please. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mpic: Fix mapping of "DCR" based MPIC variants
Commit 31207dab7d2e63795eb15823947bd2f7025b08e2
"Fix incorrect allocation of interrupt rev-map"
introduced a regression crashing on boot on machines using
a "DCR" based MPIC, such as the Cell blades.
The reason is that the irq host data structure is initialized
much later as a result of that patch, causing our calls to
mpic_map() do be done before we have a host setup.
Unfortunately, this breaks _mpic_map_dcr() which uses the
mpic->irqhost to get to the device node.
This fixes it by, instead, passing the device node explicitely
to mpic_map().
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/sysdev/mpic.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
--- linux-work.orig/arch/powerpc/sysdev/mpic.c 2009-06-23 11:30:14.0
+1000
+++ linux-work/arch/powerpc/sysdev/mpic.c 2009-06-23 11:45:17.0
+1000
@@ -279,28 +279,29 @@ static void _mpic_map_mmio(struct mpic *
}
#ifdef CONFIG_PPC_DCR
-static void _mpic_map_dcr(struct mpic *mpic, struct mpic_reg_bank *rb,
+static void _mpic_map_dcr(struct mpic *mpic, struct device_node *node,
+ struct mpic_reg_bank *rb,
unsigned int offset, unsigned int size)
{
const u32 *dbasep;
- dbasep = of_get_property(mpic->irqhost->of_node, "dcr-reg", NULL);
+ dbasep = of_get_property(node, "dcr-reg", NULL);
- rb->dhost = dcr_map(mpic->irqhost->of_node, *dbasep + offset, size);
+ rb->dhost = dcr_map(node, *dbasep + offset, size);
BUG_ON(!DCR_MAP_OK(rb->dhost));
}
-static inline void mpic_map(struct mpic *mpic, phys_addr_t phys_addr,
- struct mpic_reg_bank *rb, unsigned int offset,
- unsigned int size)
+static inline void mpic_map(struct mpic *mpic, struct device_node *node,
+ phys_addr_t phys_addr, struct mpic_reg_bank *rb,
+ unsigned int offset, unsigned int size)
{
if (mpic->flags & MPIC_USES_DCR)
- _mpic_map_dcr(mpic, rb, offset, size);
+ _mpic_map_dcr(mpic, node, rb, offset, size);
else
_mpic_map_mmio(mpic, phys_addr, rb, offset, size);
}
#else /* CONFIG_PPC_DCR */
-#define mpic_map(m,p,b,o,s)_mpic_map_mmio(m,p,b,o,s)
+#define mpic_map(m,n,p,b,o,s) _mpic_map_mmio(m,p,b,o,s)
#endif /* !CONFIG_PPC_DCR */
@@ -1152,8 +1153,8 @@ struct mpic * __init mpic_alloc(struct d
}
/* Map the global registers */
- mpic_map(mpic, paddr, &mpic->gregs, MPIC_INFO(GREG_BASE), 0x1000);
- mpic_map(mpic, paddr, &mpic->tmregs, MPIC_INFO(TIMER_BASE), 0x1000);
+ mpic_map(mpic, node, paddr, &mpic->gregs, MPIC_INFO(GREG_BASE), 0x1000);
+ mpic_map(mpic, node, paddr, &mpic->tmregs, MPIC_INFO(TIMER_BASE),
0x1000);
/* Reset */
if (flags & MPIC_WANTS_RESET) {
@@ -1194,7 +1195,7 @@ struct mpic * __init mpic_alloc(struct d
/* Map the per-CPU registers */
for (i = 0; i < mpic->num_cpus; i++) {
- mpic_map(mpic, paddr, &mpic->cpuregs[i],
+ mpic_map(mpic, node, paddr, &mpic->cpuregs[i],
MPIC_INFO(CPU_BASE) + i * MPIC_INFO(CPU_STRIDE),
0x1000);
}
@@ -1202,7 +1203,7 @@ struct mpic * __init mpic_alloc(struct d
/* Initialize main ISU if none provided */
if (mpic->isu_size == 0) {
mpic->isu_size = mpic->num_sources;
- mpic_map(mpic, paddr, &mpic->isus[0],
+ mpic_map(mpic, node, paddr, &mpic->isus[0],
MPIC_INFO(IRQ_BASE), MPIC_INFO(IRQ_STRIDE) *
mpic->isu_size);
}
mpic->isu_shift = 1 + __ilog2(mpic->isu_size - 1);
@@ -1256,8 +1257,10 @@ void __init mpic_assign_isu(struct mpic
BUG_ON(isu_num >= MPIC_MAX_ISU);
- mpic_map(mpic, paddr, &mpic->isus[isu_num], 0,
+ mpic_map(mpic, mpic->irqhost->of_node,
+paddr, &mpic->isus[isu_num], 0,
MPIC_INFO(IRQ_STRIDE) * mpic->isu_size);
+
if ((isu_first + mpic->isu_size) > mpic->num_sources)
mpic->num_sources = isu_first + mpic->isu_size;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RESEND][PATCH] SPI: xilinx_spi: Added platform driver and support for DS570
This appears to be a ppc thing, so let's cc that list. Let's also cc
the driver's author and other contributors. Please cc these people on
future versions of the patch also.
On Mon, 15 Jun 2009 17:17:54 +0200 Richard R__jfors
wrote:
> This patch splits xilinx_spi into three parts, an OF and a platform
> driver and generic part.
>
> The generic part now also works on X86 and also supports the Xilinx
> SPI IP DS570
>
>
> ...
>
> +#ifndef CONFIG_PPC
> +#define in_8(addr) ioread8(addr)
> +#define in_be16(addr) ioread16(addr)
> +#define in_be32(addr) ioread32(addr)
> +
> +#define out_8(addr, b) iowrite8(b, addr)
> +#define out_be16(addr, w) iowrite16(w, addr)
> +#define out_be32(addr, l) iowrite32(l, addr)
> +#endif
Why do we need these?
> +#define XSPI_WRITE8(xspi, offs, val) \
> + do { \
> + if (xspi->model == XILINX_SPI_MODEL_DS464) \
> + out_8(xspi->regs + offs, (val) & 0xff); \
> + else \
> + XSPI_WRITE32(xspi, offs, val); \
> + } while (0)
> +
> +#define XSPI_WRITE16(xspi, offs, val) \
> + do { \
> + if (xspi->model == XILINX_SPI_MODEL_DS464) \
> + out_be16(xspi->regs + offs, (val) & 0x); \
> + else \
> + XSPI_WRITE32(xspi, offs, val); \
> + } while (0)
> +
> +#define XSPI_WRITE32(xspi, offs, val) \
> + out_be32(xspi->regs + offs, val)
> +
> +#define XSPI_READ8(xspi, offs) \
> + (xspi->model == XILINX_SPI_MODEL_DS464) ? \
> + in_8(xspi->regs + offs) : XSPI_READ32(xspi, offs)
> +
> +#define XSPI_READ16(xspi, offs) \
> + (xspi->model == XILINX_SPI_MODEL_DS464) ? \
> + in_be16(xspi->regs + offs) : XSPI_READ32(xspi, offs)
> +
> +#define XSPI_READ32(xspi, offs) \
> + in_be32(xspi->regs + offs)
I'm seeing no reason why these had to be implemented as macros.
They're ugly, add considerable code bloat and, because they evaluate
their args multiple times they will fail if passed as expression with
side-effects.
I suggest that they be reimplemented as lower-case, uninlined C functions.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [ewg] Re: [PATCH 2.6.31 try 2] ehca: Tolerate dynamic memory operations and huge pages
thanks, applied. > -#define HCAD_VERSION "0026" > +#define HCAD_VERSION "0027" the driver version was already 0027 (since bde2cfaf), so I dropped this chunk. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Badness on the Warp
On Mon, 22 Jun 2009 08:25:04 +1000 Benjamin Herrenschmidt wrote: > Kumar already submitted a couple, Frans, feel free to beat me > at converting UIC (just use kmalloc directly in there instead > of alloc_bootmem). I replace the bootmem_alloc with a kzalloc and the badness went away. So it looks like, for my config anyway, that solves the problem. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] fbdev: work around old compiler bug
When building with a 4.1.x compiler on powerpc64 (at least) we get
this error:
drivers/video/logo/logo_linux_mono.c:81: error: logo_linux_mono causes a
section type conflict
This was introduced by commit ae52bb2384f721562f15f719de1acb8e934733cb
("fbdev: move logo externs to header file"). This is a partial revert
of that commit sufficient to not hit the compiler bug.
Signed-off-by: Stephen Rothwell
---
scripts/pnmtologo.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
v2: also convert _clut arrays from __initconst to __initdata.
diff --git a/scripts/pnmtologo.c b/scripts/pnmtologo.c
index 64f5ddb..5c11312 100644
--- a/scripts/pnmtologo.c
+++ b/scripts/pnmtologo.c
@@ -237,7 +237,7 @@ static void write_header(void)
fprintf(out, " * Linux logo %s\n", logoname);
fputs(" */\n\n", out);
fputs("#include \n\n", out);
-fprintf(out, "static const unsigned char %s_data[] __initconst = {\n",
+fprintf(out, "static unsigned char %s_data[] __initdata = {\n",
logoname);
}
@@ -374,7 +374,7 @@ static void write_logo_clut224(void)
fputs("\n};\n\n", out);
/* write logo clut */
-fprintf(out, "static const unsigned char %s_clut[] __initconst = {\n",
+fprintf(out, "static unsigned char %s_clut[] __initdata = {\n",
logoname);
write_hex_cnt = 0;
for (i = 0; i < logo_clutsize; i++) {
--
1.6.3.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc405ex GPIO mapping
Eh, sorry! I mean include/asm-generic/gpio.h NOT include/linux/gpio.h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
On Wednesday 17 June 2009 07:53:51 Grant Likely wrote: > David, what's the status of this patch? Will it be merged for 2.6.31? It's merged now. Thanks, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] sata_fsl: Add power mgmt support
Kumar Gala wrote: From: Dave Liu Signed-off-by: Dave Liu Signed-off-by: Liu Yu Signed-off-by: Kumar Gala --- drivers/ata/sata_fsl.c | 35 +++ 1 files changed, 35 insertions(+), 0 deletions(-) applied ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
