Re: [PATCH] powerpc: Export PIR data through sysfs
On Wed, Nov 09, 2011 at 09:48:25AM -0600, Scott Wood wrote: On Wed, Nov 09, 2011 at 10:11:24AM +0530, Ananth N Mavinakayanahalli wrote: On Tue, Nov 08, 2011 at 10:59:46AM -0600, Scott Wood wrote: On 11/08/2011 12:58 AM, Ananth N Mavinakayanahalli wrote: On Mon, Nov 07, 2011 at 11:18:32AM -0600, Scott Wood wrote: What use does userspace have for this? If you want to return the currently executing CPU (which unless you're pinned could change as soon as the value is read...), why not just return smp_processor_id() or hard_smp_processor_id()? Its not just the current cpu. Decoding PIR can tell you the core id, thread id in case of SMT, and this information can be used by userspace apps to set affinities, etc. Wouldn't it make more sense to expose the thread to core mappings in a general way, not tied to hardware or what thread we're currently running on? AFAIK, the information encoding in PIR is platform dependent. There is no general way to expose this information unless you want have a per-platform ifdef. Even then, I am not sure if that information will generally be available or provided. What's the use case for knowing this information only about the current thread (or rather the state the current thread was in a few moments ago)? Its not information about the thread but about the cpu. Unless you have a shared LPAR environment, the data will be consistent and can be used by applications with knowledge of the platform. I'm not sure what a shared LPAR environment is, but unless you're pinned there's no guarantee the CPU you're running on once the read() syscall returns is the same as the one that PIR was read on. Do you mean you're expecting this to be run from inside a partition that runs only on one CPU, and thus whichever thread you'll be migrated to will have the other data remain the same? This will be used from a partition with a dedicated set of cpus and so the data will remain consistent. I think this calls for a CPU_FTR_PIR. What do you suggest? Unless someone wants to test what actually happens when you read PIR on all these CPUs... What platform is this meant to be useful for? Perhaps it could just be a platform-specific sysfs entry? Currently I only care about pseries and have tested the following patch on them. I've therefore made the code similar to what currently exists for other features unique to POWER. Ananth --- From: Ananth N Mavinakayanahalli ana...@in.ibm.com 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. Signed-off-by: Ananth N Mavinakayanahalli ana...@in.ibm.com --- 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_PIRLONG_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 |
RE: [PATCH v2 1/5] [ppc] Process dynamic relocations for kernel
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). Maybe clean_dcache_range() itself should limit the range to the size of the cache? I suspect that code can easily know the cache size. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v4 00/10] fadump: Firmware-assisted dump support for Powerpc.
Hi, Mahesh, Could you please also add ke...@lists.infradead.org and Vivek into your Cc list when you send your patchset next time? 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月07日 17:55, Mahesh J Salgaonkar 写道: From: Mahesh Salgaonkarmah...@linux.vnet.ibm.com 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 Salgaonkarmah...@linux.vnet.ibm.com Please Cc Randy Dunlap rdun...@xenotime.net 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
Re: [RFC PATCH v4 02/10] fadump: Reserve the memory for firmware assisted dump.
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 05/10] fadump: Convert firmware-assisted cpu state dump data into elf notes.
于 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 10/10] fadump: Introduce config option for firmware assisted dump feature
于 2011年11月07日 17:56, Mahesh J Salgaonkar 写道: From: Mahesh Salgaonkarmah...@linux.vnet.ibm.com 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 06/10] fadump: Add PT_NOTE program header for vmcoreinfo
于 2011年11月07日 17:56, Mahesh J Salgaonkar 写道:
From: Mahesh Salgaonkarmah...@linux.vnet.ibm.com
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 Salgaonkarmah...@linux.vnet.ibm.com
---
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 01/10] fadump: Add documentation for firmware-assisted dump.
On 2011-11-10 17:46:30 Thu, Cong Wang wrote: 于 2011年11月07日 17:55, Mahesh J Salgaonkar 写道: From: Mahesh Salgaonkarmah...@linux.vnet.ibm.com 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 Salgaonkarmah...@linux.vnet.ibm.com Please Cc Randy Dunlap rdun...@xenotime.net 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 02/10] fadump: Reserve the memory for firmware assisted dump.
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
right way to get interrupt controller register
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: [PATCH 3/5] treewide: Remove useless NORET_TYPE macro and uses
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 r...@linux-mips.org Ralf ___ 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
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 j...@perches.com --- 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 r...@linux-mips.org Ralf ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 01/17] powerpc/mpic: Fix bogus CONFIG_BOOKE conditional
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 kyle.d.moff...@boeing.com
---
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: [RFC PATCH 02/17] powerpc: Split up PHYS_64BIT config option to fix select issues
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 selected 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 kyle.d.moff...@boeing.com --- 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_MPC8XXX diff --git a/arch/powerpc/platforms/86xx/Kconfig b/arch/powerpc/platforms/86xx/Kconfig index 8d6599d..576eb43 100644 ---
Re: [RFC PATCH 04/17] powerpc: Allow multiple machine-check handlers
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 kyle.d.moff...@boeing.com
---
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 08/17] powerpc/e500: Remove conditional lwsync substitution
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 kyle.d.moff...@boeing.com --- 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 13/17] powerpc/e500: Add a new CONFIG_FSL_E5500 option for the e5500
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 kyle.d.moff...@boeing.com --- 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 00/17] powerpc/e500: separate e500 from e500mc
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 02/17] powerpc: Split up PHYS_64BIT config option to fix select issues
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
[PATCH 02/11] powerpc/85xx: Simplify P1020RDB CAMP dts using includes
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 ga...@kernel.crashing.org
---
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
- since U-Boot doesn't clear the status property
[PATCH 01/11] powerpc/85xx: Add 'fsl, pq3-gpio' compatiable for GPIO driver
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 ga...@kernel.crashing.org
---
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 03/11] powerpc/85xx: Rework PCI nodes on P1020RDB
* 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 ga...@kernel.crashing.org
---
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
+ 0x0 0x0 0x2 mpic 0x1 0x1
+
[PATCH 04/11] powerpc/85xx: Update SPI binding to match binding spec for P1020RDB
The SPI node is out of date with regards to the binding for fsl-espi and
driver support.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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 05/11] powerpc/85xx: Update P1020 SEC3.3 node to match actual SoC HW
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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 07/11] powerpc/85xx: p1020si.dtsi update interrupt handling
* 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 ga...@kernel.crashing.org
---
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 = 21 2;
+ interrupts = 21 2 0 0;
};
dma-channel@100 {
[PATCH 06/11] powerpc/85xx: Add ethernet magic packet property to P1020 device tree
All eTSEC2 controllers support waking on magic packet so fixup device tree to report that. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- 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 09/11] powerpc/85xx: Rework P1020 SoC device tree
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 ga...@kernel.crashing.org
---
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;// Filled out by uboot.
+
+ ecm-law@0 {
+ compatible =
[PATCH 08/11] powerpc/85xx: create dts components to build up an SoC
Introduce some common components that we can utilize to build up the
various PQ3/85xx device trees.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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;
+ reg = 0x180
[PATCH 11/11] powerpc/85xx: Add P1020RDB 36-bit address map device tree
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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 10/11] powerpc/85xx: Rework P1020RDB device tree
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 ga...@kernel.crashing.org
---
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;
- };
-
-
[RFC][PATCH 00/30] Rework FSL MPC85xx/Pxxxx device trees
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
[RFC][PATCH 01/30] powerpc/85xx: Simplify P1020RDB CAMP dts using includes
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 ga...@kernel.crashing.org
---
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
- since U-Boot doesn't clear the status property
[RFC][PATCH 02/30] powerpc/85xx: Rework PCI nodes on P1020RDB
* 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 ga...@kernel.crashing.org
---
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
+ 0x0 0x0 0x2 mpic 0x1 0x1
+
[RFC][PATCH 03/30] powerpc/85xx: Update SPI binding to match binding spec for P1020RDB
The SPI node is out of date with regards to the binding for fsl-espi and
driver support.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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 04/30] powerpc/85xx: Update P1020 SEC3.3 node to match actual SoC HW
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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 05/30] powerpc/85xx: Add ethernet magic packet property to P1020 device tree
All eTSEC2 controllers support waking on magic packet so fixup device tree to report that. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- 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 06/30] powerpc/85xx: p1020si.dtsi update interrupt handling
* 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 ga...@kernel.crashing.org
---
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 = 21 2;
+ interrupts = 21 2 0 0;
};
dma-channel@100 {
[RFC][PATCH 08/30] powerpc/85xx: Rework P1020 SoC device tree
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 ga...@kernel.crashing.org
---
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
+ ;
+ };
+};
+
+soc {
+ #address-cells = 1;
+
[RFC][PATCH 09/30] powerpc/85xx: Rework P1020RDB device tree
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 ga...@kernel.crashing.org
---
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-only;
- };
-
-
[RFC][PATCH 10/30] powerpc/85xx: Add P1020RDB 36-bit address map device tree
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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 11/30] powerpc/85xx: Rework P1010RDB and P1010 device tree
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 ga...@kernel.crashing.org
---
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 */
+ 0x0 0x0 0x1 mpic 0x0 0x1 0x0 0x0
+
[RFC][PATCH 12/30] powerpc/85xx: Add RTC to P1010RDB device tree
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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 13/30] powerpc/85xx: Add crypto engine to P1010 SoC device tree
Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- 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 14/30] powerpc/85xx: Add a P1010RDB 36-bit address map device tree
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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 15/30] powerpc/85xx: Rework P1022DS device tree
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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-cells = 3;
+ device_type = pci;
+ interrupts = 16 2 0
[RFC][PATCH 16/30] powerpc/85xx: Rework P2020DS device tree
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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 = ;
+ interrupts = 24 2 0 0;
+
+ pcie@0 {
+
[RFC][PATCH 17/30] powerpc/85xx: Rework P2020RDB device tree
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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 =
- /* IDSEL 0x0 */
- 0x0 0x0 0x1 mpic 0x0 0x1
-
[RFC][PATCH 18/30] powerpc/85xx: Rework P1021MDS device tree
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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 = fsl,p1021-ecm, fsl,ecm;
+ reg = 0x1000 0x1000;
+
[RFC][PATCH 20/30] powerpc/85xx: Rework MPC8536DS device trees
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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 0x3 0x1 0x0 0x0
+ ;
+ };
+};
+
+/*
[RFC][PATCH 21/30] powerpc/85xx: Rework MPC8544DS device tree
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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
+ ;
+ };
+};
+
+/* controller at 0xb000 */
+pci3 {
+ compatible = fsl,mpc8548-pcie;
+
[RFC][PATCH 22/30] powerpc/85xx: Rework MPC8548CDS device trees
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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
+/include/ pq3-duart-0.dtsi
+
+ L2: l2-cache-controller@2 {
+ compatible =
[RFC][PATCH 23/30] powerpc/85xx: Rework P4080DS device trees
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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;
+ #address-cells = 3;
+ device_type = pci;
+ interrupts =
[RFC][PATCH 24/30] powerpc/85xx: Rework P5020DS device tree
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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-cells = 1;
+ #size-cells = 2;
+ #address-cells = 3;
+
[RFC][PATCH 25/30] powerpc/85xx: Rework P3041DS device tree
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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 = 1;
+ #size-cells = 2;
+ #address-cells = 3;
+
[RFC][PATCH 26/30] powerpc/85xx: Rework P2041RDB device tree
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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 = pci;
+ interrupts = 16 2 1 13;
+ interrupt-map-mask =
[RFC][PATCH 27/30] powerpc/85xx: Rework P3060QDS device tree
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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;
+ #size-cells = 2;
+ cell-index = 2;
+ };
+};
[RFC][PATCH 28/30] powerpc/85xx: Rework P1023RDS device tree
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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 = pci;
+ interrupts = 16 2 0 0;
+ interrupt-map-mask =
[RFC][PATCH 29/30] powerpc/85xx: Rework MPC8568MDS device tree
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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 {
+ compatible = fsl,mpc8568-ecm, fsl,ecm;
+ reg =
[RFC][PATCH 30/30] powerpc/85xx: Rework MPC8569MDS device tree
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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 {
+ #address-cells = 1;
+ #size-cells = 1;
+
Re: [PATCH 01/11] powerpc/85xx: Add 'fsl, pq3-gpio' compatiable for GPIO driver
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
Re: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc
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 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!
Re: [RFC PATCH 08/17] powerpc/e500: Remove conditional lwsync substitution
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 kyle.d.moff...@boeing.com --- 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 02/17] powerpc: Split up PHYS_64BIT config option to fix select issues
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 04/17] powerpc: Allow multiple machine-check handlers
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 08/17] powerpc/e500: Remove conditional lwsync substitution
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 kyle.d.moff...@boeing.com --- 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 16/17] powerpc/e500: Make __setup_cpu_{e200,e500,e500mc,e5500} optional
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 kyle.d.moff...@boeing.com --- 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 asm/cputable.h #include asm/ppc_asm.h +#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 13/17] powerpc/e500: Add a new CONFIG_FSL_E5500 option for the e5500
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 02/17] powerpc: Split up PHYS_64BIT config option to fix select issues
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 00/17] powerpc/e500: separate e500 from e500mc
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 08/17] powerpc/e500: Remove conditional lwsync substitution
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: [PATCH] powerpc/kvm: fix build with older toolchains
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 Aravamudann...@us.ibm.com 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: [PATCH] powerpc/kvm: annotate kvm_rma_init as __init
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 Aravamudann...@us.ibm.com
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: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc
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: [RFC PATCH 14/17] powerpc/e500: Don't make kgdb use e500v1/e500v2 registers on e500mc
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 15/30] powerpc/85xx: Rework P1022DS device tree
On Thu, Nov 10, 2011 at 10:13 AM, Kumar Gala ga...@kernel.crashing.org 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 08/30] powerpc/85xx: Rework P1020 SoC device tree
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 28/30] powerpc/85xx: Rework P1023RDS device tree
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 28/30] powerpc/85xx: Rework P1023RDS device tree
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 08/30] powerpc/85xx: Rework P1020 SoC device tree
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 15/30] powerpc/85xx: Rework P1022DS device tree
On Nov 10, 2011, at 11:30 AM, Tabi Timur-B04825 wrote: On Thu, Nov 10, 2011 at 10:13 AM, Kumar Gala ga...@kernel.crashing.org 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 16/17] powerpc/e500: Make __setup_cpu_{e200, e500, e500mc, e5500} optional
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 kyle.d.moff...@boeing.com --- 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 asm/cputable.h #include asm/ppc_asm.h +#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 28/30] powerpc/85xx: Rework P1023RDS device tree
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 08/30] powerpc/85xx: Rework P1020 SoC device tree
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
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
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 08/17] powerpc/e500: Remove conditional lwsync substitution
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/17] powerpc/e500: Remove conditional lwsync substitution
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: [PATCH v2 1/5] [ppc] Process dynamic relocations for kernel
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 00/17] powerpc/e500: separate e500 from e500mc
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
[PATCH] powerpc kvm: fix kvmppc_start_thread() for CONFIG_SMP=N
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 mi...@neuling.org
---
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: [PATCH 4/5] treewide: Convert uses of ATTRIB_NORETURN to __noreturn
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 j...@perches.com --- 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 let...@linux-sh.org ___ 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
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 ME,CE 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 kexin@windriver.com --- 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 v2 1/5] [ppc] Process dynamic relocations for kernel
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
Re: [PATCH] powerpc: Export PIR data through sysfs
On Thu, 2011-11-10 at 14:18 +0530, Ananth N Mavinakayanahalli wrote: From: Ananth N Mavinakayanahalli ana...@in.ibm.com 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 ana...@in.ibm.com --- 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); ___ Linuxppc-dev mailing list
Re: [PATCH v3 1/3] virtio_console: Fix locking of vtermno.
On Tue, 08 Nov 2011 13:44:58 -0800, Miche Baker-Harvey mi...@google.com 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 mi...@google.com 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: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc
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: [RFC PATCH 08/17] powerpc/e500: Remove conditional lwsync substitution
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 08/17] powerpc/e500: Remove conditional lwsync substitution
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: [PATCH] powerpc: Export PIR data through sysfs
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 ana...@in.ibm.com 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
