* Re: UBIFS problem on MPC8536DS
From: Scott Wood @ 2009-10-19 19:47 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org
In-Reply-To: <4ADCC08D.5080207@embedded-sol.com>
Felix Radensky wrote:
> OK, no problem. I just wanted to get an idea of what should be done.
> Should the NOR code poll some eLBC register to wait for completion of
> NAND special operation ? Can you tell what register is relevant ?
I was thinking you'd just share a mutex with the NAND code.
-Scott
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Felix Radensky @ 2009-10-19 20:19 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org
In-Reply-To: <4ADCC247.6080107@freescale.com>
Scott Wood wrote:
> Felix Radensky wrote:
>> OK, no problem. I just wanted to get an idea of what should be done.
>> Should the NOR code poll some eLBC register to wait for completion of
>> NAND special operation ? Can you tell what register is relevant ?
>
> I was thinking you'd just share a mutex with the NAND code.
Thanks. Do I understand correctly that in fsl_ebc_nand.c this mutex should
protect the execution of special operation and wait for completion in
fsl_elbc_run_command() routine ?
Felix.
^ permalink raw reply
* Re: linux-next: tree build failure
From: Rusty Russell @ 2009-10-20 1:12 UTC (permalink / raw)
To: Hollis Blanchard
Cc: sfr, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm,
linuxppc-dev
In-Reply-To: <1255976369.13995.98.camel@slab.beaverton.ibm.com>
On Tue, 20 Oct 2009 04:49:29 am Hollis Blanchard wrote:
> On Thu, 2009-10-15 at 08:27 +0100, Jan Beulich wrote:
> > My perspective is that it just uncovered already existing brokenness.
>
> Sorry, I thought it was clear, but to be more explicit: I propose the
> following patch, which replaces the current BUILD_BUG_ON implementation
> with Rusty's version.
OK, I switched my brain back on. Yeah, I agree: we may still want
BUILD_OR_RUNTIME_BUG_ON one day, but I like this.
It's just missing the giant comment that it needs :)
/**
* BUILD_BUG_ON - break compile if a condition is true.
* @cond: the condition which the compiler should know is false.
*
* If you have some code which relies on certain constants being equal, or
* other compile-time-evaluated condition, you should use BUILD_BUG_ON to
* detect if someone changes it.
*
* The implementation uses gcc's reluctance to create a negative array, but
* gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments
* to inline functions). So as a fallback we use the optimizer; if it can't
* prove the condition is false, it will cause a link error on the undefined
* "__build_bug_on_failed". This error is less neat, and can be harder to
* track down.
*/
Thanks!
Rusty.
^ permalink raw reply
* Re: linux-next: tree build failure
From: Hollis Blanchard @ 2009-10-20 1:29 UTC (permalink / raw)
To: Rusty Russell
Cc: sfr, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm,
linuxppc-dev
In-Reply-To: <200910201142.34006.rusty@rustcorp.com.au>
On Tue, 2009-10-20 at 11:42 +1030, Rusty Russell wrote:
> On Tue, 20 Oct 2009 04:49:29 am Hollis Blanchard wrote:
> > On Thu, 2009-10-15 at 08:27 +0100, Jan Beulich wrote:
> > > My perspective is that it just uncovered already existing brokenness.
> >
> > Sorry, I thought it was clear, but to be more explicit: I propose the
> > following patch, which replaces the current BUILD_BUG_ON implementation
> > with Rusty's version.
>
> OK, I switched my brain back on. Yeah, I agree: we may still want
> BUILD_OR_RUNTIME_BUG_ON one day, but I like this.
>
> It's just missing the giant comment that it needs :)
>
> /**
> * BUILD_BUG_ON - break compile if a condition is true.
> * @cond: the condition which the compiler should know is false.
> *
> * If you have some code which relies on certain constants being equal, or
> * other compile-time-evaluated condition, you should use BUILD_BUG_ON to
> * detect if someone changes it.
> *
> * The implementation uses gcc's reluctance to create a negative array, but
> * gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments
> * to inline functions). So as a fallback we use the optimizer; if it can't
> * prove the condition is false, it will cause a link error on the undefined
> * "__build_bug_on_failed". This error is less neat, and can be harder to
> * track down.
> */
Do you want to put together a signed-off patch Rusty? It's your code, so
I don't feel comfortable doing that.
Once we have that, can we remove the mysterious MAYBE_BUILD_BUG_ON
statements introduced in previous patches? (Does it BUG or doesn't it??)
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* [PATCH] BUILD_BUG_ON: make it handle more cases
From: Rusty Russell @ 2009-10-20 3:45 UTC (permalink / raw)
To: Hollis Blanchard
Cc: sfr, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm,
linuxppc-dev
In-Reply-To: <1256002193.6546.2.camel@slab>
BUILD_BUG_ON used to use the optimizer to do code elimination or fail
at link time; it was changed to first the size of a negative array (a
nicer compile time error), then (in
8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield.
bitfields: needs a literal constant at parse time, and can't be put under
"if (__builtin_constant_p(x))" for example.
negative array: can handle anything, but if the compiler can't tell it's
a constant, silently has no effect.
link time: breaks link if the compiler can't determine the value, but the
linker output is not usually as informative as a compiler error.
If we use the negative-array-size method *and* the link time trick,
we get the ability to use BUILD_BUG_ON() under __builtin_constant_p()
branches, and maximal ability for the compiler to detect errors at
build time.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -683,12 +683,6 @@ struct sysinfo {
char _f[20-2*sizeof(long)-sizeof(int)]; /* Padding: libc5 uses this.. */
};
-/* Force a compilation error if condition is true */
-#define BUILD_BUG_ON(condition) ((void)BUILD_BUG_ON_ZERO(condition))
-
-/* Force a compilation error if condition is constant and true */
-#define MAYBE_BUILD_BUG_ON(cond) ((void)sizeof(char[1 - 2 * !!(cond)]))
-
/* Force a compilation error if condition is true, but also produce a
result (of value 0 and type size_t), so the expression can be used
e.g. in a structure initializer (or where-ever else comma expressions
@@ -696,6 +690,33 @@ struct sysinfo {
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
#define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:-!!(e); }))
+/**
+ * BUILD_BUG_ON - break compile if a condition is true.
+ * @cond: the condition which the compiler should know is false.
+ *
+ * If you have some code which relies on certain constants being equal, or
+ * other compile-time-evaluated condition, you should use BUILD_BUG_ON to
+ * detect if someone changes it.
+ *
+ * The implementation uses gcc's reluctance to create a negative array, but
+ * gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments
+ * to inline functions). So as a fallback we use the optimizer; if it can't
+ * prove the condition is false, it will cause a link error on the undefined
+ * "__build_bug_on_failed". This error message can be harder to track down
+ * though, hence the two different methods.
+ */
+#ifndef __OPTIMIZE__
+#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
+#else
+extern int __build_bug_on_failed;
+#define BUILD_BUG_ON(condition) \
+ do { \
+ ((void)sizeof(char[1 - 2*!!(condition)])); \
+ if (condition) __build_bug_on_failed = 1; \
+ } while(0)
+#endif
+#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition)
+
/* Trap pasters of __FUNCTION__ at compile-time */
#define __FUNCTION__ (__func__)
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: perf_event: Hide iseries_check_pending_irqs
From: Anton Blanchard @ 2009-10-20 3:50 UTC (permalink / raw)
To: Ingo Molnar; +Cc: paulus, a.p.zijlstra, linuxppc-dev
In-Reply-To: <20091019072334.GA17960@elte.hu>
Hi Ingo,
> Just to confirm - these 3 symbol fixes are for the PowerPC tree, not for
> the perf events tree, right? There's nothing perf specific about the
> fixes - kgdb, systemtap and other debugging/instrumentation frameworks
> will benefit from more precise symbol generation too.
Yeah, while they were written to fix perf backtrace issues they are
definitely not perf specific. Hopefully Ben will queue them up in his
tree for the next merge window :)
Anton
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: perf_event: Hide iseries_check_pending_irqs
From: Benjamin Herrenschmidt @ 2009-10-20 4:12 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev, Ingo Molnar, paulus, a.p.zijlstra
In-Reply-To: <20091020035058.GU4808@kryten>
On Tue, 2009-10-20 at 14:50 +1100, Anton Blanchard wrote:
> Hi Ingo,
>
> > Just to confirm - these 3 symbol fixes are for the PowerPC tree, not for
> > the perf events tree, right? There's nothing perf specific about the
> > fixes - kgdb, systemtap and other debugging/instrumentation frameworks
> > will benefit from more precise symbol generation too.
>
> Yeah, while they were written to fix perf backtrace issues they are
> definitely not perf specific. Hopefully Ben will queue them up in his
> tree for the next merge window :)
Right, I'm overdue for a powerpc-next but with some family issues last
couple of week and KS/JLS this week, it' a bit hard :-)
Ben.
^ permalink raw reply
* RE: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Richard Cochran @ 2009-10-20 10:01 UTC (permalink / raw)
To: 'Scott Wood'; +Cc: 'linuxppc-dev@lists.ozlabs.org'
In-Reply-To: <20091016160125.GC11838@loki.buserror.net>
> -----Original Message-----
> From: Scott Wood [mailto:scottwood@freescale.com]
>
> What problems have you been having with upstream kernels on mpc8313erdb,
> other than this IRQ issue? It should work, though the BSP may have extra
> features that haven't been pushed upstream.
I have been working from kernel 2.6.30 (although the very latest
kernel is just the same WRT these problems, AFAICT). I had to patch in
order to sovle the following three problems:
1. The flash layout in the DTS does not match the default partitioning
from Freescale. In the current dts, the NAND partitioning is wrong,
and there is no partitioning for the NOR flash given.
2. The eTSEC interrupt issue that started this thread.
3. The PTP IO signals are not configured in a vanilla linux. For this,
you need parts of a Freescale patch. [1] Their PTP implementation
gianfar driver is horrible, but still, the IO configuration in
these two files in the patch is necessary to get any external
signals from the PTP clock:
arch/powerpc/platforms/83xx/mpc8313_rdb.c
arch/powerpc/platforms/83xx/mpc83xx.h
It may be that point 1 is not so important, since the flash layout is
perhaps a very personal thing, but I would still expect the default
dts to match the default partitioning from Freescale.
Point 2 is obviously essential, and if you buy the mpc8313 for its PTP
capabilities, as I did, then point 3 is a show stopper, as well.
> I just booted 2.6.32-rc4 straight from Linus on an mpc8572ds yesterday.
> I've booted various upstream kernels on mpc8313erdb (typically an older r=
ev,
> though).
Okay, you are right, the mpc8572ds does seem to work pretty well.
Perhaps we can fix up the above three issues?
Richard
[1] http://www.bitshrine.org/gpp_info/linux-fsl-2.6.23-MPC8313ERDB-IEEE-158=
8.patch.html
^ permalink raw reply
* RE: [PATCH v0 1/2] DMA: fsldma: Disable DMA_INTERRUPT when Async_tx enabled
From: Suresh Vishnu-B05022 @ 2009-10-20 13:09 UTC (permalink / raw)
To: Ira W. Snyder, Dan Williams
Cc: herbert, linux-kernel, linux-raid, linuxppc-dev, linux-crypto,
Tabi Timur-B04825
In-Reply-To: <20091016153334.GA27401@ovro.caltech.edu>
> -----Original Message-----
> From: Ira W. Snyder [mailto:iws@ovro.caltech.edu]=20
> Sent: Friday, October 16, 2009 9:04 PM
> To: Dan Williams
> Cc: Suresh Vishnu-B05022; herbert@gondor.apana.org.au;=20
> linux-kernel@vger.kernel.org; linux-raid@vger.kernel.org;=20
> linuxppc-dev@ozlabs.org; linux-crypto@vger.kernel.org; Tabi=20
> Timur-B04825
> Subject: Re: [PATCH v0 1/2] DMA: fsldma: Disable=20
> DMA_INTERRUPT when Async_tx enabled
>=20
> On Thu, Oct 15, 2009 at 06:25:14PM -0700, Dan Williams wrote:
> > [ added Leo and Timur to the Cc ]
> >=20
> > On Wed, Oct 14, 2009 at 11:41 PM, Vishnu Suresh=20
> <Vishnu@freescale.com> wrote:
> > > This patch disables the use of DMA_INTERRUPT capability with=20
> > > Async_tx
> > >
> > > The fsldma produces a null transfer with DMA_INTERRUPT capability=20
> > > when used with Async_tx. When RAID devices queue a=20
> transaction via=20
> > > Async_tx, this =A0results in a hang.
> > >
> > > Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
> > > ---
> > > =A0drivers/dma/fsldma.c | =A0 =A06 ++++++
> > > =A01 files changed, 6 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index=20
> > > 296f9e7..66d9b39 100644
> > > --- a/drivers/dma/fsldma.c
> > > +++ b/drivers/dma/fsldma.c
> > > @@ -1200,7 +1200,13 @@ static int __devinit=20
> of_fsl_dma_probe(struct=20
> > > of_device *dev,
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-=20
> fdev->reg.start +=20
> > > 1);
> > >
> > > =A0 =A0 =A0 =A0dma_cap_set(DMA_MEMCPY, fdev->common.cap_mask);
> > > +#ifndef CONFIG_ASYNC_CORE
> > > + =A0 =A0 =A0 /*
> > > + =A0 =A0 =A0 =A0* The DMA_INTERRUPT async_tx is a NULL transfer,=20
> which will
> > > + =A0 =A0 =A0 =A0* triger a PE interrupt.
> > > + =A0 =A0 =A0 =A0*/
> > > =A0 =A0 =A0 =A0dma_cap_set(DMA_INTERRUPT, fdev->common.cap_mask);
> > > +#endif
> > > =A0 =A0 =A0 =A0dma_cap_set(DMA_SLAVE, fdev->common.cap_mask);
> > > =A0 =A0 =A0 =A0fdev->common.device_alloc_chan_resources =3D=20
> > > fsl_dma_alloc_chan_resources;
> > > =A0 =A0 =A0 =A0fdev->common.device_free_chan_resources =3D=20
> > > fsl_dma_free_chan_resources;
> >=20
> > You are basically saying that fsl_dma_prep_interrupt() is=20
> buggy. Can=20
> > that routine be fixed rather than this piecemeal solution? If it=20
> > cannot be fixed (i.e. hardware issue) then fsl_dma_prep_interrupt()=20
> > should just be disabled/deleted altogether.
We are working to fix this issue.
> >=20
>=20
> For what it's worth, I've used the following code in the=20
> recent past, without any issues. This was on an 83xx, within=20
> the last few kernel releases. I haven't tried it on the latest -rc.
This works fine as long as only DMA_MEMCPY is being used.
The async_tx_channel_switch does not occur and the=20
device_prep_dma_interrupt is not called.=20
However, when a DMA_XOR capable device is exposed,=20
which is differnet from the DMA_MEMCPY/INTERRUPT device, this path is =
hit.
Is it proper to schedule a dma_interrupt from the channel switch call,=20
even when the depend_tx and tx channels correspond to different devices?
>=20
> Using device_prep_dma_memcpy() can trigger a callback as=20
> well, so the interrupt feature isn't strictly needed. Just=20
> attach the callback to the last memcpy operation.
>=20
> static dma_cookie_t dma_async_interrupt(struct dma_chan *chan,
> dma_async_tx_callback=20
> callback,
> void *data) {
> struct dma_device *dev =3D chan->device;
> struct dma_async_tx_descriptor *tx;=20
>=20
> /* Set up the DMA */
> tx =3D dev->device_prep_dma_interrupt(chan, =
DMA_PREP_INTERRUPT);
> if (!tx)
> return -ENOMEM;
>=20
> tx->callback =3D callback;
> tx->callback_param =3D data;
>=20
> return tx->tx_submit(tx);
> }
>=20
> Ira
>=20
>=20
^ permalink raw reply
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases
From: Américo Wang @ 2009-10-20 13:58 UTC (permalink / raw)
To: Rusty Russell
Cc: sfr, Hollis Blanchard, linux-kernel, kvm-ppc, linux-next,
Jan Beulich, akpm, linuxppc-dev
In-Reply-To: <200910201415.34361.rusty@rustcorp.com.au>
On Tue, Oct 20, 2009 at 02:15:33PM +1030, Rusty Russell wrote:
>BUILD_BUG_ON used to use the optimizer to do code elimination or fail
>at link time; it was changed to first the size of a negative array (a
>nicer compile time error), then (in
>8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield.
>
>bitfields: needs a literal constant at parse time, and can't be put under
> "if (__builtin_constant_p(x))" for example.
>negative array: can handle anything, but if the compiler can't tell it's
> a constant, silently has no effect.
>link time: breaks link if the compiler can't determine the value, but the
> linker output is not usually as informative as a compiler error.
>
>If we use the negative-array-size method *and* the link time trick,
>we get the ability to use BUILD_BUG_ON() under __builtin_constant_p()
>branches, and maximal ability for the compiler to detect errors at
>build time.
>
>Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>
>diff --git a/include/linux/kernel.h b/include/linux/kernel.h
>--- a/include/linux/kernel.h
>+++ b/include/linux/kernel.h
>@@ -683,12 +683,6 @@ struct sysinfo {
> char _f[20-2*sizeof(long)-sizeof(int)]; /* Padding: libc5 uses this.. */
> };
>
>-/* Force a compilation error if condition is true */
>-#define BUILD_BUG_ON(condition) ((void)BUILD_BUG_ON_ZERO(condition))
>-
>-/* Force a compilation error if condition is constant and true */
>-#define MAYBE_BUILD_BUG_ON(cond) ((void)sizeof(char[1 - 2 * !!(cond)]))
>-
> /* Force a compilation error if condition is true, but also produce a
> result (of value 0 and type size_t), so the expression can be used
> e.g. in a structure initializer (or where-ever else comma expressions
>@@ -696,6 +690,33 @@ struct sysinfo {
> #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
> #define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:-!!(e); }))
>
>+/**
>+ * BUILD_BUG_ON - break compile if a condition is true.
>+ * @cond: the condition which the compiler should know is false.
>+ *
>+ * If you have some code which relies on certain constants being equal, or
>+ * other compile-time-evaluated condition, you should use BUILD_BUG_ON to
>+ * detect if someone changes it.
>+ *
>+ * The implementation uses gcc's reluctance to create a negative array, but
>+ * gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments
>+ * to inline functions). So as a fallback we use the optimizer; if it can't
>+ * prove the condition is false, it will cause a link error on the undefined
>+ * "__build_bug_on_failed". This error message can be harder to track down
>+ * though, hence the two different methods.
>+ */
>+#ifndef __OPTIMIZE__
>+#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
>+#else
>+extern int __build_bug_on_failed;
Hmm, what exactly is __build_bug_on_failed?
>+#define BUILD_BUG_ON(condition) \
>+ do { \
>+ ((void)sizeof(char[1 - 2*!!(condition)])); \
>+ if (condition) __build_bug_on_failed = 1; \
>+ } while(0)
>+#endif
>+#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition)
>+
> /* Trap pasters of __FUNCTION__ at compile-time */
> #define __FUNCTION__ (__func__)
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
Live like a child, think like the god.
^ permalink raw reply
* bus error exception handler not working
From: Norbert van Bolhuis @ 2009-10-20 14:20 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org >> "linuxppc-dev@ozlabs.org"
reading a bogus address in u-boot gives:
=> md 0x88000000
88000000:Machine check in kernel mode.
Caused by (from msr): regs 0ff0ec28 Unknown values in msr
NIP: 0000111C XER: 2000005F LR: 0FFDB104 REGS: 0ff0ec28 TRAP: 0200 DAR: 00000000
MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 0FFDB104 0FF0ED18 0FF0EF48 0FFE9DAC 00000002 00000010 FFFFFFFF 00000030
GPR08: 00000001 00000020 00000000 00000009 0FF0E828 1001910C 0FFF9000 0FFE9E10
GPR16: 0FFE9DAC 0FFEADF8 0FFEADF0 0FFEDCE4 48024028 8800002B 88000000 88000000
GPR24: 0FF0ED20 00000040 00000000 00000004 0FF0ED20 00000004 0FFFA650 88000000
Call backtrace:
0FFDB104 0FFC67B4 0FFCF668 0FFCED70 0FFCEEE0 0FFD1AA8 0FFB5FF4
0FFB2644
machine check
Resetting the board.
U-Boot 2008.10 (Oct 16 2009 - 14:57:46) MPC83XX, version=0x00910161
Reset Status: Software Hard, External/Internal Soft, External/Internal Hard
doing the same in linux kernel gives an immediate reboot (checkstop):
# readmm 32 88000000 1
U-Boot 2008.10 (Oct 16 2009 - 14:57:46) MPC83XX, version=0x00910161
Reset Status: Check Stop, External/Internal Soft, External/Internal Hard
We're using an MPC8313E on a custom board (similar to MPC8313E-RDB) with
U-Boot v2008.10 and linux 2.6.28.
The problem is that the linux kernel exception handler (arch/powerpc/kernel/head_32.S)
doesn't work. It looks like this:
. = 0x200
0x200 mtspr SPRN_SPRG0,r10
mtspr SPRN_SPRG1,r11
mfcr r10
#define EXCEPTION_PROLOG_1 \
0x20c mfspr r11,SPRN_SRR1; /* check whether user or kernel */ \
andi. r11,r11,MSR_PR; \
tophys(r11,r1); /* use tophys(r1) if kernel */ \
beq 1f; \
mfspr r11,SPRN_SPRG3; \
lwz r11,THREAD_INFO-THREAD(r11); \
addi r11,r11,THREAD_SIZE; \
tophys(r11,r11); \
1: subi r11,r11,INT_FRAME_SIZE /* alloc exc. frame */
#define EXCEPTION_PROLOG_2 \
CLR_TOP32(r11); \
0x230 stw r10,_CCR(r11); /* save registers */ \
stw r12,GPR12(r11); \
stw r9,GPR9(r11); \
mfspr r10,SPRN_SPRG0; \
stw r10,GPR10(r11); \
mfspr r12,SPRN_SPRG1; \
stw r12,GPR11(r11); \
mflr r10; \
stw r10,_LINK(r11); \
mfspr r12,SPRN_SRR0; \
mfspr r9,SPRN_SRR1; \
stw r1,GPR1(r11); \
stw r1,0(r11); \
tovirt(r1,r11); /* set new kernel sp */ \
li r10,MSR_KERNEL & ~(MSR_IR|MSR_DR); /* can take exceptions */ \
MTMSRD(r10); /* (except for mach check in rtas) */ \
stw r0,GPR0(r11); \
lis r10,STACK_FRAME_REGS_MARKER@ha; /* exception frame marker */ \
0x278 addi r10,r10,STACK_FRAME_REGS_MARKER@l; \
stw r10,8(r11); \
SAVE_4GPRS(3, r11); \
SAVE_2GPRS(7, r11)
0x298 addi r3,r1,STACK_FRAME_OVERHEAD
EXC_XFER_STD(0x200, machine_check_exception)
0x29c li r10,trap
...
bl machine_check_exception
somehow machine_check_exception isn't reached. can anyone tell me why ?
is there something wrong with EXCEPTION_PROLOG_1/EXCEPTION_PROLOG_2 ?
^ permalink raw reply
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases
From: Alan Jenkins @ 2009-10-20 14:43 UTC (permalink / raw)
To: Américo Wang
Cc: sfr, Hollis Blanchard, Rusty Russell, linux-kernel, Jan Beulich,
linux-next, kvm-ppc, akpm, linuxppc-dev
In-Reply-To: <20091020135835.GB2462@hack>
On 10/20/09, Am=E9rico Wang <xiyou.wangcong@gmail.com> wrote:
> On Tue, Oct 20, 2009 at 02:15:33PM +1030, Rusty Russell wrote:
>>BUILD_BUG_ON used to use the optimizer to do code elimination or fail
>>at link time; it was changed to first the size of a negative array (a
>>nicer compile time error), then (in
>>8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield.
>>
>>bitfields: needs a literal constant at parse time, and can't be put under
>> "if (__builtin_constant_p(x))" for example.
>>negative array: can handle anything, but if the compiler can't tell it's
>> a constant, silently has no effect.
>>link time: breaks link if the compiler can't determine the value, but the
>> linker output is not usually as informative as a compiler error.
>>
>>If we use the negative-array-size method *and* the link time trick,
>>we get the ability to use BUILD_BUG_ON() under __builtin_constant_p()
>>branches, and maximal ability for the compiler to detect errors at
>>build time.
>>
>>Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>>
>>diff --git a/include/linux/kernel.h b/include/linux/kernel.h
>>--- a/include/linux/kernel.h
>>+++ b/include/linux/kernel.h
>>@@ -683,12 +683,6 @@ struct sysinfo {
>> char _f[20-2*sizeof(long)-sizeof(int)]; /* Padding: libc5 uses this.. *=
/
>> };
>>
>>-/* Force a compilation error if condition is true */
>>-#define BUILD_BUG_ON(condition) ((void)BUILD_BUG_ON_ZERO(condition))
>>-
>>-/* Force a compilation error if condition is constant and true */
>>-#define MAYBE_BUILD_BUG_ON(cond) ((void)sizeof(char[1 - 2 * !!(cond)]))
>>-
>> /* Force a compilation error if condition is true, but also produce a
>> result (of value 0 and type size_t), so the expression can be used
>> e.g. in a structure initializer (or where-ever else comma expressions
>>@@ -696,6 +690,33 @@ struct sysinfo {
>> #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
>> #define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:-!!(e); }))
>>
>>+/**
>>+ * BUILD_BUG_ON - break compile if a condition is true.
>>+ * @cond: the condition which the compiler should know is false.
>>+ *
>>+ * If you have some code which relies on certain constants being equal, =
or
>>+ * other compile-time-evaluated condition, you should use BUILD_BUG_ON t=
o
>>+ * detect if someone changes it.
>>+ *
>>+ * The implementation uses gcc's reluctance to create a negative array,
>> but
>>+ * gcc (as of 4.4) only emits that error for obvious cases (eg. not
>> arguments
>>+ * to inline functions). So as a fallback we use the optimizer; if it
>> can't
>>+ * prove the condition is false, it will cause a link error on the
>> undefined
>>+ * "__build_bug_on_failed". This error message can be harder to track
>> down
>>+ * though, hence the two different methods.
>>+ */
>>+#ifndef __OPTIMIZE__
>>+#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)])=
)
>>+#else
>>+extern int __build_bug_on_failed;
>
> Hmm, what exactly is __build_bug_on_failed?
Well, we haven't added a definition for it in this patch. I'm sure
grep will tell you it wasn't defined before hand either. So any
reference to it is an error - which will be reported at link time.
>>+#define BUILD_BUG_ON(condition) \
>>+ do { \
>>+ ((void)sizeof(char[1 - 2*!!(condition)])); \
>>+ if (condition) __build_bug_on_failed =3D 1; \
If "condition" is known false at compile time, gcc -O will eliminate
the code which refers to __build_bug_on_failed. If it's not proved to
be false - it will break the build, which is exactly what we want
BUILD_BUG_ON to do.
>>+ } while(0)
>>+#endif
>>+#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition)
>>+
>> /* Trap pasters of __FUNCTION__ at compile-time */
>> #define __FUNCTION__ (__func__)
>>
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Felix Radensky @ 2009-10-20 15:30 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org
In-Reply-To: <4ADCC247.6080107@freescale.com>
Scott Wood wrote:
> Felix Radensky wrote:
>> OK, no problem. I just wanted to get an idea of what should be done.
>> Should the NOR code poll some eLBC register to wait for completion of
>> NAND special operation ? Can you tell what register is relevant ?
>
> I was thinking you'd just share a mutex with the NAND code.
>
OK, I have NOR and NAND synchronized properly now.
Thanks a lot for your help.
Felix.
^ permalink raw reply
* Re: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Scott Wood @ 2009-10-20 15:56 UTC (permalink / raw)
To: Richard Cochran; +Cc: 'linuxppc-dev@lists.ozlabs.org'
In-Reply-To: <95DC1AA8EC908B48939B72CF375AA5E30E2AECFD@alice.at.omicron.at>
On Tue, Oct 20, 2009 at 12:01:19PM +0200, Richard Cochran wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:scottwood@freescale.com]
> >
> > What problems have you been having with upstream kernels on mpc8313erdb,
> > other than this IRQ issue? It should work, though the BSP may have extra
> > features that haven't been pushed upstream.
>
> I have been working from kernel 2.6.30 (although the very latest
> kernel is just the same WRT these problems, AFAICT). I had to patch in
> order to sovle the following three problems:
>
> 1. The flash layout in the DTS does not match the default partitioning
> from Freescale. In the current dts, the NAND partitioning is wrong,
> and there is no partitioning for the NOR flash given.
OK, I wasn't aware of that -- that kind of thing is an artifact of the BSP
development process being fairly separate from upstream development. The
"open source team" works on upstream Linux and upstream U-Boot. We don't
run the BSP u-boot (since we're developing the newer u-boot), and it's easy
to miss when things like this diverge.
In this case, I'd be surprised if the NAND partitioning that is upstream
came from anywhere but an early BSP's Linux tree. There's not much we (the
upstream-focused developers) can do if different BSPs have different layouts
(other than not specify a layout at all)... What is the layout you see in
your BSP?
> 2. The eTSEC interrupt issue that started this thread.
Well, yes. :-)
> 3. The PTP IO signals are not configured in a vanilla linux. For this,
> you need parts of a Freescale patch. [1] Their PTP implementation
> gianfar driver is horrible, but still, the IO configuration in
> these two files in the patch is necessary to get any external
> signals from the PTP clock:
>
> arch/powerpc/platforms/83xx/mpc8313_rdb.c
> arch/powerpc/platforms/83xx/mpc83xx.h
Yes, this is one of those features that is currently BSP-only (partly due to
it needing work, as you note above). That's different than the board simply
not being supported upstream, but if you need it, you need it. I'll raise
the issue in my team, but I suggest also letting Freescale support (or other
official feedback channels) know what you'd like to see in terms of
improvements in that code and getting it upstream.
-Scott
^ permalink raw reply
* Device Tree Corrupted after unflatten_device_tree()
From: Lixin Yao @ 2009-10-20 16:10 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 848 bytes --]
I use a board with MPC866T and 2.6.28 Linux Kernel. Occasionally, the
unflattened device is corrupted after "unflatten_device_tree()" which
causes crash of kernel when device tree is traversed later on.
I looked at the fixes in lib/lmb.c, arch/powerpc/mm, arch/powerpc/kernel
etc since 2.6.28 to 2.6.32-r4 (the most recent version) and could not
fix my problem.
I have had a hard time trying to determine the cause.
arch/powerpc/kernel/setup_32.c
void __init setup_arch(char **cmdline_p)
{
*cmdline_p = cmd_line;
/* so udelay does something sensible, assume <= 1000 bogomips */
loops_per_jiffy = 500000000 / HZ;
unflatten_device_tree();
/* UNFLATTENED DEVICE TREE IS CORRUPTED SOMETIMES HERE */
check_for_initrd();
......
}
Any ideas?
Thanks.
Lixin Yao
Harris Startex Networks Inc.
RTP, NC, USA
[-- Attachment #2: Type: text/html, Size: 4135 bytes --]
^ permalink raw reply
* Linux for MPC5554 or MPC5534 (core e200z6)?
From: Németh Márton @ 2009-10-20 22:21 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev
Hi Grant,
Hello List,
is there anybody who was successfully run Linux kernel on Freescale MPC5554
[1], [2] or on Freescale MPC5534 [3], [4]? Both of these embedded PowerPC
controllers have the e200z6 core.
Is there anybody who is working with these controllers or with the e200z6 core?
References:
[1] Freescale MPC5554
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5554
[2] MPC5553/MPC5554 Microcontroller Reference Manual
http://www.freescale.com/files/32bit/doc/ref_manual/MPC5553_MPC5554_RM.pdf
[3] Freescale MPC5534
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5534
[4] MPC5534 Microcontroller Reference Manual
http://www.freescale.com/files/32bit/doc/ref_manual/MPC5534RM.pdf
Regards,
Márton Németh
^ permalink raw reply
* Re: Device Tree Corrupted after unflatten_device_tree()
From: Michael Ellerman @ 2009-10-20 23:01 UTC (permalink / raw)
To: Lixin Yao; +Cc: linuxppc-dev
In-Reply-To: <03D77CA4AC7F4D48A6AB5DA3F1001B3FB5BB88@exchtxus2.HSTX.global.vpn>
[-- Attachment #1: Type: text/plain, Size: 986 bytes --]
On Tue, 2009-10-20 at 09:10 -0700, Lixin Yao wrote:
> I use a board with MPC866T and 2.6.28 Linux Kernel. Occasionally, the
> unflattened device is corrupted after “unflatten_device_tree()” which
> causes crash of kernel when device tree is traversed later on.
>
> I looked at the fixes in lib/lmb.c, arch/powerpc/mm,
> arch/powerpc/kernel etc since 2.6.28 to 2.6.32-r4 (the most recent
> version) and could not fix my problem.
>
> I have had a hard time trying to determine the cause.
>
> arch/powerpc/kernel/setup_32.c
>
> void __init setup_arch(char **cmdline_p)
>
> {
>
> *cmdline_p = cmd_line;
>
> /* so udelay does something sensible, assume <= 1000 bogomips
> */
>
> loops_per_jiffy = 500000000 / HZ;
>
> unflatten_device_tree();
>
> /* UNFLATTENED DEVICE TREE IS CORRUPTED SOMETIMES HERE */
_In what way_ is it corrupted? Bad tree structure? Bogus node/property
values, names etc.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Move ehea hcall definitions into hvcall.h
From: Anton Blanchard @ 2009-10-21 6:06 UTC (permalink / raw)
To: benh; +Cc: tklein, raisch, linuxppc-dev, themann
Move ehea hcall definitions into hvcall.h.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux.trees.git/arch/powerpc/include/asm/hvcall.h
===================================================================
--- linux.trees.git.orig/arch/powerpc/include/asm/hvcall.h 2009-10-19 17:59:42.000000000 +1100
+++ linux.trees.git/arch/powerpc/include/asm/hvcall.h 2009-10-19 18:03:18.000000000 +1100
@@ -212,6 +212,19 @@
#define H_QUERY_INT_STATE 0x1E4
#define H_POLL_PENDING 0x1D8
#define H_ILLAN_ATTRIBUTES 0x244
+#define H_MODIFY_HEA_QP 0x250
+#define H_QUERY_HEA_QP 0x254
+#define H_QUERY_HEA 0x258
+#define H_QUERY_HEA_PORT 0x25C
+#define H_MODIFY_HEA_PORT 0x260
+#define H_REG_BCMC 0x264
+#define H_DEREG_BCMC 0x268
+#define H_REGISTER_HEA_RPAGES 0x26C
+#define H_DISABLE_AND_GET_HEA 0x270
+#define H_GET_HEA_INFO 0x274
+#define H_ALLOC_HEA_RESOURCE 0x278
+#define H_ADD_CONN 0x284
+#define H_DEL_CONN 0x288
#define H_JOIN 0x298
#define H_VASI_STATE 0x2A4
#define H_ENABLE_CRQ 0x2B0
Index: linux.trees.git/drivers/net/ehea/ehea_phyp.h
===================================================================
--- linux.trees.git.orig/drivers/net/ehea/ehea_phyp.h 2009-10-19 18:03:48.000000000 +1100
+++ linux.trees.git/drivers/net/ehea/ehea_phyp.h 2009-10-19 18:03:56.000000000 +1100
@@ -33,7 +33,6 @@
#include <asm/hvcall.h>
#include "ehea.h"
#include "ehea_hw.h"
-#include "ehea_hcall.h"
/* Some abbreviations used here:
*
Index: linux.trees.git/drivers/net/ehea/ehea_hcall.h
===================================================================
--- linux.trees.git.orig/drivers/net/ehea/ehea_hcall.h 2009-10-19 17:59:31.000000000 +1100
+++ /dev/null 1970-01-01 00:00:00.000000000 +0000
@@ -1,51 +0,0 @@
-/*
- * linux/drivers/net/ehea/ehea_hcall.h
- *
- * eHEA ethernet device driver for IBM eServer System p
- *
- * (C) Copyright IBM Corp. 2006
- *
- * Authors:
- * Christoph Raisch <raisch@de.ibm.com>
- * Jan-Bernd Themann <themann@de.ibm.com>
- * Thomas Klein <tklein@de.ibm.com>
- *
- *
- * 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 Free Software Foundation; either version 2, or (at your option)
- * any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
-
-#ifndef __EHEA_HCALL_H__
-#define __EHEA_HCALL_H__
-
-/**
- * This file contains HCALL defines that are to be included in the appropriate
- * kernel files later
- */
-
-#define H_ALLOC_HEA_RESOURCE 0x278
-#define H_MODIFY_HEA_QP 0x250
-#define H_QUERY_HEA_QP 0x254
-#define H_QUERY_HEA 0x258
-#define H_QUERY_HEA_PORT 0x25C
-#define H_MODIFY_HEA_PORT 0x260
-#define H_REG_BCMC 0x264
-#define H_DEREG_BCMC 0x268
-#define H_REGISTER_HEA_RPAGES 0x26C
-#define H_DISABLE_AND_GET_HEA 0x270
-#define H_GET_HEA_INFO 0x274
-#define H_ADD_CONN 0x284
-#define H_DEL_CONN 0x288
-
-#endif /* __EHEA_HCALL_H__ */
^ permalink raw reply
* [PATCH v3 1/3] powerpc/fsl: 85xx: document cache-sram size as a kernel parametric option
From: Vivek Mahajan @ 2009-10-21 12:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kumar.gala, Vivek Mahajan
Adds documentation for the size parameter of Freescale's QorIQ
based cache-sram
Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
---
v2, v3: No change over v1
Documentation/kernel-parameters.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 6fa7292..8767f36 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -412,6 +412,9 @@ and is between 256 and 4096 characters. It is defined in the file
c101= [NET] Moxa C101 synchronous serial card
+ cache-sram-size= [PPC] Size of Freescale's QorIQ Cache SRAM
+ See Documentation/powerpc/fsl_85xx_cache_sram.txt.
+
cachesize= [BUGS=X86-32] Override level 2 CPU cache size detection.
Sometimes CPU hardware bugs make them report the cache
size incorrectly. The kernel will attempt work arounds
--
1.5.6.5
^ permalink raw reply related
* [PATCH v3 2/3] powerpc/fsl: 85xx: document cache-sram
From: Vivek Mahajan @ 2009-10-21 12:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kumar.gala, Vivek Mahajan
In-Reply-To: <1256129459-10685-1-git-send-email-vivek.mahajan@freescale.com>
Adds documentation for Freescale's QorIQ based cache-sram as under:-
* How to enable it from a low level driver
* How to set its size
Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
---
v2, v3: No change over v1
Documentation/powerpc/fsl_85xx_cache_sram.txt | 31 +++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/fsl_85xx_cache_sram.txt
diff --git a/Documentation/powerpc/fsl_85xx_cache_sram.txt b/Documentation/powerpc/fsl_85xx_cache_sram.txt
new file mode 100644
index 0000000..7f43e2a
--- /dev/null
+++ b/Documentation/powerpc/fsl_85xx_cache_sram.txt
@@ -0,0 +1,31 @@
+* Freescale QorIQ based Cache SRAM
+
+Freescale's QorIQ platforms provide an option of configuring
+a part of (or full) cache memory as SRAM. Any low level
+driver can use its APIs via selecting FSL_85XX_CACHE_SRAM as
+under for the case of gianfar ethernet driver:-
+
+In drivers/net/Kconfig:-
+
+config GIANFAR
+ ....
+ select FSL_85XX_CACHE_SRAM if MPC85xx
+ ....
+
+FSL_85XX_CACHE_SRAM and its base address are defined in
+arch/powerpc/platforms/85xx/Kconfig as under:-
+
+config FSL_85XX_CACHE_SRAM
+ bool
+ select PPC_LIB_RHEAP
+
+config FSL_85XX_CACHE_SRAM_BASE
+ hex
+ depends on FSL_85XX_CACHE_SRAM
+ default "0xfff00000"
+
+The size of the above cache SRAM memory window is passed via the
+kernel command line as <cache-sram-size=....>
+
+Absence of the above parameter in the kernel command line is
+treated as no cache SRAM.
--
1.5.6.5
^ permalink raw reply related
* [PATCH v3 3/3] powerpc/fsl: 85xx: add cache-sram support
From: Vivek Mahajan @ 2009-10-21 12:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kumar.gala, Vivek Mahajan
In-Reply-To: <1256129459-10685-2-git-send-email-vivek.mahajan@freescale.com>
This adds QorIQ based Cache-SRAM support as under:-
* A small abstraction over powerpc's remote heap allocator
* Exports mpc85xx_cache_sram_alloc()/free() APIs
* Supports only one contiguous SRAM window
* Defines FSL_85XX_CACHE_SRAM and its base address
Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
---
v2: mbar(1) -> eieio() as per Kumar G.
v3: Fixed cache-sram ways computation
arch/powerpc/include/asm/fsl_85xx_cache_sram.h | 48 ++++++
arch/powerpc/platforms/85xx/Kconfig | 9 ++
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h | 95 ++++++++++++
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 141 ++++++++++++++++++
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 184 ++++++++++++++++++++++++
6 files changed, 478 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/fsl_85xx_cache_sram.h
create mode 100644 arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h
create mode 100644 arch/powerpc/sysdev/fsl_85xx_cache_sram.c
create mode 100644 arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
diff --git a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
new file mode 100644
index 0000000..2af2bdc
--- /dev/null
+++ b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
@@ -0,0 +1,48 @@
+/*
+ * Copyright 2009 Freescale Semiconductor, Inc.
+ *
+ * Cache SRAM handling for QorIQ platform
+ *
+ * Author: Vivek Mahajan <vivek.mahajan@freescale.com>
+
+ * This file is derived from the original work done
+ * by Sylvain Munaut for the Bestcomm SRAM allocator.
+ *
+ * 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
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __ASM_POWERPC_FSL_85XX_CACHE_SRAM_H__
+#define __ASM_POWERPC_FSL_85XX_CACHE_SRAM_H__
+
+#include <asm/rheap.h>
+#include <linux/spinlock.h>
+
+/*
+ * Cache-SRAM
+ */
+
+struct mpc85xx_cache_sram {
+ phys_addr_t base_phys;
+ void *base_virt;
+ unsigned int size;
+ rh_info_t *rh;
+ spinlock_t lock;
+};
+
+extern void mpc85xx_cache_sram_free(void *ptr);
+extern void *mpc85xx_cache_sram_alloc(unsigned int size,
+ phys_addr_t *phys, unsigned int align);
+
+#endif /* __AMS_POWERPC_FSL_85XX_CACHE_SRAM_H__ */
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index d3a975e..b6f23c3 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -144,6 +144,15 @@ config SBC8560
help
This option enables support for the Wind River SBC8560 board
+config FSL_85XX_CACHE_SRAM
+ bool
+ select PPC_LIB_RHEAP
+
+config FSL_85XX_CACHE_SRAM_BASE
+ hex
+ depends on FSL_85XX_CACHE_SRAM
+ default "0xfff00000"
+
endif # MPC85xx
config TQM85xx
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 9d4b174..745994c 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl-msi-obj-y)
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
obj-$(CONFIG_MPC8xxx_GPIO) += mpc8xxx_gpio.o
+obj-$(CONFIG_FSL_85XX_CACHE_SRAM) += fsl_85xx_l2ctlr.o fsl_85xx_cache_sram.o
obj-$(CONFIG_SIMPLE_GPIO) += simple_gpio.o
obj-$(CONFIG_RAPIDIO) += fsl_rio.o
obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h b/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h
new file mode 100644
index 0000000..8c4a4ac
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h
@@ -0,0 +1,95 @@
+/*
+ * Copyright 2009 Freescale Semiconductor, Inc
+ *
+ * QorIQ based Cache Controller Memory Mapped Registers
+ *
+ * Author: Vivek Mahajan <vivek.mahajan@freescale.com>
+ *
+ * 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
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __FSL_85XX_CACHE_CTLR_H__
+#define __FSL_85XX_CACHE_CTLR_H__
+
+#define L2CR_L2FI 0x40000000 /* L2 flash invalidate */
+#define L2CR_L2IO 0x00200000 /* L2 instruction only */
+#define L2CR_SRAM_ZERO 0x00000000 /* L2SRAM zero size */
+#define L2CR_SRAM_FULL 0x00010000 /* L2SRAM full size */
+#define L2CR_SRAM_HALF 0x00020000 /* L2SRAM half size */
+#define L2CR_SRAM_TWO_HALFS 0x00030000 /* L2SRAM two half sizes */
+#define L2CR_SRAM_QUART 0x00040000 /* L2SRAM one quarter size */
+#define L2CR_SRAM_TWO_QUARTS 0x00050000 /* L2SRAM two quarter size */
+#define L2CR_SRAM_EIGHTH 0x00060000 /* L2SRAM one eighth size */
+#define L2CR_SRAM_TWO_EIGHTH 0x00070000 /* L2SRAM two eighth size */
+
+#define L2SRAM_OPTIMAL_SZ_SHIFT 0x00000003 /* Optimum size for L2SRAM */
+
+#define L2SRAM_BAR_MSK_LO18 0xFFFFC000 /* Lower 18 bits */
+#define L2SRAM_BARE_MSK_HI4 0x0000000F /* Upper 4 bits */
+
+enum cache_sram_lock_ways {
+ LOCK_WAYS_ZERO,
+ LOCK_WAYS_EIGHTH,
+ LOCK_WAYS_TWO_EIGHTH,
+ LOCK_WAYS_HALF = 4,
+ LOCK_WAYS_FULL = 8,
+};
+
+struct mpc85xx_l2ctlr {
+ u32 ctl; /* 0x000 - L2 control */
+ u8 res1[0xC];
+ u32 ewar0; /* 0x010 - External write address 0 */
+ u32 ewarea0; /* 0x014 - External write address extended 0 */
+ u32 ewcr0; /* 0x018 - External write ctrl */
+ u8 res2[4];
+ u32 ewar1; /* 0x020 - External write address 1 */
+ u32 ewarea1; /* 0x024 - External write address extended 1 */
+ u32 ewcr1; /* 0x028 - External write ctrl 1 */
+ u8 res3[4];
+ u32 ewar2; /* 0x030 - External write address 2 */
+ u32 ewarea2; /* 0x034 - External write address extended 2 */
+ u32 ewcr2; /* 0x038 - External write ctrl 2 */
+ u8 res4[4];
+ u32 ewar3; /* 0x040 - External write address 3 */
+ u32 ewarea3; /* 0x044 - External write address extended 3 */
+ u32 ewcr3; /* 0x048 - External write ctrl 3 */
+ u8 res5[0xB4];
+ u32 srbar0; /* 0x100 - SRAM base address 0 */
+ u32 srbarea0; /* 0x104 - SRAM base addr reg ext address 0 */
+ u32 srbar1; /* 0x108 - SRAM base address 1 */
+ u32 srbarea1; /* 0x10C - SRAM base addr reg ext address 1 */
+ u8 res6[0xCF0];
+ u32 errinjhi; /* 0xE00 - Error injection mask high */
+ u32 errinjlo; /* 0xE04 - Error injection mask low */
+ u32 errinjctl; /* 0xE08 - Error injection tag/ecc control */
+ u8 res7[0x14];
+ u32 captdatahi; /* 0xE20 - Error data high capture */
+ u32 captdatalo; /* 0xE24 - Error data low capture */
+ u32 captecc; /* 0xE28 - Error syndrome */
+ u8 res8[0x14];
+ u32 errdet; /* 0xE40 - Error detect */
+ u32 errdis; /* 0xE44 - Error disable */
+ u32 errinten; /* 0xE48 - Error interrupt enable */
+ u32 errattr; /* 0xE4c - Error attribute capture */
+ u32 erradrrl; /* 0xE50 - Error address capture low */
+ u32 erradrrh; /* 0xE54 - Error address capture high */
+ u32 errctl; /* 0xE58 - Error control */
+ u8 res9[0x1A4];
+};
+
+extern int instantiate_cache_sram(struct of_device *dev, unsigned int size);
+extern void remove_cache_sram(struct of_device *dev);
+
+#endif /* __FSL_85XX_CACHE_CTLR_H__ */
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
new file mode 100644
index 0000000..6744083
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright 2009 Freescale Semiconductor, Inc.
+ *
+ * Simple memory allocator abstraction for QorIQ (P1/P2) based Cache-SRAM
+ *
+ * Author: Vivek Mahajan <vivek.mahajan@freescale.com>
+ *
+ * This file is derived from the original work done
+ * by Sylvain Munaut for the Bestcomm SRAM allocator.
+ *
+ * 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
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/of_platform.h>
+#include <asm/pgtable.h>
+#include <asm/fsl_85xx_cache_sram.h>
+
+struct mpc85xx_cache_sram *cache_sram;
+
+void *mpc85xx_cache_sram_alloc(unsigned int size,
+ phys_addr_t *phys, unsigned int align)
+{
+ unsigned long offset;
+ unsigned long flags;
+
+ if (!size || (size > cache_sram->size) || (align > cache_sram->size)) {
+ pr_err("%s(): size(=%x) or align(=%x) zero or too big\n",
+ __func__, size, align);
+ return NULL;
+ }
+
+ if ((align & (align - 1)) || align <= 1) {
+ pr_err("%s(): align(=%x) must be power of two and >1\n",
+ __func__, align);
+ return NULL;
+ }
+
+ spin_lock_irqsave(&cache_sram->lock, flags);
+ offset = rh_alloc_align(cache_sram->rh, size, align, NULL);
+ spin_unlock_irqrestore(&cache_sram->lock, flags);
+
+ if (IS_ERR_VALUE(offset))
+ return NULL;
+
+ *phys = cache_sram->base_phys + offset;
+
+ return (unsigned char *)cache_sram->base_virt + offset;
+}
+EXPORT_SYMBOL(mpc85xx_cache_sram_alloc);
+
+void mpc85xx_cache_sram_free(void *ptr)
+{
+ unsigned long flags;
+ BUG_ON(!ptr);
+
+ spin_lock_irqsave(&cache_sram->lock, flags);
+ rh_free(cache_sram->rh, ptr - cache_sram->base_virt);
+ spin_unlock_irqrestore(&cache_sram->lock, flags);
+}
+EXPORT_SYMBOL(mpc85xx_cache_sram_free);
+
+int __init instantiate_cache_sram(struct of_device *dev, unsigned int size)
+{
+ if (cache_sram) {
+ dev_err(&dev->dev, "Already initialized cache-sram\n");
+ return -EBUSY;
+ }
+
+ cache_sram = kzalloc(sizeof(struct mpc85xx_cache_sram), GFP_KERNEL);
+ if (!cache_sram) {
+ dev_err(&dev->dev, "Out of memory for cache_sram structure\n");
+ return -ENOMEM;
+ }
+
+ cache_sram->base_phys = CONFIG_FSL_85XX_CACHE_SRAM_BASE;
+ cache_sram->size = size;
+
+ if (!request_mem_region(cache_sram->base_phys, cache_sram->size,
+ "fsl_85xx_cache_sram")) {
+ dev_err(&dev->dev, "%s: request memory failed\n",
+ dev->node->full_name);
+ kfree(cache_sram);
+ return -ENXIO;
+ }
+
+ cache_sram->base_virt = ioremap_flags(cache_sram->base_phys,
+ cache_sram->size, _PAGE_COHERENT | PAGE_KERNEL);
+ if (!cache_sram->base_virt) {
+ dev_err(&dev->dev, "%s: ioremap_flags failed\n",
+ dev->node->full_name);
+ release_mem_region(cache_sram->base_phys, cache_sram->size);
+ kfree(cache_sram);
+ return -ENOMEM;
+ }
+
+ cache_sram->rh = rh_create(sizeof(unsigned int));
+ if (IS_ERR(cache_sram->rh)) {
+ dev_err(&dev->dev, "%s: Unable to create remote heap\n",
+ dev->node->full_name);
+ iounmap(cache_sram->base_virt);
+ release_mem_region(cache_sram->base_phys, cache_sram->size);
+ kfree(cache_sram);
+ return PTR_ERR(cache_sram->rh);
+ }
+
+ rh_attach_region(cache_sram->rh, 0, cache_sram->size);
+ spin_lock_init(&cache_sram->lock);
+
+ dev_info(&dev->dev, "[base:0x%x, size:0x%x] configured and loaded\n",
+ cache_sram->base_phys, cache_sram->size);
+ return 0;
+}
+
+void remove_cache_sram(struct of_device *dev)
+{
+ BUG_ON(!cache_sram);
+
+ rh_detach_region(cache_sram->rh, 0, cache_sram->size);
+ rh_destroy(cache_sram->rh);
+
+ iounmap(cache_sram->base_virt);
+ release_mem_region(cache_sram->base_phys, cache_sram->size);
+
+ kfree(cache_sram);
+ cache_sram = NULL;
+
+ dev_info(&dev->dev, "MPC85xx Cache-SRAM driver unloaded\n");
+}
diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
new file mode 100644
index 0000000..c851547
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
@@ -0,0 +1,184 @@
+/*
+ * Copyright 2009 Freescale Semiconductor, Inc.
+ *
+ * QorIQ (P1/P2) L2 controller init for Cache-SRAM instantiation
+ *
+ * Author: Vivek Mahajan <vivek.mahajan@freescale.com>
+ *
+ * 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
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/of_platform.h>
+#include <asm/io.h>
+
+#include "fsl_85xx_cache_ctlr.h"
+
+static char *param;
+struct mpc85xx_l2ctlr __iomem *l2ctlr;
+
+static long get_cache_sram_size(void)
+{
+ unsigned long val;
+
+ if (!param || (strict_strtoul(param, 0, &val) < 0))
+ return -EINVAL;
+
+ return val;
+}
+
+static int __init get_cmdline_param(char *str)
+{
+ if (!str)
+ return 0;
+
+ param = str;
+ return 1;
+}
+
+__setup("cache-sram-size=", get_cmdline_param);
+
+static int __devinit mpc85xx_l2ctlr_of_probe(struct of_device *dev,
+ const struct of_device_id *match)
+{
+ long rval;
+ unsigned int rem;
+ unsigned char ways;
+ const unsigned int *prop;
+ unsigned int l2cache_size;
+ unsigned int sram_size;
+
+ if (!dev->node) {
+ dev_err(&dev->dev, "Device's OF-node is NULL\n");
+ return -EINVAL;
+ }
+
+ prop = of_get_property(dev->node, "cache-size", NULL);
+ if (!prop) {
+ dev_err(&dev->dev, "Missing L2 cache-size\n");
+ return -EINVAL;
+ }
+ l2cache_size = *prop;
+
+ rval = get_cache_sram_size();
+ if (rval <= 0) {
+ dev_err(&dev->dev,
+ "Entire L2 as cache, Aborting Cache-SRAM stuff\n");
+ return -EINVAL;
+ }
+
+ rem = l2cache_size % (unsigned int)rval;
+ ways = LOCK_WAYS_FULL * (unsigned int)rval / l2cache_size;
+ if (rem || (ways & (ways - 1))) {
+ dev_err(&dev->dev, "Illegal cache-sram-size in command line\n");
+ return -EINVAL;
+ }
+
+ sram_size = (unsigned int)rval;
+
+ l2ctlr = of_iomap(dev->node, 0);
+ if (!l2ctlr) {
+ dev_err(&dev->dev, "Can't map L2 controller\n");
+ return -EINVAL;
+ }
+
+ /*
+ * Write bits[0-17] to srbar0
+ */
+ out_be32(&l2ctlr->srbar0,
+ CONFIG_FSL_85XX_CACHE_SRAM_BASE & L2SRAM_BAR_MSK_LO18);
+
+ /*
+ * Write bits[18-21] to srbare0
+ */
+ out_be32(&l2ctlr->srbarea0,
+ (CONFIG_FSL_85XX_CACHE_SRAM_BASE >> 10) & L2SRAM_BARE_MSK_HI4);
+
+ clrsetbits_be32(&l2ctlr->ctl, L2CR_L2E, L2CR_L2FI);
+
+ switch (ways) {
+ case LOCK_WAYS_EIGHTH:
+ setbits32(&l2ctlr->ctl,
+ L2CR_L2E | L2CR_L2FI | L2CR_SRAM_EIGHTH);
+ break;
+
+ case LOCK_WAYS_TWO_EIGHTH:
+ setbits32(&l2ctlr->ctl,
+ L2CR_L2E | L2CR_L2FI | L2CR_SRAM_QUART);
+ break;
+
+ case LOCK_WAYS_HALF:
+ setbits32(&l2ctlr->ctl,
+ L2CR_L2E | L2CR_L2FI | L2CR_SRAM_HALF);
+ break;
+
+ case LOCK_WAYS_FULL:
+ default:
+ setbits32(&l2ctlr->ctl,
+ L2CR_L2E | L2CR_L2FI | L2CR_SRAM_FULL);
+ break;
+ }
+ eieio();
+
+ rval = instantiate_cache_sram(dev, sram_size);
+ if (rval < 0) {
+ dev_err(&dev->dev, "Can't instantiate Cache-SRAM\n");
+ iounmap(l2ctlr);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int __devexit mpc85xx_l2ctlr_of_remove(struct of_device *dev)
+{
+ BUG_ON(!l2ctlr);
+
+ iounmap(l2ctlr);
+ remove_cache_sram(dev);
+ dev_info(&dev->dev, "MPC85xx L2 controller unloaded\n");
+
+ return 0;
+}
+
+static struct of_device_id mpc85xx_l2ctlr_of_match[] = {
+ {
+ .compatible = "fsl,p2020-l2-cache-controller",
+ },
+ {},
+};
+
+static struct of_platform_driver mpc85xx_l2ctlr_of_platform_driver = {
+ .name = "fsl-l2ctlr",
+ .match_table = mpc85xx_l2ctlr_of_match,
+ .probe = mpc85xx_l2ctlr_of_probe,
+ .remove = __devexit_p(mpc85xx_l2ctlr_of_remove),
+};
+
+static __init int mpc85xx_l2ctlr_of_init(void)
+{
+ return of_register_platform_driver(&mpc85xx_l2ctlr_of_platform_driver);
+}
+
+static void __exit mpc85xx_l2ctlr_of_exit(void)
+{
+ of_unregister_platform_driver(&mpc85xx_l2ctlr_of_platform_driver);
+}
+
+subsys_initcall(mpc85xx_l2ctlr_of_init);
+module_exit(mpc85xx_l2ctlr_of_exit);
+
+MODULE_DESCRIPTION("Freescale MPC85xx L2 controller init");
+MODULE_LICENSE("GPL v2");
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH v4] powerpc/5200: Add mpc5200-spi (non-PSC) device driver
From: Wolfram Sang @ 2009-10-21 13:17 UTC (permalink / raw)
To: Grant Likely
Cc: linuxppc-dev, David Brownell, linux-kernel, spi-devel-general
In-Reply-To: <20090618025030.12363.69402.stgit@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 535 bytes --]
Hi Grant,
On Wed, Jun 17, 2009 at 08:55:01PM -0600, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Adds support for the dedicated SPI device on the Freescale MPC5200(b)
> SoC.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
do you have an updated version to share? Or is V4 still 'status quo'?
Genki de ;)
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Linux for MPC5554 or MPC5534 (core e200z6)?
From: Kumar Gala @ 2009-10-21 14:04 UTC (permalink / raw)
To: Németh Márton; +Cc: linuxppc-dev
In-Reply-To: <4ADE37DC.4070909@freemail.hu>
On Oct 20, 2009, at 5:21 PM, N=E9meth M=E1rton wrote:
> Hi Grant,
> Hello List,
>
> is there anybody who was successfully run Linux kernel on Freescale =20=
> MPC5554
> [1], [2] or on Freescale MPC5534 [3], [4]? Both of these embedded =20
> PowerPC
> controllers have the e200z6 core.
>
> Is there anybody who is working with these controllers or with the =20
> e200z6 core?
>
> References:
> [1] Freescale MPC5554
> =
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=3DMPC5554
>
> [2] MPC5553/MPC5554 Microcontroller Reference Manual
> =
http://www.freescale.com/files/32bit/doc/ref_manual/MPC5553_MPC5554_RM.pdf=
>
> [3] Freescale MPC5534
> http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=3DMPC5534=
>
> [4] MPC5534 Microcontroller Reference Manual
> http://www.freescale.com/files/32bit/doc/ref_manual/MPC5534RM.pdf
I'm not aware of anyone working on Linux for these chips based on the =20=
e200z6. What application do you have that you want to run Linux on =20
them?
- k=
^ permalink raw reply
* Re: Linux for MPC5554 or MPC5534 (core e200z6)?
From: Grant Likely @ 2009-10-21 14:13 UTC (permalink / raw)
To: Németh Márton; +Cc: linuxppc-dev
In-Reply-To: <4ADE37DC.4070909@freemail.hu>
2009/10/21 N=E9meth M=E1rton <nm127@freemail.hu>:
> Hi Grant,
> Hello List,
>
> is there anybody who was successfully run Linux kernel on Freescale MPC55=
54
> [1], [2] or on Freescale MPC5534 [3], [4]? Both of these embedded PowerPC
> controllers have the e200z6 core.
>
> Is there anybody who is working with these controllers or with the e200z6=
core?
I'm pretty sure nobody has done a Linux port to any of these chips.
Nor do I know of any work having been done in the past.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH 0/5 v4] Kernel Handling of Dynamic Logical Partitioning
From: Nathan Fontenot @ 2009-10-21 14:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: lkml
This is a re-send of the entire patch set with updates made from the comments
I have received, namely patches 1,3 and 5. I am re-sending the entire patch
set for clarity.
The Dynamic Logical Partitioning (DLPAR) capabilities of the powerpc pseries
platform allows for the addition and removal of resources (i.e. cpus,
memory, pci devices) from a partition. The removal of a resource involves
removing the resource's node from the device tree and then returning the
resource to firmware via the rtas set-indicator call. To add a resource, it
is first obtained from firmware via the rtas set-indicator call and then a
new device tree node is created using the ibm,configure-coinnector rtas call
and added to the device tree.
The following set of patches implements the needed infrastructure to have the
kernel handle the DLPAR addition and removal of memory and cpus (other
DLPAR'able items to follow in future patches). The framework for this is
to create a set of probe/release sysfs files in pseries that will add or
remove the cpu or memory to the system.
The majority of the code is powerpc/pseries specific except for PATCH 3/5, so
I am cc'ing lkml.
Patches include in this set:
1/5 - DLPAR infracstructure for powerpc/pseries platform.
2/5 - Move the of_drconf_cell struct to prom.h
3/5 - Export the memory sysdev class
4/5 - Memory DLPAR handling
5/5 - CPU DLPAR handling
-Nathan Fontenot
^ 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