* Please pull mpc52xx-next - CPU_FTR_NEED_COHERENT fixes for 2.6.29
From: Grant Likely @ 2009-03-17 15:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Kumar Gala, linuxppc-dev, Piotr Ziecik
Hi Ben,
Here are 2 coherency related fixes that need to go into 2.6.29. The
first is the patch we discussed last night about setting
CPU_FTR_NEED_COHERENT when the 5200 is selected. After discussing it
with galak, we agreed to stick with the ugly way for 2.6.29 and then
fix all of them at once in 2.6.30 (CONFIG_PPC_83XX, CONFIG_PPC_8260
and CONFIG_PPC_MPC52xx).
Second is Kumar's page table _PAGE_COHERENT fix. I've tested it on MPC5200.
Cheers,
g.
The following changes since commit 5bee17f18b595937e6beafeee5197868a3f74a06:
Kyle McMartin (1):
parisc: sba_iommu: fix build bug when CONFIG_PARISC_AGP=y
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6-mpc52xx.git merge
Kumar Gala (1):
powerpc/mm: Respect _PAGE_COHERENT on classic ppc32 SW
Piotr Ziecik (1):
powerpc/5200: Enable CPU_FTR_NEED_COHERENT for MPC52xx
arch/powerpc/include/asm/cputable.h | 4 +++-
arch/powerpc/kernel/head_32.S | 6 +++---
2 files changed, 6 insertions(+), 4 deletions(-)
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Compilation of PREEMPT_RT on PowerPC PPC440 Linux-2.6.29-rc7
From: srikanth krishnakar @ 2009-03-17 14:54 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]
Hi all,
Just managed to compile PREEMPT_RT on Linux-2.6.29-rc7 PowerPC, I used
following patches from broken package of RT
(Patch-2.6.26.8-rt16-broken-out.tar.gz) , Need to investigate further with
respect to HRT,
patches/patch-2.6.29-rc7
patches/patch-2.6.29-rc7-rt1.patch
patches/percpu-locked-powerpc-fixups.patch
patches/powerpc-02-make-the-irq-reverse-mapping-radix-tree-lockless.patch
patches/powerpc-ftrace-stop-on-oops.patch
patches/powerpc-match-__rw_yield-function-declaration-to-prototype.patch
patches/ppc32-latency-compile-hack-fixes.patch
patches/ppc32_notrace_init_functions.patch
patches/ppc64-fix-preempt-unsafe-paths-accessing-per_cpu-variables.patch
patches/ppc-gtod-notrace-fix.patch
patches/ppc-hacks-to-allow-rt-to-run-kernbench.patch
patches/ppc-make-tlb-batch-64-only.patch
patches/ppc-remove-duplicate-save-stack-trace.patch
patches/ppc-tlbflush-preempt.patch
patches/preempt-irqs-ppc-ack-irq-fixups.patch
patches/preempt-irqs-ppc-fix-b5.patch
patches/preempt-irqs-ppc-fix-more-fasteoi.patch
patches/preempt-realtime-powerpc-add-raw-relax-macros.patch
patches/preempt-realtime-powerpc-b2.patch
patches/preempt-realtime-powerpc-b3.patch
patches/preempt-realtime-powerpc-b4.patch
patches/preempt-realtime-powerpc-celleb-raw-spinlocks.patch
patches/preempt-realtime-powerpc.patch
patches/preempt-realtime-powerpc-tlb-batching.patch
patches/preempt-realtime-powerpc-update.patch
patches/preempt-irqs-ppc-fix-b6.patch
patches/preempt-irqs-ppc.patch
patches/preempt-irqs-ppc-preempt-schedule-irq-entry-fix.patch
patches/rt-mutex-ppc-fix-a5.patch
patches/rt-mutex-ppc.patch
Please reply back, If anybody working on this !!! Or if anything is missing
from this pls. let me know.
Regards
Srikanth
**********
[-- Attachment #2: Type: text/html, Size: 4453 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/86xx: Board support for GE Fanuc's PPC9A
From: Kumar Gala @ 2009-03-17 13:59 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <49BF6D55.7020108@gefanuc.com>
On Mar 17, 2009, at 4:28 AM, Martyn Welch wrote:
>>>
>>> + i2c1: i2c@3000 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + compatible = "fsl-i2c";
>> This should list include a compatible string specific to the
>> particular SoC model before the general name.
>
> The documentation seems to suggest to use "fsl-i2c". Should it be
> like this?:
>
> compatible = "fsl,mpc8641d-i2c", fsl-i2c";
in theory it should be, in practice don't bother.
- k
^ permalink raw reply
* Re: [PATCH 0/4] NAND: Multi-chip support for FSL-UPM for TQM8548 modules
From: Kumar Gala @ 2009-03-17 13:56 UTC (permalink / raw)
To: Wolfgang Grandegegr; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <1237281143-8768-1-git-send-email-wg@grandegger.com>
On Mar 17, 2009, at 4:12 AM, Wolfgang Grandegegr wrote:
> The following patch series adds generic support for multi-chip NAND
> devices
> to the FSL-UPM driver and support for the Micron MT29F8G08FAB NAND
> flash
> memory on the TQM8548 modules:
>
> [PATCH 1/4] NAND: FSL-UPM: add multi chip support
> [PATCH 2/4] NAND: FSL-UPM: add support for selecting chips via MAR
> [PATCH 3/4] NAND: FSL-UPM: Add wait flags to support board/chip
> specific delays
> [PATCH 4/4] powerpc/85xx: TQM8548: Update DTS file for multi-chip
> support
>
> Wolfgang.
You need to update:
Documentation/powerpc/dts-bindings/fsl/upm-nand.txt
I see some new properties defined in this code and not documented ;)
- k
^ permalink raw reply
* oops w/genphy & gianfar.. on MPC8315 RDB
From: Kumar Gala @ 2009-03-17 13:55 UTC (permalink / raw)
To: Andy Fleming; +Cc: LinuxPPC Mailing List
Andy,
Any ideas what's going on here? I'm trying to use top of Linus + PPC
next. Top of Linus doesn't show this.
- k
Setting up networking on eth0:
------------[ cut here ]------------
Kernel BUG at c0192e48 [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
MPC831x RDB
Modules linked in:
NIP: c0192e48 LR: c01936a8 CTR: c0194870
REGS: c4c9dc90 TRAP: 0700 Not tainted (2.6.29-rc8-00280-g242497a)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 84008228 XER: 00000000
TASK = c7469bd0[874] 'ifconfig' THREAD: c4c9c000
GPR00: 00000001 c4c9dd40 c7469bd0 c7462000 00000100 0000000f ffffffff
00000000
GPR08: 00000220 00000000 fffee0bf 00000100 84002228 100237d4 07ff9000
00000000
GPR16: 00000000 07fedc44 07fedc44 07fedc44 c7462000 ffff8914 c74603a0
c74603ac
GPR24: c74621e8 c78c0e20 c9018000 c7462000 c7462000 c7462360 c6e3f800
c7462360
NIP [c0192e48] startup_gfar+0x54/0x644
LR [c01936a8] gfar_enet_open+0x270/0x478
Call Trace:
[c4c9dd40] [c019be04] genphy_config_init+0xa4/0xc8 (unreliable)
[c4c9dd80] [c01936a8] gfar_enet_open+0x270/0x478
[c4c9ddb0] [c02238e8] dev_open+0xc0/0x124
[c4c9ddd0] [c0223048] dev_change_flags+0x90/0x1d4
[c4c9ddf0] [c0266a68] devinet_ioctl+0x700/0x7ac
[c4c9de60] [c0267b3c] inet_ioctl+0xcc/0xf8
[c4c9de70] [c0211afc] sock_ioctl+0x60/0x2c8
[c4c9de90] [c0099418] vfs_ioctl+0x34/0x90
[c4c9dea0] [c0099524] do_vfs_ioctl+0x8c/0x704
[c4c9df10] [c0099bdc] sys_ioctl+0x40/0x88
[c4c9df40] [c001167c] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff69268
LR = 0xffecdec
Instruction dump:
90010008 835d007c 7c0004ac 901a0014 3b0301e8 817d001c 2e180000 809d0068
4192052c 812302bc 7d200034 5400d97e <0f000000> 81290000 7c845a14
7f03c378
---[ end trace fca8f422a0a9a061 ]---
Trace/breakpoint trap
^ permalink raw reply
* Re: [PATCH] powerpc: Enable CPU_FTR_NEED_COHERENT for MPC52xx
From: Kumar Gala @ 2009-03-17 13:49 UTC (permalink / raw)
To: Grant Likely; +Cc: LinuxPPC Mailing List, Piotr Ziecik
In-Reply-To: <fa686aa40903170645p43aa4790ve4f48ea472751987@mail.gmail.com>
On Mar 17, 2009, at 8:45 AM, Grant Likely wrote:
> On Tue, Mar 17, 2009 at 6:10 AM, Kumar Gala
> <kumar.gala@freescale.com> wrote:
>> On Mar 16, 2009, at 11:43 PM, Grant Likely wrote:
>>> diff --git a/arch/powerpc/include/asm/cputable.h
>>> b/arch/powerpc/include/asm/cput
>>> index 4911104..48d7f5f 100644
>>> --- a/arch/powerpc/include/asm/cputable.h
>>> +++ b/arch/powerpc/include/asm/cputable.h
>>> @@ -348,8 +348,15 @@ extern const char *powerpc_base_platform;
>>> CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
>>> #define CPU_FTRS_82XX (CPU_FTR_COMMON | \
>>> CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB)
>>> +
>>> +#if defined(CONFIG_PPC_MPC52xx)
>>> +#define CPU_FTRS_G2_LE (CPU_FTR_COMMON | CPU_FTR_MAYBE_CAN_DOZE | \
>>> + CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP |
>>> CPU_FTR_NEED_COHERENT)
>>> +#else
>>> #define CPU_FTRS_G2_LE (CPU_FTR_COMMON | CPU_FTR_MAYBE_CAN_DOZE | \
>>> CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP)
>>> +#endif
>>> +
>>> #define CPU_FTRS_E300 (CPU_FTR_MAYBE_CAN_DOZE | \
>>> CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP | \
>>> CPU_FTR_COMMON)
>>
>> Doing this via a static CPU FTR fixup isn't really the best way to
>> handle
>> it. I was thinking about this the other day in my patch to
>> actually make
>> G2/e300 cores respect _PAGE_COHERENT. We really should set this
>> via a
>> platform fixup. Just not sure if that's soon enough.
>
> I agree, but as Ben pointed out last night on IRC, feature fixup
> (early_init) occurs well before platform probe time. Platform code
> cannot fix it up until someone does the work of making platform probe
> time earlier. It's non-trivial.
>
> However, I need to get a fix in for this ASAP, otherwise the 5200 will
> be broken in 2.6.29. I don't see this patch as a final solution, but
> it works as a stop-gap until platform probing can be reworked.
So for .29 lets just go with the easy solution of adding
CONFIG_PPC_MPC52xx to the list that set CPU_FTR_NEED_COHERENT (10x,
83xx, etc..).
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Enable CPU_FTR_NEED_COHERENT for MPC52xx
From: Grant Likely @ 2009-03-17 13:45 UTC (permalink / raw)
To: Kumar Gala; +Cc: LinuxPPC Mailing List, Piotr Ziecik
In-Reply-To: <396BE890-40BF-451E-AE3E-2E2E1D440951@freescale.com>
On Tue, Mar 17, 2009 at 6:10 AM, Kumar Gala <kumar.gala@freescale.com> wrot=
e:
> On Mar 16, 2009, at 11:43 PM, Grant Likely wrote:
>> diff --git a/arch/powerpc/include/asm/cputable.h
>> b/arch/powerpc/include/asm/cput
>> index 4911104..48d7f5f 100644
>> --- a/arch/powerpc/include/asm/cputable.h
>> +++ b/arch/powerpc/include/asm/cputable.h
>> @@ -348,8 +348,15 @@ extern const char *powerpc_base_platform;
>> =A0 =A0 =A0 =A0 =A0 CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
>> #define CPU_FTRS_82XX =A0(CPU_FTR_COMMON | \
>> =A0 =A0 =A0 =A0 =A0 CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB)
>> +
>> +#if defined(CONFIG_PPC_MPC52xx)
>> +#define CPU_FTRS_G2_LE (CPU_FTR_COMMON | CPU_FTR_MAYBE_CAN_DOZE | \
>> + =A0 =A0 =A0 =A0 =A0 CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP |
>> CPU_FTR_NEED_COHERENT)
>> +#else
>> #define CPU_FTRS_G2_LE (CPU_FTR_COMMON | CPU_FTR_MAYBE_CAN_DOZE | \
>> =A0 =A0 =A0 =A0 =A0 CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP)
>> +#endif
>> +
>> #define CPU_FTRS_E300 =A0(CPU_FTR_MAYBE_CAN_DOZE | \
>> =A0 =A0 =A0 =A0 =A0 CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP | \
>> =A0 =A0 =A0 =A0 =A0 CPU_FTR_COMMON)
>
> Doing this via a static CPU FTR fixup isn't really the best way to handle
> it. =A0I was thinking about this the other day in my patch to actually ma=
ke
> G2/e300 cores respect _PAGE_COHERENT. =A0We really should set this via a
> platform fixup. =A0Just not sure if that's soon enough.
I agree, but as Ben pointed out last night on IRC, feature fixup
(early_init) occurs well before platform probe time. Platform code
cannot fix it up until someone does the work of making platform probe
time earlier. It's non-trivial.
However, I need to get a fix in for this ASAP, otherwise the 5200 will
be broken in 2.6.29. I don't see this patch as a final solution, but
it works as a stop-gap until platform probing can be reworked.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH v3 4/4] powerpc/mm: e300c2/c3/c4 TLB errata workaround
From: Kumar Gala @ 2009-03-17 13:15 UTC (permalink / raw)
Cc: linuxppc-dev
Complete workaround for DTLB errata in e300c2/c3/c4 processors.
Due to the bug, the hardware-implemented LRU algorythm always goes to way
1 of the TLB. This fix implements the proposed software workaround in
form of a LRW table for chosing the TLB-way.
Based on patch from David Jander <david@protonic.nl>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
* use SPRG4 instead of SPRG6 (6 was random, so use next free SPRG)
* init SPRG4 to 0 before we use it
arch/powerpc/include/asm/mmu.h | 6 ++++++
arch/powerpc/kernel/cputable.c | 9 ++++++---
arch/powerpc/kernel/head_32.S | 36 ++++++++++++++++++++++++++++++++----
3 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 10476a8..cbf1543 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -46,6 +46,12 @@
*/
#define MMU_FTR_LOCK_BCAST_INVAL ASM_CONST(0x00100000)
+/* This indicates that the processor doesn't handle way selection
+ * properly and needs SW to track and update the LRU state. This
+ * is specific to an errata on e300c2/c3/c4 class parts
+ */
+#define MMU_FTR_NEED_DTLB_SW_LRU ASM_CONST(0x00200000)
+
#ifndef __ASSEMBLY__
#include <asm/cputable.h>
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index ccea243..cd1b687 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1090,7 +1090,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_name = "e300c2",
.cpu_features = CPU_FTRS_E300C2,
.cpu_user_features = PPC_FEATURE_32 | PPC_FEATURE_HAS_MMU,
- .mmu_features = MMU_FTR_USE_HIGH_BATS,
+ .mmu_features = MMU_FTR_USE_HIGH_BATS |
+ MMU_FTR_NEED_DTLB_SW_LRU,
.icache_bsize = 32,
.dcache_bsize = 32,
.cpu_setup = __setup_cpu_603,
@@ -1103,7 +1104,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_name = "e300c3",
.cpu_features = CPU_FTRS_E300,
.cpu_user_features = COMMON_USER,
- .mmu_features = MMU_FTR_USE_HIGH_BATS,
+ .mmu_features = MMU_FTR_USE_HIGH_BATS |
+ MMU_FTR_NEED_DTLB_SW_LRU,
.icache_bsize = 32,
.dcache_bsize = 32,
.cpu_setup = __setup_cpu_603,
@@ -1118,7 +1120,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_name = "e300c4",
.cpu_features = CPU_FTRS_E300,
.cpu_user_features = COMMON_USER,
- .mmu_features = MMU_FTR_USE_HIGH_BATS,
+ .mmu_features = MMU_FTR_USE_HIGH_BATS |
+ MMU_FTR_NEED_DTLB_SW_LRU,
.icache_bsize = 32,
.dcache_bsize = 32,
.cpu_setup = __setup_cpu_603,
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index 58dcc7c..1475ad5 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -153,6 +153,10 @@ __start:
*/
bl mmu_off
__after_mmu_off:
+BEGIN_MMU_FTR_SECTION
+ li r10,0
+ mtspr SPRN_SPRG4,r10 /* init SW LRU tracking */
+END_MMU_FTR_SECTION_IFSET(MMU_FTR_NEED_DTLB_SW_LRU)
bl clear_bats
bl flush_tlbs
@@ -593,9 +597,21 @@ BEGIN_FTR_SECTION
rlwinm r1,r1,0,~_PAGE_COHERENT /* clear M (coherence not required) */
END_FTR_SECTION_IFCLR(CPU_FTR_NEED_COHERENT)
mtspr SPRN_RPA,r1
+ mfspr r2,SPRN_SRR1 /* Need to restore CR0 */
+ mtcrf 0x80,r2
+BEGIN_MMU_FTR_SECTION
+ li r0,1
+ mfspr r1,SPRN_SPRG4
+ rlwinm r2,r3,20,27,31 /* Get Address bits 15:19 */
+ slw r0,r0,r2
+ xor r1,r0,r1
+ srw r0,r1,r2
+ mtspr SPRN_SPRG4,r1
+ mfspr r2,SPRN_SRR1
+ rlwimi r2,r0,31-14,14,14
+ mtspr SPRN_SRR1,r2
+END_MMU_FTR_SECTION_IFSET(MMU_FTR_NEED_DTLB_SW_LRU)
tlbld r3
- mfspr r3,SPRN_SRR1 /* Need to restore CR0 */
- mtcrf 0x80,r3
rfi
DataAddressInvalid:
mfspr r3,SPRN_SRR1
@@ -661,9 +677,21 @@ BEGIN_FTR_SECTION
rlwinm r1,r1,0,~_PAGE_COHERENT /* clear M (coherence not required) */
END_FTR_SECTION_IFCLR(CPU_FTR_NEED_COHERENT)
mtspr SPRN_RPA,r1
+ mfspr r2,SPRN_SRR1 /* Need to restore CR0 */
+ mtcrf 0x80,r2
+BEGIN_MMU_FTR_SECTION
+ li r0,1
+ mfspr r1,SPRN_SPRG4
+ rlwinm r2,r3,20,27,31 /* Get Address bits 15:19 */
+ slw r0,r0,r2
+ xor r1,r0,r1
+ srw r0,r1,r2
+ mtspr SPRN_SPRG4,r1
+ mfspr r2,SPRN_SRR1
+ rlwimi r2,r0,31-14,14,14
+ mtspr SPRN_SRR1,r2
+END_MMU_FTR_SECTION_IFSET(MMU_FTR_NEED_DTLB_SW_LRU)
tlbld r3
- mfspr r3,SPRN_SRR1 /* Need to restore CR0 */
- mtcrf 0x80,r3
rfi
#ifndef CONFIG_ALTIVEC
--
1.5.6.6
^ permalink raw reply related
* Re: [RFC][PATCH v5] MPC5121 TLB errata workaround
From: Kumar Gala @ 2009-03-17 12:43 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-dev, Paul Mackerras, Wolfgang Denk, gunnar
In-Reply-To: <200903171138.42814.david.jander@protonic.nl>
On Mar 17, 2009, at 5:38 AM, David Jander wrote:
> On Monday 16 March 2009 19:05:00 Kumar Gala wrote:
>> On Mar 16, 2009, at 10:52 AM, David Jander wrote:
>>> Complete workaround for DTLB errata in e300c2/c3/c4 processors.
>>>
>>> Due to the bug, the hardware-implemented LRU algorythm always goes
>>> to way
>>> 1 of the TLB. This fix implements the proposed software workaround
>>> in
>>> form of a LRW table for chosing the TLB-way.
>>>
>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>> Signed-off-by: David Jander <david@protonic.nl>
>>>
>>> ---
>>> diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/
>>> head_32.S
>>> index 0f4fac5..3971ee4 100644
>>> --- a/arch/powerpc/kernel/head_32.S
>>> +++ b/arch/powerpc/kernel/head_32.S
>>> @@ -578,9 +578,21 @@ DataLoadTLBMiss:
>>> andc r1,r3,r1 /* PP = user? (rw&dirty? 2: 3): 0 */
>>> mtspr SPRN_RPA,r1
>>> mfspr r3,SPRN_DMISS
>>> + mfspr r2,SPRN_SRR1 /* Need to restore CR0 */
>>> + mtcrf 0x80,r2
>>> +#ifdef CONFIG_PPC_MPC512x
>>> + li r0,1
>>> + mfspr r1,SPRN_SPRG6
>>> + rlwinm r2,r3,17,27,31 /* Get Address bits 19:15 */
>>
>> Don't we want:
>> rlwinm r2,r3,20,27,31 /* Get address bits 15:19 */
>
> Hmm, you are right, I must have accidentally counted LE bit-
> ordering ;-)
> Only funny part is, that I don't measure any performance difference
> after
> fixing this.... *sigh*.
I wouldn't expect it to. You are picking some bits to hash on. You
picked some different bits but the distribution of addresses was
probably similiar.
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Enable CPU_FTR_NEED_COHERENT for MPC52xx
From: Kumar Gala @ 2009-03-17 12:10 UTC (permalink / raw)
To: Grant Likely; +Cc: LinuxPPC Mailing List, Piotr Ziecik
In-Reply-To: <fa686aa40903162143j5f641d7dob53b96b681737e07@mail.gmail.com>
On Mar 16, 2009, at 11:43 PM, Grant Likely wrote:
> On Mon, Mar 16, 2009 at 9:54 PM, Grant Likely <grant.likely@secretlab.ca
> > wrote:
>> On Mon, Mar 16, 2009 at 4:05 AM, Piotr Ziecik <kosmo@semihalf.com>
>> wrote:
>>> BestComm, a DMA engine in MPC52xx SoC, requires snooping when
>>> CPU caches are enabled to work properly.
>>>
>>> Adding CPU_FTR_NEED_COHERENT fixes NFS problems on MPC52xx machines
>>> introduced by 'powerpc/mm: Fix handling of _PAGE_COHERENT in BAT
>>> setup code'.
>>> [...]
>>> #if defined(CONFIG_SMP) || defined(CONFIG_MPC10X_BRIDGE) \
>>> - || defined(CONFIG_PPC_83xx) || defined(CONFIG_8260)
>>> + || defined(CONFIG_PPC_83xx) || defined(CONFIG_8260) \
>>> + || defined(CONFIG_PPC_MPC52xx)
>>> #define CPU_FTR_COMMON CPU_FTR_NEED_COHERENT
>>> #else
>>> #define CPU_FTR_COMMON 0
>>
>> Aside from the fact that MPC10X_BRIDGE, PPC83xx and 8260 are already
>> doing it, adding the feature bit this way isn't multiplatform
>> friendly. Essentially it means that all selected platforms will have
>> CPU_FTR_NEED_COHERENT enabled if CONFIG_PPC_MPC52xx is enabled.
>
> Here's my counter-patch. It contains the change to just G2_LE cores
> when MPC52xx is selected. However, this change will also affect some
> of the MPC82xx parts. However CPU_FTR_NEED_COHERENT shouldn't
> actually hurt anything, so maybe it would be better to just enable it
> unconditionally for the G2_LE core.
>
> Kumar/Ben, thoughts?
>
> g.
>
> ---
>
> diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/
> include/asm/cput
> index 4911104..48d7f5f 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -348,8 +348,15 @@ extern const char *powerpc_base_platform;
> CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
> #define CPU_FTRS_82XX (CPU_FTR_COMMON | \
> CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB)
> +
> +#if defined(CONFIG_PPC_MPC52xx)
> +#define CPU_FTRS_G2_LE (CPU_FTR_COMMON | CPU_FTR_MAYBE_CAN_DOZE | \
> + CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP |
> CPU_FTR_NEED_COHERENT)
> +#else
> #define CPU_FTRS_G2_LE (CPU_FTR_COMMON | CPU_FTR_MAYBE_CAN_DOZE | \
> CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP)
> +#endif
> +
> #define CPU_FTRS_E300 (CPU_FTR_MAYBE_CAN_DOZE | \
> CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP | \
> CPU_FTR_COMMON)
Doing this via a static CPU FTR fixup isn't really the best way to
handle it. I was thinking about this the other day in my patch to
actually make G2/e300 cores respect _PAGE_COHERENT. We really should
set this via a platform fixup. Just not sure if that's soon enough.
- k
^ permalink raw reply
* MPC5200 SPI
From: Gary Thomas @ 2009-03-17 11:07 UTC (permalink / raw)
To: Linux PPC Development
I'm trying to use the PSC/SPI driver on my MPC5200 board
'drivers/spi/mpc52xx_psc_spi.c' My kernel is 2.6.28, but
I don't see any changes in this area in the latest ones.
Cribbing from the Lite5200, I put this in my DTS file:
// PSC6 => SPI
spi@2c00 { // PSC6
compatible = "fsl,mpc5200-psc-spi";
cell-index = <5>;
reg = <0x2c00 0x100>;
interrupts = <2 4 0>;
interrupt-parent = <&mpc5200_pic>;
};
I added the SPI device I'm working with (I have to write
this driver, so don't go looking for it). This was added
within the spi@2c00 node, much like various I2C devices, etc.
temp@spi {
compatible = "maxim,max6629";
};
Sadly, the SPI master driver seems 100% oblivious to this.
I found the call of_register_spi_devices (drivers/of/of_spi.c),
but it is only used by the xilinx SPI master. Also, I didn't
find any slave examples anywhere.
Is this driver (SPI on MPC5200) supposed to work?
If so, what am I missing to get it set up?
If not, what needs to be done to get it there?
Thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: [RFC][PATCH v5] MPC5121 TLB errata workaround
From: David Jander @ 2009-03-17 10:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, Wolfgang Denk, gunnar
In-Reply-To: <FDDCB39D-E847-4627-B6F8-404A40D1C0C7@kernel.crashing.org>
On Monday 16 March 2009 19:05:00 Kumar Gala wrote:
> On Mar 16, 2009, at 10:52 AM, David Jander wrote:
> > Complete workaround for DTLB errata in e300c2/c3/c4 processors.
> >
> > Due to the bug, the hardware-implemented LRU algorythm always goes
> > to way
> > 1 of the TLB. This fix implements the proposed software workaround in
> > form of a LRW table for chosing the TLB-way.
> >
> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> > Signed-off-by: David Jander <david@protonic.nl>
> >
> > ---
> > diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/
> > head_32.S
> > index 0f4fac5..3971ee4 100644
> > --- a/arch/powerpc/kernel/head_32.S
> > +++ b/arch/powerpc/kernel/head_32.S
> > @@ -578,9 +578,21 @@ DataLoadTLBMiss:
> > andc r1,r3,r1 /* PP = user? (rw&dirty? 2: 3): 0 */
> > mtspr SPRN_RPA,r1
> > mfspr r3,SPRN_DMISS
> > + mfspr r2,SPRN_SRR1 /* Need to restore CR0 */
> > + mtcrf 0x80,r2
> > +#ifdef CONFIG_PPC_MPC512x
> > + li r0,1
> > + mfspr r1,SPRN_SPRG6
> > + rlwinm r2,r3,17,27,31 /* Get Address bits 19:15 */
>
> Don't we want:
> rlwinm r2,r3,20,27,31 /* Get address bits 15:19 */
Hmm, you are right, I must have accidentally counted LE bit-ordering ;-)
Only funny part is, that I don't measure any performance difference after
fixing this.... *sigh*.
Regards,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/86xx: Board support for GE Fanuc's PPC9A
From: Martyn Welch @ 2009-03-17 9:28 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20090317013918.GA9643@yookeroo.seuss>
David Gibson wrote:
> On Mon, Mar 16, 2009 at 10:32:18AM +0000, Martyn Welch wrote:
>> Support for the PPC9A VME Single Board Computer from GE Fanuc (PowerPC
>> MPC8641D).
>>
>> This is the basic board support for GE Fanuc's PPC9A, a 6U single board
>> computer, based on Freescale's MPC8641D.
>
> Uh.. sorry. Should have noticed these little nitpicks the first time
> around.
>
No problem, just a few queries.
>> + localbus@fef05000 {
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + compatible = "fsl,mpc8641-localbus", "simple-bus";
>> + reg = <0xfef05000 0x1000>;
>> + interrupts = <19 2>;
>> + interrupt-parent = <&mpic>;
>> +
>> + ranges = <0 0 0xff000000 0x01000000 // 16MB Boot flash
>> + 1 0 0xe8000000 0x08000000 // Paged Flash 0
>> + 2 0 0xe0000000 0x08000000 // Paged Flash 1
>> + 3 0 0xfc100000 0x00020000 // NVRAM
>> + 4 0 0xfc000000 0x00008000 // FPGA
>> + 5 0 0xfc008000 0x00008000 // AFIX FPGA
>> + 6 0 0xfd000000 0x00800000 // IO FPGA (8-bit)
>> + 7 0 0xfd800000 0x00800000>; // IO FPGA (32-bit)
>> +
>> + /* flash@0,0 is a mirror of part of the memory in flash@1,0
>> + flash@0,0 {
>> + compatible = "cfi-flash";
>
> It would be nice to have the actual type of flash chips here, although
> it's not essential.
>
Flash is a little tricky, it's paged. We haven't found a good way of dealing with this yet and as a result we currently just support the first page, which may not even match one full chip width. This is especially so for flash@0,0, which is mirrored via an FPGA, the exact region depends on some jumper settings and is access is definitely read only via this region (this region is commented out in the DTS and really there for completeness as we don't expect to ever use it or enable it from Linux and is only there to all the firmware to boot). We are currently using Spansion s29gl01gp parts, which have some tricky mechanisms for sector protection (given that the parts are paged). As a result, providing the specific chip won't be much use, if a specific driver is written for spansion flash the spansion specific mechanisms are unlikely to work.
If you still want the specific chip, how about this:
compatible = "spansion, s29gl01gp", "cfi-flash";
> [snip]
>> + fpga@4,0 {
>> + compatible = "gef,fpga-regs";
>
> I don't imagine this is the only set of FPGA based control regs GE
> Fanuc will ever make, so this should be more precise. Including the
> board type here is probably the way to go.
>
OK.
compatible = "gef,fpga-regs-ppc9a";
>> + reg = <0x4 0x0 0x40>;
>> + };
>> +
>> + wdt@4,2000 {
>> + compatible = "gef,fpga-wdt";
>
> And likewise here.
>
We only have one core that is used on all our sites current and planned boards (as far as I know). How about (idea borrowed from virtex440-ml507.dts):
compatible = "gef,fpga-wdt-1.00";
>> + reg = <0x4 0x2000 0x8>;
>> + interrupts = <0x1a 0x4>;
>> + interrupt-parent = <&gef_pic>;
>> + };
>> + /* Second watchdog available, driver currently supports one.
>> + wdt@4,2010 {
>> + compatible = "gef,fpga-wdt";
>> + reg = <0x4 0x2010 0x8>;
>> + interrupts = <0x1b 0x4>;
>> + interrupt-parent = <&gef_pic>;
>> + };
>> + */
>> + gef_pic: pic@4,4000 {
>> + #interrupt-cells = <1>;
>> + interrupt-controller;
>> + compatible = "gef,fpga-pic";
>
> And possibly here, although in this case I imagine several boards
> might have compatible FPGA PICs.
>
Yes, the same design is used on all the new boards I know about. As with the watchdog, boards in the future may have different designs. Would this be acceptable?:
compatible = "gef,fpga-pic-1.00";
>> + i2c1: i2c@3000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "fsl-i2c";
>
> This should list include a compatible string specific to the
> particular SoC model before the general name.
>
The documentation seems to suggest to use "fsl-i2c". Should it be like this?:
compatible = "fsl,mpc8641d-i2c", fsl-i2c";
Martyn
--
Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd, |Registered in England and Wales
Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 729849476
^ permalink raw reply
* [PATCH 3/4] NAND: FSL-UPM: Add wait flags to support board/chip specific delays
From: Wolfgang Grandegegr @ 2009-03-17 9:12 UTC (permalink / raw)
To: linux-mtd; +Cc: linuxppc-dev
In-Reply-To: <1237281143-8768-3-git-send-email-wg@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
The NAND flash on the TQM8548_BE modules requires a short delay after
running the UPM pattern. The TQM8548_BE requires a further short delay
after writing out a buffer. Normally the R/B pin should be checked, but
it's not connected on the TQM8548_BE. The existing driver uses similar
fixed delay points. To manage these extra delays in a more general way,
I introduced the "wait_flags" field allowing the board-specific driver
to specify various types of extra delay.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
drivers/mtd/nand/fsl_upm.c | 20 ++++++++++++++++++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/fsl_upm.c b/drivers/mtd/nand/fsl_upm.c
index f42955c..0ffc872 100644
--- a/drivers/mtd/nand/fsl_upm.c
+++ b/drivers/mtd/nand/fsl_upm.c
@@ -25,6 +25,10 @@
#define FSL_UPM_NAND_MAX_CHIPS 4
+#define FSL_UPM_WAIT_RUN_PATTERN 0x1
+#define FSL_UPM_WAIT_WRITE_BYTE 0x2
+#define FSL_UPM_WAIT_WRITE_BUFFER 0x4
+
struct fsl_upm_nand {
struct device *dev;
struct mtd_info mtd;
@@ -44,6 +48,7 @@ struct fsl_upm_nand {
uint32_t max_chips;
uint32_t chip_number;
uint32_t chip_offset;
+ uint32_t wait_flags;
};
#define to_fsl_upm_nand(mtd) container_of(mtd, struct fsl_upm_nand, mtd)
@@ -101,7 +106,8 @@ static void fun_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
}
fsl_upm_run_pattern(&fun->upm, chip->IO_ADDR_R, mar);
- fun_wait_rnb(fun);
+ if (fun->wait_flags & FSL_UPM_WAIT_RUN_PATTERN)
+ fun_wait_rnb(fun);
}
static void fun_select_chip(struct mtd_info *mtd, int chip_nr)
@@ -143,8 +149,11 @@ static void fun_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
for (i = 0; i < len; i++) {
out_8(fun->chip.IO_ADDR_W, buf[i]);
- fun_wait_rnb(fun);
+ if (fun->wait_flags & FSL_UPM_WAIT_WRITE_BYTE)
+ fun_wait_rnb(fun);
}
+ if (fun->wait_flags & FSL_UPM_WAIT_WRITE_BUFFER)
+ fun_wait_rnb(fun);
}
static int __devinit fun_chip_init(struct fsl_upm_nand *fun,
@@ -293,6 +302,13 @@ static int __devinit fun_probe(struct of_device *ofdev,
if (prop && size == sizeof(uint32_t))
fun->chip_offset = *prop;
+ prop = of_get_property(ofdev->node, "wait-flags", &size);
+ if (prop && size == sizeof(uint32_t))
+ fun->wait_flags = *prop;
+ else
+ fun->wait_flags = (FSL_UPM_WAIT_RUN_PATTERN |
+ FSL_UPM_WAIT_WRITE_BYTE);
+
fun->io_base = devm_ioremap_nocache(&ofdev->dev, io_res.start,
io_res.end - io_res.start + 1);
if (!fun->io_base) {
--
1.6.0.6
^ permalink raw reply related
* [PATCH 2/4] NAND: FSL-UPM: add support for selecting chips via MAR
From: Wolfgang Grandegegr @ 2009-03-17 9:12 UTC (permalink / raw)
To: linux-mtd; +Cc: linuxppc-dev
In-Reply-To: <1237281143-8768-2-git-send-email-wg@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
For the NAND chips on the TQM8548 modules, a special chip-select logic is
used. It uses dedicated address lines to be set via UPM machine address
register (mar). This patch also adds that support to the FSL-UPM driver.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
arch/powerpc/sysdev/fsl_lbc.c | 2 +-
drivers/mtd/nand/fsl_upm.c | 13 ++++++++++++-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
index 0494ee5..dceb8d1 100644
--- a/arch/powerpc/sysdev/fsl_lbc.c
+++ b/arch/powerpc/sysdev/fsl_lbc.c
@@ -150,7 +150,7 @@ int fsl_upm_run_pattern(struct fsl_upm *upm, void __iomem *io_base, u32 mar)
spin_lock_irqsave(&fsl_lbc_lock, flags);
- out_be32(&fsl_lbc_regs->mar, mar << (32 - upm->width));
+ out_be32(&fsl_lbc_regs->mar, mar);
switch (upm->width) {
case 8:
diff --git a/drivers/mtd/nand/fsl_upm.c b/drivers/mtd/nand/fsl_upm.c
index ca7e85a..f42955c 100644
--- a/drivers/mtd/nand/fsl_upm.c
+++ b/drivers/mtd/nand/fsl_upm.c
@@ -37,6 +37,7 @@ struct fsl_upm_nand {
struct fsl_upm upm;
uint8_t upm_addr_offset;
uint8_t upm_cmd_offset;
+ uint32_t upm_mar_chip_offset;
void __iomem *io_base;
int rnb_gpio[FSL_UPM_NAND_MAX_CHIPS];
int chip_delay;
@@ -74,7 +75,9 @@ static void fun_wait_rnb(struct fsl_upm_nand *fun)
static void fun_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
{
+ struct nand_chip *chip = mtd->priv;
struct fsl_upm_nand *fun = to_fsl_upm_nand(mtd);
+ u32 mar;
if (!(ctrl & fun->last_ctrl)) {
fsl_upm_end_pattern(&fun->upm);
@@ -92,7 +95,11 @@ static void fun_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
fsl_upm_start_pattern(&fun->upm, fun->upm_cmd_offset);
}
- fsl_upm_run_pattern(&fun->upm, fun->io_base, cmd);
+ mar = cmd << (32 - fun->upm.width);
+ if (fun->upm_mar_chip_offset && fun->chip_number > 0) {
+ mar |= fun->chip_number * fun->upm_mar_chip_offset;
+ }
+ fsl_upm_run_pattern(&fun->upm, chip->IO_ADDR_R, mar);
fun_wait_rnb(fun);
}
@@ -244,6 +251,10 @@ static int __devinit fun_probe(struct of_device *ofdev,
}
fun->upm_cmd_offset = *prop;
+ prop = of_get_property(ofdev->node, "fsl,upm-mar-chip-offset", &size);
+ if (prop && size == sizeof(uint32_t))
+ fun->upm_mar_chip_offset = *prop;
+
prop = of_get_property(ofdev->node, "max-chips", &size);
if (prop && size == sizeof(uint32_t)) {
fun->max_chips = *prop;
--
1.6.0.6
^ permalink raw reply related
* [PATCH 1/4] NAND: FSL-UPM: add multi chip support
From: Wolfgang Grandegegr @ 2009-03-17 9:12 UTC (permalink / raw)
To: linux-mtd; +Cc: linuxppc-dev
In-Reply-To: <1237281143-8768-1-git-send-email-wg@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
This patch adds support for multi-chip NAND devices to the FSL-UPM
driver. This requires support for multiple GPIOs for the RNB pins.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
drivers/mtd/nand/fsl_upm.c | 90 +++++++++++++++++++++++++++++++++----------
1 files changed, 69 insertions(+), 21 deletions(-)
diff --git a/drivers/mtd/nand/fsl_upm.c b/drivers/mtd/nand/fsl_upm.c
index 7815a40..ca7e85a 100644
--- a/drivers/mtd/nand/fsl_upm.c
+++ b/drivers/mtd/nand/fsl_upm.c
@@ -23,6 +23,8 @@
#include <linux/io.h>
#include <asm/fsl_lbc.h>
+#define FSL_UPM_NAND_MAX_CHIPS 4
+
struct fsl_upm_nand {
struct device *dev;
struct mtd_info mtd;
@@ -36,8 +38,11 @@ struct fsl_upm_nand {
uint8_t upm_addr_offset;
uint8_t upm_cmd_offset;
void __iomem *io_base;
- int rnb_gpio;
+ int rnb_gpio[FSL_UPM_NAND_MAX_CHIPS];
int chip_delay;
+ uint32_t max_chips;
+ uint32_t chip_number;
+ uint32_t chip_offset;
};
#define to_fsl_upm_nand(mtd) container_of(mtd, struct fsl_upm_nand, mtd)
@@ -46,7 +51,7 @@ static int fun_chip_ready(struct mtd_info *mtd)
{
struct fsl_upm_nand *fun = to_fsl_upm_nand(mtd);
- if (gpio_get_value(fun->rnb_gpio))
+ if (gpio_get_value(fun->rnb_gpio[fun->chip_number]))
return 1;
dev_vdbg(fun->dev, "busy\n");
@@ -55,9 +60,9 @@ static int fun_chip_ready(struct mtd_info *mtd)
static void fun_wait_rnb(struct fsl_upm_nand *fun)
{
- int cnt = 1000000;
- if (fun->rnb_gpio >= 0) {
+ if (fun->rnb_gpio[fun->chip_number] >= 0) {
+ int cnt = 1000000;
while (--cnt && !fun_chip_ready(&fun->mtd))
cpu_relax();
if (!cnt)
@@ -92,6 +97,22 @@ static void fun_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
fun_wait_rnb(fun);
}
+static void fun_select_chip(struct mtd_info *mtd, int chip_nr)
+{
+ struct nand_chip *chip = mtd->priv;
+ struct fsl_upm_nand *fun = to_fsl_upm_nand(mtd);
+
+ if (chip_nr == -1) {
+ chip->cmd_ctrl(mtd, NAND_CMD_NONE, 0 | NAND_CTRL_CHANGE);
+ } else if (chip_nr >= 0) {
+ fun->chip_number = chip_nr;
+ chip->IO_ADDR_R = chip->IO_ADDR_W =
+ fun->io_base + chip_nr * fun->chip_offset;
+ } else {
+ BUG();
+ }
+}
+
static uint8_t fun_read_byte(struct mtd_info *mtd)
{
struct fsl_upm_nand *fun = to_fsl_upm_nand(mtd);
@@ -137,8 +158,10 @@ static int __devinit fun_chip_init(struct fsl_upm_nand *fun,
fun->chip.read_buf = fun_read_buf;
fun->chip.write_buf = fun_write_buf;
fun->chip.ecc.mode = NAND_ECC_SOFT;
+ if (fun->max_chips > 1)
+ fun->chip.select_chip = fun_select_chip;
- if (fun->rnb_gpio >= 0)
+ if (fun->rnb_gpio[0] >= 0)
fun->chip.dev_ready = fun_chip_ready;
fun->mtd.priv = &fun->chip;
@@ -155,7 +178,7 @@ static int __devinit fun_chip_init(struct fsl_upm_nand *fun,
goto err;
}
- ret = nand_scan(&fun->mtd, 1);
+ ret = nand_scan(&fun->mtd, fun->max_chips);
if (ret)
goto err;
@@ -187,6 +210,7 @@ static int __devinit fun_probe(struct of_device *ofdev,
const uint32_t *prop;
int ret;
int size;
+ int i;
fun = kzalloc(sizeof(*fun), GFP_KERNEL);
if (!fun)
@@ -208,7 +232,7 @@ static int __devinit fun_probe(struct of_device *ofdev,
if (!prop || size != sizeof(uint32_t)) {
dev_err(&ofdev->dev, "can't get UPM address offset\n");
ret = -EINVAL;
- goto err2;
+ goto err1;
}
fun->upm_addr_offset = *prop;
@@ -216,21 +240,36 @@ static int __devinit fun_probe(struct of_device *ofdev,
if (!prop || size != sizeof(uint32_t)) {
dev_err(&ofdev->dev, "can't get UPM command offset\n");
ret = -EINVAL;
- goto err2;
+ goto err1;
}
fun->upm_cmd_offset = *prop;
- fun->rnb_gpio = of_get_gpio(ofdev->node, 0);
- if (fun->rnb_gpio >= 0) {
- ret = gpio_request(fun->rnb_gpio, dev_name(&ofdev->dev));
- if (ret) {
- dev_err(&ofdev->dev, "can't request RNB gpio\n");
+ prop = of_get_property(ofdev->node, "max-chips", &size);
+ if (prop && size == sizeof(uint32_t)) {
+ fun->max_chips = *prop;
+ if (fun->max_chips >= FSL_UPM_NAND_MAX_CHIPS) {
+ dev_err(&ofdev->dev, "too much chips");
+ ret = -EINVAL;
+ goto err1;
+ }
+ } else {
+ fun->max_chips = 1;
+ }
+
+ for (i = 0; i < fun->max_chips; i++) {
+ fun->rnb_gpio[i] = of_get_gpio(ofdev->node, i);
+ if (fun->rnb_gpio[i] >= 0) {
+ ret = gpio_request(fun->rnb_gpio[i],
+ dev_name(&ofdev->dev));
+ if (ret) {
+ dev_err(&ofdev->dev, "can't request RNB gpio\n");
+ goto err2;
+ }
+ gpio_direction_input(fun->rnb_gpio[i]);
+ } else if (fun->rnb_gpio[i] == -EINVAL) {
+ dev_err(&ofdev->dev, "specified RNB gpio is invalid\n");
goto err2;
}
- gpio_direction_input(fun->rnb_gpio);
- } else if (fun->rnb_gpio == -EINVAL) {
- dev_err(&ofdev->dev, "specified RNB gpio is invalid\n");
- goto err2;
}
prop = of_get_property(ofdev->node, "chip-delay", NULL);
@@ -239,6 +278,10 @@ static int __devinit fun_probe(struct of_device *ofdev,
else
fun->chip_delay = 50;
+ prop = of_get_property(ofdev->node, "chip-offset", &size);
+ if (prop && size == sizeof(uint32_t))
+ fun->chip_offset = *prop;
+
fun->io_base = devm_ioremap_nocache(&ofdev->dev, io_res.start,
io_res.end - io_res.start + 1);
if (!fun->io_base) {
@@ -257,8 +300,10 @@ static int __devinit fun_probe(struct of_device *ofdev,
return 0;
err2:
- if (fun->rnb_gpio >= 0)
- gpio_free(fun->rnb_gpio);
+ for (i = 0; i < fun->max_chips; i++) {
+ if (fun->rnb_gpio[i] >= 0)
+ gpio_free(fun->rnb_gpio[i]);
+ }
err1:
kfree(fun);
@@ -268,12 +313,15 @@ err1:
static int __devexit fun_remove(struct of_device *ofdev)
{
struct fsl_upm_nand *fun = dev_get_drvdata(&ofdev->dev);
+ int i;
nand_release(&fun->mtd);
kfree(fun->mtd.name);
- if (fun->rnb_gpio >= 0)
- gpio_free(fun->rnb_gpio);
+ for (i = 0; i < fun->max_chips; i++) {
+ if (fun->rnb_gpio[i] >= 0)
+ gpio_free(fun->rnb_gpio[i]);
+ }
kfree(fun);
--
1.6.0.6
^ permalink raw reply related
* [PATCH 4/4] powerpc/85xx: TQM8548: Update DTS file for multi-chip support
From: Wolfgang Grandegegr @ 2009-03-17 9:12 UTC (permalink / raw)
To: linux-mtd; +Cc: linuxppc-dev
In-Reply-To: <1237281143-8768-5-git-send-email-wg@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
This patch adds multi-chip support for the Micron MT29F8G08FAB NAND
flash memory on the TQM8548 modules.
It should go through the powerpc/85xx maintainer.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
arch/powerpc/boot/dts/tqm8548.dts | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/tqm8548.dts b/arch/powerpc/boot/dts/tqm8548.dts
index 81d3fbb..e5c3c67 100644
--- a/arch/powerpc/boot/dts/tqm8548.dts
+++ b/arch/powerpc/boot/dts/tqm8548.dts
@@ -389,6 +389,11 @@
reg = <3 0x0 0x800>;
fsl,upm-addr-offset = <0x10>;
fsl,upm-cmd-offset = <0x08>;
+ wait-flags = <0x05>;
+ /* Multi-chip device */
+ fsl,upm-mar-chip-offset = <0x200>;
+ max-chips = <2>;
+ chip-offset = <0x200>;
chip-delay = <25>; // in micro-seconds
nand@0 {
--
1.6.0.6
^ permalink raw reply related
* [PATCH 4/4] powerpc/85xx: TQM8548: Update DTS file for multi-chip support
From: Wolfgang Grandegegr @ 2009-03-17 9:12 UTC (permalink / raw)
To: linux-mtd; +Cc: linuxppc-dev
In-Reply-To: <1237281143-8768-4-git-send-email-wg@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
This patch adds multi-chip support for the Micron MT29F8G08FAB NAND
flash memory on the TQM8548 modules.
This patch should go through the powerpc/85xx channel.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
arch/powerpc/boot/dts/tqm8548.dts | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/tqm8548.dts b/arch/powerpc/boot/dts/tqm8548.dts
index 81d3fbb..e5c3c67 100644
--- a/arch/powerpc/boot/dts/tqm8548.dts
+++ b/arch/powerpc/boot/dts/tqm8548.dts
@@ -389,6 +389,11 @@
reg = <3 0x0 0x800>;
fsl,upm-addr-offset = <0x10>;
fsl,upm-cmd-offset = <0x08>;
+ wait-flags = <0x05>;
+ /* Multi-chip device */
+ fsl,upm-mar-chip-offset = <0x200>;
+ max-chips = <2>;
+ chip-offset = <0x200>;
chip-delay = <25>; // in micro-seconds
nand@0 {
--
1.6.0.6
^ permalink raw reply related
* [PATCH 0/4] NAND: Multi-chip support for FSL-UPM for TQM8548 modules
From: Wolfgang Grandegegr @ 2009-03-17 9:12 UTC (permalink / raw)
To: linux-mtd; +Cc: linuxppc-dev
The following patch series adds generic support for multi-chip NAND devices
to the FSL-UPM driver and support for the Micron MT29F8G08FAB NAND flash
memory on the TQM8548 modules:
[PATCH 1/4] NAND: FSL-UPM: add multi chip support
[PATCH 2/4] NAND: FSL-UPM: add support for selecting chips via MAR
[PATCH 3/4] NAND: FSL-UPM: Add wait flags to support board/chip specific delays
[PATCH 4/4] powerpc/85xx: TQM8548: Update DTS file for multi-chip support
Wolfgang.
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation
From: Cedric Le Goater @ 2009-03-17 6:55 UTC (permalink / raw)
To: Nathan Lynch; +Cc: containers, Oren Laadan, linuxppc-dev
In-Reply-To: <20090316133745.4f636979@thinkcentre.lan>
> Again, how would 'cr' obtain exit status for these tasks, and how would
> it distinguish failure from normal operation?
Here's our solution to this issue.
mcr maintains in its kernel container object an exitcode attribute for
the mcr-restart process. This process is detached from the fork tree of
the restarted application.
when the restart is finished, an mcr-wait command can be called to reap
this exitcode. This make it possible to distinguish an exit of the
application process from an exit of the mcr-restart process.
This is a must-have for batch managers in an HPC environment.
Cheers,
C.
^ permalink raw reply
* [RFC] powerpc/8xxx: Clean up setting of CPU_FTR_NEED_COHERENT
From: Grant Likely @ 2009-03-17 4:59 UTC (permalink / raw)
To: galak, benh, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
Method used to set CPU_FTR_NEED_COHERENT was unfriendly for multiplatform
kernels. This patch cleans it up.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
I haven't even compile tested this. But I want to see if there are any
objections before I do the legwork.
g.
arch/powerpc/include/asm/cputable.h | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index 48d7f5f..a36494e 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -242,8 +242,7 @@ extern const char *powerpc_base_platform;
* 74[45]x and an MPC107 host bridge. Also 83xx and PowerQUICC II
* require it for PCI "streaming/prefetch" to work properly.
*/
-#if defined(CONFIG_SMP) || defined(CONFIG_MPC10X_BRIDGE) \
- || defined(CONFIG_PPC_83xx) || defined(CONFIG_8260)
+#if defined(CONFIG_SMP) || defined(CONFIG_MPC10X_BRIDGE)
#define CPU_FTR_COMMON CPU_FTR_NEED_COHERENT
#else
#define CPU_FTR_COMMON 0
@@ -347,7 +346,7 @@ extern const char *powerpc_base_platform;
CPU_FTR_SPEC7450 | CPU_FTR_NAP_DISABLE_L2_PR | \
CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
#define CPU_FTRS_82XX (CPU_FTR_COMMON | \
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB)
+ CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_NEED_COHERENT)
#if defined(CONFIG_PPC_MPC52xx)
#define CPU_FTRS_G2_LE (CPU_FTR_COMMON | CPU_FTR_MAYBE_CAN_DOZE | \
@@ -359,10 +358,10 @@ extern const char *powerpc_base_platform;
#define CPU_FTRS_E300 (CPU_FTR_MAYBE_CAN_DOZE | \
CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP | \
- CPU_FTR_COMMON)
+ CPU_FTR_COMMON | CPU_FTR_NEED_COHERENT)
#define CPU_FTRS_E300C2 (CPU_FTR_MAYBE_CAN_DOZE | \
CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP | \
- CPU_FTR_COMMON | CPU_FTR_FPU_UNAVAILABLE)
+ CPU_FTR_COMMON | CPU_FTR_FPU_UNAVAILABLE | CPU_FTR_NEED_COHERENT)
#define CPU_FTRS_CLASSIC32 (CPU_FTR_COMMON | CPU_FTR_USE_TB)
#define CPU_FTRS_8XX (CPU_FTR_USE_TB)
#define CPU_FTRS_40X (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE)
^ permalink raw reply related
* Re: [PATCH] powerpc: Enable CPU_FTR_NEED_COHERENT for MPC52xx
From: Grant Likely @ 2009-03-17 4:43 UTC (permalink / raw)
To: Piotr Ziecik; +Cc: LinuxPPC Mailing List, Kumar Gala
In-Reply-To: <fa686aa40903162054v2d28fc2er53aa4f71837110a2@mail.gmail.com>
On Mon, Mar 16, 2009 at 9:54 PM, Grant Likely <grant.likely@secretlab.ca> w=
rote:
> On Mon, Mar 16, 2009 at 4:05 AM, Piotr Ziecik <kosmo@semihalf.com> wrote:
>> BestComm, a DMA engine in MPC52xx SoC, requires snooping when
>> CPU caches are enabled to work properly.
>>
>> Adding CPU_FTR_NEED_COHERENT fixes NFS problems on MPC52xx machines
>> introduced by 'powerpc/mm: Fix handling of _PAGE_COHERENT in BAT setup c=
ode'.
>>[...]
>> =A0#if defined(CONFIG_SMP) || defined(CONFIG_MPC10X_BRIDGE) \
>> - =A0 =A0 =A0 || defined(CONFIG_PPC_83xx) || defined(CONFIG_8260)
>> + =A0 =A0 =A0 || defined(CONFIG_PPC_83xx) || defined(CONFIG_8260) \
>> + =A0 =A0 =A0 || defined(CONFIG_PPC_MPC52xx)
>> =A0#define CPU_FTR_COMMON =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CPU_FTR_NEE=
D_COHERENT
>> =A0#else
>> =A0#define CPU_FTR_COMMON =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00
>
> Aside from the fact that MPC10X_BRIDGE, PPC83xx and 8260 are already
> doing it, adding the feature bit this way isn't multiplatform
> friendly. =A0Essentially it means that all selected platforms will have
> CPU_FTR_NEED_COHERENT enabled if CONFIG_PPC_MPC52xx is enabled.
Here's my counter-patch. It contains the change to just G2_LE cores
when MPC52xx is selected. However, this change will also affect some
of the MPC82xx parts. However CPU_FTR_NEED_COHERENT shouldn't
actually hurt anything, so maybe it would be better to just enable it
unconditionally for the G2_LE core.
Kumar/Ben, thoughts?
g.
---
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm=
/cput
index 4911104..48d7f5f 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -348,8 +348,15 @@ extern const char *powerpc_base_platform;
CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
#define CPU_FTRS_82XX (CPU_FTR_COMMON | \
CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB)
+
+#if defined(CONFIG_PPC_MPC52xx)
+#define CPU_FTRS_G2_LE (CPU_FTR_COMMON | CPU_FTR_MAYBE_CAN_DOZE | \
+ CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NEED_COHERENT)
+#else
#define CPU_FTRS_G2_LE (CPU_FTR_COMMON | CPU_FTR_MAYBE_CAN_DOZE | \
CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP)
+#endif
+
#define CPU_FTRS_E300 (CPU_FTR_MAYBE_CAN_DOZE | \
CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP | \
CPU_FTR_COMMON)
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply related
* Re: [PATCH] powerpc: Enable CPU_FTR_NEED_COHERENT for MPC52xx
From: Grant Likely @ 2009-03-17 3:54 UTC (permalink / raw)
To: Piotr Ziecik; +Cc: LinuxPPC Mailing List
In-Reply-To: <1237197925-71727-1-git-send-email-kosmo@semihalf.com>
On Mon, Mar 16, 2009 at 4:05 AM, Piotr Ziecik <kosmo@semihalf.com> wrote:
> BestComm, a DMA engine in MPC52xx SoC, requires snooping when
> CPU caches are enabled to work properly.
>
> Adding CPU_FTR_NEED_COHERENT fixes NFS problems on MPC52xx machines
> introduced by 'powerpc/mm: Fix handling of _PAGE_COHERENT in BAT setup co=
de'.
>
> Signed-off-by: Piotr Ziecik <kosmo@semihalf.com>
> ---
>
> This patch was succesfully tested on our MPC5200-based.
> Ben, Gerhard could you ack this patch, as it implements your suggestion.
>
> =A0arch/powerpc/include/asm/cputable.h | =A0 =A04 +++-
> =A01 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/a=
sm/cputable.h
> index b18358f..22dc2d8 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -241,9 +241,11 @@ extern const char *powerpc_base_platform;
> =A0/* We need to mark all pages as being coherent if we're SMP or we have=
a
> =A0* 74[45]x and an MPC107 host bridge. Also 83xx and PowerQUICC II
> =A0* require it for PCI "streaming/prefetch" to work properly.
> + * This is also required by 52xx family.
> =A0*/
> =A0#if defined(CONFIG_SMP) || defined(CONFIG_MPC10X_BRIDGE) \
> - =A0 =A0 =A0 || defined(CONFIG_PPC_83xx) || defined(CONFIG_8260)
> + =A0 =A0 =A0 || defined(CONFIG_PPC_83xx) || defined(CONFIG_8260) \
> + =A0 =A0 =A0 || defined(CONFIG_PPC_MPC52xx)
> #define CPU_FTR_COMMON CPU_FTR_NEED_COHERENT
> #else
> #define CPU_FTR_COMMON 0
Aside from the fact that MPC10X_BRIDGE, PPC83xx and 8260 are already
doing it, adding the feature bit this way isn't multiplatform
friendly. Essentially it means that all selected platforms will have
CPU_FTR_NEED_COHERENT enabled if CONFIG_PPC_MPC52xx is enabled.
Adding a new section to cputable.c for PVR=3D0x8082201x and applying the
bit there would contain the impact to only G2 cores, but it's not
perfect. Some of the 82xx parts have the same PVR and so would also
be impacted.
Maybe I'm fretting over nothing. Ben, what's the right thing to do here?
Otherwise, I've pulled this into my tree and while I'm not affected by
the bug, I don't see any new problems with the patch either.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/86xx: Board support for GE Fanuc's PPC9A
From: David Gibson @ 2009-03-17 1:39 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev, wim
In-Reply-To: <20090316103048.10805.15368.stgit@ubuntu8041.localdomain>
On Mon, Mar 16, 2009 at 10:32:18AM +0000, Martyn Welch wrote:
> Support for the PPC9A VME Single Board Computer from GE Fanuc (PowerPC
> MPC8641D).
>
> This is the basic board support for GE Fanuc's PPC9A, a 6U single board
> computer, based on Freescale's MPC8641D.
Uh.. sorry. Should have noticed these little nitpicks the first time
around.
> + localbus@fef05000 {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + compatible = "fsl,mpc8641-localbus", "simple-bus";
> + reg = <0xfef05000 0x1000>;
> + interrupts = <19 2>;
> + interrupt-parent = <&mpic>;
> +
> + ranges = <0 0 0xff000000 0x01000000 // 16MB Boot flash
> + 1 0 0xe8000000 0x08000000 // Paged Flash 0
> + 2 0 0xe0000000 0x08000000 // Paged Flash 1
> + 3 0 0xfc100000 0x00020000 // NVRAM
> + 4 0 0xfc000000 0x00008000 // FPGA
> + 5 0 0xfc008000 0x00008000 // AFIX FPGA
> + 6 0 0xfd000000 0x00800000 // IO FPGA (8-bit)
> + 7 0 0xfd800000 0x00800000>; // IO FPGA (32-bit)
> +
> + /* flash@0,0 is a mirror of part of the memory in flash@1,0
> + flash@0,0 {
> + compatible = "cfi-flash";
It would be nice to have the actual type of flash chips here, although
it's not essential.
[snip]
> + fpga@4,0 {
> + compatible = "gef,fpga-regs";
I don't imagine this is the only set of FPGA based control regs GE
Fanuc will ever make, so this should be more precise. Including the
board type here is probably the way to go.
> + reg = <0x4 0x0 0x40>;
> + };
> +
> + wdt@4,2000 {
> + compatible = "gef,fpga-wdt";
And likewise here.
> + reg = <0x4 0x2000 0x8>;
> + interrupts = <0x1a 0x4>;
> + interrupt-parent = <&gef_pic>;
> + };
> + /* Second watchdog available, driver currently supports one.
> + wdt@4,2010 {
> + compatible = "gef,fpga-wdt";
> + reg = <0x4 0x2010 0x8>;
> + interrupts = <0x1b 0x4>;
> + interrupt-parent = <&gef_pic>;
> + };
> + */
> + gef_pic: pic@4,4000 {
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + compatible = "gef,fpga-pic";
And possibly here, although in this case I imagine several boards
might have compatible FPGA PICs.
> + i2c1: i2c@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl-i2c";
This should list include a compatible string specific to the
particular SoC model before the general name.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Compilation of PREEMPT_RT on PowerPC (ppc440)
From: srikanth krishnakar @ 2009-03-16 21:55 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 3475 bytes --]
Hi all,
The latest RT patch "patch-2.6.29-rc6-rt3" is throwing following compilation
errors for POWERPC linux kernel 2.6.29-rc6 :-
As I used plain vanilla kernel i.e -> Linux-2.6.28 + patch-2.6.29-rc6 +
patch-2.6.29-rc6-rt3
While compiling for ppc440...
[root@srikanth linux-2.6.29-rc6]# make ARCH=powerpc CROSS_COMPILE=ppc_440-
zImage
CHK include/linux/version.h
CHK include/linux/utsrelease.h
SYMLINK include/asm -> include/asm-powerpc
CC kernel/bounds.s
GEN include/linux/bounds.h
CC arch/powerpc/kernel/asm-offsets.s
In file included from include/linux/rwsem.h:37,
from include/linux/mm_types.h:11,
from include/linux/sched.h:61,
from arch/powerpc/kernel/asm-offsets.c:17:
/opt/mlg-rt-test/linux-2.6.29-rc6/arch/powerpc/include/asm/rwsem.h:24:
error: redefinition of ‘struct rw_semaphore’
In file included from
include/linux/rwsem.h:37,
from
include/linux/mm_types.h:11,
from
include/linux/sched.h:61,
from
arch/powerpc/kernel/asm-offsets.c:17:
/opt/mlg-rt-test/linux-2.6.29-rc6/arch/powerpc/include/asm/rwsem.h:46:1:
warning: "__RWSEM_INITIALIZER" redefined
In file included from
include/linux/spinlock.h:118,
from
include/linux/seqlock.h:34,
from include/linux/time.h:8,
from include/linux/timex.h:56,
from include/linux/sched.h:54,
from arch/powerpc/kernel/asm-offsets.c:17:
include/linux/rt_lock.h:191:1: warning: this is the location of the previous
definition
In file included from include/linux/rwsem.h:37,
from include/linux/mm_types.h:11,
from include/linux/sched.h:61,
from arch/powerpc/kernel/asm-offsets.c:17:
/opt/mlg-rt-test/linux-2.6.29-rc6/arch/powerpc/include/asm/rwsem.h:50:1:
warning: "DECLARE_RWSEM" redefined
In file included from include/linux/spinlock.h:118,
from include/linux/seqlock.h:34,
from include/linux/time.h:8,
from include/linux/timex.h:56,
from include/linux/sched.h:54,
from arch/powerpc/kernel/asm-offsets.c:17:
include/linux/rt_lock.h:195:1: warning: this is the location of the previous
definition
In file included from include/linux/rwsem.h:37,
from include/linux/mm_types.h:11,
from include/linux/sched.h:61,
from arch/powerpc/kernel/asm-offsets.c:17:
/opt/mlg-rt-test/linux-2.6.29-rc6/arch/powerpc/include/asm/rwsem.h:61:1:
warning: "init_rwsem" redefined
In file included from include/linux/spinlock.h:118,
from include/linux/seqlock.h:34,
from include/linux/time.h:8,
from include/linux/timex.h:56,
from include/linux/sched.h:54,
from arch/powerpc/kernel/asm-offsets.c:17:
include/linux/rt_lock.h:232:1: warning: this is the location of the previous
definition
/opt/mlg-rt-test/linux-2.6.29-rc6/arch/powerpc/include/asm/rwsem.h:167:
error: expected identifier or ‘(’ before ‘{’ token
make[1]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1
make: *** [prepare0] Error 2
[root@srikanth linux-2.6.29-rc6]#
Has anybody come across this ? If any fixes brought up for build of RT on
PowerPC, pls reply back.
Regards
Srikant
********
[-- Attachment #2: Type: text/html, Size: 4106 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox