* Re: Questions on interrupt vector assignment on MPC8641D
From: Scott Wood @ 2010-10-07 20:26 UTC (permalink / raw)
To: david.hagood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <fe4c3e4086132d746b79670f236302f1.squirrel@localhost>
On Thu, 7 Oct 2010 15:12:26 -0500
<david.hagood@gmail.com> wrote:
> > On Tue, 21 Sep 2010 17:37:15 -0400
> > The MPIC interrupt numberspace in the device tree (which is not
> > virtual; it is a private numberspace to MPIC) is based on the offset of
> > the registers for that interrupt source. External interrupts start at
> > zero (which is valid), internal at 16, and special things like MSIs at
> > higher numbers (I don't think it's quite 256).
>
> OK, so I'm slowly wrapping my head around this (OT: Has anybody considered
> sending this information to the folks doing the Linux Device Drivers
> books? They are just a bit x86 centric right now...).
>
> As I understand, what I have to do is somehow get a device_node *, then
> make a call to irq_of_parse_and_map() to convert that into a system IRQ.
>
> What I am doing right now is:
> device_node *mpic = of_find_node_by_type(0,"open-pic");
> irq = irq_of_parse_and_map(mpic,256);
This is asking for the 256th specifier in the interrupts property in
the mpic node -- not what you want.
Ideally you would have a node for your device with an interrupt
specifier that you could look up with irq_of_parse_and_map(). But if
not, you can use irq_create_mapping() to directly convert an MPIC IRQ
number to a virtual IRQ.
What interrupt are you trying to select with 256? That doesn't look
like a valid MPIC interrupt number.
> 2) How do I know for certain that 256 is the right value for the first MSI
> signaled via MSIR0?
It isn't. The vector/priority register (MSIVPR0) is at offset
0x51c00. Each interrupt source is 32 bytes. The first interrupt
source is at 0x50000.
So the interrupt number is (0x51c00 - 0x50000) / 32 = 224.
BTW, the MSIs are already described in an msi node in the device tree.
Are you trying to do something different with them than PCI MSIs? If
not, is the existing MSI driver not working? If you are trying to do
something different, you should bind to that node yourself and use
irq_of_parse_and_map() on it.
-Scott
^ permalink raw reply
* Re: Questions on interrupt vector assignment on MPC8641D
From: david.hagood @ 2010-10-07 20:12 UTC (permalink / raw)
To: Scott Wood; +Cc: david.hagood@gmail.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20100921170700.53a99e56@udp111988uds.am.freescale.net>
> On Tue, 21 Sep 2010 17:37:15 -0400
> The MPIC interrupt numberspace in the device tree (which is not
> virtual; it is a private numberspace to MPIC) is based on the offset of
> the registers for that interrupt source. External interrupts start at
> zero (which is valid), internal at 16, and special things like MSIs at
> higher numbers (I don't think it's quite 256).
OK, so I'm slowly wrapping my head around this (OT: Has anybody considered
sending this information to the folks doing the Linux Device Drivers
books? They are just a bit x86 centric right now...).
As I understand, what I have to do is somehow get a device_node *, then
make a call to irq_of_parse_and_map() to convert that into a system IRQ.
What I am doing right now is:
device_node *mpic = of_find_node_by_type(0,"open-pic");
irq = irq_of_parse_and_map(mpic,256);
While I get a pointer from of_find_node_by_type, when I try to map IRQ
#256 via the irq_of_parse_and_map function, I get a zero back from it.
So I guess my questions would be:
1) should I be frobbing the PIC for this, or should I be looking up some
other device?
2) How do I know for certain that 256 is the right value for the first MSI
signaled via MSIR0?
^ permalink raw reply
* [PATCH 1/3] Powerpc/4xx: Add suspend and idle support
From: Victor Gallardo @ 2010-10-07 19:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Victor Gallardo
Add suspend/resume support for all 4xx compatible CPUs.
See /sys/power/state for available power states configured in.
Add two different idle states (idle-wait and idle-doze)
controlled via sysfs. Default is idle-wait.
cat /sys/devices/system/cpu/cpu0/idle
[wait] doze
To save additional power, use idle-doze.
echo doze > /sys/devices/system/cpu/cpu0/idle
cat /sys/devices/system/cpu/cpu0/idle
wait [doze]
Signed-off-by: Victor Gallardo <vgallardo@apm.com>
---
Documentation/powerpc/dts-bindings/4xx/cpm.txt | 43 +++
arch/powerpc/Kconfig | 13 +-
arch/powerpc/platforms/44x/Makefile | 5 +-
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/ppc4xx_cpm.c | 339 ++++++++++++++++++++++++
5 files changed, 397 insertions(+), 4 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/4xx/cpm.txt
create mode 100644 arch/powerpc/sysdev/ppc4xx_cpm.c
diff --git a/Documentation/powerpc/dts-bindings/4xx/cpm.txt b/Documentation/powerpc/dts-bindings/4xx/cpm.txt
new file mode 100644
index 0000000..9635df8
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/4xx/cpm.txt
@@ -0,0 +1,43 @@
+PPC4xx Clock Power Management (CPM) node
+
+Required properties:
+ - compatible : compatible list, currently only "ibm,cpm"
+ - dcr-access-method : "native"
+ - dcr-reg : < DCR register range >
+
+Optional properties:
+ - er-offset : All 4xx SoCs with a CPM controller have
+ one of two different order for the CPM
+ registers. Some have the CPM registers
+ in the following order (ER,FR,SR). The
+ others have them in the following order
+ (SR,ER,FR). For the second case set
+ er-offset = <1>.
+ - unused-units : specifier consist of one cell. For each
+ bit in the cell, the corresponding bit
+ in CPM will be set to turn off unused
+ devices.
+ - idle-doze : specifier consist of one cell. For each
+ bit in the cell, the corresponding bit
+ in CPM will be set to turn off unused
+ devices. This is usually just CPM[CPU].
+ - standby : specifier consist of one cell. For each
+ bit in the cell, the corresponding bit
+ in CPM will be set on standby and
+ restored on resume.
+ - suspend : specifier consist of one cell. For each
+ bit in the cell, the corresponding bit
+ in CPM will be set on suspend (mem) and
+ restored on resume.
+
+Example:
+ CPM0: cpm {
+ compatible = "ibm,cpm";
+ dcr-access-method = "native";
+ dcr-reg = <0x160 0x003>;
+ er-offset = <0>;
+ unused-units = <0x00000100>;
+ idle-doze = <0x02000000>;
+ standby = <0xfeff0000>;
+ standby = <0xfeff791d>;
+ };
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 631e5a0..10b2f15 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -210,7 +210,7 @@ config ARCH_HIBERNATION_POSSIBLE
config ARCH_SUSPEND_POSSIBLE
def_bool y
depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx || \
- PPC_85xx || PPC_86xx || PPC_PSERIES
+ PPC_85xx || PPC_86xx || PPC_PSERIES || 44x || 40x
config PPC_DCR_NATIVE
bool
@@ -596,13 +596,11 @@ config EXTRA_TARGETS
If unsure, leave blank
-if !44x || BROKEN
config ARCH_WANTS_FREEZER_CONTROL
def_bool y
depends on ADB_PMU
source kernel/power/Kconfig
-endif
config SECCOMP
bool "Enable seccomp to safely compute untrusted bytecode"
@@ -683,6 +681,15 @@ config FSL_PMC
Freescale MPC85xx/MPC86xx power management controller support
(suspend/resume). For MPC83xx see platforms/83xx/suspend.c
+config PPC4xx_CPM
+ bool
+ default y
+ depends on SUSPEND && (44x || 40x)
+ help
+ PPC4xx Clock Power Management (CPM) support (suspend/resume).
+ It also enables support for two different idle states (idle-wait
+ and idle-doze).
+
config 4xx_SOC
bool
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index 82ff326..c04d16d 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -1,4 +1,7 @@
-obj-$(CONFIG_44x) := misc_44x.o idle.o
+obj-$(CONFIG_44x) += misc_44x.o
+ifneq ($(CONFIG_PPC4xx_CPM),y)
+obj-$(CONFIG_44x) += idle.o
+endif
obj-$(CONFIG_PPC44x_SIMPLE) += ppc44x_simple.o
obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 5642924..a9728d1 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_OF_RTC) += of_rtc.o
ifeq ($(CONFIG_PCI),y)
obj-$(CONFIG_4xx) += ppc4xx_pci.o
endif
+obj-$(CONFIG_PPC4xx_CPM) += ppc4xx_cpm.o
obj-$(CONFIG_PPC4xx_GPIO) += ppc4xx_gpio.o
obj-$(CONFIG_CPM) += cpm_common.o
diff --git a/arch/powerpc/sysdev/ppc4xx_cpm.c b/arch/powerpc/sysdev/ppc4xx_cpm.c
new file mode 100644
index 0000000..d47a7ed
--- /dev/null
+++ b/arch/powerpc/sysdev/ppc4xx_cpm.c
@@ -0,0 +1,339 @@
+/*
+ * PowerPC 4xx Clock and Power Management
+ *
+ * Copyright (C) 2010, Applied Micro Circuits Corporation
+ * Victor Gallardo (vgallardo@apm.com)
+ *
+ * Based on arch/powerpc/platforms/44x/idle.c:
+ * Jerone Young <jyoung5@us.ibm.com>
+ * Copyright 2008 IBM Corp.
+ *
+ * Based on arch/powerpc/sysdev/fsl_pmc.c:
+ * Anton Vorontsov <avorontsov@ru.mvista.com>
+ * Copyright 2009 MontaVista Software, Inc.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <linux/kernel.h>
+#include <linux/of_platform.h>
+#include <linux/sysfs.h>
+#include <linux/cpu.h>
+#include <linux/suspend.h>
+#include <asm/dcr.h>
+#include <asm/dcr-native.h>
+#include <asm/machdep.h>
+
+#define CPM_ER 0
+#define CPM_FR 1
+#define CPM_SR 2
+
+#define CPM_IDLE_WAIT 0
+#define CPM_IDLE_DOZE 1
+
+struct cpm {
+ dcr_host_t dcr_host;
+ unsigned int dcr_offset[3];
+ unsigned int powersave_off;
+ unsigned int unused;
+ unsigned int idle_doze;
+ unsigned int standby;
+ unsigned int suspend;
+};
+
+static struct cpm cpm;
+
+struct cpm_idle_mode {
+ unsigned int enabled;
+ const char *name;
+};
+
+static struct cpm_idle_mode idle_mode[] = {
+ [CPM_IDLE_WAIT] = { 1, "wait" }, /* default */
+ [CPM_IDLE_DOZE] = { 0, "doze" },
+};
+
+static void cpm_set(unsigned int cpm_reg, unsigned int mask)
+{
+ unsigned int value;
+
+ value = dcr_read(cpm.dcr_host, cpm.dcr_offset[cpm_reg]);
+ value |= mask;
+ dcr_write(cpm.dcr_host, cpm.dcr_offset[cpm_reg], value);
+}
+
+static void cpm_idle_wait(void)
+{
+ unsigned long msr_save;
+
+ /* save off initial state */
+ msr_save = mfmsr();
+ /* sync required when CPM0_ER[CPU] is set */
+ mb();
+ /* set wait state MSR */
+ mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE|MSR_DE);
+ isync();
+ /* return to initial state */
+ mtmsr(msr_save);
+ isync();
+}
+
+static void cpm_idle_sleep(unsigned int mask)
+{
+ unsigned int er_save;
+
+ /* update CPM_ER state */
+ er_save = dcr_read(cpm.dcr_host, cpm.dcr_offset[CPM_ER]);
+ dcr_write(cpm.dcr_host, cpm.dcr_offset[CPM_ER],
+ er_save | mask);
+
+ /* go to wait state */
+ cpm_idle_wait();
+
+ /* restore CPM_ER state */
+ dcr_write(cpm.dcr_host, cpm.dcr_offset[CPM_ER], er_save);
+}
+
+static void cpm_idle_doze(void)
+{
+ cpm_idle_sleep(cpm.idle_doze);
+}
+
+static void cpm_idle_config(int mode)
+{
+ int i;
+
+ if (idle_mode[mode].enabled)
+ return;
+
+ for (i = 0; i < ARRAY_SIZE(idle_mode); i++)
+ idle_mode[i].enabled = 0;
+
+ idle_mode[mode].enabled = 1;
+}
+
+static ssize_t cpm_idle_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ char *s = buf;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(idle_mode); i++) {
+ if (idle_mode[i].enabled)
+ s += sprintf(s, "[%s] ", idle_mode[i].name);
+ else
+ s += sprintf(s, "%s ", idle_mode[i].name);
+ }
+
+ *(s-1) = '\n'; /* convert the last space to a newline */
+
+ return s - buf;
+}
+
+static ssize_t cpm_idle_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t n)
+{
+ int i;
+ char *p;
+ int len;
+
+ p = memchr(buf, '\n', n);
+ len = p ? p - buf : n;
+
+ for (i = 0; i < ARRAY_SIZE(idle_mode); i++) {
+ if (strncmp(buf, idle_mode[i].name, len) == 0) {
+ cpm_idle_config(i);
+ return n;
+ }
+ }
+
+ return -EINVAL;
+}
+
+static struct kobj_attribute cpm_idle_attr =
+ __ATTR(idle, 0644, cpm_idle_show, cpm_idle_store);
+
+static void cpm_idle_config_sysfs(void)
+{
+ struct sys_device *sys_dev;
+ unsigned long ret;
+
+ sys_dev = get_cpu_sysdev(0);
+
+ ret = sysfs_create_file(&sys_dev->kobj,
+ &cpm_idle_attr.attr);
+ if (ret)
+ printk(KERN_WARNING
+ "cpm: failed to create idle sysfs entry\n");
+}
+
+static void cpm_idle(void)
+{
+ if (idle_mode[CPM_IDLE_DOZE].enabled)
+ cpm_idle_doze();
+ else
+ cpm_idle_wait();
+}
+
+static int cpm_suspend_valid(suspend_state_t state)
+{
+ switch (state) {
+ case PM_SUSPEND_STANDBY:
+ return !!cpm.standby;
+ case PM_SUSPEND_MEM:
+ return !!cpm.suspend;
+ default:
+ return 0;
+ }
+}
+
+static void cpm_suspend_standby(unsigned int mask)
+{
+ unsigned long tcr_save;
+
+ /* disable decrement interrupt */
+ tcr_save = mfspr(SPRN_TCR);
+ mtspr(SPRN_TCR, tcr_save & ~TCR_DIE);
+
+ /* go to sleep state */
+ cpm_idle_sleep(mask);
+
+ /* restore decrement interrupt */
+ mtspr(SPRN_TCR, tcr_save);
+}
+
+static int cpm_suspend_enter(suspend_state_t state)
+{
+ switch (state) {
+ case PM_SUSPEND_STANDBY:
+ cpm_suspend_standby(cpm.standby);
+ break;
+ case PM_SUSPEND_MEM:
+ cpm_suspend_standby(cpm.suspend);
+ break;
+ }
+
+ return 0;
+}
+
+static struct platform_suspend_ops cpm_suspend_ops = {
+ .valid = cpm_suspend_valid,
+ .enter = cpm_suspend_enter,
+};
+
+static int cpm_get_uint_property(struct device_node *np,
+ const char *name)
+{
+ int len;
+ const unsigned int *prop = of_get_property(np, name, &len);
+
+ if (prop == NULL || len < sizeof(u32))
+ return 0;
+
+ return *prop;
+}
+
+static int __init cpm_init(void)
+{
+ struct device_node *np;
+ int dcr_base, dcr_len;
+ int ret = 0;
+
+ if (!cpm.powersave_off) {
+ cpm_idle_config(CPM_IDLE_WAIT);
+ ppc_md.power_save = &cpm_idle;
+ }
+
+ np = of_find_compatible_node(NULL, NULL, "ibm,cpm");
+ if (!np) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ dcr_base = dcr_resource_start(np, 0);
+ dcr_len = dcr_resource_len(np, 0);
+
+ if (dcr_base == 0 || dcr_len == 0) {
+ printk(KERN_ERR "cpm: could not parse dcr property for %s\n",
+ np->full_name);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ cpm.dcr_host = dcr_map(np, dcr_base, dcr_len);
+
+ if (!DCR_MAP_OK(cpm.dcr_host)) {
+ printk(KERN_ERR "cpm: failed to map dcr property for %s\n",
+ np->full_name);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ /* All 4xx SoCs with a CPM controller have one of two
+ * different order for the CPM registers. Some have the
+ * CPM registers in the following order (ER,FR,SR). The
+ * others have them in the following order (SR,ER,FR).
+ */
+
+ if (cpm_get_uint_property(np, "er-offset") == 0) {
+ cpm.dcr_offset[CPM_ER] = 0;
+ cpm.dcr_offset[CPM_FR] = 1;
+ cpm.dcr_offset[CPM_SR] = 2;
+ } else {
+ cpm.dcr_offset[CPM_ER] = 1;
+ cpm.dcr_offset[CPM_FR] = 2;
+ cpm.dcr_offset[CPM_SR] = 0;
+ }
+
+ /* Now let's see what IPs to turn off for the following modes */
+
+ cpm.unused = cpm_get_uint_property(np, "unused-units");
+ cpm.idle_doze = cpm_get_uint_property(np, "idle-doze");
+ cpm.standby = cpm_get_uint_property(np, "standby");
+ cpm.suspend = cpm_get_uint_property(np, "suspend");
+
+ /* If some IPs are unused let's turn them off now */
+
+ if (cpm.unused) {
+ cpm_set(CPM_ER, cpm.unused);
+ cpm_set(CPM_FR, cpm.unused);
+ }
+
+ /* Now let's export interfaces */
+
+ if (!cpm.powersave_off && cpm.idle_doze)
+ cpm_idle_config_sysfs();
+
+ if (cpm.standby || cpm.suspend)
+ suspend_set_ops(&cpm_suspend_ops);
+out:
+ if (np)
+ of_node_put(np);
+ return ret;
+}
+
+late_initcall(cpm_init);
+
+static int __init cpm_powersave_off(char *arg)
+{
+ cpm.powersave_off = 1;
+ return 0;
+}
+__setup("powersave=off", cpm_powersave_off);
--
1.6.1.rc3
^ permalink raw reply related
* [PATCH 2/3] powerpc/4xx: Add Canyonlands suspend and idle support
From: Victor Gallardo @ 2010-10-07 19:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Victor Gallardo
- Add Clock Power Management (CPM) node to dts tree
- Add idle-doze entry in CPM node
- Add standby entry in CPM node
- Add PM and SUSPEND support by default in defconfig
- Remove UART2 and UART3 as they are unused, this will
CPM to put unused-units (UART2 and UART3) to sleep.
Signed-off-by: Victor Gallardo <vgallardo@apm.com>
---
arch/powerpc/boot/dts/canyonlands.dts | 31 +++++++-----------------
arch/powerpc/configs/44x/canyonlands_defconfig | 3 ++
2 files changed, 12 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
index a303703..5b27a4b 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -105,6 +105,15 @@
dcr-reg = <0x00c 0x002>;
};
+ CPM0: cpm {
+ compatible = "ibm,cpm";
+ dcr-access-method = "native";
+ dcr-reg = <0x160 0x003>;
+ unused-units = <0x00000100>;
+ idle-doze = <0x02000000>;
+ standby = <0xfeff791d>;
+ };
+
L2C0: l2c {
compatible = "ibm,l2-cache-460ex", "ibm,l2-cache";
dcr-reg = <0x020 0x008 /* Internal SRAM DCR's */
@@ -270,28 +279,6 @@
interrupts = <0x1 0x4>;
};
- UART2: serial@ef600500 {
- device_type = "serial";
- compatible = "ns16550";
- reg = <0xef600500 0x00000008>;
- virtual-reg = <0xef600500>;
- clock-frequency = <0>; /* Filled in by U-Boot */
- current-speed = <0>; /* Filled in by U-Boot */
- interrupt-parent = <&UIC1>;
- interrupts = <28 0x4>;
- };
-
- UART3: serial@ef600600 {
- device_type = "serial";
- compatible = "ns16550";
- reg = <0xef600600 0x00000008>;
- virtual-reg = <0xef600600>;
- clock-frequency = <0>; /* Filled in by U-Boot */
- current-speed = <0>; /* Filled in by U-Boot */
- interrupt-parent = <&UIC1>;
- interrupts = <29 0x4>;
- };
-
IIC0: i2c@ef600700 {
compatible = "ibm,iic-460ex", "ibm,iic";
reg = <0xef600700 0x00000014>;
diff --git a/arch/powerpc/configs/44x/canyonlands_defconfig b/arch/powerpc/configs/44x/canyonlands_defconfig
index 45c64d8..17e4dd9 100644
--- a/arch/powerpc/configs/44x/canyonlands_defconfig
+++ b/arch/powerpc/configs/44x/canyonlands_defconfig
@@ -42,6 +42,9 @@ CONFIG_MTD_PHYSMAP_OF=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_NDFC=y
CONFIG_PROC_DEVICETREE=y
+CONFIG_PM=y
+CONFIG_SUSPEND=y
+CONFIG_PPC4xx_CPM=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=35000
# CONFIG_MISC_DEVICES is not set
--
1.6.1.rc3
^ permalink raw reply related
* [PATCH 3/3] powerpc/4xx: Add Kilauea suspend and idle support
From: Victor Gallardo @ 2010-10-07 19:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Victor Gallardo
- Add Clock Power Management (CPM) node to dts tree
- Add idle-doze entry in CPM node
- Add standby entry in CPM node
- Add PM and SUSPEND support by default in defconfig
- Add NO_HZ and CONFIG_HIGH_RES_TIMERS support by
default in defconfig
Signed-off-by: Victor Gallardo <vgallardo@apm.com>
---
arch/powerpc/boot/dts/kilauea.dts | 9 +++++++++
arch/powerpc/configs/40x/kilauea_defconfig | 5 +++++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/kilauea.dts b/arch/powerpc/boot/dts/kilauea.dts
index 083e68e..89edb16 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -82,6 +82,15 @@
interrupt-parent = <&UIC0>;
};
+ CPM0: cpm {
+ compatible = "ibm,cpm";
+ dcr-access-method = "native";
+ dcr-reg = <0x0b0 0x003>;
+ unused-units = <0x00000000>;
+ idle-doze = <0x02000000>;
+ standby = <0xe3e74800>;
+ };
+
plb {
compatible = "ibm,plb-405ex", "ibm,plb4";
#address-cells = <1>;
diff --git a/arch/powerpc/configs/40x/kilauea_defconfig b/arch/powerpc/configs/40x/kilauea_defconfig
index 4e19ee7..34b8c1a 100644
--- a/arch/powerpc/configs/40x/kilauea_defconfig
+++ b/arch/powerpc/configs/40x/kilauea_defconfig
@@ -12,6 +12,8 @@ CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_KILAUEA=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
# CONFIG_WALNUT is not set
CONFIG_SPARSE_IRQ=y
CONFIG_PCI=y
@@ -42,6 +44,9 @@ CONFIG_MTD_PHYSMAP_OF=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_NDFC=y
CONFIG_PROC_DEVICETREE=y
+CONFIG_PM=y
+CONFIG_SUSPEND=y
+CONFIG_PPC4xx_CPM=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=35000
# CONFIG_MISC_DEVICES is not set
--
1.6.1.rc3
^ permalink raw reply related
* [PATCH 1/2] [v2] powerpc/85xx: add ngPIXIS FPGA device tree node to the P1022DS board
From: Timur Tabi @ 2010-10-07 19:36 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
The device tree for Freescale's P1022DS reference board is missing the node
for the ngPIXIS FPGA.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/boot/dts/p1022ds.dts | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1022ds.dts b/arch/powerpc/boot/dts/p1022ds.dts
index 8bcb10b..2bbecbb 100644
--- a/arch/powerpc/boot/dts/p1022ds.dts
+++ b/arch/powerpc/boot/dts/p1022ds.dts
@@ -148,6 +148,17 @@
label = "reserved-nand";
};
};
+
+ board-control@3,0 {
+ compatible = "fsl,p1022ds-pixis";
+ reg = <3 0 0x30>;
+ interrupt-parent = <&mpic>;
+ /*
+ * IRQ8 is generated if the "EVENT" switch is pressed
+ * and PX_CTL[EVESEL] is set to 00.
+ */
+ interrupts = <8 8>;
+ };
};
soc@fffe00000 {
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/2] [v2] powerpc/85xx: add DIU support to the Freecale P1022DS reference board
From: Timur Tabi @ 2010-10-07 19:36 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
In-Reply-To: <1286480203-28227-1-git-send-email-timur@freescale.com>
The Freescale P1022DS has an on-chip video controller called the DIU, and a
driver for this device already exists. Update the platform file for the
P1022DS reference board to enable the driver, and update the defconfig for
Freescale MPC85xx boards to add the driver.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/configs/mpc85xx_defconfig | 3 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 3 +
arch/powerpc/platforms/85xx/p1022_ds.c | 213 +++++++++++++++++++++++++++-
3 files changed, 217 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
index c3b113b..3aeb594 100644
--- a/arch/powerpc/configs/mpc85xx_defconfig
+++ b/arch/powerpc/configs/mpc85xx_defconfig
@@ -124,6 +124,9 @@ CONFIG_I2C_CPM=m
CONFIG_I2C_MPC=y
# CONFIG_HWMON is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
+CONFIG_FB=y
+CONFIG_FB_FSL_DIU=y
+# CONFIG_VGA_CONSOLE is not set
CONFIG_SOUND=y
CONFIG_SND=y
# CONFIG_SND_SUPPORT_OLD_API is not set
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index a075da2..d62c801 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -126,6 +126,9 @@ CONFIG_I2C_CPM=m
CONFIG_I2C_MPC=y
# CONFIG_HWMON is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
+CONFIG_FB=y
+CONFIG_FB_FSL_DIU=y
+# CONFIG_VGA_CONSOLE is not set
CONFIG_SOUND=y
CONFIG_SND=y
# CONFIG_SND_SUPPORT_OLD_API is not set
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index 2b390d1..bee247d 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -8,7 +8,6 @@
* Copyright 2010 Freescale Semiconductor, Inc.
*
* This file is taken from the Freescale P1022DS BSP, with modifications:
- * 1) No DIU support (pending rewrite of DIU code)
* 2) No AMP support
* 3) No PCI endpoint support
*
@@ -17,15 +16,216 @@
* kind, whether express or implied.
*/
+#define DEBUG
+
#include <linux/pci.h>
#include <linux/of_platform.h>
#include <linux/memblock.h>
-
+#include <asm/div64.h>
#include <asm/mpic.h>
#include <asm/swiotlb.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
+#include <asm/fsl_guts.h>
+
+#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
+
+/*
+ * Board-specific initialization of the DIU. This code should probably be
+ * executed when the DIU is opened, rather than in arch code, but the DIU
+ * driver does not have a mechanism for this (yet).
+ *
+ * This is especially problematic on the P1022DS because the local bus (eLBC)
+ * and the DIU video signals share the same pins, which means that enabling the
+ * DIU will disable access to NOR flash.
+ */
+
+/* DIU Pixel Clock bits of the CLKDVDR Global Utilities register */
+#define CLKDVDR_PXCKEN 0x80000000
+#define CLKDVDR_PXCKINV 0x10000000
+#define CLKDVDR_PXCKDLY 0x06000000
+#define CLKDVDR_PXCLK_MASK 0x00FF0000
+
+/* Some ngPIXIS register definitions */
+#define PX_BRDCFG1_DVIEN 0x80
+#define PX_BRDCFG1_DFPEN 0x40
+#define PX_BRDCFG1_BACKLIGHT 0x20
+#define PX_BRDCFG1_DDCEN 0x10
+
+/*
+ * DIU Area Descriptor
+ *
+ * Note that we need to byte-swap the value before it's written to the AD
+ * register. So even though the registers don't look like they're in the same
+ * bit positions as they are on the MPC8610, the same value is written to the
+ * AD register on the MPC8610 and on the P1022.
+ */
+#define AD_BYTE_F 0x10000000
+#define AD_ALPHA_C_MASK 0x0E000000
+#define AD_ALPHA_C_SHIFT 25
+#define AD_BLUE_C_MASK 0x01800000
+#define AD_BLUE_C_SHIFT 23
+#define AD_GREEN_C_MASK 0x00600000
+#define AD_GREEN_C_SHIFT 21
+#define AD_RED_C_MASK 0x00180000
+#define AD_RED_C_SHIFT 19
+#define AD_PALETTE 0x00040000
+#define AD_PIXEL_S_MASK 0x00030000
+#define AD_PIXEL_S_SHIFT 16
+#define AD_COMP_3_MASK 0x0000F000
+#define AD_COMP_3_SHIFT 12
+#define AD_COMP_2_MASK 0x00000F00
+#define AD_COMP_2_SHIFT 8
+#define AD_COMP_1_MASK 0x000000F0
+#define AD_COMP_1_SHIFT 4
+#define AD_COMP_0_MASK 0x0000000F
+#define AD_COMP_0_SHIFT 0
+
+#define MAKE_AD(alpha, red, blue, green, size, c0, c1, c2, c3) \
+ cpu_to_le32(AD_BYTE_F | (alpha << AD_ALPHA_C_SHIFT) | \
+ (blue << AD_BLUE_C_SHIFT) | (green << AD_GREEN_C_SHIFT) | \
+ (red << AD_RED_C_SHIFT) | (c3 << AD_COMP_3_SHIFT) | \
+ (c2 << AD_COMP_2_SHIFT) | (c1 << AD_COMP_1_SHIFT) | \
+ (c0 << AD_COMP_0_SHIFT) | (size << AD_PIXEL_S_SHIFT))
+
+/**
+ * p1022ds_get_pixel_format: return the Area Descriptor for a given pixel depth
+ *
+ * The Area Descriptor is a 32-bit value that determine which bits in each
+ * pixel are to be used for each color.
+ */
+static unsigned int p1022ds_get_pixel_format(unsigned int bits_per_pixel,
+ int monitor_port)
+{
+ switch (bits_per_pixel) {
+ case 32:
+ /* 0x88883316 */
+ return MAKE_AD(3, 2, 0, 1, 3, 8, 8, 8, 8);
+ case 24:
+ /* 0x88082219 */
+ return MAKE_AD(4, 0, 1, 2, 2, 0, 8, 8, 8);
+ case 16:
+ /* 0x65053118 */
+ return MAKE_AD(4, 2, 1, 0, 1, 5, 6, 5, 0);
+ default:
+ pr_err("fsl-diu: unsupported pixel depth %u\n", bits_per_pixel);
+ return 0;
+ }
+}
+
+/**
+ * p1022ds_set_gamma_table: update the gamma table, if necessary
+ *
+ * On some boards, the gamma table for some ports may need to be modified.
+ * This is not the case on the P1022DS, so we do nothing.
+*/
+static void p1022ds_set_gamma_table(int monitor_port, char *gamma_table_base)
+{
+}
+
+/**
+ * p1022ds_set_monitor_port: switch the output to a different monitor port
+ *
+ */
+static void p1022ds_set_monitor_port(int monitor_port)
+{
+ struct device_node *pixis_node;
+ u8 __iomem *brdcfg1;
+
+ pixis_node = of_find_compatible_node(NULL, NULL, "fsl,p1022ds-pixis");
+ if (!pixis_node) {
+ pr_err("p1022ds: missing ngPIXIS node\n");
+ return;
+ }
+
+ brdcfg1 = of_iomap(pixis_node, 0);
+ if (!brdcfg1) {
+ pr_err("p1022ds: could not map ngPIXIS registers\n");
+ return;
+ }
+ brdcfg1 += 9; /* BRDCFG1 is at offset 9 in the ngPIXIS */
+
+ switch (monitor_port) {
+ case 0: /* DVI */
+ /* Enable the DVI port, disable the DFP and the backlight */
+ clrsetbits_8(brdcfg1, PX_BRDCFG1_DFPEN | PX_BRDCFG1_BACKLIGHT,
+ PX_BRDCFG1_DVIEN);
+ break;
+ case 1: /* Single link LVDS */
+ /* Enable the DFP port, disable the DVI and the backlight */
+ clrsetbits_8(brdcfg1, PX_BRDCFG1_DVIEN | PX_BRDCFG1_BACKLIGHT,
+ PX_BRDCFG1_DFPEN);
+ break;
+ default:
+ pr_err("p1022ds: unsupported monitor port %i\n", monitor_port);
+ }
+}
+
+/**
+ * p1022ds_set_pixel_clock: program the DIU's clock
+ *
+ * @pixclock: the wavelength, in picoseconds, of the clock
+ */
+void p1022ds_set_pixel_clock(unsigned int pixclock)
+{
+ struct device_node *guts_np = NULL;
+ struct ccsr_guts_85xx __iomem *guts;
+ unsigned long freq;
+ u64 temp;
+ u32 pxclk;
+
+ /* Map the global utilities registers. */
+ guts_np = of_find_compatible_node(NULL, NULL, "fsl,p1022-guts");
+ if (!guts_np) {
+ pr_err("p1022ds: missing global utilties device node\n");
+ return;
+ }
+
+ guts = of_iomap(guts_np, 0);
+ of_node_put(guts_np);
+ if (!guts) {
+ pr_err("p1022ds: could not map global utilties device\n");
+ return;
+ }
+
+ /* Convert pixclock from a wavelength to a frequency */
+ temp = 1000000000000ULL;
+ do_div(temp, pixclock);
+ freq = temp;
+
+ /* pixclk is the ratio of the platform clock to the pixel clock */
+ pxclk = DIV_ROUND_CLOSEST(fsl_get_sys_freq(), freq);
+
+ /* Disable the pixel clock, and set it to non-inverted and no delay */
+ clrbits32(&guts->clkdvdr,
+ CLKDVDR_PXCKEN | CLKDVDR_PXCKDLY | CLKDVDR_PXCLK_MASK);
+
+ /* Enable the clock and set the pxclk */
+ setbits32(&guts->clkdvdr, CLKDVDR_PXCKEN | (pxclk << 16));
+}
+
+/**
+ * p1022ds_show_monitor_port: show the current monitor
+ *
+ * This function returns a string indicating whether the current monitor is
+ * set to DVI or LVDS.
+ */
+ssize_t p1022ds_show_monitor_port(int monitor_port, char *buf)
+{
+ return sprintf(buf, "%c0 - DVI\n%c1 - Single link LVDS\n",
+ monitor_port == 0 ? '*' : ' ', monitor_port == 1 ? '*' : ' ');
+}
+
+/**
+ * p1022ds_set_sysfs_monitor_port: set the monitor port for sysfs
+ */
+int p1022ds_set_sysfs_monitor_port(int val)
+{
+ return val < 2 ? val : 0;
+}
+
+#endif
void __init p1022_ds_pic_init(void)
{
@@ -92,6 +292,15 @@ static void __init p1022_ds_setup_arch(void)
}
#endif
+#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
+ diu_ops.get_pixel_format = p1022ds_get_pixel_format;
+ diu_ops.set_gamma_table = p1022ds_set_gamma_table;
+ diu_ops.set_monitor_port = p1022ds_set_monitor_port;
+ diu_ops.set_pixel_clock = p1022ds_set_pixel_clock;
+ diu_ops.show_monitor_port = p1022ds_show_monitor_port;
+ diu_ops.set_sysfs_monitor_port = p1022ds_set_sysfs_monitor_port;
+#endif
+
#ifdef CONFIG_SMP
mpc85xx_smp_init();
#endif
--
1.7.2.3
^ permalink raw reply related
* Re: PPC: Possible bug in prom_parse.c:of_irq_map_raw?
From: Grant Likely @ 2010-10-07 18:34 UTC (permalink / raw)
To: John Williams
Cc: linuxppc-dev, devicetree-discuss, Linux Kernel list, Michal Simek
In-Reply-To: <1d3f23371002091921m7f47a1fbt1cf7fd2ef0a927fa@mail.gmail.com>
Reaching way back into the past....
John, did you ever solve your issue here? Comments below.
On Tue, Feb 9, 2010 at 8:21 PM, John Williams
<john.williams@petalogix.com> wrote:
> Hi,
>
> Perhaps this is my misunderstanding, but I'm looking at the bit of
> code in of_irq_map_raw() that iterates the interrupt-map DTS node,
> which I am seeing to behave strangely when handling the interrupt-map
> property on a PCI bridge node.
>
> Early in the function, we get the #address-cells value from the node -
> in this case the PCI bridge, and store it in local var addrsize:
>
> =A0 =A0 =A0 =A0/* Look for this #address-cells. We have to implement the =
old linux
> =A0 =A0 =A0 =A0 * trick of looking for the parent here as some device-tre=
es rely on it
> =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0old =3D of_node_get(ipar);
> =A0 =A0 =A0 =A0do {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tmp =3D of_get_property(old, "#address-cel=
ls", NULL);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tnode =3D of_get_parent(old);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of_node_put(old);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0old =3D tnode;
> =A0 =A0 =A0 =A0} while(old && tmp =3D=3D NULL);
> =A0 =A0 =A0 =A0of_node_put(old);
> =A0 =A0 =A0 =A0old =3D NULL;
> =A0 =A0 =A0 =A0addrsize =3D (tmp =3D=3D NULL) ? 2 : *tmp;
>
> =A0 =A0 =A0 =A0DBG(" -> addrsize=3D%d\n", addrsize);
>
>
> Later, once we've found the interrupt-map and are iterating over it
> attempting to match on PCI device addresses, there is this little
> fragment:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Get the interrupt paren=
t */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (of_irq_workarounds & O=
F_IMAP_NO_PHANDLE)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0newpar =3D=
of_node_get(of_irq_dflt_pic);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0newpar =3D
> of_find_node_by_phandle((phandle)*imap);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0imap++;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0--imaplen;
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Check if not found */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (newpar =3D=3D NULL) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DBG(" -> i=
map parent not found !\n");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto fail;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Get #interrupt-cells an=
d #address-cells of new
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * parent
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tmp =3D of_get_property(ne=
wpar, "#interrupt-cells", NULL);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (tmp =3D=3D NULL) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DBG(" -> p=
arent lacks #interrupt-cells !\n");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto fail;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0newintsize =3D *tmp;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tmp =3D of_get_property(ne=
wpar, "#address-cells", NULL);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0newaddrsize =3D (tmp =3D=
=3D NULL) ? 0 : *tmp;
>
> Finally, later in the loop we update addrsize=3Dnewaddrsize
>
> As I read this code, and the behaviour I'm seeing, is that if the
> interrupt controller parent device doesn't have an #address-cells
> entry, then this get_property will return fail, therefore setting
> newaddrsize =A0to zero. =A0This then means that subsequent match attempts
> when iterating the interrupt-map always fail, because the match length
> (addrsize) is 0.
Correct. The interrupt-map property contains the following fields:
child-unit-address child-irq irq-controller irq-parent-unit-address parent-=
irq
In the *vast majority* of cases, the irq-parent-unit-address is a
zero-length field because #address-cells isn't present on the
interrupt controller parent. So effectively interrupt-map becomes:
child-unit-address child-irq irq-controller parent-irq
See epapr 1.0 for a full discussion
>
> Maybe I'm missing something here, but shouldn't this last bit of code
> instead be:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tmp =3D of_get_property(ne=
wpar, "#address-cells", NULL);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0newaddrsize =3D (tmp =3D=
=3D NULL) ? addrsize : *tmp;
>
> =A0^^^^^^^^^
> ?
>
> In other words, if the parent node has an #address-cells value, then
> use it, otherwise stick to the #address-cells value we picked up for
> the actual node in question (ie the PCI bridge).
No, because at this point we absolutely do want to know how big the
parent #address-cells is, and if it is missing, we need to use 0. If
the child's addrsize continued to be used, then the interrupt-map
parsing would get unaligned.
The inner loop is over the entries in interrupt-map. addrsize and
intsize are only updated in the case where a match is found in the
table. If a match isn't found, then it should bail out to the 'fail'
label.
> The way this is manifesting itself in the system I'm looking at is
> that only the PCI device matching the first entry in the PCI bridge
> interrupt-map property is correctly matching. For PCI devices that
> require more than one pass through the interrupt-map loop, addrsize
> goes to zero and no further match is possible.
Something sounds fishy. If you're still having problems, can you
enable #define DEBUG in drivers/of/irq.c and post the output?
> I might be able to hack around this in the device-tree by setting
> #address-cells=3D<3> in the interrupt controller node, but that doesn't
> smell right either - it's only true for PCI devices for a start,
> whereas this controller handles interrupts from many sources on the
> 32-bit PLB bus as well. =A0I looked at the ML510 DTS in boot/dts and
> it's not doing anything like this.
Yeah, that's not right, and it would mess up the interrupt-map
parsing. You'd end up with more hard to debug problems.
g.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/fsl_booke: Add support to boot from core other than 0
From: Kumar Gala @ 2010-10-07 17:19 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1283297085-3455-2-git-send-email-msm@freescale.com>
On Aug 31, 2010, at 6:24 PM, Matthew McClintock wrote:
> First we check to see if we are the first core booting up. This
> is accomplished by comparing the boot_cpuid with -1, if it is we
> assume this is the first core coming up.
>
> Secondly, we need to update the initial thread info structure
> to reflect the actual cpu we are running on otherwise
> smp_processor_id() and related functions will return the default
> initialization value of the struct or 0.
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> arch/powerpc/kernel/head_fsl_booke.S | 10 ++++++++--
> arch/powerpc/kernel/setup_32.c | 2 +-
> 2 files changed, 9 insertions(+), 3 deletions(-)
applied
- k
^ permalink raw reply
* Re: Introduce support for little endian PowerPC
From: Hollis Blanchard @ 2010-10-07 16:25 UTC (permalink / raw)
To: Olof Johansson; +Cc: paulus, linuxppc-dev, Ian Munsie, linux-kernel
In-Reply-To: <20101001220343.GA10494@lixom.net>
On Fri, Oct 1, 2010 at 3:03 PM, Olof Johansson <olof@lixom.net> wrote:
> On Sat, Oct 02, 2010 at 06:51:55AM +1000, Benjamin Herrenschmidt wrote:
>> On Fri, 2010-10-01 at 12:59 -0500, Kumar Gala wrote:
>> > I'm not against it, and I agree some of the patches seem like good
>> > clean up. =A0I'm concerned about this bit rotting pretty quickly.
>>
>> Maybe. Most of it doesn't seem to be that bit-rottable.
>>
>> The changes to the asm stuff in misc_32.S for example are functions we
>> never ever touch once written (libgcc replacements) so I don't see them
>> rotting more with LE support than they did with BE :-)
>
> Does KVM/qemu support running LE guest on BE host? That'd help keeping
> the bitrot lower. :)
Surprisingly, qemu has very poor support for the concept of
endianness. The fact that BE PowerPC works on both BE and LE hosts in
Qemu today is more accidental than anything else (the special curse of
endianness is that two wrongs make a right). Supporting LE PowerPC
guests would be a dramatic effort, and I'm pretty sure it would impact
other qemu architectures as well.
-Hollis
^ permalink raw reply
* Re: Freescale P2020 / 85xx PCIe and Advance Error Reporting (AER) service problem
From: Kumar Gala @ 2010-10-07 14:42 UTC (permalink / raw)
To: Eran Liberty
Cc: Xianghua Xiao, linuxppc-dev, linux-pci, Tony Li, Linas Vepstas,
ZHANG WEI
In-Reply-To: <4CADBD7B.3000506@extricom.com>
On Oct 7, 2010, at 7:30 AM, Eran Liberty wrote:
> Dear Penguins,
>=20
> SHORT:
> There is a BUG in the current code design / Freescale P2020/85xx PCIe =
design that prevent it from registering to the PCIe AER... or that I =
have missed something :) ..
>=20
> LESS SHORT:
> I am in the process of a Freescale P2020 based board bring up. P2020 =
is basically two 85xx processors and their peripherals share most =
features.
>=20
> PCIe has a very extensive error reporting section and the Kernel =
already has a very nice looking Advanced Error Reporting driver.
>=20
> I encounter difficulties trying to connect the P2020/85xx PCIe device =
to this AER service driver.
>=20
> My technical findings follows:
>=20
> - pcie_portdrv_probe() will be called for every BRIDGE class PCI =
device. P2020 PCIe is a PCI-PCI BRIDGE class so no problem here. - The =
code will continue to check that we have PCI_CAP_ID_EXP capability, =
which we have and continue to pcie_port_device_register().
> - Now ,the function pcie_port_device_register() will FAIL. It will =
fail because it will call assign_interrupt_mode(), return with =
PCIE_PORT_NO_IRQ, and giveup with a reasonable remark in the code
> "/*
> * Don't use service devices that require interrupts if there is
> * no way to generate them.
> */"
>=20
> So now the question is why calling assign_interrupt_mode() with the =
P2020 PCIe ROOT device return empty? Well...
> - First assign_interrupt_mode() will test for PCIE_PORT_MSIX_MODE. =
Freescale PCIe does not support this...
> - Second attampt is made to discover PCIE_PORT_MSI_MODE, which =
Freescale should support but the PCIe PCI_CAP_ID_MSI capability is =
published on the device side of the bridge and NOT on the PCIe ROOT =
device, which is the one probed and thus fails.
> - Last it attempts to look at "dev->pin" in order to set =
PCIE_PORT_INTx_MODE. On top of being the less recommended way (the old =
way), The Freescale PCIE ROOT device pin is not set anywhere.
>=20
> Failing all those the probe fails and the AER service is not activated =
for the PCIE device.
>=20
> QUESTION:
> 1. What am I missing?
> 2. Has anyone enabled the AER PCIe service for P2020/MPC85xx?
> 3. Should the PCIe ROOT end report MSI capabilities or should the =
device end report itself as bridge ???
>=20
> -- Liberty
Do you have some code that enables AER on P2020. If so it might be =
easier to see what's going on.
- k
^ permalink raw reply
* Re: Serial RapidIO Maintaintance read causes lock up
From: Micha Nelissen @ 2010-10-07 14:21 UTC (permalink / raw)
To: Bastiaan Nijkamp; +Cc: linuxppc-dev
In-Reply-To: <AANLkTimFgrRbRfsQqN9d9GOZhth072F9TKGXunaqJNVB@mail.gmail.com>
Hi Bastian,
Bastiaan Nijkamp wrote:
> It seems i forgot to include the relevant TLB entries in U-Boot and the
> Device Tree in the e-mail, so here they are:
>
> The TLB entries in U-Boot:
The kernel maintains the TLB, you must not set those in U-boot. It might
cause conflicts when the kernel chooses its virtual memory space. You
should only configure LAWs in U-boot as the kernel does not do that.
That's the physical address you pass in the DTB (which seems to work,
reading your kernel log).
Do you access RapidIO space in U-boot also?
Do you have a logic analyser, then you can see whether the read is
actually coming out.
Check whether the time-to-live, packet and link timeouts have been set
to sane values to prevent deadlocks (especially time-to-live). At least
then your kernel will crash instead of lock up.
Micha
^ permalink raw reply
* P1020RDB PCI-E Interrupt problem
From: Fabian Bertholm @ 2010-10-07 13:45 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I try to run ath9k on a P1020RDB Freescale board.
I run into the problem similar to the Bug/Patch here:
http://patchwork.ozlabs.org/patch/52137/
I get irq 16: nobody cared....
I tried to fix the dts file in the same manner but this does not help.
Currently I am using 2.6.33.7
Any hints? Anybody?
The modified pci section from my dts:
pci0: pcie@ffe09000 {
cell-index = <1>;
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>;
ranges = <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0 0xffc30000 0x0 0x10000>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
interrupts = <16 2>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
/* IDSEL 0x0 */
0000 0x0 0x0 0x1 &mpic 0x4 0x2
0000 0x0 0x0 0x2 &mpic 0x5 0x2
0000 0x0 0x0 0x3 &mpic 0x6 0x2
0000 0x0 0x0 0x4 &mpic 0x7 0x2
>;
pcie@0 {
reg = <0x0 0x0 0x0 0x0 0x0>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
ranges = <0x2000000 0x0 0xa0000000
0x2000000 0x0 0xa0000000
0x0 0x20000000
0x1000000 0x0 0x0
0x1000000 0x0 0x0
0x0 0x100000>;
};
};
pci1: pcie@ffe0a000 {
cell-index = <2>;
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>;
ranges = <0x2000000 0x0 0xc0000000 0 0xc0000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0 0xffc20000 0x0 0x10000>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
interrupts = <16 2>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
/* IDSEL 0x0 */
0000 0x0 0x0 0x1 &mpic 0x0 0x1
0000 0x0 0x0 0x2 &mpic 0x1 0x1
0000 0x0 0x0 0x3 &mpic 0x2 0x1
0000 0x0 0x0 0x4 &mpic 0x3 0x1
>;
pcie@0 {
reg = <0x0 0x0 0x0 0x0 0x0>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
ranges = <0x2000000 0x0 0xc0000000
0x2000000 0x0 0xc0000000
0x0 0x20000000
0x1000000 0x0 0x0
0x1000000 0x0 0x0
0x0 0x100000>;
};
};
Best Regards,
Fabian
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers (fix)
From: Kumar Gala @ 2010-10-07 13:21 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, linux-kernel, Dave Jiang, Peter Tyser,
Doug Thompson, Scott Wood, Andrew Morton
In-Reply-To: <20101007071226.GA32189@oksana.dev.rtsoft.ru>
On Oct 7, 2010, at 2:12 AM, Anton Vorontsov wrote:
> On Thu, Oct 07, 2010 at 02:00:50AM -0500, Kumar Gala wrote:
>>=20
>> On Oct 7, 2010, at 1:37 AM, Kumar Gala wrote:
>>=20
>>>> @ -1125,7 +1128,10 @@ static struct of_device_id =
mpc85xx_mc_err_of_match[] =3D {
>>>> { .compatible =3D "fsl,mpc8569-memory-controller", },
>>>> { .compatible =3D "fsl,mpc8572-memory-controller", },
>>>> { .compatible =3D "fsl,mpc8349-memory-controller", },
>>>> + { .compatible =3D "fsl,p1020-memory-controller", },
>>>> + { .compatible =3D "fsl,p1021-memory-controller", },
>>>> { .compatible =3D "fsl,p2020-memory-controller", },
>>>> + { .compatible =3D "fsl,p4080-memory-controller", },
>>>=20
>>> This line should be here ;)
>>=20
>> should NOT be here.
>=20
> Hm. Are you sure? I thought that only L2 cache controller is
> not applicable (and based on Scott's comment I removed
> the l2 cache compatible entry for p4080). But I guess
> memory-controller is somewhat similar to all other 85xx?
>=20
> If it's not, I can surely prepare a patch that removes
> p4080 entry.
>=20
> Thanks,
Your correct, late night and looking at the wrong line. It was the L2 =
that should have been removed. Ignore me.
- k=
^ permalink raw reply
* Freescale P2020 / 85xx PCIe and Advance Error Reporting (AER) service problem
From: Eran Liberty @ 2010-10-07 12:30 UTC (permalink / raw)
To: Xianghua Xiao, ZHANG WEI, Roy Zang, Tony Li, Linas Vepstas,
linux-pci, linuxppc-dev
Dear Penguins,
SHORT:
There is a BUG in the current code design / Freescale P2020/85xx PCIe design that prevent it from registering to the PCIe AER... or that I have missed something :) ..
LESS SHORT:
I am in the process of a Freescale P2020 based board bring up. P2020 is basically two 85xx processors and their peripherals share most features.
PCIe has a very extensive error reporting section and the Kernel already has a very nice looking Advanced Error Reporting driver.
I encounter difficulties trying to connect the P2020/85xx PCIe device to this AER service driver.
My technical findings follows:
- pcie_portdrv_probe() will be called for every BRIDGE class PCI device. P2020 PCIe is a PCI-PCI BRIDGE class so no problem here.
- The code will continue to check that we have PCI_CAP_ID_EXP capability, which we have and continue to pcie_port_device_register().
- Now ,the function pcie_port_device_register() will FAIL. It will fail because it will call assign_interrupt_mode(), return with PCIE_PORT_NO_IRQ, and giveup with a reasonable remark in the code
"/*
* Don't use service devices that require interrupts if there is
* no way to generate them.
*/"
So now the question is why calling assign_interrupt_mode() with the P2020 PCIe ROOT device return empty? Well...
- First assign_interrupt_mode() will test for PCIE_PORT_MSIX_MODE. Freescale PCIe does not support this...
- Second attampt is made to discover PCIE_PORT_MSI_MODE, which Freescale should support but the PCIe PCI_CAP_ID_MSI capability is published on the device side of the bridge and NOT on the PCIe ROOT device, which is the one probed and thus fails.
- Last it attempts to look at "dev->pin" in order to set PCIE_PORT_INTx_MODE. On top of being the less recommended way (the old way), The Freescale PCIE ROOT device pin is not set anywhere.
Failing all those the probe fails and the AER service is not activated for the PCIE device.
QUESTION:
1. What am I missing?
2. Has anyone enabled the AER PCIe service for P2020/MPC85xx?
3. Should the PCIe ROOT end report MSI capabilities or should the device end report itself as bridge ???
-- Liberty
^ permalink raw reply
* Re: Linux on ppc440gp
From: Benjamin Herrenschmidt @ 2010-10-07 8:03 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Gorelik, Jacob (335F)
In-Reply-To: <201010070932.56438.sr@denx.de>
On Thu, 2010-10-07 at 09:32 +0200, Stefan Roese wrote:
> On Thursday 07 October 2010 01:51:44 Benjamin Herrenschmidt wrote:
> > On Wed, 2010-10-06 at 07:35 -0700, Gorelik, Jacob (335F) wrote:
> > > UIC0 (32 IRQ sources) at DCR 0xc0
> > > UIC1 (32 IRQ sources) at DCR 0xd0
> >
> > That looks bad. Your device-tree probably. Check the DCR bindings.
>
> Why does this look bad? On 440EPx this looks like this:
Because of the shit in my eyes :-) I misread 0x00 for some reason...
> UIC0 (32 IRQ sources) at DCR 0xc0
> UIC1 (32 IRQ sources) at DCR 0xd0
> UIC2 (32 IRQ sources) at DCR 0xe0
>
> So I don't see a problem with the output above.
Right, me neither now that I had a shower !
Cheers,
Ben.
^ permalink raw reply
* Re: use of BAT before taking over the MMU
From: Benjamin Herrenschmidt @ 2010-10-07 8:00 UTC (permalink / raw)
To: Albert Cahalan; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikH-f7MCxVyWr_mrfzeooQwRqTf4pGVEFSLO4Zy@mail.gmail.com>
On Wed, 2010-10-06 at 22:05 -0400, Albert Cahalan wrote:
> On Tue, Oct 5, 2010 at 11:31 AM, Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
>
> > An OS shouldn't expect to have more than its own program image
> > RAM mapped, in general.
>
> Linux actually makes calls to allocate more. I'm thankful
> that Linux always specifies an address, so I was able to
> get away with simply returning success. I wonder how this
> works for a firmware implementation that resides in RAM,
> using the memory that Linux demands. Must the firmware
> move itself out of the way?
No, Linux will retry somewhere else :-)
> >> Of course that faults immediately, so I have a handler that
> >> loads IBAT0 with a 128 KiB mapping. I treat the BAT like a
> >> direct-mapped software-loaded TLB. (like MIPS arch MMU)
> >
> > Just map the first 256MB and don't worry about anything else?
> > Seems a lot simpler to me ;-)
>
> I was expecting that Linux would demand plenty of mappings,
> including small ones and ones for IO. I was preparing myself
> for that.
No, not during prom_init. It's really just a trampoline code that sucks
out the device-tree and does a few other things. Once that's complete,
Linux takes over the MMU and from that point on, your FW is dead.
> >> Note that Linux can fail even with a firmware that doesn't touch
> >> the BAT registers. The MMU is on,
> >
> > You can boot Linux with the MMU off as well.
>
> That wasn't obvious for the prom_init path. IEEE docs seemed
> to suggest that the firmware must provide MMU handling.
1275 powerpc binding specifies both mode of operations. Linux doesn't
care which one is active
> >> and 0xc0000000 may be
> >> where the firmware expects to have... MMIO for the console,
> >> the client interface entry point, a forth stack, whatever.
> >> The BAT takes priority, and thus the firmware splatters stuff
> >> right onto the kernel or dies trying to read something it left there.
> >
> > Like I said, you're supposed to swap OS BATs with firmware BATs
> > in your client interface entry and exit. You have to switch
> > a lot of other registers there as well already, so that's no
> > big deal.
>
> Well no. This isn't real hardware. My prom entry point looks
> something like this:
>
> eciwx r0,r0,r0
> blr
>
> My ISI and DSI handlers look something like this:
>
> ecowx r0,r0,r0
> rfi
>
> The firmware doesn't need **any** registers. It's magic. I was
> just using the BAT registers to map what Linux wanted mapped.
Which is really just what any client program wants: You start with the
program ELF sections, and whatever it allocates with claim() calls.
> Anyway, I'm no longer able to reproduce the problem. I think
> something unrelated was causing strange behavior. This is a
> bit of a surprise since I would've expected a crash. Oh well.
Hard to tell from my side :-) But as I said, Linux doesn't rely on any
mapping at c0000000 or any BAT at this point. By the time it sets up
BATs the firmware is long gone and Linux is fully in control of the MMU.
Cheers,
Ben.
^ permalink raw reply
* Re: Linux on ppc440gp
From: Stefan Roese @ 2010-10-07 7:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gorelik, Jacob (335F)
In-Reply-To: <1286409104.2463.373.camel@pasglop>
On Thursday 07 October 2010 01:51:44 Benjamin Herrenschmidt wrote:
> On Wed, 2010-10-06 at 07:35 -0700, Gorelik, Jacob (335F) wrote:
> > UIC0 (32 IRQ sources) at DCR 0xc0
> > UIC1 (32 IRQ sources) at DCR 0xd0
>
> That looks bad. Your device-tree probably. Check the DCR bindings.
Why does this look bad? On 440EPx this looks like this:
UIC0 (32 IRQ sources) at DCR 0xc0
UIC1 (32 IRQ sources) at DCR 0xd0
UIC2 (32 IRQ sources) at DCR 0xe0
So I don't see a problem with the output above.
Cheers,
Stefan
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers (fix)
From: Anton Vorontsov @ 2010-10-07 7:12 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev, linux-kernel, Dave Jiang, Peter Tyser,
Doug Thompson, Scott Wood, Andrew Morton
In-Reply-To: <4A00FECC-3840-45E1-AB2A-6BDBD0FE09E0@kernel.crashing.org>
On Thu, Oct 07, 2010 at 02:00:50AM -0500, Kumar Gala wrote:
>
> On Oct 7, 2010, at 1:37 AM, Kumar Gala wrote:
>
> >> @ -1125,7 +1128,10 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
> >> { .compatible = "fsl,mpc8569-memory-controller", },
> >> { .compatible = "fsl,mpc8572-memory-controller", },
> >> { .compatible = "fsl,mpc8349-memory-controller", },
> >> + { .compatible = "fsl,p1020-memory-controller", },
> >> + { .compatible = "fsl,p1021-memory-controller", },
> >> { .compatible = "fsl,p2020-memory-controller", },
> >> + { .compatible = "fsl,p4080-memory-controller", },
> >
> > This line should be here ;)
>
> should NOT be here.
Hm. Are you sure? I thought that only L2 cache controller is
not applicable (and based on Scott's comment I removed
the l2 cache compatible entry for p4080). But I guess
memory-controller is somewhat similar to all other 85xx?
If it's not, I can surely prepare a patch that removes
p4080 entry.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers (fix)
From: Kumar Gala @ 2010-10-07 7:00 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev, Doug Thompson, linux-kernel, Dave Jiang,
Peter Tyser, Scott Wood, Andrew Morton
In-Reply-To: <0778A3B9-E242-4BCC-B318-154BE9ECB2C6@kernel.crashing.org>
On Oct 7, 2010, at 1:37 AM, Kumar Gala wrote:
>> @ -1125,7 +1128,10 @@ static struct of_device_id =
mpc85xx_mc_err_of_match[] =3D {
>> { .compatible =3D "fsl,mpc8569-memory-controller", },
>> { .compatible =3D "fsl,mpc8572-memory-controller", },
>> { .compatible =3D "fsl,mpc8349-memory-controller", },
>> + { .compatible =3D "fsl,p1020-memory-controller", },
>> + { .compatible =3D "fsl,p1021-memory-controller", },
>> { .compatible =3D "fsl,p2020-memory-controller", },
>> + { .compatible =3D "fsl,p4080-memory-controller", },
>=20
> This line should be here ;)
should NOT be here.
- k=
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers (fix)
From: Kumar Gala @ 2010-10-07 6:37 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, linux-kernel, Dave Jiang, Peter Tyser,
Doug Thompson, Scott Wood, Andrew Morton
In-Reply-To: <20101007062909.GA27110@oksana.dev.rtsoft.ru>
>=20
> It's already in Linus' tree.
Yeah, the problem is what's merged in linus's tree has p4080 listed and =
it shouldn't
>=20
> Thanks,
>=20
> - - - -
> commit cd1542c8197fc3c2eb3a8301505d5d9738fab1e4
> Author: Anton Vorontsov <avorontsov@mvista.com>
> Date: Tue Aug 10 18:03:21 2010 -0700
>=20
> edac: mpc85xx: add support for new MPCxxx/Pxxxx EDAC controllers
>=20
> Simply add proper IDs into the device table.
>=20
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: Peter Tyser <ptyser@xes-inc.com>
> Cc: Dave Jiang <djiang@mvista.com>
> Cc: Doug Thompson <dougthompson@xmission.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>=20
> diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
> index fdbad55..af75e27 100644
> --- a/drivers/edac/mpc85xx_edac.c
> +++ b/drivers/edac/mpc85xx_edac.c
> @@ -647,7 +647,10 @@ static struct of_device_id =
mpc85xx_l2_err_of_match[] =3D {
> { .compatible =3D "fsl,mpc8555-l2-cache-controller", },
> { .compatible =3D "fsl,mpc8560-l2-cache-controller", },
> { .compatible =3D "fsl,mpc8568-l2-cache-controller", },
> + { .compatible =3D "fsl,mpc8569-l2-cache-controller", },
> { .compatible =3D "fsl,mpc8572-l2-cache-controller", },
> + { .compatible =3D "fsl,p1020-l2-cache-controller", },
> + { .compatible =3D "fsl,p1021-l2-cache-controller", },
> { .compatible =3D "fsl,p2020-l2-cache-controller", },
> {},
> };
> @@ -1125,7 +1128,10 @@ static struct of_device_id =
mpc85xx_mc_err_of_match[] =3D {
> { .compatible =3D "fsl,mpc8569-memory-controller", },
> { .compatible =3D "fsl,mpc8572-memory-controller", },
> { .compatible =3D "fsl,mpc8349-memory-controller", },
> + { .compatible =3D "fsl,p1020-memory-controller", },
> + { .compatible =3D "fsl,p1021-memory-controller", },
> { .compatible =3D "fsl,p2020-memory-controller", },
> + { .compatible =3D "fsl,p4080-memory-controller", },
This line should be here ;)
> {},
> };
> MODULE_DEVICE_TABLE(of, mpc85xx_mc_err_of_match);
^ permalink raw reply
* Re: [PATCH] powerpc/p1022: add probing for individual DMA channels, not just DMA controllers
From: Kumar Gala @ 2010-10-07 6:27 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <1282253292-19420-1-git-send-email-timur@freescale.com>
On Aug 19, 2010, at 4:28 PM, Timur Tabi wrote:
> Like the MPC8610 HPCD, the P1022DS ASoC DMA driver probes on =
individual DMA
> channel nodes, so the DMA controller nodes' compatible string must be =
listed in
> p1022_ds_ids[] to work.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>=20
> This is for -next.
>=20
> I don't know why I forgot to include this change in the original =
P1022DS patch.
>=20
> arch/powerpc/platforms/85xx/p1022_ds.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers (fix)
From: Anton Vorontsov @ 2010-10-07 6:29 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev, linux-kernel, Dave Jiang, Peter Tyser,
Doug Thompson, Scott Wood, Andrew Morton
In-Reply-To: <5628792F-9A5F-4200-90B3-FB3939F02969@kernel.crashing.org>
On Thu, Oct 07, 2010 at 01:18:19AM -0500, Kumar Gala wrote:
[...]
> > diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
> > index cfa86f7..b178cfa 100644
> > --- a/drivers/edac/mpc85xx_edac.c
> > +++ b/drivers/edac/mpc85xx_edac.c
> > @@ -652,7 +652,6 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
> > { .compatible = "fsl,p1020-l2-cache-controller", },
> > { .compatible = "fsl,p1021-l2-cache-controller", },
> > { .compatible = "fsl,p2020-l2-cache-controller", },
> > - { .compatible = "fsl,p4080-l2-cache-controller", },
> > {},
> > };
> > MODULE_DEVICE_TABLE(of, mpc85xx_l2_err_of_match);
> > --
> > 1.7.0.5
>
> Can you post a new patch as it doesn't look like this got merged by Andrew so we need to clean up after ourselves.
It's already in Linus' tree.
Thanks,
- - - -
commit cd1542c8197fc3c2eb3a8301505d5d9738fab1e4
Author: Anton Vorontsov <avorontsov@mvista.com>
Date: Tue Aug 10 18:03:21 2010 -0700
edac: mpc85xx: add support for new MPCxxx/Pxxxx EDAC controllers
Simply add proper IDs into the device table.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Peter Tyser <ptyser@xes-inc.com>
Cc: Dave Jiang <djiang@mvista.com>
Cc: Doug Thompson <dougthompson@xmission.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index fdbad55..af75e27 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -647,7 +647,10 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
{ .compatible = "fsl,mpc8555-l2-cache-controller", },
{ .compatible = "fsl,mpc8560-l2-cache-controller", },
{ .compatible = "fsl,mpc8568-l2-cache-controller", },
+ { .compatible = "fsl,mpc8569-l2-cache-controller", },
{ .compatible = "fsl,mpc8572-l2-cache-controller", },
+ { .compatible = "fsl,p1020-l2-cache-controller", },
+ { .compatible = "fsl,p1021-l2-cache-controller", },
{ .compatible = "fsl,p2020-l2-cache-controller", },
{},
};
@@ -1125,7 +1128,10 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
{ .compatible = "fsl,mpc8569-memory-controller", },
{ .compatible = "fsl,mpc8572-memory-controller", },
{ .compatible = "fsl,mpc8349-memory-controller", },
+ { .compatible = "fsl,p1020-memory-controller", },
+ { .compatible = "fsl,p1021-memory-controller", },
{ .compatible = "fsl,p2020-memory-controller", },
+ { .compatible = "fsl,p4080-memory-controller", },
{},
};
MODULE_DEVICE_TABLE(of, mpc85xx_mc_err_of_match);
^ permalink raw reply related
* Re: [PATCH 2/2] powerpc/fsl_booke: Add support to boot from core other than 0
From: Kumar Gala @ 2010-10-07 6:10 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1283297085-3455-2-git-send-email-msm@freescale.com>
On Aug 31, 2010, at 6:24 PM, Matthew McClintock wrote:
> First we check to see if we are the first core booting up. This
> is accomplished by comparing the boot_cpuid with -1, if it is we
> assume this is the first core coming up.
>
> Secondly, we need to update the initial thread info structure
> to reflect the actual cpu we are running on otherwise
> smp_processor_id() and related functions will return the default
> initialization value of the struct or 0.
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> arch/powerpc/kernel/head_fsl_booke.S | 10 ++++++++--
> arch/powerpc/kernel/setup_32.c | 2 +-
> 2 files changed, 9 insertions(+), 3 deletions(-)
Are we sticking with this or not?
- k
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers (fix)
From: Kumar Gala @ 2010-10-07 6:18 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, linux-kernel, Dave Jiang, Peter Tyser,
Doug Thompson, Scott Wood, Andrew Morton
In-Reply-To: <20100801105419.GA352@oksana.dev.rtsoft.ru>
On Aug 1, 2010, at 5:54 AM, Anton Vorontsov wrote:
> On Wed, Jul 21, 2010 at 06:21:08PM -0500, Scott Wood wrote:
> [...]
>>>>> + { .compatible =3D "fsl,p4080-l2-cache-controller", },
>>>>=20
>>>> L2 on the p4080 is quite different from those other chips. It's =
part
>>>> of the core, controlled by SPRs.
>>>=20
>>> erm, was that an ack or a nack?
>>=20
>> NACK, p4080 doesn't belong in this table, at least not its L2.
>>=20
>> L3 on p4080 is similar to L2 on these other chips, though, and it
>> wouldn't take much to get this driver working on it -- but the match
>> table entry should wait until the differences are accommodated.
>=20
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> ---
>=20
> Scott, thanks for catching this!
>=20
> Andrew, please merge this patch into
> edac-mpc85xx-add-support-for-new-mpcxxx-pxxxx-edac-controllers.patch
>=20
> Thanks!
>=20
> drivers/edac/mpc85xx_edac.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>=20
> diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
> index cfa86f7..b178cfa 100644
> --- a/drivers/edac/mpc85xx_edac.c
> +++ b/drivers/edac/mpc85xx_edac.c
> @@ -652,7 +652,6 @@ static struct of_device_id =
mpc85xx_l2_err_of_match[] =3D {
> { .compatible =3D "fsl,p1020-l2-cache-controller", },
> { .compatible =3D "fsl,p1021-l2-cache-controller", },
> { .compatible =3D "fsl,p2020-l2-cache-controller", },
> - { .compatible =3D "fsl,p4080-l2-cache-controller", },
> {},
> };
> MODULE_DEVICE_TABLE(of, mpc85xx_l2_err_of_match);
> --=20
> 1.7.0.5
Can you post a new patch as it doesn't look like this got merged by =
Andrew so we need to clean up after ourselves.
- k
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox