* Re: [PATCH] powerpc: Feature nop out reservation clear when stcx checks address
From: Paul Mackerras @ 2010-08-11 6:41 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20100811052005.GV29316@kryten>
On Wed, Aug 11, 2010 at 03:20:05PM +1000, Anton Blanchard wrote:
> All recent POWER CPUs check the address before letting the stcx succeed
> so we can create a CPU feature and nop it out. As Ben suggested, we can
> only do this in our syscall path because there is a remote possibility
> some kernel code gets interrupted by an exception that ends up operating
> on the same cacheline.
Nice... Just one nit, and that is that I think we now need a dummy
stcx in the context switch code so there is no possibility of getting
from one user context to another with a reservation still pending from
the first context. I guess our chances of getting through schedule()
without doing any atomics, bitops or spinlocks are pretty remote, but
nevertheless it might be as well to make sure.
Paul.
^ permalink raw reply
* kernel 2.6.33 fail to mount rootfs on ramdisk
From: Shawn Jin @ 2010-08-11 6:55 UTC (permalink / raw)
To: ppcdev
Hi,
The kernel 2.6.33 failed to mount the rootfs on the ramdisk. I enabled
the ramdisk block device support and ext2 filesystem as shown below.
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_EXT2_FS=y
Are these adequate configurations for kernel to support rootfs on
ramdisk? What have I missed? The ramdisk image is from DENX's SELF.
The boot message is shown below.
=> bootm 1000000 2000000
## Booting image at 01000000 ...
Image Name: Linux-2.6.33.5
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1070272 Bytes = 1 MB
Load Address: 00400000
Entry Point: 00400554
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 02000000 ...
Image Name: Simple Embedded Linux Framework
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1459535 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 07bb7000, end 07d1b54f ... OK
Memory <- <0x0 0x8000000> (128MB)
ENET0: local-mac-address <- 00:09:9b:01:58:64
CPU clock-frequency <- 0x7270e00 (120MHz)
CPU timebase-frequency <- 0x7270e0 (8MHz)
CPU bus-frequency <- 0x3938700 (60MHz)
zImage starting: loaded at 0x00400000 (sp: 0x07d1cbd0)
Allocating 0x23f554 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040c000:0x0067d01c)...done 0x22e6ec bytes
Using loader supplied ramdisk at 0x7bb7000-0x7d1b54f
initrd head: 0x1f8b0808
Linux/PowerPC load: root=/dev/ram
Finalizing device tree... flat tree at 0x68a300
.......
NET: Registered protocol family 17
List of all partitions:
No filesystem could mount root, tried: ext2
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
Call Trace:
[c781fed0] [c0006ce0] show_stack+0x40/0x168 (unreliable)
[c781ff10] [c001cc5c] panic+0x8c/0x178
[c781ff60] [c0201dc0] mount_block_root+0x1d4/0x244
[c781ffb0] [c0201fa4] prepare_namespace+0x64/0x210
[c781ffd0] [c0201220] kernel_init+0x104/0x130
[c781fff0] [c000dcc8] kernel_thread+0x4c/0x68
Rebooting in 180 seconds..
Thanks,
-Shawn.
^ permalink raw reply
* Re: kernel 2.6.33 fail to mount rootfs on ramdisk
From: Shawn Jin @ 2010-08-11 7:16 UTC (permalink / raw)
To: ppcdev
In-Reply-To: <AANLkTi=ZSBNUYgwv3CKA1PEZm7Vkk6SsubcFR8410qz+@mail.gmail.com>
On Tue, Aug 10, 2010 at 11:55 PM, Shawn Jin <shawnxjin@gmail.com> wrote:
> Hi,
>
> The kernel 2.6.33 failed to mount the rootfs on the ramdisk. I enabled
> the ramdisk block device support and ext2 filesystem as shown below.
>
> CONFIG_BLK_DEV_RAM=y
> CONFIG_BLK_DEV_RAM_COUNT=16
> CONFIG_BLK_DEV_RAM_SIZE=4096
> CONFIG_EXT2_FS=y
>
> Are these adequate configurations for kernel to support rootfs on
> ramdisk? What have I missed? The ramdisk image is from DENX's SELF.
> The boot message is shown below.
I figured that out. What I missed is CONFIG_BLK_DEV_INITRD.
Thanks,
-Shawn.
^ permalink raw reply
* kernel version 2.6.35-git10 build failure
From: divya @ 2010-08-11 7:21 UTC (permalink / raw)
To: LKML, linuxppc-dev, sripathik
Hi,
Today kernel(version 2.6.35-git10 -commitid 3d30701b58970) build fails with following error on both system x and p
fs/9p/vfs_inode.c: In function 'v9fs_vfs_setattr_dotl':
fs/9p/vfs_inode.c:1267: error: implicit declaration of function 'inode_setattr'
make[2]: *** [fs/9p/vfs_inode.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [fs/9p] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [fs] Error 2
make: *** Waiting for unfinished jobs....
Seems like the commit 87d7845aa0b is the corrupt which added the function v9fs_vfs_setattr_dotl()
Thanks
Divya
^ permalink raw reply
* Re: kernel version 2.6.35-git10 build failure
From: Stephen Rothwell @ 2010-08-11 7:51 UTC (permalink / raw)
To: divya; +Cc: linuxppc-dev, sripathik, LKML
In-Reply-To: <4C624F7F.3070608@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
Hi Divya,
On Wed, 11 Aug 2010 12:51:35 +0530 divya <dipraksh@linux.vnet.ibm.com> wrote:
>
> Today kernel(version 2.6.35-git10 -commitid 3d30701b58970) build fails with following error on both system x and p
>
> fs/9p/vfs_inode.c: In function 'v9fs_vfs_setattr_dotl':
> fs/9p/vfs_inode.c:1267: error: implicit declaration of function 'inode_setattr'
This is known about and a fix is pending. Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: kernel version 2.6.35-git10 build failure
From: Sripathi Kodi @ 2010-08-11 7:53 UTC (permalink / raw)
To: divya; +Cc: linuxppc-dev, LKML, Stephen Rothwell
In-Reply-To: <4C624F7F.3070608@linux.vnet.ibm.com>
On Wed, 11 Aug 2010 12:51:35 +0530
divya <dipraksh@linux.vnet.ibm.com> wrote:
> Hi,
>
> Today kernel(version 2.6.35-git10 -commitid 3d30701b58970) build fails with following error on both system x and p
>
> fs/9p/vfs_inode.c: In function 'v9fs_vfs_setattr_dotl':
> fs/9p/vfs_inode.c:1267: error: implicit declaration of function 'inode_setattr'
> make[2]: *** [fs/9p/vfs_inode.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[1]: *** [fs/9p] Error 2
> make[1]: *** Waiting for unfinished jobs....
> make: *** [fs] Error 2
> make: *** Waiting for unfinished jobs....
>
> Seems like the commit 87d7845aa0b is the corrupt which added the function v9fs_vfs_setattr_dotl()
Yes, it is a problem I created. Stephen Rothwell has already fixed it.
Al Viro has sent a git pull request to Linus today with the fix in it.
Here is the patch you need: http://lkml.org/lkml/2010/6/21/442
Thanks,
Sripathi.
>
> Thanks
> Divya
>
>
^ permalink raw reply
* Re: [PATCH] powerpc: Feature nop out reservation clear when stcx checks address
From: Benjamin Herrenschmidt @ 2010-08-11 8:21 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <20100811064152.GC15252@drongo>
On Wed, 2010-08-11 at 16:41 +1000, Paul Mackerras wrote:
> On Wed, Aug 11, 2010 at 03:20:05PM +1000, Anton Blanchard wrote:
>
> > All recent POWER CPUs check the address before letting the stcx succeed
> > so we can create a CPU feature and nop it out. As Ben suggested, we can
> > only do this in our syscall path because there is a remote possibility
> > some kernel code gets interrupted by an exception that ends up operating
> > on the same cacheline.
>
> Nice... Just one nit, and that is that I think we now need a dummy
> stcx in the context switch code so there is no possibility of getting
> from one user context to another with a reservation still pending from
> the first context. I guess our chances of getting through schedule()
> without doing any atomics, bitops or spinlocks are pretty remote, but
> nevertheless it might be as well to make sure.
Do we care ? IE. If we define that the moment you have done a syscall,
the reservation state is undefined, we are clear here, don't you think ?
Cheers,
Ben.
^ permalink raw reply
* Re: kernel version 2.6.35-git10 build failure
From: Piotr Hosowicz @ 2010-08-11 8:59 UTC (permalink / raw)
To: Sripathi Kodi; +Cc: linuxppc-dev, Stephen Rothwell, LKML, divya
In-Reply-To: <20100811132313.3d6c7f27@sripathi.in.ibm.com>
On 11.08.2010 09:53, Sripathi Kodi wrote:
> On Wed, 11 Aug 2010 12:51:35 +0530
> divya<dipraksh@linux.vnet.ibm.com> wrote:
>
>> Hi,
>>
>> Today kernel(version 2.6.35-git10 -commitid 3d30701b58970) build fails with following error on both system x and p
>>
>> fs/9p/vfs_inode.c: In function 'v9fs_vfs_setattr_dotl':
>> fs/9p/vfs_inode.c:1267: error: implicit declaration of function 'inode_setattr'
>> make[2]: *** [fs/9p/vfs_inode.o] Error 1
>> make[2]: *** Waiting for unfinished jobs....
>> make[1]: *** [fs/9p] Error 2
>> make[1]: *** Waiting for unfinished jobs....
>> make: *** [fs] Error 2
>> make: *** Waiting for unfinished jobs....
>>
>> Seems like the commit 87d7845aa0b is the corrupt which added the function v9fs_vfs_setattr_dotl()
>
> Yes, it is a problem I created. Stephen Rothwell has already fixed it.
> Al Viro has sent a git pull request to Linus today with the fix in it.
> Here is the patch you need: http://lkml.org/lkml/2010/6/21/442
I fail to apply the patch.
aapi205:/usr/src/linux# patch -p1 < ../9p-patch.txt
patching file fs/9p/vfs_inode.c
Hunk #1 FAILED at 1052.
1 out of 1 hunk FAILED -- saving rejects to file fs/9p/vfs_inode.c.rej
aapi205:/usr/src/linux# cat fs/9p/vfs_inode.c.rej
--- fs/9p/vfs_inode.c
+++ fs/9p/vfs_inode.c
@@ -1052,10 +1052,19 @@
return PTR_ERR(fid);
retval = p9_client_setattr(fid, &p9attr);
- if (retval >= 0)
- retval = inode_setattr(dentry->d_inode, iattr);
+ if (retval < 0)
+ return retval;
- return retval;
+ if ((iattr->ia_valid & ATTR_SIZE) &&
+ iattr->ia_size != i_size_read(dentry->d_inode)) {
+ retval = vmtruncate(dentry->d_inode, iattr->ia_size);
+ if (retval)
+ return retval;
+ }
+
+ setattr_copy(dentry->d_inode, iattr);
+ mark_inode_dirty(dentry->d_inode);
+ return 0;
}
/**
I must be doing something wrong way.
Regards,
Piotr Hosowicz
--
Z cyklu "Uroki demokracji", czyli pytania i odpowiedzi w teledurniejach:
- Jaką walutę mają Indie?
- Ramadan.
NP: Patrick O'Hearn - Approaching Summit
NB: 2.6.35-git9
^ permalink raw reply
* Re: [PATCH] powerpc: Feature nop out reservation clear when stcx checks address
From: Anton Blanchard @ 2010-08-11 11:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20100811064152.GC15252@drongo>
Hi Paul,
> Nice... Just one nit, and that is that I think we now need a dummy
> stcx in the context switch code so there is no possibility of getting
> from one user context to another with a reservation still pending from
> the first context. I guess our chances of getting through schedule()
> without doing any atomics, bitops or spinlocks are pretty remote, but
> nevertheless it might be as well to make sure.
Good point. How does this look? It also swaps uses a larx in the exception
exit path if we can, it's a clear win too.
Anton
--
[PATCH] powerpc: Feature nop out reservation clear when stcx checks address
The POWER architecture does not require stcx to check that it is operating
on the same address as the larx. This means it is possible for an
an exception handler to execute a larx, get a reservation, decide
not to do the stcx and then return back with an active reservation. If the
interrupted code was in the middle of a larx/stcx sequence the stcx could
incorrectly succeed.
All recent POWER CPUs check the address before letting the stcx succeed
so we can create a CPU feature and nop it out. As Ben suggested, we can
only do this in our syscall path because there is a remote possibility
some kernel code gets interrupted by an exception that ends up operating
on the same cacheline.
Thanks to Paul Mackerras and Derek Williams for the idea.
To test this I used a very simple null syscall (actually getppid) testcase
at http://ozlabs.org/~anton/junkcode/null_syscall.c
I tested against 2.6.35-git10 with the following changes against the
pseries_defconfig:
CONFIG_VIRT_CPU_ACCOUNTING=n
CONFIG_AUDIT=n
CONFIG_PPC_4K_PAGES=n
CONFIG_PPC_64K_PAGES=y
CONFIG_FORCE_MAX_ZONEORDER=9
CONFIG_PPC_SUBPAGE_PROT=n
CONFIG_FUNCTION_TRACER=n
CONFIG_FUNCTION_GRAPH_TRACER=n
CONFIG_IRQSOFF_TRACER=n
CONFIG_STACK_TRACER=n
to remove the overhead of virtual CPU accounting, syscall auditing and
the ftrace mcount tracers. 64kB pages were enabled to minimise TLB misses.
POWER6: +8.2%
POWER7: +7.0%
Another suggestion was to use a larx to something in the L1 instead of a stcx.
This was almost as fast as removing the larx on POWER6, but only 3.5% faster
on POWER7. We can use this to speed up the reservation clear in our
exception exit code.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/kernel/entry_64.S
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/entry_64.S 2010-08-11 21:04:52.644491970 +1000
+++ powerpc.git/arch/powerpc/kernel/entry_64.S 2010-08-11 21:13:46.210740998 +1000
@@ -202,7 +202,9 @@ syscall_exit:
bge- syscall_error
syscall_error_cont:
ld r7,_NIP(r1)
+BEGIN_FTR_SECTION
stdcx. r0,0,r1 /* to clear the reservation */
+END_FTR_SECTION_IFCLR(CPU_FTR_STCX_CHECKS_ADDRESS)
andi. r6,r8,MSR_PR
ld r4,_LINK(r1)
/*
@@ -419,6 +421,17 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
sync
#endif /* CONFIG_SMP */
+ /*
+ * If we optimise away the clear of the reservation in system
+ * calls because we know the CPU tracks the address of the
+ * reservation, then we need to clear it here to cover the
+ * case that the kernel context switch path has no larx
+ * instructions.
+ */
+BEGIN_FTR_SECTION
+ ldarx r6,0,r1
+END_FTR_SECTION_IFSET(CPU_FTR_STCX_CHECKS_ADDRESS)
+
addi r6,r4,-THREAD /* Convert THREAD to 'current' */
std r6,PACACURRENT(r13) /* Set new 'current' */
@@ -576,7 +589,16 @@ ALT_FW_FTR_SECTION_END_IFCLR(FW_FEATURE_
andi. r0,r3,MSR_RI
beq- unrecov_restore
+ /*
+ * Clear the reservation. If we know the CPU tracks the address of
+ * the reservation then we can potentially save some cycles and use
+ * a larx. On POWER6 and POWER7 this is significantly faster.
+ */
+BEGIN_FTR_SECTION
stdcx. r0,0,r1 /* to clear the reservation */
+FTR_SECTION_ELSE
+ ldarx r4,0,r1
+ALT_FTR_SECTION_END_IFCLR(CPU_FTR_STCX_CHECKS_ADDRESS)
/*
* Clear RI before restoring r13. If we are returning to
Index: powerpc.git/arch/powerpc/include/asm/cputable.h
===================================================================
--- powerpc.git.orig/arch/powerpc/include/asm/cputable.h 2010-08-11 21:04:52.614491766 +1000
+++ powerpc.git/arch/powerpc/include/asm/cputable.h 2010-08-11 21:13:14.190741348 +1000
@@ -198,6 +198,7 @@ extern const char *powerpc_base_platform
#define CPU_FTR_CP_USE_DCBTZ LONG_ASM_CONST(0x0040000000000000)
#define CPU_FTR_UNALIGNED_LD_STD LONG_ASM_CONST(0x0080000000000000)
#define CPU_FTR_ASYM_SMT LONG_ASM_CONST(0x0100000000000000)
+#define CPU_FTR_STCX_CHECKS_ADDRESS LONG_ASM_CONST(0x0200000000000000)
#ifndef __ASSEMBLY__
@@ -392,28 +393,31 @@ extern const char *powerpc_base_platform
CPU_FTR_MMCRA | CPU_FTR_CTRL)
#define CPU_FTRS_POWER4 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
- CPU_FTR_MMCRA | CPU_FTR_CP_USE_DCBTZ)
+ CPU_FTR_MMCRA | CPU_FTR_CP_USE_DCBTZ | \
+ CPU_FTR_STCX_CHECKS_ADDRESS)
#define CPU_FTRS_PPC970 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_CAN_NAP | CPU_FTR_MMCRA | \
- CPU_FTR_CP_USE_DCBTZ)
+ CPU_FTR_CP_USE_DCBTZ | CPU_FTR_STCX_CHECKS_ADDRESS)
#define CPU_FTRS_POWER5 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
- CPU_FTR_PURR)
+ CPU_FTR_PURR | CPU_FTR_STCX_CHECKS_ADDRESS)
#define CPU_FTRS_POWER6 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
- CPU_FTR_DSCR | CPU_FTR_UNALIGNED_LD_STD)
+ CPU_FTR_DSCR | CPU_FTR_UNALIGNED_LD_STD | \
+ CPU_FTR_STCX_CHECKS_ADDRESS)
#define CPU_FTRS_POWER7 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
- CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_ASYM_SMT)
+ CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_ASYM_SMT | \
+ CPU_FTR_STCX_CHECKS_ADDRESS)
#define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
^ permalink raw reply
* How to use mpc8xxx_gpio.c device driver
From: Ravi Gupta @ 2010-08-11 13:27 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 3156 bytes --]
Hi,
I am new to device driver development. I am trying to access the GPIO of
MPC837xERDB eval board. I have upgraded its kernel to linux-2.6.28.9 and
enable support for mpc8xxx_gpio.c. On boot up, it successfully detect two
gpio controllers. Now my question is how I am going to use it to communicate
with the gpio pins? Do I have to modify the code in mpc8xxx_gpio.c file to
do whatever I want to do with gpios or I can use the standard gpio API
provided in kernel ( gpio_request()/gpio_free() ). I also tries the standard
kernel API, but it fails. Here is my code :
#include <linux/module.h>
#include <linux/errno.h> /* error codes */
#include <linux/gpio.h>
static __init int sample_module_init(void)
{
int ret;
int i;
for (i=1; i<32; i++) {
ret = gpio_request(i, "Sample Driver");
if (ret) {
printk(KERN_WARNING "sample_driver: unable to request GPIO_PG%d\n",
i);
//return ret;
}
}
return 0;
}
static __exit void sample_module_exit(void)
{
gpio_free(9);
}
MODULE_LICENSE("GPL");
module_init(sample_module_init);
module_exit(sample_module_exit);
It give the following O/P:
[ 617.075329] sample_driver: unable to request GPIO_PG1
[ 617.080418] sample_driver: unable to request GPIO_PG2
[ 617.085470] sample_driver: unable to request GPIO_PG3
[ 617.090522] sample_driver: unable to request GPIO_PG4
[ 617.095574] sample_driver: unable to request GPIO_PG5
[ 617.100625] sample_driver: unable to request GPIO_PG6
[ 617.105676] sample_driver: unable to request GPIO_PG7
[ 617.110727] sample_driver: unable to request GPIO_PG8
[ 617.115779] sample_driver: unable to request GPIO_PG9
[ 617.120830] sample_driver: unable to request GPIO_PG10
[ 617.125968] sample_driver: unable to request GPIO_PG11
[ 617.131106] sample_driver: unable to request GPIO_PG12
[ 617.136245] sample_driver: unable to request GPIO_PG13
[ 617.141383] sample_driver: unable to request GPIO_PG14
[ 617.146521] sample_driver: unable to request GPIO_PG15
[ 617.151660] sample_driver: unable to request GPIO_PG16
[ 617.156798] sample_driver: unable to request GPIO_PG17
[ 617.161936] sample_driver: unable to request GPIO_PG18
[ 617.167074] sample_driver: unable to request GPIO_PG19
[ 617.172213] sample_driver: unable to request GPIO_PG20
[ 617.177351] sample_driver: unable to request GPIO_PG21
[ 617.182489] sample_driver: unable to request GPIO_PG22
[ 617.187628] sample_driver: unable to request GPIO_PG23
[ 617.192767] sample_driver: unable to request GPIO_PG24
[ 617.197905] sample_driver: unable to request GPIO_PG25
[ 617.203042] sample_driver: unable to request GPIO_PG26
[ 617.208182] sample_driver: unable to request GPIO_PG27
[ 617.213319] sample_driver: unable to request GPIO_PG28
[ 617.218458] sample_driver: unable to request GPIO_PG29
[ 617.223597] sample_driver: unable to request GPIO_PG30
[ 617.228735] sample_driver: unable to request GPIO_PG31
[ 617.233873] sample_driver: unable to request GPIO_PG32
Can someone provide me a sample code or something else. Actually I am trying
to set the GPIO pin no. 9 to active low as it is connected to a LED on
board.
Thanks in advance
Ravi Gupta
[-- Attachment #2: Type: text/html, Size: 3457 bytes --]
^ permalink raw reply
* Re: How to use mpc8xxx_gpio.c device driver
From: Ravi Gupta @ 2010-08-11 14:19 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-dev
In-Reply-To: <AANLkTinYCfFJB2NR3hcQ4aZU7QXfCs2ixdEu7VuNxf0=@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
Also, when I try to export a gpio in sysfs
echo 9 > /sys/class/gpio/export
It gives me an error in dmesg
gpio_request: gpio-9 (sysfs) status -22
export_store: status -22
Here is a look of sysfs on my machine
# ls /sys/class/gpio/ -la
drwxr-xr-x 4 root root 0 Jan 1 00:00 .
drwxr-xr-x 24 root root 0 Jan 1 00:00 ..
--w------- 1 root root 4096 Jan 1 00:10 export
drwxr-xr-x 3 root root 0 Jan 1 00:00 gpiochip192
drwxr-xr-x 3 root root 0 Jan 1 00:00 gpiochip224
--w------- 1 root root 4096 Jan 1 00:00 unexport
[-- Attachment #2: Type: text/html, Size: 687 bytes --]
^ permalink raw reply
* Re: [PATCH 0/8] v5 De-couple sysfs memory directories from memory sections
From: Dave Hansen @ 2010-08-11 15:18 UTC (permalink / raw)
To: Nathan Fontenot
Cc: linux-mm, Greg KH, linux-kernel, KAMEZAWA Hiroyuki, linuxppc-dev
In-Reply-To: <4C60407C.2080608@austin.ibm.com>
On Mon, 2010-08-09 at 12:53 -0500, Nathan Fontenot wrote:
> This set of patches de-couples the idea that there is a single
> directory in sysfs for each memory section. The intent of the
> patches is to reduce the number of sysfs directories created to
> resolve a boot-time performance issue. On very large systems
> boot time are getting very long (as seen on powerpc hardware)
> due to the enormous number of sysfs directories being created.
> On a system with 1 TB of memory we create ~63,000 directories.
> For even larger systems boot times are being measured in hours.
Hi Nathan,
The set is looking pretty good to me. We _might_ want to up the ante in
the future and allow it to be even more dynamic than this, but this
looks like a good start to me.
BTW, have you taken a look at what the hotplug events look like if only
a single section (not filling up a whole block) is added?
Feel free to add my:
Acked-by: Dave Hansen <dave@linux.vnet.ibm.com>
-- Dave
^ permalink raw reply
* Re: How to use mpc8xxx_gpio.c device driver
From: MJ embd @ 2010-08-11 16:15 UTC (permalink / raw)
To: Ravi Gupta; +Cc: linuxppc-dev, linuxppc-dev
In-Reply-To: <AANLkTinYCfFJB2NR3hcQ4aZU7QXfCs2ixdEu7VuNxf0=@mail.gmail.com>
u can directly access GPIO registers in kernel, by ioremap of GPIO
memory mapped registers.
you might need to check
- muxing of gpio
-mj
On Wed, Aug 11, 2010 at 6:57 PM, Ravi Gupta <dceravigupta@gmail.com> wrote:
> Hi,
>
> I am new to device driver development. I am trying to access the GPIO of
> MPC837xERDB eval board. I have upgraded its kernel to linux-2.6.28.9 and
> enable support for mpc8xxx_gpio.c. On boot up, it successfully detect two
> gpio controllers. Now my question is how I am going to use it to communic=
ate
> with the gpio pins? Do I have to modify the code in mpc8xxx_gpio.c file t=
o
> do whatever I want to do with gpios or I can use the standard gpio API
> provided in kernel ( gpio_request()/gpio_free() ). I also tries the stand=
ard
> kernel API, but it fails. Here is my code :
>
> #include <linux/module.h>
> #include <linux/errno.h>=A0 /* error codes */
> #include <linux/gpio.h>
>
> static __init int sample_module_init(void)
> {
> =A0 int ret;
>
> =A0 int i;
> =A0 for (i=3D1; i<32; i++) {
> =A0=A0=A0 ret =3D gpio_request(i, "Sample Driver");
> =A0=A0=A0 if (ret) {
> =A0=A0=A0=A0=A0 printk(KERN_WARNING "sample_driver: unable to request GPI=
O_PG%d\n",
> i);
> =A0=A0=A0=A0=A0 //return ret;
> =A0=A0=A0 }
> =A0 }
>
> =A0 return 0;
> }
>
> static __exit void sample_module_exit(void)
> {
> =A0 gpio_free(9);
> }
>
> MODULE_LICENSE("GPL");
>
> module_init(sample_module_init);
> module_exit(sample_module_exit);
>
> It give the following O/P:
>
> [=A0 617.075329] sample_driver: unable to request GPIO_PG1
> [=A0 617.080418] sample_driver: unable to request GPIO_PG2
> [=A0 617.085470] sample_driver: unable to request GPIO_PG3
> [=A0 617.090522] sample_driver: unable to request GPIO_PG4
> [=A0 617.095574] sample_driver: unable to request GPIO_PG5
> [=A0 617.100625] sample_driver: unable to request GPIO_PG6
> [=A0 617.105676] sample_driver: unable to request GPIO_PG7
> [=A0 617.110727] sample_driver: unable to request GPIO_PG8
> [=A0 617.115779] sample_driver: unable to request GPIO_PG9
> [=A0 617.120830] sample_driver: unable to request GPIO_PG10
> [=A0 617.125968] sample_driver: unable to request GPIO_PG11
> [=A0 617.131106] sample_driver: unable to request GPIO_PG12
> [=A0 617.136245] sample_driver: unable to request GPIO_PG13
> [=A0 617.141383] sample_driver: unable to request GPIO_PG14
> [=A0 617.146521] sample_driver: unable to request GPIO_PG15
> [=A0 617.151660] sample_driver: unable to request GPIO_PG16
> [=A0 617.156798] sample_driver: unable to request GPIO_PG17
> [=A0 617.161936] sample_driver: unable to request GPIO_PG18
> [=A0 617.167074] sample_driver: unable to request GPIO_PG19
> [=A0 617.172213] sample_driver: unable to request GPIO_PG20
> [=A0 617.177351] sample_driver: unable to request GPIO_PG21
> [=A0 617.182489] sample_driver: unable to request GPIO_PG22
> [=A0 617.187628] sample_driver: unable to request GPIO_PG23
> [=A0 617.192767] sample_driver: unable to request GPIO_PG24
> [=A0 617.197905] sample_driver: unable to request GPIO_PG25
> [=A0 617.203042] sample_driver: unable to request GPIO_PG26
> [=A0 617.208182] sample_driver: unable to request GPIO_PG27
> [=A0 617.213319] sample_driver: unable to request GPIO_PG28
> [=A0 617.218458] sample_driver: unable to request GPIO_PG29
> [=A0 617.223597] sample_driver: unable to request GPIO_PG30
> [=A0 617.228735] sample_driver: unable to request GPIO_PG31
> [=A0 617.233873] sample_driver: unable to request GPIO_PG32
>
> Can someone provide me a sample code or something else. Actually I am try=
ing
> to set the GPIO pin no. 9 to active low as it is connected to a LED on
> board.
>
> Thanks in advance
> Ravi Gupta
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--=20
-mj
^ permalink raw reply
* Re: How to use mpc8xxx_gpio.c device driver
From: Anton Vorontsov @ 2010-08-11 16:45 UTC (permalink / raw)
To: Ravi Gupta; +Cc: linuxppc-dev, MJ embd, linuxppc-dev
In-Reply-To: <AANLkTimJ1+d7U2SN_SSHepo6u01RJqUEXUDQXUgBfCWK@mail.gmail.com>
Hi,
On Wed, Aug 11, 2010 at 06:57:16PM +0530, Ravi Gupta wrote:
> I am new to device driver development. I am trying to access the GPIO of
> MPC837xERDB eval board. I have upgraded its kernel to linux-2.6.28.9 and
> enable support for mpc8xxx_gpio.c. On boot up, it successfully detect two
> gpio controllers. Now my question is how I am going to use it to communicate
> with the gpio pins? Do I have to modify the code in mpc8xxx_gpio.c file to
> do whatever I want to do with gpios or I can use the standard gpio API
> provided in kernel ( gpio_request()/gpio_free() ). I also tries the standard
> kernel API, but it fails. Here is my code :
No, you don't have to modify anything, and yes, you can
use standard kernel GPIO API.
> #include <linux/module.h>
> #include <linux/errno.h> /* error codes */
> #include <linux/gpio.h>
>
> static __init int sample_module_init(void)
> {
> int ret;
>
> int i;
> for (i=1; i<32; i++) {
> ret = gpio_request(i, "Sample Driver");
Before issing gpio_request() you must get GPIO number from the
of_get_gpio() or of_get_gpio_flags() calls (the _flags variant
will also retreive flags such as 'active-low').
The calls assume that you have gpio = <> specifier in the
device tree, see arch/powerpc/boot/dts/mpc8377_rdb.dts's
"leds" node as an example.
As you want GPIO LEDs, you can use drivers/leds/leds-gpio.c
(see of_gpio_leds_probe() call, it gets gpio numbers via
of_get_gpio_flags() and then requests them via gpio_request()).
Also see
Documentation/powerpc/dts-bindings/gpio/gpio.txt
Documentation/powerpc/dts-bindings/gpio/led.txt
> if (ret) {
> printk(KERN_WARNING "sample_driver: unable to request GPIO_PG%d\n",
> i);
> //return ret;
> }
> }
>
> return 0;
> }
On Wed, Aug 11, 2010 at 07:49:40PM +0530, Ravi Gupta wrote:
> Also, when I try to export a gpio in sysfs
>
> echo 9 > /sys/class/gpio/export
The gpio numbers are global, i.e. GPIO controller base + GPIO
number within the controller.
[...]
> drwxr-xr-x 3 root root 0 Jan 1 00:00 gpiochip192
So, if you want GPIO9 within gpiochip192, you should issue
"echo 201 > export".
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: How to use mpc8xxx_gpio.c device driver
From: Ira W. Snyder @ 2010-08-11 16:25 UTC (permalink / raw)
To: Ravi Gupta; +Cc: linuxppc-dev, linuxppc-dev
In-Reply-To: <AANLkTimJ1+d7U2SN_SSHepo6u01RJqUEXUDQXUgBfCWK@mail.gmail.com>
On Wed, Aug 11, 2010 at 07:49:40PM +0530, Ravi Gupta wrote:
> Also, when I try to export a gpio in sysfs
>
> echo 9 > /sys/class/gpio/export
>
> It gives me an error in dmesg
> gpio_request: gpio-9 (sysfs) status -22
> export_store: status -22
>
> Here is a look of sysfs on my machine
>
> # ls /sys/class/gpio/ -la
> drwxr-xr-x 4 root root 0 Jan 1 00:00 .
> drwxr-xr-x 24 root root 0 Jan 1 00:00 ..
> --w------- 1 root root 4096 Jan 1 00:10 export
> drwxr-xr-x 3 root root 0 Jan 1 00:00 gpiochip192
> drwxr-xr-x 3 root root 0 Jan 1 00:00 gpiochip224
> --w------- 1 root root 4096 Jan 1 00:00 unexport
Your GPIO pins are numbered from 192-223 on one GPIO chip, and 224-255
on the next GPIO chip. You should be exporting GPIO pin 200 or 201
(192+8 or 192+9), depending on whether your pins are numbered from zero
or one.
"status -22" is -EINVAL: Invalid Argument. You're doing something which
is invalid, so this makes sense. There is no "pin 9".
Ira
^ permalink raw reply
* [PATCH] booting-without-of: Remove nonexistent chapters from TOC, fix numbering
From: Anton Vorontsov @ 2010-08-11 16:56 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
Marvell and GPIO bindings live in their own files, so the TOC should not
mention them.
Also fix chapters numbering.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
Documentation/powerpc/booting-without-of.txt | 31 +------------------------
1 files changed, 2 insertions(+), 29 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 46d2210..3f454b7 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -49,40 +49,13 @@ Table of Contents
f) MDIO on GPIOs
g) SPI busses
- VII - Marvell Discovery mv64[345]6x System Controller chips
- 1) The /system-controller node
- 2) Child nodes of /system-controller
- a) Marvell Discovery MDIO bus
- b) Marvell Discovery ethernet controller
- c) Marvell Discovery PHY nodes
- d) Marvell Discovery SDMA nodes
- e) Marvell Discovery BRG nodes
- f) Marvell Discovery CUNIT nodes
- g) Marvell Discovery MPSCROUTING nodes
- h) Marvell Discovery MPSCINTR nodes
- i) Marvell Discovery MPSC nodes
- j) Marvell Discovery Watch Dog Timer nodes
- k) Marvell Discovery I2C nodes
- l) Marvell Discovery PIC (Programmable Interrupt Controller) nodes
- m) Marvell Discovery MPP (Multipurpose Pins) multiplexing nodes
- n) Marvell Discovery GPP (General Purpose Pins) nodes
- o) Marvell Discovery PCI host bridge node
- p) Marvell Discovery CPU Error nodes
- q) Marvell Discovery SRAM Controller nodes
- r) Marvell Discovery PCI Error Handler nodes
- s) Marvell Discovery Memory Controller nodes
-
- VIII - Specifying interrupt information for devices
+ VII - Specifying interrupt information for devices
1) interrupts property
2) interrupt-parent property
3) OpenPIC Interrupt Controllers
4) ISA Interrupt Controllers
- IX - Specifying GPIO information for devices
- 1) gpios property
- 2) gpio-controller nodes
-
- X - Specifying device power management information (sleep property)
+ VIII - Specifying device power management information (sleep property)
Appendix A - Sample SOC node for MPC8540
--
1.7.0.5
^ permalink raw reply related
* [PATCH 1/1] powerpc: Clear cpu_sibling_map in cpu_die
From: Brian King @ 2010-08-11 20:34 UTC (permalink / raw)
To: benh; +Cc: brking, linuxppc-dev
While testing CPU DLPAR, the following problem was discovered.
We were DLPAR removing the first CPU, which in this case was
logical CPUs 0-3. CPUs 0-2 were already marked offline and
we were in the process of offlining CPU 3. After marking
the CPU inactive and offline in cpu_disable, but before the
cpu was completely idle (cpu_die), we ended up in __make_request
on CPU 3. There we looked at the topology map to see which CPU
to complete the I/O on and found no CPUs in the cpu_sibling_map.
This resulted in the block layer setting the completion cpu
to be NR_CPUS, which then caused an oops when we tried to
complete the I/O.
Fix this by delaying clearing the sibling map of the cpu we
are offlining for the cpu we are offlining until cpu_die.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
arch/powerpc/kernel/smp.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff -puN arch/powerpc/kernel/smp.c~powerpc_sibling_map_offline arch/powerpc/kernel/smp.c
--- linux-2.6/arch/powerpc/kernel/smp.c~powerpc_sibling_map_offline 2010-08-09 16:49:47.000000000 -0500
+++ linux-2.6-bjking1/arch/powerpc/kernel/smp.c 2010-08-09 16:49:47.000000000 -0500
@@ -598,8 +598,11 @@ int __cpu_disable(void)
/* Update sibling maps */
base = cpu_first_thread_in_core(cpu);
for (i = 0; i < threads_per_core; i++) {
- cpumask_clear_cpu(cpu, cpu_sibling_mask(base + i));
- cpumask_clear_cpu(base + i, cpu_sibling_mask(cpu));
+ if ((base + i) != cpu) {
+ cpumask_clear_cpu(cpu, cpu_sibling_mask(base + i));
+ cpumask_clear_cpu(base + i, cpu_sibling_mask(cpu));
+ }
+
cpumask_clear_cpu(cpu, cpu_core_mask(base + i));
cpumask_clear_cpu(base + i, cpu_core_mask(cpu));
}
@@ -641,6 +644,8 @@ void cpu_hotplug_driver_unlock()
void cpu_die(void)
{
+ cpumask_clear_cpu(smp_processor_id(), cpu_sibling_mask(smp_processor_id()));
+
if (ppc_md.cpu_die)
ppc_md.cpu_die();
}
_
^ permalink raw reply
* Query regarding 2.6.335 RT[Ingo's] and Non-RT performance
From: Manikandan Ramachandran @ 2010-08-11 22:18 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 3340 bytes --]
Hello All,
I created a very simple program which has higher priority than normal
tasks and runs a tight loop. Under same test environment I ran this
program on both non-rt and rt 2.6.33.5 kernel. To my suprise I see that
performance of non-RT kernel is better than RT. non-RT kernel took 3 sec and
366156 usec while RT kernel took about 3 sec and 418011 usec.Can someone
please explain why the performance of non-rt kernel is better than rt
kernel? From the face of the test result, I feel RT has more overhead,Is
there any configuration that I could do to bring down the overhead?
Processor:
----------------
processor : 0
cpu : 7448
clock : 996.000000MHz
revision : 2.2 (pvr 8004 0202)
bogomips : 83.10
processor : 1
cpu : 7448
clock : 996.000000MHz
revision : 2.2 (pvr 8004 0202)
bogomips : 83.10
CFS optimization:
--------------------------
# cat /proc/sys/kernel/sched_rt_runtime_us
1000000
# cat /proc/sys/kernel/sched_rt_period_us
1000000
# cat /proc/sys/kernel/sched_compat_yield
1
Test Program:
---------------------
main()
{
int sched_rr_min,sched_rr_max;
struct sched_param scheduling_parameters;
struct timeval tv,late_tv;
suseconds_t usec_diff,avg_usec = 0;
time_t sec_diff, avg_sec = 0;
int i;
long count = 1;
sched_rr_min = sched_get_priority_min(SCHED_RR);
sched_rr_max = sched_get_priority_max(SCHED_RR);
scheduling_parameters.sched_priority = sched_rr_min+4;
sched_setscheduler(0, SCHED_RR, &scheduling_parameters);// Run the
process with the given priority
for(i = 0 ; i < 150 ; i++) {
gettimeofday(&tv, NULL);
while(count > 0){
//printf(".");
count++;
}
gettimeofday(&late_tv, NULL);
count = 1;
sec_diff = (late_tv.tv_sec - tv.tv_sec);
avg_sec += sec_diff;
usec_diff = ( (late_tv.tv_usec > tv.tv_usec) ? (late_tv.tv_usec -
tv.tv_usec) : ( tv.tv_usec - late_tv.tv_usec));
avg_usec += usec_diff;
printf("Iteration #%d sec %x usec %x\n",i,(sec_diff),(usec_diff));
}
printf("Average of #%d sec %x usec %x\n",i,(avg_sec/i),(avg_usec)/i);
}
Partial Result of non-rt kernel:
-------------------------------------------
Iteration #140 sec 3 usec 3aef8
Iteration #141 sec 3 usec 3aefe
Iteration #142 sec 3 usec 3aee4
*Iteration #143 sec 4 usec b935b [Why there is this periodic bump ??]
[Scheduler at work??]*
Iteration #144 sec 3 usec 3aef2
Iteration #145 sec 3 usec 3aef0
Iteration #146 sec 3 usec 3aef4
*Iteration #147 sec 4 usec b934b*
Iteration #148 sec 3 usec 3aeed
Iteration #149 sec 3 usec 3aef9
Partial Result of rt kernel:
-------------------------------------------
Iteration #135 sec 3 usec 47328
*Iteration #136 sec 4 usec ac4fd
*Iteration #137 sec 3 usec 48b0b
Iteration #138 sec 3 usec 4738c
Iteration #139 sec 4 usec ac4d5
Iteration #140 sec 3 usec 483cb
Iteration #141 sec 3 usec 48500
*Iteration #142 sec 4 usec acc49
*Iteration #143 sec 3 usec 47c1f
Iteration #144 sec 3 usec 478c2
Iteration #145 sec 3 usec 47e48
Iteration #146 sec 4 usec ac9b5
Iteration #147 sec 3 usec 48de4
Iteration #148 sec 3 usec 46fbe
Iteration #149 sec 4 usec ac52e
Average of #150 sec 3 usec 660db
Thanks,
Mani
--
Thanks,
Manik
Think twice about a tree before you take a printout
[-- Attachment #2: Type: text/html, Size: 6395 bytes --]
^ permalink raw reply
* [039/111] irq: Add new IRQ flag IRQF_NO_SUSPEND
From: Greg KH @ 2010-08-11 23:54 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jeremy Fitzhardinge, xen-devel, Thomas Gleixner, Ian Campbell,
devicetree-discuss, Dmitry Torokhov, linuxppc-dev, Paul Mackerras,
linux-input, akpm, torvalds, stable-review, alan
In-Reply-To: <20100811235623.GA24440@kroah.com>
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ian Campbell <ian.campbell@citrix.com>
commit 685fd0b4ea3f0f1d5385610b0d5b57775a8d5842 upstream.
A small number of users of IRQF_TIMER are using it for the implied no
suspend behaviour on interrupts which are not timer interrupts.
Therefore add a new IRQF_NO_SUSPEND flag, rename IRQF_TIMER to
__IRQF_TIMER and redefine IRQF_TIMER in terms of these new flags.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: xen-devel@lists.xensource.com
Cc: linux-input@vger.kernel.org
Cc: linuxppc-dev@ozlabs.org
Cc: devicetree-discuss@lists.ozlabs.org
LKML-Reference: <1280398595-29708-1-git-send-email-ian.campbell@citrix.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
include/linux/interrupt.h | 7 ++++++-
kernel/irq/manage.c | 2 +-
2 files changed, 7 insertions(+), 2 deletions(-)
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -52,16 +52,21 @@
* IRQF_ONESHOT - Interrupt is not reenabled after the hardirq handler finished.
* Used by threaded interrupts which need to keep the
* irq line disabled until the threaded handler has been run.
+ * IRQF_NO_SUSPEND - Do not disable this IRQ during suspend
+ *
*/
#define IRQF_DISABLED 0x00000020
#define IRQF_SAMPLE_RANDOM 0x00000040
#define IRQF_SHARED 0x00000080
#define IRQF_PROBE_SHARED 0x00000100
-#define IRQF_TIMER 0x00000200
+#define __IRQF_TIMER 0x00000200
#define IRQF_PERCPU 0x00000400
#define IRQF_NOBALANCING 0x00000800
#define IRQF_IRQPOLL 0x00001000
#define IRQF_ONESHOT 0x00002000
+#define IRQF_NO_SUSPEND 0x00004000
+
+#define IRQF_TIMER (__IRQF_TIMER | IRQF_NO_SUSPEND)
/*
* Bits used by threaded handlers:
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -200,7 +200,7 @@ static inline int setup_affinity(unsigne
void __disable_irq(struct irq_desc *desc, unsigned int irq, bool suspend)
{
if (suspend) {
- if (!desc->action || (desc->action->flags & IRQF_TIMER))
+ if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND))
return;
desc->status |= IRQ_SUSPENDED;
}
^ permalink raw reply
* [48/54] irq: Add new IRQ flag IRQF_NO_SUSPEND
From: Greg KH @ 2010-08-12 0:01 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jeremy Fitzhardinge, xen-devel, Thomas Gleixner, Ian Campbell,
devicetree-discuss, Dmitry Torokhov, linuxppc-dev, Paul Mackerras,
linux-input, akpm, torvalds, stable-review, alan
In-Reply-To: <20100812000249.GA30948@kroah.com>
2.6.34-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ian Campbell <ian.campbell@citrix.com>
commit 685fd0b4ea3f0f1d5385610b0d5b57775a8d5842 upstream.
A small number of users of IRQF_TIMER are using it for the implied no
suspend behaviour on interrupts which are not timer interrupts.
Therefore add a new IRQF_NO_SUSPEND flag, rename IRQF_TIMER to
__IRQF_TIMER and redefine IRQF_TIMER in terms of these new flags.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: xen-devel@lists.xensource.com
Cc: linux-input@vger.kernel.org
Cc: linuxppc-dev@ozlabs.org
Cc: devicetree-discuss@lists.ozlabs.org
LKML-Reference: <1280398595-29708-1-git-send-email-ian.campbell@citrix.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
include/linux/interrupt.h | 7 ++++++-
kernel/irq/manage.c | 2 +-
2 files changed, 7 insertions(+), 2 deletions(-)
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -52,16 +52,21 @@
* IRQF_ONESHOT - Interrupt is not reenabled after the hardirq handler finished.
* Used by threaded interrupts which need to keep the
* irq line disabled until the threaded handler has been run.
+ * IRQF_NO_SUSPEND - Do not disable this IRQ during suspend
+ *
*/
#define IRQF_DISABLED 0x00000020
#define IRQF_SAMPLE_RANDOM 0x00000040
#define IRQF_SHARED 0x00000080
#define IRQF_PROBE_SHARED 0x00000100
-#define IRQF_TIMER 0x00000200
+#define __IRQF_TIMER 0x00000200
#define IRQF_PERCPU 0x00000400
#define IRQF_NOBALANCING 0x00000800
#define IRQF_IRQPOLL 0x00001000
#define IRQF_ONESHOT 0x00002000
+#define IRQF_NO_SUSPEND 0x00004000
+
+#define IRQF_TIMER (__IRQF_TIMER | IRQF_NO_SUSPEND)
/*
* Bits used by threaded handlers:
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -200,7 +200,7 @@ static inline int setup_affinity(unsigne
void __disable_irq(struct irq_desc *desc, unsigned int irq, bool suspend)
{
if (suspend) {
- if (!desc->action || (desc->action->flags & IRQF_TIMER))
+ if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND))
return;
desc->status |= IRQ_SUSPENDED;
}
^ permalink raw reply
* [64/67] irq: Add new IRQ flag IRQF_NO_SUSPEND
From: Greg KH @ 2010-08-12 0:06 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jeremy Fitzhardinge, xen-devel, Thomas Gleixner, Ian Campbell,
devicetree-discuss, Dmitry Torokhov, linuxppc-dev, Paul Mackerras,
linux-input, akpm, torvalds, stable-review, alan
In-Reply-To: <20100812000641.GA6348@kroah.com>
2.6.35-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ian Campbell <ian.campbell@citrix.com>
commit 685fd0b4ea3f0f1d5385610b0d5b57775a8d5842 upstream.
A small number of users of IRQF_TIMER are using it for the implied no
suspend behaviour on interrupts which are not timer interrupts.
Therefore add a new IRQF_NO_SUSPEND flag, rename IRQF_TIMER to
__IRQF_TIMER and redefine IRQF_TIMER in terms of these new flags.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: xen-devel@lists.xensource.com
Cc: linux-input@vger.kernel.org
Cc: linuxppc-dev@ozlabs.org
Cc: devicetree-discuss@lists.ozlabs.org
LKML-Reference: <1280398595-29708-1-git-send-email-ian.campbell@citrix.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
include/linux/interrupt.h | 7 ++++++-
kernel/irq/manage.c | 2 +-
2 files changed, 7 insertions(+), 2 deletions(-)
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -53,16 +53,21 @@
* IRQF_ONESHOT - Interrupt is not reenabled after the hardirq handler finished.
* Used by threaded interrupts which need to keep the
* irq line disabled until the threaded handler has been run.
+ * IRQF_NO_SUSPEND - Do not disable this IRQ during suspend
+ *
*/
#define IRQF_DISABLED 0x00000020
#define IRQF_SAMPLE_RANDOM 0x00000040
#define IRQF_SHARED 0x00000080
#define IRQF_PROBE_SHARED 0x00000100
-#define IRQF_TIMER 0x00000200
+#define __IRQF_TIMER 0x00000200
#define IRQF_PERCPU 0x00000400
#define IRQF_NOBALANCING 0x00000800
#define IRQF_IRQPOLL 0x00001000
#define IRQF_ONESHOT 0x00002000
+#define IRQF_NO_SUSPEND 0x00004000
+
+#define IRQF_TIMER (__IRQF_TIMER | IRQF_NO_SUSPEND)
/*
* Bits used by threaded handlers:
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -216,7 +216,7 @@ static inline int setup_affinity(unsigne
void __disable_irq(struct irq_desc *desc, unsigned int irq, bool suspend)
{
if (suspend) {
- if (!desc->action || (desc->action->flags & IRQF_TIMER))
+ if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND))
return;
desc->status |= IRQ_SUSPENDED;
}
^ permalink raw reply
* [PATCH] powerpc: Fix bogus it_blocksize in VIO iommu code
From: Anton Blanchard @ 2010-08-12 2:42 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
When looking at some issues with the virtual ethernet driver I noticed
that TCE allocation was following a very strange pattern:
address 00e9000 length 2048
address 0409000 length 2048 <-----
address 0429000 length 2048
address 0449000 length 2048
address 0469000 length 2048
address 0489000 length 2048
address 04a9000 length 2048
address 04c9000 length 2048
address 04e9000 length 2048
address 4009000 length 2048 <-----
address 4029000 length 2048
Huge unexplained gaps in what should be an empty TCE table. It turns out
it_blocksize, the amount we want to align the next allocation to, was
c0000000fe903b20. Completely bogus.
Initialise it to something reasonable in the VIO IOMMU code, and use kzalloc
everywhere to protect against this when we next add a non compulsary
field to iommu code and forget to initialise it.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/kernel/vio.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/vio.c 2010-08-12 12:27:58.674490962 +1000
+++ powerpc.git/arch/powerpc/kernel/vio.c 2010-08-12 12:28:18.660741428 +1000
@@ -1059,7 +1059,7 @@ static struct iommu_table *vio_build_iom
if (!dma_window)
return NULL;
- tbl = kmalloc(sizeof(*tbl), GFP_KERNEL);
+ tbl = kzalloc(sizeof(*tbl), GFP_KERNEL);
if (tbl == NULL)
return NULL;
@@ -1072,6 +1072,7 @@ static struct iommu_table *vio_build_iom
tbl->it_offset = offset >> IOMMU_PAGE_SHIFT;
tbl->it_busno = 0;
tbl->it_type = TCE_VB;
+ tbl->it_blocksize = 16;
return iommu_init_table(tbl, -1);
}
Index: powerpc.git/arch/powerpc/platforms/iseries/iommu.c
===================================================================
--- powerpc.git.orig/arch/powerpc/platforms/iseries/iommu.c 2010-08-12 12:29:35.473241172 +1000
+++ powerpc.git/arch/powerpc/platforms/iseries/iommu.c 2010-08-12 12:29:50.190890563 +1000
@@ -184,7 +184,7 @@ static void pci_dma_dev_setup_iseries(st
BUG_ON(lsn == NULL);
- tbl = kmalloc(sizeof(struct iommu_table), GFP_KERNEL);
+ tbl = kzalloc(sizeof(struct iommu_table), GFP_KERNEL);
iommu_table_getparms_iSeries(pdn->busno, *lsn, 0, tbl);
Index: powerpc.git/arch/powerpc/platforms/pseries/iommu.c
===================================================================
--- powerpc.git.orig/arch/powerpc/platforms/pseries/iommu.c 2010-08-12 12:28:45.340756738 +1000
+++ powerpc.git/arch/powerpc/platforms/pseries/iommu.c 2010-08-12 12:29:15.401118951 +1000
@@ -403,7 +403,7 @@ static void pci_dma_bus_setup_pSeries(st
pci->phb->dma_window_size = 0x8000000ul;
pci->phb->dma_window_base_cur = 0x8000000ul;
- tbl = kmalloc_node(sizeof(struct iommu_table), GFP_KERNEL,
+ tbl = kzalloc_node(sizeof(struct iommu_table), GFP_KERNEL,
pci->phb->node);
iommu_table_setparms(pci->phb, dn, tbl);
@@ -448,7 +448,7 @@ static void pci_dma_bus_setup_pSeriesLP(
pdn->full_name, ppci->iommu_table);
if (!ppci->iommu_table) {
- tbl = kmalloc_node(sizeof(struct iommu_table), GFP_KERNEL,
+ tbl = kzalloc_node(sizeof(struct iommu_table), GFP_KERNEL,
ppci->phb->node);
iommu_table_setparms_lpar(ppci->phb, pdn, tbl, dma_window,
bus->number);
@@ -478,7 +478,7 @@ static void pci_dma_dev_setup_pSeries(st
struct pci_controller *phb = PCI_DN(dn)->phb;
pr_debug(" --> first child, no bridge. Allocating iommu table.\n");
- tbl = kmalloc_node(sizeof(struct iommu_table), GFP_KERNEL,
+ tbl = kzalloc_node(sizeof(struct iommu_table), GFP_KERNEL,
phb->node);
iommu_table_setparms(phb, dn, tbl);
PCI_DN(dn)->iommu_table = iommu_init_table(tbl, phb->node);
@@ -544,7 +544,7 @@ static void pci_dma_dev_setup_pSeriesLP(
pci = PCI_DN(pdn);
if (!pci->iommu_table) {
- tbl = kmalloc_node(sizeof(struct iommu_table), GFP_KERNEL,
+ tbl = kzalloc_node(sizeof(struct iommu_table), GFP_KERNEL,
pci->phb->node);
iommu_table_setparms_lpar(pci->phb, pdn, tbl, dma_window,
pci->phb->bus->number);
Index: powerpc.git/arch/powerpc/platforms/cell/iommu.c
===================================================================
--- powerpc.git.orig/arch/powerpc/platforms/cell/iommu.c 2010-08-12 12:31:27.040741891 +1000
+++ powerpc.git/arch/powerpc/platforms/cell/iommu.c 2010-08-12 12:31:34.641324320 +1000
@@ -477,7 +477,7 @@ cell_iommu_setup_window(struct cbe_iommu
ioid = cell_iommu_get_ioid(np);
- window = kmalloc_node(sizeof(*window), GFP_KERNEL, iommu->nid);
+ window = kzalloc_node(sizeof(*window), GFP_KERNEL, iommu->nid);
BUG_ON(window == NULL);
window->offset = offset;
^ permalink raw reply
* RE: [PATCH 1/2] mmc: change ACMD12 to AUTO_CMD12 for more clear
From: Zang Roy-R61911 @ 2010-08-12 4:00 UTC (permalink / raw)
To: Zang Roy-R61911, akpm, linux-mmc; +Cc: linuxppc-dev, mirqus
=20
> -----Original Message-----
> From: Zang Roy-R61911=20
> Sent: Wednesday, August 11, 2010 12:47 PM
> To: Zang Roy-R61911; akpm@linux-foundation.org;=20
> linux-mmc@vger.kernel.org
> Cc: linuxppc-dev@ozlabs.org; mirqus@gmail.com;=20
> cbouatmailru@gmail.com; grant.likely@secretlab.ca
> Subject: RE: [PATCH 1/2] mmc: change ACMD12 to AUTO_CMD12 for=20
> more clear
>=20
> =20
>=20
> > -----Original Message-----
> > From: Zang Roy-R61911=20
> > Sent: Tuesday, August 10, 2010 17:47 PM
> > To: akpm@linux-foundation.org; linux-mmc@vger.kernel.org
> > Cc: linuxppc-dev@ozlabs.org; mirqus@gmail.com;=20
> > cbouatmailru@gmail.com; grant.likely@secretlab.ca
> > Subject: [PATCH 1/2] mmc: change ACMD12 to AUTO_CMD12 for more clear
> >=20
> > Change ACMD12 to AUTO_CMD12 to reduce the confusion.
> > ACMD12 might be confused with MMC/SD App CMD 12 (CMD55+CMD12 combo).
> >=20
> > Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> > ---
> > drivers/mmc/host/sdhci-of-core.c | 2 +-
> > drivers/mmc/host/sdhci.c | 8 ++++----
> > drivers/mmc/host/sdhci.h | 10 +++++-----
> > 3 files changed, 10 insertions(+), 10 deletions(-)
> Andrew,=20
> Could you help to pick up this minor fix?
> Thanks.
> Roy
Any update?
Thanks.
Roy
^ permalink raw reply
* Re: [PATCH 1/2] mmc: change ACMD12 to AUTO_CMD12 for more clear
From: Grant Likely @ 2010-08-12 4:21 UTC (permalink / raw)
To: Zang Roy-R61911; +Cc: linux-mmc, linuxppc-dev, mirqus, akpm
In-Reply-To: <3850A844E6A3854C827AC5C0BEC7B60A0565B8@zch01exm23.fsl.freescale.net>
On Wed, Aug 11, 2010 at 10:00 PM, Zang Roy-R61911 <r61911@freescale.com> wr=
ote:
>
>
>> -----Original Message-----
>> From: Zang Roy-R61911
>> Sent: Wednesday, August 11, 2010 12:47 PM
>> To: Zang Roy-R61911; akpm@linux-foundation.org;
>> linux-mmc@vger.kernel.org
>> Cc: linuxppc-dev@ozlabs.org; mirqus@gmail.com;
>> cbouatmailru@gmail.com; grant.likely@secretlab.ca
>> Subject: RE: [PATCH 1/2] mmc: change ACMD12 to AUTO_CMD12 for
>> more clear
>>
>>
>>
>> > -----Original Message-----
>> > From: Zang Roy-R61911
>> > Sent: Tuesday, August 10, 2010 17:47 PM
>> > To: akpm@linux-foundation.org; linux-mmc@vger.kernel.org
>> > Cc: linuxppc-dev@ozlabs.org; mirqus@gmail.com;
>> > cbouatmailru@gmail.com; grant.likely@secretlab.ca
>> > Subject: [PATCH 1/2] mmc: change ACMD12 to AUTO_CMD12 for more clear
>> >
>> > Change ACMD12 to AUTO_CMD12 to reduce the confusion.
>> > ACMD12 might be confused with MMC/SD App CMD 12 (CMD55+CMD12 combo).
>> >
>> > Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
>> > ---
>> > =A0drivers/mmc/host/sdhci-of-core.c | =A0 =A02 +-
>> > =A0drivers/mmc/host/sdhci.c =A0 =A0 =A0 =A0 | =A0 =A08 ++++----
>> > =A0drivers/mmc/host/sdhci.h =A0 =A0 =A0 =A0 | =A0 10 +++++-----
>> > =A03 files changed, 10 insertions(+), 10 deletions(-)
>> Andrew,
>> Could you help to pick up this minor fix?
>> Thanks.
>> Roy
> Any update?
> Thanks.
> Roy
Patience Roy. You only sent the patch 1 day ago.
g.
^ permalink raw reply
* Looking for a tutorial on the use of the new of_??? init functions
From: LEROY Christophe @ 2010-08-12 8:13 UTC (permalink / raw)
To: LinuxPPC-dev
Hello,
Is there a tutorial or an HOWTO out somewhere explaining the use of
those new of_platform_xxx() and other of_xxx() functions in the init of
drivers ? It looks like a very nice way to write drivers in Linux 2-6
but a little help would be welcomed.
Regards
Christophe
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox