* Re: Fix small race in 44x tlbie function
From: Kumar Gala @ 2007-08-08 15:20 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras, Todd Inglett, Volkmar Uhlig
In-Reply-To: <20070807042050.GJ13522@localhost.localdomain>
On Aug 6, 2007, at 11:20 PM, David Gibson wrote:
> The 440 family of processors don't have a tlbie instruction. So, we
> implement TLB invalidates by explicitly searching the TLB with tlbsx.,
> then clobbering the relevant entry, if any. Unfortunately the PID for
> the search needs to be stored in the MMUCR register, which is also
> used by the TLB miss handler. Interrupts were enabled in _tlbie(), so
> an interrupt between loading the MMUCR and the tlbsx could cause
> incorrect search results, and thus a failure to invalide TLB entries
> which needed to be invalidated.
>
> This patch fixes the problem in both arch/ppc and arch/powerpc by
> inhibiting interrupts (even critical and debug interrupts) across the
> relevant instructions.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> Paul, this one's a bugfix, which I think should go into 2.6.23.
Did you actually see this happen?
- k
^ permalink raw reply
* how the bytes ordered in mpc8313
From: Yoni Levin @ 2007-08-08 15:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 348 bytes --]
I have mpc83xx,
I saw that I need to use swab32 to any read\write operation from registers,
I don't understand why I need it?
Do I need it for all registers?
Why in the mpc8313 reference in registers description some bits look like
31,30,29,.,3,2,1,0
And some: 0,1,2,3.,30,31
Is it just mistake? Or some registers are different then other?
[-- Attachment #2: Type: text/html, Size: 2738 bytes --]
^ permalink raw reply
* RE: Fix small race in 44x tlbie function
From: Volkmar Uhlig @ 2007-08-08 15:34 UTC (permalink / raw)
To: galak, david; +Cc: linuxppc-dev, paulus, Todd Inglett
> -----Original Message-----
> From: galak@kernel.crashing.org [mailto:galak@kernel.crashing.org]
> Sent: Wednesday, August 08, 2007 11:21 AM
> To: david@gibson.dropbear.id.au
> Cc: paulus@samba.org; linuxppc-dev@ozlabs.org; Todd Inglett;
> Volkmar Uhlig
> Subject: Re: Fix small race in 44x tlbie function
>
>
> On Aug 6, 2007, at 11:20 PM, David Gibson wrote:
>
> > The 440 family of processors don't have a tlbie instruction. So, we
> > implement TLB invalidates by explicitly searching the TLB
> with tlbsx.,
> > then clobbering the relevant entry, if any. Unfortunately
> the PID for
> > the search needs to be stored in the MMUCR register, which is also
> > used by the TLB miss handler. Interrupts were enabled in
> _tlbie(), so
> > an interrupt between loading the MMUCR and the tlbsx could cause
> > incorrect search results, and thus a failure to invalide TLB entries
> > which needed to be invalidated.
> >
> > This patch fixes the problem in both arch/ppc and arch/powerpc by
> > inhibiting interrupts (even critical and debug interrupts)
> across the
> > relevant instructions.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> > Paul, this one's a bugfix, which I think should go into 2.6.23.
>
> Did you actually see this happen?
Yes! (I guess you didn't get the initial mail...)
- Volkmar
^ permalink raw reply
* Re: no output to serial console from /init process on ml405
From: Wolfgang Reissnegger @ 2007-08-08 15:36 UTC (permalink / raw)
To: Anton Kowalski; +Cc: linuxppc-embedded
In-Reply-To: <e835b80a0708080428q59378732x52ee40f9702f5692@mail.gmail.com>
Hi Anton,
it looks as if your init executable is not doing the right thing and for
some reason terminates. Maybe your inittab configuration is wrong? Maybe
the init executable has been compiled with the wrong options?
You can try to copy another executable (e.g. sh, getty) into /init and
see if you get any output. If you see anything doing that then most
likely there's something wrong with your init executable.
Wolfgang
Anton Kowalski wrote:
> Hi All:
>
> I'm trying to bring up linux 2.6.21.1 on an ml405 board. The kernel
> boots fine but the init process does not produce any output. The /init
> program resides in an initramfs file system and I believe the /dev
> device files have been set up correctly. Here's an excerpt from my
> initramfs specification:
>
> dir /dev 755 0 0
> nod /dev/console 644 0 0 c 5 1
> nod /dev/ttyS0 644 0 0 c 4 64
>
> (I am able to open these files from the init program. I tested this by
> sleeping for a specified time on success.)
>
> Also, printk continues to function after /init terminates and before
> the kernel panics.
>
> Here are the last few lines of the console output:
>
> [ 0.507478] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports,
> IRQ sharing disabled
> [ 0.513862] serial8250.0: ttyS0 at MMIO 0x80201003 (irq = 3) is a 16550A
> [ 2.927509] RAMDISK driver initialized: 1 RAM disks of 8192K size
> 1024 blocksize
> [ 3.018391] tun: Universal TUN/TAP device driver, 1.6
> [ 3.079115] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
> [ 3.154919] mice: PS/2 mouse device common for all mice
> [ 3.218021] TCP cubic registered
> [ 3.257034] NET: Registered protocol family 1
> [ 3.309405] NET: Registered protocol family 17
> [ 3.363462] Freeing unused kernel memory: 300k init
> [ 23.488277] Kernel panic - not syncing: Attempted to kill init!
> [ 23.559517] Rebooting in 180 seconds..<NULL>
>
> I'm using the plb uart and the 8250.c driver. (The obp uartlite driver
> didn't work so I switched.) The kernel and the init program were
> compiled with eldk.
>
> Any insights into resolving this problem are greatly appreciated.
>
>
> Anton
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: Fix small race in 44x tlbie function
From: Josh Boyer @ 2007-08-08 16:00 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev, Volkmar Uhlig, Paul Mackerras, Todd Inglett,
David Gibson
In-Reply-To: <BDA0DE7D-8AD8-4116-ABE0-2DF6AE72A516@kernel.crashing.org>
On Wed, 8 Aug 2007 10:20:45 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Aug 6, 2007, at 11:20 PM, David Gibson wrote:
>
> > The 440 family of processors don't have a tlbie instruction. So, we
> > implement TLB invalidates by explicitly searching the TLB with tlbsx.,
> > then clobbering the relevant entry, if any. Unfortunately the PID for
> > the search needs to be stored in the MMUCR register, which is also
> > used by the TLB miss handler. Interrupts were enabled in _tlbie(), so
> > an interrupt between loading the MMUCR and the tlbsx could cause
> > incorrect search results, and thus a failure to invalide TLB entries
> > which needed to be invalidated.
> >
> > This patch fixes the problem in both arch/ppc and arch/powerpc by
> > inhibiting interrupts (even critical and debug interrupts) across the
> > relevant instructions.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> > Paul, this one's a bugfix, which I think should go into 2.6.23.
>
> Did you actually see this happen?
Yes.
josh
^ permalink raw reply
* Re: [PATCH] ehca: map 4k firmware context of cq, qp to user space
From: Roland Dreier @ 2007-08-08 16:08 UTC (permalink / raw)
To: Hoang-Nam Nguyen
Cc: Arnd Bergmann, linux-kernel, linuxppc-dev, paulus, general,
stefan.roscher
In-Reply-To: <200708081613.39837.hnguyen@linux.vnet.ibm.com>
> Haven't got any ack for this updated patch yet. Anyway, since it contains
> another bug as shown below, please ignore this patch. We'll send a patch
> set that includes the proper version of this patch later.
Yes, sorry, I'm a bit behind applying patches.
Anyway, OK I'll wait for a fixed patch and drop this one :)
^ permalink raw reply
* Re: pci in arch/powerpc vs arch/ppc
From: Scott Wood @ 2007-08-08 16:24 UTC (permalink / raw)
To: Alexandros Kostopoulos; +Cc: linuxppc-dev
In-Reply-To: <op.twqrwwx2nhx3hy@phoenix>
Alexandros Kostopoulos wrote:
>> Well, the error message is:
>> PCI:0000:00:16.0: Resource 0: 0000000000000000-0000000000000fff (f=200)
>> PCI: Cannot allocate resource region 0 of device 0000:00:16.0
>> PCI: parent is c03c4058: 0000000080000000-00000000bfffffff (f=200)
[snip]
> Oops, I think I found it. I think resources are allocated properly in
> pci_assign_resource(), and you were probably talking about the PCI
> device BAR, not the host bridge POBARs, right. So the error message in
> my previous mail is the one you say it's ok?
Yes.
-Scott
^ permalink raw reply
* Re: help with ppc sections -- no luck, any ideas?
From: Chris Friesen @ 2007-08-08 16:24 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <46A8F22E.6010701@nortel.com>
Well, I've played around with the sections a bit more, and just can't
seem to get it to work. As soon as I apply the following, the kernel
refuses to boot. (And if I remove the changes to _GLOBAL, then it
refuses to boot if I enable CONFIG_KPROBES.)
Index: linux/include/asm-ppc/processor.h
===================================================================
--- linux.orig/include/asm-ppc/processor.h 2007-08-02 16:12:16.000000000
-0600
+++ linux/include/asm-ppc/processor.h 2007-08-02 16:26:06.000000000 -0600
@@ -38,9 +38,20 @@
#define _GLOBAL(n)\
.stabs __stringify(n:F-1),N_FUN,0,0,n;\
+ .section ".text"; \
.globl n;\
n:
+#ifdef CONFIG_KPROBES
+#define _KPROBE(n)\
+ .stabs __stringify(n:F-1),N_FUN,0,0,n;\
+ .section ".kprobes.text","a"; \
+ .globl n;\
+n:
+#else
+#define _KPROBE(n) _GLOBAL(n)
+#endif
+
/*
* this is the minimum allowable io space due to the location
* of the io areas on prep (first one at 0x80000000) but
Index: linux/arch/ppc/kernel/misc.S
===================================================================
--- linux.orig/arch/ppc/kernel/misc.S 2007-08-02 16:12:16.000000000 -0600
+++ linux/arch/ppc/kernel/misc.S 2007-08-02 16:24:43.000000000 -0600
@@ -624,7 +624,7 @@
*
* flush_icache_range(unsigned long start, unsigned long stop)
*/
-_GLOBAL(flush_icache_range)
+_KPROBE(flush_icache_range)
BEGIN_FTR_SECTION
blr /* for 601, do nothing */
END_FTR_SECTION_IFCLR(CPU_FTR_SPLIT_ID_CACHE)
Based on Segher's comments I tried changing it to:
+ .section ".text","ax"; \
but that didn't work either.
Anyone else got any suggestions on how I might force
flush_icache_range() into a ".kprobes.text" section?
Chris
^ permalink raw reply
* RE: no output to serial console from /init process on ml405
From: Benedict, Michael @ 2007-08-08 16:25 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <e835b80a0708080428q59378732x52ee40f9702f5692@mail.gmail.com>
Just a guess, but do you have stdout and friends defined as recommended
in the Compulsory links section of Documentation/devices.txt?
-Michael
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+mbenedict=3Dtwacs.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+mbenedict=3Dtwacs.com@ozlabs.o
rg] On Behalf Of Anton Kowalski
> Sent: Wednesday, August 08, 2007 6:28 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: no output to serial console from /init process on ml405
>=20
> Hi All:
>=20
> I'm trying to bring up linux 2.6.21.1 on an ml405 board. The kernel
> boots fine but the init process does not produce any output. The /init
> program resides in an initramfs file system and I believe the /dev
> device files have been set up correctly. Here's an excerpt from my
> initramfs specification:
>=20
> dir /dev 755 0 0
> nod /dev/console 644 0 0 c 5 1
> nod /dev/ttyS0 644 0 0 c 4 64
>=20
> (I am able to open these files from the init program. I tested this by
> sleeping for a specified time on success.)
>=20
> Also, printk continues to function after /init terminates and before
> the kernel panics.
>=20
> Here are the last few lines of the console output:
>=20
> [ 0.507478] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports,
> IRQ sharing disabled
> [ 0.513862] serial8250.0: ttyS0 at MMIO 0x80201003 (irq =3D=20
> 3) is a 16550A
> [ 2.927509] RAMDISK driver initialized: 1 RAM disks of 8192K size
> 1024 blocksize
> [ 3.018391] tun: Universal TUN/TAP device driver, 1.6
> [ 3.079115] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
> [ 3.154919] mice: PS/2 mouse device common for all mice
> [ 3.218021] TCP cubic registered
> [ 3.257034] NET: Registered protocol family 1
> [ 3.309405] NET: Registered protocol family 17
> [ 3.363462] Freeing unused kernel memory: 300k init
> [ 23.488277] Kernel panic - not syncing: Attempted to kill init!
> [ 23.559517] Rebooting in 180 seconds..<NULL>
>=20
> I'm using the plb uart and the 8250.c driver. (The obp uartlite driver
> didn't work so I switched.) The kernel and the init program were
> compiled with eldk.
>=20
> Any insights into resolving this problem are greatly appreciated.
>=20
>=20
> Anton
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
^ permalink raw reply
* Re: no output to serial console from /init process on ml405
From: Anton Kowalski @ 2007-08-08 16:27 UTC (permalink / raw)
To: Wolfgang Reissnegger; +Cc: linuxppc-embedded
In-Reply-To: <20070808153630.AF2D91A88050@mail200-sin.bigfish.com>
Wolfgang,
Thanks, I'll try your suggestion.
It's worth noting that the init executable is calling into the kernel.
I put a printk in sys_write, which is on the call path of printf() and
the output is sent to the console. However, the output of printf is
not to be seen. This suggests the problem is perhaps in the serial
device setup?
Anton
On 8/8/07, Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com> wrote:
> Hi Anton,
>
> it looks as if your init executable is not doing the right thing and for
> some reason terminates. Maybe your inittab configuration is wrong? Maybe
> the init executable has been compiled with the wrong options?
>
> You can try to copy another executable (e.g. sh, getty) into /init and
> see if you get any output. If you see anything doing that then most
> likely there's something wrong with your init executable.
>
> Wolfgang
>
> Anton Kowalski wrote:
> > Hi All:
> >
> > I'm trying to bring up linux 2.6.21.1 on an ml405 board. The kernel
> > boots fine but the init process does not produce any output. The /init
> > program resides in an initramfs file system and I believe the /dev
> > device files have been set up correctly. Here's an excerpt from my
> > initramfs specification:
> >
> > dir /dev 755 0 0
> > nod /dev/console 644 0 0 c 5 1
> > nod /dev/ttyS0 644 0 0 c 4 64
> >
> > (I am able to open these files from the init program. I tested this by
> > sleeping for a specified time on success.)
> >
> > Also, printk continues to function after /init terminates and before
> > the kernel panics.
> >
> > Here are the last few lines of the console output:
> >
> > [ 0.507478] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports,
> > IRQ sharing disabled
> > [ 0.513862] serial8250.0: ttyS0 at MMIO 0x80201003 (irq = 3) is a 16550A
> > [ 2.927509] RAMDISK driver initialized: 1 RAM disks of 8192K size
> > 1024 blocksize
> > [ 3.018391] tun: Universal TUN/TAP device driver, 1.6
> > [ 3.079115] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
> > [ 3.154919] mice: PS/2 mouse device common for all mice
> > [ 3.218021] TCP cubic registered
> > [ 3.257034] NET: Registered protocol family 1
> > [ 3.309405] NET: Registered protocol family 17
> > [ 3.363462] Freeing unused kernel memory: 300k init
> > [ 23.488277] Kernel panic - not syncing: Attempted to kill init!
> > [ 23.559517] Rebooting in 180 seconds..<NULL>
> >
> > I'm using the plb uart and the 8250.c driver. (The obp uartlite driver
> > didn't work so I switched.) The kernel and the init program were
> > compiled with eldk.
> >
> > Any insights into resolving this problem are greatly appreciated.
> >
> >
> > Anton
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
>
^ permalink raw reply
* MPC8260 PCI9 erratum
From: Scott Wood @ 2007-08-08 16:29 UTC (permalink / raw)
To: Alexandros Kostopoulos; +Cc: linuxppc-dev
In-Reply-To: <op.twqn4vtsnhx3hy@phoenix>
Alexandros Kostopoulos wrote:
> On Tue, 07 Aug 2007 18:20:12 +0300, Scott Wood
> <scottwood@freescale.com> wrote:
>> I don't think the workaround exists yet in arch/powerpc, despite the
>> config option.
>>
> Is there a plan to be implemented on arch/powerpc, or devices with the
> erratum will have to keep on using the legacy arch/ppc code?
I don't have any immediate plans to move it over (and I don't think I
have easy access to affected hardware to test on); I can't speak for any
plans others might have. Patches are of course welcome. :-)
-Scott
^ permalink raw reply
* [patch 2/3 v2] PS3: Remove incomplete message
From: Geoff Levand @ 2007-08-08 16:39 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070808033120.055823394@am.sony.com>
Remove the Kconfig message that indicates the PS3 platform support is
incomplete.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
v2 changes:
o Fix typo pointed out by Geert
arch/powerpc/platforms/ps3/Kconfig | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/arch/powerpc/platforms/ps3/Kconfig
+++ b/arch/powerpc/platforms/ps3/Kconfig
@@ -1,5 +1,5 @@
config PPC_PS3
- bool "Sony PS3 (incomplete)"
+ bool "Sony PS3"
depends on PPC_MULTIPLATFORM && PPC64
select PPC_CELL
select USB_ARCH_HAS_OHCI
@@ -10,10 +10,10 @@ config PPC_PS3
select MEMORY_HOTPLUG
help
This option enables support for the Sony PS3 game console
- and other platforms using the PS3 hypervisor.
- Support for this platform is not yet complete, so
- enabling this will not result in a bootable kernel on a
- PS3 system.
+ and other platforms using the PS3 hypervisor. Enabling this
+ option will allow building otheros.bld, a kernel image suitable
+ for programming into flash memory, and vmlinux, a kernel image
+ suitable for loading via kexec.
menu "PS3 Platform Options"
depends on PPC_PS3
^ permalink raw reply
* Re: no output to serial console from /init process on ml405
From: Wolfgang Reissnegger @ 2007-08-08 16:42 UTC (permalink / raw)
To: Anton Kowalski; +Cc: linuxppc-embedded
In-Reply-To: <e835b80a0708080927x115ef07bw62e546dd6200d252@mail.gmail.com>
The thing that points to a problem with init is:
Kernel panic - not syncing: Attempted to kill init!
What is the string that is supposed to be printed? Maybe the printf
tries to print a string at an invalid address, causing init to crash?
Also, you can check if you set the option for console on serial output:
Location:
-> Device Drivers
-> Character devices
-> Serial drivers
-> 8250/16550 and compatible serial support (SERIAL_8250 [=y])
Cheers,
Wolfgang
Anton Kowalski wrote:
> Wolfgang,
>
> Thanks, I'll try your suggestion.
>
> It's worth noting that the init executable is calling into the
> kernel.
>
> I put a printk in sys_write, which is on the call path of printf()
> and the output is sent to the console. However, the output of printf
> is not to be seen. This suggests the problem is perhaps in the serial
> device setup?
>
> Anton
>
> On 8/8/07, Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com>
> wrote:
>> Hi Anton,
>>
>> it looks as if your init executable is not doing the right thing
>> and for some reason terminates. Maybe your inittab configuration is
>> wrong? Maybe the init executable has been compiled with the wrong
>> options?
>>
>> You can try to copy another executable (e.g. sh, getty) into /init
>> and see if you get any output. If you see anything doing that then
>> most likely there's something wrong with your init executable.
>>
>> Wolfgang
>>
>> Anton Kowalski wrote:
>>> Hi All:
>>>
>>> I'm trying to bring up linux 2.6.21.1 on an ml405 board. The
>>> kernel boots fine but the init process does not produce any
>>> output. The /init program resides in an initramfs file system and
>>> I believe the /dev device files have been set up correctly.
>>> Here's an excerpt from my initramfs specification:
>>>
>>> dir /dev 755 0 0 nod /dev/console 644 0 0 c 5 1 nod /dev/ttyS0
>>> 644 0 0 c 4 64
>>>
>>> (I am able to open these files from the init program. I tested
>>> this by sleeping for a specified time on success.)
>>>
>>> Also, printk continues to function after /init terminates and
>>> before the kernel panics.
>>>
>>> Here are the last few lines of the console output:
>>>
>>> [ 0.507478] Serial: 8250/16550 driver $Revision: 1.90 $ 4
>>> ports, IRQ sharing disabled [ 0.513862] serial8250.0: ttyS0 at
>>> MMIO 0x80201003 (irq = 3) is a 16550A [ 2.927509] RAMDISK
>>> driver initialized: 1 RAM disks of 8192K size 1024 blocksize [
>>> 3.018391] tun: Universal TUN/TAP device driver, 1.6 [
>>> 3.079115] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
>>> [ 3.154919] mice: PS/2 mouse device common for all mice [
>>> 3.218021] TCP cubic registered [ 3.257034] NET: Registered
>>> protocol family 1 [ 3.309405] NET: Registered protocol family
>>> 17 [ 3.363462] Freeing unused kernel memory: 300k init [
>>> 23.488277] Kernel panic - not syncing: Attempted to kill init! [
>>> 23.559517] Rebooting in 180 seconds..<NULL>
>>>
>>> I'm using the plb uart and the 8250.c driver. (The obp uartlite
>>> driver didn't work so I switched.) The kernel and the init
>>> program were compiled with eldk.
>>>
>>> Any insights into resolving this problem are greatly appreciated.
>>>
>>>
>>>
>>> Anton _______________________________________________
>>> Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>>
>
^ permalink raw reply
* Re: how the bytes ordered in mpc8313
From: Scott Wood @ 2007-08-08 16:49 UTC (permalink / raw)
To: Yoni Levin; +Cc: linuxppc-embedded
In-Reply-To: <CE785D12544843B49C5D1315CAE61C23.MAI@mail.livedns.co.il>
Yoni Levin wrote:
> I have mpc83xx,
>
> I saw that I need to use swab32 to any read\write operation from registers,
Only little endian registers (such as PCI).
> Why in the mpc8313 reference in registers description some bits look like
> 31,30,29,.,3,2,1,0
>
> And some: 0,1,2,3.,30,31
Most PowerPC documentation numbers bits in the same endianness as the
bytes in the register.
> Is it just mistake? Or some registers are different then other?
I consider big-endian bit numbering to be a mistake, but good luck
getting them to fix it. :-)
-Scott
^ permalink raw reply
* Re: how the bytes ordered in mpc8313
From: Scott Wood @ 2007-08-08 16:55 UTC (permalink / raw)
To: Yoni Levin; +Cc: linuxppc-embedded
In-Reply-To: <CE785D12544843B49C5D1315CAE61C23.MAI@mail.livedns.co.il>
Yoni Levin wrote:
> I have mpc83xx,
>
> I saw that I need to use swab32 to any read\write operation from registers,
BTW, you should be using in/out_le32() (or for PCI MMIO, readl/writel)
rather than swab32(). This will be more efficient since it can use the
lwbrx/stwbrx instructions, and it will keep working even if the code is
run little-endian.
-Scott
^ permalink raw reply
* [PATCH v3 0/2] SPI support for fsl_soc and mpc832x_rdb
From: Anton Vorontsov @ 2007-08-08 17:07 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
This is v3. The only objection I can imagine is about "fsl,device-id".
Though in the v2 nobody complained, thus it's stayed intact.
If you want to, complain now. I'll give up and will remove it. ;-)
Changelog:
v2 -> v3
o Device tree:
- completely removed mmc node;
- removed pio-handles and pio-maps.
o board file:
- Instead of par_io_of_config(), now par_io_config_pin() used to
configure GPIO pins, which does not require device tree node.
v1 -> v2
o Device tree:
- cosmetic cleanups (@01 -> @1);
- device-id renamed to fsl,device-id;
- removed max-chipselect and sysclk properties from spi node;
- removed chipselect property from mmc node, now reg property
used for this purpose, thereby address-cells and size-cells
added to the spi node;
- other non-mandatory (device-id, device_type, compatible, ...)
properties removed from mmc node, today board file is using
of_find_node_by_name(), instead of of_find_compatible_node();
- "qe" mode renamed to "cpu-qe".
o board file <-> fsl_soc interaction
- fsl_soc no longer scans for SPI nodes in the arch initcall.
Also it's no longer exports any global variables. Instead, it's
export fsl_spi_init function now, which accepts pointer to the
fsl_spi_board_info structure;
- board file fills fsl_spi_board_info structure and issues
fsl_spi_init(), which register SPI devices and SPI board infos.
Various sanity checks also perfromed.
I'd want to note that if spi_mpc83xx will be converted to
of_platform_driver then the scheme described above will not
work anymore, and I'll have to revert back ugly hacks:
global variables for activate/deactivate_cs functions. I see
no other options.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH v3 1/2] [POWERPC] MPC832x_RDB: update dts to use spi, register mmc_spi stub
From: Anton Vorontsov @ 2007-08-08 17:09 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070808170728.GA21118@localhost.localdomain>
mmc_spi already tested to work. When it will hit mainline
the only change that will be needed is replacing "spidev"
by "mmc_spi".
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc832x_rdb.dts | 4 ++-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 52 +++++++++++++++++++++++++++++
2 files changed, 55 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index e9c332f..664dd16 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -207,15 +207,17 @@
spi@4c0 {
device_type = "spi";
+ fsl,device-id = <1>;
compatible = "fsl_spi";
reg = <4c0 40>;
interrupts = <2>;
interrupt-parent = <&qeic>;
- mode = "cpu";
+ mode = "cpu-qe";
};
spi@500 {
device_type = "spi";
+ fsl,device-id = <2>;
compatible = "fsl_spi";
reg = <500 40>;
interrupts = <1>;
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index 93ba957..89cc039 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -15,6 +15,7 @@
*/
#include <linux/pci.h>
+#include <linux/spi/spi.h>
#include <asm/of_platform.h>
#include <asm/time.h>
@@ -24,6 +25,7 @@
#include <asm/qe_ic.h>
#include "mpc83xx.h"
+#include "../../sysdev/fsl_soc.h"
#undef DEBUG
#ifdef DEBUG
@@ -32,6 +34,56 @@
#define DBG(fmt...)
#endif
+extern int par_io_data_set(u8 port, u8 pin, u8 val);
+extern int par_io_config_pin(u8 port, u8 pin, int dir, int open_drain,
+ int assignment, int has_irq);
+
+static void mpc83xx_spi_activate_cs(u8 cs, u8 polarity)
+{
+ pr_debug("%s %d %d\n", __func__, cs, polarity);
+ par_io_data_set(3, 13, polarity);
+}
+
+static void mpc83xx_spi_deactivate_cs(u8 cs, u8 polarity)
+{
+ pr_debug("%s %d %d\n", __func__, cs, polarity);
+ par_io_data_set(3, 13, !polarity);
+}
+
+static struct spi_board_info mpc832x_spi_boardinfo = {
+ .bus_num = 1,
+ .chip_select = 0,
+ .max_speed_hz = 50000000,
+ /*
+ * XXX: This is spidev (spi in userspace) stub, should
+ * be replaced by "mmc_spi" when mmc_spi will hit mainline.
+ */
+ .modalias = "spidev",
+};
+
+static struct fsl_spi_board_info fsl_spi_board_info = {
+ .activate_cs = mpc83xx_spi_activate_cs,
+ .deactivate_cs = mpc83xx_spi_deactivate_cs,
+ .board_infos = &mpc832x_spi_boardinfo,
+ .num_board_infos = 1,
+};
+
+static int __init mpc832x_spi_init(void)
+{
+ par_io_config_pin(3, 0, 3, 0, 1, 0); /* SPI1 MOSI, I/O */
+ par_io_config_pin(3, 1, 3, 0, 1, 0); /* SPI1 MISO, I/O */
+ par_io_config_pin(3, 2, 3, 0, 1, 0); /* SPI1 CLK, I/O */
+ par_io_config_pin(3, 3, 2, 0, 1, 0); /* SPI1 SEL, I */
+
+ par_io_config_pin(3, 13, 1, 0, 0, 0); /* !SD_CS, O */
+ par_io_config_pin(3, 14, 2, 0, 0, 0); /* SD_INSERT, I */
+ par_io_config_pin(3, 15, 2, 0, 0, 0); /* SD_PROTECT,I */
+
+ return fsl_spi_init(&fsl_spi_board_info);
+}
+
+device_initcall(mpc832x_spi_init);
+
/* ************************************************************************
*
* Setup the architecture
--
1.5.0.6
^ permalink raw reply related
* [PATCH v3 2/2] [POWERPC] fsl_soc: add support for fsl_spi
From: Anton Vorontsov @ 2007-08-08 17:09 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070808170728.GA21118@localhost.localdomain>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/fsl_soc.c | 88 +++++++++++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/fsl_soc.h | 12 ++++++
2 files changed, 100 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 727453d..0771700 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -23,6 +23,7 @@
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/phy.h>
+#include <linux/spi/spi.h>
#include <linux/fsl_devices.h>
#include <linux/fs_enet_pd.h>
#include <linux/fs_uart_pd.h>
@@ -1186,3 +1187,90 @@ err:
arch_initcall(cpm_smc_uart_of_init);
#endif /* CONFIG_8xx */
+
+int fsl_spi_init(struct fsl_spi_board_info *binfo)
+{
+ struct device_node *np;
+ unsigned int i;
+ u32 sysclk;
+
+ np = of_find_node_by_type(NULL, "qe");
+ if (!np)
+ return -ENODEV;
+
+ sysclk = *(u32 *)of_get_property(np, "bus-frequency", NULL);
+
+ for (np = NULL, i = 1;
+ (np = of_find_compatible_node(np, "spi", "fsl_spi")) != NULL;
+ i++) {
+ int ret = 0;
+ unsigned int j;
+ const char *devid;
+ const char *mode;
+ struct resource res[2];
+ struct platform_device *pdev = NULL;
+ struct fsl_spi_platform_data pdata = {
+ .activate_cs = binfo->activate_cs,
+ .deactivate_cs = binfo->deactivate_cs,
+ };
+
+ memset(res, 0, sizeof(res));
+
+ devid = of_get_property(np, "fsl,device-id", NULL);
+ mode = of_get_property(np, "mode", NULL);
+ if (!devid || !mode)
+ goto err;
+
+ pdata.sysclk = sysclk;
+ pdata.bus_num = *(u32 *)devid;
+
+ for (j = 0; j < binfo->num_board_infos; j++) {
+ if (binfo->board_infos[j].bus_num == pdata.bus_num)
+ pdata.max_chipselect++;
+ }
+
+ if (!pdata.max_chipselect)
+ goto err;
+
+ if (!strcmp(mode, "cpu-qe"))
+ pdata.qe_mode = 1;
+
+ ret = of_address_to_resource(np, 0, &res[0]);
+ if (ret)
+ goto err;
+
+ res[1].start = res[2].end = irq_of_parse_and_map(np, 0);
+ if (res[1].start == NO_IRQ)
+ goto err;
+
+ res[1].name = "mpc83xx_spi";
+ res[1].flags = IORESOURCE_IRQ;;
+
+ pdev = platform_device_alloc("mpc83xx_spi", i);
+ if (!pdev)
+ goto err;
+
+ ret = platform_device_add_data(pdev, &pdata, sizeof(pdata));
+ if (ret)
+ goto unreg;
+
+ ret = platform_device_add_resources(pdev, res,
+ ARRAY_SIZE(res));
+ if (ret)
+ goto unreg;
+
+ ret = platform_device_register(pdev);
+ if (ret)
+ goto unreg;
+
+ continue;
+unreg:
+ platform_device_del(pdev);
+err:
+ continue;
+ }
+
+ return spi_register_board_info(binfo->board_infos,
+ binfo->num_board_infos);
+}
+EXPORT_SYMBOL(fsl_spi_init);
diff --git a/arch/powerpc/sysdev/fsl_soc.h b/arch/powerpc/sysdev/fsl_soc.h
index 04e145b..a83998d 100644
--- a/arch/powerpc/sysdev/fsl_soc.h
+++ b/arch/powerpc/sysdev/fsl_soc.h
@@ -8,5 +8,17 @@ extern phys_addr_t get_immrbase(void);
extern u32 get_brgfreq(void);
extern u32 get_baudrate(void);
+struct spi_board_info;
+
+struct fsl_spi_board_info {
+ struct spi_board_info *board_infos;
+ unsigned int num_board_infos;
+
+ void (*activate_cs)(u8 cs, u8 polarity);
+ void (*deactivate_cs)(u8 cs, u8 polarity);
+};
+
+extern int fsl_spi_init(struct fsl_spi_board_info *info);
+
#endif
#endif
--
1.5.0.6
^ permalink raw reply related
* Re: [PATCH] i2c-mpc: don't disable I2C module on stop condition.
From: Jean Delvare @ 2007-08-08 17:19 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded, Guennadi Liakhovetski, i2c
In-Reply-To: <20070724051431.GF4529@moe.telargo.com>
Hi Domen,
On Tue, 24 Jul 2007 07:14:31 +0200, Domen Puncer wrote:
> Disabling module on stop doesn't work on some CPUs (ie. mpc8241,
> as reported by Guennadi Liakhovetski), so remove that.
>
> Disable I2C module on errors/interrupts to prevent it from
> locking up on mpc5200b.
>
>
> Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
> ---
> Hi!
>
> So I fixed i2c on one board, and broke it on another :-(
> This patch works on both Guennadi's and mine (hey, it might break
> a third one!).
> Jean, can you please push this, if there are no objections
> and "doesn't work for me" reports.
Queued for 2.6.23-rc3, thanks. Guennadi, can you please confirm that
this patch fixes your problem?
>
>
> Domen
>
>
> drivers/i2c/busses/i2c-mpc.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> Index: work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> ===================================================================
> --- work-powerpc.git.orig/drivers/i2c/busses/i2c-mpc.c
> +++ work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> @@ -105,6 +105,7 @@ static int i2c_wait(struct mpc_i2c *i2c,
> schedule();
> if (time_after(jiffies, orig_jiffies + timeout)) {
> pr_debug("I2C: timeout\n");
> + writeccr(i2c, 0);
> result = -EIO;
> break;
> }
> @@ -116,10 +117,12 @@ static int i2c_wait(struct mpc_i2c *i2c,
> result = wait_event_interruptible_timeout(i2c->queue,
> (i2c->interrupt & CSR_MIF), timeout * HZ);
>
> - if (unlikely(result < 0))
> + if (unlikely(result < 0)) {
> pr_debug("I2C: wait interrupted\n");
> - else if (unlikely(!(i2c->interrupt & CSR_MIF))) {
> + writeccr(i2c, 0);
> + } else if (unlikely(!(i2c->interrupt & CSR_MIF))) {
> pr_debug("I2C: wait timeout\n");
> + writeccr(i2c, 0);
> result = -ETIMEDOUT;
> }
>
> @@ -172,7 +175,6 @@ static void mpc_i2c_start(struct mpc_i2c
> static void mpc_i2c_stop(struct mpc_i2c *i2c)
> {
> writeccr(i2c, CCR_MEN);
> - writeccr(i2c, 0);
> }
>
> static int mpc_write(struct mpc_i2c *i2c, int target,
> @@ -261,6 +263,7 @@ static int mpc_xfer(struct i2c_adapter *
> while (readb(i2c->base + MPC_I2C_SR) & CSR_MBB) {
> if (signal_pending(current)) {
> pr_debug("I2C: Interrupted\n");
> + writeccr(i2c, 0);
> return -EINTR;
> }
> if (time_after(jiffies, orig_jiffies + HZ)) {
--
Jean Delvare
^ permalink raw reply
* Re: signals handling in the kernel
From: David Hawkins @ 2007-08-08 17:19 UTC (permalink / raw)
To: Mirek23; +Cc: linuxppc-embedded
In-Reply-To: <12048448.post@talk.nabble.com>
Hi Mirek,
> I run embedded Linux on ppc405 (ml403 xilinx evaluation board).
> I use the GPIO based device build on FPGA part of the xilinx
> chip. My gpio device generates interrupts whenever it changes
> its state.
>
> I use Montavista gpio driver with some modifications to react
> on interrupts. Each time when interrupt occurs the interrupt
> handler routine is called. This routine sends the signal to the
> application in user space to trigger it. When the application
> is triggered it reads the data from the GPIO device.
>
> I read that in this situation the best is to use signals. In my
> case the ideal would be to use kill_proc_info which sends to the
> application the Signal with info data were I intended to put just
> one integer value. Such a value determines how to react for the
> signal on the application level.
Signals are not the appropriate solution.
It sounds like your application is read-only, so how about
the following use-cases for the driver:
1. In user-space, you only have one GPIO, and the code
only needs to react in response to this one I/O port.
The information required by user-space is the 1-byte
(or 2, or 4) of GPIO
Solution:
The driver implements a buffer that a user-space read() call
consumes. A user-space read() call blocks until there is
data in the buffer.
The driver ISR reads the GPIO port, and writes the
contents to the buffer.
2. In user-space, you have multiple GPIO ports, and
the code needs to respond to any one.
Solution:
The driver implements the poll() call back so that
user-space can call select() on the multiple GPIO
file descriptors.
Again, the driver ISR reads the different GPIO ports,
and writes the data to the GPIO specific buffer.
I have plenty of driver code lying around, and can point
you to an example that implements both of these options.
The driver easily supports both (1) and (2) since
(1) is just a blocking-read, and (2) is poll().
Is the kernel 2.4 or 2.6? Here's some code I wrote for
2.6, and this code was ported from some 2.4 drivers
(and I still have that code in CVS)
http://www.ovro.caltech.edu/~dwh/correlator/cobra_docs.html
http://www.ovro.caltech.edu/~dwh/correlator/software/driver_design.tar.gz
http://www.ovro.caltech.edu/~dwh/correlator/pdf/LNX-762-Hawkins.pdf
I can re-write say the parallel port example to demonstrate
how the value of the GPIO port (the parallel port) can be
sent to user space. There's a parallel port interrupt
example in there somewhere. I know I wrote a GPIO driver
for my Yosemite board (440EP example), but I don't see it
in that zip ... it must be lying around here somewhere :)
I wouldn't necessarily copy say a parallel port example
verbatim, since there is only ever one of those devices
in a system. There are more likely to be multiple GPIO ports,
so the driver design would be generalized a little more.
Look at the COBRA driver code. I have crates of cPCI equipment
loaded with 10s of boards, with each board having multiple
device nodes, transferring megabytes per second over
multiple cPCI crates :)
Anyway, stop thinking about signals, they'll just mess you up.
Oh, the driver will also support sending SIGIO to the process,
via the fasync() driver call, so you can try signals, and
convince yourself that select() is much nicer.
A GPIO driver seems like such an obvious thing to write. Are
you sure the montavista driver doesn't already support these
features? I have no idea of your experience with coding, so
it could just be that you are unaware of what the driver
implements. If you are allowed to post it, go ahead, and
I'll comment on its features.
Cheers
Dave
^ permalink raw reply
* [patch 1/3 v2] PS3: Fix storage probe logic
From: Geoff Levand @ 2007-08-08 18:01 UTC (permalink / raw)
To: paulus; +Cc: Geert Uytterhoeven, linuxppc-dev
In-Reply-To: <20070808033119.960825832@am.sony.com>
Subject: PS3: Fix storage probe logic
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Fix the PS3 storage probe logic to properly find device regions on cold
startup.
o Change the storage probe event mask from notify_device_ready
to notify_region_update.
o Improve the storage probe error handling.
o Change ps3_storage_wait_for_device() to use a temporary variable to hold
the buffer address.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
V2 changes:
o Correct the value the returned notify_event->event_type is compared to.
arch/powerpc/platforms/ps3/device-init.c | 37 +++++++++++++++----------------
1 file changed, 19 insertions(+), 18 deletions(-)
--- a/arch/powerpc/platforms/ps3/device-init.c
+++ b/arch/powerpc/platforms/ps3/device-init.c
@@ -273,55 +273,58 @@ static int ps3stor_wait_for_completion(u
static int ps3_storage_wait_for_device(const struct ps3_repository_device *repo)
{
+ int error = -ENODEV;
int result;
const u64 notification_dev_id = (u64)-1LL;
const unsigned int timeout = HZ;
u64 lpar;
u64 tag;
+ void *buf;
+ enum ps3_notify_type {
+ notify_device_ready = 0,
+ notify_region_probe = 1,
+ notify_region_update = 2,
+ };
struct {
u64 operation_code; /* must be zero */
- u64 event_mask; /* 1 = device ready */
+ u64 event_mask; /* OR of 1UL << enum ps3_notify_type */
} *notify_cmd;
struct {
- u64 event_type; /* notify_device_ready */
+ u64 event_type; /* enum ps3_notify_type */
u64 bus_id;
u64 dev_id;
u64 dev_type;
u64 dev_port;
} *notify_event;
- enum {
- notify_device_ready = 1
- };
pr_debug(" -> %s:%u: bus_id %u, dev_id %u, dev_type %u\n", __func__,
__LINE__, repo->bus_id, repo->dev_id, repo->dev_type);
- notify_cmd = kzalloc(512, GFP_KERNEL);
- notify_event = (void *)notify_cmd;
- if (!notify_cmd)
+ buf = kzalloc(512, GFP_KERNEL);
+ if (!buf)
return -ENOMEM;
- lpar = ps3_mm_phys_to_lpar(__pa(notify_cmd));
+ lpar = ps3_mm_phys_to_lpar(__pa(buf));
+ notify_cmd = buf;
+ notify_event = buf;
result = lv1_open_device(repo->bus_id, notification_dev_id, 0);
if (result) {
printk(KERN_ERR "%s:%u: lv1_open_device %s\n", __func__,
__LINE__, ps3_result(result));
- result = -ENODEV;
goto fail_free;
}
/* Setup and write the request for device notification. */
- notify_cmd->operation_code = 0; /* must be zero */
- notify_cmd->event_mask = 0x01; /* device ready */
+ notify_cmd->operation_code = 0; /* must be zero */
+ notify_cmd->event_mask = 1UL << notify_region_probe;
result = lv1_storage_write(notification_dev_id, 0, 0, 1, 0, lpar,
&tag);
if (result) {
printk(KERN_ERR "%s:%u: write failed %s\n", __func__, __LINE__,
ps3_result(result));
- result = -ENODEV;
goto fail_close;
}
@@ -332,13 +335,11 @@ static int ps3_storage_wait_for_device(c
if (result) {
printk(KERN_ERR "%s:%u: write not completed %s\n", __func__,
__LINE__, ps3_result(result));
- result = -ENODEV;
goto fail_close;
}
/* Loop here processing the requested notification events. */
- result = -ENODEV;
while (1) {
memset(notify_event, 0, sizeof(*notify_event));
@@ -358,7 +359,7 @@ static int ps3_storage_wait_for_device(c
break;
}
- if (notify_event->event_type != notify_device_ready ||
+ if (notify_event->event_type != notify_region_probe ||
notify_event->bus_id != repo->bus_id) {
pr_debug("%s:%u: bad notify_event: event %lu, "
"dev_id %lu, dev_type %lu\n",
@@ -386,9 +387,9 @@ static int ps3_storage_wait_for_device(c
fail_close:
lv1_close_device(repo->bus_id, notification_dev_id);
fail_free:
- kfree(notify_cmd);
+ kfree(buf);
pr_debug(" <- %s:%u\n", __func__, __LINE__);
- return result;
+ return error;
}
static int ps3_setup_storage_dev(const struct ps3_repository_device *repo,
^ permalink raw reply
* [PATCH 0/7] IB/ehca: support for user space small queues, support more than 4k queue pairs, generate last WQE reached
From: Stefan Roscher @ 2007-08-08 18:36 UTC (permalink / raw)
To: Roland Dreier, linux-kernel, linuxppc-dev, general
Cc: craisch, Hoang-Nam Nguyen, fenkes
Here is a patch set against Roland's git, branch for-2.6.23 for ehca.
It enables userspace support for small QP feature and make some fixes for it.
Also there is add the mapping of 4k firmware context to user space.
They are in details:
[1/7] add support for userspace small queues and make some fixes
[2/7] ensure that a non-existing queues in case of SRQs are not interprete as
small queues
[3/7] we have no longer to add 1 to the number of requestet wqes, because
firmware does now
[4/7] make changes to ehca_mmap() to support more than 4k queues
[5/7] map 4k firmware context of cq, qp to user space
[6/7] generate last WQE reached, when base QP for SRQ has entered error state
[7/7] prevent overwriting QP init attributes given by caller
The patches should apply cleanly, in order, against Roland's git. Please
review the changes and apply the patches if they are okay.
Regards,
Stefan
^ permalink raw reply
* [PATCH 1/7] IB/ehca: Small QP userspace support and fixes
From: Stefan Roscher @ 2007-08-08 18:37 UTC (permalink / raw)
To: Roland Dreier, linux-kernel, linuxppc-dev, openib-general
Cc: fenkes, Hoang-Nam Nguyen, raisch
Signed-off-by: Stefan Roscher <stefan.roscher@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_qp.c | 7 +++----
drivers/infiniband/hw/ehca/ipz_pt_fn.c | 3 ++-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c b/drivers/infiniband/hw/ehca/ehca_qp.c
index b178cba..cfa83fa 100644
--- a/drivers/infiniband/hw/ehca/ehca_qp.c
+++ b/drivers/infiniband/hw/ehca/ehca_qp.c
@@ -273,6 +273,7 @@ static inline void queue2resp(struct ipzu_queue_resp *resp,
resp->queue_length = queue->queue_length;
resp->pagesize = queue->pagesize;
resp->toggle_state = queue->toggle_state;
+ resp->offset = queue->offset;
}
/*
@@ -598,8 +599,7 @@ static struct ehca_qp *internal_create_qp(
parms.squeue.max_sge = max_send_sge;
parms.rqueue.max_sge = max_recv_sge;
- if (EHCA_BMASK_GET(HCA_CAP_MINI_QP, shca->hca_cap)
- && !(context && udata)) { /* no small QP support in userspace ATM */
+ if (EHCA_BMASK_GET(HCA_CAP_MINI_QP, shca->hca_cap)) {
ehca_determine_small_queue(
&parms.squeue, max_send_sge, is_llqp);
ehca_determine_small_queue(
@@ -739,8 +739,7 @@ static struct ehca_qp *internal_create_qp(
resp.ext_type = my_qp->ext_type;
resp.qkey = my_qp->qkey;
resp.real_qp_num = my_qp->real_qp_num;
- resp.ipz_rqueue.offset = my_qp->ipz_rqueue.offset;
- resp.ipz_squeue.offset = my_qp->ipz_squeue.offset;
+
if (HAS_SQ(my_qp))
queue2resp(&resp.ipz_squeue, &my_qp->ipz_squeue);
if (HAS_RQ(my_qp))
diff --git a/drivers/infiniband/hw/ehca/ipz_pt_fn.c b/drivers/infiniband/hw/ehca/ipz_pt_fn.c
index a090c67..661f8db 100644
--- a/drivers/infiniband/hw/ehca/ipz_pt_fn.c
+++ b/drivers/infiniband/hw/ehca/ipz_pt_fn.c
@@ -158,6 +158,7 @@ static int alloc_small_queue_page(struct ipz_queue *queue, struct ehca_pd *pd)
queue->queue_pages[0] = (void *)(page->page | (bit << (order + 9)));
queue->small_page = page;
+ queue->offset = bit << (order + 9);
return 1;
out:
@@ -172,7 +173,7 @@ static void free_small_queue_page(struct ipz_queue *queue, struct ehca_pd *pd)
unsigned long bit;
int free_page = 0;
- bit = ((unsigned long)queue->queue_pages[0] & PAGE_MASK)
+ bit = ((unsigned long)queue->queue_pages[0] & ~PAGE_MASK)
>> (order + 9);
mutex_lock(&pd->lock);
--
1.5.2
^ permalink raw reply related
* [PATCH 2/7] IB/ehca: Ensure non-existing queues aren't made small queues
From: Stefan Roscher @ 2007-08-08 18:39 UTC (permalink / raw)
To: Roland Dreier, linux-kernel, linuxppc-dev, openib-general
Cc: fenkes, raisch, "Hoang-Nam Nguyen" @dyn-9-152-249-53
Signed-off-by: Stefan Roscher <stefan.roscher@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_qp.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c b/drivers/infiniband/hw/ehca/ehca_qp.c
index cfa83fa..13b61c3 100644
--- a/drivers/infiniband/hw/ehca/ehca_qp.c
+++ b/drivers/infiniband/hw/ehca/ehca_qp.c
@@ -600,10 +600,12 @@ static struct ehca_qp *internal_create_qp(
parms.rqueue.max_sge = max_recv_sge;
if (EHCA_BMASK_GET(HCA_CAP_MINI_QP, shca->hca_cap)) {
- ehca_determine_small_queue(
- &parms.squeue, max_send_sge, is_llqp);
- ehca_determine_small_queue(
- &parms.rqueue, max_recv_sge, is_llqp);
+ if (HAS_SQ(my_qp))
+ ehca_determine_small_queue(
+ &parms.squeue, max_send_sge, is_llqp);
+ if (HAS_RQ(my_qp))
+ ehca_determine_small_queue(
+ &parms.rqueue, max_recv_sge, is_llqp);
parms.qp_storage =
(parms.squeue.is_small || parms.rqueue.is_small);
}
--
1.5.2
^ permalink raw reply related
* [PATCH 3/7] IB/ehca: Add 1 is not longer needed because of firmware interface change
From: Stefan Roscher @ 2007-08-08 18:40 UTC (permalink / raw)
To: Roland Dreier, linux-kernel, linuxppc-dev, openib-general
Cc: fenkes, raisch, "Hoang-Nam Nguyen" @dyn-9-152-249-53
Signed-off-by: Stefan Roscher <stefan.roscher@de.ibm.com>
---
drivers/infiniband/hw/ehca/hcp_if.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/hcp_if.c b/drivers/infiniband/hw/ehca/hcp_if.c
index 24f4541..8534061 100644
--- a/drivers/infiniband/hw/ehca/hcp_if.c
+++ b/drivers/infiniband/hw/ehca/hcp_if.c
@@ -317,9 +317,9 @@ u64 hipz_h_alloc_resource_qp(const struct ipz_adapter_handle adapter_handle,
max_r10_reg =
EHCA_BMASK_SET(H_ALL_RES_QP_MAX_OUTST_SEND_WR,
- parms->squeue.max_wr + 1)
+ parms->squeue.max_wr)
| EHCA_BMASK_SET(H_ALL_RES_QP_MAX_OUTST_RECV_WR,
- parms->rqueue.max_wr + 1)
+ parms->rqueue.max_wr)
| EHCA_BMASK_SET(H_ALL_RES_QP_MAX_SEND_SGE,
parms->squeue.max_sge)
| EHCA_BMASK_SET(H_ALL_RES_QP_MAX_RECV_SGE,
--
1.5.2
^ permalink raw reply related
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