* Re: [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982
From: Peter Zijlstra @ 2011-07-07 12:28 UTC (permalink / raw)
To: mahesh; +Cc: torvalds, mingo, linuxppc-dev, linux-kernel, anton
In-Reply-To: <20110707115531.GA21737@in.ibm.com>
On Thu, 2011-07-07 at 17:25 +0530, Mahesh J Salgaonkar wrote:
> > I guess I'm asking is, do smaller P7 machines boot? And if so, is there
> > any difference except size?
>=20
> Yes, the smaller P7 machine that I have with 20 CPUs and 2GB ram boots
> fine with 3.0.0-rc.=20
That sounds like a single node machine. P7 comes as {4,6,8}*4 (16,24,32
cpus) per socket. And that 2G doesn't sound like much either.
^ permalink raw reply
* [PATCH] powerpc/5200: dts: digsy_mtc.dts: enable both MSCAN nodes
From: Anatolij Gustschin @ 2011-07-07 12:49 UTC (permalink / raw)
To: grant.likely, linuxppc-dev; +Cc: Anatolij Gustschin
We use both MSCAN controllers on this board, so do not disable
them in the device tree.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
arch/powerpc/boot/dts/digsy_mtc.dts | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/boot/dts/digsy_mtc.dts b/arch/powerpc/boot/dts/digsy_mtc.dts
index 2aad7ae..a7511f2 100644
--- a/arch/powerpc/boot/dts/digsy_mtc.dts
+++ b/arch/powerpc/boot/dts/digsy_mtc.dts
@@ -37,14 +37,6 @@
status = "disabled";
};
- can@900 {
- status = "disabled";
- };
-
- can@980 {
- status = "disabled";
- };
-
spi@f00 {
msp430@0 {
compatible = "spidev";
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v3 1/3] driver core: Add ability for arch code to setup pdev_archdata
From: Kumar Gala @ 2011-07-07 13:55 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20110701220900.GA28971@kroah.com>
On Jul 1, 2011, at 5:09 PM, Greg KH wrote:
> On Thu, Jun 23, 2011 at 06:33:57AM -0500, Kumar Gala wrote:
>> On some architectures we need to setup pdev_archdata before we add =
the
>> device. Waiting til a bus_notifier is too late since we might need =
the
>> pdev_archdata in the bus notifier. One example is setting up of =
dma_mask
>> pointers such that it can be used in a bus_notifier.
>>=20
>> We add noop version of arch_setup_pdev_archdata() in
>> <asm-generic/platform_device.h> and allow the arch code to override =
with
>> access the full definitions of struct device, struct platform_device, =
and
>> struct pdev_archdata.
>=20
> Isn't there some way to use "weak" symbols to keep us from having to
> create this .h file in every single arch and then if the arch wants to
> define it, it does so?
>=20
> That should make this patch simpler, right?
>=20
> thanks,
>=20
> greg k-h
Changing to weak should be doable if we are ok with the additional =
function call always happening.
- k
^ permalink raw reply
* [PATCH] Remove a BUG_ON that triggered when running under FSL Hypervisor
From: Laurentiu TUDOR @ 2011-07-07 13:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Laurentiu TUDOR
mpc85xx_smp_init platform init function assumed that smp_ops.message_pass
was set to default arch dependent smp_muxed_ipi_message_pass.
However this does not seem to happen. Moreover, the arch specific code
in arch/powerpc/kernel/smp.c handles smp_ops.message_pass == NULL and if so
calls the default implementation.
Signed-off-by: Laurentiu TUDOR <Laurentiu.Tudor@freescale.com>
---
arch/powerpc/platforms/85xx/smp.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
index f5aa619..5b9b901 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -2,7 +2,7 @@
* Author: Andy Fleming <afleming@freescale.com>
* Kumar Gala <galak@kernel.crashing.org>
*
- * Copyright 2006-2008 Freescale Semiconductor Inc.
+ * Copyright 2006-2008, 2011 Freescale Semiconductor Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -239,12 +239,13 @@ void __init mpc85xx_smp_init(void)
}
if (cpu_has_feature(CPU_FTR_DBELL)) {
- /* .message_pass defaults to smp_muxed_ipi_message_pass */
+ /*
+ * If left NULL, .message_pass defaults to
+ * smp_muxed_ipi_message_pass
+ */
smp_85xx_ops.cause_ipi = doorbell_cause_ipi;
}
- BUG_ON(!smp_85xx_ops.message_pass);
-
smp_ops = &smp_85xx_ops;
#ifdef CONFIG_KEXEC
--
1.6.6
^ permalink raw reply related
* Re: [PATCH v3 1/3] driver core: Add ability for arch code to setup pdev_archdata
From: Greg KH @ 2011-07-07 14:11 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <597354F4-D1D4-4BC0-9251-FDDC31B1E2A1@kernel.crashing.org>
On Thu, Jul 07, 2011 at 08:55:44AM -0500, Kumar Gala wrote:
>
> On Jul 1, 2011, at 5:09 PM, Greg KH wrote:
>
> > On Thu, Jun 23, 2011 at 06:33:57AM -0500, Kumar Gala wrote:
> >> On some architectures we need to setup pdev_archdata before we add the
> >> device. Waiting til a bus_notifier is too late since we might need the
> >> pdev_archdata in the bus notifier. One example is setting up of dma_mask
> >> pointers such that it can be used in a bus_notifier.
> >>
> >> We add noop version of arch_setup_pdev_archdata() in
> >> <asm-generic/platform_device.h> and allow the arch code to override with
> >> access the full definitions of struct device, struct platform_device, and
> >> struct pdev_archdata.
> >
> > Isn't there some way to use "weak" symbols to keep us from having to
> > create this .h file in every single arch and then if the arch wants to
> > define it, it does so?
> >
> > That should make this patch simpler, right?
> >
> > thanks,
> >
> > greg k-h
>
> Changing to weak should be doable if we are ok with the additional
> function call always happening.
Given that this is not a fast path, and the function call for the
"normal" case would do nothing, it should be fine, right?
greg k-h
^ permalink raw reply
* Re: Analysing a kernel panic
From: Guillaume Dargaud @ 2011-07-07 15:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <201107051619.50548.dargaud@lpsc.in2p3.fr>
I'll expand a bit on my previous message. Here's a more detailed dump of what happens when my system receives a second
interrupt (the 1st one works fine) from my hardware:
[ 263.586996] do_IRQ: stack overflow: 1920
[ 263.590785] Call Trace:
[ 263.593275] [c7792780] [c00073ac] show_stack+0x80/0x19c (unreliable)
[ 263.599543] [c77927c0] [c0004d98] do_IRQ+0x48/0xcc
[ 263.604314] [c77927d0] [c000f434] ret_from_except+0x0/0x18
[ 263.609714] [c7792890] [00000000] (null)
[ 263.613628] [c77928a0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 263.619476] [c7792960] [00000000] (null)
[ 263.623410] [c7792970] [c0052554] handle_level_irq+0x54/0x128
[ 263.629090] [c7792980] [c0004dd8] do_IRQ+0x88/0xcc
[ 263.633852] [c7792990] [c000f434] ret_from_except+0x0/0x18
[ 263.639262] [c7792a50] [00000000] (null)
[ 263.643176] [c7792a60] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 263.649025] [c7792b20] [00000000] (null)
[ 263.652945] [c7792b30] [c0052554] handle_level_irq+0x54/0x128
[ 263.658638] [c7792b40] [c0004dd8] do_IRQ+0x88/0xcc
[ 263.663400] [c7792b50] [c000f434] ret_from_except+0x0/0x18
[ 263.668811] [c7792c10] [00000000] (null)
[ 263.672725] [c7792c20] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 263.678574] [c7792ce0] [00000000] (null)
[ 263.682494] [c7792cf0] [c0052554] handle_level_irq+0x54/0x128
[ 263.688189] [c7792d00] [c0004dd8] do_IRQ+0x88/0xcc
[ 263.692949] [c7792d10] [c000f434] ret_from_except+0x0/0x18
[ 263.698360] [c7792dd0] [00000000] (null)
[ 263.702274] [c7792de0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 263.708123] [c7792ea0] [00000000] (null)
[ 263.712043] [c7792eb0] [c0052554] handle_level_irq+0x54/0x128
[ 263.717736] [c7792ec0] [c0004dd8] do_IRQ+0x88/0xcc
[ 263.722498] [c7792ed0] [c000f434] ret_from_except+0x0/0x18
[ 263.727909] [c7792f90] [00000000] (null)
[ 263.731822] [c7792fa0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 263.737671] [c7793060] [00000000] (null)
[ 263.741592] [c7793070] [c0052554] handle_level_irq+0x54/0x128
[ 263.747285] [c7793080] [c0004dd8] do_IRQ+0x88/0xcc
[ 263.752048] [c7793090] [c000f434] ret_from_except+0x0/0x18
[ 263.757457] [c7793150] [00000000] (null)
[ 263.761372] [c7793160] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 263.767221] [c7793220] [00000000] (null)
[ 263.771143] [c7793230] [c0052554] handle_level_irq+0x54/0x128
[ 263.776834] [c7793240] [c0004dd8] do_IRQ+0x88/0xcc
[ 263.781597] [c7793250] [c000f434] ret_from_except+0x0/0x18
[ 263.787006] [c7793310] [00000000] (null)
[ 263.790921] [c7793320] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 263.796770] [c77933e0] [00000000] (null)
[ 263.800693] [c77933f0] [c0052554] handle_level_irq+0x54/0x128
[ 263.806383] [c7793400] [c0004dd8] do_IRQ+0x88/0xcc
[ 263.811146] [c7793410] [c000f434] ret_from_except+0x0/0x18
[ 263.816555] [c77934d0] [00000000] (null)
[ 263.820470] [c77934e0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 263.826319] [c77935a0] [00000000] (null)
[ 263.830241] [c77935b0] [c0052554] handle_level_irq+0x54/0x128
[ 263.835932] [c77935c0] [c0004dd8] do_IRQ+0x88/0xcc
[ 263.840694] [c77935d0] [c000f434] ret_from_except+0x0/0x18
[ 263.846104] [c7793690] [00000000] (null)
[ 263.850019] [c77936a0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 263.855867] [c7793760] [00000000] (null)
[ 263.859788] [c7793770] [c0052554] handle_level_irq+0x54/0x128
[ 263.865481] [c7793780] [c0004dd8] do_IRQ+0x88/0xcc
[ 263.870242] [c7793790] [c000f434] ret_from_except+0x0/0x18
[ 263.875653] [c7793850] [00000000] (null)
[ 263.879567] [c7793860] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 263.885416] [c7793920] [00000000] (null)
[ 263.889336] [c7793930] [c0052554] handle_level_irq+0x54/0x128
[ 263.895030] [c7793940] [c0004dd8] do_IRQ+0x88/0xcc
[ 263.899790] [c7793950] [c000f434] ret_from_except+0x0/0x18
[ 263.905201] [c7793a10] [00000000] (null)
[ 263.909115] [c7793a20] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 263.914971] do_IRQ: stack overflow: 1472
[ 263.918843] Call Trace:
[ 263.921304] [c77925c0] [c00073ac] show_stack+0x80/0x19c (unreliable)
[ 263.927600] [c7792600] [c0004d98] do_IRQ+0x48/0xcc
[ 263.932357] [c7792610] [c000f434] ret_from_except+0x0/0x18
[ 263.937791] [c77926d0] [3b9aca00] 0x3b9aca00
[ 263.942035] [c77926e0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 263.947899] [c77927a0] [3b9aca00] 0x3b9aca00
[ 263.952151] [c77927b0] [c0052554] handle_level_irq+0x54/0x128
[ 263.957842] [c77927c0] [c0004dd8] do_IRQ+0x88/0xcc
[ 263.962603] [c77927d0] [c000f434] ret_from_except+0x0/0x18
[ 263.968014] [c7792890] [00000000] (null)
[ 263.971928] [c77928a0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 263.977777] [c7792960] [00000000] (null)
[ 263.981697] [c7792970] [c0052554] handle_level_irq+0x54/0x128
[ 263.987390] [c7792980] [c0004dd8] do_IRQ+0x88/0xcc
[ 263.992152] [c7792990] [c000f434] ret_from_except+0x0/0x18
[ 263.997563] [c7792a50] [00000000] (null)
[ 264.001476] [c7792a60] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.007326] [c7792b20] [00000000] (null)
[ 264.011246] [c7792b30] [c0052554] handle_level_irq+0x54/0x128
[ 264.016939] [c7792b40] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.021701] [c7792b50] [c000f434] ret_from_except+0x0/0x18
[ 264.027111] [c7792c10] [00000000] (null)
[ 264.031025] [c7792c20] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.036875] [c7792ce0] [00000000] (null)
[ 264.040796] [c7792cf0] [c0052554] handle_level_irq+0x54/0x128
[ 264.046488] [c7792d00] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.051250] [c7792d10] [c000f434] ret_from_except+0x0/0x18
[ 264.056661] [c7792dd0] [00000000] (null)
[ 264.060574] [c7792de0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.066424] [c7792ea0] [00000000] (null)
[ 264.070344] [c7792eb0] [c0052554] handle_level_irq+0x54/0x128
[ 264.076037] [c7792ec0] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.080799] [c7792ed0] [c000f434] ret_from_except+0x0/0x18
[ 264.086209] [c7792f90] [00000000] (null)
[ 264.090123] [c7792fa0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.095972] [c7793060] [00000000] (null)
[ 264.099893] [c7793070] [c0052554] handle_level_irq+0x54/0x128
[ 264.105586] [c7793080] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.110347] [c7793090] [c000f434] ret_from_except+0x0/0x18
[ 264.115758] [c7793150] [00000000] (null)
[ 264.119672] [c7793160] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.125521] [c7793220] [00000000] (null)
[ 264.129441] [c7793230] [c0052554] handle_level_irq+0x54/0x128
[ 264.135134] [c7793240] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.139896] [c7793250] [c000f434] ret_from_except+0x0/0x18
[ 264.145307] [c7793310] [00000000] (null)
[ 264.149221] [c7793320] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.155070] [c77933e0] [00000000] (null)
[ 264.158990] [c77933f0] [c0052554] handle_level_irq+0x54/0x128
[ 264.164684] [c7793400] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.169446] [c7793410] [c000f434] ret_from_except+0x0/0x18
[ 264.174856] [c77934d0] [00000000] (null)
[ 264.178770] [c77934e0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.184619] [c77935a0] [00000000] (null)
[ 264.188540] [c77935b0] [c0052554] handle_level_irq+0x54/0x128
[ 264.194233] [c77935c0] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.198994] [c77935d0] [c000f434] ret_from_except+0x0/0x18
[ 264.204405] [c7793690] [00000000] (null)
[ 264.208320] [c77936a0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.214168] [c7793760] [00000000] (null)
[ 264.218088] [c7793770] [c0052554] handle_level_irq+0x54/0x128
[ 264.223782] [c7793780] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.228543] [c7793790] [c000f434] ret_from_except+0x0/0x18
[ 264.233953] [c7793850] [00000000] (null)
[ 264.237867] [c7793860] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.243723] do_IRQ: stack overflow: 1024
[ 264.247595] Call Trace:
[ 264.250053] [c7792400] [c00073ac] show_stack+0x80/0x19c (unreliable)
[ 264.256352] [c7792440] [c0004d98] do_IRQ+0x48/0xcc
[ 264.261109] [c7792450] [c000f434] ret_from_except+0x0/0x18
[ 264.266542] [c7792510] [3b9aca00] 0x3b9aca00
[ 264.270787] [c7792520] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.276651] [c77925e0] [3b9aca00] 0x3b9aca00
[ 264.280903] [c77925f0] [c0052554] handle_level_irq+0x54/0x128
[ 264.286595] [c7792600] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.291355] [c7792610] [c000f434] ret_from_except+0x0/0x18
[ 264.296782] [c77926d0] [3b9aca00] 0x3b9aca00
[ 264.301027] [c77926e0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.306891] [c77927a0] [3b9aca00] 0x3b9aca00
[ 264.311142] [c77927b0] [c0052554] handle_level_irq+0x54/0x128
[ 264.316835] [c77927c0] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.321595] [c77927d0] [c000f434] ret_from_except+0x0/0x18
[ 264.327006] [c7792890] [00000000] (null)
[ 264.330920] [c77928a0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.336769] [c7792960] [00000000] (null)
[ 264.340689] [c7792970] [c0052554] handle_level_irq+0x54/0x128
[ 264.346383] [c7792980] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.351144] [c7792990] [c000f434] ret_from_except+0x0/0x18
[ 264.356555] [c7792a50] [00000000] (null)
[ 264.360469] [c7792a60] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.366318] [c7792b20] [00000000] (null)
[ 264.370238] [c7792b30] [c0052554] handle_level_irq+0x54/0x128
[ 264.375932] [c7792b40] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.380693] [c7792b50] [c000f434] ret_from_except+0x0/0x18
[ 264.386104] [c7792c10] [00000000] (null)
[ 264.390018] [c7792c20] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.395867] [c7792ce0] [00000000] (null)
[ 264.399787] [c7792cf0] [c0052554] handle_level_irq+0x54/0x128
[ 264.405481] [c7792d00] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.410242] [c7792d10] [c000f434] ret_from_except+0x0/0x18
[ 264.415653] [c7792dd0] [00000000] (null)
[ 264.419566] [c7792de0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.425416] [c7792ea0] [00000000] (null)
[ 264.429336] [c7792eb0] [c0052554] handle_level_irq+0x54/0x128
[ 264.435030] [c7792ec0] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.439792] [c7792ed0] [c000f434] ret_from_except+0x0/0x18
[ 264.445201] [c7792f90] [00000000] (null)
[ 264.449116] [c7792fa0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.454964] [c7793060] [00000000] (null)
[ 264.458888] [c7793070] [c0052554] handle_level_irq+0x54/0x128
[ 264.464578] [c7793080] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.469341] [c7793090] [c000f434] ret_from_except+0x0/0x18
[ 264.474750] [c7793150] [00000000] (null)
[ 264.478665] [c7793160] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.484513] [c7793220] [00000000] (null)
[ 264.488436] [c7793230] [c0052554] handle_level_irq+0x54/0x128
[ 264.494126] [c7793240] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.498889] [c7793250] [c000f434] ret_from_except+0x0/0x18
[ 264.504299] [c7793310] [00000000] (null)
[ 264.508213] [c7793320] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.514062] [c77933e0] [00000000] (null)
[ 264.517985] [c77933f0] [c0052554] handle_level_irq+0x54/0x128
[ 264.523675] [c7793400] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.528438] [c7793410] [c000f434] ret_from_except+0x0/0x18
[ 264.533848] [c77934d0] [00000000] (null)
[ 264.537762] [c77934e0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.543611] [c77935a0] [00000000] (null)
[ 264.547532] [c77935b0] [c0052554] handle_level_irq+0x54/0x128
[ 264.553225] [c77935c0] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.557986] [c77935d0] [c000f434] ret_from_except+0x0/0x18
[ 264.563397] [c7793690] [00000000] (null)
[ 264.567312] [c77936a0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.573166] do_IRQ: stack overflow: 576
[ 264.576952] Call Trace:
[ 264.579413] [c7792240] [c00073ac] show_stack+0x80/0x19c (unreliable)
[ 264.585709] [c7792280] [c0004d98] do_IRQ+0x48/0xcc
[ 264.590466] [c7792290] [c000f434] ret_from_except+0x0/0x18
[ 264.595899] [c7792350] [3b9aca00] 0x3b9aca00
[ 264.600143] [c7792360] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.606008] [c7792420] [3b9aca00] 0x3b9aca00
[ 264.610260] [c7792430] [c0052554] handle_level_irq+0x54/0x128
[ 264.615951] [c7792440] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.620712] [c7792450] [c000f434] ret_from_except+0x0/0x18
[ 264.626139] [c7792510] [3b9aca00] 0x3b9aca00
[ 264.630384] [c7792520] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.636247] [c77925e0] [3b9aca00] 0x3b9aca00
[ 264.640499] [c77925f0] [c0052554] handle_level_irq+0x54/0x128
[ 264.646191] [c7792600] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.650952] [c7792610] [c000f434] ret_from_except+0x0/0x18
[ 264.656379] [c77926d0] [3b9aca00] 0x3b9aca00
[ 264.660624] [c77926e0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.666487] [c77927a0] [3b9aca00] 0x3b9aca00
[ 264.670738] [c77927b0] [c0052554] handle_level_irq+0x54/0x128
[ 264.676431] [c77927c0] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.681192] [c77927d0] [c000f434] ret_from_except+0x0/0x18
[ 264.686603] [c7792890] [00000000] (null)
[ 264.690517] [c77928a0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.696366] [c7792960] [00000000] (null)
[ 264.700286] [c7792970] [c0052554] handle_level_irq+0x54/0x128
[ 264.705980] [c7792980] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.710741] [c7792990] [c000f434] ret_from_except+0x0/0x18
[ 264.716152] [c7792a50] [00000000] (null)
[ 264.720065] [c7792a60] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.725915] [c7792b20] [00000000] (null)
[ 264.729835] [c7792b30] [c0052554] handle_level_irq+0x54/0x128
[ 264.735528] [c7792b40] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.740290] [c7792b50] [c000f434] ret_from_except+0x0/0x18
[ 264.745700] [c7792c10] [00000000] (null)
[ 264.749614] [c7792c20] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.755464] [c7792ce0] [00000000] (null)
[ 264.759384] [c7792cf0] [c0052554] handle_level_irq+0x54/0x128
[ 264.765077] [c7792d00] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.769838] [c7792d10] [c000f434] ret_from_except+0x0/0x18
[ 264.775249] [c7792dd0] [00000000] (null)
[ 264.779163] [c7792de0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.785013] [c7792ea0] [00000000] (null)
[ 264.788933] [c7792eb0] [c0052554] handle_level_irq+0x54/0x128
[ 264.794626] [c7792ec0] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.799387] [c7792ed0] [c000f434] ret_from_except+0x0/0x18
[ 264.804798] [c7792f90] [00000000] (null)
[ 264.808712] [c7792fa0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.814561] [c7793060] [00000000] (null)
[ 264.818481] [c7793070] [c0052554] handle_level_irq+0x54/0x128
[ 264.824174] [c7793080] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.828936] [c7793090] [c000f434] ret_from_except+0x0/0x18
[ 264.834347] [c7793150] [00000000] (null)
[ 264.838261] [c7793160] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.844110] [c7793220] [00000000] (null)
[ 264.848030] [c7793230] [c0052554] handle_level_irq+0x54/0x128
[ 264.853723] [c7793240] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.858485] [c7793250] [c000f434] ret_from_except+0x0/0x18
[ 264.863895] [c7793310] [00000000] (null)
[ 264.867809] [c7793320] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.873659] [c77933e0] [00000000] (null)
[ 264.877579] [c77933f0] [c0052554] handle_level_irq+0x54/0x128
[ 264.883272] [c7793400] [c0004dd8] do_IRQ+0x88/0xcc
[ 264.888034] [c7793410] [c000f434] ret_from_except+0x0/0x18
[ 264.893445] [c77934d0] [00000000] (null)
[ 264.897359] [c77934e0] [c000f3e8] ret_from_except_full+0x0/0x4c
[ 264.903213] do_IRQ: stack overflow: 128
[ 264.907000] Call Trace:
[ 264.909444] Kernel stack overflow in process c6cea0a0, r1=c77920a0
[ 264.915569] NIP: c0003e84 LR: c0018114 CTR: c00180f8
[ 264.920498] REGS: c7791ff0 TRAP: 0700 Not tainted (2.6.34)
[ 264.926185] MSR: 00021030 <ME,CE,IR,DR> CR: 44000088 XER: 00000000
[ 264.932505] TASK = c6cea0a0[241] 'SoftNoy' THREAD: c7792000
[ 264.937850] GPR00: c0052554 c77920a0 c6cea0a0 00000015 c05a7ad4 ffffffff c0154414 00000000
[ 264.946142] GPR08: c05c60e0 c05a51bc c05c6584 ffffffff 06cea2a8 100265c8 00000000 1007c600
[ 264.954436] GPR16: 100acd0c c7793daf 0000000f c7793daf 00000036 c0242f89 000003e8 c7793d98
[ 264.962731] GPR24: 00000001 3b9aca00 00000000 00029030 c7793da0 c05a5780 00000015 c05a7ad4
[ 264.971230] NIP [c0003e84] virq_to_hw+0x0/0x14
[ 264.975653] LR [c0018114] xilinx_intc_mask+0x1c/0x54
[ 264.980528] Call Trace:
[ 264.982947] Instruction dump:
[ 264.985889] 0000057f 0000078f 0000058f 0000079f 0000059f 000007af 000005af 000007bf
[ 264.993576] 000005bf 000007cf 000005cf 000007df <000005df> 000007ef 000005ef 000007ff
[ 265.001447] Kernel panic - not syncing: kernel stack overflow
[ 265.007137] Call Trace:
[ 265.009580] Rebooting in 180 seconds..
I have a hard time understanding the cause of the problem. It may very well be the hardware as my code works fine on a
different but very similar piece of hardware.
Does the above mean that Linux is crashing in the do_IRQ routine, before even entering my own interrupt function ?
The electronics guys assure me that only ONE interrupt signal is sent to the processor...
Any lead ?
On Tuesday 05 July 2011 16:19:50 Guillaume Dargaud wrote:
> Hello all,
> one of my drivers is causing a kernel panic and I _think_ it happens in the
> 1st call to the interrupt routine. What kind of information can I extract
> from the following ?
> Is it like a core dump that I can load with the executable in the debugger
> to know exactly what happened (I doubt it) ?
>
> Oops: Exception in kernel mode, sig: 4 [#1]
> Xilinx Virtex
> last sysfs file:
> Modules linked in: xad
> NIP: c0002328 LR: c0011de8 CTR: c001d77c
> REGS: c778de20 TRAP: 0700 Not tainted (2.6.34)
> MSR: 00021030 <ME,CE,IR,DR> CR: 24000044 XER: 00000000
> TASK = c6ce80a0[241] 'SoftNoy' THREAD: c778c000
> GPR00: 00000000 c778ded0 c6ce80a0 00000026 c6dbe000 00000000 e146dcab
> 00000000 GPR08: 02134be0 00000000 000020e7 00000001 000020e6 100265d8
> 00000000 1007c600 GPR16: 100acd0c 100822e4 1009024d bfa39a48 c7452080
> c05bf0e8 c05bf02c c0207d6c GPR24: c778c03c 00000004 c6cc7040 c05c1b88
> 00000001 00000004 c6cc73c0 00000026 NIP [c0002328] set_context+0x0/0x10
> LR [c0011de8] switch_mmu_context+0x194/0x1b8
> Call Trace:
> [c778ded0] [c001a810] pick_next_task_fair+0xec/0x130 (unreliable)
> [c778def0] [c0203514] schedule+0x300/0x394
> [c778df40] [c000f63c] recheck+0x0/0x24
> Instruction dump:
> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000 <00000000> 00000000 00000000 00000000
> Kernel stack overflow in process c6ce80a0, r1=c778c070
> NIP: c000d270 LR: c000f3c8 CTR: c0017fd0
> REGS: c778bfc0 TRAP: 0501 Tainted: G D (2.6.34)
> MSR: 00029030 <EE,ME,CE,IR,DR> CR: 24000048 XER: 00000000
> TASK = c6ce80a0[241] 'SoftNoy' THREAD: c778c000
> GPR00: 00029030 c778c070 c6ce80a0 c778c090 08000000 ffff32d8 00000001
> 00000001 GPR08: ffff32da 00000000 00021032 c000d110 06ce82a8
> NIP [c000d270] program_check_exception+0x160/0x228
> LR [c000f3c8] ret_from_except_full+0x0/0x4c
> Call Trace:
> Instruction dump:
> 38090004 901f0080 480000d8 3ca00003 7fe4fb78 80df0080 60a50001 38600005
> 480000a8 7c0000a6 60008000 7c000124 <77c00c04> 41a20068 4bffef89 2f83fff2
> Kernel panic - not syncing: kernel stack overflow
> Call Trace:
> Rebooting in 180 seconds..
>
> My driver is xad.ko, though /dev/xps-acqui-data. The user program is
> SoftNoy. The code for the ISR (note that this code works fine on the same
> driver for a slightly different piece of custom hardware):
>
> static irqreturn_t XadIsr(int irq, void *dev_id) {
> Xad.control_reg->fin_in = 0;
> Xad.interrupt_reg->ISR = 1;
> Xad.interrupt_IPIF_reg->ISR = 4;
>
> Xad.control_reg->flux_address[0] = BUFFER_PHY_BASE + BUF_SZ*(++Xad.Icnt %
> BUF_NB); Xad.control_reg->flux_address[1] =
> Xad.control_reg->flux_address[0] + BUF_SZ/2;
>
> if (Xad.Icnt<Xad.Rcnt+BUF_NB)
> Xad.control_reg->flux_start=255; // Arm the next interrupt
> else {
> // There aren't any buffers available for the next read. We'll do the
> start in the read routine Xad.Suspended=1;
> Xad.OverflowsSinceLastRead++;
> Xad.Overflow++;
> DBG_ADD_CHAR('*');
> if (Verbose) printk(KERN_WARNING SD "%dth buffer overflow:
> %d-%d=%d>=%d\n" FL, Xad.Overflow, Xad.Icnt, Xad.Rcnt, Xad.Icnt-Xad.Rcnt,
> BUF_NB);
> }
>
> wake_up_interruptible(&Xad.wait);
> return IRQ_HANDLED;
> }
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* Re: [PATCH] powerpc/p1022ds: Remove fixed-link property from ethernet nodes.
From: Timur Tabi @ 2011-07-07 16:05 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev
In-Reply-To: <1310024270-2675-1-git-send-email-felix@embedded-sol.com>
Felix Radensky wrote:
> On P1022DS both ethernet controllers are connected to RGMII PHYs
> accessible via MDIO bus. Remove fixed-link property from ethernet
> nodes as they only required when fixed link PHYs without MDIO bus
> are used.
>
> Signed-off-by: Felix Radensky <felix@embedded-sol.com>
Acked-by: Timur Tabi <timur@freescale.com>
Ethernet works before and after applying this patch, so all I can say is that it
doesn't break anything.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH] powerpc,ppc4xx_edac: Add comma to fix build error
From: Mike Williams @ 2011-07-07 16:09 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mike Williams
Commit 4018294b53d1dae026880e45f174c1cc63b5d435 broke the ppc4xx_edac driver at
line 210 where the struct member is missing a comma.
Signed-off-by: Mike Williams <mike@mikebwilliams.com>
---
drivers/edac/ppc4xx_edac.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/edac/ppc4xx_edac.c b/drivers/edac/ppc4xx_edac.c
index b9f0c20..446b5c0 100644
--- a/drivers/edac/ppc4xx_edac.c
+++ b/drivers/edac/ppc4xx_edac.c
@@ -206,7 +206,7 @@ static struct of_platform_driver ppc4xx_edac_driver = {
.remove = ppc4xx_edac_remove,
.driver = {
.owner = THIS_MODULE,
- .name = PPC4XX_EDAC_MODULE_NAME
+ .name = PPC4XX_EDAC_MODULE_NAME,
.of_match_table = ppc4xx_edac_match,
},
};
--
1.7.3.4
^ permalink raw reply related
* [PATCH] drivers/video: use strings to specify the Freescale DIU monitor port
From: Timur Tabi @ 2011-07-07 16:51 UTC (permalink / raw)
To: kumar.gala, lethal, linuxppc-dev, linux-fbdev
Instead of using ill-defined numbers (0, 1, and 2) for the monitor port, allow
the user to specify the port by name ("dvi", "lvds", or "dlvds"). This works
on the kernel command line, the module command-line, and the sysfs "monitor"
device.
Note that changing the monitor port does not currently work on the P1022DS,
because the code that talks to the PIXIS FPGA is broken.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/platforms/512x/mpc512x_shared.c | 22 +++-----
arch/powerpc/platforms/85xx/p1022_ds.c | 47 ++++++++---------
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 55 +++++++++-----------
arch/powerpc/sysdev/fsl_soc.h | 25 ++++++---
drivers/video/fsl-diu-fb.c | 73 +++++++++++++++++++------
5 files changed, 128 insertions(+), 94 deletions(-)
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/platforms/512x/mpc512x_shared.c
index e41ebbd..3dc62f9 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -66,8 +66,8 @@ struct fsl_diu_shared_fb {
bool in_use;
};
-unsigned int mpc512x_get_pixel_format(unsigned int bits_per_pixel,
- int monitor_port)
+u32 mpc512x_get_pixel_format(enum fsl_diu_monitor_port port,
+ unsigned int bits_per_pixel)
{
switch (bits_per_pixel) {
case 32:
@@ -80,11 +80,12 @@ unsigned int mpc512x_get_pixel_format(unsigned int bits_per_pixel,
return 0x00000400;
}
-void mpc512x_set_gamma_table(int monitor_port, char *gamma_table_base)
+void mpc512x_set_gamma_table(enum fsl_diu_monitor_port port,
+ char *gamma_table_base)
{
}
-void mpc512x_set_monitor_port(int monitor_port)
+void mpc512x_set_monitor_port(enum fsl_diu_monitor_port port)
{
}
@@ -182,14 +183,10 @@ void mpc512x_set_pixel_clock(unsigned int pixclock)
iounmap(ccm);
}
-ssize_t mpc512x_show_monitor_port(int monitor_port, char *buf)
+enum fsl_diu_monitor_port
+mpc512x_valid_monitor_port(enum fsl_diu_monitor_port port)
{
- return sprintf(buf, "0 - 5121 LCD\n");
-}
-
-int mpc512x_set_sysfs_monitor_port(int val)
-{
- return 0;
+ return FSL_DIU_PORT_DVI;
}
static struct fsl_diu_shared_fb __attribute__ ((__aligned__(8))) diu_shared_fb;
@@ -332,8 +329,7 @@ void __init mpc512x_setup_diu(void)
diu_ops.set_gamma_table = mpc512x_set_gamma_table;
diu_ops.set_monitor_port = mpc512x_set_monitor_port;
diu_ops.set_pixel_clock = mpc512x_set_pixel_clock;
- diu_ops.show_monitor_port = mpc512x_show_monitor_port;
- diu_ops.set_sysfs_monitor_port = mpc512x_set_sysfs_monitor_port;
+ diu_ops.valid_monitor_port = mpc512x_valid_monitor_port;
diu_ops.release_bootmem = mpc512x_release_bootmem;
#endif
}
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index 266b3aa..c01c727 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -93,8 +93,8 @@
* The Area Descriptor is a 32-bit value that determine which bits in each
* pixel are to be used for each color.
*/
-static unsigned int p1022ds_get_pixel_format(unsigned int bits_per_pixel,
- int monitor_port)
+static u32 p1022ds_get_pixel_format(enum fsl_diu_monitor_port port,
+ unsigned int bits_per_pixel)
{
switch (bits_per_pixel) {
case 32:
@@ -118,7 +118,8 @@ static unsigned int p1022ds_get_pixel_format(unsigned int bits_per_pixel,
* On some boards, the gamma table for some ports may need to be modified.
* This is not the case on the P1022DS, so we do nothing.
*/
-static void p1022ds_set_gamma_table(int monitor_port, char *gamma_table_base)
+static void p1022ds_set_gamma_table(enum fsl_diu_monitor_port port,
+ char *gamma_table_base)
{
}
@@ -126,7 +127,7 @@ static void p1022ds_set_gamma_table(int monitor_port, char *gamma_table_base)
* p1022ds_set_monitor_port: switch the output to a different monitor port
*
*/
-static void p1022ds_set_monitor_port(int monitor_port)
+static void p1022ds_set_monitor_port(enum fsl_diu_monitor_port port)
{
struct device_node *pixis_node;
void __iomem *pixis;
@@ -145,19 +146,21 @@ static void p1022ds_set_monitor_port(int monitor_port)
}
brdcfg1 = pixis + 9; /* BRDCFG1 is at offset 9 in the ngPIXIS */
- switch (monitor_port) {
- case 0: /* DVI */
+ switch (port) {
+ case FSL_DIU_PORT_DVI:
+ printk(KERN_INFO "%s:%u\n", __func__, __LINE__);
/* Enable the DVI port, disable the DFP and the backlight */
clrsetbits_8(brdcfg1, PX_BRDCFG1_DFPEN | PX_BRDCFG1_BACKLIGHT,
PX_BRDCFG1_DVIEN);
break;
- case 1: /* Single link LVDS */
+ case FSL_DIU_PORT_LVDS:
+ printk(KERN_INFO "%s:%u\n", __func__, __LINE__);
/* Enable the DFP port, disable the DVI and the backlight */
clrsetbits_8(brdcfg1, PX_BRDCFG1_DVIEN | PX_BRDCFG1_BACKLIGHT,
PX_BRDCFG1_DFPEN);
break;
default:
- pr_err("p1022ds: unsupported monitor port %i\n", monitor_port);
+ pr_err("p1022ds: unsupported monitor port %i\n", port);
}
iounmap(pixis);
@@ -214,23 +217,18 @@ void p1022ds_set_pixel_clock(unsigned int pixclock)
}
/**
- * p1022ds_show_monitor_port: show the current monitor
- *
- * This function returns a string indicating whether the current monitor is
- * set to DVI or LVDS.
- */
-ssize_t p1022ds_show_monitor_port(int monitor_port, char *buf)
-{
- return sprintf(buf, "%c0 - DVI\n%c1 - Single link LVDS\n",
- monitor_port == 0 ? '*' : ' ', monitor_port == 1 ? '*' : ' ');
-}
-
-/**
- * p1022ds_set_sysfs_monitor_port: set the monitor port for sysfs
+ * p1022ds_valid_monitor_port: set the monitor port for sysfs
*/
-int p1022ds_set_sysfs_monitor_port(int val)
+enum fsl_diu_monitor_port
+p1022ds_valid_monitor_port(enum fsl_diu_monitor_port port)
{
- return val < 2 ? val : 0;
+ switch (port) {
+ case FSL_DIU_PORT_DVI:
+ case FSL_DIU_PORT_LVDS:
+ return port;
+ default:
+ return FSL_DIU_PORT_DVI; /* Dual-link LVDS is not supported */
+ }
}
#endif
@@ -305,8 +303,7 @@ static void __init p1022_ds_setup_arch(void)
diu_ops.set_gamma_table = p1022ds_set_gamma_table;
diu_ops.set_monitor_port = p1022ds_set_monitor_port;
diu_ops.set_pixel_clock = p1022ds_set_pixel_clock;
- diu_ops.show_monitor_port = p1022ds_show_monitor_port;
- diu_ops.set_sysfs_monitor_port = p1022ds_set_sysfs_monitor_port;
+ diu_ops.valid_monitor_port = p1022ds_valid_monitor_port;
#endif
#ifdef CONFIG_SMP
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 74e018e..13fa9a6 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -152,10 +152,10 @@ machine_device_initcall(mpc86xx_hpcd, mpc8610_declare_of_platform_devices);
(c2 << AD_COMP_2_SHIFT) | (c1 << AD_COMP_1_SHIFT) | \
(c0 << AD_COMP_0_SHIFT) | (size << AD_PIXEL_S_SHIFT))
-unsigned int mpc8610hpcd_get_pixel_format(unsigned int bits_per_pixel,
- int monitor_port)
+u32 mpc8610hpcd_get_pixel_format(enum fsl_diu_monitor_port port,
+ unsigned int bits_per_pixel)
{
- static const unsigned long pixelformat[][3] = {
+ static const u32 pixelformat[][3] = {
{
MAKE_AD(3, 0, 2, 1, 3, 8, 8, 8, 8),
MAKE_AD(4, 2, 0, 1, 2, 8, 8, 8, 0),
@@ -170,7 +170,8 @@ unsigned int mpc8610hpcd_get_pixel_format(unsigned int bits_per_pixel,
unsigned int arch_monitor;
/* The DVI port is mis-wired on revision 1 of this board. */
- arch_monitor = ((*pixis_arch == 0x01) && (monitor_port == 0))? 0 : 1;
+ arch_monitor =
+ ((*pixis_arch == 0x01) && (port == FSL_DIU_PORT_DVI)) ? 0 : 1;
switch (bits_per_pixel) {
case 32:
@@ -185,10 +186,11 @@ unsigned int mpc8610hpcd_get_pixel_format(unsigned int bits_per_pixel,
}
}
-void mpc8610hpcd_set_gamma_table(int monitor_port, char *gamma_table_base)
+void mpc8610hpcd_set_gamma_table(enum fsl_diu_monitor_port port,
+ char *gamma_table_base)
{
int i;
- if (monitor_port == 2) { /* dual link LVDS */
+ if (port == FSL_DIU_PORT_DLVDS) {
for (i = 0; i < 256*3; i++)
gamma_table_base[i] = (gamma_table_base[i] << 2) |
((gamma_table_base[i] >> 6) & 0x03);
@@ -199,17 +201,21 @@ void mpc8610hpcd_set_gamma_table(int monitor_port, char *gamma_table_base)
#define PX_BRDCFG0_DLINK (1 << 4)
#define PX_BRDCFG0_DIU_MASK (PX_BRDCFG0_DVISEL | PX_BRDCFG0_DLINK)
-void mpc8610hpcd_set_monitor_port(int monitor_port)
+void mpc8610hpcd_set_monitor_port(enum fsl_diu_monitor_port port)
{
- static const u8 bdcfg[] = {
- PX_BRDCFG0_DVISEL | PX_BRDCFG0_DLINK,
- PX_BRDCFG0_DLINK,
- 0,
- };
-
- if (monitor_port < 3)
+ switch (port) {
+ case FSL_DIU_PORT_DVI:
clrsetbits_8(pixis_bdcfg0, PX_BRDCFG0_DIU_MASK,
- bdcfg[monitor_port]);
+ PX_BRDCFG0_DVISEL | PX_BRDCFG0_DLINK);
+ break;
+ case FSL_DIU_PORT_LVDS:
+ clrsetbits_8(pixis_bdcfg0, PX_BRDCFG0_DIU_MASK,
+ PX_BRDCFG0_DLINK);
+ break;
+ case FSL_DIU_PORT_DLVDS:
+ clrbits8(pixis_bdcfg0, PX_BRDCFG0_DIU_MASK);
+ break;
+ }
}
/**
@@ -262,20 +268,10 @@ void mpc8610hpcd_set_pixel_clock(unsigned int pixclock)
iounmap(guts);
}
-ssize_t mpc8610hpcd_show_monitor_port(int monitor_port, char *buf)
-{
- return snprintf(buf, PAGE_SIZE,
- "%c0 - DVI\n"
- "%c1 - Single link LVDS\n"
- "%c2 - Dual link LVDS\n",
- monitor_port == 0 ? '*' : ' ',
- monitor_port == 1 ? '*' : ' ',
- monitor_port == 2 ? '*' : ' ');
-}
-
-int mpc8610hpcd_set_sysfs_monitor_port(int val)
+enum fsl_diu_monitor_port
+mpc8610hpcd_valid_monitor_port(enum fsl_diu_monitor_port port)
{
- return val < 3 ? val : 0;
+ return port;
}
#endif
@@ -307,8 +303,7 @@ static void __init mpc86xx_hpcd_setup_arch(void)
diu_ops.set_gamma_table = mpc8610hpcd_set_gamma_table;
diu_ops.set_monitor_port = mpc8610hpcd_set_monitor_port;
diu_ops.set_pixel_clock = mpc8610hpcd_set_pixel_clock;
- diu_ops.show_monitor_port = mpc8610hpcd_show_monitor_port;
- diu_ops.set_sysfs_monitor_port = mpc8610hpcd_set_sysfs_monitor_port;
+ diu_ops.valid_monitor_port = mpc8610hpcd_valid_monitor_port;
#endif
pixis_node = of_find_compatible_node(NULL, NULL, "fsl,fpga-pixis");
diff --git a/arch/powerpc/sysdev/fsl_soc.h b/arch/powerpc/sysdev/fsl_soc.h
index 5360948..064bc70 100644
--- a/arch/powerpc/sysdev/fsl_soc.h
+++ b/arch/powerpc/sysdev/fsl_soc.h
@@ -22,15 +22,24 @@ struct device_node;
extern void fsl_rstcr_restart(char *cmd);
#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
+
+/* The different ports that the DIU can be connected to */
+enum fsl_diu_monitor_port {
+ FSL_DIU_PORT_DVI, /* DVI */
+ FSL_DIU_PORT_LVDS, /* Single-link LVDS */
+ FSL_DIU_PORT_DLVDS /* Dual-link LVDS */
+};
+
struct platform_diu_data_ops {
- unsigned int (*get_pixel_format) (unsigned int bits_per_pixel,
- int monitor_port);
- void (*set_gamma_table) (int monitor_port, char *gamma_table_base);
- void (*set_monitor_port) (int monitor_port);
- void (*set_pixel_clock) (unsigned int pixclock);
- ssize_t (*show_monitor_port) (int monitor_port, char *buf);
- int (*set_sysfs_monitor_port) (int val);
- void (*release_bootmem) (void);
+ u32 (*get_pixel_format)(enum fsl_diu_monitor_port port,
+ unsigned int bpp);
+ void (*set_gamma_table)(enum fsl_diu_monitor_port port,
+ char *gamma_table_base);
+ void (*set_monitor_port)(enum fsl_diu_monitor_port port);
+ void (*set_pixel_clock)(unsigned int pixclock);
+ enum fsl_diu_monitor_port (*valid_monitor_port)
+ (enum fsl_diu_monitor_port port);
+ void (*release_bootmem)(void);
};
extern struct platform_diu_data_ops diu_ops;
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index 0acc7d6..9c6837e 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -31,8 +31,6 @@
#include <linux/uaccess.h>
#include <linux/vmalloc.h>
-#include <linux/of_platform.h>
-
#include <sysdev/fsl_soc.h>
#include <linux/fsl-diu-fb.h>
#include "edid.h"
@@ -183,7 +181,8 @@ static struct fb_videomode __devinitdata fsl_diu_mode_db[] = {
static char *fb_mode = "1024x768-32@60";
static unsigned long default_bpp = 32;
-static int monitor_port;
+static enum fsl_diu_monitor_port monitor_port;
+static char *monitor_string;
#if defined(CONFIG_NOT_COHERENT_CACHE)
static u8 *coherence_data;
@@ -201,7 +200,7 @@ struct fsl_diu_data {
void *dummy_aoi_virt;
unsigned int irq;
int fb_enabled;
- int monitor_port;
+ enum fsl_diu_monitor_port monitor_port;
};
struct mfb_info {
@@ -282,6 +281,37 @@ static struct diu_hw dr = {
static struct diu_pool pool;
/**
+ * fsl_diu_name_to_port - convert a port name to a monitor port enum
+ *
+ * Takes the name of a monitor port ("dvi", "lvds", or "dlvds") and returns
+ * the enum fsl_diu_monitor_port that corresponds to that string.
+ *
+ * For compatibility with older versions, a number ("0", "1", or "2") is also
+ * supported.
+ *
+ * If the string is unknown, DVI is assumed.
+ *
+ * If the particular port is not supported by the platform, another port
+ * (platform-specific) is chosen instead.
+ */
+static enum fsl_diu_monitor_port fsl_diu_name_to_port(const char *s)
+{
+ enum fsl_diu_monitor_port port = FSL_DIU_PORT_DVI;
+ unsigned long val;
+
+ if (s) {
+ if (!strict_strtoul(s, 10, &val) && (val <= 2))
+ port = (enum fsl_diu_monitor_port) val;
+ else if (strncmp(s, "lvds", 4) == 0)
+ port = FSL_DIU_PORT_LVDS;
+ else if (strncmp(s, "dlvds", 5) == 0)
+ port = FSL_DIU_PORT_DLVDS;
+ }
+
+ return diu_ops.valid_monitor_port(port);
+}
+
+/**
* fsl_diu_alloc - allocate memory for the DIU
* @size: number of bytes to allocate
* @param: returned physical address of memory
@@ -832,8 +862,8 @@ static int fsl_diu_set_par(struct fb_info *info)
}
ad->pix_fmt =
- diu_ops.get_pixel_format(var->bits_per_pixel,
- machine_data->monitor_port);
+ cpu_to_be32(diu_ops.get_pixel_format(machine_data->monitor_port,
+ var->bits_per_pixel));
ad->addr = cpu_to_le32(info->fix.smem_start);
ad->src_size_g_alpha = cpu_to_le32((var->yres_virtual << 12) |
var->xres_virtual) | mfbi->g_alpha;
@@ -1439,16 +1469,12 @@ static void free_buf(struct device *dev, struct diu_addr *buf, u32 size,
static ssize_t store_monitor(struct device *device,
struct device_attribute *attr, const char *buf, size_t count)
{
- int old_monitor_port;
- unsigned long val;
+ enum fsl_diu_monitor_port old_monitor_port;
struct fsl_diu_data *machine_data =
container_of(attr, struct fsl_diu_data, dev_attr);
- if (strict_strtoul(buf, 10, &val))
- return 0;
-
old_monitor_port = machine_data->monitor_port;
- machine_data->monitor_port = diu_ops.set_sysfs_monitor_port(val);
+ machine_data->monitor_port = fsl_diu_name_to_port(buf);
if (old_monitor_port != machine_data->monitor_port) {
/* All AOIs need adjust pixel format
@@ -1468,7 +1494,17 @@ static ssize_t show_monitor(struct device *device,
{
struct fsl_diu_data *machine_data =
container_of(attr, struct fsl_diu_data, dev_attr);
- return diu_ops.show_monitor_port(machine_data->monitor_port, buf);
+
+ switch (machine_data->monitor_port) {
+ case FSL_DIU_PORT_DVI:
+ return sprintf(buf, "DVI\n");
+ case FSL_DIU_PORT_LVDS:
+ return sprintf(buf, "Single-link LVDS\n");
+ case FSL_DIU_PORT_DLVDS:
+ return sprintf(buf, "Dual-link LVDS\n");
+ }
+
+ return 0;
}
static int __devinit fsl_diu_probe(struct platform_device *ofdev)
@@ -1692,8 +1728,7 @@ static int __init fsl_diu_setup(char *options)
if (!*opt)
continue;
if (!strncmp(opt, "monitor=", 8)) {
- if (!strict_strtoul(opt + 8, 10, &val) && (val <= 2))
- monitor_port = val;
+ monitor_port = fsl_diu_name_to_port(opt + 8);
} else if (!strncmp(opt, "bpp=", 4)) {
if (!strict_strtoul(opt + 4, 10, &val))
default_bpp = val;
@@ -1746,6 +1781,8 @@ static int __init fsl_diu_init(void)
if (fb_get_options("fslfb", &option))
return -ENODEV;
fsl_diu_setup(option);
+#else
+ monitor_port = fsl_diu_name_to_port(monitor_string);
#endif
printk(KERN_INFO "Freescale DIU driver\n");
@@ -1812,7 +1849,7 @@ MODULE_PARM_DESC(mode,
"Specify resolution as \"<xres>x<yres>[-<bpp>][@<refresh>]\" ");
module_param_named(bpp, default_bpp, ulong, 0);
MODULE_PARM_DESC(bpp, "Specify bit-per-pixel if not specified mode");
-module_param_named(monitor, monitor_port, int, 0);
-MODULE_PARM_DESC(monitor,
- "Specify the monitor port (0, 1 or 2) if supported by the platform");
+module_param_named(monitor, monitor_string, charp, 0);
+MODULE_PARM_DESC(monitor, "Specify the monitor port "
+ "(\"dvi\", \"lvds\", or \"dlvds\") if supported by the platform");
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] powerpc/5200: dts: digsy_mtc.dts: enable both MSCAN nodes
From: Grant Likely @ 2011-07-07 18:42 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <1310042990-21666-1-git-send-email-agust@denx.de>
On Thu, Jul 07, 2011 at 02:49:50PM +0200, Anatolij Gustschin wrote:
> We use both MSCAN controllers on this board, so do not disable
> them in the device tree.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
Applied, thanks.
g.
> ---
> arch/powerpc/boot/dts/digsy_mtc.dts | 8 --------
> 1 files changed, 0 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/digsy_mtc.dts b/arch/powerpc/boot/dts/digsy_mtc.dts
> index 2aad7ae..a7511f2 100644
> --- a/arch/powerpc/boot/dts/digsy_mtc.dts
> +++ b/arch/powerpc/boot/dts/digsy_mtc.dts
> @@ -37,14 +37,6 @@
> status = "disabled";
> };
>
> - can@900 {
> - status = "disabled";
> - };
> -
> - can@980 {
> - status = "disabled";
> - };
> -
> spi@f00 {
> msp430@0 {
> compatible = "spidev";
> --
> 1.7.1
>
^ permalink raw reply
* Re: [PATCH] powerpc: enable access to HT Host-Bridge on Maple
From: Benjamin Herrenschmidt @ 2011-07-07 22:48 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Dmitry Eremin-Solenikov, linuxppc-dev
In-Reply-To: <F4E7EABC-B63F-4776-A8EB-8C93F64C2A3C@kernel.crashing.org>
On Fri, 2011-07-01 at 18:44 +0200, Segher Boessenkool wrote:
> > CPC925/CPC945 use special window to access host bridge
> > functionality of
> > u3-ht. Provide a way to access this device.
>
> Why? Is anything going to use it?
>
> > +static int u3_ht_root_read_config(struct pci_controller *hose, u8
> > offset,
> > + int len, u32 *val)
> > +{
> > + volatile void __iomem *addr;
> > +
> > + addr = hose->cfg_addr;
> > + addr += ((offset & ~3) << 2) + (4 - len - (offset & 3));
>
> This will only work for len 1,2,4 with offset a multiple of len, is that
> guaranteed here?
I think the upper layer does. Dbl check tho.
> > hose->cfg_data = ioremap(0xf2000000, 0x02000000);
> > + hose->cfg_addr = ioremap(0xf8070000, 0x1000);
>
> Eww. You could just make a global instead of abusing existing fields,
> there can be only one CPC9x5 in a system anyway.
Nah, that's fine, we abuse it that way regulary :-)
Cheers,
Ben.
^ permalink raw reply
* Re: Analysing a kernel panic
From: Benjamin Herrenschmidt @ 2011-07-07 22:58 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <201107051619.50548.dargaud@lpsc.in2p3.fr>
On Tue, 2011-07-05 at 16:19 +0200, Guillaume Dargaud wrote:
> Hello all,
> one of my drivers is causing a kernel panic and I _think_ it happens in the 1st call to the interrupt routine.
> What kind of information can I extract from the following ?
> Is it like a core dump that I can load with the executable in the debugger to know exactly what happened (I doubt it) ?
> Kernel stack overflow in process c6ce80a0, r1=c778c070
That's bad...
> NIP: c000d270 LR: c000f3c8 CTR: c0017fd0
> REGS: c778bfc0 TRAP: 0501 Tainted: G D (2.6.34)
> MSR: 00029030 <EE,ME,CE,IR,DR> CR: 24000048 XER: 00000000
> TASK = c6ce80a0[241] 'SoftNoy' THREAD: c778c000
> GPR00: 00029030 c778c070 c6ce80a0 c778c090 08000000 ffff32d8 00000001 00000001
> GPR08: ffff32da 00000000 00021032 c000d110 06ce82a8
> NIP [c000d270] program_check_exception+0x160/0x228
> LR [c000f3c8] ret_from_except_full+0x0/0x4c
> Call Trace:
> Instruction dump:
> 38090004 901f0080 480000d8 3ca00003 7fe4fb78 80df0080 60a50001 38600005
> 480000a8 7c0000a6 60008000 7c000124 <77c00c04> 41a20068 4bffef89 2f83fff2
> Kernel panic - not syncing: kernel stack overflow
> Call Trace:
> Rebooting in 180 seconds..
>
> My driver is xad.ko, though /dev/xps-acqui-data. The user program is SoftNoy.
> The code for the ISR (note that this code works fine on the same driver for a slightly different piece of custom
> hardware):
>
> static irqreturn_t XadIsr(int irq, void *dev_id) {
> Xad.control_reg->fin_in = 0;
> Xad.interrupt_reg->ISR = 1;
> Xad.interrupt_IPIF_reg->ISR = 4;
>
> Xad.control_reg->flux_address[0] = BUFFER_PHY_BASE + BUF_SZ*(++Xad.Icnt % BUF_NB);
> Xad.control_reg->flux_address[1] = Xad.control_reg->flux_address[0] + BUF_SZ/2;
>
> if (Xad.Icnt<Xad.Rcnt+BUF_NB)
> Xad.control_reg->flux_start=255; // Arm the next interrupt
> else {
> // There aren't any buffers available for the next read. We'll do the start in the read routine
> Xad.Suspended=1;
> Xad.OverflowsSinceLastRead++;
> Xad.Overflow++;
> DBG_ADD_CHAR('*');
> if (Verbose) printk(KERN_WARNING SD "%dth buffer overflow: %d-%d=%d>=%d\n" FL,
> Xad.Overflow, Xad.Icnt, Xad.Rcnt, Xad.Icnt-Xad.Rcnt, BUF_NB);
> }
>
> wake_up_interruptible(&Xad.wait);
> return IRQ_HANDLED;
> }
>
What is "Xad." ? (btw, coding style FAIL !)
Are you trying to write to HW registers using a structure like that
without using the appropriate MMIO register accessors ?
In that case, your accesses may happen our of order since you don't have
memory barriers (among other potential problems).
The crash looks like you aren't properly clearing the interrupt
condition on the HW, it remains asserted, tho it shouldn't overflow like
that, something seems wrong with your PIC.
What HW is this ? What PIC ? It looks like the interrupt source isn't
masked on the PIC itself while it's being handled or something...
Cheers,
Ben.
^ permalink raw reply
* powerpc endian issue
From: Yuan Shi (yuansshi) @ 2011-07-07 22:58 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 567 bytes --]
Hello,
I am using perf to collect data from powerpc and analyze the data on a
local server.
When I am trying to use "perf report" the error "fatal:imcompatible file
format" comes up. It is noticed that the error is generated due to
perf_header size dismatch.
The issue is caused by that the powerpc is big endian and local server
is little endian.
I am wondering if any of you have ideas how to solve this problem.
Basically, how to analyze the perf.data generated on a powerpc on a
little endian Machine.
Sincerely yours,
Yuan
[-- Attachment #2: Type: text/html, Size: 2545 bytes --]
^ permalink raw reply
* Re: {PATCH] Firmware update using the update_flash -f <filename> results to soft lockup BUG
From: Michael Neuling @ 2011-07-08 1:51 UTC (permalink / raw)
To: divya
Cc: antonb, naveedaus, suzukikp, chavez, arunbal, srikar,
linuxppc-dev, jlarrew, lxie, mahesh.salgaonkar, Subrata Modak,
kenistoj
In-Reply-To: <4E155F15.1030805@linux.vnet.ibm.com>
In message <4E155F15.1030805@linux.vnet.ibm.com> you wrote:
> This is a multi-part message in MIME format.
> --===============3790206687486290502==
> Content-Type: multipart/alternative;
> boundary="------------080309090408040507080807"
>
> This is a multi-part message in MIME format.
> --------------080309090408040507080807
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
>
> On Thursday 07 July 2011 11:42 AM, Michael Neuling wrote:
> > In message<4E1543B6.9060800@linux.vnet.ibm.com> you wrote:
> >
> >> Hi ,
> >>
> >> Problem Description:
> >> Firmware update using the update_flash -f<filename> results to soft lock
up
> >> BUG
> >> FLASH: preparing saved firmware image for flash
> >> FLASH: flash image is 50141296 bytes
> >> FLASH: performing flash and reboot
> >> FLASH: this will take several minutes. Do not power off!
> >> BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36]
> >>
> >> Steps to reproduce:
> >> 1. Check the firmware information on the machine (using ASM or lsmcode)
> >> 2. Update the system firmware with the update_flash command
> >> update_flash -f 01FL350_039_038.img
> >> info: Temporary side will be updated with a newer or
> >> identical image
> >>
> >> Projected Flash Update Results:
> >> Current T Image: FL350_039
> >> Current P Image: FL350_039
> >> New T Image: FL350_039
> >> New P Image: FL350_039
> >> Flash image ready...rebooting the system...
> >>
> >> Broadcast message from root@abc
> >> (/dev/hvc0) at 5:25 ...
> >>
> >> The system is going down for reboot NOW!
> >> [root@abc /]# Stopping rhsmcertd[ OK ]
> >> Stopping atd: [ OK ]
> >> Stopping cups: [ OK ]
> >> Stopping abrt daemon: [ OK ]
> >> Stopping sshd: [ OK ]
> >> Shutting down postfix: [ OK ]
> >> Stopping rtas_errd (platform error handling) daemon: [ OK ]
> >> Stopping crond: [ OK ]
> >> Stopping automount: [ OK ]
> >> Stopping HAL daemon: [ OK ]
> >> Stopping iprdump: [ OK ]
> >> Killing mdmonitor: [ OK ]]
> >> Stopping system message bus: [ OK ]
> >> Stopping rpcbind: [ OK ]
> >> Stopping auditd: [ OK ]
> >> Shutting down interface eth0: [ OK ]
> >> Shutting down loopback interface: [ OK ]
> >> ip6tables: Flushing firewall rules: [ OK ]
> >> ip6tables: Setting chains to policy ACCEPT: filter [ OK ]
> >> ip6tables: Unloading modules: [ OK ]
> >> iptables: Flushing firewall rules: [ OK ]
> >> iptables: Setting chains to policy ACCEPT: filter [ OK ]
> >> iptables: Unloading modules: [ OK ]
> >> Sending all processes the TERM signal... [ OK ]
> >> Sending all processes the KILL signal... [ OK ]
> >> Saving random seed: [ OK ]
> >> Turning off swap: [ OK ]
> >> Turning off quotas: [ OK ]
> >> Unmounting pipe file systems: [ OK ]
> >> Unmounting file systems: [ OK ]
> >> init: Re-executing /sbin/init
> >> Please stand by while rebooting the system...
> >> Restarting system.
> >> FLASH: preparing saved firmware image for flash
> >> FLASH: flash image is 50141296 bytes
> >> FLASH: performing flash and reboot
> >> FLASH: this will take several minutes. Do not power off!
> >> BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36]
> >>
> >> This is solved by the following patch
> >>
> > Can you please explain how it fixes it?
> >
> The flash update is conducted with an RTAS call. The RTAS calls are
> serialized by lock_rtas() which uses a spin_lock.
>
> Now there is rtasd which keeps scanning for the RTAS events generated
> on the machine. This is performed via workqueue mechanism. The
> rtas_event_scan() also uses an RTAS call to scan the events,
> eventually taking the lock_rtas() before it issues the request.
>
> The flash update is an operation which takes long time, and hence
> while we are at it, anyboy else who wants to make an RTAS call will
> have to wait until the update is completed. Now in this case, the
> rtas_event_scan() is being kicked in to check for events and it waits
> a long time on the spin_lock, getting us a SOFT Lockup.
What other RTAS calls are going on at this point? It worries me we are
stopping a CPU that's doing RTAS calls. Your solution would seem to be
papering over a more serious problem.
> Before the rtas firmware update starts, all other CPUs should be
> stopped. Which means no other CPU should be in lock_rtas(). We do not
> want other CPUs execute while FW update is in progress and the system
> will be rebooted anyway after the update.
Mikey
^ permalink raw reply
* [PATCH v4 1/3] driver core: Add ability for arch code to setup pdev_archdata
From: Kumar Gala @ 2011-07-08 4:00 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-kernel
On some architectures we need to setup pdev_archdata before we add the
device. Waiting til a bus_notifier is too late since we might need the
pdev_archdata in the bus notifier. One example is setting up of dma_mask
pointers such that it can be used in a bus_notifier.
We add weak noop version of arch_setup_pdev_archdata() and allow the arch
code to override with access the full definitions of struct device,
struct platform_device, and struct pdev_archdata.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
v4:
* Move to use a weak function based on comments from Greg
v3:
* Add more comments and add missing call to arch_setup_pdev_archdata in
platform_device_register
v2:
* Added license, and comments about arch_setup_pdev_archdata()
per Mike's comments
drivers/base/platform.c | 22 ++++++++++++++++++++++
include/linux/platform_device.h | 1 +
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 1c291af..060686d 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -32,6 +32,26 @@ struct device platform_bus = {
EXPORT_SYMBOL_GPL(platform_bus);
/**
+ * arch_setup_pdev_archdata - Allow manipulation of archdata before its used
+ * @dev: platform device
+ *
+ * This is called before platform_device_add() such that any pdev_archdata may
+ * be setup before the platform_notifier is called. So if a user needs to
+ * manipulate any relevant information in the pdev_archdata they can do:
+ *
+ * platform_devic_alloc()
+ * ... manipulate ...
+ * platform_device_add()
+ *
+ * And if they don't care they can just call platform_device_register() and
+ * everything will just work out.
+ */
+void __weak arch_setup_pdev_archdata(struct platform_device *pdev)
+{
+ return ;
+}
+
+/**
* platform_get_resource - get a resource for a device
* @dev: platform device
* @type: resource type
@@ -173,6 +193,7 @@ struct platform_device *platform_device_alloc(const char *name, int id)
pa->pdev.id = id;
device_initialize(&pa->pdev.dev);
pa->pdev.dev.release = platform_device_release;
+ arch_setup_pdev_archdata(&pa->pdev);
}
return pa ? &pa->pdev : NULL;
@@ -334,6 +355,7 @@ EXPORT_SYMBOL_GPL(platform_device_del);
int platform_device_register(struct platform_device *pdev)
{
device_initialize(&pdev->dev);
+ arch_setup_pdev_archdata(pdev);
return platform_device_add(pdev);
}
EXPORT_SYMBOL_GPL(platform_device_register);
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index ede1a80..27bb05a 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -42,6 +42,7 @@ extern void platform_device_unregister(struct platform_device *);
extern struct bus_type platform_bus_type;
extern struct device platform_bus;
+extern void arch_setup_pdev_archdata(struct platform_device *);
extern struct resource *platform_get_resource(struct platform_device *, unsigned int, unsigned int);
extern int platform_get_irq(struct platform_device *, unsigned int);
extern struct resource *platform_get_resource_byname(struct platform_device *, unsigned int, const char *);
--
1.7.3.4
^ permalink raw reply related
* [PATCH v4 2/3] powerpc: implement arch_setup_pdev_archdata
From: Kumar Gala @ 2011-07-08 4:00 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1310097643-8414-1-git-send-email-galak@kernel.crashing.org>
We have a long standing issues with platform devices not have a valid
dma_mask pointer. This hasn't been an issue to date as no platform
device has tried to set its dma_mask value to a non-default value.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/kernel/setup-common.c | 28 ++++------------------------
drivers/of/platform.c | 4 ++--
2 files changed, 6 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 79fca26..ea82baa 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -704,29 +704,9 @@ static int powerpc_debugfs_init(void)
arch_initcall(powerpc_debugfs_init);
#endif
-static int ppc_dflt_bus_notify(struct notifier_block *nb,
- unsigned long action, void *data)
+void arch_setup_pdev_archdata(struct platform_device *pdev)
{
- struct device *dev = data;
-
- /* We are only intereted in device addition */
- if (action != BUS_NOTIFY_ADD_DEVICE)
- return 0;
-
- set_dma_ops(dev, &dma_direct_ops);
-
- return NOTIFY_DONE;
-}
-
-static struct notifier_block ppc_dflt_plat_bus_notifier = {
- .notifier_call = ppc_dflt_bus_notify,
- .priority = INT_MAX,
-};
-
-static int __init setup_bus_notifier(void)
-{
- bus_register_notifier(&platform_bus_type, &ppc_dflt_plat_bus_notifier);
- return 0;
+ pdev->archdata.dma_mask = DMA_BIT_MASK(32);
+ pdev->dev.dma_mask = &pdev->archdata.dma_mask;
+ set_dma_ops(&pdev->dev, &dma_direct_ops);
}
-
-arch_initcall(setup_bus_notifier);
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 63d3cb7..cfc6a79 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -153,7 +153,7 @@ struct platform_device *of_device_alloc(struct device_node *np,
}
dev->dev.of_node = of_node_get(np);
-#if defined(CONFIG_PPC) || defined(CONFIG_MICROBLAZE)
+#if defined(CONFIG_MICROBLAZE)
dev->dev.dma_mask = &dev->archdata.dma_mask;
#endif
dev->dev.parent = parent;
@@ -189,7 +189,7 @@ struct platform_device *of_platform_device_create(struct device_node *np,
if (!dev)
return NULL;
-#if defined(CONFIG_PPC) || defined(CONFIG_MICROBLAZE)
+#if defined(CONFIG_MICROBLAZE)
dev->archdata.dma_mask = 0xffffffffUL;
#endif
dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
--
1.7.3.4
^ permalink raw reply related
* [PATCH v4 3/3] powerpc: Dont require a dma_ops struct to set dma mask
From: Kumar Gala @ 2011-07-08 4:00 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1310097643-8414-2-git-send-email-galak@kernel.crashing.org>
The only reason to require a dma_ops struct is to see if it has
implemented set_dma_mask. If not we can fall back to setting the mask
directly.
This resolves an issue with how to sequence the setting of a DMA mask
for platform devices. Before we had an issue in that we have no way of
setting the DMA mask before the various low level bus notifiers get
called that might check it (swiotlb).
So now we can do:
pdev = platform_device_alloc("foobar", 0);
dma_set_mask(&pdev->dev, DMA_BIT_MASK(37));
platform_device_add(pdev);
And expect the right thing to happen with the bus notifiers get called
via platform_device_add.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/kernel/dma.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index d238c08..4f0959f 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -161,9 +161,7 @@ int dma_set_mask(struct device *dev, u64 dma_mask)
if (ppc_md.dma_set_mask)
return ppc_md.dma_set_mask(dev, dma_mask);
- if (unlikely(dma_ops == NULL))
- return -EIO;
- if (dma_ops->set_dma_mask != NULL)
+ if ((dma_ops != NULL) && (dma_ops->set_dma_mask != NULL))
return dma_ops->set_dma_mask(dev, dma_mask);
if (!dev->dma_mask || !dma_supported(dev, dma_mask))
return -EIO;
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH v3 1/3] driver core: Add ability for arch code to setup pdev_archdata
From: Kumar Gala @ 2011-07-08 4:03 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20110707141125.GE27648@kroah.com>
On Jul 7, 2011, at 9:11 AM, Greg KH wrote:
> On Thu, Jul 07, 2011 at 08:55:44AM -0500, Kumar Gala wrote:
>>=20
>> On Jul 1, 2011, at 5:09 PM, Greg KH wrote:
>>=20
>>> On Thu, Jun 23, 2011 at 06:33:57AM -0500, Kumar Gala wrote:
>>>> On some architectures we need to setup pdev_archdata before we add =
the
>>>> device. Waiting til a bus_notifier is too late since we might need =
the
>>>> pdev_archdata in the bus notifier. One example is setting up of =
dma_mask
>>>> pointers such that it can be used in a bus_notifier.
>>>>=20
>>>> We add noop version of arch_setup_pdev_archdata() in
>>>> <asm-generic/platform_device.h> and allow the arch code to override =
with
>>>> access the full definitions of struct device, struct =
platform_device, and
>>>> struct pdev_archdata.
>>>=20
>>> Isn't there some way to use "weak" symbols to keep us from having to
>>> create this .h file in every single arch and then if the arch wants =
to
>>> define it, it does so?
>>>=20
>>> That should make this patch simpler, right?
>>>=20
>>> thanks,
>>>=20
>>> greg k-h
>>=20
>> Changing to weak should be doable if we are ok with the additional
>> function call always happening.
>=20
> Given that this is not a fast path, and the function call for the
> "normal" case would do nothing, it should be fine, right?
>=20
> greg k-h
Sounds good, new version sent that uses weak instead. If this looks =
good let me know if you just want to ACK and send via powerpc.git tree =
or if you'll pick these up.
- k
^ permalink raw reply
* Re: [PATCH] Remove a BUG_ON that triggered when running under FSL Hypervisor
From: Kumar Gala @ 2011-07-08 4:12 UTC (permalink / raw)
To: Laurentiu TUDOR; +Cc: linuxppc-dev
In-Reply-To: <1310046270-6654-1-git-send-email-Laurentiu.Tudor@freescale.com>
On Jul 7, 2011, at 8:44 AM, Laurentiu TUDOR wrote:
> mpc85xx_smp_init platform init function assumed that smp_ops.message_pass
> was set to default arch dependent smp_muxed_ipi_message_pass.
> However this does not seem to happen. Moreover, the arch specific code
> in arch/powerpc/kernel/smp.c handles smp_ops.message_pass == NULL and if so
> calls the default implementation.
>
> Signed-off-by: Laurentiu TUDOR <Laurentiu.Tudor@freescale.com>
> ---
> arch/powerpc/platforms/85xx/smp.c | 9 +++++----
> 1 files changed, 5 insertions(+), 4 deletions(-)
Re-worded commit message a bit, applied to next
- k
^ permalink raw reply
* Re: [PATCH] powerpc/p1022ds: Remove fixed-link property from ethernet nodes.
From: Kumar Gala @ 2011-07-08 4:12 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev, B04825
In-Reply-To: <1310024270-2675-1-git-send-email-felix@embedded-sol.com>
On Jul 7, 2011, at 2:37 AM, Felix Radensky wrote:
> On P1022DS both ethernet controllers are connected to RGMII PHYs
> accessible via MDIO bus. Remove fixed-link property from ethernet
> nodes as they only required when fixed link PHYs without MDIO bus
> are used.
>
> Signed-off-by: Felix Radensky <felix@embedded-sol.com>
> ---
> arch/powerpc/boot/dts/p1022ds.dts | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
applied to next
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Add p2040 RDB board support
From: Kumar Gala @ 2011-07-08 4:12 UTC (permalink / raw)
To: Mingkai Hu; +Cc: linuxppc-dev
In-Reply-To: <1309247554-13580-1-git-send-email-Mingkai.hu@freescale.com>
On Jun 28, 2011, at 2:52 AM, Mingkai Hu wrote:
> P2040RDB Specification:
> -----------------------
> 2Gbyte unbuffered DDR3 SDRAM SO-DIMM(64bit bus)
> 128 Mbyte NOR flash single-chip memory
> 256 Kbit M24256 I2C EEPROM
> 16 Mbyte SPI memory
> SD connector to interface with the SD memory card
> dTSEC1: connected to the Vitesse SGMII PHY (VSC8221)
> dTSEC2: connected to the Vitesse SGMII PHY (VSC8221)
> dTSEC3: connected to the Vitesse SGMII PHY (VSC8221)
> dTSEC4: connected to the Vitesse RGMII PHY (VSC8641)
> dTSEC5: connected to the Vitesse RGMII PHY (VSC8641)
> I2C1: Real time clock, Temperature sensor
> I2C2: Vcore Regulator, 256Kbit I2C Bus EEPROM
> SATA: Lanes C and Land D of Bank2 are connected to two SATA connectors
> UART: supports two UARTs up to 115200 bps for console
> USB 2.0: connected via a internal UTMI PHY to two TYPE-A interfaces
> PCIe:
> - Lanes E, F, G and H of Bank1 are connected to one x4 PCIe SLOT1
> - Lanes C and Land D of Bank2 are connected to one x4 PCIe SLOT2
>=20
> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
> ---
> Based on =
http://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
>=20
> arch/powerpc/boot/dts/p2040rdb.dts | 166 +++++++
> arch/powerpc/boot/dts/p2040si.dtsi | 623 =
++++++++++++++++++++++++++
> arch/powerpc/configs/corenet32_smp_defconfig | 1 +
> arch/powerpc/platforms/85xx/Kconfig | 12 +
> arch/powerpc/platforms/85xx/Makefile | 1 +
> arch/powerpc/platforms/85xx/p2040_rdb.c | 88 ++++
> 6 files changed, 891 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/p2040rdb.dts
> create mode 100644 arch/powerpc/boot/dts/p2040si.dtsi
> create mode 100644 arch/powerpc/platforms/85xx/p2040_rdb.c
applied to next
- k
^ permalink raw reply
* Re: [PATCH 4/5] powerpc: Create next_tlbcam_idx percpu variable for FSL_BOOKE
From: Kumar Gala @ 2011-07-08 4:13 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev, linux-kernel, wli, david
In-Reply-To: <13092911313115-git-send-email-beckyb@kernel.crashing.org>
On Jun 28, 2011, at 2:54 PM, Becky Bruce wrote:
> From: Becky Bruce <beckyb@kernel.crashing.org>
>
> This is used to round-robin TLBCAM entries.
>
> Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
> ---
> arch/powerpc/include/asm/mmu.h | 5 +++++
> arch/powerpc/kernel/smp.c | 4 ++++
> arch/powerpc/mm/mem.c | 9 +++++++++
> arch/powerpc/mm/tlb_nohash.c | 6 ++++++
> 4 files changed, 24 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH v4 1/3] driver core: Add ability for arch code to setup pdev_archdata
From: Greg KH @ 2011-07-08 4:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1310097643-8414-1-git-send-email-galak@kernel.crashing.org>
On Thu, Jul 07, 2011 at 11:00:41PM -0500, Kumar Gala wrote:
> On some architectures we need to setup pdev_archdata before we add the
> device. Waiting til a bus_notifier is too late since we might need the
> pdev_archdata in the bus notifier. One example is setting up of dma_mask
> pointers such that it can be used in a bus_notifier.
>
> We add weak noop version of arch_setup_pdev_archdata() and allow the arch
> code to override with access the full definitions of struct device,
> struct platform_device, and struct pdev_archdata.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> v4:
> * Move to use a weak function based on comments from Greg
> v3:
> * Add more comments and add missing call to arch_setup_pdev_archdata in
> platform_device_register
> v2:
> * Added license, and comments about arch_setup_pdev_archdata()
> per Mike's comments
>
> drivers/base/platform.c | 22 ++++++++++++++++++++++
> include/linux/platform_device.h | 1 +
> 2 files changed, 23 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 1c291af..060686d 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -32,6 +32,26 @@ struct device platform_bus = {
> EXPORT_SYMBOL_GPL(platform_bus);
>
> /**
> + * arch_setup_pdev_archdata - Allow manipulation of archdata before its used
> + * @dev: platform device
> + *
> + * This is called before platform_device_add() such that any pdev_archdata may
> + * be setup before the platform_notifier is called. So if a user needs to
> + * manipulate any relevant information in the pdev_archdata they can do:
> + *
> + * platform_devic_alloc()
> + * ... manipulate ...
> + * platform_device_add()
> + *
> + * And if they don't care they can just call platform_device_register() and
> + * everything will just work out.
> + */
> +void __weak arch_setup_pdev_archdata(struct platform_device *pdev)
> +{
> + return ;
> +}
The "return" isn't needed, nor is the extra ' ' there, right? :)
Change that and you can take this through the ppc tree and add a:
Acked-by: Greg Kroah-Hartman
to them.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4 1/3] driver core: Add ability for arch code to setup pdev_archdata
From: Kumar Gala @ 2011-07-08 5:16 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20110708042235.GA26357@kroah.com>
On Jul 7, 2011, at 11:22 PM, Greg KH wrote:
> On Thu, Jul 07, 2011 at 11:00:41PM -0500, Kumar Gala wrote:
>> On some architectures we need to setup pdev_archdata before we add =
the
>> device. Waiting til a bus_notifier is too late since we might need =
the
>> pdev_archdata in the bus notifier. One example is setting up of =
dma_mask
>> pointers such that it can be used in a bus_notifier.
>>=20
>> We add weak noop version of arch_setup_pdev_archdata() and allow the =
arch
>> code to override with access the full definitions of struct device,
>> struct platform_device, and struct pdev_archdata.
>>=20
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>> v4:
>> * Move to use a weak function based on comments from Greg
>> v3:
>> * Add more comments and add missing call to arch_setup_pdev_archdata =
in
>> platform_device_register
>> v2:
>> * Added license, and comments about arch_setup_pdev_archdata()
>> per Mike's comments
>>=20
>> drivers/base/platform.c | 22 ++++++++++++++++++++++
>> include/linux/platform_device.h | 1 +
>> 2 files changed, 23 insertions(+), 0 deletions(-)
>>=20
>> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
>> index 1c291af..060686d 100644
>> --- a/drivers/base/platform.c
>> +++ b/drivers/base/platform.c
>> @@ -32,6 +32,26 @@ struct device platform_bus =3D {
>> EXPORT_SYMBOL_GPL(platform_bus);
>>=20
>> /**
>> + * arch_setup_pdev_archdata - Allow manipulation of archdata before =
its used
>> + * @dev: platform device
>> + *
>> + * This is called before platform_device_add() such that any =
pdev_archdata may
>> + * be setup before the platform_notifier is called. So if a user =
needs to
>> + * manipulate any relevant information in the pdev_archdata they can =
do:
>> + *
>> + * platform_devic_alloc()
>> + * ... manipulate ...
>> + * platform_device_add()
>> + *
>> + * And if they don't care they can just call =
platform_device_register() and
>> + * everything will just work out.
>> + */
>> +void __weak arch_setup_pdev_archdata(struct platform_device *pdev)
>> +{
>> + return ;
>> +}
>=20
> The "return" isn't needed, nor is the extra ' ' there, right? :)
yep, removed the ';' as well ;)
> Change that and you can take this through the ppc tree and add a:
> Acked-by: Greg Kroah-Hartman
> to them.
Ack added to all.
thanks
- k=
^ permalink raw reply
* [PATCH] powerpc/irq: Quieten irq mapping printks
From: Anton Blanchard @ 2011-07-08 6:35 UTC (permalink / raw)
To: benh, miltonm, michael; +Cc: linuxppc-dev
HFI creates interrupts each time a window is setup. This results in
a lot of messages in the kernel log buffer:
irq: irq 199007 on host null mapped to virtual irq 351
This box has over 3500 of them, causing more important kernel
messages to be overwritten. We can get at this information via
debugfs now so we may as well turn it into a pr_debug.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-powerpc/arch/powerpc/kernel/irq.c
===================================================================
--- linux-powerpc.orig/arch/powerpc/kernel/irq.c 2011-07-08 08:49:44.288874115 +1000
+++ linux-powerpc/arch/powerpc/kernel/irq.c 2011-07-08 08:49:47.458927046 +1000
@@ -744,7 +744,7 @@ unsigned int irq_create_mapping(struct i
if (irq_setup_virq(host, virq, hwirq))
return NO_IRQ;
- printk(KERN_DEBUG "irq: irq %lu on host %s mapped to virtual irq %u\n",
+ pr_debug("irq: irq %lu on host %s mapped to virtual irq %u\n",
hwirq, host->of_node ? host->of_node->full_name : "null", virq);
return virq;
^ 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