* 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
* 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: 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: [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: 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
* 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: [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
* 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: 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: 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: 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
* 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 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 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: [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
* [PATCH] powerpc, perf_event: Reduce latency of calling perf_event_do_pending
From: Paul Mackerras @ 2010-08-11 6:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Peter Zijlstra, Ingo Molnar, Milton Miller
Commit 0fe1ac48 ("powerpc/perf_event: Fix oops due to
perf_event_do_pending call") moved the call to perf_event_do_pending
in timer_interrupt() down so that it was after the irq_enter() call.
Unfortunately this moved it after the code that checks whether it
is time for the next decrementer clock event. The result is that
the call to perf_event_do_pending() won't happen until the next
decrementer clock event is due. This was pointed out by Milton
Miller.
This fixes it by moving the check for whether it's time for the
next decrementer clock event down to the point where we're about
to call the event handler, after we've called perf_event_do_pending.
This has the side effect that on old pre-Core99 Powermacs where we
use the ppc_n_lost_interrupts mechanism to replay interrupts, a
replayed interrupt will incur a little more latency since it will
now do the code from the irq_enter down to the irq_exit, that it
used to skip. However, these machines are now old and rare enough
that this doesn't matter. To make it clear that ppc_n_lost_interrupts
is only used on Powermacs, and to speed up the code slightly on
non-Powermac ppc32 machines, the code that tests ppc_n_lost_interrupts
is now conditional on CONFIG_PMAC as well as CONFIG_PPC32.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Cc: stable@kernel.org
---
Ingo, Peter: this is for information & comment, I'll ask Ben to send
this to Linus through his tree.
arch/powerpc/kernel/time.c | 23 +++++++++++------------
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index ce53dfa..8533b3b 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -577,20 +577,11 @@ void timer_interrupt(struct pt_regs * regs)
* some CPUs will continuue to take decrementer exceptions */
set_dec(DECREMENTER_MAX);
-#ifdef CONFIG_PPC32
+#if defined(CONFIG_PPC32) && defined(CONFIG_PMAC)
if (atomic_read(&ppc_n_lost_interrupts) != 0)
do_IRQ(regs);
#endif
- now = get_tb_or_rtc();
- if (now < decrementer->next_tb) {
- /* not time for this event yet */
- now = decrementer->next_tb - now;
- if (now <= DECREMENTER_MAX)
- set_dec((int)now);
- trace_timer_interrupt_exit(regs);
- return;
- }
old_regs = set_irq_regs(regs);
irq_enter();
@@ -606,8 +597,16 @@ void timer_interrupt(struct pt_regs * regs)
get_lppaca()->int_dword.fields.decr_int = 0;
#endif
- if (evt->event_handler)
- evt->event_handler(evt);
+ now = get_tb_or_rtc();
+ if (now >= decrementer->next_tb) {
+ decrementer->next_tb = ~(u64)0;
+ if (evt->event_handler)
+ evt->event_handler(evt);
+ } else {
+ now = decrementer->next_tb - now;
+ if (now <= DECREMENTER_MAX)
+ set_dec((int)now);
+ }
#ifdef CONFIG_PPC_ISERIES
if (firmware_has_feature(FW_FEATURE_ISERIES) && hvlpevent_is_pending())
^ permalink raw reply related
* DMA transfer within kernel space
From: Ravi Gupta @ 2010-08-11 6:09 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
Hi,
I am new to linux device driver development and I'm trying to learn the
DMA transfer. Currently I have created a DMA buffer using
pci_alloc_consistent() function. Since I don't have a real DMA enabled pci
device, so I am thinking of transfer the data in the DMA buffer to some
other buffer within kernel space(let say created through kmalloc) using
DMA.
Is it possible to do DMA transfer within kernel space? If yes, please
provide some sample code for the same.
Thanks in advance
Ravi Gupta
[-- Attachment #2: Type: text/html, Size: 541 bytes --]
^ permalink raw reply
* [PATCH] powerpc: move arch_sd_sibling_asym_packing() to smp.c
From: Michael Neuling @ 2010-08-11 6:02 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Simple cleanup by moving arch_sd_sibling_asym_packing from process.c to
smp.c to save an #ifdef CONFIG_SMP
No functionality change.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/process.c | 11 -----------
arch/powerpc/kernel/smp.c | 9 +++++++++
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index e78a5ad..551f671 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1299,14 +1299,3 @@ unsigned long randomize_et_dyn(unsigned long base)
return ret;
}
-
-#ifdef CONFIG_SMP
-int arch_sd_sibling_asym_packing(void)
-{
- if (cpu_has_feature(CPU_FTR_ASYM_SMT)) {
- printk_once(KERN_INFO "Enabling Asymmetric SMT scheduling\n");
- return SD_ASYM_PACKING;
- }
- return 0;
-}
-#endif
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index a61b3dd..41be244 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -580,6 +580,15 @@ void __init smp_cpus_done(unsigned int max_cpus)
dump_numa_cpu_topology();
}
+int arch_sd_sibling_asym_packing(void)
+{
+ if (cpu_has_feature(CPU_FTR_ASYM_SMT)) {
+ printk_once(KERN_INFO "Enabling Asymmetric SMT scheduling\n");
+ return SD_ASYM_PACKING;
+ }
+ return 0;
+}
+
#ifdef CONFIG_HOTPLUG_CPU
int __cpu_disable(void)
{
^ permalink raw reply related
* [PATCH] powerpc: Feature nop out reservation clear when stcx checks address
From: Anton Blanchard @ 2010-08-11 5:20 UTC (permalink / raw)
To: paulus, benh; +Cc: linuxppc-dev
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%
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/include/asm/cputable.h
===================================================================
--- powerpc.git.orig/arch/powerpc/include/asm/cputable.h 2010-08-11 12:56:03.340741765 +1000
+++ powerpc.git/arch/powerpc/include/asm/cputable.h 2010-08-11 13:02:30.131470190 +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 | \
Index: powerpc.git/arch/powerpc/kernel/entry_64.S
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/entry_64.S 2010-08-11 12:56:03.360742333 +1000
+++ powerpc.git/arch/powerpc/kernel/entry_64.S 2010-08-11 13:00:08.862283406 +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)
/*
^ permalink raw reply
* RE: [PATCH 1/2] mmc: change ACMD12 to AUTO_CMD12 for more clear
From: Zang Roy-R61911 @ 2010-08-11 4:47 UTC (permalink / raw)
To: Zang Roy-R61911, akpm, linux-mmc; +Cc: linuxppc-dev, mirqus
In-Reply-To: <1281433632-18758-1-git-send-email-tie-fei.zang@freescale.com>
=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
^ permalink raw reply
* RE: [PATCH 1/3][MTD] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Zang Roy-R61911 @ 2010-08-11 2:45 UTC (permalink / raw)
To: Zang Roy-R61911, linux-mtd
Cc: Lan Chunhe-B25806, linuxppc-dev, akpm, Gala Kumar-B11780,
Wood Scott-B07421
In-Reply-To: <1281063096-26598-1-git-send-email-tie-fei.zang@freescale.com>
=20
> -----Original Message-----
> From: Zang Roy-R61911=20
> Sent: Friday, August 06, 2010 10:52 AM
> To: linux-mtd@lists.infradead.org
> Cc: linuxppc-dev@ozlabs.org; akpm@linux-foundation.org; Gala=20
> Kumar-B11780; Lan Chunhe-B25806
> Subject: [PATCH 1/3][MTD] P4080/eLBC: Make Freescale elbc=20
> interrupt common to elbc devices
>=20
> From: Lan Chunhe-B25806 <b25806@freescale.com>
>=20
> Move Freescale elbc interrupt from nand dirver to elbc driver.
> Then all elbc devices can use the interrupt instead of ONLY nand.
>=20
> Signed-off-by: Lan Chunhe-B25806 <b25806@freescale.com>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
> send the patch to linux-mtd@lists.infradead.org
> it has been posted to linuxppc-dev@ozlabs.org and do not get=20
> any comment.
>=20
> arch/powerpc/Kconfig | 7 +-
> arch/powerpc/include/asm/fsl_lbc.h | 34 +++++-
> arch/powerpc/sysdev/fsl_lbc.c | 254=20
> ++++++++++++++++++++++++++++++------
> 3 files changed, 253 insertions(+), 42 deletions(-)
Who is response to review the nand driver in mtd list?
Please help to comment on this serial patch.
Thanks.
Roy
^ permalink raw reply
* Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
From: Darren Hart @ 2010-08-10 22:36 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Stephen Rothwell, Gautham R Shenoy, Steven Rostedt, linuxppc-dev,
Will Schmidt, Paul Mackerras
In-Reply-To: <alpine.LFD.2.00.1007222028420.2616@localhost.localdomain>
On 07/22/2010 11:38 AM, Thomas Gleixner wrote:
> On Thu, 22 Jul 2010, Darren Hart wrote:
>
>> Also of interest is that this path
>> cpu_idle()->cpu_die()->pseries_mach_cpu_die() to start_secondary()
>> enters with a preempt_count=1 if it wasn't corrupted across the hcall.
>
> That triggers the problem as well. preempt_count needs to be 0 when
> entering start_secondary(). So I really wonder how that ever worked.
>
>> The early boot path from _start however appears to call
>> start_secondary() with a preempt_count of 0.
>
> Which is correct.
>
>> The following patch is most certainly not correct, but it does eliminate
>
> It is correct, but i think it is incomplete as other portions of the
> thread_info on the stack might be in some weird state as well.
Just FYI, I took a look at the stack pointers as well as all the fields
in the thread_info struct. The only one that changes is preempt_count.
The previous value of preempt_count doesn't impact the value after cede.
An initial value of 0, 1, or 4 all result in an after-cede value of
0xffffffff. I also added 32 bits of padding on either side of the
preempt_count in case the change was accidental - it wasnt', the padded
values remained unchanged across the cede call while the preempt_count
still changed to 0xffffffff.
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
^ permalink raw reply
* Re: [PATCH 0/6] Remove owner field from sysfs attribute structure
From: Guenter Roeck @ 2010-08-10 16:43 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Mark Brown, David Woodhouse, James Smart, Greg KH,
linuxppc-dev@ozlabs.org, James E.J. Bottomley, Paul Mackerras,
Nick Cheng, linux-scsi@vger.kernel.org, Eric Biederman,
Alex Iannicelli, Benjamin Thery, Chris Wright, Tejun Heo,
Liam Girdwood, Linus Walleij, Dmitry Torokhov, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, Richard Purdie, Jani Nikula,
Jean Delvare
In-Reply-To: <20100811012001.6fb50655.sfr@canb.auug.org.au>
On Tue, 2010-08-10 at 11:20 -0400, Stephen Rothwell wrote:
> Hi Jean,
>
> On Wed, 11 Aug 2010 01:17:33 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Tue, 10 Aug 2010 15:43:37 +0200 Jean Delvare <khali@linux-fr.org> wrote:
> > >
> > > Related bug?
> > >
> > > https://bugzilla.kernel.org/show_bug.cgi?id=16544
> >
> > Yep, fixed in linux-next today - hopefully the fix is on its way to Linus.
>
> Sorry, more info:
>
> Fixed by commit 690e85a3957291f4cfe0cac22d97994ec7e5ee45 ("olpc_battery:
> Fix build failure caused by sysfs changes") from the battery tree.
Excellent. Guess the patch I sent out earlier today to fix the problem
wasn't needed then.
Guenter
^ permalink raw reply
* Re: [PATCH 0/6] Remove owner field from sysfs attribute structure
From: Stephen Rothwell @ 2010-08-10 15:20 UTC (permalink / raw)
To: Jean Delvare
Cc: Mark Brown, David Woodhouse, James Smart, Greg KH, linuxppc-dev,
James E.J. Bottomley, Paul Mackerras, Guenter Roeck, Nick Cheng,
linux-scsi, Eric Biederman, Alex Iannicelli, Benjamin Thery,
Chris Wright, Liam Girdwood, Linus Walleij, Dmitry Torokhov,
Greg Kroah-Hartman, linux-kernel, Richard Purdie, Jani Nikula,
Tejun Heo
In-Reply-To: <20100811011733.16243ddb.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 615 bytes --]
Hi Jean,
On Wed, 11 Aug 2010 01:17:33 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Tue, 10 Aug 2010 15:43:37 +0200 Jean Delvare <khali@linux-fr.org> wrote:
> >
> > Related bug?
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=16544
>
> Yep, fixed in linux-next today - hopefully the fix is on its way to Linus.
Sorry, more info:
Fixed by commit 690e85a3957291f4cfe0cac22d97994ec7e5ee45 ("olpc_battery:
Fix build failure caused by sysfs changes") from the battery tree.
--
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: [PATCH 0/6] Remove owner field from sysfs attribute structure
From: Stephen Rothwell @ 2010-08-10 15:17 UTC (permalink / raw)
To: Jean Delvare
Cc: Guenter Roeck, Greg Kroah-Hartman, Dmitry Torokhov, Linus Walleij,
James Smart, Eric Biederman, Greg KH, Mark Brown, linux-kernel,
Chris Wright, linuxppc-dev, James E.J. Bottomley, Richard Purdie,
Nick Cheng, Jani Nikula, Tejun Heo, Paul Mackerras, Liam Girdwood,
linux-scsi, Alex Iannicelli, Benjamin Thery
In-Reply-To: <20100810154337.006a0df9@hyperion.delvare>
[-- Attachment #1: Type: text/plain, Size: 352 bytes --]
Hi Jean,
On Tue, 10 Aug 2010 15:43:37 +0200 Jean Delvare <khali@linux-fr.org> wrote:
>
> Related bug?
>
> https://bugzilla.kernel.org/show_bug.cgi?id=16544
Yep, fixed in linux-next today - hopefully the fix is on its way to Linus.
--
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
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