* Re: Oops while running systemtap on the p6 machine against the kernel version 2.6.36-rc7-git3
From: Frank Ch. Eigler @ 2010-10-14 20:46 UTC (permalink / raw)
To: divya; +Cc: linuxppc-dev, systemtap
In-Reply-To: <4CB704AC.4070203@linux.vnet.ibm.com>
divya <dipraksh@linux.vnet.ibm.com> writes:
> While running systemtap tests on the p6 machine , against the kernel
> version 2.6.36-rc7-git3 Oops occured , here are the call trace
Did the oops happen during a systemtap module startup vs. operation
vs. shutdown? stap -V version string?
> BUG: spinlock bad magic on CPU#6, stapio/20398
> -- 0:conmux-control -- time-stamp -- Oct/13/10 2:49:18 --res
> lock: c000000000fcfa18, .magic: 00000000, .owner:<none>/-1, .owner_cpu: 0
> Call Trace:
> [c0000001effbfab0] [c000000000011934] .show_stack+0x6c/0x16c (unreliable)
> [c0000001effbfb60] [c0000000002c9274] .spin_bug+0xb0/0xd4
> [c0000001effbfbf0] [c0000000002c953c] .do_raw_spin_lock+0x48/0x184
> [c0000001effbfc90] [c00000000054af78] ._raw_spin_lock+0x10/0x24
> [c0000001effbfd00] [d000000003015908] .__stp_time_timer_callback+0x94/0x13c [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798]
> [...]
> kernel BUG at kernel/timer.c:681!
> Oops: Exception in kernel mode, sig: 5 [#1]
> SMP NR_CPUS=1024 NUMA pSeries
> [...]
> [c0000001effbfc50] [c0000001effbfd00] 0xc0000001effbfd00 (unreliable)
> [c0000001effbfd00] [d00000000301597c] .__stp_time_timer_callback+0x108/0x13c [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798]
> [c0000001effbfdc0] [c00000000009c2f8] .run_timer_softirq+0x1d8/0x2a8
We have had occasional problems in the past with something like this:
http://sourceware.org/PR10651, but it never was tracked down to a
systemtap bug per se, as opposed to suspicions that the kernel was not
satisfying one of its guarantees w.r.t. del_timer_sync().
- FChE
^ permalink raw reply
* Re: [PATCH 2/2] [v2] powerpc/85xx: add DIU support to the Freecale P1022DS reference board
From: Mark Brown @ 2010-10-14 20:49 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, kumar.gala, alsa-devel mailing list
In-Reply-To: <AANLkTimWgbJ0oDsQkXxzjQ_pDxm_Vd+PJRhQJzN0BLTc@mail.gmail.com>
On Thu, Oct 14, 2010 at 01:21:33PM -0500, Timur Tabi wrote:
> Mark, can you pick up this patch for us? Because it depends on
> "powerpc: rename immap_86xx.h to fsl_guts.h, and add 85xx support", it
> will break the build if we apply to powerpc-next.
>
> You can grab the patch from http://patchwork.ozlabs.org/patch/67095/
Done, but I had to fix up what looked like an add/add conflict with
headers in the file. Since I was editing that area of the file anyway I
also dropped the #define DEBUG as it looked like a mistake. Please send
followup patch(es) correcting things if I messed up any of that.
^ permalink raw reply
* msi_bitmap.c question
From: Tirumala Marri @ 2010-10-14 22:56 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 612 bytes --]
Hi,
I am trying to resubmit a patch for MSI support for ppc4xx devices. One of
the review feedback was not to use the bit map as it is only for the devices
which don’t have hard wired mapping between interrupt controller interrupts
and MSI number. For example intr-ctrl0 interrupt 20 goes to MSI-0, interrupt
21 goes to MSI-1 ..etc. But when I checked freescale SoCs and cell SoCs
they have interrupts hard wired to MSI interrupts.
Why do they have to use the bitmap and create irqhost, even though they are
one-to-one mapped between interrupt controller numbers and MSI ?
Thx,
Marri
[-- Attachment #2: Type: text/html, Size: 1843 bytes --]
^ permalink raw reply
* Re: Possible kernel stack overflow due to fast interrupts
From: Benjamin Herrenschmidt @ 2010-10-14 23:57 UTC (permalink / raw)
To: Rick Tao; +Cc: linuxppc-dev
In-Reply-To: <174398.42321.qm@web50405.mail.re2.yahoo.com>
On Thu, 2010-10-14 at 13:45 -0700, Rick Tao wrote:
> Hi, all,
.../...
> In the context of task A
> a. NIP would point to the instruction after switch_to().
> b. MSR_EE is enabled in the call trace (finish_task_switch -->finish_lock_switch-->spin_unlock_irq)
> c. do something that would trigger an interrupt later on (such as timer)
> d. call schedule() for context switch to task B.
> In this step,
> task B's stack is popped INT_FRAME_SIZE size for context restore.
> Note that task B's ksp = X - INT_FRAME_SIZE
>
> In the context of task B again
> a1. similar to step "a" above
>
> b1. similar to step "b" above
> c1. interrupt occurs, go to step "1" above, and repeat!!!
>
> As you can see, task B's kernel stack space is reduced by INT_FRAME_SIZE
> on each loop. It will eventually overflow.
So if I follow you correctly, you are worried that by the time execution
resumes in B, and before it pops the second frame off, it might get
another interrupt and re-preempt...
Now unless I missed something, that cannot happen because
preempt_schedule_irq() does increment the preempt count:
add_preempt_count(PREEMPT_ACTIVE);
local_irq_enable();
schedule();
local_irq_disable();
sub_preempt_count(PREEMPT_ACTIVE);
Which means that it won't preempt again in finish_task_switch, and so
will eventually come back, turn EE back off, and pop off the stack
frame.
Or am I missing something ?
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
From: Michael Ellerman @ 2010-10-15 0:14 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Michael Neuling, Frans Pop, linux-kernel, Paul Mackerras,
Anton Blanchard, Linas Vepstas, linuxppc-dev, Thomas Gleixner
In-Reply-To: <1287078495-11722-1-git-send-email-nacc@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 986 bytes --]
On Thu, 2010-10-14 at 10:48 -0700, Nishanth Aravamudan wrote:
> These files undef DEBUG, but I think they were added before the ability
> to control this from Kconfig.
Perhaps. Some people, *cough*, have a tendency to merge those back in
again from time to time :)
> It's really annoying to only get some of the debug messages!
True, but ..
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
>
> ---
> Because the lpar and pci_dlpar code is pretty low-level & verbose,
> perhaps it makes sense to add another Kconfig variable for really
> low-level stuff? But it's annoying to have DEBUG *somewhat* effective,
> especially in the EEH area when doing PCI stuff.
I really don't think you want to enable the lpar debug by default. Have
you tried it? It can make for a pretty unusable system, just because of
the console spam.
Also these days there is CONFIG_DYNAMIC_DEBUG which is much smarter than
all this, but requires setup at runtime.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
From: Nishanth Aravamudan @ 2010-10-15 0:23 UTC (permalink / raw)
To: Michael Ellerman
Cc: Michael Neuling, Frans Pop, linux-kernel, Paul Mackerras,
Anton Blanchard, Linas Vepstas, linuxppc-dev, Thomas Gleixner
In-Reply-To: <1287101663.4194.5.camel@concordia>
On 15.10.2010 [11:14:23 +1100], Michael Ellerman wrote:
> On Thu, 2010-10-14 at 10:48 -0700, Nishanth Aravamudan wrote:
> > These files undef DEBUG, but I think they were added before the ability
> > to control this from Kconfig.
>
> Perhaps. Some people, *cough*, have a tendency to merge those back in
> again from time to time :)
>
> > It's really annoying to only get some of the debug messages!
>
> True, but ..
>
> > Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> >
> > ---
> > Because the lpar and pci_dlpar code is pretty low-level & verbose,
> > perhaps it makes sense to add another Kconfig variable for really
> > low-level stuff? But it's annoying to have DEBUG *somewhat* effective,
> > especially in the EEH area when doing PCI stuff.
>
> I really don't think you want to enable the lpar debug by default.
> Have you tried it? It can make for a pretty unusable system, just
> because of the console spam.
Yeah, you're right. After enabling it, I had to kill my boot and start
over w/o the lpar DEBUG on. I assume dlpar_pci is similar?
I dunno, would a patch to a least remove the EEH one be ok? Seems like
it isn't super-verbose, and does have some handy output.
> Also these days there is CONFIG_DYNAMIC_DEBUG which is much smarter than
> all this, but requires setup at runtime.
True, I started looking into it, but only realized today that eeh.c had
that #undef! :)
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* Re: msi_bitmap.c question
From: Michael Ellerman @ 2010-10-15 0:25 UTC (permalink / raw)
To: Tirumala Marri; +Cc: linuxppc-dev
In-Reply-To: <6cfa2d1c7ecd946ea4acbd3077defa92@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]
On Thu, 2010-10-14 at 15:56 -0700, Tirumala Marri wrote:
> Hi,
>
> I am trying to resubmit a patch for MSI support for ppc4xx devices.
> One of the review feedback was not to use the bit map as it is only
> for the devices which don’t have hard wired mapping between interrupt
> controller interrupts and MSI number. For example intr-ctrl0 interrupt
> 20 goes to MSI-0, interrupt 21 goes to MSI-1 ..etc. But when I checked
> freescale SoCs and cell SoCs they have interrupts hard wired to MSI
> interrupts.
>
>
>
> Why do they have to use the bitmap and create irqhost, even though
> they are one-to-one mapped between interrupt controller numbers and
> MSI ?
I'm not quite sure I understand your question.
The MSI bitmap and the irq_host are two different things.
The MSI bitmap is basically an allocator for hardware numbers that can
be used for MSI. On some interrupt controllers that might be any
interrupt that's not used, on others there are restrictions on which
numbers can be used for MSI, it depends. So it's possible you don't need
to use that code, but I don't know how your hardware works.
The irq_host is the struct that controls mapping hardware irq numbers
into linux irq numbers. The cell MSI code has no restrictions on what
the MSI value is, so it just uses the Linux irq number directly using
irq_create_direct_mapping().
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
From: Michael Ellerman @ 2010-10-15 0:29 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Michael Neuling, Frans Pop, linux-kernel, Paul Mackerras,
Anton Blanchard, Linas Vepstas, linuxppc-dev, Thomas Gleixner
In-Reply-To: <20101015002300.GB7522@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]
On Thu, 2010-10-14 at 17:23 -0700, Nishanth Aravamudan wrote:
> On 15.10.2010 [11:14:23 +1100], Michael Ellerman wrote:
> > On Thu, 2010-10-14 at 10:48 -0700, Nishanth Aravamudan wrote:
> > > Because the lpar and pci_dlpar code is pretty low-level & verbose,
> > > perhaps it makes sense to add another Kconfig variable for really
> > > low-level stuff? But it's annoying to have DEBUG *somewhat* effective,
> > > especially in the EEH area when doing PCI stuff.
> >
> > I really don't think you want to enable the lpar debug by default.
> > Have you tried it? It can make for a pretty unusable system, just
> > because of the console spam.
>
> Yeah, you're right. After enabling it, I had to kill my boot and start
> over w/o the lpar DEBUG on.
:)
> I assume dlpar_pci is similar?
That should be OK to enable I think. Suck it and see I guess.
> I dunno, would a patch to a least remove the EEH one be ok? Seems like
> it isn't super-verbose, and does have some handy output.
Yeah definitely. That undef was merged as part of a cleanup/fix patch
but shouldn't have been.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH v2] pseries: don't override CONFIG_PPC_PSERIES_DEBUG
From: Nishanth Aravamudan @ 2010-10-15 0:48 UTC (permalink / raw)
To: nacc
Cc: Frans Pop, linux-kernel, Paul Mackerras, Anton Blanchard,
Brian King, Linas Vepstas, linuxppc-dev, Thomas Gleixner
eeh and pci_dlpar #undef DEBUG, but I think they were added before the
ability to control this from Kconfig. It's really annoying to only get
some of the debug messages from these files. Leave the lpar.c #undef
alone as it produces so much output as to make the kernel unusable.
Update the Kconfig text to indicate this particular quirk :)
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
arch/powerpc/platforms/pseries/Kconfig | 6 ++++++
arch/powerpc/platforms/pseries/eeh.c | 2 --
arch/powerpc/platforms/pseries/pci_dlpar.c | 2 --
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
index c667f0f..3139814 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -47,6 +47,12 @@ config LPARCFG
config PPC_PSERIES_DEBUG
depends on PPC_PSERIES && PPC_EARLY_DEBUG
bool "Enable extra debug logging in platforms/pseries"
+ help
+ Say Y here if you want the pseries core to produce a bunch of
+ debug messages to the system log. Select this if you are having a
+ problem with the pseries core and want to see more of what is
+ going on. This does not enable debugging in lpar.c, which must
+ be manually done due to its verbosity.
default y
config PPC_SMLPAR
diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
index 34b7dc1..17a11c8 100644
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -21,8 +21,6 @@
* Please address comments and feedback to Linas Vepstas <linas@austin.ibm.com>
*/
-#undef DEBUG
-
#include <linux/delay.h>
#include <linux/init.h>
#include <linux/list.h>
diff --git a/arch/powerpc/platforms/pseries/pci_dlpar.c b/arch/powerpc/platforms/pseries/pci_dlpar.c
index 4b7a062..5fcc92a 100644
--- a/arch/powerpc/platforms/pseries/pci_dlpar.c
+++ b/arch/powerpc/platforms/pseries/pci_dlpar.c
@@ -25,8 +25,6 @@
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-#undef DEBUG
-
#include <linux/pci.h>
#include <asm/pci-bridge.h>
#include <asm/ppc-pci.h>
--
1.7.1
^ permalink raw reply related
* Re: Questions on interrupt vector assignment on MPC8641D
From: tiejun.chen @ 2010-10-15 1:28 UTC (permalink / raw)
To: Scott Wood; +Cc: david.hagood, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20101014105126.08da9dd7@udp111988uds.am.freescale.net>
Scott Wood wrote:
> On Thu, 14 Oct 2010 11:27:09 +0800
> "tiejun.chen" <tiejun.chen@windriver.com> wrote:
>
>> tiejun.chen wrote:
>>> Scott Wood wrote:
>>>> On Wed, 13 Oct 2010 09:17:01 +0800
>>>> "tiejun.chen" <tiejun.chen@windriver.com> wrote:
>>>>
>>>>> Scott Wood wrote:
>>>>>> The crash is happening somewhere in mpic_set_irq_type():
>>>>> Agreed. That is just where I pointed out on my email replied for OOPS. To enable
>>>>> DBG to figure out 'src' and 'mpic->irq_count' from the file,
>>>>> arch/powerpc/sysdev/mpic.c, .
>>>>> ======
>>>>> int mpic_set_irq_type(unsigned int virq, unsigned int flow_type)
>>>>> {
>>>>> ......
>>>>> if (src >= mpic->irq_count)
>>>>> return -EINVAL;
>>>>> ^
>>>>> I think this OOPS may be from here.
>>>> No, it's after that. His board code is using the mpic's "isu" remapping
>>> I means OOPS is *from* here. According to David's call trace,
>>> mpic_set_irq_type() is the last issued function. And that corresponding return
>>> value, R3, is '0xffffffea', -22, and also '-EINVAL'.
>
> Just because that value is in r3 doesn't mean that src >=
> mpic->irq_count.
>
> Consider something like:
>
> cmplw r4, r5
> li r3, -EINVAL
> bgelr
Right absolutely and got it.
Thanks again
Tiejun
> ...
>
>
> -Scott
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
From: Linas Vepstas @ 2010-10-15 1:47 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Michael Neuling, Frans Pop, linux-kernel, Paul Mackerras,
Anton Blanchard, Thomas Gleixner, linuxppc-dev
In-Reply-To: <1287078495-11722-1-git-send-email-nacc@us.ibm.com>
On 14 October 2010 12:48, Nishanth Aravamudan <nacc@us.ibm.com> wrote:
> These files undef DEBUG, but I think they were added before the ability
> to control this from Kconfig.
Right.
> It's really annoying to only get some of
> the debug messages!
I don't get the big picture. Will there be some CONFIG_DEBUG_EEH in Kconfig?
or just some option to turn on DEBUG for all powerpc-related files?
Or maybe I am demonstrating my utter ignorance of some new whiz-bang
Kconfig technology?
Anyway, I see no harm in the EEH portion of the patch.
--linas
^ permalink raw reply
* Re: [PATCH v2] pseries: don't override CONFIG_PPC_PSERIES_DEBUG
From: Linas Vepstas @ 2010-10-15 1:54 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Frans Pop, linux-kernel, Paul Mackerras, Anton Blanchard,
Brian King, Thomas Gleixner, linuxppc-dev
In-Reply-To: <1287103733-7121-1-git-send-email-nacc@us.ibm.com>
On 14 October 2010 19:48, Nishanth Aravamudan <nacc@us.ibm.com> wrote:
> eeh and pci_dlpar #undef DEBUG, but I think they were added before the
> ability to control this from Kconfig. It's really annoying to only get
> some of the debug messages from these files. Leave the lpar.c #undef
> alone as it produces so much output as to make the kernel unusable.
> Update the Kconfig text to indicate this particular quirk :)
>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
OK, ignore my last email.
Acked by: Linas Vepstas <linasvepstas@gmail.com>
> --- a/arch/powerpc/platforms/pseries/Kconfig
> +++ b/arch/powerpc/platforms/pseries/Kconfig
> @@ -47,6 +47,12 @@ config LPARCFG
> =C2=A0config PPC_PSERIES_DEBUG
> =C2=A0 =C2=A0 =C2=A0 =C2=A0depends on PPC_PSERIES && PPC_EARLY_DEBUG
> =C2=A0 =C2=A0 =C2=A0 =C2=A0bool "Enable extra debug logging in platforms/=
pseries"
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0help
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 Say Y here if you want the pseries core to =
produce a bunch of
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 debug messages to the system log. Select th=
is if you are having a
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 problem with the pseries core and want to s=
ee more of what is
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 going on. This does not enable debugging in=
lpar.c, which must
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 be manually done due to its verbosity.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0default y
Umm, I see "default y" and you are not changing this but ... default y
?? Really?
Also, I am guessing that the lpar spam is due only to a handful of printk's=
,
while most of the rest will be infrequent. Just knock out the
high-frequency ones...
--linas
^ permalink raw reply
* RE: [PATCH 2/3 v4] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Zang Roy-R61911 @ 2010-10-15 2:15 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: dedekind1, Hu Mingkai-B21284, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <20101014110118.11fabed5@udp111988uds.am.freescale.net>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Friday, October 15, 2010 0:01 AM
> To: Zang Roy-R61911
> Cc: Wood Scott-B07421; Anton Vorontsov; linux-mtd@lists.infradead.org;
> dwmw2@infradead.org; dedekind1@gmail.com; akpm@linux-foundation.org;
Lan
> Chunhe-B25806; Gala Kumar-B11780; linuxppc-dev@ozlabs.org; Hu
Mingkai-B21284
> Subject: Re: [PATCH 2/3 v4] P4080/mtd: Only make elbc nand driver
detect nand
> flash partitions
>=20
> On Wed, 13 Oct 2010 20:09:02 -0700
> "Zang Roy-R61911" <r61911@freescale.com> wrote:
>=20
> > > > > > + struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl =3D NULL;
> > > > >
> > > > > No need for =3D NULL.
> > > > Any harm? Or just personal habit or style? Can you explain about
> > why?
> > >
> > > Besides not wanting superfluous code on general principle, it
could
> > > hide a bug if in the future the real initialization is missing on
some
> > > code path. It would become a runtime NULL dereference rather than
a
> > > compiler warning.
> >
> > Not exactly.
> > Per my understand, if the pointer will definitely be assigned in
code
> > path,
> > it is not necessary to init it when define. for example,
> >
> > char c;
> > char b;
> > char *a;
> > if (condition)
> > a =3D &c;
> > else
> > a =3D &b;
> > ...
> >
> > for other case, if the path will not ensure the pointer assignment,
it
> > will be inited
> > when define to avoid warning. for example,
> >
> > char c;
> > char *a =3D NULL;
> > if (condition)
> > a =3D &c;
> > ...
>=20
> Yes, but this patch looks like the former case, not the
> latter.=20
That is right.
> Is GCC giving a warning without the initializer?
no.
we are on the same point.
Thanks.
Roy
^ permalink raw reply
* Re: [PATCH v2] pseries: don't override CONFIG_PPC_PSERIES_DEBUG
From: Michael Ellerman @ 2010-10-15 4:01 UTC (permalink / raw)
To: linasvepstas
Cc: Frans Pop, linux-kernel, Paul Mackerras, Anton Blanchard,
Brian King, Nishanth Aravamudan, Thomas Gleixner, linuxppc-dev
In-Reply-To: <AANLkTinEzRpREFzDVhPS5ynqjYydHOs9iW5NM6W9Tf9A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2117 bytes --]
On Thu, 2010-10-14 at 20:54 -0500, Linas Vepstas wrote:
> On 14 October 2010 19:48, Nishanth Aravamudan <nacc@us.ibm.com> wrote:
> > eeh and pci_dlpar #undef DEBUG, but I think they were added before the
> > ability to control this from Kconfig. It's really annoying to only get
> > some of the debug messages from these files. Leave the lpar.c #undef
> > alone as it produces so much output as to make the kernel unusable.
> > Update the Kconfig text to indicate this particular quirk :)
> >
> > Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
>
> OK, ignore my last email.
>
> Acked by: Linas Vepstas <linasvepstas@gmail.com>
I guess I'll ack it too seeing I added PPC_PSERIES_DEBUG:
Acked-by: Michael Ellerman <michael@ellerman.id.au>
> > --- a/arch/powerpc/platforms/pseries/Kconfig
> > +++ b/arch/powerpc/platforms/pseries/Kconfig
> > @@ -47,6 +47,12 @@ config LPARCFG
> > config PPC_PSERIES_DEBUG
> > depends on PPC_PSERIES && PPC_EARLY_DEBUG
> > bool "Enable extra debug logging in platforms/pseries"
> > + help
> > + Say Y here if you want the pseries core to produce a bunch of
> > + debug messages to the system log. Select this if you are having a
> > + problem with the pseries core and want to see more of what is
> > + going on. This does not enable debugging in lpar.c, which must
> > + be manually done due to its verbosity.
> > default y
>
> Umm, I see "default y" and you are not changing this but ... default y
> ?? Really?
Yes, default y if early debug is enabled. Unlike DEBUG_KERNEL,
PPC_EARLY_DEBUG is a pretty good indication that you are doing some
kernel development - because you have to choose exactly which platform
you're working on.
> Also, I am guessing that the lpar spam is due only to a handful of printk's,
> while most of the rest will be infrequent. Just knock out the
> high-frequency ones...
No they're all related to the HPTE code, so you basically don't want any
of them enabled unless you're debugging that, and most people aren't.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] add icswx support v2
From: Tseng-Hui (Frank) Lin @ 2010-10-15 4:41 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <16640.1286931161@neuling.org>
On Wed, 2010-10-13 at 11:52 +1100, Michael Neuling wrote:
> In message <1286855108.14049.8.camel@flin.austin.ibm.com> you wrote:
> > icswx is a PowerPC co-processor instruction to send data to a
> > co-processor. On Book-S processors the LPAR_ID and process ID (PID) of
> > the owning process are registered in the window context of the
> > co-processor at initial time. When the icswx instruction is executed,
> > the L2 generates a cop-reg transaction on PowerBus. The transaction has
> > no address and the processor does not perform an MMU access to
> > authenticate the transaction. The coprocessor compares the LPAR_ID and
> > the PID included in the transaction and the LPAR_ID and PID held in the
> > window context to determine if the process is authorized to generate the
> > transaction.
> >
> > This patch adds icswx co-processor instruction support.
>
> Can you describe the ABI a bit?
>
> How has this changed from version 1?
>
The icswx instruction itself does nothing but generating a cop-req
transaction on PowerBus. The cop-req transaction causes 1 cache
line of data (128 bytes) sent to the co-processor. This provides
a low latency mechanism for sending small amount of data without
the co-processor becoming a master on the PowerBus.
Since the transaction has no address and the processor does not
perform an MMU access to authenticate the transaction, the
co-processor relys on the the LPAR_ID and PID to determine if
the process is authorized to generate the transaction.
The OS needs to assign a 16-bit PID for the process. This
cop-PID needs needs to be updated during context switch. The
cop-PID needs to be destroied when the context is destroied.
Change log from v1:
- Change 2'nd parameter of use_cop() from struct task_struct *task
to struct mm_struct *mm.
- Check for mm == current->active_mm before calling mtspr().
- Add a lock to guard acop related operations.
- Check for POWER7 CPU.
- Move the definition of SPRN_PID from reg_booke.h to avoid
defining SPRN_PID in two different files.
- Rename pid to acop_pid.
- Change function name disuse_cop() to drop_cop().
- Add a comment to describe the two new fields in mm_context_t.
- Moving CONFIG_ICSWX from arch/powerpc/platforms/pseries/Kconfig
to arch/powerpc/platforms/Kconfig.cputype
All other comments will be addressed in a new patch.
> Patch has been whitespace munged aswell.
>
> More comments below...
>
> >
> > Signed-off-by: Sonny Rao <sonnyrao@linux.vnet.ibm.com>
> > Signed-off-by: Tseng-Hui (Frank) Lin <thlin@linux.vnet.ibm.com>
> > ---
> > arch/powerpc/include/asm/mmu-hash64.h | 5 ++
> > arch/powerpc/include/asm/mmu_context.h | 6 ++
> > arch/powerpc/include/asm/reg.h | 12 ++++
> > arch/powerpc/include/asm/reg_booke.h | 3 -
> > arch/powerpc/mm/mmu_context_hash64.c | 105
> > ++++++++++++++++++++++++++++++++
> > arch/powerpc/platforms/Kconfig.cputype | 16 +++++
> > 6 files changed, 144 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/mmu-hash64.h
> > b/arch/powerpc/include/asm/mmu-hash64.h
> > index acac35d..6c1ab90 100644
> > --- a/arch/powerpc/include/asm/mmu-hash64.h
> > +++ b/arch/powerpc/include/asm/mmu-hash64.h
> > @@ -423,6 +423,11 @@ typedef struct {
> > #ifdef CONFIG_PPC_SUBPAGE_PROT
> > struct subpage_prot_table spt;
> > #endif /* CONFIG_PPC_SUBPAGE_PROT */
> > +#ifdef CONFIG_ICSWX
> > + unsigned long acop; /* mask of enabled coprocessor types */
> > +#define HASH64_MAX_PID (0xFFFF)
> > + unsigned int acop_pid; /* pid value used with coprocessors */
> > +#endif /* CONFIG_ICSWX */
> > } mm_context_t;
> >
> >
> > diff --git a/arch/powerpc/include/asm/mmu_context.h
> > b/arch/powerpc/include/asm/mmu_context.h
> > index 81fb412..88118de 100644
> > --- a/arch/powerpc/include/asm/mmu_context.h
> > +++ b/arch/powerpc/include/asm/mmu_context.h
> > @@ -80,6 +80,12 @@ static inline void switch_mm(struct mm_struct *prev,
> > struct mm_struct *next,
> >
> > #define deactivate_mm(tsk,mm) do { } while (0)
> >
> > +#ifdef CONFIG_ICSWX
> > +extern void switch_cop(struct mm_struct *next);
> > +extern int use_cop(unsigned long acop, struct mm_struct *mm);
> > +extern void drop_cop(unsigned long acop, struct mm_struct *mm);
> > +#endif /* CONFIG_ICSWX */
> > +
> > /*
> > * After we have set current->mm to a new value, this activates
> > * the context for the new mm so we see the new mappings.
> > diff --git a/arch/powerpc/include/asm/reg.h
> > b/arch/powerpc/include/asm/reg.h
> > index ff0005eec..9bbf178 100644
> > --- a/arch/powerpc/include/asm/reg.h
> > +++ b/arch/powerpc/include/asm/reg.h
> > @@ -170,8 +170,19 @@
> > #define SPEFSCR_FRMC 0x00000003 /* Embedded FP rounding mode co
> ntrol
> > */
> >
> > /* Special Purpose Registers (SPRNs)*/
> > +
> > +#ifdef CONFIG_40x
> > +#define SPRN_PID 0x3B1 /* Process ID */
> > +#else
> > +#define SPRN_PID 0x030 /* Process ID */
> > +#ifdef CONFIG_BOOKE
> > +#define SPRN_PID0 SPRN_PID/* Process ID Register 0 */
> > +#endif
> > +#endif
> > +
>
> Why are you moving these definitions?
>
> > #define SPRN_CTR 0x009 /* Count Register */
> > #define SPRN_DSCR 0x11
> > +#define SPRN_ACOP 0x1F /* Available Coprocessor Register */
> > #define SPRN_CTRLF 0x088
> > #define SPRN_CTRLT 0x098
> > #define CTRL_CT 0xc0000000 /* current thread */
> > @@ -879,6 +890,7 @@
> > #define PV_POWER5 0x003A
> > #define PV_POWER5p 0x003B
> > #define PV_970FX 0x003C
> > +#define PV_POWER7 0x003F
> > #define PV_630 0x0040
> > #define PV_630p 0x0041
> > #define PV_970MP 0x0044
> > diff --git a/arch/powerpc/include/asm/reg_booke.h
> > b/arch/powerpc/include/asm/reg_booke.h
> > index 667a498..5b0c781 100644
> > --- a/arch/powerpc/include/asm/reg_booke.h
> > +++ b/arch/powerpc/include/asm/reg_booke.h
> > @@ -150,8 +150,6 @@
> > * or IBM 40x.
> > */
> > #ifdef CONFIG_BOOKE
> > -#define SPRN_PID 0x030 /* Process ID */
> > -#define SPRN_PID0 SPRN_PID/* Process ID Register 0 */
> > #define SPRN_CSRR0 0x03A /* Critical Save and Restore Register 0 */
> > #define SPRN_CSRR1 0x03B /* Critical Save and Restore Register 1 */
> > #define SPRN_DEAR 0x03D /* Data Error Address Register */
> > @@ -168,7 +166,6 @@
> > #define SPRN_TCR 0x154 /* Timer Control Register */
> > #endif /* Book E */
> > #ifdef CONFIG_40x
> > -#define SPRN_PID 0x3B1 /* Process ID */
> > #define SPRN_DBCR1 0x3BD /* Debug Control Register 1 */
> > #define SPRN_ESR 0x3D4 /* Exception Syndrome Register */
> > #define SPRN_DEAR 0x3D5 /* Data Error Address Register */
> > diff --git a/arch/powerpc/mm/mmu_context_hash64.c
> > b/arch/powerpc/mm/mmu_context_hash64.c
> > index 2535828..8f432b6 100644
> > --- a/arch/powerpc/mm/mmu_context_hash64.c
> > +++ b/arch/powerpc/mm/mmu_context_hash64.c
> > @@ -18,6 +18,7 @@
> > #include <linux/mm.h>
> > #include <linux/spinlock.h>
> > #include <linux/idr.h>
> > +#include <linux/percpu.h>
> > #include <linux/module.h>
> > #include <linux/gfp.h>
> >
> > @@ -26,6 +27,103 @@
> > static DEFINE_SPINLOCK(mmu_context_lock);
> > static DEFINE_IDA(mmu_context_ida);
> >
> > +#ifdef CONFIG_ICSWX
> > +static DEFINE_SPINLOCK(mmu_context_acop_lock);
> > +static DEFINE_IDA(cop_ida);
> > +
> > +/* Lazy switch the ACOP register */
> > +static DEFINE_PER_CPU(unsigned long, acop_reg);
> > +
> > +void switch_cop(struct mm_struct *next)
> > +{
> > + if (!__is_processor(PV_POWER7))
> > + return;
> > +
> > + mtspr(SPRN_PID, next->context.acop_pid);
> > + if (next->context.acop_pid &&
> > + __get_cpu_var(acop_reg) != next->context.acop) {
> > + mtspr(SPRN_ACOP, next->context.acop);
> > + __get_cpu_var(acop_reg) = next->context.acop;
> > + }
> > +}
> > +EXPORT_SYMBOL(switch_cop);
> > +
> > +int use_cop(unsigned long acop, struct mm_struct *mm)
> > +{
> > + int acop_pid;
> > + int err;
> > +
> > + if (!__is_processor(PV_POWER7))
> > + return -ENOSYS;
>
> This should be a CPU feature.
>
> > +
> > + if (!mm)
> > + return -EINVAL;
> > +
> > + if (!mm->context.acop_pid) {
> > + if (!ida_pre_get(&cop_ida, GFP_KERNEL))
> > + return -ENOMEM;
> > +again:
> > + spin_lock(&mmu_context_acop_lock);
> > + err = ida_get_new_above(&cop_ida, 1, &acop_pid);
> > + spin_unlock(&mmu_context_acop_lock);
> > +
> > + if (err == -EAGAIN)
> > + goto again;
>
> Make this a do while loop. Please don't create your own loop
> prematives.
>
> > + else if (err)
> > + return err;
> > +
> > + if (acop_pid > HASH64_MAX_PID) {
> > + spin_lock(&mmu_context_acop_lock);
> > + ida_remove(&cop_ida, acop_pid);
> > + spin_unlock(&mmu_context_acop_lock);
> > + return -EBUSY;
> > + }
> > + mm->context.acop_pid = acop_pid;
> > + if (mm == current->active_mm)
> > + mtspr(SPRN_PID, mm->context.acop_pid);
> > + }
> > + spin_lock(&mmu_context_acop_lock);
> > + mm->context.acop |= acop;
> > + spin_unlock(&mmu_context_acop_lock);
> > +
> > + get_cpu_var(acop_reg) = mm->context.acop;
> > + if (mm == current->active_mm)
> > + mtspr(SPRN_ACOP, mm->context.acop);
> > + put_cpu_var(acop_reg);
> > +
> > + return mm->context.acop_pid;
> > +}
> > +EXPORT_SYMBOL(use_cop);
> > +
> > +void drop_cop(unsigned long acop, struct mm_struct *mm)
> > +{
> > + if (!__is_processor(PV_POWER7))
> > + return;
> > +
> > + if (WARN_ON(!mm))
> > + return;
> > +
> > + spin_lock(&mmu_context_acop_lock);
> > + mm->context.acop &= ~acop;
> > + spin_unlock(&mmu_context_acop_lock);
> > + if (!mm->context.acop) {
> > + spin_lock(&mmu_context_acop_lock);
> > + ida_remove(&cop_ida, mm->context.acop_pid);
> > + spin_unlock(&mmu_context_acop_lock);
> > + mm->context.acop_pid = 0;
> > + if (mm == current->active_mm)
> > + mtspr(SPRN_PID, mm->context.acop_pid);
> > + } else {
> > + get_cpu_var(acop_reg) = mm->context.acop;
> > + if (mm == current->active_mm)
> > + mtspr(SPRN_ACOP, mm->context.acop);
> > + put_cpu_var(acop_reg);
> > + }
> > + mmput(mm);
> > +}
> > +EXPORT_SYMBOL(drop_cop);
> > +#endif /* CONFIG_ICSWX */
> > +
> > /*
> > * The proto-VSID space has 2^35 - 1 segments available for user
> > mappings.
> > * Each segment contains 2^28 bytes. Each context maps 2^44 bytes,
> > @@ -93,6 +191,13 @@ EXPORT_SYMBOL_GPL(__destroy_context);
> >
> > void destroy_context(struct mm_struct *mm)
> > {
> > +#ifdef CONFIG_ICSWX
> > + if (mm->context.acop_pid) {
> > + spin_lock(&mmu_context_acop_lock);
> > + ida_remove(&cop_ida, mm->context.acop_pid);
> > + spin_unlock(&mmu_context_acop_lock);
> > + }
> > +#endif /* CONFIG_ICSWX */
>
> Can you put this in a destroy_context_acop() and #define that funtion
> based CONFIG_ICSWX. Cleans up the #ifdefs here
>
>
> > __destroy_context(mm->context.id);
> > subpage_prot_free(mm);
> > mm->context.id = NO_CONTEXT;
> > diff --git a/arch/powerpc/platforms/Kconfig.cputype
> > b/arch/powerpc/platforms/Kconfig.cputype
> > index d361f81..9674703 100644
> > --- a/arch/powerpc/platforms/Kconfig.cputype
> > +++ b/arch/powerpc/platforms/Kconfig.cputype
> > @@ -220,6 +220,22 @@ config VSX
> >
> > If in doubt, say Y here.
> >
> > +config ICSWX
> > + bool "Support for PowerPC icswx co-processor instruction"
> > + depends on POWER4
> > + default n
> > + ---help---
> > +
> > + Enabling this option to turn on the PowerPC icswx co-processor
> > + instruction support for POWER7 processors.
> > + This option is only useful if you have a processor that supports
> > + icswx co-processor instruction. It does not have any affect on
> > + processors without icswx co-processor instruction.
> > +
> > + This support slightly increases kernel memory usage.
> > +
> > + Say N if you do not have a POWER7 processor and a PowerPC
> > co-processor.
> > +
> > config SPE
> > bool "SPE Support"
> > depends on E200 || (E500 && !PPC_E500MC)
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* RE: [PATCH 1/3 v4] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Zang Roy-R61911 @ 2010-10-15 5:03 UTC (permalink / raw)
To: Wood Scott-B07421, Anton Vorontsov
Cc: dedekind1, Lan Chunhe-B25806, linuxppc-dev, linux-mtd, akpm,
dwmw2, Gala Kumar-B11780
In-Reply-To: <20101014110239.466072be@udp111988uds.am.freescale.net>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Friday, October 15, 2010 0:03 AM
> To: Zang Roy-R61911
> Cc: Anton Vorontsov; linux-mtd@lists.infradead.org;
dwmw2@infradead.org;
> dedekind1@gmail.com; akpm@linux-foundation.org; Lan Chunhe-B25806;
Wood Scott-
> B07421; Gala Kumar-B11780; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 1/3 v4] P4080/eLBC: Make Freescale elbc interrupt
common
> to elbc devices
>=20
> On Wed, 13 Oct 2010 23:43:38 -0700
> "Zang Roy-R61911" <r61911@freescale.com> wrote:
>=20
> > > Plus, I think the patch is not runtime bisectable (i.e. you
> > > now do request_irq() here, but not removing it from the nand
> > > driver, so nand will fail to probe).
> > Nand driver does not need to request irq. It will use the irq
requested by
> lbc.
> > remember, other lbc device may also need to use this registered irq.
> > It should not be removed in nand driver.
>=20
> The point is that you need to make both changes in the same patch.
But according to previous discussion, if lbc driver is registered
successful, it will not be removed. (.remove function is dropped in the
patch). that is not bisectable?
nand driver will not touch the irq. all irq status process is in the lbc
driver.
Thanks.
Roy
^ permalink raw reply
* [PATCH] mxc_udc: add workaround for ENGcm09152 for i.MX35
From: Eric Bénard @ 2010-10-15 12:30 UTC (permalink / raw)
To: linux-usb
Cc: dbrownell, Dinh.Nguyen, gregkh, linux-kernel, linuxppc-dev,
linux-arm-kernel
this patch gives the possibility to workaround bug ENGcm09152
on i.MX35 when the hardware workaround is also implemented on
the board.
It covers the workaround described on page 25 of the following Errata :
http://cache.freescale.com/files/dsp/doc/errata/IMX35CE.pdf
Signed-off-by: Eric Bénard <eric@eukrea.com>
---
arch/arm/mach-mx3/mach-cpuimx35.c | 1 +
drivers/usb/gadget/fsl_mxc_udc.c | 15 +++++++++++++++
include/linux/fsl_devices.h | 3 +++
3 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx3/mach-cpuimx35.c b/arch/arm/mach-mx3/mach-cpuimx35.c
index 6024bb9..a95ff79 100644
--- a/arch/arm/mach-mx3/mach-cpuimx35.c
+++ b/arch/arm/mach-mx3/mach-cpuimx35.c
@@ -132,6 +132,7 @@ static struct mxc_usbh_platform_data __maybe_unused usbh1_pdata = {
static struct fsl_usb2_platform_data otg_device_pdata = {
.operating_mode = FSL_USB2_DR_DEVICE,
.phy_mode = FSL_USB2_PHY_UTMI,
+ .workaround = FLS_USB2_WORKAROUND_ENGCM09152,
};
static int otg_mode_host;
diff --git a/drivers/usb/gadget/fsl_mxc_udc.c b/drivers/usb/gadget/fsl_mxc_udc.c
index eafa6d2..5bdbfe6 100644
--- a/drivers/usb/gadget/fsl_mxc_udc.c
+++ b/drivers/usb/gadget/fsl_mxc_udc.c
@@ -22,6 +22,10 @@
static struct clk *mxc_ahb_clk;
static struct clk *mxc_usb_clk;
+/* workaround ENGcm09152 for i.MX35 */
+#define USBPHYCTRL_OTGBASE_OFFSET 0x608
+#define USBPHYCTRL_EVDO (1 << 23)
+
int fsl_udc_clk_init(struct platform_device *pdev)
{
struct fsl_usb2_platform_data *pdata;
@@ -84,6 +88,17 @@ eenahb:
void fsl_udc_clk_finalize(struct platform_device *pdev)
{
struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
+#if defined(CONFIG_ARCH_MX35)
+ unsigned int v;
+
+ /* workaround ENGcm09152 for i.MX35 */
+ if (pdata->workaround & FLS_USB2_WORKAROUND_ENGCM09152) {
+ v = readl(MX35_IO_ADDRESS(MX35_OTG_BASE_ADDR +
+ USBPHYCTRL_OTGBASE_OFFSET));
+ writel(v | USBPHYCTRL_EVDO, MX35_IO_ADDRESS(MX35_OTG_BASE_ADDR +
+ USBPHYCTRL_OTGBASE_OFFSET));
+ }
+#endif
/* ULPI transceivers don't need usbpll */
if (pdata->phy_mode == FSL_USB2_PHY_ULPI) {
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index 28e33fe..01a23fa 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -63,12 +63,15 @@ struct fsl_usb2_platform_data {
enum fsl_usb2_operating_modes operating_mode;
enum fsl_usb2_phy_modes phy_mode;
unsigned int port_enables;
+ unsigned int workaround;
};
/* Flags in fsl_usb2_mph_platform_data */
#define FSL_USB2_PORT0_ENABLED 0x00000001
#define FSL_USB2_PORT1_ENABLED 0x00000002
+#define FLS_USB2_WORKAROUND_ENGCM09152 (1 << 0)
+
struct spi_device;
struct fsl_spi_platform_data {
--
1.7.0.4
^ permalink raw reply related
* [RFC PATCH v3] 476: Set CCR2[DSTI] to prevent isync from flushing shadow TLB
From: Dave Kleikamp @ 2010-10-15 17:33 UTC (permalink / raw)
To: Josh Boyer, Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Dave Kleikamp
Josh, don't pick this up yet. It needs a bit more testing, but I think I
got it right this time.
When the DSTI (Disable Shadow TLB Invalidate) bit is set in the CCR2
register, the isync command does not flush the shadow TLB (iTLB & dTLB).
However, since the shadow TLB does not contain context information, we
want the shadow TLB flushed in situations where we are switching context.
In those situations, we explicitly clear the DSTI bit before performing
isync, and set it again afterward. We also need to do the same when we
perform isync after explicitly flushing the TLB.
The 476 requires an isync following a write to certain SPRs in order for
their changes to be effective. Such is the case with the DSTI bit, so
the first isync may not be affected by an immediate change to CCR2, but
a second isync instruction will repect the setting.
Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/reg_booke.h | 4 ++++
arch/powerpc/kernel/head_44x.S | 28 ++++++++++++++++++++++++++++
arch/powerpc/mm/tlb_nohash_low.S | 24 +++++++++++++++++++++++-
arch/powerpc/platforms/44x/misc_44x.S | 28 ++++++++++++++++++++++++++++
4 files changed, 83 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h
index 667a498..a7ecbfe 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -120,6 +120,7 @@
#define SPRN_TLB3CFG 0x2B3 /* TLB 3 Config Register */
#define SPRN_EPR 0x2BE /* External Proxy Register */
#define SPRN_CCR1 0x378 /* Core Configuration Register 1 */
+#define SPRN_CCR2_476 0x379 /* Core Configuration Register 2 (476)*/
#define SPRN_ZPR 0x3B0 /* Zone Protection Register (40x) */
#define SPRN_MAS7 0x3B0 /* MMU Assist Register 7 */
#define SPRN_MMUCR 0x3B2 /* MMU Control Register */
@@ -188,6 +189,9 @@
#define CCR1_DPC 0x00000100 /* Disable L1 I-Cache/D-Cache parity checking */
#define CCR1_TCS 0x00000080 /* Timer Clock Select */
+/* Bit definitions for CCR2. */
+#define CCR2_476_DSTI 0x08000000 /* Disable Shadow TLB Invalidate */
+
/* Bit definitions for the MCSR. */
#define MCSR_MCS 0x80000000 /* Machine Check Summary */
#define MCSR_IB 0x40000000 /* Instruction PLB Error */
diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
index 562305b..df1ef80 100644
--- a/arch/powerpc/kernel/head_44x.S
+++ b/arch/powerpc/kernel/head_44x.S
@@ -38,6 +38,7 @@
#include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
#include <asm/synch.h>
+#include <asm/bug.h>
#include "head_booke.h"
@@ -703,8 +704,29 @@ _GLOBAL(set_context)
stw r4, 0x4(r5)
#endif
mtspr SPRN_PID,r3
+BEGIN_MMU_FTR_SECTION
+ b 1f
+END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x)
isync /* Force context change */
blr
+1:
+#ifdef CONFIG_PPC_47x
+ mfspr r10,SPRN_CCR2_476
+ rlwinm r11,r10,0,~CCR2_476_DSTI
+ mtspr SPRN_CCR2_476,r11
+ /*
+ * The first isync may not respect the change to CCR2, but its
+ * completion will ensure that the second isync does.
+ */
+ isync
+ isync /* Force context change */
+ mtspr SPRN_CCR2_476,r10
+ isync
+#else /* CONFIG_PPC_47x */
+2: trap
+ EMIT_BUG_ENTRY 2b,__FILE__,__LINE__,0;
+#endif /* CONFIG_PPC_47x */
+ blr
/*
* Init CPU state. This is called at boot time or for secondary CPUs
@@ -1083,6 +1105,12 @@ clear_utlb_entry:
isync
#endif /* CONFIG_PPC_EARLY_DEBUG_44x */
+ mfspr r3,SPRN_CCR2_476
+ /* With CCR2(DSTI) set, isync does not invalidate the shadow TLB */
+ oris r3,r3,CCR2_476_DSTI@h
+ mtspr SPRN_CCR2_476,r3
+ isync
+
/* Establish the interrupt vector offsets */
SET_IVOR(0, CriticalInput);
SET_IVOR(1, MachineCheckA);
diff --git a/arch/powerpc/mm/tlb_nohash_low.S b/arch/powerpc/mm/tlb_nohash_low.S
index b9d9fed..8e318ed 100644
--- a/arch/powerpc/mm/tlb_nohash_low.S
+++ b/arch/powerpc/mm/tlb_nohash_low.S
@@ -112,6 +112,16 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x)
clrrwi r4,r3,12 /* get an EPN for the hashing with V = 0 */
ori r4,r4,PPC47x_TLBE_SIZE
tlbwe r4,r7,0 /* write it */
+ mfspr r8,SPRN_CCR2_476
+ rlwinm r9,r8,0,~CCR2_476_DSTI
+ mtspr SPRN_CCR2_476,r9
+ /*
+ * The first isync may not respect the change to CCR2, but its
+ * completion will ensure that the second isync does.
+ */
+ isync
+ isync
+ mtspr SPRN_CCR2_476,r8
isync
wrtee r10
blr
@@ -180,7 +190,13 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x)
lwz r8,0(r10) /* Load boltmap entry */
addi r10,r10,4 /* Next word */
b 1b /* Then loop */
-1: isync /* Sync shadows */
+1: mfspr r9,SPRN_CCR2_476
+ rlwinm r10,r9,0,~CCR2_476_DSTI
+ mtspr SPRN_CCR2_476,r10
+ isync
+ isync /* Sync shadows */
+ mtspr SPRN_CCR2_476,r9
+ isync
wrtee r11
#else /* CONFIG_PPC_47x */
1: trap
@@ -203,6 +219,12 @@ _GLOBAL(_tlbivax_bcast)
isync
/* tlbivax 0,r3 - use .long to avoid binutils deps */
.long 0x7c000624 | (r3 << 11)
+ mfspr r8,SPRN_CCR2_476
+ rlwinm r9,r8,0,~CCR2_476_DSTI
+ mtspr SPRN_CCR2_476,r9
+ isync
+ isync
+ mtspr SPRN_CCR2_476,r8
isync
eieio
tlbsync
diff --git a/arch/powerpc/platforms/44x/misc_44x.S b/arch/powerpc/platforms/44x/misc_44x.S
index dc12b80..2422dd3 100644
--- a/arch/powerpc/platforms/44x/misc_44x.S
+++ b/arch/powerpc/platforms/44x/misc_44x.S
@@ -9,15 +9,40 @@
*
*/
+#include <asm/mmu.h>
#include <asm/reg.h>
#include <asm/ppc_asm.h>
.text
+#ifdef CONFIG_PPC_47x
+
+#define LOAD_CLEAR_CCR2_DSTI(REG1, REG2) \
+BEGIN_MMU_FTR_SECTION \
+ mfspr REG1,SPRN_CCR2_476; \
+ rlwinm REG2,REG1,0,~CCR2_476_DSTI; \
+ mtspr SPRN_CCR2_476,REG2; \
+ isync; \
+END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x)
+
+#define RESTORE_CCR2_DSTI(REG) \
+BEGIN_MMU_FTR_SECTION \
+ mtspr SPRN_CCR2_476,REG; \
+ isync; \
+END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x)
+
+#else /* CONFIG_PPC_47x */
+
+#define LOAD_CLEAR_CCR2_DSTI(REG1, REG2)
+#define RESTORE_CCR2_DSTI(REG)
+
+#endif /* CONFIG_PPC_47x */
+
/*
* Do an IO access in AS1
*/
_GLOBAL(as1_readb)
+ LOAD_CLEAR_CCR2_DSTI(r8, r9)
mfmsr r7
ori r0,r7,MSR_DS
sync
@@ -29,9 +54,11 @@ _GLOBAL(as1_readb)
mtmsr r7
sync
isync
+ RESTORE_CCR2_DSTI(r8)
blr
_GLOBAL(as1_writeb)
+ LOAD_CLEAR_CCR2_DSTI(r8, r9)
mfmsr r7
ori r0,r7,MSR_DS
sync
@@ -43,4 +70,5 @@ _GLOBAL(as1_writeb)
mtmsr r7
sync
isync
+ RESTORE_CCR2_DSTI(r8)
blr
--
1.7.2.2
^ permalink raw reply related
* Re: Possible kernel stack overflow due to fast interrupts
From: Rick Tao @ 2010-10-15 19:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1287100633.2205.80.camel@pasglop>
You are exactly right! Ensuring interrupts would not cause more preemptions=
. =0AThanks for pointing it out.=0ARick=0A=0A--- On Thu, 10/14/10, Benjamin=
Herrenschmidt <benh@kernel.crashing.org> wrote:=0A=0A> From: Benjamin Herr=
enschmidt <benh@kernel.crashing.org>=0A> Subject: Re: Possible kernel stack=
overflow due to fast interrupts=0A> To: "Rick Tao" <tao_rick@yahoo.com>=0A=
> Cc: linuxppc-dev@lists.ozlabs.org=0A> Date: Thursday, October 14, 2010, 4=
:57 PM=0A> On Thu, 2010-10-14 at 13:45 -0700,=0A> Rick Tao wrote:=0A> > Hi,=
all,=0A> =0A> .../...=0A> =0A> > In the context of task A=0A> > a. NIP wo=
uld point to the instruction after=0A> switch_to(). =0A> > b. MSR_EE is ena=
bled in the call trace=0A> (finish_task_switch=0A> -->finish_lock_switch-->=
spin_unlock_irq)=0A> > c. do something that would trigger an interrupt late=
r=0A> on (such as timer)=0A> > d. call schedule() for context switch to tas=
k B.=0A> >=A0 =A0 In this step, =0A> >=A0 =A0 =A0 task B's stack is popped=
=0A> INT_FRAME_SIZE size for context restore.=A0 =0A> >=A0 =A0 Note that ta=
sk B's ksp =3D X -=0A> INT_FRAME_SIZE=0A> > =0A> > In the context of task B=
again=0A> > a1. similar to step "a" above=0A> >=0A> > b1. similar to step =
"b" above =0A> > c1. interrupt occurs, go to step "1" above, and=0A> repeat=
!!!=0A> > =0A> > As you can see, task B's kernel stack space is reduced=0A>=
by INT_FRAME_SIZE=0A> > on each loop. It will eventually overflow.=0A> =0A=
> So if I follow you correctly, you are worried that by the=0A> time execut=
ion=0A> resumes in B, and before it pops the second frame off, it=0A> might=
get=0A> another interrupt and re-preempt...=0A> =0A> Now unless I missed s=
omething, that cannot happen because=0A> preempt_schedule_irq() does increm=
ent the preempt count:=0A> =0A> =A0=A0=A0 add_preempt_count(PREEMPT_ACTIVE)=
;=0A> =A0=A0=A0 local_irq_enable();=0A> =A0=A0=A0 schedule();=0A> =A0=A0=A0=
local_irq_disable();=0A> =A0=A0=A0 sub_preempt_count(PREEMPT_ACTIVE);=0A> =
=0A> Which means that it won't preempt again in=0A> finish_task_switch, and=
so=0A> will eventually come back, turn EE back off, and pop off=0A> the st=
ack=0A> frame.=0A> =0A> Or am I missing something ?=0A> =0A> Cheers,=0A> Be=
n.=0A> =0A> =0A> _______________________________________________=0A> Linuxp=
pc-dev mailing list=0A> Linuxppc-dev@lists.ozlabs.org=0A> https://lists.ozl=
abs.org/listinfo/linuxppc-dev=0A> =0A=0A=0A
^ permalink raw reply
* Re: [PATCH] mxc_udc: add workaround for ENGcm09152 for i.MX35
From: Greg KH @ 2010-10-15 19:10 UTC (permalink / raw)
To: Eric Bénard
Cc: dbrownell, Dinh.Nguyen, linux-usb, linux-kernel, linuxppc-dev,
gregkh, linux-arm-kernel
In-Reply-To: <1287145858-10239-1-git-send-email-eric@eukrea.com>
On Fri, Oct 15, 2010 at 02:30:58PM +0200, Eric Bénard wrote:
> this patch gives the possibility to workaround bug ENGcm09152
> on i.MX35 when the hardware workaround is also implemented on
> the board.
> It covers the workaround described on page 25 of the following Errata :
> http://cache.freescale.com/files/dsp/doc/errata/IMX35CE.pdf
>
> Signed-off-by: Eric Bénard <eric@eukrea.com>
> ---
> arch/arm/mach-mx3/mach-cpuimx35.c | 1 +
> drivers/usb/gadget/fsl_mxc_udc.c | 15 +++++++++++++++
> include/linux/fsl_devices.h | 3 +++
> 3 files changed, 19 insertions(+), 0 deletions(-)
Do you want me to take this through my usb tree, or will it go through
some other developer's tree?
Either is fine with me.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] mxc_udc: add workaround for ENGcm09152 for i.MX35
From: Eric Bénard @ 2010-10-15 19:24 UTC (permalink / raw)
To: Greg KH
Cc: dbrownell, Dinh.Nguyen, linux-usb, linux-kernel, linuxppc-dev,
gregkh, linux-arm-kernel
In-Reply-To: <20101015191005.GB8098@kroah.com>
Hi Greg,
Le 15/10/2010 21:10, Greg KH a écrit :
> On Fri, Oct 15, 2010 at 02:30:58PM +0200, Eric Bénard wrote:
>> this patch gives the possibility to workaround bug ENGcm09152
>> on i.MX35 when the hardware workaround is also implemented on
>> the board.
>> It covers the workaround described on page 25 of the following Errata :
>> http://cache.freescale.com/files/dsp/doc/errata/IMX35CE.pdf
>>
>> Signed-off-by: Eric Bénard<eric@eukrea.com>
>> ---
>> arch/arm/mach-mx3/mach-cpuimx35.c | 1 +
>> drivers/usb/gadget/fsl_mxc_udc.c | 15 +++++++++++++++
>> include/linux/fsl_devices.h | 3 +++
>> 3 files changed, 19 insertions(+), 0 deletions(-)
>
> Do you want me to take this through my usb tree, or will it go through
> some other developer's tree?
>
as most of the changes are in drivers/usb that would be great if you can take it.
Thanks
Eric
^ permalink raw reply
* [PATCH] Drivers: ps3: Makefile: replace the use of <module>-objs with <module>-y
From: Tracey Dent @ 2010-10-16 3:30 UTC (permalink / raw)
To: geoff; +Cc: Tracey Dent, linuxppc-dev, linux-kernel
Changed <module>-objs to <module>-y in Makefile.
Signed-off-by: Tracey Dent <tdent48227@gmail.com>
---
drivers/ps3/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/ps3/Makefile b/drivers/ps3/Makefile
index ccea15c..50cb1e1 100644
--- a/drivers/ps3/Makefile
+++ b/drivers/ps3/Makefile
@@ -1,6 +1,6 @@
obj-$(CONFIG_PS3_VUART) += ps3-vuart.o
obj-$(CONFIG_PS3_PS3AV) += ps3av_mod.o
-ps3av_mod-objs += ps3av.o ps3av_cmd.o
+ps3av_mod-y := ps3av.o ps3av_cmd.o
obj-$(CONFIG_PPC_PS3) += sys-manager-core.o
obj-$(CONFIG_PS3_SYS_MANAGER) += ps3-sys-manager.o
obj-$(CONFIG_PS3_STORAGE) += ps3stor_lib.o
--
1.7.3.1.104.gc752e
^ permalink raw reply related
* Re: [PATCH] powerpc/5121: pdm360ng: fix touch irq if 8xxx gpio driver is enabled
From: Grant Likely @ 2010-10-16 3:52 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <20101014165549.473d71ab@wker>
On Thu, Oct 14, 2010 at 04:55:49PM +0200, Anatolij Gustschin wrote:
> Hi Grant,
>
> On Wed, 15 Sep 2010 22:12:57 +0200
> Anatolij Gustschin <agust@denx.de> wrote:
>
> > Enabling the MPC8xxx GPIO driver with MPC512x GPIO extension
> > breaks touch screen support on this board since the GPIO
> > interrupt will be mapped to 8xxx GPIO irq host resulting in
> > a not requestable interrupt in the touch screen driver. Fix
> > it by mapping the touch interrupt on 8xxx GPIO irq host.
> >
> > Signed-off-by: Anatolij Gustschin <agust@denx.de>
> > ---
> > arch/powerpc/platforms/512x/pdm360ng.c | 26 ++++++++++++++++++++++----
> > 1 files changed, 22 insertions(+), 4 deletions(-)
>
> Can this patch go in for 2.6.37 ?
I hope so, but I haven't looked at it properly yet and I'm trying to
dig myself out of a patch backlog.
g.
^ permalink raw reply
* 64K PAGE_SIZE and arch/powerpc/kernel/vdso.c
From: Nicholas A. Bellinger @ 2010-10-16 8:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Brian King
Greetings Linux-ppc64 folks,
While trying to compile v2.6.36-rc8 with PAGE_SIZE=65536 I run into the
following compile failure w/ strict checking on a RHEL5.4 / gcc (GCC)
4.1.2 20080704 (Red Hat 4.1.2-46) system:
cc1: warnings being treated as errors
arch/powerpc/kernel/vdso.c:81: warning: alignment of ‘vdso_data_store’
is greater than maximum object file alignment. Using 32768
CC arch/powerpc/sysdev/msi_bitmap.o
make[1]: *** [arch/powerpc/kernel/vdso.o] Error 1
make[1]: *** Waiting for unfinished jobs....
Any ideas folks..?
TIA,
--nab
^ permalink raw reply
* Help about chip select on SPI slave devices
From: WANG YiFei @ 2010-10-16 10:35 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <BAY158-ds2BEE228C7E27E7CE0C28BF5550@phx.gbl>
Hi,
We have a board which has 1 SPI master controller and 4 SPI slave =
devices, and we'd like to use 2 GPIOs to demux to chip select these =
slave devices.
Can anyone tell me if current powerpc dts support demuxer for chip =
select for spi slave devices? So far as I know, in dts, SPI master can =
only use 1 to 1 GPIO to CS(then needs 4 GPIOs).
Thanks in advance,
YiFei
^ 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