[PATCH V2] powerpc: Export PIR data through sysfs

2011-11-10 Thread Ananth N Mavinakayanahalli
On Fri, Nov 11, 2011 at 10:17:55AM +0530, Ananth N Mavinakayanahalli wrote:
> > 
> > At this rate we're going to end up with no bits left for CPU features
> > way too quickly... Especially for something we only care about once at
> > boot time.
> >
> > Wouldn't CPU_FTR_PPCAS_ARCH_V2 be a good enough test ?
> 
> /me checks Cell manuals... yes, that test would be good enough. I will
> cook up a patch to use this.

Here it is...
---

From: Ananth N Mavinakayanahalli 

The Processor Identification Register (PIR) on some powerpc platforms
provides information to decode the processor identification tag that
can be used for node/core/thread affinity tests and for debugging.
Decoding this information is platform specific.

Export PIR contents through sysfs.

[V2] Use CPU_FTR_PPCAS_ARCH_V2 as a test for PIR's presence per
BenH's suggestion.

Signed-off-by: Ananth N Mavinakayanahalli 
---
 arch/powerpc/kernel/sysfs.c |8 
 1 file changed, 8 insertions(+)

Index: linux-3.2-rc1/arch/powerpc/kernel/sysfs.c
===
--- linux-3.2-rc1.orig/arch/powerpc/kernel/sysfs.c
+++ linux-3.2-rc1/arch/powerpc/kernel/sysfs.c
@@ -177,11 +177,13 @@ SYSFS_PMCSETUP(mmcra, SPRN_MMCRA);
 SYSFS_PMCSETUP(purr, SPRN_PURR);
 SYSFS_PMCSETUP(spurr, SPRN_SPURR);
 SYSFS_PMCSETUP(dscr, SPRN_DSCR);
+SYSFS_PMCSETUP(pir, SPRN_PIR);
 
 static SYSDEV_ATTR(mmcra, 0600, show_mmcra, store_mmcra);
 static SYSDEV_ATTR(spurr, 0600, show_spurr, NULL);
 static SYSDEV_ATTR(dscr, 0600, show_dscr, store_dscr);
 static SYSDEV_ATTR(purr, 0600, show_purr, store_purr);
+static SYSDEV_ATTR(pir, 0400, show_pir, NULL);
 
 unsigned long dscr_default = 0;
 EXPORT_SYMBOL(dscr_default);
@@ -392,6 +394,9 @@ static void __cpuinit register_cpu_onlin
 
if (cpu_has_feature(CPU_FTR_DSCR))
sysdev_create_file(s, &attr_dscr);
+
+   if (cpu_has_feature(CPU_FTR_PPCAS_ARCH_V2))
+   sysdev_create_file(s, &attr_pir);
 #endif /* CONFIG_PPC64 */
 
cacheinfo_cpu_online(cpu);
@@ -462,6 +467,9 @@ static void unregister_cpu_online(unsign
 
if (cpu_has_feature(CPU_FTR_DSCR))
sysdev_remove_file(s, &attr_dscr);
+
+   if (cpu_has_feature(CPU_FTR_PPCAS_ARCH_V2))
+   sysdev_remove_file(s, &attr_pir);
 #endif /* CONFIG_PPC64 */
 
cacheinfo_cpu_offline(cpu);

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 02/17] powerpc: Split up PHYS_64BIT config option to fix "select" issues

2011-11-10 Thread Benjamin Herrenschmidt
On Thu, 2011-11-10 at 10:50 -0600, Timur Tabi wrote:

> I'm not sure that Kconfig rule is enforceable.  We use 'select' all the time 
> to make sure that our boards enable the options that need to be enabled.  I'd 
> rather see this:
> 
> config X
>   select A
> 
> config Y
>   select A
> 
> config Z
>   select A
> 
> than this:
> 
> config A
>   default y if X | Y | Z
> 
> The former is more maintainable and does not allow the option of disabling 
> "A" if someone wants "X".

This is fine as long as config A is not a user selectable option.

We do the wrong thing in a few places (i2c comes to mind) and we should
most certainly consider fixing it. Some of the solution is to move some
select's to defconfigs, some is to do things the way Kyle proposed.

For PHYS_64BIT, I'm not 100% certain at this point what the best
approach it. It should clearly be fixed and hidden for real 64-bit. As
for the rest, should it be user selectable ? I tend to think it should
be fixed & selected by the board config and keep it that way, avoiding
the user question entirely... but you may have good reasons to want to
keep it around.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc: Export PIR data through sysfs

2011-11-10 Thread Ananth N Mavinakayanahalli
On Fri, Nov 11, 2011 at 03:18:14PM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2011-11-10 at 14:18 +0530, Ananth N Mavinakayanahalli wrote:
> 
> > 
> > From: Ananth N Mavinakayanahalli 
> > 
> > The Processor Identification Register (PIR) on some powerpc platforms
> > provides information to decode the processor identification tag.
> > Decoding this information is platform specific.
> > 
> > We currently need this information for POWERx processors and hence
> > follows a similar model as adopted for the other POWERx specific
> > features.
> 
> At this rate we're going to end up with no bits left for CPU features
> way too quickly... Especially for something we only care about once at
> boot time.
>
> Wouldn't CPU_FTR_PPCAS_ARCH_V2 be a good enough test ?

/me checks Cell manuals... yes, that test would be good enough. I will
cook up a patch to use this.
 
> Can you tell us a bit more about the real use for that feature ? I still
> don't see what's the point of getting the underlying HW ID.

This is a requirement from the hardware system test folks for use with
their core, node and thread tests.

Ananth

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 08/17] powerpc/e500: Remove conditional "lwsync" substitution

2011-11-10 Thread Benjamin Herrenschmidt
On Thu, 2011-11-10 at 14:34 -0600, Kumar Gala wrote:

> No idea, we have to ask Ben how much he cares.  I don't see any FSL
> customers pushing us to run the same kernel on A2 and P5020 (or future
> FSL devices).

I do care. For example, imagine somebody wanting to support an
enterprise distro on both BG/Q and some FSL based HW ...

Besides, this has generally forced us to do things more cleanly and I
don't want to go back into #ifdef land. These cores are both arch 2.06 E
compilant, there is no good reason to prevent or forbid having them
build into a single binary image.

Look at the mess ARM got into and the pain they are having getting out
of with that stuff ... No way I'm going backward with split configs. If
anything, I'd like to reconcile things even more.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 08/17] powerpc/e500: Remove conditional "lwsync" substitution

2011-11-10 Thread Benjamin Herrenschmidt
On Thu, 2011-11-10 at 14:27 -0600, Moffett, Kyle D wrote:
> 
> Does this mean that PPC_BOOK3E_64 needs to be split into two separate
> Book 3-III families the same way that 32-bit has been split?  Is there
> another way around it? 

No, I don't want more split, on the contrary.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc

2011-11-10 Thread Benjamin Herrenschmidt
On Thu, 2011-11-10 at 18:38 -0600, Moffett, Kyle D wrote:

> Ok, so I've been poking around this code a bunch and as far as I can
> tell, the cacheline stuff has basically always been subtly wrong in
> twelve different ways and it's only largely coincidence that it works
> today.

Yay ! Somebody to clean that shit up ! :-)

That's the biggest missing step to being able to have 440 and 476 in a
single binary :-)

> So PowerPC64 systems have their own "ppc64_caches" structure set up
> before start_kernel() is called by parsing the OpenFirmware "cpu" nodes.
> That structure is then checked in every piece of 64-bit kernel code
> (except xmon) that uses the "dcbXX" and "icbXX" opcodes.

Yup. (And we should really fix xmon btw...)

> There is an entirely separate mechanism built into the "cputable" that
> is used on all PowerPC systems to compute cacheline sizes to pass in via
> ELF headers for userspace to use in memset()/memcpy(), etc.

Yeah well, it actually uses global variables which are set from cputable
on ppc32 and from the ppc64_caches structure on ppc64. Yeah it's not
pretty.

> Furthermore, the VDSO gets cacheline sizes stored into it, but on 64-bit
> they come from the ppc64_caches structure and on 32-bit they come from
> dcache_bsize/icache_bsize copied from the cputable.

Yup.

> Then there's the value in arch/powerpc/include/asm/cache.h which is used
> throughout the kernel to figure out how far apart to space CPU-specific
> datastructures (EG: __cacheline_aligned_on_smp).

Not much we can do about that one since it has to be compile time. Maybe
something like calculating the biggest cache line size supported by all
built-in processor types ?

> Despite the fact that all PPC64 have an "L1_CACHE_SIZE" value of 128,
> the PowerPC A2 and e5500 have {d,i}cache_bsize values of 64 in cputable
> and presumably also get correct values from OpenFirmware, so the bogus
> constant in asm/cache.h does nothing more than waste a bit of memory
> for unnecessary padding.

More or less yes, though we haven't totally given up on the idea of
eventually, one day, produce binaries capable of running both 64-bit S
and E :-)

> Unfortunately, lots of PPC32 assembly pretends that the value found in
> asm/cache.h is a hard truth and uses it for "dcbz", etc, which is why
> there are all of those ugly #ifdefs in asm/cache.h

Yes, well... -some- assembly, mostly the copy routines. It's been the
main reason why this hasn't been fixed yet.

> Based on all of that, my proposal is going to be a patch which does the
> following:
> 
>   (1) Conditionally set L1_CACHE_SHIFT to the maximum value used by any
>   platform being compiled in for alignment purposes.

Yay !

>   (2) Make the ppc64_caches struct apply to ppc32 as well, and
>   preinitialize it with a minimum value used by any platform being
>   compiled in (for "dcbXX"/"icbXX" purposes).  This is safe because
>   the pagesize is always a multiple of the cache block size and the
>   kernel only uses dcbXX/icbXX on whole pages.  The only impact is a
>   temporary small performance hit from flushing or zeroing the same
>   block 8 times if too small.

Are you sure about dcbz ? Getting that wrong can be deadly ... I'd
rather get rid of some fancy optims and use a soft value in some cases.
That or we can compile multiple variants for the common case of some of
the copy routines and use patching (alternate sections) to branch to the
right one at runtime, at least for the common cases (32 and 128 for
example for 440 and 476).

>   (3) Try to initialize the ppc_caches struct on ppc32 from the
>   OpenFirmware device-tree.  If that fails, then use the values we
>   find in the cputable.  After this is initialized any performance
>   hit in copy_page()/zero_page() will obviously disappear.
>
>   (4) Fix all of the PPC32 assembly code that is misusing L1_CACHE_SHIFT
>   to use the ppc_caches struct instead.

Yes. This could be done while keeping the hand-optimized stuff by
compiling several variants of it.

> Does that sound like a reasonable approach?

It absolutely does ! Thanks for looking at that, it's been on my todo
list for ages and I've been always finding good reasons to do something
else instead :-)

Cheers,
Ben.

> Cheers,
> Kyle Moffett
> 
> --
> Curious about my work on the Debian powerpcspe port?
> I'm keeping a blog here: http://pureperl.blogspot.com/


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v3 1/3] virtio_console: Fix locking of vtermno.

2011-11-10 Thread Rusty Russell
On Tue, 08 Nov 2011 13:44:58 -0800, Miche Baker-Harvey  wrote:
> Some modifications of vtermno were not done under the spinlock.
> 
> Moved assignment from vtermno and increment of vtermno together,
> putting both under the spinlock.  Revert vtermno on failure.
> 
> Signed-off-by: Miche Baker-Harvey 

Does it matter?  It's normal not to lock in a function called
"init_XXX", since it's not exposed yet.

Or is it?

Thanks,
Rusty.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 2/7] powerpc/85xx: add HOTPLUG_CPU support

2011-11-10 Thread Benjamin Herrenschmidt
On Fri, 2011-11-04 at 20:31 +0800, Zhao Chenhui wrote:

>  #ifdef CONFIG_SMP
>  /* When we get here, r24 needs to hold the CPU # */
>   .globl __secondary_start
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 7bf2187..12a54f0 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -381,8 +381,14 @@ void generic_cpu_die(unsigned int cpu)
>  
>   for (i = 0; i < 100; i++) {
>   smp_rmb();
> - if (per_cpu(cpu_state, cpu) == CPU_DEAD)
> + if (per_cpu(cpu_state, cpu) == CPU_DEAD) {
> + /*
> +  * After another core sets cpu_state to CPU_DEAD,
> +  * it needs some time to die.
> +  */
> + msleep(10);
>   return;
> + }
>   msleep(100);
>   }
>   printk(KERN_ERR "CPU%d didn't die...\n", cpu);

I don't really see why you need to wait. This loop is about waiting for
the CPU to mark itself DEAD, not necessarily to be physically powered
off.

> +struct epapr_entry {
> + u32 addr_h;
> + u32 addr_l;
> + u32 r3_h;
> + u32 r3_l;
> + u32 reserved;
> + u32 pir;
> + u32 r6_h;
> + u32 r6_l;
> +};

This should probably be in a generic location.

> +static int is_corenet;

This global is a bit gross...

 ...

> +
> +static void __cpuinit smp_85xx_reset_core(int nr)
> +{
> + __iomem u32 *vaddr, *pir_vaddr;
> + u32 val, cpu_mask;
> +
> + /* If CoreNet platform, use BRR as release register. */
> + if (is_corenet) {
> + cpu_mask = 1 << nr;
> + vaddr = ioremap(get_immrbase() + MPC85xx_BRR_OFF, 4);
> + } else {
> + cpu_mask = 1 << (24 + nr);
> + vaddr = ioremap(get_immrbase() + MPC85xx_ECM_EEBPCR_OFF, 4);
> + }

Instead, can't you instead have two functions using a common helper and
pick/hook the right one ?

Also in what context is that reset_core() called ? Doing ioremap isn't
something you can do at any random time...

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc: Export PIR data through sysfs

2011-11-10 Thread Benjamin Herrenschmidt
On Thu, 2011-11-10 at 14:18 +0530, Ananth N Mavinakayanahalli wrote:

> 
> From: Ananth N Mavinakayanahalli 
> 
> The Processor Identification Register (PIR) on some powerpc platforms
> provides information to decode the processor identification tag.
> Decoding this information is platform specific.
> 
> We currently need this information for POWERx processors and hence
> follows a similar model as adopted for the other POWERx specific
> features.

At this rate we're going to end up with no bits left for CPU features
way too quickly... Especially for something we only care about once at
boot time.

Wouldn't CPU_FTR_PPCAS_ARCH_V2 be a good enough test ?

Can you tell us a bit more about the real use for that feature ? I still
don't see what's the point of getting the underlying HW ID.

Cheers,
Ben.

> Signed-off-by: Ananth N Mavinakayanahalli 
> ---
>  arch/powerpc/include/asm/cputable.h |9 +
>  arch/powerpc/kernel/sysfs.c |8 
>  2 files changed, 13 insertions(+), 4 deletions(-)
> 
> Index: linux-3.2-rc1/arch/powerpc/include/asm/cputable.h
> ===
> --- linux-3.2-rc1.orig/arch/powerpc/include/asm/cputable.h
> +++ linux-3.2-rc1/arch/powerpc/include/asm/cputable.h
> @@ -201,6 +201,7 @@ extern const char *powerpc_base_platform
>  #define CPU_FTR_POPCNTB  
> LONG_ASM_CONST(0x0400)
>  #define CPU_FTR_POPCNTD  
> LONG_ASM_CONST(0x0800)
>  #define CPU_FTR_ICSWX
> LONG_ASM_CONST(0x1000)
> +#define CPU_FTR_PIR  LONG_ASM_CONST(0x2000)
>  
>  #ifndef __ASSEMBLY__
>  
> @@ -400,7 +401,7 @@ extern const char *powerpc_base_platform
>  #define CPU_FTRS_POWER4  (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
>   CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
>   CPU_FTR_MMCRA | CPU_FTR_CP_USE_DCBTZ | \
> - CPU_FTR_STCX_CHECKS_ADDRESS)
> + CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_PIR)
>  #define CPU_FTRS_PPC970  (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
>   CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | CPU_FTR_ARCH_201 | \
>   CPU_FTR_ALTIVEC_COMP | CPU_FTR_CAN_NAP | CPU_FTR_MMCRA | \
> @@ -408,19 +409,19 @@ extern const char *powerpc_base_platform
>   CPU_FTR_HVMODE)
>  #define CPU_FTRS_POWER5  (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
>   CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
> - CPU_FTR_MMCRA | CPU_FTR_SMT | \
> + CPU_FTR_MMCRA | CPU_FTR_SMT | CPU_FTR_PIR | \
>   CPU_FTR_COHERENT_ICACHE | CPU_FTR_PURR | \
>   CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB)
>  #define CPU_FTRS_POWER6 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
>   CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
> - CPU_FTR_MMCRA | CPU_FTR_SMT | \
> + CPU_FTR_MMCRA | CPU_FTR_SMT | CPU_FTR_PIR | \
>   CPU_FTR_COHERENT_ICACHE | \
>   CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
>   CPU_FTR_DSCR | CPU_FTR_UNALIGNED_LD_STD | \
>   CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_CFAR)
>  #define CPU_FTRS_POWER7 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
>   CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | CPU_FTR_ARCH_206 |\
> - CPU_FTR_MMCRA | CPU_FTR_SMT | \
> + CPU_FTR_MMCRA | CPU_FTR_SMT | CPU_FTR_PIR | \
>   CPU_FTR_COHERENT_ICACHE | \
>   CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
>   CPU_FTR_DSCR | CPU_FTR_SAO  | CPU_FTR_ASYM_SMT | \
> Index: linux-3.2-rc1/arch/powerpc/kernel/sysfs.c
> ===
> --- linux-3.2-rc1.orig/arch/powerpc/kernel/sysfs.c
> +++ linux-3.2-rc1/arch/powerpc/kernel/sysfs.c
> @@ -177,11 +177,13 @@ SYSFS_PMCSETUP(mmcra, SPRN_MMCRA);
>  SYSFS_PMCSETUP(purr, SPRN_PURR);
>  SYSFS_PMCSETUP(spurr, SPRN_SPURR);
>  SYSFS_PMCSETUP(dscr, SPRN_DSCR);
> +SYSFS_PMCSETUP(pir, SPRN_PIR);
>  
>  static SYSDEV_ATTR(mmcra, 0600, show_mmcra, store_mmcra);
>  static SYSDEV_ATTR(spurr, 0600, show_spurr, NULL);
>  static SYSDEV_ATTR(dscr, 0600, show_dscr, store_dscr);
>  static SYSDEV_ATTR(purr, 0600, show_purr, store_purr);
> +static SYSDEV_ATTR(pir, 0400, show_pir, NULL);
>  
>  unsigned long dscr_default = 0;
>  EXPORT_SYMBOL(dscr_default);
> @@ -392,6 +394,9 @@ static void __cpuinit register_cpu_onlin
>  
>   if (cpu_has_feature(CPU_FTR_DSCR))
>   sysdev_create_file(s, &attr_dscr);
> +
> + if (cpu_has_feature(CPU_FTR_PIR))
> + sysdev_create_file(s, &attr_pir);
>  #endif /* CONFIG_PPC64 */
>  
>   cacheinfo_cpu_online(cpu);
> @@ -462,6 +467,9 @@ static void unregister_cpu_online(unsign
>  
>   if (cpu_has_feature(CPU_FTR_DSCR))
>   sysdev_remove_file(s, &attr_dscr);
> +
> + if (cpu_has_feature(CPU_FTR_PIR))
> + sysdev_remove_file(s, &attr_pir);
>  #endif /* CONFIG_PPC64 */
>  
>   cacheinfo_cpu_offline(cpu);
> 
> 

Re: [PATCH v2 1/5] [ppc] Process dynamic relocations for kernel

2011-11-10 Thread Benjamin Herrenschmidt
On Thu, 2011-11-10 at 08:01 +0530, Suzuki Poulose wrote:

> Oops ! You are right. We could go back to the clean_dcache_all() or the
> initial approach that you suggested. (dcbst).
> 
> I am not sure how do we flush the entire dcache(only). Could you post a
> patch which does the same ?
> 
> Another option is to, change the current mapping to 'Write Through' before
> calling the relocate() and revert back to the original setting after 
> relocate().

Why not just keep the dcbst's & icbi's in relocate for now ? (original
patch) Is it noticably slower to boot ? If not I'd say keep it that way,
it will work on all implementations.

Cheers,
Ben.
> >
> >>
> >>
> >>> For i-cache invalidation there's already the (incorrectly named?)
> >>> flush_instruction_cache().  It uses the appropriate platform-specific
> >>> methods (e.g. iccci for 44x) to invalidate the entire i-cache.
> >>
> >> Agreed. The only thing that worries me is the use of KERNELBASE in the
> >> flush_instruction_cache() for CONFIG_4xx. Can we safely assume all 4xx
> >> implementations ignore the arguments passed to iccci ?
> >
> > Good question.  I don't know the answer. :-)
> >
> > That also may suggest a bigger can of worms.  A grep of the powerpc code
> > shows many uses of KERNELBASE.  For a relocatable kernel, nobody should
> > be relying on KERNELBASE except for the early relocation code.  Are we
> > sure that all the other usages of KERNELBASE are "safe"?
> >
> I think we could simply replace the occurrences of KERNELBASE (after the 
> relocate())
>   with '_stext' which would give the virtual start address of the kernel.
> 
> Thanks
> Suzuki
> 
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH] powerpc/trace: add a dummy stack frame for trace_hardirqs_off

2011-11-10 Thread Kevin Hao
The trace_hardirqs_off will use CALLER_ADDR0 and CALLER_ADDR1.
If an exception occurs in user mode, there is only one stack frame
on the stack and accessing the CALLER_ADDR1 will causes the following
call trace. So we create a dummy stack frame to make
trace_hardirqs_off happy.

WARNING: at kernel/smp.c:459
Modules linked in:
NIP: c0093280 LR: c00930a0 CTR: c0010780
REGS: edb87ae0 TRAP: 0700   Not tainted  (3.1.0)
MSR: 00021002   CR: 28002888  XER: 
TASK = edce2ac0[17658] 'mthread-lock-on' THREAD: edb86000 CPU: 5
GPR00: 0001 edb87b90 edce2ac0 0005 c0019594 edb87bd8 0001 0fe3
GPR08: 00041000 c084138c 4e20120d edb87b90 48002888 1001aa7c  
GPR16: 4883 10012a8c  1af4 0001 c081  
GPR24: ee9aa920 c0816a18  0005 c0019594 edb87bd8 ee20178c edb87b90
NIP [c0093280] smp_call_function_many+0x214/0x2b4
LR [c00930a0] smp_call_function_many+0x34/0x2b4
Call Trace:
[edb87b90] [c00930a0] smp_call_function_many+0x34/0x2b4 (unreliable)
[edb87bd0] [c00194ec] __flush_tlb_page+0xac/0x100
[edb87c00] [c001957c] flush_tlb_page+0x3c/0x54
[edb87c10] [c00180ac] ptep_set_access_flags+0x74/0x12c
[edb87c40] [c0128068] handle_pte_fault+0x2f0/0x9ac
[edb87cb0] [c0128c3c] handle_mm_fault+0x104/0x1dc
[edb87ce0] [c05f40f4] do_page_fault+0x2dc/0x630
[edb87e50] [c001078c] handle_page_fault+0xc/0x80
--- Exception: 301 at trace_hardirqs_off+0x68/0x150
LR = reenable_mmu+0x24/0x78
[edb87f10] [4902f4f8] 0x4902f4f8 (unreliable)
[edb87f40] [c00101d8] reenable_mmu+0x24/0x78
Instruction dump:
3d20c082 8009916c 2f80 40befe7c 3d20c081 880968c4 2f81 41befe6c
3d20c084 3929138c 88090004 6801 <0f00> 2f80 419efe50 3801
---[ end trace f26d2d7d0a9c89a2 ]---

Signed-off-by: Kevin Hao 
---
 arch/powerpc/kernel/entry_32.S |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 56212bc..4f80cf1 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -215,7 +215,22 @@ reenable_mmu:  /* re-enable 
mmu so we can */
stw r9,8(r1)
stw r11,12(r1)
stw r3,ORIG_GPR3(r1)
+   /*
+* The trace_hardirqs_off will use CALLER_ADDR0 and CALLER_ADDR1.
+* If from user mode there is only one stack frame on the stack, and
+* accessing CALLER_ADDR1 will cause oops. So we need create a dummy
+* stack frame to make trace_hardirqs_off happy.
+*/
+   andi.   r12,r12,MSR_PR
+   beq 11f
+   stwur1,-16(r1)
+   bl  trace_hardirqs_off
+   addir1,r1,16
+   b   12f
+
+11:
bl  trace_hardirqs_off
+12:
lwz r0,GPR0(r1)
lwz r3,ORIG_GPR3(r1)
lwz r4,GPR4(r1)
-- 
1.7.4.1.433.gcd306

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 4/5] treewide: Convert uses of ATTRIB_NORETURN to __noreturn

2011-11-10 Thread Paul Mundt
On Thu, Nov 10, 2011 at 01:41:45AM -0800, Joe Perches wrote:
> Use the more commonly used __noreturn instead of ATTRIB_NORETURN.
> 
> Signed-off-by: Joe Perches 
> ---
>  arch/ia64/kernel/machine_kexec.c   |2 +-
>  arch/m68k/amiga/config.c   |2 +-
>  arch/mips/include/asm/ptrace.h |2 +-
>  arch/mips/kernel/traps.c   |2 +-
>  arch/mn10300/include/asm/exceptions.h  |2 +-
>  arch/powerpc/kernel/machine_kexec_32.c |2 +-
>  arch/powerpc/kernel/machine_kexec_64.c |2 +-
>  arch/s390/include/asm/processor.h  |2 +-
>  arch/sh/kernel/process_32.c|2 +-
>  arch/sh/kernel/process_64.c|2 +-
>  arch/tile/kernel/machine_kexec.c   |2 +-
>  include/linux/kernel.h |6 +++---
>  12 files changed, 14 insertions(+), 14 deletions(-)
> 
For the SH bits:

Signed-off-by: Paul Mundt 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH] powerpc kvm: fix kvmppc_start_thread() for CONFIG_SMP=N

2011-11-10 Thread Michael Neuling
Currently kvmppc_start_thread() tries to wake other SMT threads via
xics_wake_cpu().  Unfortunately xics_wake_cpu only exists when
CONFIG_SMP=Y so when compiling with CONFIG_SMP=N we get:

  arch/powerpc/kvm/built-in.o: In function `.kvmppc_start_thread':
  book3s_hv.c:(.text+0xa1e0): undefined reference to `.xics_wake_cpu'

The following should be fine since kvmppc_start_thread() shouldn't
called to start non-zero threads when SMP=N since threads_per_core=1.

Signed-off-by: Michael Neuling 
---
 arch/powerpc/kvm/book3s_hv.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-ozlabs/arch/powerpc/kvm/book3s_hv.c
===
--- linux-ozlabs.orig/arch/powerpc/kvm/book3s_hv.c
+++ linux-ozlabs/arch/powerpc/kvm/book3s_hv.c
@@ -538,7 +538,7 @@ static void kvmppc_start_thread(struct k
tpaca->kvm_hstate.napping = 0;
vcpu->cpu = vc->pcpu;
smp_wmb();
-#ifdef CONFIG_PPC_ICP_NATIVE
+#if defined(CONFIG_PPC_ICP_NATIVE) && defined(CONFIG_SMP)
if (vcpu->arch.ptid) {
tpaca->cpu_start = 0x80;
wmb();
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc

2011-11-10 Thread Moffett, Kyle D
On Nov 10, 2011, at 11:54, Scott Wood wrote:
> On Thu, Nov 10, 2011 at 10:30:41AM -0600, Kumar Gala wrote:
>> On Nov 10, 2011, at 10:17 AM, Moffett, Kyle D wrote:
>>> Furthermore, it looks like there are a couple issues here I missed
>>> before.  PPC64 systems all appear to have an L1_CACHE_SHIFT of 7,
>>> except when you turn on the P5020DS board option which magically
>>> changes it to "6" and breaks lord-knows-what.  I think my patch
>>> series actually "breaks" that and makes e5500 use 7 as well.
>> 
>> a value of '6' on E5500 / P5020DS is correct and doesn't break anything.
>> Setting it to 7 is wrong and thus the code is correct today.
>> 
>>> Are you sure that a kernel built to support E5500 can also run on
>>> other 64-bit PowerPC/POWER systems?
>> 
>> No it will not.  There is not expectation of that as E5500 is an
>> embedded / Book-E class part and uses that ISA version.  Book-S
>> (server) 64-bit machines are not OS compatible and we are not trying to
>> make them as such (but we do re-use a lot of code).
> 
> What about other 64-bit book3e chips?  What cache block size does A2 have?

Ok, so I've been poking around this code a bunch and as far as I can
tell, the cacheline stuff has basically always been subtly wrong in
twelve different ways and it's only largely coincidence that it works
today.

So PowerPC64 systems have their own "ppc64_caches" structure set up
before start_kernel() is called by parsing the OpenFirmware "cpu" nodes.
That structure is then checked in every piece of 64-bit kernel code
(except xmon) that uses the "dcbXX" and "icbXX" opcodes.

There is an entirely separate mechanism built into the "cputable" that
is used on all PowerPC systems to compute cacheline sizes to pass in via
ELF headers for userspace to use in memset()/memcpy(), etc.

Furthermore, the VDSO gets cacheline sizes stored into it, but on 64-bit
they come from the ppc64_caches structure and on 32-bit they come from
dcache_bsize/icache_bsize copied from the cputable.

Then there's the value in arch/powerpc/include/asm/cache.h which is used
throughout the kernel to figure out how far apart to space CPU-specific
datastructures (EG: __cacheline_aligned_on_smp).

Despite the fact that all PPC64 have an "L1_CACHE_SIZE" value of 128,
the PowerPC A2 and e5500 have {d,i}cache_bsize values of 64 in cputable
and presumably also get correct values from OpenFirmware, so the bogus
constant in asm/cache.h does nothing more than waste a bit of memory
for unnecessary padding.

Unfortunately, lots of PPC32 assembly pretends that the value found in
asm/cache.h is a hard truth and uses it for "dcbz", etc, which is why
there are all of those ugly #ifdefs in asm/cache.h

Based on all of that, my proposal is going to be a patch which does the
following:

  (1) Conditionally set L1_CACHE_SHIFT to the maximum value used by any
  platform being compiled in for alignment purposes.

  (2) Make the ppc64_caches struct apply to ppc32 as well, and
  preinitialize it with a minimum value used by any platform being
  compiled in (for "dcbXX"/"icbXX" purposes).  This is safe because
  the pagesize is always a multiple of the cache block size and the
  kernel only uses dcbXX/icbXX on whole pages.  The only impact is a
  temporary small performance hit from flushing or zeroing the same
  block 8 times if too small.

  (3) Try to initialize the ppc_caches struct on ppc32 from the
  OpenFirmware device-tree.  If that fails, then use the values we
  find in the cputable.  After this is initialized any performance
  hit in copy_page()/zero_page() will obviously disappear.

  (4) Fix all of the PPC32 assembly code that is misusing L1_CACHE_SHIFT
  to use the ppc_caches struct instead.

Does that sound like a reasonable approach?

Cheers,
Kyle Moffett

--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v2 1/5] [ppc] Process dynamic relocations for kernel

2011-11-10 Thread Josh Poimboeuf
On Thu, 2011-11-10 at 08:01 +0530, Suzuki Poulose wrote:
> >> How about using clean_dcache_range() to flush the range runtime
> >> address range [ _stext, _end ] ? That would flush the entire
> >> instructions.
> >
> > Wouldn't that result in more cache flushing than the original solution?
> >
> > For example, my kernel is 3.5MB.  Assuming a 32 byte cache line size,
> > clean_dcache_range(_stext, _end) would result in about 115,000 dcbst's
> > (3.5MB / 32).
> 
> Oops ! You are right. We could go back to the clean_dcache_all() or the
> initial approach that you suggested. (dcbst).
> 
> I am not sure how do we flush the entire dcache(only). Could you post a
> patch which does the same ?

It turns out that my original idea of giving a 64k address range to
clean_dcache_range() wouldn't work, because dcbst only flushes the line
if the given address is in the cache already.


Also, I experimented with a simple clean_dcache_all() function in
misc_32.S:

#define L1_CACHE_SIZE   (32 * 1024)
#define L1_CACHE_LINES  (L1_CACHE_SIZE / L1_CACHE_BYTES) 
_GLOBAL(clean_dcache_all)
lis r3, _start@h
ori r3, r3, _start@l
li  r4, (L1_CACHE_LINES * 2)
mtctr   r4
1:  lwz r5, 0(r3)
addir3, r3, L1_CACHE_BYTES
bdnz1b
sync
blr

But this approach has some issues:

1. It should probably be made more platform-independent with respect to
d-cache size.  I'm not sure the best way to achieve that.

2. The _start address is the kernel virtual address, not the physical
address, but relocate() is running without TLB address translation
enabled.  Although we could easily circumvent this problem by clearing
the d-cache directly in relocate() (or in head_44x.S) using physical
addresses.

3. Chicken/egg issue:  the _start address might be stale because we
haven't yet flushed the d-cache and invalidated the i-cache.

I also discovered that calling flush_instruction_cache() from relocate()
wouldn't work for all platforms, for similar reasons.

We could overcome these issues with more code, but the added complexity
might not be worth it (premature optimization and all).  My original
patch at least has the benefit of being simple.


> 
> Another option is to, change the current mapping to 'Write Through' before
> calling the relocate() and revert back to the original setting after 
> relocate().

True, that's another option.  Although since TLB handling is
platform-specific, I think it would have to be handled by the caller in
head_44x.S, rather than within relocate().


> > That also may suggest a bigger can of worms.  A grep of the powerpc code
> > shows many uses of KERNELBASE.  For a relocatable kernel, nobody should
> > be relying on KERNELBASE except for the early relocation code.  Are we
> > sure that all the other usages of KERNELBASE are "safe"?
> >
> I think we could simply replace the occurrences of KERNELBASE (after the 
> relocate())
>   with '_stext' which would give the virtual start address of the kernel.

Yeah, that would work.


Josh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 08/17] powerpc/e500: Remove conditional "lwsync" substitution

2011-11-10 Thread Moffett, Kyle D
On Nov 10, 2011, at 12:03, Scott Wood wrote:
> On Thu, Nov 10, 2011 at 10:42:25AM -0600, Kumar Gala wrote:
>> 
>> On Nov 10, 2011, at 10:31 AM, Scott Wood wrote:
>> 
>>> On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote:
 Nak, we can run an e500mc in a mode that is compatible with e500v1/v2.
 I see no reason to change the support we have there.
>>> 
>>> What "mode" do you mean?  DCBZ32?  We don't support using that currently,
>>> and I'd imagine the performance implication would be such that you'd
>>> never want to do it unless it's the only way to make some piece of legacy
>>> software work.
>> 
>> Correct, DCBZ32, we've had customers that go down this path.
> 
> For running legacy software, or for multiplatform Linux kernels?
> 
> And if you're willing to toss performance away for this goal, why do you
> need lwsync? :-)
> 
> DCBZ32 is not a "mode that is compatible with v1/v2", BTW.  It only
> affects cache block size (for dcbz/dcba only), not SPE versus FP, not
> changes in power management, not changes in machine check handling, etc.
> 
> Using DCBZ32 for the kernel would also complicate switching the kernel to
> dcbzl, to support enabling DCBZ32 for certain userspace apps (a more
> likely use case) without making it systemwide.

So, as far as I can tell the kernel doesn't even try to touch DCBZ32.

Even if it did, if you are building a new kernel that includes this patch,
surely you can actually build a proper e500mc kernel instead of trying to
build a new kernel to run on hardware it wasn't designed to run on, right?

I think the bigger issue is the fact that building a PPC_BOOK3E_64 kernel
with both e5500 and PowerPC A2 support turned on will not actually run on
both.  Before my v1-patch-series, machine-check handling is messed up for
PowerPC A2, and afterwards cacheline sizes are messed up for e5500.

Does this mean that PPC_BOOK3E_64 needs to be split into two separate
Book 3-III families the same way that 32-bit has been split?  Is there
another way around it?

Cheers,
Kyle Moffett
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 08/17] powerpc/e500: Remove conditional "lwsync" substitution

2011-11-10 Thread Kumar Gala

On Nov 10, 2011, at 2:27 PM, Moffett, Kyle D wrote:

> On Nov 10, 2011, at 12:03, Scott Wood wrote:
>> On Thu, Nov 10, 2011 at 10:42:25AM -0600, Kumar Gala wrote:
>>> 
>>> On Nov 10, 2011, at 10:31 AM, Scott Wood wrote:
>>> 
 On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote:
> Nak, we can run an e500mc in a mode that is compatible with e500v1/v2.
> I see no reason to change the support we have there.
 
 What "mode" do you mean?  DCBZ32?  We don't support using that currently,
 and I'd imagine the performance implication would be such that you'd
 never want to do it unless it's the only way to make some piece of legacy
 software work.
>>> 
>>> Correct, DCBZ32, we've had customers that go down this path.
>> 
>> For running legacy software, or for multiplatform Linux kernels?
>> 
>> And if you're willing to toss performance away for this goal, why do you
>> need lwsync? :-)
>> 
>> DCBZ32 is not a "mode that is compatible with v1/v2", BTW.  It only
>> affects cache block size (for dcbz/dcba only), not SPE versus FP, not
>> changes in power management, not changes in machine check handling, etc.
>> 
>> Using DCBZ32 for the kernel would also complicate switching the kernel to
>> dcbzl, to support enabling DCBZ32 for certain userspace apps (a more
>> likely use case) without making it systemwide.
> 
> So, as far as I can tell the kernel doesn't even try to touch DCBZ32.

Correct, it was my thinking I'd get there an add this one day, that day never 
came.

> Even if it did, if you are building a new kernel that includes this patch,
> surely you can actually build a proper e500mc kernel instead of trying to
> build a new kernel to run on hardware it wasn't designed to run on, right?
> 
> I think the bigger issue is the fact that building a PPC_BOOK3E_64 kernel
> with both e5500 and PowerPC A2 support turned on will not actually run on
> both.  Before my v1-patch-series, machine-check handling is messed up for
> PowerPC A2, and afterwards cacheline sizes are messed up for e5500.

That might be, but who is asking or wanting to run a BOOK3E_64 kernel on both.  
I'm guessing there are a number of issues with this.

> Does this mean that PPC_BOOK3E_64 needs to be split into two separate
> Book 3-III families the same way that 32-bit has been split?  Is there
> another way around it?

No idea, we have to ask Ben how much he cares.  I don't see any FSL customers 
pushing us to run the same kernel on A2 and P5020 (or future FSL devices).

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC][PATCH 08/30] powerpc/85xx: Rework P1020 SoC device tree

2011-11-10 Thread Kumar Gala

On Nov 10, 2011, at 12:58 PM, Scott Wood wrote:

> On Thu, Nov 10, 2011 at 12:46:27PM -0600, Kumar Gala wrote:
>> 
>> On Nov 10, 2011, at 12:05 PM, Scott Wood wrote:
>> 
>>> On Thu, Nov 10, 2011 at 10:13:51AM -0600, Kumar Gala wrote:
 Split the P1020 SoC device tree into what we can include as a 'prefix'
 to the board device tree and what needs to be included as a 'postfix'.
 
 This allows use more re-use and less duplication between various board
 device tree configurations (32-bit address map vs 36-bit address map).
>>> 
>>> Could you elaborate on the issues that require this pre/post approach?
>> 
>> We utilize two 'features' of dtc to accomplish things.  One is includes the 
>> other is 'merging of labeled nodes'.
>> 
>> We can using merging to allow the board to specify the "reg" & "ranges"
>> values of a SoC node that might vary between physical address maps
>> (32-bit vs 36-bit as example).
>> 
>> dtc is able to 'merge' multiple labeled nodes as well.  So we use that
>> to handle board specific values for something like localbus if we want
>> to support both a 32-bit and 36-bit address map.
>> 
>>> What does the SoC part need to specify that has to override or go within
>>> something the board specifies?
>> 
>> Not sure I follow the question.
> 
> My question is, why does the stuff in post need to be in post, versus pre?
> 
> Why can't pre define the soc node, and let the board dts set ranges? 
> Likewise for localbus, pci, etc.
> 
> -Scott

Gotcha, the reason we have -pre and -post is because of how dtc include 
mechanism works.  It builds it's tree in the order things are parsed in the 
file.  In addition, "labeled nodes" like we have in post for 'soc', 'lbc', etc. 
have to be defined after they are referenced.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC][PATCH 28/30] powerpc/85xx: Rework P1023RDS device tree

2011-11-10 Thread Kumar Gala

On Nov 10, 2011, at 12:55 PM, Scott Wood wrote:

> On Thu, Nov 10, 2011 at 12:42:54PM -0600, Kumar Gala wrote:
>> 
>> On Nov 10, 2011, at 12:10 PM, Scott Wood wrote:
>> 
>>> On Thu, Nov 10, 2011 at 10:14:11AM -0600, Kumar Gala wrote:
 -  power@e0070{
 -  compatible = "fsl,mpc8536-pmc", "fsl,mpc8548-pmc",
 -   "fsl,p1022-pmc";
 -  reg = <0xe0070 0x20>;
 -  etsec1_clk: soc-clk@B0{
 -  fsl,pmcdr-mask = <0x0080>;
 -  };
 -  etsec2_clk: soc-clk@B1{
 -  fsl,pmcdr-mask = <0x0040>;
 -  };
 -  etsec3_clk: soc-clk@B2{
 -  fsl,pmcdr-mask = <0x0020>;
 -  };
 -  };
>>> 
>>> The compatibles on this node are wrong, but it looks like you're removing
>>> it altogether?
>>> 
>>> -Scott
>> 
>> Yeah, I think the whole thing needs to be relocated at because there are no 
>> etsec's on P1023, etc.  So will comment about this in commit message
> 
> Ah right, the etsec stuff should go as well. :-)
> 
> It should look like this:
> 
>   power@e0070 {
>   compatible = "fsl,p1023-pmc", "fsl,mpc8548-pmc";
>   reg = <0xe0070 0x20>;
>   };

What does being compatible with mpc8548-pmc mean?

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC][PATCH 08/30] powerpc/85xx: Rework P1020 SoC device tree

2011-11-10 Thread Scott Wood
On Thu, Nov 10, 2011 at 12:46:27PM -0600, Kumar Gala wrote:
> 
> On Nov 10, 2011, at 12:05 PM, Scott Wood wrote:
> 
> > On Thu, Nov 10, 2011 at 10:13:51AM -0600, Kumar Gala wrote:
> >> Split the P1020 SoC device tree into what we can include as a 'prefix'
> >> to the board device tree and what needs to be included as a 'postfix'.
> >> 
> >> This allows use more re-use and less duplication between various board
> >> device tree configurations (32-bit address map vs 36-bit address map).
> > 
> > Could you elaborate on the issues that require this pre/post approach?
> 
> We utilize two 'features' of dtc to accomplish things.  One is includes the 
> other is 'merging of labeled nodes'.
> 
> We can using merging to allow the board to specify the "reg" & "ranges"
> values of a SoC node that might vary between physical address maps
> (32-bit vs 36-bit as example).
> 
> dtc is able to 'merge' multiple labeled nodes as well.  So we use that
> to handle board specific values for something like localbus if we want
> to support both a 32-bit and 36-bit address map.
> 
> > What does the SoC part need to specify that has to override or go within
> > something the board specifies?
> 
> Not sure I follow the question.

My question is, why does the stuff in post need to be in post, versus pre?

Why can't pre define the soc node, and let the board dts set ranges? 
Likewise for localbus, pci, etc.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC][PATCH 28/30] powerpc/85xx: Rework P1023RDS device tree

2011-11-10 Thread Scott Wood
On Thu, Nov 10, 2011 at 12:42:54PM -0600, Kumar Gala wrote:
> 
> On Nov 10, 2011, at 12:10 PM, Scott Wood wrote:
> 
> > On Thu, Nov 10, 2011 at 10:14:11AM -0600, Kumar Gala wrote:
> >> -  power@e0070{
> >> -  compatible = "fsl,mpc8536-pmc", "fsl,mpc8548-pmc",
> >> -   "fsl,p1022-pmc";
> >> -  reg = <0xe0070 0x20>;
> >> -  etsec1_clk: soc-clk@B0{
> >> -  fsl,pmcdr-mask = <0x0080>;
> >> -  };
> >> -  etsec2_clk: soc-clk@B1{
> >> -  fsl,pmcdr-mask = <0x0040>;
> >> -  };
> >> -  etsec3_clk: soc-clk@B2{
> >> -  fsl,pmcdr-mask = <0x0020>;
> >> -  };
> >> -  };
> > 
> > The compatibles on this node are wrong, but it looks like you're removing
> > it altogether?
> > 
> > -Scott
> 
> Yeah, I think the whole thing needs to be relocated at because there are no 
> etsec's on P1023, etc.  So will comment about this in commit message

Ah right, the etsec stuff should go as well. :-)

It should look like this:

power@e0070 {
compatible = "fsl,p1023-pmc", "fsl,mpc8548-pmc";
reg = <0xe0070 0x20>;
};

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 16/17] powerpc/e500: Make __setup_cpu_{e200, e500, e500mc, e5500} optional

2011-11-10 Thread Kumar Gala

On Nov 10, 2011, at 10:47 AM, Scott Wood wrote:

> On Wed, Nov 09, 2011 at 07:07:14PM -0500, Kyle Moffett wrote:
>> Only build the setup functions when the corresponding entries are
>> included in the CPU table.
>> 
>> Signed-off-by: Kyle Moffett 
>> ---
>> arch/powerpc/kernel/cpu_setup_fsl_booke.S |   14 +-
>> 1 files changed, 13 insertions(+), 1 deletions(-)
>> 
>> diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S 
>> b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
>> index 8053db0..77721b2 100644
>> --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
>> +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
>> @@ -17,6 +17,8 @@
>> #include 
>> #include 
>> 
>> +#if defined(CONFIG_FSL_E500_V1_V2) || defined(CONFIG_FSL_E500MC) \
>> +|| defined(CONFIG_FSL_E5500)
> 
> This seems like the kind of thing that CONFIG_E500 should be retained
> for.
> 
> -Scott

Agreed, we should define CONFIG_E500 as internal and used for common 
functionality between E500, E500MC, E5500, E6500.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC][PATCH 15/30] powerpc/85xx: Rework P1022DS device tree

2011-11-10 Thread Kumar Gala

On Nov 10, 2011, at 11:30 AM, Tabi Timur-B04825 wrote:

> On Thu, Nov 10, 2011 at 10:13 AM, Kumar Gala  
> wrote:
>> 
>>  arch/powerpc/boot/dts/fsl/p1022si-post.dtsi |  235 +++
>>  arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi  |   68 +
>>  arch/powerpc/boot/dts/p1022ds.dts   |  431 
>> +--
>>  3 files changed, 318 insertions(+), 416 deletions(-)
>>  create mode 100644 arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
>>  create mode 100644 arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi
> 
> I understand the value of removing duplication of DTS contents, so
> that we don't copy-paste the same nodes over and over again, but now
> that you've added pre- and post- dtsi files, I wonder if you're not
> jumping out of the frying pan and into the flame.  It seems that the
> DTS files are more fragile than ever, and it's more difficult now to
> figure out which files go where.

I hope that is not true, as the template is the same.

BOARD.dts:

include "fsl/SOCsi-pre.dtsi"

…

include "fsl/SOCsi-post.dtsi"

[ some boards may do more complicated things like we do on MPC8572DS to deal 
with 32-bit vs 36-bit addr maps, or CAMP use examples ]

All BOARD dts's should follow this pattern given the knowledge of which SoC you 
are utilizing.  For a board port, you should NEVER have to touch anything in 
the 'fsl/' directory.  That assumes, we've done a good job with the .dts struct 
in general.  From time to time I'm sure we'll find some pattern or IP block we 
need to fix.

> Another concern I have is whether this will force all P boards to
> have the same CCSR address.  I don't think so, because I didn't see
> it, but I just want to make sure.


Nope, we can have as many boards for the same SoC w/different address maps and 
share the same SOC.dtsi files

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC][PATCH 08/30] powerpc/85xx: Rework P1020 SoC device tree

2011-11-10 Thread Kumar Gala

On Nov 10, 2011, at 12:05 PM, Scott Wood wrote:

> On Thu, Nov 10, 2011 at 10:13:51AM -0600, Kumar Gala wrote:
>> Split the P1020 SoC device tree into what we can include as a 'prefix'
>> to the board device tree and what needs to be included as a 'postfix'.
>> 
>> This allows use more re-use and less duplication between various board
>> device tree configurations (32-bit address map vs 36-bit address map).
> 
> Could you elaborate on the issues that require this pre/post approach?

We utilize two 'features' of dtc to accomplish things.  One is includes the 
other is 'merging of labeled nodes'.

We can using merging to allow the board to specify the "reg" & "ranges" values 
of a SoC node that might vary between physical address maps (32-bit vs 36-bit 
as example).

dtc is able to 'merge' multiple labeled nodes as well.  So we use that to 
handle board specific values for something like localbus if we want to support 
both a 32-bit and 36-bit address map.

> What does the SoC part need to specify that has to override or go within
> something the board specifies?

Not sure I follow the question.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC][PATCH 28/30] powerpc/85xx: Rework P1023RDS device tree

2011-11-10 Thread Kumar Gala

On Nov 10, 2011, at 12:10 PM, Scott Wood wrote:

> On Thu, Nov 10, 2011 at 10:14:11AM -0600, Kumar Gala wrote:
>> -power@e0070{
>> -compatible = "fsl,mpc8536-pmc", "fsl,mpc8548-pmc",
>> - "fsl,p1022-pmc";
>> -reg = <0xe0070 0x20>;
>> -etsec1_clk: soc-clk@B0{
>> -fsl,pmcdr-mask = <0x0080>;
>> -};
>> -etsec2_clk: soc-clk@B1{
>> -fsl,pmcdr-mask = <0x0040>;
>> -};
>> -etsec3_clk: soc-clk@B2{
>> -fsl,pmcdr-mask = <0x0020>;
>> -};
>> -};
> 
> The compatibles on this node are wrong, but it looks like you're removing
> it altogether?
> 
> -Scott

Yeah, I think the whole thing needs to be relocated at because there are no 
etsec's on P1023, etc.  So will comment about this in commit message

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC][PATCH 28/30] powerpc/85xx: Rework P1023RDS device tree

2011-11-10 Thread Scott Wood
On Thu, Nov 10, 2011 at 10:14:11AM -0600, Kumar Gala wrote:
> - power@e0070{
> - compatible = "fsl,mpc8536-pmc", "fsl,mpc8548-pmc",
> -  "fsl,p1022-pmc";
> - reg = <0xe0070 0x20>;
> - etsec1_clk: soc-clk@B0{
> - fsl,pmcdr-mask = <0x0080>;
> - };
> - etsec2_clk: soc-clk@B1{
> - fsl,pmcdr-mask = <0x0040>;
> - };
> - etsec3_clk: soc-clk@B2{
> - fsl,pmcdr-mask = <0x0020>;
> - };
> - };

The compatibles on this node are wrong, but it looks like you're removing
it altogether?

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC][PATCH 08/30] powerpc/85xx: Rework P1020 SoC device tree

2011-11-10 Thread Scott Wood
On Thu, Nov 10, 2011 at 10:13:51AM -0600, Kumar Gala wrote:
> Split the P1020 SoC device tree into what we can include as a 'prefix'
> to the board device tree and what needs to be included as a 'postfix'.
> 
> This allows use more re-use and less duplication between various board
> device tree configurations (32-bit address map vs 36-bit address map).

Could you elaborate on the issues that require this pre/post approach?

What does the SoC part need to specify that has to override or go within
something the board specifies?

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC][PATCH 15/30] powerpc/85xx: Rework P1022DS device tree

2011-11-10 Thread Tabi Timur-B04825
On Thu, Nov 10, 2011 at 10:13 AM, Kumar Gala  wrote:
>
>  arch/powerpc/boot/dts/fsl/p1022si-post.dtsi |  235 +++
>  arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi  |   68 +
>  arch/powerpc/boot/dts/p1022ds.dts           |  431 
> +--
>  3 files changed, 318 insertions(+), 416 deletions(-)
>  create mode 100644 arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
>  create mode 100644 arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi

I understand the value of removing duplication of DTS contents, so
that we don't copy-paste the same nodes over and over again, but now
that you've added pre- and post- dtsi files, I wonder if you're not
jumping out of the frying pan and into the flame.  It seems that the
DTS files are more fragile than ever, and it's more difficult now to
figure out which files go where.

Another concern I have is whether this will force all P boards to
have the same CCSR address.  I don't think so, because I didn't see
it, but I just want to make sure.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 14/17] powerpc/e500: Don't make kgdb use e500v1/e500v2 registers on e500mc

2011-11-10 Thread Scott Wood
BOn Wed, Nov 09, 2011 at 07:07:12PM -0500, Kyle Moffett wrote:
> The only systems which need the sparse PowerPC register map are the
> e500v1/e500v2.

Is this due to SPE?

> +/*
> + * On FreeScale e500v1 or e500v2 processors we need to skip some register
> + * sections, so just add up a list of what we need to store.
> + *
> + * On all other 32-bit PowerPC we can just pick the last needed register.
> + */

The "s" in "Freescale" is not capitalized, BTW.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc

2011-11-10 Thread Moffett, Kyle D
On Nov 10, 2011, at 08:59, Kumar Gala wrote:
> On Nov 9, 2011, at 6:03 PM, Kyle Moffett wrote:
>> I saw Baruch Siach's patch:
>> powerpc: 85xx: separate e500 from e500mc
>> 
>> Unfortunately, that patch breaks the dependencies for the P5020DS
>> platform and does not fix the underlying code which does not
>> understand what the ambiguous "CONFIG_E500" means.
>> 
>> In order to fix the issue at the fundamental level, I created the
>> following 17-patch series loosely based on Baruch's patch.
>> 
>> === High-Level Summary ===
>> 
>> The e500v1/v2 and e500mc/e5500 CPU families are not compatible with
>> each other, yet they share the same "CONFIG_E500" Kconfig option.
>> 
>> The following patch series splits the 32-bit CPU support into two
>> separate options: "CONFIG_FSL_E500_V1_V2" and "CONFIG_FSL_E500MC".
>> Additionally, the 64-bit e5500 support is separated to its own config
>> option ("CONFIG_FSL_E5500") which is automatically combined with
>> either 32-bit e500MC or 64-bit Book-3E when the P5020DS board support
>> is enabled.
> 
> So its clear from the community that there is confusion here and we
> need to clean this up.  I guess my attempt to support an kernel that
> ran on both E500v2 and E500mc isn't worth it.  However I don't want to
> completely remove the ability to do this.

Well, a kernel built with CONFIG_PPC_E500MC today appears to be
fundamentally broken on E500v1/E500v2:

#if defined(CONFIG_8xx) || defined(CONFIG_403GCX)
#define L1_CACHE_SHIFT  4
#define MAX_COPY_PREFETCH   1
#elif defined(CONFIG_PPC_E500MC)
#define L1_CACHE_SHIFT  6
#define MAX_COPY_PREFETCH   4
#elif defined(CONFIG_PPC32)
#define MAX_COPY_PREFETCH   4
#if defined(CONFIG_PPC_47x)
#define L1_CACHE_SHIFT  7
#else
#define L1_CACHE_SHIFT  5
#endif
#else /* CONFIG_PPC64 */
#define L1_CACHE_SHIFT  7
#endif

E500MC will set L1_CACHE_SHIFT to 6, while regular E500 appears to
want it set to 5.  I don't know if that's a mistake or exactly what
code that affects, but it looks very wrong.

Furthermore, it looks like there are a couple issues here I missed
before.  PPC64 systems all appear to have an L1_CACHE_SHIFT of 7,
except when you turn on the P5020DS board option which magically
changes it to "6" and breaks lord-knows-what.  I think my patch
series actually "breaks" that and makes e5500 use 7 as well.

Are you sure that a kernel built to support E5500 can also run on
other 64-bit PowerPC/POWER systems?


> Towards the cleanup I'd ask for a proposal on what exactly the
> CONFIG_ options we'd end up with would be and their meaning.
> So today we have:
> 
> CONFIG_E500
> CONFIG_PPC_E500MC

It's actually a bit more complicated than that.  There are 3 ways
that the user can configure an e500 kernel today.  I'm omitting
the "FSL_SOC_BOOKE" menu that wraps around all of the 85xx/e5500
boards today, because that is set for all of these platforms:

  * PPC32 + PPC_85xx + E500 [+ boards]
  * PPC64 + BOOK3E_64 + P5020_DS (which adds E500 and PPC_E500MC)

Note that whether or not "PPC_E500MC" is set on PPC32 depends
only on which boards the user picked.  So if I am trying to
build an e500v2 kernel and I accidentally also turn on support
for one of the e500mc boards, my kernel mysteriously breaks.


> What do we want to move to?  I want to keep the builds such that we
> have only 2 classes:  e500V1/V2 and e500mc/e5500/e6500/.../eX500.
> I see no reason to hyper-optimize e500mc vs e5500 vs e6500.

So after my changes, there are the following user-configurable
option sets:
  * PPC32 + FSL_E500_V1_V2 [+ e500v1/v2 boards]
  * PPC32 + FSL_E500MC [+ e500mc boards]
  * PPC64 + BOOK3E_64 + P5020_DS (which adds FSL_E5500)

Since most of the "e500mc"-specific code was in 32-bit-only ASM
or inside of #ifdef PPC32, the new FSL_E500MC option is only
set on 32-bit builds, even if it is running in compat mode on
64-bit e5500 hardware)

Internally the P5020_DS option turns on the hidden FSL_E5500
option for both 32-bit and 64-bit; that config option enables
platform drivers and similar stuff.

Depending on how compatible the AMP processors are, you could
rename the option to be "FSL_E5X00" or add a hidden option for
"FSL_E6500" that is also selected by appropriate boards.

Please let me know if you think!

Cheers,
Kyle Moffett

--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/kvm: annotate kvm_rma_init as __init

2011-11-10 Thread Alexander Graf

On 11/08/2011 12:29 AM, Nishanth Aravamudan wrote:

kvm_rma_init() is only called at boot-time, by setup_arch, which is also __init.

Signed-off-by: Nishanth Aravamudan


Thanks, applied to kvm-ppc-next.


Alex


diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c 
b/arch/powerpc/kvm/book3s_hv_builtin.c
index d431203..73fdcc1 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -85,7 +85,7 @@ static inline int lpcr_rmls(unsigned long rma_size)
   * to allocate contiguous physical memory for the real memory
   * areas for guests.
   */
-void kvm_rma_init(void)
+void __init kvm_rma_init(void)
  {
unsigned long i;
unsigned long j, npages;



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/kvm: fix build with older toolchains

2011-11-10 Thread Alexander Graf

On 11/08/2011 12:36 AM, Nishanth Aravamudan wrote:

Fix KVM build for older toolchains (found with .powerpc64-unknown-linux-gnu-gcc
(crosstool-NG-1.8.1) 4.3.2):

   AS  arch/powerpc/kvm/book3s_hv_rmhandlers.o
arch/powerpc/kvm/book3s_hv_rmhandlers.S: Assembler messages:
arch/powerpc/kvm/book3s_hv_rmhandlers.S:1388: Error: Unrecognized opcode: 
`popcntw'
make[1]: *** [arch/powerpc/kvm/book3s_hv_rmhandlers.o] Error 1
make: *** [_module_arch/powerpc/kvm] Error 2

Signed-off-by: Nishanth Aravamudan


Thanks, applied to kvm-ppc-next.


Alex


diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index 0607909..a053db1 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -1385,7 +1385,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_206)
addir6,r5,VCORE_NAPPING_THREADS
  31:   lwarx   r4,0,r6
or  r4,r4,r0
-   popcntw r7,r4
+   PPC_POPCNTW(r7,r4)
cmpwr7,r8
bge 2f
stwcx.  r4,0,r6



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 08/17] powerpc/e500: Remove conditional "lwsync" substitution

2011-11-10 Thread Scott Wood
On Thu, Nov 10, 2011 at 10:42:25AM -0600, Kumar Gala wrote:
> 
> On Nov 10, 2011, at 10:31 AM, Scott Wood wrote:
> 
> > On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote:
> >> Nak, we can run an e500mc in a mode that is compatible with e500v1/v2.  I 
> >> see no reason to change the support we have there.
> > 
> > What "mode" do you mean?  DCBZ32?  We don't support using that currently,
> > and I'd imagine the performance implication would be such that you'd
> > never want to do it unless it's the only way to make some piece of legacy
> > software work.
> 
> Correct, DCBZ32, we've had customers that go down this path.

For running legacy software, or for multiplatform Linux kernels?

And if you're willing to toss performance away for this goal, why do you
need lwsync? :-)

DCBZ32 is not a "mode that is compatible with v1/v2", BTW.  It only
affects cache block size (for dcbz/dcba only), not SPE versus FP, not
changes in power management, not changes in machine check handling, etc.

Using DCBZ32 for the kernel would also complicate switching the kernel to
dcbzl, to support enabling DCBZ32 for certain userspace apps (a more
likely use case) without making it systemwide.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc

2011-11-10 Thread Scott Wood
On Thu, Nov 10, 2011 at 10:30:41AM -0600, Kumar Gala wrote:
> On Nov 10, 2011, at 10:17 AM, Moffett, Kyle D wrote:
> > Furthermore, it looks like there are a couple issues here I missed
> > before.  PPC64 systems all appear to have an L1_CACHE_SHIFT of 7,
> > except when you turn on the P5020DS board option which magically
> > changes it to "6" and breaks lord-knows-what.  I think my patch
> > series actually "breaks" that and makes e5500 use 7 as well.
> 
> a value of '6' on E5500 / P5020DS is correct and doesn't break anything.  
> Setting it to 7 is wrong and thus the code is correct today.
> 
> > Are you sure that a kernel built to support E5500 can also run on
> > other 64-bit PowerPC/POWER systems?
> 
> No it will not.  There is not expectation of that as E5500 is an
> embedded / Book-E class part and uses that ISA version.  Book-S
> (server) 64-bit machines are not OS compatible and we are not trying to
> make them as such (but we do re-use a lot of code).

What about other 64-bit book3e chips?  What cache block size does A2 have?

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 02/17] powerpc: Split up PHYS_64BIT config option to fix "select" issues

2011-11-10 Thread Timur Tabi
Moffett, Kyle D wrote:

> Did you look at the existing code?  It's already that complicated:
> 
> config ARCH_PHYS_ADDR_T_64BIT
>   def_bool PPC64 || PHYS_64BIT

I never understood why we have PHYS_64BIT and ARCH_PHYS_ADDR_T_64BIT, since 
they mean the same thing.  

> config ARCH_DMA_ADDR_T_64BIT
>   def_bool ARCH_PHYS_ADDR_T_64BIT
> 
> config {P1022_DS,P2041_RDB,P3041_DS,P3060_QDS,P4080_DS,P5020_DS}
>   select PHYS_64BIT

I posted a patch to remove the P1022_DS version of this.  I'm in favor of 
removing it from the other boards and letting the defconfig define it, but 
Kumar nak'd that idea.

> config PTE_64BIT
>   bool
>   depends on 44x || E500 || PPC_86xx
>   default y if PHYS_64BIT

I think this one is about how our TLB registers look, and it's not related to 
anything else.

> Even worse, PHYS_64BIT is not set on 64-bit processors, but there is
> a lot of driver code that seems to assume PHYS_64BIT indicates the
> size of "phys_addr_t".

There's a Kconfig option somewhere that takes care of this.

> The big issue is that the Kconfig docs are very clear that "select"
> should not be used on user-visible options (AKA: PHYS_64BIT), and yet
> half the PPC_85xx boards have this tidbit:
>   select PHYS_64BIT # The DTS has 36-bit addresses

I'm not sure that Kconfig rule is enforceable.  We use 'select' all the time to 
make sure that our boards enable the options that need to be enabled.  I'd 
rather see this:

config X
select A

config Y
select A

config Z
select A

than this:

config A
default y if X | Y | Z

The former is more maintainable and does not allow the option of disabling "A" 
if someone wants "X".

> I'm totally OK with removing that from all those boards, but to preserve
> the existing behavior (also used by the entire 44x platform) I added the
> new config symbol PHYS_64BIT_DT_REQUIRED, which is used to control
> whether or not the "PHYS_64BIT" option is even visible to the user.
> 
> I originally called it "PHYS_64BIT_REQUIRED", but since all of the
> board comments talked about 36-bit DTS addresses, I added the _DT_.

They're really 64-bit DTS addresses.  The 36 bit is just a hardware quirk of 
our SOCs.  From the kernel's perspective, there's no difference between 36-bit 
and 64-bit physical address.

>> There are only two reasons to create a 32-bit kernel:
>>
>> 1) A small performance improvement on systems with 2GB or less.
>> 2) Some SOC devices only support 32-bit physical addresses, so the
>> easiest way to ensure a compatible address is to prohibit memory above
>> 4GB.
> 
> If this is true, then why does PHYS_64BIT have that big ugly list of
> dependencies right now? 

Because Kumar doesn't want to allow 32-bit kernels on our high-end parts.  Like 
I said, I'm not a fan of that decision.

> I don't know about the other platforms well
> enough to tell what would break by enabling PHYS_64BIT, but I assume
> that something in the past caused that dependency list.

It's just an arbitrary decision.  We don't ship 32-bit DTs for the P4080-class 
parts, and we don't have a U-Boot configuration option for building a 32-bit 
compatible U-Boot.

-- 
Timur Tabi
Linux kernel developer at Freescale

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 13/17] powerpc/e500: Add a new CONFIG_FSL_E5500 option for the e5500

2011-11-10 Thread Scott Wood
On Wed, Nov 09, 2011 at 07:07:11PM -0500, Kyle Moffett wrote:
> As part of splitting CONFIG_E500 into separate options for e500v1/v2 and
> e500mc/e5500, some code only needs to be built when e5500 support is
> required.

How much code is this?  e5500 is basically just a 64-bit version of
e500mc.  When running a 32-bit kernel the extra code should be minimal.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 16/17] powerpc/e500: Make __setup_cpu_{e200,e500,e500mc,e5500} optional

2011-11-10 Thread Scott Wood
On Wed, Nov 09, 2011 at 07:07:14PM -0500, Kyle Moffett wrote:
> Only build the setup functions when the corresponding entries are
> included in the CPU table.
> 
> Signed-off-by: Kyle Moffett 
> ---
>  arch/powerpc/kernel/cpu_setup_fsl_booke.S |   14 +-
>  1 files changed, 13 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S 
> b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> index 8053db0..77721b2 100644
> --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> @@ -17,6 +17,8 @@
>  #include 
>  #include 
>  
> +#if defined(CONFIG_FSL_E500_V1_V2) || defined(CONFIG_FSL_E500MC) \
> + || defined(CONFIG_FSL_E5500)

This seems like the kind of thing that CONFIG_E500 should be retained
for.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 08/17] powerpc/e500: Remove conditional "lwsync" substitution

2011-11-10 Thread Kumar Gala

On Nov 10, 2011, at 10:31 AM, Scott Wood wrote:

> On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote:
>> 
>> On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:
>> 
>>> As FreeScale e500 systems have different cacheline sizes from e500mc, it
>>> is basically impossible for the kernel to support both in a single
>>> system image at present.
>>> 
>>> Given that one is SPE-float and the other is classic-float, they are not
>>> generally userspace-compatible either.
>>> 
>>> This patch updates the conditional to depend on whether the system is
>>> actually targetting an "e500" or "e500mc" core and entirely removes the
>>> unused sync-to-lwsync-replacement on e500v1/e500v2 systems.
>>> 
>>> Signed-off-by: Kyle Moffett 
>>> ---
>>> arch/powerpc/include/asm/synch.h |   16 
>>> 1 files changed, 4 insertions(+), 12 deletions(-)
>> 
>> Nak, we can run an e500mc in a mode that is compatible with e500v1/v2.  I 
>> see no reason to change the support we have there.
> 
> What "mode" do you mean?  DCBZ32?  We don't support using that currently,
> and I'd imagine the performance implication would be such that you'd
> never want to do it unless it's the only way to make some piece of legacy
> software work.

Correct, DCBZ32, we've had customers that go down this path.

>> I see no reason to change the support we have there.
> 
> No reason to remove complexity that is not needed, and is not planned to
> be needed?


I'd rather wait for at least 2 years for e500mc devices to have further 
deployment before we'd remove this.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 04/17] powerpc: Allow multiple machine-check handlers

2011-11-10 Thread Moffett, Kyle D
On Nov 10, 2011, at 08:37, Kumar Gala wrote:
> On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:
>> 
>> +#if defined(CONFIG_FSL_E500MC) || defined(CONFIG_FSL_E5500)
>> +#ifdef CONFIG_FSL_E500_V1_V2
> 
> doesn't exist yet, so patch is wrong sequence order.

Oops, d'oh.

You are completely correct, thanks for noticing!

I'll fix this for my next submission.

Cheers,
Kyle Moffett
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 02/17] powerpc: Split up PHYS_64BIT config option to fix "select" issues

2011-11-10 Thread Moffett, Kyle D
On Nov 10, 2011, at 09:04, Timur Tabi wrote:
> Kyle Moffett wrote:
>>  CONFIG_PHYS_64BIT_SUPPORTED:
>>This hidden option should be selected by any CPU type which supports
>>64-bit physical addresses.  This will enable the PHYS_64BIT option
>>to be selected.  It is (obviously) always set on PPC64.
>> 
>>  CONFIG_PHYS_64BIT_DT_REQUIRED:
>>This hidden option should be selected by any board or platform which
>>has >32-bit physical devices present in hardware.  If this is set
>>then the CONFIG_PHYS_64BIT option will be forcibly enabled and
>>hidden from the user.  It is (obviously) always set on PPC64.
>> 
>>  CONFIG_PHYS_64BIT:
>>This option is user-controllable, where allowed by CPU and platform
>>settings, and should never be pointed at with a "select" statement.
>>Due to the values of the above two options, this is never visible on
>>PPC64.
> 
> I'm with Kumar on this.  I don't see the point of making it so complicated.

Did you look at the existing code?  It's already that complicated:

config ARCH_PHYS_ADDR_T_64BIT
def_bool PPC64 || PHYS_64BIT

config ARCH_DMA_ADDR_T_64BIT
def_bool ARCH_PHYS_ADDR_T_64BIT

config {P1022_DS,P2041_RDB,P3041_DS,P3060_QDS,P4080_DS,P5020_DS}
select PHYS_64BIT

config 44x
select PHYS_64BIT

config PTE_64BIT
bool
depends on 44x || E500 || PPC_86xx
default y if PHYS_64BIT

config PHYS_64BIT
bool 'Large physical address support' if E500 || PPC_86xx
depends on (44x || E500 || PPC_86xx) && !PPC_83xx && !PPC_82xx

Even worse, PHYS_64BIT is not set on 64-bit processors, but there is
a lot of driver code that seems to assume PHYS_64BIT indicates the
size of "phys_addr_t".

> No kernel should ever have to care with a DT is 64-bit or 32-bit.  If
> you build a kernel with 64-bit phys support, then it will work with
> any DT.
> 

> U-Boot already warns you if the DT and the actual physical addresses
> of the devices don't match.

The big issue is that the Kconfig docs are very clear that "select"
should not be used on user-visible options (AKA: PHYS_64BIT), and yet
half the PPC_85xx boards have this tidbit:
select PHYS_64BIT # The DTS has 36-bit addresses

I'm totally OK with removing that from all those boards, but to preserve
the existing behavior (also used by the entire 44x platform) I added the
new config symbol PHYS_64BIT_DT_REQUIRED, which is used to control
whether or not the "PHYS_64BIT" option is even visible to the user.

I originally called it "PHYS_64BIT_REQUIRED", but since all of the
board comments talked about 36-bit DTS addresses, I added the _DT_.


> There are only two reasons to create a 32-bit kernel:
> 
> 1) A small performance improvement on systems with 2GB or less.
> 2) Some SOC devices only support 32-bit physical addresses, so the
> easiest way to ensure a compatible address is to prohibit memory above
> 4GB.

If this is true, then why does PHYS_64BIT have that big ugly list of
dependencies right now?  I don't know about the other platforms well
enough to tell what would break by enabling PHYS_64BIT, but I assume
that something in the past caused that dependency list.

Cheers,
Kyle Moffett

--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 08/17] powerpc/e500: Remove conditional "lwsync" substitution

2011-11-10 Thread Scott Wood
On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote:
> 
> On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:
> 
> > As FreeScale e500 systems have different cacheline sizes from e500mc, it
> > is basically impossible for the kernel to support both in a single
> > system image at present.
> > 
> > Given that one is SPE-float and the other is classic-float, they are not
> > generally userspace-compatible either.
> > 
> > This patch updates the conditional to depend on whether the system is
> > actually targetting an "e500" or "e500mc" core and entirely removes the
> > unused sync-to-lwsync-replacement on e500v1/e500v2 systems.
> > 
> > Signed-off-by: Kyle Moffett 
> > ---
> > arch/powerpc/include/asm/synch.h |   16 
> > 1 files changed, 4 insertions(+), 12 deletions(-)
> 
> Nak, we can run an e500mc in a mode that is compatible with e500v1/v2.  I see 
> no reason to change the support we have there.

What "mode" do you mean?  DCBZ32?  We don't support using that currently,
and I'd imagine the performance implication would be such that you'd
never want to do it unless it's the only way to make some piece of legacy
software work.

>  I see no reason to change the support we have there.

No reason to remove complexity that is not needed, and is not planned to
be needed?

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc

2011-11-10 Thread Kumar Gala

On Nov 10, 2011, at 10:17 AM, Moffett, Kyle D wrote:

> On Nov 10, 2011, at 08:59, Kumar Gala wrote:
>> On Nov 9, 2011, at 6:03 PM, Kyle Moffett wrote:
>>> I saw Baruch Siach's patch:
>>> powerpc: 85xx: separate e500 from e500mc
>>> 
>>> Unfortunately, that patch breaks the dependencies for the P5020DS
>>> platform and does not fix the underlying code which does not
>>> understand what the ambiguous "CONFIG_E500" means.
>>> 
>>> In order to fix the issue at the fundamental level, I created the
>>> following 17-patch series loosely based on Baruch's patch.
>>> 
>>> === High-Level Summary ===
>>> 
>>> The e500v1/v2 and e500mc/e5500 CPU families are not compatible with
>>> each other, yet they share the same "CONFIG_E500" Kconfig option.
>>> 
>>> The following patch series splits the 32-bit CPU support into two
>>> separate options: "CONFIG_FSL_E500_V1_V2" and "CONFIG_FSL_E500MC".
>>> Additionally, the 64-bit e5500 support is separated to its own config
>>> option ("CONFIG_FSL_E5500") which is automatically combined with
>>> either 32-bit e500MC or 64-bit Book-3E when the P5020DS board support
>>> is enabled.
>> 
>> So its clear from the community that there is confusion here and we
>> need to clean this up.  I guess my attempt to support an kernel that
>> ran on both E500v2 and E500mc isn't worth it.  However I don't want to
>> completely remove the ability to do this.
> 
> Well, a kernel built with CONFIG_PPC_E500MC today appears to be
> fundamentally broken on E500v1/E500v2:
> 
> #if defined(CONFIG_8xx) || defined(CONFIG_403GCX)
> #define L1_CACHE_SHIFT4
> #define MAX_COPY_PREFETCH 1
> #elif defined(CONFIG_PPC_E500MC)
> #define L1_CACHE_SHIFT6
> #define MAX_COPY_PREFETCH 4
> #elif defined(CONFIG_PPC32)
> #define MAX_COPY_PREFETCH 4
> #if defined(CONFIG_PPC_47x)
> #define L1_CACHE_SHIFT7
> #else
> #define L1_CACHE_SHIFT5
> #endif
> #else /* CONFIG_PPC64 */
> #define L1_CACHE_SHIFT7
> #endif
> 
> E500MC will set L1_CACHE_SHIFT to 6, while regular E500 appears to
> want it set to 5.  I don't know if that's a mistake or exactly what
> code that affects, but it looks very wrong.

This is correct for E500 & E500MC.  However we have a HW mode that allows us to 
handle running in 'e500' mode on e500mc.

> Furthermore, it looks like there are a couple issues here I missed
> before.  PPC64 systems all appear to have an L1_CACHE_SHIFT of 7,
> except when you turn on the P5020DS board option which magically
> changes it to "6" and breaks lord-knows-what.  I think my patch
> series actually "breaks" that and makes e5500 use 7 as well.

a value of '6' on E5500 / P5020DS is correct and doesn't break anything.  
Setting it to 7 is wrong and thus the code is correct today.

> Are you sure that a kernel built to support E5500 can also run on
> other 64-bit PowerPC/POWER systems?

No it will not.  There is not expectation of that as E5500 is an embedded / 
Book-E class part and uses that ISA version.  Book-S (server) 64-bit machines 
are not OS compatible and we are not trying to make them as such (but we do 
re-use a lot of code).

>> Towards the cleanup I'd ask for a proposal on what exactly the
>> CONFIG_ options we'd end up with would be and their meaning.
>> So today we have:
>> 
>> CONFIG_E500
>> CONFIG_PPC_E500MC
> 
> It's actually a bit more complicated than that.  There are 3 ways
> that the user can configure an e500 kernel today.  I'm omitting
> the "FSL_SOC_BOOKE" menu that wraps around all of the 85xx/e5500
> boards today, because that is set for all of these platforms:
> 
>  * PPC32 + PPC_85xx + E500 [+ boards]
>  * PPC64 + BOOK3E_64 + P5020_DS (which adds E500 and PPC_E500MC)
> 
> Note that whether or not "PPC_E500MC" is set on PPC32 depends
> only on which boards the user picked.  So if I am trying to
> build an e500v2 kernel and I accidentally also turn on support
> for one of the e500mc boards, my kernel mysteriously breaks.

sure, I understand I'm fine with us 'fixing' things such that we treat 
E500V1/V2 differently from E500MC/E5500 in user Kconfig choices

>> What do we want to move to?  I want to keep the builds such that we
>> have only 2 classes:  e500V1/V2 and e500mc/e5500/e6500/.../eX500.
>> I see no reason to hyper-optimize e500mc vs e5500 vs e6500.
> 
> So after my changes, there are the following user-configurable
> option sets:
>  * PPC32 + FSL_E500_V1_V2 [+ e500v1/v2 boards]
>  * PPC32 + FSL_E500MC [+ e500mc boards]
>  * PPC64 + BOOK3E_64 + P5020_DS (which adds FSL_E5500)
> 
> Since most of the "e500mc"-specific code was in 32-bit-only ASM
> or inside of #ifdef PPC32, the new FSL_E500MC option is only
> set on 32-bit builds, even if it is running in compat mode on
> 64-bit e5500 hardware)
> 
> Internally the P5020_DS option turns on the hidden FSL_E5500
> option for both 32-bit and 64-bit; that config option enables
> platform drivers and similar stuff.
> 
> Depending on how compatible the AMP proc

Re: [PATCH 01/11] powerpc/85xx: Add 'fsl, pq3-gpio' compatiable for GPIO driver

2011-11-10 Thread Kumar Gala
oops, sent the wrong set of patches, ignore this group.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[RFC][PATCH 30/30] powerpc/85xx: Rework MPC8569MDS device tree

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/fsl/mpc8569si-post.dtsi |  292 ++
 arch/powerpc/boot/dts/fsl/mpc8569si-pre.dtsi  |   64 
 arch/powerpc/boot/dts/mpc8569mds.dts  |  409 ++---
 3 files changed, 389 insertions(+), 376 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/mpc8569si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/mpc8569si-pre.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/mpc8569si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/mpc8569si-post.dtsi
new file mode 100644
index 000..eb75a18
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/mpc8569si-post.dtsi
@@ -0,0 +1,292 @@
+/*
+ * MPC8569 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+   #address-cells = <2>;
+   #size-cells = <1>;
+   compatible = "fsl,mpc8569-elbc", "fsl,elbc", "simple-bus";
+   interrupts = <19 2 0 0>;
+   sleep = <&pmc 0x0800>;
+};
+
+/* controller at 0xa000 */
+&pci1 {
+   compatible = "fsl,mpc8548-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <26 2 0 0>;
+   sleep = <&pmc 0x2000>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <26 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x0 0x1 0x0 0x0
+    0x0 0x0 0x2 &mpic 0x1 0x1 0x0 0x0
+    0x0 0x0 0x3 &mpic 0x2 0x1 0x0 0x0
+    0x0 0x0 0x4 &mpic 0x3 0x1 0x0 0x0
+   >;
+   };
+};
+
+&rio {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   compatible = "fsl,mpc8569-rapidio", "fsl,rapidio-delta";
+   interrupts = <48 2 0 0 /* error */
+ 49 2 0 0 /* bell_outb */
+ 50 2 0 0 /* bell_inb  */
+ 53 2 0 0 /* msg1_tx   */
+ 54 2 0 0 /* msg1_rx   */
+ 55 2 0 0 /* msg2_tx   */
+ 56 2 0 0 /* msg2_rx   */>;
+   sleep = <&pmc 0x0008>;
+};
+
+&soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   device_type = "soc";
+   compatible = "fsl,mpc8569-immr", "simple-bus";
+   bus-frequency = <0>;// Filled out by uboot.
+
+   ecm-law@0 {
+   compatible = "fsl,ecm-law";
+   reg = <0x0 0x1000>;
+   fsl,num-laws = <10>;
+   };
+
+   ecm@1000 {
+   compatible = "fsl,mpc8569-ecm", "fsl,ecm";
+   reg = <0x1000 0x1000>;
+   interrupts = <17 2 0 0>;
+   };
+
+   memory-controller@2000 {
+   compatible = "fsl,mpc8569-memory-controller";
+   reg = <0x2000 0x1000>;
+   interrupts = <18 2 0 0>;
+   };
+
+   i2c-sleep-nexus {
+  

[RFC][PATCH 29/30] powerpc/85xx: Rework MPC8568MDS device tree

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/fsl/mpc8568si-post.dtsi |  265 ++
 arch/powerpc/boot/dts/fsl/mpc8568si-pre.dtsi  |   65 
 arch/powerpc/boot/dts/mpc8568mds.dts  |  480 -
 3 files changed, 393 insertions(+), 417 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/mpc8568si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/mpc8568si-pre.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/mpc8568si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/mpc8568si-post.dtsi
new file mode 100644
index 000..6a9cca8
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/mpc8568si-post.dtsi
@@ -0,0 +1,265 @@
+/*
+ * MPC8568 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+   #address-cells = <2>;
+   #size-cells = <1>;
+   compatible = "fsl,mpc8568-localbus", "fsl,pq3-localbus", "simple-bus";
+   interrupts = <19 2 0 0>;
+   sleep = <&pmc 0x0800>;
+};
+
+/* controller at 0x8000 */
+&pci0 {
+   compatible = "fsl,mpc8540-pci";
+   device_type = "pci";
+   interrupts = <24 0x2 0 0>;
+   bus-range = <0 0xff>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   sleep = <&pmc 0x8000>;
+};
+
+/* controller at 0xa000 */
+&pci1 {
+   compatible = "fsl,mpc8548-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <26 2 0 0>;
+   sleep = <&pmc 0x2000>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <26 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x0 0x1 0x0 0x0
+    0x0 0x0 0x2 &mpic 0x1 0x1 0x0 0x0
+    0x0 0x0 0x3 &mpic 0x2 0x1 0x0 0x0
+    0x0 0x0 0x4 &mpic 0x3 0x1 0x0 0x0
+   >;
+   };
+};
+
+&rio {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   compatible = "fsl,mpc8568-rapidio", "fsl,rapidio-delta";
+   interrupts = <48 2 0 0 /* error */
+ 49 2 0 0 /* bell_outb */
+ 50 2 0 0 /* bell_inb  */
+ 53 2 0 0 /* msg1_tx   */
+ 54 2 0 0 /* msg1_rx   */
+ 55 2 0 0 /* msg2_tx   */
+ 56 2 0 0 /* msg2_rx   */>;
+   sleep = <&pmc 0x0008   /* controller */
+&pmc 0x0004>; /* message unit */
+};
+
+&soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   device_type = "soc";
+   compatible = "fsl,mpc8568-immr", "simple-bus";
+   bus-frequency = <0>;// Filled out by uboot.
+
+   ecm-law@0 {
+   compatible = "fsl,ecm-law";
+   reg = <0x0 0x1000>;
+   fsl,num-laws = <10>;
+   };
+
+   ecm@1000

[RFC][PATCH 28/30] powerpc/85xx: Rework P1023RDS device tree

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/fsl/p1023si-post.dtsi |  248 ++
 arch/powerpc/boot/dts/fsl/p1023si-pre.dtsi  |   76 ++
 arch/powerpc/boot/dts/p1023rds.dts  |  372 +--
 3 files changed, 330 insertions(+), 366 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/p1023si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/p1023si-pre.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/p1023si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p1023si-post.dtsi
new file mode 100644
index 000..b29330c
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/p1023si-post.dtsi
@@ -0,0 +1,248 @@
+/*
+ * P1023/P1017 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+   #address-cells = <2>;
+   #size-cells = <1>;
+   compatible = "fsl,p1023-elbc", "fsl,elbc", "simple-bus";
+   interrupts = <19 2 0 0>;
+};
+
+/* controller at 0xa000 */
+&pci0 {
+   compatible = "fsl,p1023-pcie", "fsl,qoriq-pcie-v2.2";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0x0 0xff>;
+   clock-frequency = <>;
+   interrupts = <16 2 0 0>;
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0 0 1 &mpic 0 1 0 0
+    0 0 2 &mpic 1 1 0 0
+    0 0 3 &mpic 2 1 0 0
+    0 0 4 &mpic 3 1 0 0
+   >;
+   };
+};
+
+/* controller at 0x9000 */
+&pci1 {
+   compatible = "fsl,p1023-pcie", "fsl,qoriq-pcie-v2.2";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 0xff>;
+   clock-frequency = <>;
+   interrupts = <16 2 0 0>;
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0 0 1 &mpic 4 1 0 0
+    0 0 2 &mpic 5 1 0 0
+    0 0 3 &mpic 6 1 0 0
+    0 0 4 &mpic 7 1 0 0
+   >;
+   };
+};
+
+/* controller at 0xb000 */
+&pci2 {
+   compatible = "fsl,p1023-pcie", "fsl,qoriq-pcie-v2.2";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0x0 0xff>;
+   clock-frequency = <>;
+   interrupts = <16 2 0 0>;
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type 

[RFC][PATCH 27/30] powerpc/85xx: Rework P3060QDS device tree

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/fsl/p3060si-post.dtsi |  296 +++
 arch/powerpc/boot/dts/fsl/p3060si-pre.dtsi  |  125 +
 arch/powerpc/boot/dts/p3060qds.dts  |   12 +-
 arch/powerpc/boot/dts/p3060si.dtsi  |  719 ---
 4 files changed, 430 insertions(+), 722 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/p3060si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/p3060si-pre.dtsi
 delete mode 100644 arch/powerpc/boot/dts/p3060si.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/p3060si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p3060si-post.dtsi
new file mode 100644
index 000..a63edd1
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/p3060si-post.dtsi
@@ -0,0 +1,296 @@
+/*
+ * P3060 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+   compatible = "fsl,p3060-elbc", "fsl,elbc", "simple-bus";
+   interrupts = <25 2 0 0>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+};
+
+/* controller at 0x20 */
+&pci0 {
+   compatible = "fsl,p3060-pcie", "fsl,qoriq-pcie-v2.2";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0x0 0xff>;
+   clock-frequency = <>;
+   interrupts = <16 2 1 15>;
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 1 15>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0 0 1 &mpic 40 1 0 0
+    0 0 2 &mpic 1 1 0 0
+    0 0 3 &mpic 2 1 0 0
+    0 0 4 &mpic 3 1 0 0
+   >;
+   };
+};
+
+/* controller at 0x201000 */
+&pci1 {
+   compatible = "fsl,p3060-pcie", "fsl,qoriq-pcie-v2.2";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 0xff>;
+   clock-frequency = <>;
+   interrupts = <16 2 1 14>;
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 1 14>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0 0 1 &mpic 41 1 0 0
+    0 0 2 &mpic 5 1 0 0
+    0 0 3 &mpic 6 1 0 0
+    0 0 4 &mpic 7 1 0 0
+   >;
+   };
+};
+
+&rio {
+   compatible = "fsl,srio";
+   interrupts = <16 2 1 11>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   fsl,srio-rmu-handle = <&rmu>;
+   ranges;
+
+   port1 {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   cell-index = <1>;
+   };
+
+   port2 {
+   #address-cells = <2

[RFC][PATCH 26/30] powerpc/85xx: Rework P2041RDB device tree

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/fsl/p2041si-post.dtsi |  332 +++
 arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi  |  112 +
 arch/powerpc/boot/dts/p2041rdb.dts  |   28 ++-
 3 files changed, 470 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
new file mode 100644
index 000..c653465
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
@@ -0,0 +1,332 @@
+/*
+ * P2041/P2040 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+   compatible = "fsl,p2041-elbc", "fsl,elbc", "simple-bus";
+   interrupts = <25 2 0 0>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+};
+
+/* controller at 0x20 */
+&pci0 {
+   compatible = "fsl,p2041-pcie", "fsl,qoriq-pcie-v2.2";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0x0 0xff>;
+   clock-frequency = <>;
+   interrupts = <16 2 1 15>;
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 1 15>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0 0 1 &mpic 40 1 0 0
+    0 0 2 &mpic 1 1 0 0
+    0 0 3 &mpic 2 1 0 0
+    0 0 4 &mpic 3 1 0 0
+   >;
+   };
+};
+
+/* controller at 0x201000 */
+&pci1 {
+   compatible = "fsl,p2041-pcie", "fsl,qoriq-pcie-v2.2";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 0xff>;
+   clock-frequency = <>;
+   interrupts = <16 2 1 14>;
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 1 14>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0 0 1 &mpic 41 1 0 0
+    0 0 2 &mpic 5 1 0 0
+    0 0 3 &mpic 6 1 0 0
+    0 0 4 &mpic 7 1 0 0
+   >;
+   };
+};
+
+/* controller at 0x202000 */
+&pci2 {
+   compatible = "fsl,p2041-pcie", "fsl,qoriq-pcie-v2.2";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0x0 0xff>;
+   clock-frequency = <>;
+   interrupts = <16 2 1 13>;
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type =

[RFC][PATCH 25/30] powerpc/85xx: Rework P3041DS device tree

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/fsl/p3041si-post.dtsi |  332 
 arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi  |  112 
 arch/powerpc/boot/dts/p3041ds.dts   |   12 +-
 arch/powerpc/boot/dts/p3041si.dtsi  |  729 ---
 4 files changed, 454 insertions(+), 731 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/p3041si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi
 delete mode 100644 arch/powerpc/boot/dts/p3041si.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/p3041si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p3041si-post.dtsi
new file mode 100644
index 000..9cda481
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/p3041si-post.dtsi
@@ -0,0 +1,332 @@
+/*
+ * P3041 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+   compatible = "fsl,p3041-elbc", "fsl,elbc", "simple-bus";
+   interrupts = <25 2 0 0>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+};
+
+/* controller at 0x20 */
+&pci0 {
+   compatible = "fsl,p3041-pcie", "fsl,qoriq-pcie-v2.2";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0x0 0xff>;
+   clock-frequency = <>;
+   interrupts = <16 2 1 15>;
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 1 15>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0 0 1 &mpic 40 1 0 0
+    0 0 2 &mpic 1 1 0 0
+    0 0 3 &mpic 2 1 0 0
+    0 0 4 &mpic 3 1 0 0
+   >;
+   };
+};
+
+/* controller at 0x201000 */
+&pci1 {
+   compatible = "fsl,p3041-pcie", "fsl,qoriq-pcie-v2.2";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 0xff>;
+   clock-frequency = <>;
+   interrupts = <16 2 1 14>;
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 1 14>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0 0 1 &mpic 41 1 0 0
+    0 0 2 &mpic 5 1 0 0
+    0 0 3 &mpic 6 1 0 0
+    0 0 4 &mpic 7 1 0 0
+   >;
+   };
+};
+
+/* controller at 0x202000 */
+&pci2 {
+   compatible = "fsl,p3041-pcie", "fsl,qoriq-pcie-v2.2";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0x0 0xff>;
+   clock-frequency = <>;
+   interrupts = <16 2 1 13>;
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells

[RFC][PATCH 24/30] powerpc/85xx: Rework P5020DS device tree

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/fsl/p5020si-post.dtsi |  335 +
 arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi  |   96 
 arch/powerpc/boot/dts/p5020ds.dts   |   13 +-
 arch/powerpc/boot/dts/p5020si.dtsi  |  716 ---
 4 files changed, 441 insertions(+), 719 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/p5020si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi
 delete mode 100644 arch/powerpc/boot/dts/p5020si.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/p5020si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p5020si-post.dtsi
new file mode 100644
index 000..7135c67
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/p5020si-post.dtsi
@@ -0,0 +1,335 @@
+/*
+ * P5020/5010 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+   compatible = "fsl,p5020-elbc", "fsl,elbc", "simple-bus";
+   interrupts = <25 2 0 0>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+};
+
+/* controller at 0x20 */
+&pci0 {
+   compatible = "fsl,p5020-pcie", "fsl,qoriq-pcie-v2.2";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0x0 0xff>;
+   clock-frequency = <>;
+   interrupts = <16 2 1 15>;
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 1 15>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0 0 1 &mpic 40 1 0 0
+    0 0 2 &mpic 1 1 0 0
+    0 0 3 &mpic 2 1 0 0
+    0 0 4 &mpic 3 1 0 0
+   >;
+   };
+};
+
+/* controller at 0x201000 */
+&pci1 {
+   compatible = "fsl,p5020-pcie", "fsl,qoriq-pcie-v2.2";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 0xff>;
+   clock-frequency = <>;
+   interrupts = <16 2 1 14>;
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 1 14>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0 0 1 &mpic 41 1 0 0
+    0 0 2 &mpic 5 1 0 0
+    0 0 3 &mpic 6 1 0 0
+    0 0 4 &mpic 7 1 0 0
+   >;
+   };
+};
+
+/* controller at 0x202000 */
+&pci2 {
+   compatible = "fsl,p5020-pcie", "fsl,qoriq-pcie-v2.2";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0x0 0xff>;
+   clock-frequency = <>;
+   interrupts = <16 2 1 13>;
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt

[RFC][PATCH 23/30] powerpc/85xx: Rework P4080DS device trees

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/fsl/p4080si-post.dtsi |  342 
 arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi  |  145 +
 arch/powerpc/boot/dts/p4080ds.dts   |   14 +-
 arch/powerpc/boot/dts/p4080si.dtsi  |  755 ---
 4 files changed, 498 insertions(+), 758 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi
 delete mode 100644 arch/powerpc/boot/dts/p4080si.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
new file mode 100644
index 000..1510991
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
@@ -0,0 +1,342 @@
+/*
+ * P4080/P4040 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+   compatible = "fsl,p4080-elbc", "fsl,elbc", "simple-bus";
+   interrupts = <25 2 0 0>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+};
+
+/* controller at 0x20 */
+&pci0 {
+   compatible = "fsl,p4080-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0x0 0xff>;
+   clock-frequency = <>;
+   interrupts = <16 2 1 15>;
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 1 15>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0 0 1 &mpic 40 1 0 0
+    0 0 2 &mpic 1 1 0 0
+    0 0 3 &mpic 2 1 0 0
+    0 0 4 &mpic 3 1 0 0
+   >;
+   };
+};
+
+/* controller at 0x201000 */
+&pci1 {
+   compatible = "fsl,p4080-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 0xff>;
+   clock-frequency = <>;
+   interrupts = <16 2 1 14>;
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 1 14>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0 0 1 &mpic 41 1 0 0
+    0 0 2 &mpic 5 1 0 0
+    0 0 3 &mpic 6 1 0 0
+    0 0 4 &mpic 7 1 0 0
+   >;
+   };
+};
+
+/* controller at 0x202000 */
+&pci2 {
+   compatible = "fsl,p4080-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0x0 0xff>;
+   clock-frequency = <>;
+   interrupts = <16 2 1 13>;
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #ad

[RFC][PATCH 22/30] powerpc/85xx: Rework MPC8548CDS device trees

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/fsl/mpc8548si-post.dtsi |  143 +++
 arch/powerpc/boot/dts/fsl/mpc8548si-pre.dtsi  |   62 +++
 arch/powerpc/boot/dts/mpc8548cds.dts  |  505 ++---
 3 files changed, 327 insertions(+), 383 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/mpc8548si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/mpc8548si-pre.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/mpc8548si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/mpc8548si-post.dtsi
new file mode 100644
index 000..9d8023a
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/mpc8548si-post.dtsi
@@ -0,0 +1,143 @@
+/*
+ * MPC8548 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+   #address-cells = <2>;
+   #size-cells = <1>;
+   compatible = "fsl,mpc8548-lbc", "fsl,pq3-localbus", "simple-bus";
+   interrupts = <19 2 0 0>;
+};
+
+/* controller at 0x8000 */
+&pci0 {
+   compatible = "fsl,mpc8540-pcix", "fsl,mpc8540-pci";
+   device_type = "pci";
+   interrupts = <24 0x2 0 0>;
+   bus-range = <0 0xff>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+};
+
+/* controller at 0x9000 */
+&pci1 {
+   compatible = "fsl,mpc8540-pci";
+   device_type = "pci";
+   interrupts = <25 0x2 0 0>;
+   bus-range = <0 0xff>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+};
+
+/* controller at 0xa000 */
+&pci2 {
+   compatible = "fsl,mpc8548-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <26 2 0 0>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <26 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x0 0x1 0x0 0x0
+    0x0 0x0 0x2 &mpic 0x1 0x1 0x0 0x0
+    0x0 0x0 0x3 &mpic 0x2 0x1 0x0 0x0
+    0x0 0x0 0x4 &mpic 0x3 0x1 0x0 0x0
+   >;
+   };
+};
+
+&soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   device_type = "soc";
+   compatible = "fsl,mpc8548-immr", "simple-bus";
+   bus-frequency = <0>;// Filled out by uboot.
+
+   ecm-law@0 {
+   compatible = "fsl,ecm-law";
+   reg = <0x0 0x1000>;
+   fsl,num-laws = <10>;
+   };
+
+   ecm@1000 {
+   compatible = "fsl,mpc8548-ecm", "fsl,ecm";
+   reg = <0x1000 0x1000>;
+   interrupts = <17 2 0 0>;
+   };
+
+   memory-controller@2000 {
+   compatible = "fsl,mpc8548-memory-controller";
+   reg = <0x2000 0x1000>;
+   interrupts = <18 2 0 0>;
+   };
+
+/include/ "pq3-i2c-0.dtsi"
+/include/ "pq3-i2c-1.dtsi"
+/incl

[RFC][PATCH 21/30] powerpc/85xx: Rework MPC8544DS device tree

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/fsl/mpc8544si-post.dtsi |  191 ++
 arch/powerpc/boot/dts/fsl/mpc8544si-pre.dtsi  |   63 
 arch/powerpc/boot/dts/mpc8544ds.dts   |  473 ++---
 arch/powerpc/boot/dts/mpc8544ds.dtsi  |  161 +
 4 files changed, 453 insertions(+), 435 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/mpc8544si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/mpc8544si-pre.dtsi
 create mode 100644 arch/powerpc/boot/dts/mpc8544ds.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/mpc8544si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/mpc8544si-post.dtsi
new file mode 100644
index 000..f73ba4e
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/mpc8544si-post.dtsi
@@ -0,0 +1,191 @@
+/*
+ * MPC8544 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+   #address-cells = <2>;
+   #size-cells = <1>;
+   compatible = "fsl,mpc8544-lbc", "fsl,pq3-localbus", "simple-bus";
+   interrupts = <19 2 0 0>;
+};
+
+/* controller at 0x8000 */
+&pci0 {
+   compatible = "fsl,mpc8540-pci";
+   device_type = "pci";
+   interrupts = <24 0x2 0 0>;
+   bus-range = <0 0xff>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+};
+
+/* controller at 0x9000 */
+&pci1 {
+   compatible = "fsl,mpc8548-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <25 2 0 0>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <25 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x4 0x1 0x0 0x0
+    0x0 0x0 0x2 &mpic 0x5 0x1 0x0 0x0
+    0x0 0x0 0x3 &mpic 0x6 0x1 0x0 0x0
+    0x0 0x0 0x4 &mpic 0x7 0x1 0x0 0x0
+   >;
+   };
+};
+
+/* controller at 0xa000 */
+&pci2 {
+   compatible = "fsl,mpc8548-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <26 2 0 0>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <26 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x0 0x1 0x0 0x0
+    0x0 0x0 0x2 &mpic 0x1 0x1 0x0 0x0
+    0x0 0x0 0x3 &mpic 0x2 0x1 0x0 0x0
+    0x0 0x0 0x4 &mpic 0x3 0x1 0x0 0x0
+   >;
+   };
+};
+
+/* controlle

[RFC][PATCH 20/30] powerpc/85xx: Rework MPC8536DS device trees

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi |  248 ++
 arch/powerpc/boot/dts/fsl/mpc8536si-pre.dtsi  |   63 
 arch/powerpc/boot/dts/mpc8536ds.dts   |  456 +
 arch/powerpc/boot/dts/mpc8536ds.dtsi  |  141 
 arch/powerpc/boot/dts/mpc8536ds_36b.dts   |  410 ++-
 5 files changed, 489 insertions(+), 829 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/mpc8536si-pre.dtsi
 create mode 100644 arch/powerpc/boot/dts/mpc8536ds.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
new file mode 100644
index 000..8365be6
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
@@ -0,0 +1,248 @@
+/*
+ * MPC8536 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+   #address-cells = <2>;
+   #size-cells = <1>;
+   compatible = "fsl,mpc8536-elbc", "fsl,elbc", "simple-bus";
+   interrupts = <19 2 0 0>;
+};
+
+/* controller at 0x8000 */
+&pci0 {
+   compatible = "fsl,mpc8540-pci";
+   device_type = "pci";
+   interrupts = <24 0x2 0 0>;
+   bus-range = <0 0xff>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+};
+
+/* controller at 0x9000 */
+&pci1 {
+   compatible = "fsl,mpc8548-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <25 2 0 0>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <25 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x4 0x1 0x0 0x0
+    0x0 0x0 0x2 &mpic 0x5 0x1 0x0 0x0
+    0x0 0x0 0x3 &mpic 0x6 0x1 0x0 0x0
+    0x0 0x0 0x4 &mpic 0x7 0x1 0x0 0x0
+   >;
+   };
+};
+
+/* controller at 0xa000 */
+&pci2 {
+   compatible = "fsl,mpc8548-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <26 2 0 0>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <26 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x0 0x1 0x0 0x0
+    0x0 0x0 0x2 &mpic 0x1 0x1 0x0 0x0
+    0x0 0x0 0x3 &mpic 0x2 0x1 0x0 0x0
+    0x0 0x0 0x4 &mpic

[RFC][PATCH 18/30] powerpc/85xx: Rework P1021MDS device tree

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/fsl/p1021si-post.dtsi |  225 ++
 arch/powerpc/boot/dts/fsl/p1021si-pre.dtsi  |   68 +
 arch/powerpc/boot/dts/p1021mds.dts  |  421 ++-
 3 files changed, 314 insertions(+), 400 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/p1021si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/p1021si-pre.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/p1021si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p1021si-post.dtsi
new file mode 100644
index 000..38ba54d
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/p1021si-post.dtsi
@@ -0,0 +1,225 @@
+/*
+ * P1021/P1012 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+   #address-cells = <2>;
+   #size-cells = <1>;
+   compatible = "fsl,p1021-elbc", "fsl,elbc", "simple-bus";
+   interrupts = <19 2 0 0>;
+};
+
+/* controller at 0x9000 */
+&pci0 {
+   compatible = "fsl,mpc8548-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <16 2 0 0>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x4 0x1 0x0 0x0
+    0x0 0x0 0x2 &mpic 0x5 0x1 0x0 0x0
+    0x0 0x0 0x3 &mpic 0x6 0x1 0x0 0x0
+    0x0 0x0 0x4 &mpic 0x7 0x1 0x0 0x0
+   >;
+   };
+};
+
+/* controller at 0xa000 */
+&pci1 {
+   compatible = "fsl,mpc8548-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <16 2 0 0>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x0 0x1 0x0 0x0
+    0x0 0x0 0x2 &mpic 0x1 0x1 0x0 0x0
+    0x0 0x0 0x3 &mpic 0x2 0x1 0x0 0x0
+    0x0 0x0 0x4 &mpic 0x3 0x1 0x0 0x0
+   >;
+   };
+};
+
+&soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   device_type = "soc";
+   compatible = "fsl,p1021-immr", "simple-bus";
+   bus-frequency = <0>;// Filled out by uboot.
+
+   ecm-law@0 {
+   compatible = "fsl,ecm-law";
+   reg = <0x0 0x1000>;
+   fsl,num-laws = <12>;
+   };
+
+   ecm@1000 {
+   compatible = "fs

[RFC][PATCH 17/30] powerpc/85xx: Rework P2020RDB device tree

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/p2020rdb.dts|   63 ++---
 arch/powerpc/boot/dts/p2020rdb_camp_core0.dts |  141 +--
 arch/powerpc/boot/dts/p2020rdb_camp_core1.dts |  107 +
 arch/powerpc/boot/dts/p2020si.dtsi|  355 -
 4 files changed, 22 insertions(+), 644 deletions(-)
 delete mode 100644 arch/powerpc/boot/dts/p2020si.dtsi

diff --git a/arch/powerpc/boot/dts/p2020rdb.dts 
b/arch/powerpc/boot/dts/p2020rdb.dts
index 1d7a05f..fd42712 100644
--- a/arch/powerpc/boot/dts/p2020rdb.dts
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -9,7 +9,7 @@
  * option) any later version.
  */
 
-/include/ "p2020si.dtsi"
+/include/ "fsl/p2020si-pre.dtsi"
 
 / {
model = "fsl,P2020RDB";
@@ -29,7 +29,8 @@
device_type = "memory";
};
 
-   localbus@ffe05000 {
+   lbc: localbus@ffe05000 {
+   reg = <0 0xffe05000 0 0x1000>;
 
/* NOR and NAND Flashes */
ranges = <0x0 0x0 0x0 0xef00 0x0100
@@ -140,7 +141,9 @@
 
};
 
-   soc@ffe0 {
+   soc: soc@ffe0 {
+   ranges = <0x0 0x0 0xffe0 0x10>;
+
i2c@3000 {
rtc@68 {
compatible = "dallas,ds1339";
@@ -148,17 +151,13 @@
};
};
 
-   spi@7000 {
-
-   fsl_m25p80@0 {
+   spi@7000 {
+   flash@0 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "fsl,espi-flash";
+   compatible = "spansion,s25sl12801";
reg = <0>;
-   linux,modalias = "fsl_m25p80";
-   modal = "s25sl128b";
spi-max-frequency = <5000>;
-   mode = <0>;
 
partition@0 {
/* 512KB for u-boot Bootloader Image */
@@ -202,13 +201,11 @@
 
mdio@24520 {
phy0: ethernet-phy@0 {
-   interrupt-parent = <&mpic>;
-   interrupts = <3 1>;
+   interrupts = <3 1 0 0>;
reg = <0x0>;
};
phy1: ethernet-phy@1 {
-   interrupt-parent = <&mpic>;
-   interrupts = <3 1>;
+   interrupts = <3 1 0 0>;
reg = <0x1>;
};
};
@@ -224,11 +221,7 @@
status = "disabled";
};
 
-   ptp_clock@24E00 {
-   compatible = "fsl,etsec-ptp";
-   reg = <0x24E00 0xB0>;
-   interrupts = <68 2 69 2 70 2>;
-   interrupt-parent = < &mpic >;
+   ptp_clock@24e00 {
fsl,tclk-period = <5>;
fsl,tmr-prsc = <200>;
fsl,tmr-add = <0xCCCD>;
@@ -252,29 +245,18 @@
phy-handle = <&phy1>;
phy-connection-type = "rgmii-id";
};
-
};
 
pci0: pcie@ffe08000 {
+   reg = <0 0xffe08000 0 0x1000>;
status = "disabled";
};
 
pci1: pcie@ffe09000 {
+   reg = <0 0xffe09000 0 0x1000>;
ranges = <0x200 0x0 0xa000 0 0xa000 0x0 0x2000
  0x100 0x0 0x 0 0xffc1 0x0 0x1>;
-   interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
-   interrupt-map = <
-   /* IDSEL 0x0 */
-    0x0 0x0 0x1 &mpic 0x4 0x1
-    0x0 0x0 0x2 &mpic 0x5 0x1
-    0x0 0x0 0x3 &mpic 0x6 0x1
-    0x0 0x0 0x4 &mpic 0x7 0x1
-   >;
-   pcie@0 {
-   reg = <0x0 0x0 0x0 0x0 0x0>;
-   #size-cells = <2>;
-   #address-cells = <3>;
-   device_type = "pci";
+   pcie@0 {
ranges = <0x200 0x0 0xa000
  0x200 0x0 0xa000
  0x0 0x2000
@@ -286,21 +268,10 @@
};
 
pci2: pcie@ffe0a000 {
+   reg = <0 0xffe0a000 0 0x1000>;
ranges = <0x200 0x0 0x8000 0 0x8000 0x0 0x2000
  0x100 0x0 0x 0 0xffc0 0x0 0x1>;
-   interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
-   interrupt-map = <
-   /* I

[RFC][PATCH 16/30] powerpc/85xx: Rework P2020DS device tree

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/fsl/p2020si-post.dtsi |  194 +++
 arch/powerpc/boot/dts/fsl/p2020si-pre.dtsi  |   69 ++
 arch/powerpc/boot/dts/p2020ds.dts   |  353 ++-
 arch/powerpc/boot/dts/p2020ds.dtsi  |  316 
 arch/powerpc/boot/dts/p2020si.dtsi  |   99 +++-
 5 files changed, 634 insertions(+), 397 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/p2020si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/p2020si-pre.dtsi
 create mode 100644 arch/powerpc/boot/dts/p2020ds.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/p2020si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p2020si-post.dtsi
new file mode 100644
index 000..c041050
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/p2020si-post.dtsi
@@ -0,0 +1,194 @@
+/*
+ * P2020/P2010 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+   #address-cells = <2>;
+   #size-cells = <1>;
+   compatible = "fsl,p2020-elbc", "fsl,elbc", "simple-bus";
+   interrupts = <19 2 0 0>;
+};
+
+/* controller at 0xa000 */
+&pci0 {
+   compatible = "fsl,mpc8548-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <26 2 0 0>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <26 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x0 0x1 0x0 0x0
+    0x0 0x0 0x2 &mpic 0x1 0x1 0x0 0x0
+    0x0 0x0 0x3 &mpic 0x2 0x1 0x0 0x0
+    0x0 0x0 0x4 &mpic 0x3 0x1 0x0 0x0
+   >;
+   };
+};
+
+/* controller at 0x9000 */
+&pci1 {
+   compatible = "fsl,mpc8548-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <25 2 0 0>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <25 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x4 0x1 0x0 0x0
+    0x0 0x0 0x2 &mpic 0x5 0x1 0x0 0x0
+    0x0 0x0 0x3 &mpic 0x6 0x1 0x0 0x0
+    0x0 0x0 0x4 &mpic 0x7 0x1 0x0 0x0
+   >;
+   };
+};
+
+/* controller at 0x8000 */
+&pci2 {
+   compatible = "fsl,mpc8548-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = 

[RFC][PATCH 15/30] powerpc/85xx: Rework P1022DS device tree

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/fsl/p1022si-post.dtsi |  235 +++
 arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi  |   68 +
 arch/powerpc/boot/dts/p1022ds.dts   |  431 +--
 3 files changed, 318 insertions(+), 416 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
new file mode 100644
index 000..16239b1
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
@@ -0,0 +1,235 @@
+/*
+ * P1022/P1013 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+   #address-cells = <2>;
+   #size-cells = <1>;
+   compatible = "fsl,p1022-elbc", "fsl,elbc", "simple-bus";
+   interrupts = <19 2 0 0>;
+};
+
+/* controller at 0x9000 */
+&pci0 {
+   compatible = "fsl,p1022-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <16 2 0 0>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x4 0x1 0x0 0x0
+    0x0 0x0 0x2 &mpic 0x5 0x1 0x0 0x0
+    0x0 0x0 0x3 &mpic 0x6 0x1 0x0 0x0
+    0x0 0x0 0x4 &mpic 0x7 0x1 0x0 0x0
+   >;
+   };
+};
+
+/* controller at 0xa000 */
+&pci1 {
+   compatible = "fsl,p1022-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <16 2 0 0>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x0 0x1 0x0 0x0
+    0x0 0x0 0x2 &mpic 0x1 0x1 0x0 0x0
+    0x0 0x0 0x3 &mpic 0x2 0x1 0x0 0x0
+    0x0 0x0 0x4 &mpic 0x3 0x1 0x0 0x0
+   >;
+   };
+};
+
+/* controller at 0xb000 */
+&pci2 {
+   compatible = "fsl,p1022-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <16 2 0 0>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-c

[RFC][PATCH 14/30] powerpc/85xx: Add a P1010RDB 36-bit address map device tree

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/p1010rdb_36b.dts |   89 
 1 files changed, 89 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/p1010rdb_36b.dts

diff --git a/arch/powerpc/boot/dts/p1010rdb_36b.dts 
b/arch/powerpc/boot/dts/p1010rdb_36b.dts
new file mode 100644
index 000..64776f4
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1010rdb_36b.dts
@@ -0,0 +1,89 @@
+/*
+ * P1010 RDB Device Tree Source (36-bit address map)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p1010si-pre.dtsi"
+
+/ {
+   model = "fsl,P1010RDB";
+   compatible = "fsl,P1010RDB";
+
+   memory {
+   device_type = "memory";
+   };
+
+   board_ifc: ifc: ifc@fffe1e000 {
+   /* NOR, NAND Flashes and CPLD on board */
+   ranges = <0x0 0x0 0xf 0xee00 0x0200
+ 0x1 0x0 0xf 0xff80 0x0001
+ 0x3 0x0 0xf 0xffb0 0x0020>;
+   reg = <0xf 0xffe1e000 0 0x2000>;
+   };
+
+   board_soc: soc: soc@fffe0 {
+   ranges = <0x0 0xf 0xffe0 0x10>;
+   };
+
+   pci0: pcie@fffe09000 {
+   reg = <0xf 0xffe09000 0 0x1000>;
+   ranges = <0x200 0x0 0xc000 0xc 0x2000 0x0 0x2000
+ 0x100 0x0 0x 0xf 0xffc1 0x0 0x1>;
+   pcie@0 {
+   ranges = <0x200 0x0 0xc000
+ 0x200 0x0 0xc000
+ 0x0 0x2000
+
+ 0x100 0x0 0x0
+ 0x100 0x0 0x0
+ 0x0 0x10>;
+   };
+   };
+
+   pci1: pcie@fffe0a000 {
+   reg = <0xf 0xffe0a000 0 0x1000>;
+   ranges = <0x200 0x0 0xc000 0xc 0x2000 0x0 0x2000
+ 0x100 0x0 0x 0xf 0xffc1 0x0 0x1>;
+   pcie@0 {
+   ranges = <0x200 0x0 0xc000
+ 0x200 0x0 0xc000
+ 0x0 0x2000
+
+ 0x100 0x0 0x0
+ 0x100 0x0 0x0
+ 0x0 0x10>;
+   };
+   };
+};
+
+/include/ "p1010rdb.dtsi"
+/include/ "fsl/p1010si-post.dtsi"
-- 
1.7.3.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[RFC][PATCH 13/30] powerpc/85xx: Add crypto engine to P1010 SoC device tree

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/fsl/p1010si-post.dtsi |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
index 75eb921..bd9e163 100644
--- a/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
@@ -161,6 +161,7 @@
fsl,sdhci-auto-cmd12;
};
 
+/include/ "pq3-sec4.4-0.dtsi"
 /include/ "pq3-mpic.dtsi"
 /include/ "pq3-mpic-timer-B.dtsi"
 
-- 
1.7.3.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[RFC][PATCH 12/30] powerpc/85xx: Add RTC to P1010RDB device tree

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/p1010rdb.dtsi |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/p1010rdb.dtsi 
b/arch/powerpc/boot/dts/p1010rdb.dtsi
index 149d196..3aa2b82 100644
--- a/arch/powerpc/boot/dts/p1010rdb.dtsi
+++ b/arch/powerpc/boot/dts/p1010rdb.dtsi
@@ -125,6 +125,13 @@
 };
 
 &board_soc {
+   i2c@3000 {
+   rtc@68 {
+   compatible = "pericom,pt7c4338";
+   reg = <0x68>;
+   };
+   };
+
spi@7000 {
flash@0 {
#address-cells = <1>;
-- 
1.7.3.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[RFC][PATCH 11/30] powerpc/85xx: Rework P1010RDB and P1010 device tree

2011-11-10 Thread Kumar Gala
Utilize new split between board & SoC, and new SoC device trees split
into pre & post utilizing 'template' includes for SoC IP blocks.

Moved to 4 cell interrupt nodes to deal with FSL timer and moved
interrupt-parent to root so we don't duplicate it per IP block.

During rework fixed:
* PCI interrupt map - wrong IRQs for PCI-0 controller
* SDHC interrupt sense was wrong

Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/fsl/p1010si-post.dtsi |  197 ++
 arch/powerpc/boot/dts/fsl/p1010si-pre.dtsi  |   64 +
 arch/powerpc/boot/dts/p1010rdb.dts  |  228 +
 arch/powerpc/boot/dts/p1010rdb.dtsi |  222 
 arch/powerpc/boot/dts/p1010si.dtsi  |  374 ---
 5 files changed, 493 insertions(+), 592 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/p1010si-pre.dtsi
 create mode 100644 arch/powerpc/boot/dts/p1010rdb.dtsi
 delete mode 100644 arch/powerpc/boot/dts/p1010si.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
new file mode 100644
index 000..75eb921
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
@@ -0,0 +1,197 @@
+/*
+ * P1010/P1014 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&ifc {
+   #address-cells = <2>;
+   #size-cells = <1>;
+   compatible = "fsl,ifc", "simple-bus";
+   interrupts = <16 2 0 0 19 2 0 0>;
+};
+
+/* controller at 0x9000 */
+&pci0 {
+   compatible = "fsl,p1010-pcie", "fsl,qoriq-pcie-v2.3", 
"fsl,qoriq-pcie-v2.2";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <16 2 0 0>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x4 0x1 0x0 0x0
+    0x0 0x0 0x2 &mpic 0x5 0x1 0x0 0x0
+    0x0 0x0 0x3 &mpic 0x6 0x1 0x0 0x0
+    0x0 0x0 0x4 &mpic 0x7 0x1 0x0 0x0
+   >;
+   };
+};
+
+/* controller at 0xa000 */
+&pci1 {
+   compatible = "fsl,p1010-pcie", "fsl,qoriq-pcie-v2.3", 
"fsl,qoriq-pcie-v2.2";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <16 2 0 0>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+
+   interrupt-map = <
+   /* IDSEL 0x0 */
+

[RFC][PATCH 10/30] powerpc/85xx: Add P1020RDB 36-bit address map device tree

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/p1020rdb_36b.dts |   66 
 1 files changed, 66 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/p1020rdb_36b.dts

diff --git a/arch/powerpc/boot/dts/p1020rdb_36b.dts 
b/arch/powerpc/boot/dts/p1020rdb_36b.dts
new file mode 100644
index 000..bdbdb60
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1020rdb_36b.dts
@@ -0,0 +1,66 @@
+/*
+ * P1020 RDB Device Tree Source (36-bit address map)
+ *
+ * Copyright 2009-2011 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+/include/ "fsl/p1020si-pre.dtsi"
+/ {
+   model = "fsl,P1020RDB";
+   compatible = "fsl,P1020RDB";
+
+   memory {
+   device_type = "memory";
+   };
+
+   board_lbc: lbc: localbus@fffe05000 {
+   reg = <0xf 0xffe05000 0 0x1000>;
+
+   /* NOR, NAND Flashes and Vitesse 5 port L2 switch */
+   ranges = <0x0 0x0 0xf 0xef00 0x0100
+ 0x1 0x0 0xf 0xffa0 0x0004
+ 0x2 0x0 0xf 0xffb0 0x0002>;
+   };
+
+   board_soc: soc: soc@fffe0 {
+   ranges = <0x0 0xf 0xffe0 0x10>;
+   };
+
+   pci0: pcie@fffe09000 {
+   reg = <0xf 0xffe09000 0 0x1000>;
+   ranges = <0x200 0x0 0xc000 0xc 0x2000 0x0 0x2000
+ 0x100 0x0 0x 0xf 0xffc1 0x0 0x1>;
+   pcie@0 {
+   ranges = <0x200 0x0 0xc000
+ 0x200 0x0 0xc000
+ 0x0 0x2000
+
+ 0x100 0x0 0x0
+ 0x100 0x0 0x0
+ 0x0 0x10>;
+   };
+   };
+
+   pci1: pcie@fffe0a000 {
+   reg = <0xf 0xffe0a000 0 0x1000>;
+   ranges = <0x200 0x0 0x8000 0xc 0x 0x0 0x2000
+ 0x100 0x0 0x 0xf 0xffc0 0x0 0x1>;
+   pcie@0 {
+   ranges = <0x200 0x0 0x8000
+ 0x200 0x0 0x8000
+ 0x0 0x2000
+
+ 0x100 0x0 0x0
+ 0x100 0x0 0x0
+ 0x0 0x10>;
+   };
+   };
+};
+
+/include/ "p1020rdb.dtsi"
+/include/ "fsl/p1020si-post.dtsi"
-- 
1.7.3.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[RFC][PATCH 09/30] powerpc/85xx: Rework P1020RDB device tree

2011-11-10 Thread Kumar Gala
We split out the common bits of the P1020RDB device tree such that we
can reuse those bits between a 32-bit or 36-bit address map device tree.

We also update the P1020RDB device tree to utilize the new p1020 SoC dts
includes (fsl/p1020si-pre.dtsi & fsl/p1020si-post.dtsi).

Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/p1020rdb.dts  |  232 +
 arch/powerpc/boot/dts/p1020rdb.dtsi |  242 +++
 2 files changed, 250 insertions(+), 224 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/p1020rdb.dtsi

diff --git a/arch/powerpc/boot/dts/p1020rdb.dts 
b/arch/powerpc/boot/dts/p1020rdb.dts
index b31e7ec..518bf99 100644
--- a/arch/powerpc/boot/dts/p1020rdb.dts
+++ b/arch/powerpc/boot/dts/p1020rdb.dts
@@ -9,245 +9,26 @@
  * option) any later version.
  */
 
-/include/ "p1020si.dtsi"
-
+/include/ "fsl/p1020si-pre.dtsi"
 / {
model = "fsl,P1020RDB";
compatible = "fsl,P1020RDB";
 
-   aliases {
-   serial0 = &serial0;
-   serial1 = &serial1;
-   ethernet0 = &enet0;
-   ethernet1 = &enet1;
-   ethernet2 = &enet2;
-   pci0 = &pci0;
-   pci1 = &pci1;
-   };
-
memory {
device_type = "memory";
};
 
-   localbus@ffe05000 {
+   board_lbc: lbc: localbus@ffe05000 {
+   reg = <0 0xffe05000 0 0x1000>;
 
/* NOR, NAND Flashes and Vitesse 5 port L2 switch */
ranges = <0x0 0x0 0x0 0xef00 0x0100
  0x1 0x0 0x0 0xffa0 0x0004
  0x2 0x0 0x0 0xffb0 0x0002>;
-
-   nor@0,0 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "cfi-flash";
-   reg = <0x0 0x0 0x100>;
-   bank-width = <2>;
-   device-width = <1>;
-
-   partition@0 {
-   /* This location must not be altered  */
-   /* 256KB for Vitesse 7385 Switch firmware */
-   reg = <0x0 0x0004>;
-   label = "NOR (RO) Vitesse-7385 Firmware";
-   read-only;
-   };
-
-   partition@4 {
-   /* 256KB for DTB Image */
-   reg = <0x0004 0x0004>;
-   label = "NOR (RO) DTB Image";
-   read-only;
-   };
-
-   partition@8 {
-   /* 3.5 MB for Linux Kernel Image */
-   reg = <0x0008 0x0038>;
-   label = "NOR (RO) Linux Kernel Image";
-   read-only;
-   };
-
-   partition@40 {
-   /* 11MB for JFFS2 based Root file System */
-   reg = <0x0040 0x00b0>;
-   label = "NOR (RW) JFFS2 Root File System";
-   };
-
-   partition@f0 {
-   /* This location must not be altered  */
-   /* 512KB for u-boot Bootloader Image */
-   /* 512KB for u-boot Environment Variables */
-   reg = <0x00f0 0x0010>;
-   label = "NOR (RO) U-Boot Image";
-   read-only;
-   };
-   };
-
-   nand@1,0 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "fsl,p1020-fcm-nand",
-"fsl,elbc-fcm-nand";
-   reg = <0x1 0x0 0x4>;
-
-   partition@0 {
-   /* This location must not be altered  */
-   /* 1MB for u-boot Bootloader Image */
-   reg = <0x0 0x0010>;
-   label = "NAND (RO) U-Boot Image";
-   read-only;
-   };
-
-   partition@10 {
-   /* 1MB for DTB Image */
-   reg = <0x0010 0x0010>;
-   label = "NAND (RO) DTB Image";
-   read-only;
-   };
-
-   partition@20 {
-   /* 4MB for Linux Kernel Image */
-   reg = <0x0020 0x0040>;
-   label = "NAND (RO) Linux Kernel Image";
-   read-onl

[RFC][PATCH 08/30] powerpc/85xx: Rework P1020 SoC device tree

2011-11-10 Thread Kumar Gala
Split the P1020 SoC device tree into what we can include as a 'prefix'
to the board device tree and what needs to be included as a 'postfix'.

This allows use more re-use and less duplication between various board
device tree configurations (32-bit address map vs 36-bit address map).

Also enable 2nd USB2 in the SoC device tree, let the board code disable
it if needed.

Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/fsl/p1020si-post.dtsi |  174 
 arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi  |   68 +
 arch/powerpc/boot/dts/p1020si.dtsi  |  407 ---
 3 files changed, 242 insertions(+), 407 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi
 delete mode 100644 arch/powerpc/boot/dts/p1020si.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
new file mode 100644
index 000..fc924c5
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
@@ -0,0 +1,174 @@
+/*
+ * P1020/P1011 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+   #address-cells = <2>;
+   #size-cells = <1>;
+   compatible = "fsl,p1020-elbc", "fsl,elbc", "simple-bus";
+   interrupts = <19 2 0 0>;
+};
+
+/* controller at 0x9000 */
+&pci0 {
+   compatible = "fsl,mpc8548-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <16 2 0 0>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x4 0x1 0x0 0x0
+    0x0 0x0 0x2 &mpic 0x5 0x1 0x0 0x0
+    0x0 0x0 0x3 &mpic 0x6 0x1 0x0 0x0
+    0x0 0x0 0x4 &mpic 0x7 0x1 0x0 0x0
+   >;
+   };
+};
+
+/* controller at 0xa000 */
+&pci1 {
+   compatible = "fsl,mpc8548-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <16 2 0 0>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x0 0x1 0x0 0x0
+    0x0 0x0 0x2 &mpic 0x1 0x1 0x0 0x0
+    0x0 0x0 0x3 &mpic 0x2 0x1 0x0 0x0
+    0x0 0x0 0x4 &mpic 0x3 0x1 0x0 0x0
+   >;
+

[RFC][PATCH 06/30] powerpc/85xx: p1020si.dtsi update interrupt handling

2011-11-10 Thread Kumar Gala
* set interrupt-parent at root so its not duplicate in every node
* Add mpic timers
* Move to 4-prop cells for mpic timer

Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/p1020si.dtsi |  117 +---
 1 files changed, 56 insertions(+), 61 deletions(-)

diff --git a/arch/powerpc/boot/dts/p1020si.dtsi 
b/arch/powerpc/boot/dts/p1020si.dtsi
index 14dff69..b08c848 100644
--- a/arch/powerpc/boot/dts/p1020si.dtsi
+++ b/arch/powerpc/boot/dts/p1020si.dtsi
@@ -14,6 +14,7 @@
compatible = "fsl,P1020";
#address-cells = <2>;
#size-cells = <2>;
+   interrupt-parent = <&mpic>;
 
cpus {
#address-cells = <1>;
@@ -37,8 +38,7 @@
#size-cells = <1>;
compatible = "fsl,p1020-elbc", "fsl,elbc", "simple-bus";
reg = <0 0xffe05000 0 0x1000>;
-   interrupts = <19 2>;
-   interrupt-parent = <&mpic>;
+   interrupts = <19 2 0 0>;
};
 
soc@ffe0 {
@@ -58,15 +58,13 @@
ecm@1000 {
compatible = "fsl,p1020-ecm", "fsl,ecm";
reg = <0x1000 0x1000>;
-   interrupts = <16 2>;
-   interrupt-parent = <&mpic>;
+   interrupts = <16 2 0 0>;
};
 
memory-controller@2000 {
compatible = "fsl,p1020-memory-controller";
reg = <0x2000 0x1000>;
-   interrupt-parent = <&mpic>;
-   interrupts = <16 2>;
+   interrupts = <16 2 0 0>;
};
 
i2c@3000 {
@@ -75,8 +73,7 @@
cell-index = <0>;
compatible = "fsl-i2c";
reg = <0x3000 0x100>;
-   interrupts = <43 2>;
-   interrupt-parent = <&mpic>;
+   interrupts = <43 2 0 0>;
dfsrr;
};
 
@@ -86,8 +83,7 @@
cell-index = <1>;
compatible = "fsl-i2c";
reg = <0x3100 0x100>;
-   interrupts = <43 2>;
-   interrupt-parent = <&mpic>;
+   interrupts = <43 2 0 0>;
dfsrr;
};
 
@@ -97,8 +93,7 @@
compatible = "ns16550";
reg = <0x4500 0x100>;
clock-frequency = <0>;
-   interrupts = <42 2>;
-   interrupt-parent = <&mpic>;
+   interrupts = <42 2 0 0>;
};
 
serial1: serial@4600 {
@@ -107,8 +102,7 @@
compatible = "ns16550";
reg = <0x4600 0x100>;
clock-frequency = <0>;
-   interrupts = <42 2>;
-   interrupt-parent = <&mpic>;
+   interrupts = <42 2 0 0>;
};
 
spi@7000 {
@@ -116,8 +110,7 @@
#size-cells = <0>;
compatible = "fsl,p1020-espi", "fsl,mpc8536-espi";
reg = <0x7000 0x1000>;
-   interrupts = <59 0x2>;
-   interrupt-parent = <&mpic>;
+   interrupts = <59 0x2 0 0>;
fsl,espi-num-chipselects = <4>;
};
 
@@ -125,8 +118,7 @@
#gpio-cells = <2>;
compatible = "fsl,mpc8572-gpio";
reg = <0xf000 0x100>;
-   interrupts = <47 0x2>;
-   interrupt-parent = <&mpic>;
+   interrupts = <47 0x2 0 0>;
gpio-controller;
};
 
@@ -135,8 +127,7 @@
reg = <0x2 0x1000>;
cache-line-size = <32>; // 32 bytes
cache-size = <0x4>; // L2,256K
-   interrupt-parent = <&mpic>;
-   interrupts = <16 2>;
+   interrupts = <16 2 0 0>;
};
 
dma@21300 {
@@ -150,29 +141,25 @@
compatible = "fsl,eloplus-dma-channel";
reg = <0x0 0x80>;
cell-index = <0>;
-   interrupt-parent = <&mpic>;
-   interrupts = <20 2>;
+   interrupts = <20 2 0 0>;
};
dma-channel@80 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x80 0x80>;
cell-index = <1>;
-   interrupt-parent = <&mpic>;
-   interrupts = <

[RFC][PATCH 05/30] powerpc/85xx: Add ethernet magic packet property to P1020 device tree

2011-11-10 Thread Kumar Gala
All eTSEC2 controllers support waking on magic packet so fixup device
tree to report that.

Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/p1020si.dtsi |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/p1020si.dtsi 
b/arch/powerpc/boot/dts/p1020si.dtsi
index 5514e1d..14dff69 100644
--- a/arch/powerpc/boot/dts/p1020si.dtsi
+++ b/arch/powerpc/boot/dts/p1020si.dtsi
@@ -200,6 +200,7 @@
compatible = "fsl,etsec2";
fsl,num_rx_queues = <0x8>;
fsl,num_tx_queues = <0x8>;
+   fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupt-parent = <&mpic>;
 
@@ -226,6 +227,7 @@
compatible = "fsl,etsec2";
fsl,num_rx_queues = <0x8>;
fsl,num_tx_queues = <0x8>;
+   fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupt-parent = <&mpic>;
 
@@ -252,6 +254,7 @@
compatible = "fsl,etsec2";
fsl,num_rx_queues = <0x8>;
fsl,num_tx_queues = <0x8>;
+   fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupt-parent = <&mpic>;
 
-- 
1.7.3.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[RFC][PATCH 04/30] powerpc/85xx: Update P1020 SEC3.3 node to match actual SoC HW

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/p1020si.dtsi |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/boot/dts/p1020si.dtsi 
b/arch/powerpc/boot/dts/p1020si.dtsi
index 25e10cf..5514e1d 100644
--- a/arch/powerpc/boot/dts/p1020si.dtsi
+++ b/arch/powerpc/boot/dts/p1020si.dtsi
@@ -305,15 +305,16 @@
};
 
crypto@3 {
-   compatible = "fsl,sec3.1", "fsl,sec3.0", "fsl,sec2.4",
-"fsl,sec2.2", "fsl,sec2.1", "fsl,sec2.0";
+   compatible = "fsl,sec3.3", "fsl,sec3.1", "fsl,sec3.0",
+"fsl,sec2.4", "fsl,sec2.2", "fsl,sec2.1",
+"fsl,sec2.0";
reg = <0x3 0x1>;
interrupts = <45 2 58 2>;
interrupt-parent = <&mpic>;
fsl,num-channels = <4>;
fsl,channel-fifo-len = <24>;
-   fsl,exec-units-mask = <0xbfe>;
-   fsl,descriptor-types-mask = <0x3ab0ebf>;
+   fsl,exec-units-mask = <0x97c>;
+   fsl,descriptor-types-mask = <0x3a30abf>;
};
 
mpic: pic@4 {
-- 
1.7.3.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[RFC][PATCH 03/30] powerpc/85xx: Update SPI binding to match binding spec for P1020RDB

2011-11-10 Thread Kumar Gala
The SPI node is out of date with regards to the binding for fsl-espi and
driver support.

Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/p1020rdb.dts |   30 +-
 arch/powerpc/boot/dts/p1020si.dtsi |5 ++---
 2 files changed, 15 insertions(+), 20 deletions(-)

diff --git a/arch/powerpc/boot/dts/p1020rdb.dts 
b/arch/powerpc/boot/dts/p1020rdb.dts
index 8b1a7ee..b31e7ec 100644
--- a/arch/powerpc/boot/dts/p1020rdb.dts
+++ b/arch/powerpc/boot/dts/p1020rdb.dts
@@ -149,49 +149,45 @@
};
 
spi@7000 {
-
-   fsl_m25p80@0 {
+   flash@0 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "fsl,espi-flash";
+   compatible = "spansion,s25sl12801";
reg = <0>;
-   linux,modalias = "fsl_m25p80";
-   modal = "s25sl128b";
-   spi-max-frequency = <5000>;
-   mode = <0>;
+   spi-max-frequency = <4000>; /* input clock 
*/
 
-   partition@0 {
+   partition@u-boot {
/* 512KB for u-boot Bootloader Image */
reg = <0x0 0x0008>;
-   label = "SPI (RO) U-Boot Image";
+   label = "u-boot";
read-only;
};
 
-   partition@8 {
+   partition@dtb {
/* 512KB for DTB Image */
reg = <0x0008 0x0008>;
-   label = "SPI (RO) DTB Image";
+   label = "dtb";
read-only;
};
 
-   partition@10 {
+   partition@kernel {
/* 4MB for Linux Kernel Image */
reg = <0x0010 0x0040>;
-   label = "SPI (RO) Linux Kernel Image";
+   label = "kernel";
read-only;
};
 
-   partition@50 {
+   partition@fs {
/* 4MB for Compressed RFS Image */
reg = <0x0050 0x0040>;
-   label = "SPI (RO) Compressed RFS Image";
+   label = "file system";
read-only;
};
 
-   partition@90 {
+   partition@jffs-fs {
/* 7MB for JFFS2 based RFS */
reg = <0x0090 0x0070>;
-   label = "SPI (RW) JFFS2 RFS";
+   label = "file system jffs2";
};
};
};
diff --git a/arch/powerpc/boot/dts/p1020si.dtsi 
b/arch/powerpc/boot/dts/p1020si.dtsi
index 58f6b30..25e10cf 100644
--- a/arch/powerpc/boot/dts/p1020si.dtsi
+++ b/arch/powerpc/boot/dts/p1020si.dtsi
@@ -112,14 +112,13 @@
};
 
spi@7000 {
-   cell-index = <0>;
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "fsl,espi";
+   compatible = "fsl,p1020-espi", "fsl,mpc8536-espi";
reg = <0x7000 0x1000>;
interrupts = <59 0x2>;
interrupt-parent = <&mpic>;
-   mode = "cpu";
+   fsl,espi-num-chipselects = <4>;
};
 
gpio: gpio-controller@f000 {
-- 
1.7.3.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[RFC][PATCH 02/30] powerpc/85xx: Rework PCI nodes on P1020RDB

2011-11-10 Thread Kumar Gala
* Move SoC specific details like irq mapping to SoC dtsi
* Update interrupt property to cover both error interrupt and PCIe
  runtime interrupts

Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/p1020rdb.dts |   26 +-
 arch/powerpc/boot/dts/p1020si.dtsi |   40 ---
 2 files changed, 38 insertions(+), 28 deletions(-)

diff --git a/arch/powerpc/boot/dts/p1020rdb.dts 
b/arch/powerpc/boot/dts/p1020rdb.dts
index d6a8ae4..8b1a7ee 100644
--- a/arch/powerpc/boot/dts/p1020rdb.dts
+++ b/arch/powerpc/boot/dts/p1020rdb.dts
@@ -257,19 +257,8 @@
pci0: pcie@ffe09000 {
ranges = <0x200 0x0 0xa000 0 0xa000 0x0 0x2000
  0x100 0x0 0x 0 0xffc1 0x0 0x1>;
-   interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
-   interrupt-map = <
-   /* IDSEL 0x0 */
-    0x0 0x0 0x1 &mpic 0x4 0x1
-    0x0 0x0 0x2 &mpic 0x5 0x1
-    0x0 0x0 0x3 &mpic 0x6 0x1
-    0x0 0x0 0x4 &mpic 0x7 0x1
-   >;
+   reg = <0 0xffe09000 0 0x1000>;
pcie@0 {
-   reg = <0x0 0x0 0x0 0x0 0x0>;
-   #size-cells = <2>;
-   #address-cells = <3>;
-   device_type = "pci";
ranges = <0x200 0x0 0xa000
  0x200 0x0 0xa000
  0x0 0x2000
@@ -281,21 +270,10 @@
};
 
pci1: pcie@ffe0a000 {
+   reg = <0 0xffe0a000 0 0x1000>;
ranges = <0x200 0x0 0x8000 0 0x8000 0x0 0x2000
  0x100 0x0 0x 0 0xffc0 0x0 0x1>;
-   interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
-   interrupt-map = <
-   /* IDSEL 0x0 */
-    0x0 0x0 0x1 &mpic 0x0 0x1
-    0x0 0x0 0x2 &mpic 0x1 0x1
-    0x0 0x0 0x3 &mpic 0x2 0x1
-    0x0 0x0 0x4 &mpic 0x3 0x1
-   >;
pcie@0 {
-   reg = <0x0 0x0 0x0 0x0 0x0>;
-   #size-cells = <2>;
-   #address-cells = <3>;
-   device_type = "pci";
ranges = <0x200 0x0 0x8000
  0x200 0x0 0x8000
  0x0 0x2000
diff --git a/arch/powerpc/boot/dts/p1020si.dtsi 
b/arch/powerpc/boot/dts/p1020si.dtsi
index 5c5acb6..58f6b30 100644
--- a/arch/powerpc/boot/dts/p1020si.dtsi
+++ b/arch/powerpc/boot/dts/p1020si.dtsi
@@ -352,26 +352,58 @@
pci0: pcie@ffe09000 {
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
-   #interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
-   reg = <0 0xffe09000 0 0x1000>;
bus-range = <0 255>;
clock-frequency = <>;
interrupt-parent = <&mpic>;
interrupts = <16 2>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x4 0x1
+    0x0 0x0 0x2 &mpic 0x5 0x1
+    0x0 0x0 0x3 &mpic 0x6 0x1
+    0x0 0x0 0x4 &mpic 0x7 0x1
+   >;
+   };
+
};
 
pci1: pcie@ffe0a000 {
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
-   #interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
-   reg = <0 0xffe0a000 0 0x1000>;
bus-range = <0 255>;
clock-frequency = <>;
interrupt-parent = <&mpic>;
interrupts = <16 2>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x0 0x1
+ 

[RFC][PATCH 01/30] powerpc/85xx: Simplify P1020RDB CAMP dts using includes

2011-11-10 Thread Kumar Gala
If we include the p1020rdb.dts instead of p1020si.dts we greatly reduce
duplication and maintenance.  We can just list which devices are
disabled for the given core and mpic protected sources.

Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/p1020rdb_camp_core0.dts |  154 +
 arch/powerpc/boot/dts/p1020rdb_camp_core1.dts |   11 +--
 2 files changed, 4 insertions(+), 161 deletions(-)

diff --git a/arch/powerpc/boot/dts/p1020rdb_camp_core0.dts 
b/arch/powerpc/boot/dts/p1020rdb_camp_core0.dts
index f0bf7f4..41b4585 100644
--- a/arch/powerpc/boot/dts/p1020rdb_camp_core0.dts
+++ b/arch/powerpc/boot/dts/p1020rdb_camp_core0.dts
@@ -16,7 +16,7 @@
  * option) any later version.
  */
 
-/include/ "p1020si.dtsi"
+/include/ "p1020rdb.dts"
 
 / {
model = "fsl,P1020RDB";
@@ -32,7 +32,7 @@
 
cpus {
PowerPC,P1020@1 {
-   status = "disabled";
+   status = "disabled";
};
};
 
@@ -45,169 +45,19 @@
};
 
soc@ffe0 {
-   i2c@3000 {
-   rtc@68 {
-   compatible = "dallas,ds1339";
-   reg = <0x68>;
-   };
-   };
-
serial1: serial@4600 {
status = "disabled";
};
 
-   spi@7000 {
-   fsl_m25p80@0 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "fsl,espi-flash";
-   reg = <0>;
-   linux,modalias = "fsl_m25p80";
-   spi-max-frequency = <4000>;
-
-   partition@0 {
-   /* 512KB for u-boot Bootloader Image */
-   reg = <0x0 0x0008>;
-   label = "SPI (RO) U-Boot Image";
-   read-only;
-   };
-
-   partition@8 {
-   /* 512KB for DTB Image */
-   reg = <0x0008 0x0008>;
-   label = "SPI (RO) DTB Image";
-   read-only;
-   };
-
-   partition@10 {
-   /* 4MB for Linux Kernel Image */
-   reg = <0x0010 0x0040>;
-   label = "SPI (RO) Linux Kernel Image";
-   read-only;
-   };
-
-   partition@50 {
-   /* 4MB for Compressed RFS Image */
-   reg = <0x0050 0x0040>;
-   label = "SPI (RO) Compressed RFS Image";
-   read-only;
-   };
-
-   partition@90 {
-   /* 7MB for JFFS2 based RFS */
-   reg = <0x0090 0x0070>;
-   label = "SPI (RW) JFFS2 RFS";
-   };
-   };
-   };
-
-   mdio@24000 {
-   phy0: ethernet-phy@0 {
-   interrupt-parent = <&mpic>;
-   interrupts = <3 1>;
-   reg = <0x0>;
-   };
-   phy1: ethernet-phy@1 {
-   interrupt-parent = <&mpic>;
-   interrupts = <2 1>;
-   reg = <0x1>;
-   };
-   };
-
-   mdio@25000 {
-   tbi0: tbi-phy@11 {
-   reg = <0x11>;
-   device_type = "tbi-phy";
-   };
-   };
-
enet0: ethernet@b {
status = "disabled";
};
 
-   enet1: ethernet@b1000 {
-   phy-handle = <&phy0>;
-   tbi-handle = <&tbi0>;
-   phy-connection-type = "sgmii";
-   };
-
-   enet2: ethernet@b2000 {
-   phy-handle = <&phy1>;
-   phy-connection-type = "rgmii-id";
-   };
-
-   usb@22000 {
-   phy_type = "ulpi";
-   };
-
-   /* USB2 is shared with localbus, so it must be disabled
-  by default. We can't put 'status = "disabled";' here
-   

[RFC][PATCH 00/30] Rework FSL MPC85xx/Pxxxx device trees

2011-11-10 Thread Kumar Gala
Posting this to get any feedback and review while I cleanup commit messages
and the such.

The general idea is to split out the SoC and IP blocks into their own files
that can be included to build up a board level device tree.  This allows us
to reduce overall duplication and forward looking maintenance when updating
device nodes.

I've dropped numerous cases of compatiables that are of form "CHIP-IPname-.."
so as to use the basic IP dts includes as much as possible.  In general this
is areas that drivers have not typically utilized.

I've moved all the changed .dts to a 4-cell MPIC IRQ and made other cleanups
that I'll comment on in the commit mesages.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 10/11] powerpc/85xx: Rework P1020RDB device tree

2011-11-10 Thread Kumar Gala
We split out the common bits of the P1020RDB device tree such that we
can reuse those bits between a 32-bit or 36-bit address map device tree.

We also update the P1020RDB device tree to utilize the new p1020 SoC dts
includes (fsl/p1020si-pre.dtsi & fsl/p1020si-post.dtsi).

Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/p1020rdb.dts  |  232 ++-
 arch/powerpc/boot/dts/p1020rdb.dtsi |  208 +++
 2 files changed, 216 insertions(+), 224 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/p1020rdb.dtsi

diff --git a/arch/powerpc/boot/dts/p1020rdb.dts 
b/arch/powerpc/boot/dts/p1020rdb.dts
index b31e7ec..518bf99 100644
--- a/arch/powerpc/boot/dts/p1020rdb.dts
+++ b/arch/powerpc/boot/dts/p1020rdb.dts
@@ -9,245 +9,26 @@
  * option) any later version.
  */
 
-/include/ "p1020si.dtsi"
-
+/include/ "fsl/p1020si-pre.dtsi"
 / {
model = "fsl,P1020RDB";
compatible = "fsl,P1020RDB";
 
-   aliases {
-   serial0 = &serial0;
-   serial1 = &serial1;
-   ethernet0 = &enet0;
-   ethernet1 = &enet1;
-   ethernet2 = &enet2;
-   pci0 = &pci0;
-   pci1 = &pci1;
-   };
-
memory {
device_type = "memory";
};
 
-   localbus@ffe05000 {
+   board_lbc: lbc: localbus@ffe05000 {
+   reg = <0 0xffe05000 0 0x1000>;
 
/* NOR, NAND Flashes and Vitesse 5 port L2 switch */
ranges = <0x0 0x0 0x0 0xef00 0x0100
  0x1 0x0 0x0 0xffa0 0x0004
  0x2 0x0 0x0 0xffb0 0x0002>;
-
-   nor@0,0 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "cfi-flash";
-   reg = <0x0 0x0 0x100>;
-   bank-width = <2>;
-   device-width = <1>;
-
-   partition@0 {
-   /* This location must not be altered  */
-   /* 256KB for Vitesse 7385 Switch firmware */
-   reg = <0x0 0x0004>;
-   label = "NOR (RO) Vitesse-7385 Firmware";
-   read-only;
-   };
-
-   partition@4 {
-   /* 256KB for DTB Image */
-   reg = <0x0004 0x0004>;
-   label = "NOR (RO) DTB Image";
-   read-only;
-   };
-
-   partition@8 {
-   /* 3.5 MB for Linux Kernel Image */
-   reg = <0x0008 0x0038>;
-   label = "NOR (RO) Linux Kernel Image";
-   read-only;
-   };
-
-   partition@40 {
-   /* 11MB for JFFS2 based Root file System */
-   reg = <0x0040 0x00b0>;
-   label = "NOR (RW) JFFS2 Root File System";
-   };
-
-   partition@f0 {
-   /* This location must not be altered  */
-   /* 512KB for u-boot Bootloader Image */
-   /* 512KB for u-boot Environment Variables */
-   reg = <0x00f0 0x0010>;
-   label = "NOR (RO) U-Boot Image";
-   read-only;
-   };
-   };
-
-   nand@1,0 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "fsl,p1020-fcm-nand",
-"fsl,elbc-fcm-nand";
-   reg = <0x1 0x0 0x4>;
-
-   partition@0 {
-   /* This location must not be altered  */
-   /* 1MB for u-boot Bootloader Image */
-   reg = <0x0 0x0010>;
-   label = "NAND (RO) U-Boot Image";
-   read-only;
-   };
-
-   partition@10 {
-   /* 1MB for DTB Image */
-   reg = <0x0010 0x0010>;
-   label = "NAND (RO) DTB Image";
-   read-only;
-   };
-
-   partition@20 {
-   /* 4MB for Linux Kernel Image */
-   reg = <0x0020 0x0040>;
-   label = "NAND (RO) Linux Kernel Image";
-   read-only;

[PATCH 11/11] powerpc/85xx: Add P1020RDB 36-bit address map device tree

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/p1020rdb_36b.dts |   66 
 1 files changed, 66 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/p1020rdb_36b.dts

diff --git a/arch/powerpc/boot/dts/p1020rdb_36b.dts 
b/arch/powerpc/boot/dts/p1020rdb_36b.dts
new file mode 100644
index 000..bdbdb60
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1020rdb_36b.dts
@@ -0,0 +1,66 @@
+/*
+ * P1020 RDB Device Tree Source (36-bit address map)
+ *
+ * Copyright 2009-2011 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+/include/ "fsl/p1020si-pre.dtsi"
+/ {
+   model = "fsl,P1020RDB";
+   compatible = "fsl,P1020RDB";
+
+   memory {
+   device_type = "memory";
+   };
+
+   board_lbc: lbc: localbus@fffe05000 {
+   reg = <0xf 0xffe05000 0 0x1000>;
+
+   /* NOR, NAND Flashes and Vitesse 5 port L2 switch */
+   ranges = <0x0 0x0 0xf 0xef00 0x0100
+ 0x1 0x0 0xf 0xffa0 0x0004
+ 0x2 0x0 0xf 0xffb0 0x0002>;
+   };
+
+   board_soc: soc: soc@fffe0 {
+   ranges = <0x0 0xf 0xffe0 0x10>;
+   };
+
+   pci0: pcie@fffe09000 {
+   reg = <0xf 0xffe09000 0 0x1000>;
+   ranges = <0x200 0x0 0xc000 0xc 0x2000 0x0 0x2000
+ 0x100 0x0 0x 0xf 0xffc1 0x0 0x1>;
+   pcie@0 {
+   ranges = <0x200 0x0 0xc000
+ 0x200 0x0 0xc000
+ 0x0 0x2000
+
+ 0x100 0x0 0x0
+ 0x100 0x0 0x0
+ 0x0 0x10>;
+   };
+   };
+
+   pci1: pcie@fffe0a000 {
+   reg = <0xf 0xffe0a000 0 0x1000>;
+   ranges = <0x200 0x0 0x8000 0xc 0x 0x0 0x2000
+ 0x100 0x0 0x 0xf 0xffc0 0x0 0x1>;
+   pcie@0 {
+   ranges = <0x200 0x0 0x8000
+ 0x200 0x0 0x8000
+ 0x0 0x2000
+
+ 0x100 0x0 0x0
+ 0x100 0x0 0x0
+ 0x0 0x10>;
+   };
+   };
+};
+
+/include/ "p1020rdb.dtsi"
+/include/ "fsl/p1020si-post.dtsi"
-- 
1.7.3.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 08/11] powerpc/85xx: create dts components to build up an SoC

2011-11-10 Thread Kumar Gala
Introduce some common components that we can utilize to build up the
various PQ3/85xx device trees.

Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/fsl/pq3-dma-0.dtsi|   66 ++
 arch/powerpc/boot/dts/fsl/pq3-duart-0.dtsi  |   51 +
 arch/powerpc/boot/dts/fsl/pq3-esdhc-0.dtsi  |   41 ++
 arch/powerpc/boot/dts/fsl/pq3-espi-0.dtsi   |   42 ++
 arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi |   67 +++
 arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi |   67 +++
 arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi |   66 ++
 arch/powerpc/boot/dts/fsl/pq3-gpio-0.dtsi   |   41 ++
 arch/powerpc/boot/dts/fsl/pq3-i2c-0.dtsi|   43 +++
 arch/powerpc/boot/dts/fsl/pq3-i2c-1.dtsi|   43 +++
 arch/powerpc/boot/dts/fsl/pq3-mpic-timer-B.dtsi |   42 ++
 arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi |   66 ++
 arch/powerpc/boot/dts/fsl/pq3-sec3.3-0.dtsi |   45 +++
 13 files changed, 680 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/pq3-dma-0.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/pq3-duart-0.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/pq3-esdhc-0.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/pq3-espi-0.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/pq3-gpio-0.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/pq3-i2c-0.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/pq3-i2c-1.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/pq3-mpic-timer-B.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/pq3-sec3.3-0.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/pq3-dma-0.dtsi 
b/arch/powerpc/boot/dts/fsl/pq3-dma-0.dtsi
new file mode 100644
index 000..caf0b1e
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/pq3-dma-0.dtsi
@@ -0,0 +1,66 @@
+/*
+ * PQ3 DMA device tree stub [ controller @ offset 0x21000 ]
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&dma0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "fsl,eloplus-dma";
+   reg = <0x21300 0x4>;
+   ranges = <0x0 0x21100 0x200>;
+   cell-index = <0>;
+   dma-channel@0 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x0 0x80>;
+   cell-index = <0>;
+   interrupts = <20 2 0 0>;
+   };
+   dma-channel@80 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x80 0x80>;
+   cell-index = <1>;
+   interrupts = <21 2 0 0>;
+   };
+   dma-channel@100 {
+   compatible = "fsl,eloplus-dma-channel";
+   reg = <0x100 0x80>;
+   cell-index = <2>;
+   interrupts = <22 2 0 0>;
+   };
+   dma-channel@180 {
+   compatible = "fsl,eloplus-dma-channel";
+   r

[PATCH 09/11] powerpc/85xx: Rework P1020 SoC device tree

2011-11-10 Thread Kumar Gala
Split the P1020 SoC device tree into what we can include as a 'prefix'
to the board device tree and what needs to be included as a 'postfix'.

This allows use more re-use and less duplication between various board
device tree configurations (32-bit address map vs 36-bit address map).

Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/fsl/p1020si-post.dtsi |  229 +++
 arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi  |   68 +
 arch/powerpc/boot/dts/p1020si.dtsi  |  407 ---
 3 files changed, 297 insertions(+), 407 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi
 delete mode 100644 arch/powerpc/boot/dts/p1020si.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
new file mode 100644
index 000..74538a4
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
@@ -0,0 +1,229 @@
+/*
+ * P1020/P1011 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+   #address-cells = <2>;
+   #size-cells = <1>;
+   compatible = "fsl,p1020-elbc", "fsl,elbc", "simple-bus";
+   interrupts = <19 2 0 0>;
+};
+
+&pci0 {
+   compatible = "fsl,mpc8548-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <16 2 0 0>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x4 0x1
+    0x0 0x0 0x2 &mpic 0x5 0x1
+    0x0 0x0 0x3 &mpic 0x6 0x1
+    0x0 0x0 0x4 &mpic 0x7 0x1
+   >;
+   };
+};
+
+&pci1 {
+   compatible = "fsl,mpc8548-pcie";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <16 2 0 0>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x0 0x1
+    0x0 0x0 0x2 &mpic 0x1 0x1
+    0x0 0x0 0x3 &mpic 0x2 0x1
+    0x0 0x0 0x4 &mpic 0x3 0x1
+   >;
+   };
+};
+
+&soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   device_type = "soc";
+   compatible = "fsl,p1020-immr", "simple-bus";
+   bus-frequency = <0>;// Fi

[PATCH 06/11] powerpc/85xx: Add ethernet magic packet property to P1020 device tree

2011-11-10 Thread Kumar Gala
All eTSEC2 controllers support waking on magic packet so fixup device
tree to report that.

Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/p1020si.dtsi |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/p1020si.dtsi 
b/arch/powerpc/boot/dts/p1020si.dtsi
index 5514e1d..14dff69 100644
--- a/arch/powerpc/boot/dts/p1020si.dtsi
+++ b/arch/powerpc/boot/dts/p1020si.dtsi
@@ -200,6 +200,7 @@
compatible = "fsl,etsec2";
fsl,num_rx_queues = <0x8>;
fsl,num_tx_queues = <0x8>;
+   fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupt-parent = <&mpic>;
 
@@ -226,6 +227,7 @@
compatible = "fsl,etsec2";
fsl,num_rx_queues = <0x8>;
fsl,num_tx_queues = <0x8>;
+   fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupt-parent = <&mpic>;
 
@@ -252,6 +254,7 @@
compatible = "fsl,etsec2";
fsl,num_rx_queues = <0x8>;
fsl,num_tx_queues = <0x8>;
+   fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupt-parent = <&mpic>;
 
-- 
1.7.3.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 07/11] powerpc/85xx: p1020si.dtsi update interrupt handling

2011-11-10 Thread Kumar Gala
* set interrupt-parent at root so its not duplicate in every node
* Add mpic timers
* Move to 4-prop cells for mpic timer

Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/p1020si.dtsi |  117 +---
 1 files changed, 56 insertions(+), 61 deletions(-)

diff --git a/arch/powerpc/boot/dts/p1020si.dtsi 
b/arch/powerpc/boot/dts/p1020si.dtsi
index 14dff69..b08c848 100644
--- a/arch/powerpc/boot/dts/p1020si.dtsi
+++ b/arch/powerpc/boot/dts/p1020si.dtsi
@@ -14,6 +14,7 @@
compatible = "fsl,P1020";
#address-cells = <2>;
#size-cells = <2>;
+   interrupt-parent = <&mpic>;
 
cpus {
#address-cells = <1>;
@@ -37,8 +38,7 @@
#size-cells = <1>;
compatible = "fsl,p1020-elbc", "fsl,elbc", "simple-bus";
reg = <0 0xffe05000 0 0x1000>;
-   interrupts = <19 2>;
-   interrupt-parent = <&mpic>;
+   interrupts = <19 2 0 0>;
};
 
soc@ffe0 {
@@ -58,15 +58,13 @@
ecm@1000 {
compatible = "fsl,p1020-ecm", "fsl,ecm";
reg = <0x1000 0x1000>;
-   interrupts = <16 2>;
-   interrupt-parent = <&mpic>;
+   interrupts = <16 2 0 0>;
};
 
memory-controller@2000 {
compatible = "fsl,p1020-memory-controller";
reg = <0x2000 0x1000>;
-   interrupt-parent = <&mpic>;
-   interrupts = <16 2>;
+   interrupts = <16 2 0 0>;
};
 
i2c@3000 {
@@ -75,8 +73,7 @@
cell-index = <0>;
compatible = "fsl-i2c";
reg = <0x3000 0x100>;
-   interrupts = <43 2>;
-   interrupt-parent = <&mpic>;
+   interrupts = <43 2 0 0>;
dfsrr;
};
 
@@ -86,8 +83,7 @@
cell-index = <1>;
compatible = "fsl-i2c";
reg = <0x3100 0x100>;
-   interrupts = <43 2>;
-   interrupt-parent = <&mpic>;
+   interrupts = <43 2 0 0>;
dfsrr;
};
 
@@ -97,8 +93,7 @@
compatible = "ns16550";
reg = <0x4500 0x100>;
clock-frequency = <0>;
-   interrupts = <42 2>;
-   interrupt-parent = <&mpic>;
+   interrupts = <42 2 0 0>;
};
 
serial1: serial@4600 {
@@ -107,8 +102,7 @@
compatible = "ns16550";
reg = <0x4600 0x100>;
clock-frequency = <0>;
-   interrupts = <42 2>;
-   interrupt-parent = <&mpic>;
+   interrupts = <42 2 0 0>;
};
 
spi@7000 {
@@ -116,8 +110,7 @@
#size-cells = <0>;
compatible = "fsl,p1020-espi", "fsl,mpc8536-espi";
reg = <0x7000 0x1000>;
-   interrupts = <59 0x2>;
-   interrupt-parent = <&mpic>;
+   interrupts = <59 0x2 0 0>;
fsl,espi-num-chipselects = <4>;
};
 
@@ -125,8 +118,7 @@
#gpio-cells = <2>;
compatible = "fsl,mpc8572-gpio";
reg = <0xf000 0x100>;
-   interrupts = <47 0x2>;
-   interrupt-parent = <&mpic>;
+   interrupts = <47 0x2 0 0>;
gpio-controller;
};
 
@@ -135,8 +127,7 @@
reg = <0x2 0x1000>;
cache-line-size = <32>; // 32 bytes
cache-size = <0x4>; // L2,256K
-   interrupt-parent = <&mpic>;
-   interrupts = <16 2>;
+   interrupts = <16 2 0 0>;
};
 
dma@21300 {
@@ -150,29 +141,25 @@
compatible = "fsl,eloplus-dma-channel";
reg = <0x0 0x80>;
cell-index = <0>;
-   interrupt-parent = <&mpic>;
-   interrupts = <20 2>;
+   interrupts = <20 2 0 0>;
};
dma-channel@80 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x80 0x80>;
cell-index = <1>;
-   interrupt-parent = <&mpic>;
-   interrupts = <

[PATCH 05/11] powerpc/85xx: Update P1020 SEC3.3 node to match actual SoC HW

2011-11-10 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/p1020si.dtsi |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/boot/dts/p1020si.dtsi 
b/arch/powerpc/boot/dts/p1020si.dtsi
index 25e10cf..5514e1d 100644
--- a/arch/powerpc/boot/dts/p1020si.dtsi
+++ b/arch/powerpc/boot/dts/p1020si.dtsi
@@ -305,15 +305,16 @@
};
 
crypto@3 {
-   compatible = "fsl,sec3.1", "fsl,sec3.0", "fsl,sec2.4",
-"fsl,sec2.2", "fsl,sec2.1", "fsl,sec2.0";
+   compatible = "fsl,sec3.3", "fsl,sec3.1", "fsl,sec3.0",
+"fsl,sec2.4", "fsl,sec2.2", "fsl,sec2.1",
+"fsl,sec2.0";
reg = <0x3 0x1>;
interrupts = <45 2 58 2>;
interrupt-parent = <&mpic>;
fsl,num-channels = <4>;
fsl,channel-fifo-len = <24>;
-   fsl,exec-units-mask = <0xbfe>;
-   fsl,descriptor-types-mask = <0x3ab0ebf>;
+   fsl,exec-units-mask = <0x97c>;
+   fsl,descriptor-types-mask = <0x3a30abf>;
};
 
mpic: pic@4 {
-- 
1.7.3.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 04/11] powerpc/85xx: Update SPI binding to match binding spec for P1020RDB

2011-11-10 Thread Kumar Gala
The SPI node is out of date with regards to the binding for fsl-espi and
driver support.

Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/p1020rdb.dts |   30 +-
 arch/powerpc/boot/dts/p1020si.dtsi |5 ++---
 2 files changed, 15 insertions(+), 20 deletions(-)

diff --git a/arch/powerpc/boot/dts/p1020rdb.dts 
b/arch/powerpc/boot/dts/p1020rdb.dts
index 8b1a7ee..b31e7ec 100644
--- a/arch/powerpc/boot/dts/p1020rdb.dts
+++ b/arch/powerpc/boot/dts/p1020rdb.dts
@@ -149,49 +149,45 @@
};
 
spi@7000 {
-
-   fsl_m25p80@0 {
+   flash@0 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "fsl,espi-flash";
+   compatible = "spansion,s25sl12801";
reg = <0>;
-   linux,modalias = "fsl_m25p80";
-   modal = "s25sl128b";
-   spi-max-frequency = <5000>;
-   mode = <0>;
+   spi-max-frequency = <4000>; /* input clock 
*/
 
-   partition@0 {
+   partition@u-boot {
/* 512KB for u-boot Bootloader Image */
reg = <0x0 0x0008>;
-   label = "SPI (RO) U-Boot Image";
+   label = "u-boot";
read-only;
};
 
-   partition@8 {
+   partition@dtb {
/* 512KB for DTB Image */
reg = <0x0008 0x0008>;
-   label = "SPI (RO) DTB Image";
+   label = "dtb";
read-only;
};
 
-   partition@10 {
+   partition@kernel {
/* 4MB for Linux Kernel Image */
reg = <0x0010 0x0040>;
-   label = "SPI (RO) Linux Kernel Image";
+   label = "kernel";
read-only;
};
 
-   partition@50 {
+   partition@fs {
/* 4MB for Compressed RFS Image */
reg = <0x0050 0x0040>;
-   label = "SPI (RO) Compressed RFS Image";
+   label = "file system";
read-only;
};
 
-   partition@90 {
+   partition@jffs-fs {
/* 7MB for JFFS2 based RFS */
reg = <0x0090 0x0070>;
-   label = "SPI (RW) JFFS2 RFS";
+   label = "file system jffs2";
};
};
};
diff --git a/arch/powerpc/boot/dts/p1020si.dtsi 
b/arch/powerpc/boot/dts/p1020si.dtsi
index 58f6b30..25e10cf 100644
--- a/arch/powerpc/boot/dts/p1020si.dtsi
+++ b/arch/powerpc/boot/dts/p1020si.dtsi
@@ -112,14 +112,13 @@
};
 
spi@7000 {
-   cell-index = <0>;
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "fsl,espi";
+   compatible = "fsl,p1020-espi", "fsl,mpc8536-espi";
reg = <0x7000 0x1000>;
interrupts = <59 0x2>;
interrupt-parent = <&mpic>;
-   mode = "cpu";
+   fsl,espi-num-chipselects = <4>;
};
 
gpio: gpio-controller@f000 {
-- 
1.7.3.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 03/11] powerpc/85xx: Rework PCI nodes on P1020RDB

2011-11-10 Thread Kumar Gala
* Move SoC specific details like irq mapping to SoC dtsi
* Update interrupt property to cover both error interrupt and PCIe
  runtime interrupts

Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/p1020rdb.dts |   26 +-
 arch/powerpc/boot/dts/p1020si.dtsi |   40 ---
 2 files changed, 38 insertions(+), 28 deletions(-)

diff --git a/arch/powerpc/boot/dts/p1020rdb.dts 
b/arch/powerpc/boot/dts/p1020rdb.dts
index d6a8ae4..8b1a7ee 100644
--- a/arch/powerpc/boot/dts/p1020rdb.dts
+++ b/arch/powerpc/boot/dts/p1020rdb.dts
@@ -257,19 +257,8 @@
pci0: pcie@ffe09000 {
ranges = <0x200 0x0 0xa000 0 0xa000 0x0 0x2000
  0x100 0x0 0x 0 0xffc1 0x0 0x1>;
-   interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
-   interrupt-map = <
-   /* IDSEL 0x0 */
-    0x0 0x0 0x1 &mpic 0x4 0x1
-    0x0 0x0 0x2 &mpic 0x5 0x1
-    0x0 0x0 0x3 &mpic 0x6 0x1
-    0x0 0x0 0x4 &mpic 0x7 0x1
-   >;
+   reg = <0 0xffe09000 0 0x1000>;
pcie@0 {
-   reg = <0x0 0x0 0x0 0x0 0x0>;
-   #size-cells = <2>;
-   #address-cells = <3>;
-   device_type = "pci";
ranges = <0x200 0x0 0xa000
  0x200 0x0 0xa000
  0x0 0x2000
@@ -281,21 +270,10 @@
};
 
pci1: pcie@ffe0a000 {
+   reg = <0 0xffe0a000 0 0x1000>;
ranges = <0x200 0x0 0x8000 0 0x8000 0x0 0x2000
  0x100 0x0 0x 0 0xffc0 0x0 0x1>;
-   interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
-   interrupt-map = <
-   /* IDSEL 0x0 */
-    0x0 0x0 0x1 &mpic 0x0 0x1
-    0x0 0x0 0x2 &mpic 0x1 0x1
-    0x0 0x0 0x3 &mpic 0x2 0x1
-    0x0 0x0 0x4 &mpic 0x3 0x1
-   >;
pcie@0 {
-   reg = <0x0 0x0 0x0 0x0 0x0>;
-   #size-cells = <2>;
-   #address-cells = <3>;
-   device_type = "pci";
ranges = <0x200 0x0 0x8000
  0x200 0x0 0x8000
  0x0 0x2000
diff --git a/arch/powerpc/boot/dts/p1020si.dtsi 
b/arch/powerpc/boot/dts/p1020si.dtsi
index 5c5acb6..58f6b30 100644
--- a/arch/powerpc/boot/dts/p1020si.dtsi
+++ b/arch/powerpc/boot/dts/p1020si.dtsi
@@ -352,26 +352,58 @@
pci0: pcie@ffe09000 {
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
-   #interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
-   reg = <0 0xffe09000 0 0x1000>;
bus-range = <0 255>;
clock-frequency = <>;
interrupt-parent = <&mpic>;
interrupts = <16 2>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x4 0x1
+    0x0 0x0 0x2 &mpic 0x5 0x1
+    0x0 0x0 0x3 &mpic 0x6 0x1
+    0x0 0x0 0x4 &mpic 0x7 0x1
+   >;
+   };
+
};
 
pci1: pcie@ffe0a000 {
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
-   #interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
-   reg = <0 0xffe0a000 0 0x1000>;
bus-range = <0 255>;
clock-frequency = <>;
interrupt-parent = <&mpic>;
interrupts = <16 2>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1 &mpic 0x0 0x1
+ 

[PATCH 01/11] powerpc/85xx: Add 'fsl, pq3-gpio' compatiable for GPIO driver

2011-11-10 Thread Kumar Gala
Support MPC85xx platforms outside of MPC8572/MPC8536.  The
MPC8572/MPC8536 have an erratum that is worked around based on having
"fsl,mpc8572-gpio" in the compatiable list.  All other MPC85xx SoCs
don't require this workaround and thus utilize the 'fsl,pq3-gpio'
compatiable.

Signed-off-by: Kumar Gala 
---
 drivers/gpio/gpio-mpc8xxx.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
index fb4963a..d74d19b 100644
--- a/drivers/gpio/gpio-mpc8xxx.c
+++ b/drivers/gpio/gpio-mpc8xxx.c
@@ -310,6 +310,7 @@ static struct of_device_id mpc8xxx_gpio_ids[] __initdata = {
{ .compatible = "fsl,mpc8572-gpio", },
{ .compatible = "fsl,mpc8610-gpio", },
{ .compatible = "fsl,mpc5121-gpio", .data = mpc512x_irq_set_type, },
+   { .compatible = "fsl,pq3-gpio", },
{ .compatible = "fsl,qoriq-gpio",   },
{}
 };
-- 
1.7.3.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 02/11] powerpc/85xx: Simplify P1020RDB CAMP dts using includes

2011-11-10 Thread Kumar Gala
If we include the p1020rdb.dts instead of p1020si.dts we greatly reduce
duplication and maintenance.  We can just list which devices are
disabled for the given core and mpic protected sources.

Signed-off-by: Kumar Gala 
---
 arch/powerpc/boot/dts/p1020rdb_camp_core0.dts |  154 +
 arch/powerpc/boot/dts/p1020rdb_camp_core1.dts |   11 +--
 2 files changed, 4 insertions(+), 161 deletions(-)

diff --git a/arch/powerpc/boot/dts/p1020rdb_camp_core0.dts 
b/arch/powerpc/boot/dts/p1020rdb_camp_core0.dts
index f0bf7f4..41b4585 100644
--- a/arch/powerpc/boot/dts/p1020rdb_camp_core0.dts
+++ b/arch/powerpc/boot/dts/p1020rdb_camp_core0.dts
@@ -16,7 +16,7 @@
  * option) any later version.
  */
 
-/include/ "p1020si.dtsi"
+/include/ "p1020rdb.dts"
 
 / {
model = "fsl,P1020RDB";
@@ -32,7 +32,7 @@
 
cpus {
PowerPC,P1020@1 {
-   status = "disabled";
+   status = "disabled";
};
};
 
@@ -45,169 +45,19 @@
};
 
soc@ffe0 {
-   i2c@3000 {
-   rtc@68 {
-   compatible = "dallas,ds1339";
-   reg = <0x68>;
-   };
-   };
-
serial1: serial@4600 {
status = "disabled";
};
 
-   spi@7000 {
-   fsl_m25p80@0 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "fsl,espi-flash";
-   reg = <0>;
-   linux,modalias = "fsl_m25p80";
-   spi-max-frequency = <4000>;
-
-   partition@0 {
-   /* 512KB for u-boot Bootloader Image */
-   reg = <0x0 0x0008>;
-   label = "SPI (RO) U-Boot Image";
-   read-only;
-   };
-
-   partition@8 {
-   /* 512KB for DTB Image */
-   reg = <0x0008 0x0008>;
-   label = "SPI (RO) DTB Image";
-   read-only;
-   };
-
-   partition@10 {
-   /* 4MB for Linux Kernel Image */
-   reg = <0x0010 0x0040>;
-   label = "SPI (RO) Linux Kernel Image";
-   read-only;
-   };
-
-   partition@50 {
-   /* 4MB for Compressed RFS Image */
-   reg = <0x0050 0x0040>;
-   label = "SPI (RO) Compressed RFS Image";
-   read-only;
-   };
-
-   partition@90 {
-   /* 7MB for JFFS2 based RFS */
-   reg = <0x0090 0x0070>;
-   label = "SPI (RW) JFFS2 RFS";
-   };
-   };
-   };
-
-   mdio@24000 {
-   phy0: ethernet-phy@0 {
-   interrupt-parent = <&mpic>;
-   interrupts = <3 1>;
-   reg = <0x0>;
-   };
-   phy1: ethernet-phy@1 {
-   interrupt-parent = <&mpic>;
-   interrupts = <2 1>;
-   reg = <0x1>;
-   };
-   };
-
-   mdio@25000 {
-   tbi0: tbi-phy@11 {
-   reg = <0x11>;
-   device_type = "tbi-phy";
-   };
-   };
-
enet0: ethernet@b {
status = "disabled";
};
 
-   enet1: ethernet@b1000 {
-   phy-handle = <&phy0>;
-   tbi-handle = <&tbi0>;
-   phy-connection-type = "sgmii";
-   };
-
-   enet2: ethernet@b2000 {
-   phy-handle = <&phy1>;
-   phy-connection-type = "rgmii-id";
-   };
-
-   usb@22000 {
-   phy_type = "ulpi";
-   };
-
-   /* USB2 is shared with localbus, so it must be disabled
-  by default. We can't put 'status = "disabled";' here
-   

Re: [RFC PATCH 02/17] powerpc: Split up PHYS_64BIT config option to fix "select" issues

2011-11-10 Thread Timur Tabi
Kyle Moffett wrote:
>   CONFIG_PHYS_64BIT_SUPPORTED:
> This hidden option should be selected by any CPU type which supports
> 64-bit physical addresses.  This will enable the PHYS_64BIT option
> to be selected.  It is (obviously) always set on PPC64.
> 
>   CONFIG_PHYS_64BIT_DT_REQUIRED:
> This hidden option should be selected by any board or platform which
> has >32-bit physical devices present in hardware.  If this is set
> then the CONFIG_PHYS_64BIT option will be forcibly enabled and
> hidden from the user.  It is (obviously) always set on PPC64.
> 
>   CONFIG_PHYS_64BIT:
> This option is user-controllable, where allowed by CPU and platform
> settings, and should never be pointed at with a "select" statement.
> Due to the values of the above two options, this is never visible on
> PPC64.

I'm with Kumar on this.  I don't see the point of making it so complicated.  No 
kernel should ever have to care with a DT is 64-bit or 32-bit.  If you build a 
kernel with 64-bit phys support, then it will work with any DT.

U-Boot already warns you if the DT and the actual physical addresses of the 
devices don't match.

There are only two reasons to create a 32-bit kernel:

1) A small performance improvement on systems with 2GB or less.
2) Some SOC devices only support 32-bit physical addresses, so the easiest way 
to ensure a compatible address is to prohibit memory above 4GB.

Item #2 is not something that we really worry about.  It's only a real problem 
on true 64-bit kernels, and in those cases, we cannot build a kernel with 
32-bit phys support, so the driver needs to handle it internally.

-- 
Timur Tabi
Linux kernel developer at Freescale

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc

2011-11-10 Thread Kumar Gala

On Nov 9, 2011, at 6:03 PM, Kyle Moffett wrote:

> Hello,
> 
> I saw Baruch Siach's patch:
>  powerpc: 85xx: separate e500 from e500mc
> 
> Unfortunately, that patch breaks the dependencies for the P5020DS
> platform and does not fix the underlying code which does not
> understand what the ambiguous "CONFIG_E500" means.
> 
> In order to fix the issue at the fundamental level, I created the
> following 17-patch series loosely based on Baruch's patch.
> 
> === High-Level Summary ===
> 
> The e500v1/v2 and e500mc/e5500 CPU families are not compatible with
> each other, yet they share the same "CONFIG_E500" Kconfig option.
> 
> The following patch series splits the 32-bit CPU support into two
> separate options: "CONFIG_FSL_E500_V1_V2" and "CONFIG_FSL_E500MC".
> Additionally, the 64-bit e5500 support is separated to its own config
> option ("CONFIG_FSL_E5500") which is automatically combined with
> either 32-bit e500MC or 64-bit Book-3E when the P5020DS board support
> is enabled.

So its clear from the community that there is confusion here and we need to 
clean this up.  I guess my attempt to support an kernel that ran on both E500v2 
and E500mc isn't worth it.  However I don't want to completely remove the 
ability to do this.

Towards the cleanup I'd ask for a proposal on what exactly the CONFIG_ options 
we'd end up with would be and their meaning.

So today we have:

CONFIG_E500
CONFIG_PPC_E500MC

What do we want to move to?  I want to keep the builds such that we have only 2 
classes:  e500V1/V2 and e500mc/e5500/e6500/.../eX500.  I see no reason to 
hyper-optimize e500mc vs e5500 vs e6500.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 13/17] powerpc/e500: Add a new CONFIG_FSL_E5500 option for the e5500

2011-11-10 Thread Kumar Gala

On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:

> As part of splitting CONFIG_E500 into separate options for e500v1/v2 and
> e500mc/e5500, some code only needs to be built when e5500 support is
> required.
> 
> This adds a new internal-use config option for both 32-bit and 64-bit
> builds that enables only the e5500 support code.
> 
> Signed-off-by: Kyle Moffett 
> ---
> arch/powerpc/platforms/85xx/Kconfig|2 +-
> arch/powerpc/platforms/Kconfig.cputype |4 
> 2 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/85xx/Kconfig 
> b/arch/powerpc/platforms/85xx/Kconfig
> index 248f87c..72488d4 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -231,8 +231,8 @@ endif # PPC32
> config P5020_DS
>   bool "Freescale P5020 DS"
>   depends on FSL_E500MC || PPC_BOOK3E_64
> + select FSL_E5500
>   select DEFAULT_UIMAGE
> - select E500
>   select PHYS_64BIT_DT_REQUIRED
>   select SWIOTLB
>   select ARCH_REQUIRE_GPIOLIB
> diff --git a/arch/powerpc/platforms/Kconfig.cputype 
> b/arch/powerpc/platforms/Kconfig.cputype
> index fd37bb2..cff45e3 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -144,6 +144,10 @@ config 8xx
> config PPC_85xx
>   bool
> 
> +config FSL_E5500
> + bool
> + select E500
> +
> config E500
>   select FSL_EMB_PERFMON
>   select PPC_FSL_BOOK3E
> -- 
> 1.7.2.5

Nak, I don't want to add a unique build option for 64-bit E5500 vs E500MC.  We 
have E6500 coming and I don't want to introduce CONFIG_FSL_E6500 at that point.

- k

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 08/17] powerpc/e500: Remove conditional "lwsync" substitution

2011-11-10 Thread Kumar Gala

On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:

> As FreeScale e500 systems have different cacheline sizes from e500mc, it
> is basically impossible for the kernel to support both in a single
> system image at present.
> 
> Given that one is SPE-float and the other is classic-float, they are not
> generally userspace-compatible either.
> 
> This patch updates the conditional to depend on whether the system is
> actually targetting an "e500" or "e500mc" core and entirely removes the
> unused sync-to-lwsync-replacement on e500v1/e500v2 systems.
> 
> Signed-off-by: Kyle Moffett 
> ---
> arch/powerpc/include/asm/synch.h |   16 
> 1 files changed, 4 insertions(+), 12 deletions(-)

Nak, we can run an e500mc in a mode that is compatible with e500v1/v2.  I see 
no reason to change the support we have there.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 04/17] powerpc: Allow multiple machine-check handlers

2011-11-10 Thread Kumar Gala

On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:

> Certain processor types are co-supportable, and their machine-check
> handlers will be referenced if the entries in cputable.c are actually
> generated, so allow more than one machine-check handler to be built in.
> 
> This fixes a bug where configuring FreeScale E5500 support (P5020DS)
> into the kernel would break machine-check handling on PPC64 A2 systems
> by using a bogus machine_check_generic() handler that does nothing.
> 
> Signed-off-by: Kyle Moffett 
> ---
> arch/powerpc/kernel/traps.c |   18 --
> 1 files changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 4e59082..e3113341 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -418,7 +418,8 @@ int machine_check_47x(struct pt_regs *regs)
> 
>   return 0;
> }
> -#elif defined(CONFIG_E500)
> +#endif
> +#if defined(CONFIG_FSL_E500MC) || defined(CONFIG_FSL_E5500)
> int machine_check_e500mc(struct pt_regs *regs)
> {
>   unsigned long mcsr = mfspr(SPRN_MCSR);
> @@ -517,7 +518,8 @@ silent_out:
>   mtspr(SPRN_MCSR, mcsr);
>   return mfspr(SPRN_MCSR) == 0 && recoverable;
> }
> -
> +#endif
> +#ifdef CONFIG_FSL_E500_V1_V2

doesn't exist yet, so patch is wrong sequence order.

> int machine_check_e500(struct pt_regs *regs)
> {
>   unsigned long reason = get_mc_reason(regs);
> @@ -557,12 +559,8 @@ int machine_check_e500(struct pt_regs *regs)
> 
>   return 0;
> }
> -
> -int machine_check_generic(struct pt_regs *regs)
> -{
> - return 0;
> -}
> -#elif defined(CONFIG_E200)
> +#endif
> +#ifdef CONFIG_E200
> int machine_check_e200(struct pt_regs *regs)
> {
>   unsigned long reason = get_mc_reason(regs);
> @@ -587,7 +585,8 @@ int machine_check_e200(struct pt_regs *regs)
> 
>   return 0;
> }
> -#else
> +#endif
> +
> int machine_check_generic(struct pt_regs *regs)
> {
>   unsigned long reason = get_mc_reason(regs);
> @@ -623,7 +622,6 @@ int machine_check_generic(struct pt_regs *regs)
>   }
>   return 0;
> }
> -#endif /* everything else */
> 
> void machine_check_exception(struct pt_regs *regs)
> {
> -- 
> 1.7.2.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 02/17] powerpc: Split up PHYS_64BIT config option to fix "select" issues

2011-11-10 Thread Kumar Gala

On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:

> The "CONFIG_PHYS_64BIT" option violates the Kconfig best-practices in
> various colorful ways.  It has explicit dependencies, but it is also
> "select"ed by various CPUs and platforms.  It is not set on 64-bit
> systems, but it is used by a number of pieces of powerpc code to enable
> or disable 64-bit physical address support.
> 
> To resolve these issues, the option has now been split into 3:
> 
>  CONFIG_PHYS_64BIT_SUPPORTED:
>This hidden option should be selected by any CPU type which supports
>64-bit physical addresses.  This will enable the PHYS_64BIT option
>to be selected.  It is (obviously) always set on PPC64.
> 
>  CONFIG_PHYS_64BIT_DT_REQUIRED:
>This hidden option should be selected by any board or platform which
>has >32-bit physical devices present in hardware.  If this is set
>then the CONFIG_PHYS_64BIT option will be forcibly enabled and
>hidden from the user.  It is (obviously) always set on PPC64.
> 
>  CONFIG_PHYS_64BIT:
>This option is user-controllable, where allowed by CPU and platform
>settings, and should never be pointed at with a "select" statement.
>Due to the values of the above two options, this is never visible on
>PPC64.
> 
> Signed-off-by: Kyle Moffett 
> ---
> arch/powerpc/Kconfig   |4 ++--
> arch/powerpc/platforms/82xx/Kconfig|2 +-
> arch/powerpc/platforms/83xx/Kconfig|2 +-
> arch/powerpc/platforms/85xx/Kconfig|   12 ++--
> arch/powerpc/platforms/86xx/Kconfig|1 +
> arch/powerpc/platforms/Kconfig.cputype |   25 ++---
> 6 files changed, 29 insertions(+), 17 deletions(-)

I don't really see what this gets us and don't think we should make this change.

- k

> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index b177caa..27e31c5 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -18,10 +18,10 @@ config WORD_SIZE
>   default 32 if !PPC64
> 
> config ARCH_PHYS_ADDR_T_64BIT
> -   def_bool PPC64 || PHYS_64BIT
> + def_bool PHYS_64BIT
> 
> config ARCH_DMA_ADDR_T_64BIT
> - def_bool ARCH_PHYS_ADDR_T_64BIT
> + def_bool PHYS_64BIT
> 
> config MMU
>   bool
> diff --git a/arch/powerpc/platforms/82xx/Kconfig 
> b/arch/powerpc/platforms/82xx/Kconfig
> index 7c7df40..849d403 100644
> --- a/arch/powerpc/platforms/82xx/Kconfig
> +++ b/arch/powerpc/platforms/82xx/Kconfig
> @@ -1,6 +1,6 @@
> menuconfig PPC_82xx
>   bool "82xx-based boards (PQ II)"
> - depends on 6xx
> + depends on 6xx && !PHYS_64BIT
> 
> if PPC_82xx
> 
> diff --git a/arch/powerpc/platforms/83xx/Kconfig 
> b/arch/powerpc/platforms/83xx/Kconfig
> index 670a033..1ed8877 100644
> --- a/arch/powerpc/platforms/83xx/Kconfig
> +++ b/arch/powerpc/platforms/83xx/Kconfig
> @@ -1,6 +1,6 @@
> menuconfig PPC_83xx
>   bool "83xx-based boards"
> - depends on 6xx
> + depends on 6xx && !PHYS_64BIT
>   select PPC_UDBG_16550
>   select PPC_PCI_CHOICE
>   select FSL_PCI if PCI
> diff --git a/arch/powerpc/platforms/85xx/Kconfig 
> b/arch/powerpc/platforms/85xx/Kconfig
> index 9088381..37f9de7 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -80,7 +80,7 @@ config P1010_RDB
> config P1022_DS
>   bool "Freescale P1022 DS"
>   select DEFAULT_UIMAGE
> - select PHYS_64BIT   # The DTS has 36-bit addresses
> + select PHYS_64BIT_DT_REQUIRED # The DTS has 36-bit addresses
>   select SWIOTLB
>   help
> This option enables support for the Freescale P1022DS reference board.
> @@ -175,7 +175,7 @@ config P2041_RDB
>   bool "Freescale P2041 RDB"
>   select DEFAULT_UIMAGE
>   select PPC_E500MC
> - select PHYS_64BIT
> + select PHYS_64BIT_DT_REQUIRED
>   select SWIOTLB
>   select ARCH_REQUIRE_GPIOLIB
>   select GPIO_MPC8XXX
> @@ -189,7 +189,7 @@ config P3041_DS
>   bool "Freescale P3041 DS"
>   select DEFAULT_UIMAGE
>   select PPC_E500MC
> - select PHYS_64BIT
> + select PHYS_64BIT_DT_REQUIRED
>   select SWIOTLB
>   select ARCH_REQUIRE_GPIOLIB
>   select GPIO_MPC8XXX
> @@ -203,7 +203,7 @@ config P3060_QDS
>   bool "Freescale P3060 QDS"
>   select DEFAULT_UIMAGE
>   select PPC_E500MC
> - select PHYS_64BIT
> + select PHYS_64BIT_DT_REQUIRED
>   select SWIOTLB
>   select MPC8xxx_GPIO
>   select HAS_RAPIDIO
> @@ -216,7 +216,7 @@ config P4080_DS
>   bool "Freescale P4080 DS"
>   select DEFAULT_UIMAGE
>   select PPC_E500MC
> - select PHYS_64BIT
> + select PHYS_64BIT_DT_REQUIRED
>   select SWIOTLB
>   select ARCH_REQUIRE_GPIOLIB
>   select GPIO_MPC8XXX
> @@ -233,7 +233,7 @@ config P5020_DS
>   select DEFAULT_UIMAGE
>   select E500
>   select PPC_E500MC
> - select PHYS_64BIT
> + select PHYS_64BIT_DT_REQUIRED
>   select SWIOTLB
>   select ARCH_REQUIRE_GPIOLIB
>   select GPIO_M

Re: [RFC PATCH 01/17] powerpc/mpic: Fix bogus CONFIG_BOOKE conditional

2011-11-10 Thread Kumar Gala

On Nov 9, 2011, at 6:06 PM, Kyle Moffett wrote:

> The code inside the conditional is only used by 85xx CoreNet fabric
> platforms, so add a new config define and use it where necessary.

1. why make the change
2. if you're using FSL_CORENET as a SoC feature CONFIG option than other bits 
of this patch are wrong

It should NOT be used in platforms/85xx/Makefile those should be left alone and 
FSL_CORENET should be selected by having E500MC or similar set.

> 
> Signed-off-by: Kyle Moffett 
> ---
> arch/powerpc/platforms/85xx/Kconfig|5 +
> arch/powerpc/platforms/85xx/Makefile   |   11 ++-
> arch/powerpc/platforms/Kconfig.cputype |3 +++
> arch/powerpc/sysdev/mpic.c |6 ++
> 4 files changed, 16 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/85xx/Kconfig 
> b/arch/powerpc/platforms/85xx/Kconfig
> index 45023e2..9088381 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -181,6 +181,7 @@ config P2041_RDB
>   select GPIO_MPC8XXX
>   select HAS_RAPIDIO
>   select PPC_EPAPR_HV_PIC
> + select FSL_CORENET
>   help
> This option enables support for the P2041 RDB board
> 
> @@ -194,6 +195,7 @@ config P3041_DS
>   select GPIO_MPC8XXX
>   select HAS_RAPIDIO
>   select PPC_EPAPR_HV_PIC
> + select FSL_CORENET
>   help
> This option enables support for the P3041 DS board
> 
> @@ -206,6 +208,7 @@ config P3060_QDS
>   select MPC8xxx_GPIO
>   select HAS_RAPIDIO
>   select PPC_EPAPR_HV_PIC
> + select FSL_CORENET
>   help
> This option enables support for the P3060 QDS board
> 
> @@ -219,6 +222,7 @@ config P4080_DS
>   select GPIO_MPC8XXX
>   select HAS_RAPIDIO
>   select PPC_EPAPR_HV_PIC
> + select FSL_CORENET
>   help
> This option enables support for the P4080 DS board
> 
> @@ -235,6 +239,7 @@ config P5020_DS
>   select GPIO_MPC8XXX
>   select HAS_RAPIDIO
>   select PPC_EPAPR_HV_PIC
> + select FSL_CORENET
>   help
> This option enables support for the P5020 DS board
> 
> diff --git a/arch/powerpc/platforms/85xx/Makefile 
> b/arch/powerpc/platforms/85xx/Makefile
> index bc5acb9..c6d1334 100644
> --- a/arch/powerpc/platforms/85xx/Makefile
> +++ b/arch/powerpc/platforms/85xx/Makefile
> @@ -13,11 +13,12 @@ obj-$(CONFIG_MPC85xx_RDB) += mpc85xx_rdb.o
> obj-$(CONFIG_P1010_RDB)   += p1010rdb.o
> obj-$(CONFIG_P1022_DS)+= p1022_ds.o
> obj-$(CONFIG_P1023_RDS)   += p1023_rds.o
> -obj-$(CONFIG_P2041_RDB)   += p2041_rdb.o corenet_ds.o
> -obj-$(CONFIG_P3041_DS)+= p3041_ds.o corenet_ds.o
> -obj-$(CONFIG_P3060_QDS)   += p3060_qds.o corenet_ds.o
> -obj-$(CONFIG_P4080_DS)+= p4080_ds.o corenet_ds.o
> -obj-$(CONFIG_P5020_DS)+= p5020_ds.o corenet_ds.o
> +obj-$(CONFIG_P2041_RDB)   += p2041_rdb.o
> +obj-$(CONFIG_P3041_DS)+= p3041_ds.o
> +obj-$(CONFIG_P3060_QDS)   += p3060_qds.o
> +obj-$(CONFIG_P4080_DS)+= p4080_ds.o
> +obj-$(CONFIG_P5020_DS)+= p5020_ds.o
> +obj-$(CONFIG_FSL_CORENET) += corenet_ds.o
> obj-$(CONFIG_STX_GP3)   += stx_gp3.o
> obj-$(CONFIG_TQM85xx)   += tqm85xx.o
> obj-$(CONFIG_SBC8560) += sbc8560.o
> diff --git a/arch/powerpc/platforms/Kconfig.cputype 
> b/arch/powerpc/platforms/Kconfig.cputype
> index fbecae0..9210e94 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -177,6 +177,9 @@ config FSL_BOOKE
>   select SYS_SUPPORTS_HUGETLBFS if PHYS_64BIT
>   default y
> 
> +config FSL_CORENET
> + bool
> +
> # this is for common code between PPC32 & PPC64 FSL BOOKE
> config PPC_FSL_BOOK3E
>   bool
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index 0842c6f..1a3d84a 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -1642,9 +1642,9 @@ unsigned int mpic_get_irq(void)
>   return mpic_get_one_irq(mpic);
> }
> 
> +#ifdef CONFIG_FSL_CORENET
> unsigned int mpic_get_coreint_irq(void)
> {
> -#ifdef CONFIG_BOOKE
>   struct mpic *mpic = mpic_primary;
>   u32 src;
> 
> @@ -1664,10 +1664,8 @@ unsigned int mpic_get_coreint_irq(void)
>   }
> 
>   return irq_linear_revmap(mpic->irqhost, src);
> -#else
> - return NO_IRQ;
> -#endif
> }
> +#endif
> 
> unsigned int mpic_get_mcirq(void)
> {
> -- 
> 1.7.2.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 4/5] treewide: Convert uses of ATTRIB_NORETURN to __noreturn

2011-11-10 Thread Ralf Baechle
On Thu, Nov 10, 2011 at 01:41:45AM -0800, Joe Perches wrote:

> Use the more commonly used __noreturn instead of ATTRIB_NORETURN.

Subject and here: s/ATTRIB_NORETURN/ATTRIB_NORET/

> Signed-off-by: Joe Perches 
> ---
>  arch/ia64/kernel/machine_kexec.c   |2 +-
>  arch/m68k/amiga/config.c   |2 +-
>  arch/mips/include/asm/ptrace.h |2 +-
>  arch/mips/kernel/traps.c   |2 +-

For the MIPS bits:

Acked-by: Ralf Baechle 

  Ralf
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 3/5] treewide: Remove useless NORET_TYPE macro and uses

2011-11-10 Thread Ralf Baechle
On Thu, Nov 10, 2011 at 01:41:44AM -0800, Joe Perches wrote:

>  arch/mips/include/asm/ptrace.h |2 +-
>  arch/mips/kernel/traps.c   |2 +-

For the MIPS bits:

Acked-by: Ralf Baechle 

  Ralf
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


right way to get interrupt controller register

2011-11-10 Thread Andreas Friesen
Hello people,

I have a little problem with the isr routine. The interrupt handler
is installed and working fine, but I can not clear the interrupt flag in
ICTL-Register.

Is that right way to get interrupt controller register ?

Thanks in advance,
Andreas Friesen


Hier is my ISR-Handler and probe functions :

static irqreturn_t mess_isr (int irq, void *data)
{
struct qxcpld_drvdata *drvdata ;
drvdata = (struct qxcpld_drvdata *)data ;
struct mpc52xx_intr __iomem *intr;
int i ;
u32 intr_ctrl;

       intr = drvdata->intr
       intr_ctrl = intr->ctrl ;
intr_ctrl = in_be32(&intr->ctrl);
intr_ctrl |=  0x0400;
out_be32 (&intr->ctrl,intr_ctrl);

      // set gpio
      

return IRQ_HANDLED;
}



/* MPC5200 device tree match tables */
static struct of_device_id mpc52xx_pic_ids[] __initdata = {
{ .compatible = "fsl,mpc5200b-pic", },
{ .compatible = "mpc5200-pic", },
{}
};


static int __devinit qxcpld_of_probe (struct platform_device *ofdev)
{
.
/* Remap the necessary zones */
np = of_find_matching_node(NULL, mpc52xx_pic_ids);
drvdata->intr = of_iomap(np, 0);
if (!drvdata->intr)
panic(__FILE__  ": find_and_map failed on 'mpc5200-pic'. "
     "Check node !");
of_node_put (np);


/* request irq */
drvdata->mess_irq = irq_of_parse_and_map(ofdev->dev.of_node,0);
if (drvdata->mess_irq == NO_IRQ ) {
dev_err (&ofdev->dev, "failed to attach interrupt\n");
goto reg_unmap ;
}


if ( request_irq( drvdata->mess_irq,
                 qxcpld_mess_isr,
                 IRQF_DISABLED|IRQF_SHARED,
                 "qxcpld-mess-irq",
                 (void *)drvdata
    ) ) {
dev_err(&ofdev->dev, "Can't request irq\n") ;
goto reg_unmap ;
}

...

}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH v4 02/10] fadump: Reserve the memory for firmware assisted dump.

2011-11-10 Thread Mahesh J Salgaonkar
On 2011-11-10 17:57:02 Thu, Cong Wang wrote:
> Hi, Mahesh,
> 
> Your patch seems have some style problems... checkpatch.pl complains,
> 
> total: 330 errors, 1 warnings, 355 lines checked
> 
> NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
>   scripts/cleanfile
> 
> Could use scripts/checkpatch.pl to check your patch?

I do run the checkpatch.pl before sending patches out. I am not sure how
I missed this one. Will do better job next time.

Thanks,

-- 
Mahesh J Salgaonkar

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH v4 01/10] fadump: Add documentation for firmware-assisted dump.

2011-11-10 Thread Mahesh J Salgaonkar
On 2011-11-10 17:46:30 Thu, Cong Wang wrote:
> 于 2011年11月07日 17:55, Mahesh J Salgaonkar 写道:
> >From: Mahesh Salgaonkar
> >
> >Documentation for firmware-assisted dump. This document is based on the
> >original documentation written for phyp assisted dump by Linas Vepstas
> >and Manish Ahuja, with few changes to reflect the current implementation.
> >
> >Change in v3:
> >- Modified the documentation to reflect introdunction of fadump_registered
> >   sysfs file and few minor changes.
> >
> >Change in v2:
> >- Modified the documentation to reflect the change of fadump_region
> >   file under debugfs filesystem.
> >
> >Signed-off-by: Mahesh Salgaonkar
> 
> 
> Please Cc Randy Dunlap  for kernel documentation
> patch.
> 
> I have some inline comments below.
> 

Thanks for your review. I will incorporate all your comments.

<...>
> >+with minor modifications. The kdump script requires following
> >+modifications:
> >+-- During service kdump start if /proc/vmcore entry is not present,
> >+   look for the existence of /sys/kernel/fadump_enabled and read
> >+   value exported by it. If value is set to '0' then fallback to
> >+   existing kexec based kdump. If value is set to '1' then check the
> >+   value exported by /sys/kernel/fadump_registered. If value it set
> >+   to '1' then print success otherwise register for fadump by
> >+   echo'ing 1>  /sys/kernel/fadump_registered file.
> >+
> >+-- During service kdump start if /proc/vmcore entry is present,
> >+   execute the existing routine to save the dump. Once the dump
> >+   is saved, echo 1>  /sys/kernel/fadump_release_mem (if the
> >+   file exists) to release the reserved memory for general use
> >+   and continue without rebooting. At this point the memory
> >+   reservation map will look like as shown in Fig. 1. If the file
> >+   /sys/kernel/fadump_release_mem is not present then follow
> >+   the existing routine to reboot into new kernel.
> >+
> >+-- During service kdump stop echo 0>  /sys/kernel/fadump_registered
> >+   to un-register the fadump.
> >+
> 
> I don't think you need to document kdump script changes in a kernel
> doc.
> 

Agree. I will remove it.

> >+
> >+TODO:
> >+-
> >+ o Need to come up with the better approach to find out more
> >+   accurate boot memory size that is required for a kernel to
> >+   boot successfully when booted with restricted memory.
> >+ o The fadump implementation introduces a fadump crash info structure
> >+   in the scratch area before the ELF core header. The idea of introducing
> >+   this structure is to pass some important crash info data to the second
> >+   kernel which will help second kernel to populate ELF core header with
> >+   correct data before it gets exported through /proc/vmcore. The current
> >+   design implementation does not address a possibility of introducing
> >+   additional fields (in future) to this structure without affecting
> >+   compatibility. Need to come up with the better approach to address this.
> >+   The possible approaches are:
> >+1. Introduce version field for version tracking, bump up the version
> >+whenever a new field is added to the structure in future. The version
> >+field can be used to find out what fields are valid for the current
> >+version of the structure.
> >+2. Reserve the area of predefined size (say PAGE_SIZE) for this
> >+structure and have unused area as reserved (initialized to zero)
> >+for future field additions.
> >+   The advantage of approach 1 over 2 is we don't need to reserve extra 
> >space.
> >+---
> 
> Why do we keep TODO in this doc?
> 

I see most of the kernel doc do contain TODO, hence I added it here.

Thanks,
-Mahesh.

-- 
Mahesh J Salgaonkar
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH v4 06/10] fadump: Add PT_NOTE program header for vmcoreinfo

2011-11-10 Thread Cong Wang

于 2011年11月07日 17:56, Mahesh J Salgaonkar 写道:

From: Mahesh Salgaonkar

Introduce a PT_NOTE program header that points to physical address of
vmcoreinfo_note buffer declared in kernel/kexec.c. The vmcoreinfo
note buffer is populated during crash_fadump() at the time of system
crash.

Signed-off-by: Mahesh Salgaonkar
---
  arch/powerpc/kernel/fadump.c |   29 +
  1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 70d6287..e68ee3a 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -816,6 +816,19 @@ static void setup_crash_memory_ranges(void)
}
  }

+/*
+ * If the given physical address falls within the boot memory region then
+ * return the relocated address that points to the dump region reserved
+ * for saving initial boot memory contents.
+ */
+static inline unsigned long relocate(unsigned long paddr)
+{
+   if (paddr>  RMR_START&&  paddr<  fw_dump.boot_memory_size)
+   return fdm.rmr_region.destination_address + paddr;
+   else
+   return paddr;
+}


Although they are static functions, it is still better to name them
with "fadump_" prefix...

Thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH v4 10/10] fadump: Introduce config option for firmware assisted dump feature

2011-11-10 Thread Cong Wang

于 2011年11月07日 17:56, Mahesh J Salgaonkar 写道:

From: Mahesh Salgaonkar

This patch introduces a new config option CONFIG_FA_DUMP for firmware
assisted dump feature on Powerpc (ppc64) architecture.



I think this patch can be folded into the 02/10, as this config
is already used there.

Thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH v4 05/10] fadump: Convert firmware-assisted cpu state dump data into elf notes.

2011-11-10 Thread Cong Wang

于 2011年11月07日 17:55, Mahesh J Salgaonkar 写道:

+#ifdef CONFIG_FA_DUMP
+   crash_fadump(regs, str);
+#endif
+


Please make it a nop for !CONFIG_FA_DUMP.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH v4 02/10] fadump: Reserve the memory for firmware assisted dump.

2011-11-10 Thread Cong Wang

Hi, Mahesh,

Your patch seems have some style problems... checkpatch.pl complains,

total: 330 errors, 1 warnings, 355 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
  scripts/cleanfile

Could use scripts/checkpatch.pl to check your patch?

Thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH v4 01/10] fadump: Add documentation for firmware-assisted dump.

2011-11-10 Thread Cong Wang

于 2011年11月07日 17:55, Mahesh J Salgaonkar 写道:

From: Mahesh Salgaonkar

Documentation for firmware-assisted dump. This document is based on the
original documentation written for phyp assisted dump by Linas Vepstas
and Manish Ahuja, with few changes to reflect the current implementation.

Change in v3:
- Modified the documentation to reflect introdunction of fadump_registered
   sysfs file and few minor changes.

Change in v2:
- Modified the documentation to reflect the change of fadump_region
   file under debugfs filesystem.

Signed-off-by: Mahesh Salgaonkar



Please Cc Randy Dunlap  for kernel documentation
patch.

I have some inline comments below.


---
  Documentation/powerpc/firmware-assisted-dump.txt |  262 ++
  1 files changed, 262 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/powerpc/firmware-assisted-dump.txt

diff --git a/Documentation/powerpc/firmware-assisted-dump.txt 
b/Documentation/powerpc/firmware-assisted-dump.txt
new file mode 100644
index 000..ba6724a
--- /dev/null
+++ b/Documentation/powerpc/firmware-assisted-dump.txt
@@ -0,0 +1,262 @@
+
+   Firmware-Assisted Dump
+   
+   July 2011
+
+The goal of firmware-assisted dump is to enable the dump of
+a crashed system, and to do so from a fully-reset system, and
+to minimize the total elapsed time until the system is back
+in production use.
+
+As compared to kdump or other strategies, firmware-assisted
+dump offers several strong, practical advantages:



Comparing with kdump or...


+
+-- Unlike kdump, the system has been reset, and loaded
+   with a fresh copy of the kernel.  In particular,
+   PCI and I/O devices have been reinitialized and are
+   in a clean, consistent state.
+-- Once the dump is copied out, the memory that held the dump
+   is immediately available to the running kernel. A further
+   reboot isn't required.
+
+The above can only be accomplished by coordination with,
+and assistance from the Power firmware. The procedure is
+as follows:
+
+-- The first kernel registers the sections of memory with the
+   Power firmware for dump preservation during OS initialization.
+   This registered sections of memory is reserved by the first


These registered sections of memory are...


+   kernel during early boot.
+
+-- When a system crashes, the Power firmware will save
+   the low memory (boot memory of size larger of 5% of system RAM
+   or 256MB) of RAM to a previously registered save region. It


...to the previous registered region...


+   will also save system registers, and hardware PTE's.
+
+   NOTE: The term 'boot memory' means size of the low memory chunk
+ that is required for a kernel to boot successfully when
+ booted with restricted memory. By default, the boot memory
+ size will be calculated to larger of 5% of system RAM or


will be the larger of...


+ 256MB. Alternatively, user can also specify boot memory
+ size through boot parameter 'fadump_reserve_mem=' which
+ will override the default calculated size.
+
+-- After the low memory (boot memory) area has been saved, the
+   firmware will reset PCI and other hardware state.  It will
+   *not* clear the RAM. It will then launch the bootloader, as
+   normal.
+
+-- The freshly booted kernel will notice that there is a new
+   node (ibm,dump-kernel) in the device tree, indicating that
+   there is crash data available from a previous boot. During
+   the early boot OS will reserve rest of the memory above
+   boot memory size effectively booting with restricted memory
+   size. This will make sure that the second kernel will not
+   touch any of the dump memory area.
+
+-- Userspace tools will read /proc/vmcore to obtain the contents
+   of memory, which holds the previous crashed kernel dump in ELF
+   format. The userspace tools may copy this info to disk, or
+   network, nas, san, iscsi, etc. as desired.



s/Userspace/User-space/


+
+-- Once the userspace tool is done saving dump, it will echo
+   '1' to /sys/kernel/fadump_release_mem to release the reserved
+   memory back to general use, except the memory required for
+   next firmware-assisted dump registration.
+
+   e.g.
+ # echo 1>  /sys/kernel/fadump_release_mem
+
+Please note that the firmware-assisted dump feature
+is only available on Power6 and above systems with recent
+firmware versions.
+
+Implementation details:
+--
+
+During boot, a check is made to see if firmware supports
+this feature on that particular machine. If it does, then
+we check to see if an active dump is waiting for us. If yes
+then everything but boot memory size of RAM is reserved during
+early boot (See Fig. 2). This area is released once we collect a
+dump from user land scripts (kdump scripts) that are run. If


This area is released once we finish collecting the dump
from user land scripts (e.g. kdump scripts).



+there is dump 

  1   2   >