Re: RTC on 2.6.36 for PowerMac 8600
On Sat, 2012-01-28 at 21:08 -0600, kevin diggs wrote: Hi, What will give me access to the RTC hardware on an old PowerMac 8600? I modload rtc-generic. /proc/devices has: should work with rtc generic, not sure what's up. You can check with printk ... rtc_generic should call into get_rtc_time which should go via ppc_md. into some powermac specific variants, themselves calling into the cuda driver. Cheers, Ben. 254 rtc and ls -l /dev/rtc*: crw-r--r-- 2 root root 254, 0 Sep 2 2010 /dev/rtc crw-r--r-- 2 root root 254, 0 Sep 2 2010 /dev/rtc0 crw-r--r-- 1 root root 10, 135 Aug 10 2004 /dev/rtc.old Trying to run hwclock gives: [root@PowerMac8600B root]# hwclock --debug hwclock from util-linux-2.12pre Using /dev/rtc interface to clock. Last drift adjustment done at 131743 seconds after 1969 Last calibration done at 131743 seconds after 1969 Hardware clock is on local time Assuming hardware clock is kept in local time. Waiting for clock tick... /dev/rtc does not have interrupt functions. Waiting in loop for time from /dev/rtc to change RTC_RD_TIME: Invalid argument ioctl() to /dev/rtc to read the time failed. I could have sworn this used to work on this system??? What am I forgetting? gzip -dc /proc/config.gz|grep -i rtc lists: CONFIG_RTC_LIB=m CONFIG_RTC_CLASS=m # RTC interfaces CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y # Platform RTC drivers CONFIG_RTC_DRV_CMOS=m # on-CPU RTC drivers CONFIG_RTC_DRV_GENERIC=m Thanks! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2 v2] powerpc/dts: Add dts for p1025rdb board
From: Zhicheng Fan b32...@freeescale.com
P1025RDB Overview
--
1Gbyte DDR3 SDRAM
32 Mbyte NAND flash
16Mbyte NOR flash
16 Mbyte SPI flash
SD connector to interface with the SD memory card
Real-time clock on I2C bus
PCIe:
- x1 PCIe slot
- x1 mini-PCIe slot
10/100/1000 BaseT Ethernet ports:
- eTSEC1, RGMII: one 10/100/1000 port using AtherosTM AR8021
- eTSEC2, SGMII: one 10/100/1000 port using VitesseTM VSC8221
- eTSEC3, RGMII: one 10/100/1000 port using AtherosTM AR8021
USB 2.0 port:
- Two USB2.0 Type A receptacles
- One USB2.0 signal to Mini PCIe slot
Dual RJ45 UART ports:
- DUART interface: supports two UARTs up to 115200 bps for console display
Signed-off-by: Zhicheng Fan b32...@freeescale.com
---
arch/powerpc/boot/dts/fsl/p1025si-post.dtsi | 228 +
arch/powerpc/boot/dts/fsl/p1025si-pre.dtsi | 70 +++
arch/powerpc/boot/dts/p1025rdb.dts | 137 +
arch/powerpc/boot/dts/p1025rdb.dtsi | 286 +++
arch/powerpc/boot/dts/p1025rdb_36b.dts | 88
5 files changed, 809 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/p1025si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p1025si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/p1025rdb.dts
create mode 100644 arch/powerpc/boot/dts/p1025rdb.dtsi
create mode 100644 arch/powerpc/boot/dts/p1025rdb_36b.dts
diff --git a/arch/powerpc/boot/dts/fsl/p1025si-post.dtsi
b/arch/powerpc/boot/dts/fsl/p1025si-post.dtsi
new file mode 100644
index 000..e0e3e4d
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/p1025si-post.dtsi
@@ -0,0 +1,228 @@
+/*
+ * P1025 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,p1025-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;
+
[PATCH 2/2 v2] P1025RDB: Add p1025rdb platform support
From: Zhicheng Fan b32...@freeescale.com
Signed-off-by: Zhicheng Fan b32...@freeescale.com
---
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 0d3d7c6..3381a80 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -91,6 +91,7 @@ static void __init mpc85xx_rdb_setup_arch(void)
machine_device_initcall(p2020_rdb, mpc85xx_common_publish_devices);
machine_device_initcall(p1020_rdb, mpc85xx_common_publish_devices);
machine_device_initcall(p1020_rdb_pc, mpc85xx_common_publish_devices);
+machine_device_initcall(p1025_rdb, mpc85xx_common_publish_devices);
/*
* Called very early, device-tree isn't unflattened
@@ -122,6 +123,15 @@ static int __init p1020_rdb_probe(void)
return 0;
}
+static int __init p1025_rdb_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (of_flat_dt_is_compatible(root, fsl,P1025RDB))
+ return 1;
+ return 0;
+}
+
define_machine(p2020_rdb) {
.name = P2020 RDB,
.probe = p2020_rdb_probe,
@@ -163,3 +173,17 @@ define_machine(p1020_rdb_pc) {
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
};
+
+define_machine(p1025_rdb) {
+ .name = P1025 RDB,
+ .probe = p1025_rdb_probe,
+ .setup_arch = mpc85xx_rdb_setup_arch,
+ .init_IRQ = mpc85xx_rdb_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+ .get_irq= mpic_get_irq,
+ .restart= fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
--
1.7.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: Add missing config option for CACHE SRAM code
fsl_85xx_l2ctlr.o and fsl_85xx_cache_sram.o are built only if CONFIG_FSL_85XX_CACHE_SRAM is defined. The driver that qualifies and wants to make use of the CACHE SRAM's exported API (i.e. a freescale net driver) should (be able to) select this config option. Signed-off-by: Claudiu Manoil claudiu.man...@freescale.com --- arch/powerpc/platforms/85xx/Kconfig |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig index d7946be..6e2eecd 100644 --- a/arch/powerpc/platforms/85xx/Kconfig +++ b/arch/powerpc/platforms/85xx/Kconfig @@ -13,6 +13,15 @@ if FSL_SOC_BOOKE if PPC32 +config FSL_85XX_CACHE_SRAM + bool + select PPC_LIB_RHEAP + help + When selected, this option enables cache-sram support + for memory allocation on P1/P2 QorIQ platforms. + cache-sram-size and cache-sram-offset kernel boot + parameters should be passed when this option is enabled. + config MPC8540_ADS bool Freescale MPC8540 ADS select DEFAULT_UIMAGE -- 1.6.6 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: Fix compiler error with THIS_MODULE and related
CC arch/powerpc/sysdev/fsl_85xx_l2ctlr.o arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:209:13: error: 'THIS_MODULE' undeclared here (not in a function) arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:229:20: error: expected declaration specifiers or '...' before string constant cc1: warnings being treated as errors arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:229:1: error: data definition has no type or storage class arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:229:1: error: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION' arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:229:20: error: function declaration isn't a prototype arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:230:16: error: expected declaration specifiers or '...' before string constant arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:230:1: error: data definition has no type or storage class arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:230:1: error: type defaults to 'int' in declaration of 'MODULE_LICENSE' arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:230:16: error: function declaration isn't a prototype make[1]: *** [arch/powerpc/sysdev/fsl_85xx_l2ctlr.o] Error 1 ... CC arch/powerpc/sysdev/fsl_85xx_cache_sram.o cc1: warnings being treated as errors arch/powerpc/sysdev/fsl_85xx_cache_sram.c:69:1: error: data definition has no type or storage class arch/powerpc/sysdev/fsl_85xx_cache_sram.c:69:1: error: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' arch/powerpc/sysdev/fsl_85xx_cache_sram.c:69:1: error: parameter names (without types) in function declaration arch/powerpc/sysdev/fsl_85xx_cache_sram.c:80:1: error: data definition has no type or storage class arch/powerpc/sysdev/fsl_85xx_cache_sram.c:80:1: error: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' arch/powerpc/sysdev/fsl_85xx_cache_sram.c:80:1: error: parameter names (without types) in function declaration make[1]: *** [arch/powerpc/sysdev/fsl_85xx_cache_sram.o] Error 1 Signed-off-by: Claudiu Manoil claudiu.man...@freescale.com --- arch/powerpc/sysdev/fsl_85xx_cache_sram.c |1 + arch/powerpc/sysdev/fsl_85xx_l2ctlr.c |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c index 1164158..92cce8d 100644 --- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c +++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c @@ -24,6 +24,7 @@ */ #include linux/kernel.h +#include linux/module.h #include linux/slab.h #include linux/err.h #include linux/of_platform.h diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c index 5f88797..1957e53 100644 --- a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c +++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c @@ -21,6 +21,7 @@ */ #include linux/kernel.h +#include linux/module.h #include linux/of_platform.h #include asm/io.h -- 1.6.6 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 14/25] irq_domain: Remove irq_domain_add_simple()
On Fri, Jan 27, 2012 at 02:36:08PM -0700, Grant Likely wrote:
irq_domain_add_simple() was a stop-gap measure until complete irq_domain
support was complete. This patch removes the irq_domain_add_simple()
interface.
v2: Updated to pass in host_data pointer on irq_domain allocation.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Milton Miller milt...@bga.com
---
arch/arm/mach-imx/mach-imx6q.c |3 ++-
arch/arm/mach-msm/board-msm8x60.c |8 ++--
arch/arm/mach-mx5/imx51-dt.c|4 ++--
arch/arm/mach-mx5/imx53-dt.c|4 ++--
arch/arm/mach-omap2/board-generic.c |2 +-
arch/arm/mach-prima2/irq.c |2 +-
drivers/mfd/twl-core.c |2 +-
include/linux/irqdomain.h |1 -
kernel/irq/irqdomain.c | 10 ++
9 files changed, 13 insertions(+), 23 deletions(-)
...
--- a/arch/arm/mach-mx5/imx51-dt.c
+++ b/arch/arm/mach-mx5/imx51-dt.c
@@ -47,7 +47,7 @@ static const struct of_dev_auxdata imx51_auxdata_lookup[]
__initconst = {
static int __init imx51_tzic_add_irq_domain(struct device_node *np,
struct device_node *interrupt_parent)
{
- irq_domain_add_simple(np, 0);
+ irq_domain_add_legacy(np, 32, 0, 0, irq_domain_simple_ops, NULL);
return 0;
}
@@ -57,7 +57,7 @@ static int __init imx51_gpio_add_irq_domain(struct
device_node *np,
static int gpio_irq_base = MXC_GPIO_IRQ_START + ARCH_NR_GPIOS;
gpio_irq_base -= 32;
- irq_domain_add_simple(np, gpio_irq_base);
+ irq_domain_add_legacy(np, 32, gpio_irq_base, 0, irq_domain_simple_ops,
NULL);
The tzic on imx5 gets 128 irq lines rather than 32 here. The current
code will make any hwirq that is 32 hit the WARN_ON below in
irq_domain_legacy_revmap().
WARN_ON(hwirq first_hwirq || hwirq = first_hwirq + size)
The first_hwirq is 0 and size is 32 in this case.
Changing 32 to 128 seems fixing the problem.
return 0;
}
diff --git a/arch/arm/mach-mx5/imx53-dt.c b/arch/arm/mach-mx5/imx53-dt.c
index 05ebb3e..89de5d4 100644
--- a/arch/arm/mach-mx5/imx53-dt.c
+++ b/arch/arm/mach-mx5/imx53-dt.c
@@ -51,7 +51,7 @@ static const struct of_dev_auxdata imx53_auxdata_lookup[]
__initconst = {
static int __init imx53_tzic_add_irq_domain(struct device_node *np,
struct device_node *interrupt_parent)
{
- irq_domain_add_simple(np, 0);
+ irq_domain_add_legacy(np, 32, 0, 0, irq_domain_simple_ops, NULL);
Ditto
Regards,
Shawn
return 0;
}
@@ -61,7 +61,7 @@ static int __init imx53_gpio_add_irq_domain(struct
device_node *np,
static int gpio_irq_base = MXC_GPIO_IRQ_START + ARCH_NR_GPIOS;
gpio_irq_base -= 32;
- irq_domain_add_simple(np, gpio_irq_base);
+ irq_domain_add_legacy(np, 32, gpio_irq_base, 0, irq_domain_simple_ops,
NULL);
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 14/25] irq_domain: Remove irq_domain_add_simple()
Shawn,
On 01/31/2012 06:45 AM, Shawn Guo wrote:
On Fri, Jan 27, 2012 at 02:36:08PM -0700, Grant Likely wrote:
irq_domain_add_simple() was a stop-gap measure until complete irq_domain
support was complete. This patch removes the irq_domain_add_simple()
interface.
v2: Updated to pass in host_data pointer on irq_domain allocation.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Milton Miller milt...@bga.com
---
arch/arm/mach-imx/mach-imx6q.c |3 ++-
arch/arm/mach-msm/board-msm8x60.c |8 ++--
arch/arm/mach-mx5/imx51-dt.c|4 ++--
arch/arm/mach-mx5/imx53-dt.c|4 ++--
arch/arm/mach-omap2/board-generic.c |2 +-
arch/arm/mach-prima2/irq.c |2 +-
drivers/mfd/twl-core.c |2 +-
include/linux/irqdomain.h |1 -
kernel/irq/irqdomain.c | 10 ++
9 files changed, 13 insertions(+), 23 deletions(-)
...
--- a/arch/arm/mach-mx5/imx51-dt.c
+++ b/arch/arm/mach-mx5/imx51-dt.c
@@ -47,7 +47,7 @@ static const struct of_dev_auxdata imx51_auxdata_lookup[]
__initconst = {
static int __init imx51_tzic_add_irq_domain(struct device_node *np,
struct device_node *interrupt_parent)
{
-irq_domain_add_simple(np, 0);
+irq_domain_add_legacy(np, 32, 0, 0, irq_domain_simple_ops, NULL);
return 0;
}
@@ -57,7 +57,7 @@ static int __init imx51_gpio_add_irq_domain(struct
device_node *np,
static int gpio_irq_base = MXC_GPIO_IRQ_START + ARCH_NR_GPIOS;
gpio_irq_base -= 32;
-irq_domain_add_simple(np, gpio_irq_base);
+irq_domain_add_legacy(np, 32, gpio_irq_base, 0, irq_domain_simple_ops,
NULL);
The tzic on imx5 gets 128 irq lines rather than 32 here. The current
code will make any hwirq that is 32 hit the WARN_ON below in
irq_domain_legacy_revmap().
But this is the gpio controller code? Really this should be 4 domains,
but this temp fix is probably fine until you use my generic irq chip
support.
Rob
WARN_ON(hwirq first_hwirq || hwirq = first_hwirq + size)
The first_hwirq is 0 and size is 32 in this case.
Changing 32 to 128 seems fixing the problem.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 14/25] irq_domain: Remove irq_domain_add_simple()
On Tue, Jan 31, 2012 at 07:15:26AM -0600, Rob Herring wrote:
...
--- a/arch/arm/mach-mx5/imx51-dt.c
+++ b/arch/arm/mach-mx5/imx51-dt.c
@@ -47,7 +47,7 @@ static const struct of_dev_auxdata
imx51_auxdata_lookup[] __initconst = {
static int __init imx51_tzic_add_irq_domain(struct device_node *np,
struct device_node *interrupt_parent)
{
- irq_domain_add_simple(np, 0);
+ irq_domain_add_legacy(np, 32, 0, 0, irq_domain_simple_ops, NULL);
return 0;
}
@@ -57,7 +57,7 @@ static int __init imx51_gpio_add_irq_domain(struct
device_node *np,
static int gpio_irq_base = MXC_GPIO_IRQ_START + ARCH_NR_GPIOS;
gpio_irq_base -= 32;
- irq_domain_add_simple(np, gpio_irq_base);
+ irq_domain_add_legacy(np, 32, gpio_irq_base, 0, irq_domain_simple_ops,
NULL);
The tzic on imx5 gets 128 irq lines rather than 32 here. The current
code will make any hwirq that is 32 hit the WARN_ON below in
irq_domain_legacy_revmap().
But this is the gpio controller code? Really this should be 4 domains,
but this temp fix is probably fine until you use my generic irq chip
support.
Sorry. The comment was put at the wrong place. It should be against
imx51_tzic_add_irq_domain() just above.
--
Regards,
Shawn
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v2] powerpc/dts: Add dts for p1025rdb board
On Jan 31, 2012, at 3:51 AM, Zhicheng Fan wrote: From: Zhicheng Fan b32...@freeescale.com P1025RDB Overview -- 1Gbyte DDR3 SDRAM 32 Mbyte NAND flash 16Mbyte NOR flash 16 Mbyte SPI flash SD connector to interface with the SD memory card Real-time clock on I2C bus PCIe: - x1 PCIe slot - x1 mini-PCIe slot 10/100/1000 BaseT Ethernet ports: - eTSEC1, RGMII: one 10/100/1000 port using AtherosTM AR8021 - eTSEC2, SGMII: one 10/100/1000 port using VitesseTM VSC8221 - eTSEC3, RGMII: one 10/100/1000 port using AtherosTM AR8021 USB 2.0 port: - Two USB2.0 Type A receptacles - One USB2.0 signal to Mini PCIe slot Dual RJ45 UART ports: - DUART interface: supports two UARTs up to 115200 bps for console display Signed-off-by: Zhicheng Fan b32...@freeescale.com --- arch/powerpc/boot/dts/fsl/p1025si-post.dtsi | 228 + arch/powerpc/boot/dts/fsl/p1025si-pre.dtsi | 70 +++ arch/powerpc/boot/dts/p1025rdb.dts | 137 + arch/powerpc/boot/dts/p1025rdb.dtsi | 286 +++ arch/powerpc/boot/dts/p1025rdb_36b.dts | 88 5 files changed, 809 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/p1025si-post.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/p1025si-pre.dtsi create mode 100644 arch/powerpc/boot/dts/p1025rdb.dts create mode 100644 arch/powerpc/boot/dts/p1025rdb.dtsi create mode 100644 arch/powerpc/boot/dts/p1025rdb_36b.dts For the p1024 p1025 I do NOT want to add new dts/fsl/p1025si*.dtsi files. We should use the p1020 and p1021 as they are identical. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Question about GPIO Lib
Bruce: On Mon, Jan 30, 2012 at 6:06 PM, bruce_leon...@selinc.com wrote: Bill Gatliff b...@billgatliff.com wrote on 01/27/2012 10:42:57 AM: Sounds like you DON'T want to merely export that GPIO pin to userspace. Well, yes I do want to just export to userspace I misunderstood your message, then. I was thinking that you were already using certain pins in kernel space, and didn't want THOSE pins exported to userspace due to the risks that users might invoke them and cause Bad Things to happen. I just want to restrict the pins that get exported to only those that are defined in the device tree. I don't want or need to access any of the exported pins from kernel space and I don't want user space to access any pin not explicitly called out in the device tree. I want it to behave like gpio-leds only with input as well as output capabilities. I glanced at gpiolib.c, and I don't immediately see a way to achieve this with the current code. Again, you could get the same net effect by doing a gpio_request() in kernel space on the pins you DON'T want exported, which would prevent those pins being exportable. But that's still different from what you are actually asking for. If I understand this correctly you're basically saying that gpiolib is a waste of time and I should just write my own driver? I'm DEFINITELY not saying that gpiolib is generally a waste of time! :) I'm just saying that, sadly, in many ways gpiolib is still a work-in-progress. The userspace component has been somewhat controversial in general over the years, and definitely lacks several key features in addition to the one you are asking for. Since I know others will ask :), note that the userspace component won't give you a direction attribute for pins whose directions cannot be changed from userspace. That's a pretty important omission, since it prevents me from conveniently verifying (apart from debugfs, I mean) that a pin is in fact configured in the direction I want it to be. Whether I can change its direction is a different issue entirely. Another omission that has struck me over the years is that it's not straightforward for gpio_chip authors to add custom attributes in sysfs for either the chip itself, or for the pins the chip exports. Within /sys/class/gpio/gpioN/ I mean. But even in its current state, gpiolib is awesome. Maybe someday I or someone else will find time to make it awesomer. :) b.g. -- Bill Gatliff b...@billgatliff.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Question about GPIO Lib
Bill, Bill Gatliff b...@billgatliff.com wrote on 01/31/2012 08:39:05 AM: I misunderstood your message, then. I was thinking that you were No worries, I frequently misunderstand myself :) Thanks for taking the time to respond, I appreciate it. I'm DEFINITELY not saying that gpiolib is generally a waste of time! :) I'm just saying that, sadly, in many ways gpiolib is still a work-in-progress. The userspace component has been somewhat Okay, that's more or less the point I had gotten to myself. My first linux project I just wrote everything myself and on this latest one I've been making a concerted effort to utilize existing services within the kernel. This looked (and still does) like a good candidate, I guess I just need to wrap a little bit of extra around it. Thanks! Bruce ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v2] powerpc/dts: Add dts for p1020rdb-pc
On 01/31/2012 01:06 AM, Zhicheng Fan wrote:
+lbc {
+ 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;
+ };
+
+ partition@60 {
+ /* 4MB for Compressed Root file System Image */
+ reg = 0x0060 0x0040;
+ label = NAND (RO) Compressed RFS Image;
+ read-only;
+ };
+
+ partition@a0 {
+ /* 7MB for JFFS2 based Root file System */
+ reg = 0x00a0 0x0070;
+ label = NAND (RW) JFFS2 Root File System;
+ };
+
+ partition@110 {
+ /* 15MB for JFFS2 based Root file System */
+ reg = 0x0110 0x00f0;
+ label = NAND (RW) Writable User area;
+ };
+ };
Please remove (RO) and (RW) -- this duplicates information provided by
the read-only property.
Please only mark partitions read-only when they could brick the board if
overwritten. Things like the Linux kernel, RFS, and DTB should not be
read-only.
+/include/ p1020rdb-pc.dts
+
+/ {
+ model = fsl,P1020RDB-PC;
+ compatible = fsl,P1020RDB-PC, fsl,MPC85XXRDB-CAMP;
Eliminate fsl,MPC85XXRDB-CAMP. Specify pic-no-reset on the mpic node
instead.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v2] powerpc/dts: Add dts for p1025rdb board
On 01/31/2012 09:55 AM, Kumar Gala wrote: On Jan 31, 2012, at 3:51 AM, Zhicheng Fan wrote: Signed-off-by: Zhicheng Fan b32...@freeescale.com --- arch/powerpc/boot/dts/fsl/p1025si-post.dtsi | 228 + arch/powerpc/boot/dts/fsl/p1025si-pre.dtsi | 70 +++ arch/powerpc/boot/dts/p1025rdb.dts | 137 + arch/powerpc/boot/dts/p1025rdb.dtsi | 286 +++ arch/powerpc/boot/dts/p1025rdb_36b.dts | 88 5 files changed, 809 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/p1025si-post.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/p1025si-pre.dtsi create mode 100644 arch/powerpc/boot/dts/p1025rdb.dts create mode 100644 arch/powerpc/boot/dts/p1025rdb.dtsi create mode 100644 arch/powerpc/boot/dts/p1025rdb_36b.dts For the p1024 p1025 I do NOT want to add new dts/fsl/p1025si*.dtsi files. We should use the p1020 and p1021 as they are identical. Are they sufficiently software compatible that we want to use p1020/p1021 in all the compatible strings? If yes, how was this verified? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Fix compiler error with THIS_MODULE and related
On 01/31/2012 04:15 AM, Claudiu Manoil wrote: CC arch/powerpc/sysdev/fsl_85xx_l2ctlr.o arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:209:13: error: 'THIS_MODULE' undeclared here (not in a function) arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:229:20: error: expected declaration specifiers or '...' before string constant cc1: warnings being treated as errors arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:229:1: error: data definition has no type or storage class arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:229:1: error: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION' arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:229:20: error: function declaration isn't a prototype arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:230:16: error: expected declaration specifiers or '...' before string constant arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:230:1: error: data definition has no type or storage class arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:230:1: error: type defaults to 'int' in declaration of 'MODULE_LICENSE' arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:230:16: error: function declaration isn't a prototype make[1]: *** [arch/powerpc/sysdev/fsl_85xx_l2ctlr.o] Error 1 ... CC arch/powerpc/sysdev/fsl_85xx_cache_sram.o cc1: warnings being treated as errors arch/powerpc/sysdev/fsl_85xx_cache_sram.c:69:1: error: data definition has no type or storage class arch/powerpc/sysdev/fsl_85xx_cache_sram.c:69:1: error: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' arch/powerpc/sysdev/fsl_85xx_cache_sram.c:69:1: error: parameter names (without types) in function declaration arch/powerpc/sysdev/fsl_85xx_cache_sram.c:80:1: error: data definition has no type or storage class arch/powerpc/sysdev/fsl_85xx_cache_sram.c:80:1: error: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' arch/powerpc/sysdev/fsl_85xx_cache_sram.c:80:1: error: parameter names (without types) in function declaration make[1]: *** [arch/powerpc/sysdev/fsl_85xx_cache_sram.o] Error 1 Signed-off-by: Claudiu Manoil claudiu.man...@freescale.com --- arch/powerpc/sysdev/fsl_85xx_cache_sram.c |1 + arch/powerpc/sysdev/fsl_85xx_l2ctlr.c |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c index 1164158..92cce8d 100644 --- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c +++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c @@ -24,6 +24,7 @@ */ #include linux/kernel.h +#include linux/module.h #include linux/slab.h #include linux/err.h #include linux/of_platform.h diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c index 5f88797..1957e53 100644 --- a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c +++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c @@ -21,6 +21,7 @@ */ #include linux/kernel.h +#include linux/module.h #include linux/of_platform.h #include asm/io.h I believe linux/export.h is what you're supposed to include for this these days. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RTC on 2.6.36 for PowerMac 8600
Hi, On 1/29/12, Andreas Schwab sch...@linux-m68k.org wrote: kevin diggs diggskevi...@gmail.com writes: Perhaps the RTC was reset due to battery running out? That would set the year to 1900, but the kernel RTC interface cannot represent dates before 1970. Unfortunately hwclock insists on reading the RTC even when you just want to write to it, so you cannot fix that with hwclock -w. When the battery of my iBook has run out I'm using the following to reset RTC to current time so that it is usable again. Andreas. Thanks! I did not know about this problem with the year. This vintage of mac sets the year to 1956. Yes, the battery is dead. It is one of those $20 1/3 AA lithium cells. I can't afford to replace it. I went into the MacOS Classic date control panel and set the year to 1971 and it worked! Thanks for the tip. I would have never figured this one out! kevin -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PULL] ARM mach/irqs.h cleanup for 3.4
Russell, Can you please pull mach/irqs.h clean-up for 3.4. I've gotten little to no response from the affected platform maintainers. It's primarily superh and shmobile that have any significant changes though. Rob The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f: Linux 3.3-rc1 (2012-01-19 15:04:48 -0800) are available in the git repository at: git://sources.calxeda.com/kernel/linux.git sparse_irq Jamie Iles (1): ARM: picoxcell: remove mach/irqs.h Rob Herring (13): irq: make SPARSE_IRQ an optionally hidden option sound: pxa2xx-ac97: include mach/irqs.h directly gpio: pxa: explicitly include mach/irqs.h ARM: remove mc146818rtc.h from time.c ARM: mc146818rtc: remove unnecessary include of mach/irqs.h ARM: it8152: explicitly include mach/irqs.h sh: intc: unify evt2irq/irq2evt macros for sh and arm sh: intc: remove dependency on NR_IRQS ARM: mmp: remove NR_IRQS ARM: pxa: remove NR_IRQS ARM: shmobile: remove NR_IRQS ARM: only include mach/irqs.h for !SPARSE_IRQ ARM: highbank: select SPARSE_IRQ and remove irqs.h arch/arm/Kconfig|2 +- arch/arm/include/asm/hardware/it8152.h |3 +++ arch/arm/include/asm/irq.h |8 ++-- arch/arm/include/asm/mc146818rtc.h |4 +++- arch/arm/kernel/time.c |2 -- arch/arm/mach-highbank/highbank.c |1 - arch/arm/mach-highbank/include/mach/irqs.h |6 -- arch/arm/mach-mmp/aspenite.c|5 +++-- arch/arm/mach-mmp/avengers_lite.c |1 + arch/arm/mach-mmp/brownstone.c |4 ++-- arch/arm/mach-mmp/flint.c |3 ++- arch/arm/mach-mmp/gplugd.c |2 +- arch/arm/mach-mmp/include/mach/irqs.h |3 +-- arch/arm/mach-mmp/irq-mmp2.c|1 + arch/arm/mach-mmp/jasper.c |5 +++-- arch/arm/mach-mmp/tavorevb.c|1 + arch/arm/mach-mmp/teton_bga.c |3 ++- arch/arm/mach-mmp/ttc_dkb.c |4 ++-- arch/arm/mach-picoxcell/include/mach/irqs.h | 20 arch/arm/mach-pxa/capc7117.c|1 + arch/arm/mach-pxa/cm-x300.c |1 + arch/arm/mach-pxa/colibri-pxa270.c |2 ++ arch/arm/mach-pxa/colibri-pxa300.c |1 + arch/arm/mach-pxa/colibri-pxa320.c |1 + arch/arm/mach-pxa/corgi.c |3 +++ arch/arm/mach-pxa/csb726.c |1 + arch/arm/mach-pxa/devices.c |1 + arch/arm/mach-pxa/em-x270.c |2 ++ arch/arm/mach-pxa/gumstix.c |1 + arch/arm/mach-pxa/h5000.c |1 + arch/arm/mach-pxa/himalaya.c|1 + arch/arm/mach-pxa/icontrol.c|1 + arch/arm/mach-pxa/idp.c |1 + arch/arm/mach-pxa/include/mach/irqs.h |2 +- arch/arm/mach-pxa/mioa701.c |1 + arch/arm/mach-pxa/mp900.c |1 + arch/arm/mach-pxa/palmld.c |1 + arch/arm/mach-pxa/palmt5.c |1 + arch/arm/mach-pxa/palmtc.c |1 + arch/arm/mach-pxa/palmte2.c |1 + arch/arm/mach-pxa/palmtreo.c|2 ++ arch/arm/mach-pxa/palmtx.c |1 + arch/arm/mach-pxa/palmz72.c |1 + arch/arm/mach-pxa/pxa3xx.c |1 + arch/arm/mach-pxa/raumfeld.c|3 +++ arch/arm/mach-pxa/saar.c|1 + arch/arm/mach-pxa/spitz.c |3 +++ arch/arm/mach-pxa/stargate2.c |1 + arch/arm/mach-pxa/tavorevb.c|1 + arch/arm/mach-pxa/time.c|1 + arch/arm/mach-pxa/trizeps4.c|2 ++ arch/arm/mach-pxa/viper.c |1 + arch/arm/mach-pxa/vpac270.c |1 + arch/arm/mach-pxa/xcep.c|1 + arch/arm/mach-pxa/z2.c |1 + arch/arm/mach-shmobile/Kconfig |4 arch/arm/mach-shmobile/board-ag5evm.c |1 + arch/arm/mach-shmobile/board-bonito.c |1 + arch/arm/mach-shmobile/board-g3evm.c|1 + arch/arm/mach-shmobile/board-g4evm.c|1 + arch/arm/mach-shmobile/board-kota2.c|1 + arch/arm/mach-shmobile/board-mackerel.c |1 + arch/arm/mach-shmobile/board-marzen.c |1 + arch/arm/mach-shmobile/include/mach/irqs.h |6 +- arch/arm/mach-shmobile/intc-r8a7740.c |1 + arch/arm/mach-shmobile/intc-sh7367.c|1 + arch/arm/mach-shmobile/intc-sh7372.c|1 + arch/arm/mach-shmobile/intc-sh7377.c|1 + arch/arm/mach-shmobile/intc-sh73a0.c|1 + arch/arm/mach-shmobile/setup-r8a7740.c |
[PATCH v2] fsldma: ignore end of segments interrupt
The mpc8349ea has been observed to generate spurious end of segments
interrupts despite the fact that they are not enabled by this driver.
Check for them and ignore them to avoid a kernel error message.
Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu
Cc: Dan Williams dan.j.willi...@intel.com
---
Changes v1 - v2:
- skip the descriptor cleanup tasklet if the controller is not yet idle
drivers/dma/fsldma.c | 27 ---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 8a78154..037631a 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1052,20 +1052,41 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
stat = ~FSL_DMA_SR_EOLNI;
}
- /* check that the DMA controller is really idle */
- if (!dma_is_idle(chan))
- chan_err(chan, irq: controller not idle!\n);
+ /*
+* This driver does not use this feature, therefore we shouldn't
+* ever see this bit set in the status register. However, it has
+* been observed on MPC8349EA parts.
+*/
+ if (stat FSL_DMA_SR_EOSI) {
+ chan_dbg(chan, irq: End-of-Segments INT\n);
+ stat = ~FSL_DMA_SR_EOSI;
+ }
/* check that we handled all of the bits */
if (stat)
chan_err(chan, irq: unhandled sr 0x%08x\n, stat);
/*
+* Check that the DMA controller is really idle
+*
+* Occasionally on MPC8349EA parts, a spurious End-of-Segments
+* interrupt is generated. When this happens, the controller is
+* still busy. In this case, we shouldn't run the tasklet to
+* clean up idle descriptors, since the controller is not yet idle.
+*/
+ if (!dma_is_idle(chan)) {
+ chan_err(chan, irq: controller not idle!\n);
+ goto out_skip_tasklet;
+ }
+
+ /*
* Schedule the tasklet to handle all cleanup of the current
* transaction. It will start a new transaction if there is
* one pending.
*/
tasklet_schedule(chan-tasklet);
+
+out_skip_tasklet:
chan_dbg(chan, irq: Exit\n);
return IRQ_HANDLED;
}
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v2] powerpc/dts: Add dts for p1025rdb board
On Jan 31, 2012, at 1:10 PM, Scott Wood wrote: On 01/31/2012 09:55 AM, Kumar Gala wrote: On Jan 31, 2012, at 3:51 AM, Zhicheng Fan wrote: Signed-off-by: Zhicheng Fan b32...@freeescale.com --- arch/powerpc/boot/dts/fsl/p1025si-post.dtsi | 228 + arch/powerpc/boot/dts/fsl/p1025si-pre.dtsi | 70 +++ arch/powerpc/boot/dts/p1025rdb.dts | 137 + arch/powerpc/boot/dts/p1025rdb.dtsi | 286 +++ arch/powerpc/boot/dts/p1025rdb_36b.dts | 88 5 files changed, 809 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/p1025si-post.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/p1025si-pre.dtsi create mode 100644 arch/powerpc/boot/dts/p1025rdb.dts create mode 100644 arch/powerpc/boot/dts/p1025rdb.dtsi create mode 100644 arch/powerpc/boot/dts/p1025rdb_36b.dts For the p1024 p1025 I do NOT want to add new dts/fsl/p1025si*.dtsi files. We should use the p1020 and p1021 as they are identical. Are they sufficiently software compatible that we want to use p1020/p1021 in all the compatible strings? If yes, how was this verified? They are the identical silicon just in different physical packages. It was verified by me asking the FSL marketing team. I'll work up a patch to add some comments to the p1020 p1021si dts files about being the same for p1024/p1025. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 00/25] irq_domain generalization and refinement
On Mon, Jan 30, 2012 at 08:53:44PM -0800, Olof Johansson wrote: On Fri, Jan 27, 2012 at 02:35:54PM -0700, Grant Likely wrote: Hey everyone, This patch series is ready for much wider consumption now. I'd like to get it into linux-next ASAP because there will be ARM board support depending on it. I'll wait a few days before I ask Stephen to pull this in. Stephen/Milton/Ben, any testing you can help with here would be appreciated since you've got access to a wider variety of Power machines than I do. This series has been: Tested-by: Olof Johansson o...@lixom.net On powerpc/pasemi (it's the only one I still have easy access to). Excellent, thanks Olof! g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 14/25] irq_domain: Remove irq_domain_add_simple()
On Tue, Jan 31, 2012 at 09:58:22PM +0800, Shawn Guo wrote:
On Tue, Jan 31, 2012 at 07:15:26AM -0600, Rob Herring wrote:
...
--- a/arch/arm/mach-mx5/imx51-dt.c
+++ b/arch/arm/mach-mx5/imx51-dt.c
@@ -47,7 +47,7 @@ static const struct of_dev_auxdata
imx51_auxdata_lookup[] __initconst = {
static int __init imx51_tzic_add_irq_domain(struct device_node *np,
struct device_node *interrupt_parent)
{
-irq_domain_add_simple(np, 0);
+irq_domain_add_legacy(np, 32, 0, 0, irq_domain_simple_ops,
NULL);
return 0;
}
@@ -57,7 +57,7 @@ static int __init imx51_gpio_add_irq_domain(struct
device_node *np,
static int gpio_irq_base = MXC_GPIO_IRQ_START + ARCH_NR_GPIOS;
gpio_irq_base -= 32;
-irq_domain_add_simple(np, gpio_irq_base);
+irq_domain_add_legacy(np, 32, gpio_irq_base, 0,
irq_domain_simple_ops, NULL);
The tzic on imx5 gets 128 irq lines rather than 32 here. The current
code will make any hwirq that is 32 hit the WARN_ON below in
irq_domain_legacy_revmap().
But this is the gpio controller code? Really this should be 4 domains,
but this temp fix is probably fine until you use my generic irq chip
support.
Sorry. The comment was put at the wrong place. It should be against
imx51_tzic_add_irq_domain() just above.
I didn't know how large the bank was, so I just assumed 32. If it should
be 128 then I'll change it. Please confirm (or reply with a fixup patch)
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] dmaengine/dma_slave: add context parameter to prep_slave_sg callback
On Mon, 30 Jan 2012, Vinod Koul wrote:
On Thu, 2012-01-26 at 16:22 -0500, Alexandre Bounine wrote:
As we agreed during our discussion about adding DMA Engine support for
RapidIO
subsystem, RapidIO and similar clients may benefit from adding an extra
context
parameter to device_prep_slave_sg() callback.
See https://lkml.org/lkml/2011/10/24/275 for more details.
Adding the context parameter will allow to pass client/target specific
information associated with an individual data transfer request.
In the case of RapidIO support this additional information consists of
target
destination ID and its buffer address (which is not mapped into the local
CPU
memory space). Because a single RapidIO-capable DMA channel may queue data
transfer requests to different target devices, the per-request configuration
is required.
The proposed change eliminates need for new subsystem-specific API.
Existing DMA_SLAVE clients will ignore the new parameter.
This RFC only demonstrates the API change and does not include corresponding
changes to existing DMA_SLAVE clients. Complete set of patches will be
provided
after (if) this API change is accepted.
This looks good to me. But was thinking if we need to add this new
parameter for other slave calls (circular, interleaved, memcpy...)
Yes, we (shdma.c) also need to pass additional slave configuration
information to the dmaengine driver and I also was thinking about
extending the existing API, but my ideas were going more in the direction
of adding a parameter to __dma_request_channel() along the lines of
-struct dma_chan *__dma_request_channel(dma_cap_mask_t *mask, dma_filter_fn fn,
void *fn_param);
+struct dma_chan *__dma_request_channel(dma_cap_mask_t *mask, dma_filter_fn fn,
void *fn_param,
+ struct dma_slave_desc *slave);
where struct dma_slave_desc would basically just contain an opaque slave
ID and would be embedded by dmaengine drivers in their specific
slave-configuration types. The main difference to the API change being
proposed here is, that I was going to configure DMA channels only once for
each slave upon channel allocation, whereas the proposed change does this
on a per-transfer basis. Therefore my question: do I understand the
explanation of the RapidIO DMA architecture from the above quoted thread
right, that DMA channels can be freely used by client drivers, without
binding them to specific DSP cards? In which case you, probably, don't use
DMA_PRIVATE? But that the decision - to which DSP card this specific
transfer is directed - is made by configuring the DMA channels rather than
embedded in the actual data?
Thanks
Guennadi
Signed-off-by: Alexandre Bounine alexandre.boun...@idt.com
Cc: Jassi Brar jaswinder.si...@linaro.org
Cc: Russell King r...@arm.linux.org.uk
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: Matt Porter mpor...@kernel.crashing.org
Cc: Li Yang le...@freescale.com
---
include/linux/dmaengine.h |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 679b349..79d71bb 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -575,7 +575,7 @@ struct dma_device {
struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction direction,
- unsigned long flags);
+ unsigned long flags, void *context);
struct dma_async_tx_descriptor *(*device_prep_dma_cyclic)(
struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
size_t period_len, enum dma_transfer_direction direction);
@@ -607,12 +607,13 @@ static inline int dmaengine_slave_config(struct
dma_chan *chan,
static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_single(
struct dma_chan *chan, void *buf, size_t len,
- enum dma_transfer_direction dir, unsigned long flags)
+ enum dma_transfer_direction dir, unsigned long flags, void *context)
{
struct scatterlist sg;
sg_init_one(sg, buf, len);
- return chan-device-device_prep_slave_sg(chan, sg, 1, dir, flags);
+ return chan-device-device_prep_slave_sg(chan, sg, 1, dir, flags,
+ context);
}
static inline int dmaengine_terminate_all(struct dma_chan *chan)
--
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
___
Linuxppc-dev mailing list
RE: [PATCH 1/2 v2] powerpc/dts: Add dts for p1025rdb board
-Original Message- From: linuxppc-dev-bounces+tie-fei.zang=freescale@lists.ozlabs.org [mailto:linuxppc-dev-bounces+tie-fei.zang=freescale@lists.ozlabs.org] On Behalf Of Kumar Gala Sent: Wednesday, February 01, 2012 7:44 AM To: Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org; Zhicheng Fan; Fan Zhicheng-B32736 Subject: Re: [PATCH 1/2 v2] powerpc/dts: Add dts for p1025rdb board On Jan 31, 2012, at 1:10 PM, Scott Wood wrote: On 01/31/2012 09:55 AM, Kumar Gala wrote: On Jan 31, 2012, at 3:51 AM, Zhicheng Fan wrote: Signed-off-by: Zhicheng Fan b32...@freeescale.com --- arch/powerpc/boot/dts/fsl/p1025si-post.dtsi | 228 + arch/powerpc/boot/dts/fsl/p1025si-pre.dtsi | 70 +++ arch/powerpc/boot/dts/p1025rdb.dts | 137 + arch/powerpc/boot/dts/p1025rdb.dtsi | 286 +++ arch/powerpc/boot/dts/p1025rdb_36b.dts | 88 5 files changed, 809 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/p1025si-post.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/p1025si-pre.dtsi create mode 100644 arch/powerpc/boot/dts/p1025rdb.dts create mode 100644 arch/powerpc/boot/dts/p1025rdb.dtsi create mode 100644 arch/powerpc/boot/dts/p1025rdb_36b.dts For the p1024 p1025 I do NOT want to add new dts/fsl/p1025si*.dtsi files. We should use the p1020 and p1021 as they are identical. Are they sufficiently software compatible that we want to use p1020/p1021 in all the compatible strings? If yes, how was this verified? They are the identical silicon just in different physical packages. It was verified by me asking the FSL marketing team. I'll work up a patch to add some comments to the p1020 p1021si dts files about being the same for p1024/p1025. Should we expose the information p1024/p1025 are identical to p1020/p1021 to our customer? Thanks. Roy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] dmaengine/dma_slave: add context parameter to prep_slave_sg callback
On Wed, 2012-02-01 at 01:09 +0100, Guennadi Liakhovetski wrote: On Mon, 30 Jan 2012, Vinod Koul wrote: On Thu, 2012-01-26 at 16:22 -0500, Alexandre Bounine wrote: As we agreed during our discussion about adding DMA Engine support for RapidIO subsystem, RapidIO and similar clients may benefit from adding an extra context parameter to device_prep_slave_sg() callback. See https://lkml.org/lkml/2011/10/24/275 for more details. Adding the context parameter will allow to pass client/target specific information associated with an individual data transfer request. In the case of RapidIO support this additional information consists of target destination ID and its buffer address (which is not mapped into the local CPU memory space). Because a single RapidIO-capable DMA channel may queue data transfer requests to different target devices, the per-request configuration is required. The proposed change eliminates need for new subsystem-specific API. Existing DMA_SLAVE clients will ignore the new parameter. This RFC only demonstrates the API change and does not include corresponding changes to existing DMA_SLAVE clients. Complete set of patches will be provided after (if) this API change is accepted. This looks good to me. But was thinking if we need to add this new parameter for other slave calls (circular, interleaved, memcpy...) Yes, we (shdma.c) also need to pass additional slave configuration information to the dmaengine driver and I also was thinking about extending the existing API, but my ideas were going more in the direction of adding a parameter to __dma_request_channel() along the lines of So your question is more on the lines of channel mapping/allocation? The approach here is to pass controller specific parameters which are required to setup the respective transfer. Since this is dependent on each transfer, this needs to be passed in respective prepare. The two things are completely orthogonal and shouldn't be clubbed. For your issue we need a separate debate on how to solve this... I am open to ideas... -- ~Vinod ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: next BUG: using smp_processor_id() in preemptible
On Sun, 15 Jan 2012, Benjamin Herrenschmidt wrote: On Sat, 2012-01-14 at 14:21 -0800, Hugh Dickins wrote: On Fri, 23 Dec 2011, Benjamin Herrenschmidt wrote: On Thu, 2011-12-22 at 04:07 -0800, Hugh Dickins wrote: On Mon, 5 Dec 2011, Hugh Dickins wrote: 3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of Dec 4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible [] code: startpar/1365 Dec 4 20:03:19 thorn kernel: caller is .arch_local_irq_restore+0x44/0x90 Dec 4 20:03:19 thorn kernel: Call Trace: Dec 4 20:03:19 thorn kernel: [c001b45a7c60] [c0011fe8] .show_stack+0x6c/0x16c (unreliable) Dec 4 20:03:19 thorn kernel: [c001b45a7d10] [c024318c] .debug_smp_processor_id+0xe4/0x11c Dec 4 20:03:19 thorn kernel: [c001b45a7da0] [c000e2e8] .arch_local_irq_restore+0x44/0x90 Dec 4 20:03:19 thorn kernel: [c001b45a7e30] [c0005870] .do_hash_page+0x70/0x74 Dec 4 20:03:21 thorn kernel: debug_smp_processor_id: 21950 callbacks suppressed from the u64 *next_tb = __get_cpu_var(decrementers_next_tb) in decrementer_check_overflow(): I've no idea whether it's safe just to use get_cpu_var then put_cpu_var there instead, but no hurry, I can survive with DEBUG_PREEMPT off. Still a problem in 3.2.0-rc6-next-20111222 Ah forgot about that, I'll have a look. Thanks for the reminder. I'm afraid it's now blighting Linus's tree for 3.3. Grrr, my memory is a colander... And now am in Ballarat for the week with a semi working 3g connection. I'll see what I can do. Sorry to be such a bore - you can guess what I have to say about 3.3-rc2 :() Hugh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PULL] ARM mach/irqs.h cleanup for 3.4
On Tue, Jan 31, 2012 at 01:46:58PM -0600, Rob Herring wrote: Can you please pull mach/irqs.h clean-up for 3.4. I've gotten little to no response from the affected platform maintainers. It's primarily superh and shmobile that have any significant changes though. Sorry about that, it's been in my backlog. The changes as they are are fine with me, I've got some pending work that switches to dynamic use off of nr_irqs that will make most of it redundant that I had hoped to have done in time, but it can be done incrementally at a later point in time, too. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2 v3] powerpc/85xx: Add p1020rdb-pc platform support
Signed-off-by: Zhicheng Fan b32...@freescale.com
---
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 27 ++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index f5ff911..0b04bef 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -1,7 +1,7 @@
/*
* MPC85xx RDB Board Setup
*
- * Copyright 2009 Freescale Semiconductor Inc.
+ * Copyright 2009,2012 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
@@ -121,8 +121,10 @@ static int __init mpc85xxrdb_publish_devices(void)
{
return of_platform_bus_probe(NULL, mpc85xxrdb_ids, NULL);
}
+
machine_device_initcall(p2020_rdb, mpc85xxrdb_publish_devices);
machine_device_initcall(p1020_rdb, mpc85xxrdb_publish_devices);
+machine_device_initcall(p1020_rdb_pc, mpc85xx_common_publish_devices);
/*
* Called very early, device-tree isn't unflattened
@@ -145,6 +147,15 @@ static int __init p1020_rdb_probe(void)
return 0;
}
+static int __init p1020_rdb_pc_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (of_flat_dt_is_compatible(root, fsl,P1020RDB-PC))
+ return 1;
+ return 0;
+}
+
define_machine(p2020_rdb) {
.name = P2020 RDB,
.probe = p2020_rdb_probe,
@@ -172,3 +183,17 @@ define_machine(p1020_rdb) {
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
};
+
+define_machine(p1020_rdb_pc) {
+ .name = P1020RDB-PC,
+ .probe = p1020_rdb_pc_probe,
+ .setup_arch = mpc85xx_rdb_setup_arch,
+ .init_IRQ = mpc85xx_rdb_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+ .get_irq= mpic_get_irq,
+ .restart= fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2 v3] powerpc/dts: Add dts for p1020rdb-pc board
P1020RDB-PC Overview
--
1Gbyte DDR3 SDRAM
32 Mbyte NAND flash
10 16Mbyte NOR flash
16 Mbyte SPI flash
SD connector to interface with the SD memory card
Real-time clock on I2C bus
PCIe:
- x1 PCIe slot
- x1 mini-PCIe slot
10/100/1000 BaseT Ethernet ports:
- eTSEC1, RGMII: one 10/100/1000 port using VitesseTM VSC7385 L2 switch
- eTSEC2, SGMII: one 10/100/1000 port using VitesseTM VSC8221
- eTSEC3, RGMII: one 10/100/1000 port using AtherosTM AR8021
USB 2.0 port:
- Two USB2.0 Type A receptacles
- One USB2.0 signal to Mini PCIe slot
Dual RJ45 UART ports:
- DUART interface: supports two UARTs up to 115200 bps for console display
Signed-off-by: Zhicheng Fan b32...@freescale.com
---
arch/powerpc/boot/dts/p1020rdb-pc.dts| 90
arch/powerpc/boot/dts/p1020rdb-pc.dtsi | 247 ++
arch/powerpc/boot/dts/p1020rdb-pc_36b.dts| 90
arch/powerpc/boot/dts/p1020rdb-pc_camp_core0.dts | 64 ++
arch/powerpc/boot/dts/p1020rdb-pc_camp_core1.dts | 142 +
5 files changed, 633 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p1020rdb-pc.dts
create mode 100644 arch/powerpc/boot/dts/p1020rdb-pc.dtsi
create mode 100644 arch/powerpc/boot/dts/p1020rdb-pc_36b.dts
create mode 100644 arch/powerpc/boot/dts/p1020rdb-pc_camp_core0.dts
create mode 100644 arch/powerpc/boot/dts/p1020rdb-pc_camp_core1.dts
diff --git a/arch/powerpc/boot/dts/p1020rdb-pc.dts
b/arch/powerpc/boot/dts/p1020rdb-pc.dts
new file mode 100644
index 000..5c333b0
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1020rdb-pc.dts
@@ -0,0 +1,90 @@
+/*
+ * P1020 RDB-PC Device Tree Source
+ *
+ * Copyright 2012 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/p1020si-pre.dtsi
+/ {
+ model = fsl,P1020RDB-PC;
+ compatible = fsl,P1020RDB-PC;
+
+ memory {
+ device_type = memory;
+ };
+
+ 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 0xff80 0x0004
+ 0x2 0x0 0x0 0xffb0 0x0002
+ 0x3 0x0 0x0 0xffa0 0x0002;
+ };
+
+ soc: soc@ffe0 {
+ ranges = 0x0 0x0 0xffe0 0x10;
+ };
+
+ pci0: pcie@ffe09000 {
+ ranges = 0x200 0x0 0xa000 0 0xa000 0x0 0x2000
+ 0x100 0x0 0x 0 0xffc1 0x0 0x1;
+ reg = 0 0xffe09000 0 0x1000;
+ pcie@0 {
+ ranges = 0x200 0x0 0xa000
+ 0x200 0x0 0xa000
+ 0x0 0x2000
+
+ 0x100 0x0 0x0
+ 0x100 0x0 0x0
+ 0x0 0x10;
+ };
+ };
+
+ pci1: pcie@ffe0a000 {
+ reg = 0 0xffe0a000 0 0x1000;
+ ranges = 0x200 0x0 0x8000 0 0x8000 0x0 0x2000
+ 0x100 0x0 0x 0
