* [PATCH 4/7] [PPC] Stop using ppc_sys for Xilinx Virtex boards
From: Grant Likely @ 2007-04-27 19:50 UTC (permalink / raw)
To: linuxppc-embedded, paulus; +Cc: Peter Korsgaard, Andrei Konovalov, Rick Moleres
In-Reply-To: <11777034141879-git-send-email-grant.likely@secretlab.ca>
The arch/ppc/syslib/ppc_sys.c infrastructure does not work well for the
virtex ports. Move the ml300 and ml403 board ports over to use the new
virtex_devices infrastructure.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
---
arch/ppc/platforms/4xx/Makefile | 1 -
arch/ppc/platforms/4xx/virtex.c | 56 ----------------------------
arch/ppc/platforms/4xx/virtex.h | 7 +---
arch/ppc/platforms/4xx/xilinx_ml300.c | 64 ++------------------------------
arch/ppc/platforms/4xx/xilinx_ml403.c | 65 ++-------------------------------
arch/ppc/syslib/Makefile | 3 +-
include/asm-ppc/ppc_sys.h | 2 -
7 files changed, 11 insertions(+), 187 deletions(-)
delete mode 100644 arch/ppc/platforms/4xx/virtex.c
diff --git a/arch/ppc/platforms/4xx/Makefile b/arch/ppc/platforms/4xx/Makefile
index fa6610b..723ad79 100644
--- a/arch/ppc/platforms/4xx/Makefile
+++ b/arch/ppc/platforms/4xx/Makefile
@@ -28,5 +28,4 @@ obj-$(CONFIG_440SP) += ibm440sp.o
obj-$(CONFIG_440SPE) += ppc440spe.o
obj-$(CONFIG_405EP) += ibm405ep.o
obj-$(CONFIG_405GPR) += ibm405gpr.o
-obj-$(CONFIG_XILINX_VIRTEX) += virtex.o
diff --git a/arch/ppc/platforms/4xx/virtex.c b/arch/ppc/platforms/4xx/virtex.c
deleted file mode 100644
index 133a831..0000000
--- a/arch/ppc/platforms/4xx/virtex.c
+++ /dev/null
@@ -1,56 +0,0 @@
-/*
- * Virtex-II Pro & Virtex-4 FX common infrastructure
- *
- * Maintainer: Grant Likely <grant.likely@secretlab.ca>
- *
- * Copyright 2005 Secret Lab Technologies Ltd.
- * Copyright 2005 General Dynamics Canada Ltd.
- * Copyright 2005 Freescale Semiconductor Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-
-#include <linux/init.h>
-#include <linux/module.h>
-#include <linux/device.h>
-#include <linux/serial_8250.h>
-#include <asm/ppc_sys.h>
-#include <platforms/4xx/virtex.h>
-#include <platforms/4xx/xparameters/xparameters.h>
-
-#define XPAR_UART(num) { \
- .mapbase = XPAR_UARTNS550_##num##_BASEADDR + 3, \
- .irq = XPAR_INTC_0_UARTNS550_##num##_VEC_ID, \
- .iotype = UPIO_MEM, \
- .uartclk = XPAR_UARTNS550_##num##_CLOCK_FREQ_HZ, \
- .flags = UPF_BOOT_AUTOCONF, \
- .regshift = 2, \
- }
-
-struct plat_serial8250_port serial_platform_data[] = {
-#ifdef XPAR_UARTNS550_0_BASEADDR
- XPAR_UART(0),
-#endif
-#ifdef XPAR_UARTNS550_1_BASEADDR
- XPAR_UART(1),
-#endif
-#ifdef XPAR_UARTNS550_2_BASEADDR
- XPAR_UART(2),
-#endif
-#ifdef XPAR_UARTNS550_3_BASEADDR
- XPAR_UART(3),
-#endif
- { }, /* terminated by empty record */
-};
-
-struct platform_device ppc_sys_platform_devices[] = {
- [VIRTEX_UART] = {
- .name = "serial8250",
- .id = 0,
- .dev.platform_data = serial_platform_data,
- },
-};
-
diff --git a/arch/ppc/platforms/4xx/virtex.h b/arch/ppc/platforms/4xx/virtex.h
index e9f58a7..4fc76da 100644
--- a/arch/ppc/platforms/4xx/virtex.h
+++ b/arch/ppc/platforms/4xx/virtex.h
@@ -19,13 +19,8 @@
#if !defined(BASE_BAUD)
#define BASE_BAUD (0) /* dummy value; not used */
#endif
-
-/* Device type enumeration for platform bus definitions */
+
#ifndef __ASSEMBLY__
-enum ppc_sys_devices {
- VIRTEX_UART, NUM_PPC_SYS_DEVS,
-};
-
typedef struct board_info {
unsigned int bi_memsize; /* DRAM installed, in bytes */
unsigned char bi_enetaddr[6]; /* Local Ethernet MAC address */
diff --git a/arch/ppc/platforms/4xx/xilinx_ml300.c b/arch/ppc/platforms/4xx/xilinx_ml300.c
index 4e4aca4..6e522fe 100644
--- a/arch/ppc/platforms/4xx/xilinx_ml300.c
+++ b/arch/ppc/platforms/4xx/xilinx_ml300.c
@@ -18,9 +18,9 @@
#include <linux/serialP.h>
#include <asm/io.h>
#include <asm/machdep.h>
-#include <asm/ppc_sys.h>
#include <syslib/gen550.h>
+#include <syslib/virtex_devices.h>
#include <platforms/4xx/xparameters/xparameters.h>
/*
@@ -53,25 +53,9 @@
* ppc4xx_pic_init arch/ppc/syslib/xilinx_pic.c
*/
-/* Board specifications structures */
-struct ppc_sys_spec *cur_ppc_sys_spec;
-struct ppc_sys_spec ppc_sys_specs[] = {
- {
- /* Only one entry, always assume the same design */
- .ppc_sys_name = "Xilinx ML300 Reference Design",
- .mask = 0x00000000,
- .value = 0x00000000,
- .num_devices = 1,
- .device_list = (enum ppc_sys_devices[])
- {
- VIRTEX_UART,
- },
- },
-};
const char* virtex_machine_name = "ML300 Reference Design";
#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
-
static volatile unsigned *powerdown_base =
(volatile unsigned *) XPAR_POWER_0_POWERDOWN_BASEADDR;
@@ -96,52 +80,14 @@ ml300_map_io(void)
#endif
}
-/* Early serial support functions */
-static void __init
-ml300_early_serial_init(int num, struct plat_serial8250_port *pdata)
-{
-#if defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB)
- struct uart_port serial_req;
-
- memset(&serial_req, 0, sizeof(serial_req));
- serial_req.mapbase = pdata->mapbase;
- serial_req.membase = pdata->membase;
- serial_req.irq = pdata->irq;
- serial_req.uartclk = pdata->uartclk;
- serial_req.regshift = pdata->regshift;
- serial_req.iotype = pdata->iotype;
- serial_req.flags = pdata->flags;
- gen550_init(num, &serial_req);
-#endif
-}
-
-void __init
-ml300_early_serial_map(void)
-{
-#ifdef CONFIG_SERIAL_8250
- struct plat_serial8250_port *pdata;
- int i = 0;
-
- pdata = (struct plat_serial8250_port *) ppc_sys_get_pdata(VIRTEX_UART);
- while(pdata && pdata->flags)
- {
- pdata->membase = ioremap(pdata->mapbase, 0x100);
- ml300_early_serial_init(i, pdata);
- pdata++;
- i++;
- }
-#endif /* CONFIG_SERIAL_8250 */
-}
-
void __init
ml300_setup_arch(void)
{
- ml300_early_serial_map();
+ virtex_early_serial_map();
ppc4xx_setup_arch(); /* calls ppc4xx_find_bridges() */
/* Identify the system */
- printk(KERN_INFO "Xilinx Virtex-II Pro port\n");
- printk(KERN_INFO "Port by MontaVista Software, Inc. (source@mvista.com)\n");
+ printk(KERN_INFO "Xilinx ML300 Reference System (Virtex-II Pro)\n");
}
/* Called after board_setup_irq from ppc4xx_init_IRQ(). */
@@ -157,8 +103,6 @@ platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
{
ppc4xx_init(r3, r4, r5, r6, r7);
- identify_ppc_sys_by_id(mfspr(SPRN_PVR));
-
ppc_md.setup_arch = ml300_setup_arch;
ppc_md.setup_io_mappings = ml300_map_io;
ppc_md.init_IRQ = ml300_init_irq;
@@ -168,7 +112,7 @@ platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
#endif
#ifdef CONFIG_KGDB
- ppc_md.early_serial_map = ml300_early_serial_map;
+ ppc_md.early_serial_map = virtex_early_serial_map;
#endif
}
diff --git a/arch/ppc/platforms/4xx/xilinx_ml403.c b/arch/ppc/platforms/4xx/xilinx_ml403.c
index c98e40a..bc3ace3 100644
--- a/arch/ppc/platforms/4xx/xilinx_ml403.c
+++ b/arch/ppc/platforms/4xx/xilinx_ml403.c
@@ -1,11 +1,9 @@
/*
- * arch/ppc/platforms/4xx/xilinx_ml403.c
- *
* Xilinx ML403 evaluation board initialization
*
* Author: Grant Likely <grant.likely@secretlab.ca>
*
- * 2005 (c) Secret Lab Technologies Ltd.
+ * 2005-2007 (c) Secret Lab Technologies Ltd.
* 2002-2004 (c) MontaVista Software, Inc.
*
* This file is licensed under the terms of the GNU General Public License
@@ -22,9 +20,9 @@
#include <linux/serialP.h>
#include <asm/io.h>
#include <asm/machdep.h>
-#include <asm/ppc_sys.h>
#include <syslib/gen550.h>
+#include <syslib/virtex_devices.h>
#include <platforms/4xx/xparameters/xparameters.h>
/*
@@ -57,25 +55,9 @@
* ppc4xx_pic_init arch/ppc/syslib/xilinx_pic.c
*/
-/* Board specifications structures */
-struct ppc_sys_spec *cur_ppc_sys_spec;
-struct ppc_sys_spec ppc_sys_specs[] = {
- {
- /* Only one entry, always assume the same design */
- .ppc_sys_name = "Xilinx ML403 Reference Design",
- .mask = 0x00000000,
- .value = 0x00000000,
- .num_devices = 1,
- .device_list = (enum ppc_sys_devices[])
- {
- VIRTEX_UART,
- },
- },
-};
const char* virtex_machine_name = "ML403 Reference Design";
#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
-
static volatile unsigned *powerdown_base =
(volatile unsigned *) XPAR_POWER_0_POWERDOWN_BASEADDR;
@@ -100,47 +82,10 @@ ml403_map_io(void)
#endif
}
-/* Early serial support functions */
-static void __init
-ml403_early_serial_init(int num, struct plat_serial8250_port *pdata)
-{
-#if defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB)
- struct uart_port serial_req;
-
- memset(&serial_req, 0, sizeof(serial_req));
- serial_req.mapbase = pdata->mapbase;
- serial_req.membase = pdata->membase;
- serial_req.irq = pdata->irq;
- serial_req.uartclk = pdata->uartclk;
- serial_req.regshift = pdata->regshift;
- serial_req.iotype = pdata->iotype;
- serial_req.flags = pdata->flags;
- gen550_init(num, &serial_req);
-#endif
-}
-
-void __init
-ml403_early_serial_map(void)
-{
-#ifdef CONFIG_SERIAL_8250
- struct plat_serial8250_port *pdata;
- int i = 0;
-
- pdata = (struct plat_serial8250_port *) ppc_sys_get_pdata(VIRTEX_UART);
- while(pdata && pdata->flags)
- {
- pdata->membase = ioremap(pdata->mapbase, 0x100);
- ml403_early_serial_init(i, pdata);
- pdata++;
- i++;
- }
-#endif /* CONFIG_SERIAL_8250 */
-}
-
void __init
ml403_setup_arch(void)
{
- ml403_early_serial_map();
+ virtex_early_serial_map();
ppc4xx_setup_arch(); /* calls ppc4xx_find_bridges() */
/* Identify the system */
@@ -160,8 +105,6 @@ platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
{
ppc4xx_init(r3, r4, r5, r6, r7);
- identify_ppc_sys_by_id(mfspr(SPRN_PVR));
-
ppc_md.setup_arch = ml403_setup_arch;
ppc_md.setup_io_mappings = ml403_map_io;
ppc_md.init_IRQ = ml403_init_irq;
@@ -171,7 +114,7 @@ platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
#endif
#ifdef CONFIG_KGDB
- ppc_md.early_serial_map = ml403_early_serial_map;
+ ppc_md.early_serial_map = virtex_early_serial_map;
#endif
}
diff --git a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
index 0991111..9569415 100644
--- a/arch/ppc/syslib/Makefile
+++ b/arch/ppc/syslib/Makefile
@@ -18,7 +18,8 @@ obj-$(CONFIG_440SP) += ibm440gx_common.o ibm440sp_common.o
obj-$(CONFIG_440SPE) += ibm440gx_common.o ibm440sp_common.o ppc440spe_pcie.o
ifeq ($(CONFIG_4xx),y)
ifeq ($(CONFIG_XILINX_VIRTEX),y)
-obj-$(CONFIG_40x) += xilinx_pic.o ppc_sys.o
+obj-$(CONFIG_40x) += xilinx_pic.o
+obj-y += virtex_devices.o
else
ifeq ($(CONFIG_403),y)
obj-$(CONFIG_40x) += ppc403_pic.o
diff --git a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
index 40f197a..de99e92 100644
--- a/include/asm-ppc/ppc_sys.h
+++ b/include/asm-ppc/ppc_sys.h
@@ -33,8 +33,6 @@
#include <asm/mpc52xx.h>
#elif defined(CONFIG_MPC10X_BRIDGE)
#include <asm/mpc10x.h>
-#elif defined(CONFIG_XILINX_VIRTEX)
-#include <platforms/4xx/virtex.h>
#else
#error "need definition of ppc_sys_devices"
#endif
--
1.5.1
^ permalink raw reply related
* [PATCH 5/7] [PPC] Add uartlite boot console driver for the zImage wrapper
From: Grant Likely @ 2007-04-27 19:50 UTC (permalink / raw)
To: linuxppc-embedded, paulus; +Cc: Peter Korsgaard, Andrei Konovalov, Rick Moleres
In-Reply-To: <11777034152490-git-send-email-grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
---
arch/ppc/boot/common/misc-common.c | 15 +++++++++----
arch/ppc/boot/simple/Makefile | 1 +
arch/ppc/boot/simple/uartlite_tty.c | 37 +++++++++++++++++++++++++++++++++++
3 files changed, 48 insertions(+), 5 deletions(-)
create mode 100644 arch/ppc/boot/simple/uartlite_tty.c
diff --git a/arch/ppc/boot/common/misc-common.c b/arch/ppc/boot/common/misc-common.c
index 8e1fccd..9589969 100644
--- a/arch/ppc/boot/common/misc-common.c
+++ b/arch/ppc/boot/common/misc-common.c
@@ -57,7 +57,8 @@ unsigned char *ISA_io = NULL;
#if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \
|| defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \
- || defined(CONFIG_SERIAL_MPSC_CONSOLE)
+ || defined(CONFIG_SERIAL_MPSC_CONSOLE) \
+ || defined(CONFIG_SERIAL_UARTLITE_CONSOLE)
extern unsigned long com_port;
extern int serial_tstc(unsigned long com_port);
@@ -80,7 +81,8 @@ int tstc(void)
{
#if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \
|| defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \
- || defined(CONFIG_SERIAL_MPSC_CONSOLE)
+ || defined(CONFIG_SERIAL_MPSC_CONSOLE) \
+ || defined(CONFIG_SERIAL_UARTLITE_CONSOLE)
if(keyb_present)
return (CRT_tstc() || serial_tstc(com_port));
else
@@ -95,7 +97,8 @@ int getc(void)
while (1) {
#if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \
|| defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \
- || defined(CONFIG_SERIAL_MPSC_CONSOLE)
+ || defined(CONFIG_SERIAL_MPSC_CONSOLE) \
+ || defined(CONFIG_SERIAL_UARTLITE_CONSOLE)
if (serial_tstc(com_port))
return (serial_getc(com_port));
#endif /* serial console */
@@ -112,7 +115,8 @@ putc(const char c)
#if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \
|| defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \
- || defined(CONFIG_SERIAL_MPSC_CONSOLE)
+ || defined(CONFIG_SERIAL_MPSC_CONSOLE) \
+ || defined(CONFIG_SERIAL_UARTLITE_CONSOLE)
serial_putc(com_port, c);
if ( c == '\n' )
serial_putc(com_port, '\r');
@@ -161,7 +165,8 @@ void puts(const char *s)
while ( ( c = *s++ ) != '\0' ) {
#if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \
|| defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \
- || defined(CONFIG_SERIAL_MPSC_CONSOLE)
+ || defined(CONFIG_SERIAL_MPSC_CONSOLE) \
+ || defined(CONFIG_SERIAL_UARTLITE_CONSOLE)
serial_putc(com_port, c);
if ( c == '\n' ) serial_putc(com_port, '\r');
#endif /* serial console */
diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile
index bcfb6cd..5b87779 100644
--- a/arch/ppc/boot/simple/Makefile
+++ b/arch/ppc/boot/simple/Makefile
@@ -201,6 +201,7 @@ boot-$(CONFIG_8260) += m8260_tty.o
endif
boot-$(CONFIG_SERIAL_MPC52xx_CONSOLE) += mpc52xx_tty.o
boot-$(CONFIG_SERIAL_MPSC_CONSOLE) += mv64x60_tty.o
+boot-$(CONFIG_SERIAL_UARTLITE_CONSOLE) += uartlite_tty.o
LIBS := $(common)/lib.a $(bootlib)/lib.a
ifeq ($(CONFIG_PPC_PREP),y)
diff --git a/arch/ppc/boot/simple/uartlite_tty.c b/arch/ppc/boot/simple/uartlite_tty.c
new file mode 100644
index 0000000..0eae1ea
--- /dev/null
+++ b/arch/ppc/boot/simple/uartlite_tty.c
@@ -0,0 +1,37 @@
+/*
+ * Xilinx UARTLITE bootloader driver
+ *
+ * Copyright (c) 2007 Secret Lab Technologies Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/types.h>
+#include <asm/serial.h>
+#include <asm/io.h>
+#include <platforms/4xx/xparameters/xparameters.h>
+
+#define UARTLITE_BASEADDR ((void*)(XPAR_UARTLITE_0_BASEADDR))
+
+void
+serial_putc(unsigned long com_port, unsigned char c)
+{
+ while ((in_be32(UARTLITE_BASEADDR + 0x8) & 0x08) != 0); /* spin */
+ out_be32(UARTLITE_BASEADDR + 0x4, c);
+}
+
+unsigned char
+serial_getc(unsigned long com_port)
+{
+ while ((in_be32(UARTLITE_BASEADDR + 0x8) & 0x01) == 0); /* spin */
+ return in_be32(UARTLITE_BASEADDR);
+}
+
+int
+serial_tstc(unsigned long com_port)
+{
+ return ((in_be32(UARTLITE_BASEADDR + 0x8) & 0x01) != 0);
+}
--
1.5.1
^ permalink raw reply related
* [PATCH 6/7] [PPC] Add sane defaults for Xilinx EDK generated xparameters files
From: Grant Likely @ 2007-04-27 19:50 UTC (permalink / raw)
To: linuxppc-embedded, paulus; +Cc: Peter Korsgaard, Andrei Konovalov, Rick Moleres
In-Reply-To: <11777034153009-git-send-email-grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/ppc/platforms/4xx/xparameters/xparameters.h | 60 ++++++++++++++++++++++
1 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h b/arch/ppc/platforms/4xx/xparameters/xparameters.h
index 66ec5f3..01aa043 100644
--- a/arch/ppc/platforms/4xx/xparameters/xparameters.h
+++ b/arch/ppc/platforms/4xx/xparameters/xparameters.h
@@ -34,3 +34,63 @@
.io_type = SERIAL_IO_MEM, \
},
#endif
+
+/*
+ * A few reasonable defaults for the #defines which could be missing depending
+ * on the IP version or variant (e.g. OPB vs PLB)
+ */
+
+#ifndef XPAR_EMAC_0_CAM_EXIST
+#define XPAR_EMAC_0_CAM_EXIST 0
+#endif
+#ifndef XPAR_EMAC_0_JUMBO_EXIST
+#define XPAR_EMAC_0_JUMBO_EXIST 0
+#endif
+#ifndef XPAR_EMAC_0_TX_DRE_TYPE
+#define XPAR_EMAC_0_TX_DRE_TYPE 0
+#endif
+#ifndef XPAR_EMAC_0_RX_DRE_TYPE
+#define XPAR_EMAC_0_RX_DRE_TYPE 0
+#endif
+#ifndef XPAR_EMAC_0_TX_INCLUDE_CSUM
+#define XPAR_EMAC_0_TX_INCLUDE_CSUM 0
+#endif
+#ifndef XPAR_EMAC_0_RX_INCLUDE_CSUM
+#define XPAR_EMAC_0_RX_INCLUDE_CSUM 0
+#endif
+
+#ifndef XPAR_EMAC_1_CAM_EXIST
+#define XPAR_EMAC_1_CAM_EXIST 0
+#endif
+#ifndef XPAR_EMAC_1_JUMBO_EXIST
+#define XPAR_EMAC_1_JUMBO_EXIST 0
+#endif
+#ifndef XPAR_EMAC_1_TX_DRE_TYPE
+#define XPAR_EMAC_1_TX_DRE_TYPE 0
+#endif
+#ifndef XPAR_EMAC_1_RX_DRE_TYPE
+#define XPAR_EMAC_1_RX_DRE_TYPE 0
+#endif
+#ifndef XPAR_EMAC_1_TX_INCLUDE_CSUM
+#define XPAR_EMAC_1_TX_INCLUDE_CSUM 0
+#endif
+#ifndef XPAR_EMAC_1_RX_INCLUDE_CSUM
+#define XPAR_EMAC_1_RX_INCLUDE_CSUM 0
+#endif
+
+#ifndef XPAR_GPIO_0_IS_DUAL
+#define XPAR_GPIO_0_IS_DUAL 0
+#endif
+#ifndef XPAR_GPIO_1_IS_DUAL
+#define XPAR_GPIO_1_IS_DUAL 0
+#endif
+#ifndef XPAR_GPIO_2_IS_DUAL
+#define XPAR_GPIO_2_IS_DUAL 0
+#endif
+#ifndef XPAR_GPIO_3_IS_DUAL
+#define XPAR_GPIO_3_IS_DUAL 0
+#endif
+#ifndef XPAR_GPIO_4_IS_DUAL
+#define XPAR_GPIO_4_IS_DUAL 0
+#endif
+
--
1.5.1
^ permalink raw reply related
* [PATCH 7/7] [PPC] Don't define a custom bd_t for Xilixn Virtex based boards.
From: Grant Likely @ 2007-04-27 19:50 UTC (permalink / raw)
To: linuxppc-embedded, paulus; +Cc: Peter Korsgaard, Andrei Konovalov, Rick Moleres
In-Reply-To: <11777034164090-git-send-email-grant.likely@secretlab.ca>
Why create a platform specific board_info structure that is hacked
together, ugly, and dangerous, when we've got a perfectly fine common
board_info structure that is hacked-together, ugly and dangerous.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/ppc/platforms/4xx/virtex.h | 15 +--------------
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/arch/ppc/platforms/4xx/virtex.h b/arch/ppc/platforms/4xx/virtex.h
index 4fc76da..7382804 100644
--- a/arch/ppc/platforms/4xx/virtex.h
+++ b/arch/ppc/platforms/4xx/virtex.h
@@ -14,6 +14,7 @@
#define __ASM_VIRTEX_H__
#include <asm/ibm405.h>
+#include <asm/ppcboot.h>
/* Ugly, ugly, ugly! BASE_BAUD defined here to keep 8250.c happy. */
#if !defined(BASE_BAUD)
@@ -21,22 +22,8 @@
#endif
#ifndef __ASSEMBLY__
-typedef struct board_info {
- unsigned int bi_memsize; /* DRAM installed, in bytes */
- unsigned char bi_enetaddr[6]; /* Local Ethernet MAC address */
- unsigned int bi_intfreq; /* Processor speed, in Hz */
- unsigned int bi_busfreq; /* PLB Bus speed, in Hz */
- unsigned int bi_pci_busfreq; /* PCI Bus speed, in Hz */
-} bd_t;
-
-/* Some 4xx parts use a different timebase frequency from the internal clock.
- * the Virtex 405 does not, so just use a macro to make tbfreq match intfreq
-*/
-#define bi_tbfreq bi_intfreq
-
extern const char* virtex_machine_name;
#define PPC4xx_MACHINE_NAME (virtex_machine_name)
-
#endif /* !__ASSEMBLY__ */
/* We don't need anything mapped. Size of zero will accomplish that. */
--
1.5.1
^ permalink raw reply related
* [PATCH] bootwrapper: CONFIG_ -> CONFIG_DEVICE_TREE
From: Scott Wood @ 2007-04-27 20:32 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
A usage of CONFIG_DEVICE_TREE got accidentally truncated; this
fix allows out-of-tree dts files to work.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/boot/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 9d7b877..3716594 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -166,7 +166,7 @@ cuboot-plat-$(CONFIG_83xx) += 83xx
cuboot-plat-$(CONFIG_85xx) += 85xx
cuboot-plat-y += unknown-platform
-dts = $(if $(shell echo $(CONFIG_) | grep '^/'),\
+dts = $(if $(shell echo $(CONFIG_DEVICE_TREE) | grep '^/'),\
,$(srctree)/$(src)/dts/)$(CONFIG_DEVICE_TREE)
$(obj)/cuImage: vmlinux $(wrapperbits)
--
1.5.0.3
^ permalink raw reply related
* Re: [PATCH 11/13] powerpc: Add DTS file for the Motorola PrPMC2800 platform
From: Mark A. Greer @ 2007-04-27 20:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20070426000151.GM4046@mag.az.mvista.com>
[PATCH 11/13] powerpc: Add DTS file for the Motorola PrPMC2800 platform
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
---
prpmc2800.dts | 321 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 321 insertions(+)
Index: powerpc/arch/powerpc/boot/dts/prpmc2800.dts
===================================================================
--- /dev/null
+++ powerpc/arch/powerpc/boot/dts/prpmc2800.dts
@@ -0,0 +1,321 @@
+/* Device Tree Source for Motorola PrPMC2800
+ *
+ * Author: Mark A. Greer <mgreer@mvista.com>
+ *
+ * 2007 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ *
+ * To build:
+ * dtc -I dts -O asm -o prpmc2800.S -V 16 -b 0 prpmc2800.dts
+ * dtc -I dts -O dtb -o prpmc2800.dtb -V 16 -b 0 prpmc2800.dts
+ */
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "PrPMC280/PrPMC2800"; /* Updated by bootwrapper */
+ compatible = "PrPMC2800";
+ coherency-off;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,7447 {
+ device_type = "cpu";
+ reg = <0>;
+ clock-frequency = <0>; /* Set by bootwrapper */
+ bus-frequency = <7f28155>; /* 133.333333 MHz */
+ timebase-frequency = <1fca055>; /* 33.333333 MHz */
+ /* Following required by dtc but not used */
+ i-cache-line-size = <0>;
+ d-cache-line-size = <0>;
+ i-cache-size = <0>;
+ d-cache-size = <0>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <00000000 00000000>; /* Set by bootwrapper */
+ };
+
+ mv64x60@f1000000 { /* Marvell Discovery */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <1>;
+ device_type = "mv64360";
+ compatible = "mv64x60";
+ clock-frequency = <7f28155>; /* 133.333333 Mhz */
+ reg = <f1000000 00010000>;
+ virtual-reg = <f1000000>;
+ ranges = <88000000 88000000 01000000 /* PCI 0 I/O Space */
+ 80000000 80000000 08000000 /* PCI 0 MEM Space */
+ a0000000 a0000000 04000000 /* User FLASH */
+ 00000000 f1000000 00010000 /* Bridge's regs */
+ f2000000 f2000000 00040000>; /* Integrated SRAM */
+
+ flash@a0000000 {
+ device_type = "rom";
+ compatible = "direct-mapped";
+ reg = <a0000000 0>; /* Size set by bootwrapper */
+ probe-type = "CFI";
+ bank-width = <4>;
+ partitions = <00000000 00100000 /* RO */
+ 00100000 00040001 /* RW */
+ 00140000 00400000 /* RO */
+ 00540000 039c0000 /* RO */
+ 03f00000 00100000>; /* RO */
+ partition-names = "FW Image A\0FW Config Data\0Kernel Image\0Filesystem\0FW Image B";
+ };
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "mdio";
+ compatible = "mv64x60-mdio";
+ ethernet-phy@1 {
+ device_type = "ethernet-phy";
+ compatible = "bcm5421";
+ interrupts = <4c>; /* GPP 12 */
+ interrupt-parent = <&/mv64x60/pic>;
+ reg = <1>;
+ };
+ ethernet-phy@3 {
+ device_type = "ethernet-phy";
+ compatible = "bcm5421";
+ interrupts = <4c>; /* GPP 12 */
+ interrupt-parent = <&/mv64x60/pic>;
+ reg = <3>;
+ };
+ };
+
+ ethernet@2000 { /* mac-address set by bootwrapper */
+ reg = <2000 2000>;
+ eth0 {
+ device_type = "network";
+ compatible = "mv64x60-eth";
+ block-index = <0>;
+ interrupts = <20>;
+ interrupt-parent = <&/mv64x60/pic>;
+ phy = <&/mv64x60/mdio/ethernet-phy@1>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ };
+ eth1 {
+ device_type = "network";
+ compatible = "mv64x60-eth";
+ block-index = <1>;
+ interrupts = <21>;
+ interrupt-parent = <&/mv64x60/pic>;
+ phy = <&/mv64x60/mdio/ethernet-phy@3>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ };
+ };
+
+ sdma@4000 {
+ device_type = "dma";
+ compatible = "mv64x60-sdma";
+ reg = <4000 c18>;
+ virtual-reg = <f1004000>;
+ interrupt-base = <0>;
+ interrupts = <24>;
+ interrupt-parent = <&/mv64x60/pic>;
+ };
+
+ sdma@6000 {
+ device_type = "dma";
+ compatible = "mv64x60-sdma";
+ reg = <6000 c18>;
+ virtual-reg = <f1006000>;
+ interrupt-base = <0>;
+ interrupts = <26>;
+ interrupt-parent = <&/mv64x60/pic>;
+ };
+
+ brg@b200 {
+ device_type = "brg";
+ compatible = "mv64x60-brg";
+ reg = <b200 8>;
+ clock-src = <8>;
+ clock-frequency = <7ed6b40>;
+ current-speed = <2580>;
+ bcr = <0>;
+ };
+
+ brg@b208 {
+ device_type = "brg";
+ compatible = "mv64x60-brg";
+ reg = <b208 8>;
+ clock-src = <8>;
+ clock-frequency = <7ed6b40>;
+ current-speed = <2580>;
+ bcr = <0>;
+ };
+
+ cunit@f200 {
+ device_type = "mv64x60-cunit";
+ reg = <f200 200>;
+ };
+
+ mpscrouting@b400 {
+ device_type = "mpscrouting";
+ reg = <b400 c>;
+ };
+
+ mpscintr@b800 {
+ device_type = "mpscintr";
+ reg = <b800 100>;
+ virtual-reg = <f100b800>;
+ };
+
+ mpsc@8000 {
+ device_type = "serial";
+ compatible = "mpsc";
+ reg = <8000 38>;
+ virtual-reg = <f1008000>;
+ sdma = <&/mv64x60/sdma@4000>;
+ brg = <&/mv64x60/brg@b200>;
+ cunit = <&/mv64x60/cunit@f200>;
+ mpscrouting = <&/mv64x60/mpscrouting@b400>;
+ mpscintr = <&/mv64x60/mpscintr@b800>;
+ block-index = <0>;
+ max_idle = <28>;
+ chr_1 = <0>;
+ chr_2 = <0>;
+ chr_10 = <3>;
+ mpcr = <0>;
+ interrupts = <28>;
+ interrupt-parent = <&/mv64x60/pic>;
+ };
+
+ mpsc@9000 {
+ device_type = "serial";
+ compatible = "mpsc";
+ reg = <9000 38>;
+ virtual-reg = <f1009000>;
+ sdma = <&/mv64x60/sdma@6000>;
+ brg = <&/mv64x60/brg@b208>;
+ cunit = <&/mv64x60/cunit@f200>;
+ mpscrouting = <&/mv64x60/mpscrouting@b400>;
+ mpscintr = <&/mv64x60/mpscintr@b800>;
+ block-index = <1>;
+ max_idle = <28>;
+ chr_1 = <0>;
+ chr_2 = <0>;
+ chr_10 = <3>;
+ mpcr = <0>;
+ interrupts = <2a>;
+ interrupt-parent = <&/mv64x60/pic>;
+ };
+
+ i2c@c000 {
+ device_type = "i2c";
+ compatible = "mv64x60-i2c";
+ reg = <c000 20>;
+ virtual-reg = <f100c000>;
+ freq_m = <8>;
+ freq_n = <3>;
+ timeout = <3e8>; /* 1000 = 1 second */
+ retries = <1>;
+ interrupts = <25>;
+ interrupt-parent = <&/mv64x60/pic>;
+ };
+
+ pic {
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ device_type = "mv64x60-pic";
+ compatible = "mv64x60-pic";
+ reg = <0000 88>;
+ interrupt-controller;
+ };
+
+ mpp@f000 {
+ device_type = "mv64x60-mpp";
+ compatible = "mv64x60-mpp";
+ reg = <f000 10>;
+ };
+
+ gpp@f100 {
+ device_type = "mv64x60-gpp";
+ compatible = "mv64x60-gpp";
+ reg = <f100 20>;
+ };
+
+ pci@80000000 {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ device_type = "pci";
+ compatible = "mv64x60-pci";
+ reg = <0cf8 8>;
+ ranges = <01000000 0 0 88000000 0 01000000
+ 02000000 0 80000000 80000000 0 08000000>;
+ bus-range = <0 ff>;
+ clock-frequency = <3EF1480>;
+ interrupt-pci-iack = <0c34>;
+ interrupt-parent = <&/mv64x60/pic>;
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0a */
+ 5000 0 0 1 &/mv64x60/pic 50
+ 5000 0 0 2 &/mv64x60/pic 51
+ 5000 0 0 3 &/mv64x60/pic 5b
+ 5000 0 0 4 &/mv64x60/pic 5d
+
+ /* IDSEL 0x0b */
+ 5800 0 0 1 &/mv64x60/pic 5b
+ 5800 0 0 2 &/mv64x60/pic 5d
+ 5800 0 0 3 &/mv64x60/pic 50
+ 5800 0 0 4 &/mv64x60/pic 51
+
+ /* IDSEL 0x0c */
+ 6000 0 0 1 &/mv64x60/pic 5b
+ 6000 0 0 2 &/mv64x60/pic 5d
+ 6000 0 0 3 &/mv64x60/pic 50
+ 6000 0 0 4 &/mv64x60/pic 51
+
+ /* IDSEL 0x0d */
+ 6800 0 0 1 &/mv64x60/pic 5d
+ 6800 0 0 2 &/mv64x60/pic 50
+ 6800 0 0 3 &/mv64x60/pic 51
+ 6800 0 0 4 &/mv64x60/pic 5b
+ >;
+ };
+
+ cpu-error@0070 {
+ device_type = "mv64x60-cpu-error";
+ reg = <0070 10 0128 28>;
+ interrupts = <03>;
+ interrupt-parent = <&/mv64x60/pic>;
+ };
+
+ sram-error@0380 {
+ device_type = "mv64x60-sram-error";
+ reg = <0380 80>;
+ interrupts = <0d>;
+ interrupt-parent = <&/mv64x60/pic>;
+ };
+
+ pci-error@1dc0 {
+ device_type = "mv64x60-pci-error";
+ reg = <1d40 40 0c28 4>;
+ interrupts = <0c>;
+ interrupt-parent = <&/mv64x60/pic>;
+ };
+
+ memctrl@1400 {
+ device_type = "mv64x60-memctrl";
+ reg = <1400 60>;
+ interrupts = <11>;
+ interrupt-parent = <&/mv64x60/pic>;
+ };
+ };
+
+ chosen {
+ bootargs = "ip=on console=ttyMM0";
+ linux,stdout-path = "/mv64x60/mpsc@8000";
+ };
+};
^ permalink raw reply
* RE:
From: Scott Coulter @ 2007-04-27 20:30 UTC (permalink / raw)
To: Mead, Joseph; +Cc: linuxppc-embedded
In-Reply-To: <D1AFFAE2CC4BD54CA4C1543CFF4A4FCC2F37BB@exchangemb3.bnl.gov>
[-- Attachment #1: Type: text/plain, Size: 4340 bytes --]
Check your UART interrupt setup
___________________________________________________________________
Scott N. Coulter
Senior Software Engineer
Cyclone Microsystems
370 James Street Phone: 203.786.5536 ext. 118
New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
U.S.A. Web: http://www.cyclone.com
___________________________________________________________________
________________________________
From: linuxppc-embedded-bounces+scott.coulter=cyclone.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+scott.coulter=cyclone.com@ozlabs.org]
On Behalf Of Mead, Joseph
Sent: Friday, April 27, 2007 3:16 PM
To: linuxppc-embedded@ozlabs.org
Subject:
Hi,
I'm trying to use initramfs on an ML403 system but don't understand why
I can't see any console output after the line:
[ 1.034361] Freeing unused kernel memory: 1172k init
my filesystem is built from the following:
dir /dev 755 0 0
nod /dev/console 644 0 0 c 5 1
dir /proc 755 0 0
dir /sys 755 0 0
file /init usr/busybox 755 0 0
Busybox was built statically, with init functionality so I think I can
just rename it to init and it should run the init process. It seems to
find /dev/console because if I delete that node I get an error message
that it can't find /dev/console. Also I think it is finding the
busybox init because I don't get a kernel panic like I do when I don't
include it.
Any help would be great.
Thanks,
Joe
Kernel boot-up messages.
loaded at: 00400000 005E613C
board data at: 005E4124 005E413C
relocated to: 004050D0 004050E8
zimage at: 004057E9 005E3869
avail ram: 005E7000 04000000
Linux/PPC load: console=ttyS0,9600
Uncompressing Linux...done.
Now booting the kernel
[ 0.000000] Linux version 2.6.17.1 (root@ansto1) (gcc version 3.4.5)
#29 Thu Apr 27 11:13:26 EDT 2007
[ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
[ 0.000000] Built 1 zonelists
[ 0.000000] Kernel command line: console=ttyS0,9600
[ 0.000000] Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFE000
[ 0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)
[ 0.000105] Console: colour dummy device 80x25
[ 0.000394] Dentry cache hash table entries: 8192 (order: 3, 32768
bytes)
[ 0.000887] Inode-cache hash table entries: 4096 (order: 2, 16384
bytes)
[ 0.009214] Memory: 61964k available (1292k kernel code, 468k data,
1172k init, 0k highmem)
[ 0.096238] Mount-cache hash table entries: 512
[ 0.435539] NET: Registered protocol family 16
[ 0.440315] NET: Registered protocol family 2
[ 0.480121] IP route cache hash table entries: 512 (order: -1, 2048
bytes)
[ 0.480636] TCP established hash table entries: 2048 (order: 1, 8192
bytes)
[ 0.480755] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.480821] TCP: Hash tables configure
[ 0.480843] TCP reno registered
[ 0.484696] io scheduler noop registered
[ 0.484754] io scheduler anticipatory registered (default)
[ 0.484799] io scheduler deadline registered
[ 0.484890] io scheduler cfq registered
[ 0.510230] Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ
sharing disabled
[ 0.511764] serial8250.0: ttyS0 at MMIO 0x40401003 (irq = 9) is a
16550A
[ 0.924578] RAMDISK driver initialized: 16 RAM disks of 65536K size
1024 blocksize
[ 0.948301] tun: Universal TUN
[ 0.963483] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 0.982713] mice: PS/2 mouse device common for all mice
[ 0.998445] TCP bic registered
[ 1.007702] NET: Registered protocol family 1
[ 1.020827] NET: Registered protocol family 17
[ 1.034361] Freeing unused kernel memory: 1172k init
[-- Attachment #2: Type: text/html, Size: 25869 bytes --]
^ permalink raw reply
* Re: [PATCH 2/13] powerpc: Add dt_xlate_addr() to bootwrapper
From: Mark A. Greer @ 2007-04-27 20:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17969.36930.988443.16462@cargo.ozlabs.ibm.com>
dt_xlate_reg() looks up the 'reg' property in the specified node
to get the address and size to translate. Add dt_xlate_addr()
which is passed in the address and size to translate.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
---
Paul, this should apply on top of Scott's patch.
devtree.c | 47 +++++++++++++++++++++++++++++++++--------------
ops.h | 4 ++--
2 files changed, 35 insertions(+), 16 deletions(-)
Index: powerpc/arch/powerpc/boot/devtree.c
===================================================================
--- powerpc.orig/arch/powerpc/boot/devtree.c
+++ powerpc/arch/powerpc/boot/devtree.c
@@ -207,12 +207,13 @@ static int find_range(u32 *reg, u32 *ran
* In particular, PCI is not supported. Also, only the beginning of the
* reg block is tracked; size is ignored except in ranges.
*/
-int dt_xlate_reg(void *node, int res, unsigned long *addr,
- unsigned long *size)
+static u32 dt_xlate_buf[MAX_ADDR_CELLS * MAX_RANGES * 3];
+
+static int dt_xlate(void *node, int res, int reglen, unsigned long *addr,
+ unsigned long *size)
{
u32 last_addr[MAX_ADDR_CELLS];
u32 this_addr[MAX_ADDR_CELLS];
- u32 buf[MAX_ADDR_CELLS * MAX_RANGES * 3];
void *parent;
u64 ret_addr, ret_size;
u32 naddr, nsize, prev_naddr;
@@ -227,19 +228,18 @@ int dt_xlate_reg(void *node, int res, un
if (nsize > 2)
return 0;
- buflen = getprop(node, "reg", buf, sizeof(buf)) / 4;
offset = (naddr + nsize) * res;
- if (buflen < offset + naddr + nsize ||
- sizeof(buf) < offset + naddr + nsize)
+ if (reglen < offset + naddr + nsize ||
+ sizeof(dt_xlate_buf) < offset + naddr + nsize)
return 0;
- copy_val(last_addr, buf + offset, naddr);
+ copy_val(last_addr, dt_xlate_buf + offset, naddr);
- ret_size = buf[offset + naddr];
+ ret_size = dt_xlate_buf[offset + naddr];
if (nsize == 2) {
ret_size <<= 32;
- ret_size |= buf[offset + naddr + 1];
+ ret_size |= dt_xlate_buf[offset + naddr + 1];
}
while ((node = get_parent(node))) {
@@ -247,24 +247,25 @@ int dt_xlate_reg(void *node, int res, un
get_reg_format(node, &naddr, &nsize);
- buflen = getprop(node, "ranges", buf, sizeof(buf));
+ buflen = getprop(node, "ranges", dt_xlate_buf,
+ sizeof(dt_xlate_buf));
if (buflen < 0)
continue;
- if (buflen > sizeof(buf))
+ if (buflen > sizeof(dt_xlate_buf))
return 0;
- offset = find_range(last_addr, buf, prev_naddr,
+ offset = find_range(last_addr, dt_xlate_buf, prev_naddr,
naddr, nsize, buflen / 4);
if (offset < 0)
return 0;
- copy_val(this_addr, buf + offset, prev_naddr);
+ copy_val(this_addr, dt_xlate_buf + offset, prev_naddr);
if (!sub_reg(last_addr, this_addr))
return 0;
- copy_val(this_addr, buf + offset + prev_naddr, naddr);
+ copy_val(this_addr, dt_xlate_buf + offset + prev_naddr, naddr);
if (!add_reg(last_addr, this_addr, naddr))
return 0;
@@ -286,3 +287,21 @@ int dt_xlate_reg(void *node, int res, un
return 1;
}
+
+int dt_xlate_reg(void *node, int res, unsigned long *addr, unsigned long *size)
+{
+ int reglen;
+
+ reglen = getprop(node, "reg", dt_xlate_buf, sizeof(dt_xlate_buf)) / 4;
+ return dt_xlate(node, res, reglen, addr, size);
+}
+
+int dt_xlate_addr(void *node, u32 *buf, int buflen, unsigned long *xlated_addr)
+{
+
+ if (buflen > sizeof(dt_xlate_buf))
+ return 0;
+
+ memcpy(dt_xlate_buf, buf, buflen);
+ return dt_xlate(node, 0, buflen / 4, xlated_addr, NULL);
+}
Index: powerpc/arch/powerpc/boot/ops.h
===================================================================
--- powerpc.orig/arch/powerpc/boot/ops.h
+++ powerpc/arch/powerpc/boot/ops.h
@@ -82,8 +82,8 @@ int ns16550_console_init(void *devp, str
void *simple_alloc_init(char *base, unsigned long heap_size,
unsigned long granularity, unsigned long max_allocs);
extern void flush_cache(void *, unsigned long);
-int dt_xlate_reg(void *node, int res, unsigned long *addr,
- unsigned long *size);
+int dt_xlate_reg(void *node, int res, unsigned long *addr, unsigned long *size);
+int dt_xlate_addr(void *node, u32 *buf, int buflen, unsigned long *xlated_addr);
static inline void *finddevice(const char *name)
{
^ permalink raw reply
* RE: How do external irq's get mapped?
From: Charles Krinke @ 2007-04-27 20:58 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Randy Brown, Chris Carlson, Kevin Smith, linuxppc-embedded
In-Reply-To: <46324428.7070401@ru.mvista.com>
A little further on IRQ mapping. I was incorrect in saying enet_tx is at
19. According to MPC8555ERM.pdf the TSEC1_tx, TSEC_rx and DUART are at
13 TSEC1_tx (maps to 93)
14 TSEC1_rx (maps to 94)
26 DUART (maps to 106)
A 'cat /proc/interrupts' shows this 93, 94 & 106 mapping:
root@sff1:~# cat /proc/interrupts
CPU0
2: 0 i8259 Edge 82c59 secondary cascade
32: 0 CPM2 SIU Level ichar
93: 10701 OpenPIC Level enet_tx
94: 13945 OpenPIC Level enet_rx
98: 0 OpenPIC Level enet_error
106: 542 OpenPIC Level serial
107: 0 OpenPIC Level i2c-mpc
110: 0 OpenPIC Level cpm2_cascade
128: 0 OpenPIC Level <NULL>
BAD: 0
root@sff1:~#
Looking at arch/ppc/platforms/85xx/mpc85xx_cds_common.c, I can see the
mpc85xx_cds_openpic[] array and since CONFIG_PCI is defined, the first
four entries for IRQ0..3 (or INTA, INTB, INTC & INTD) have non-zero
entries containing (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), which
should be OK.
Down a little further in this file is mpc85xx_cds_init_IRQ and it we do
not have CONFIG_MPC8548 defined, so we should be calling
openpic_set_sources(0, 32, OpenPIC_ADDR + 0x10200)=20
followed by calling=20
openpic_set_sources(48, 12, OpenPIC_ADDR + 0x10000)
This leads to a couple of new questions.
1. We have no 8259 in our design. Is this a concern as we are always
calling the i8259_init() routine.
2. The 'cat /proc/interrupts' shows 82c59 secondary cascade. Again, does
this matter?
3. The offset between TSEC1_tx of 13-->93 is a constant of 80 decimal.
Is this a clue to what the irq should be set to for external IRQ0 in
this design?
Charles Krinke
^ permalink raw reply
* Re: How do external irq's get mapped?
From: Andy Fleming @ 2007-04-27 21:23 UTC (permalink / raw)
To: Charles Krinke; +Cc: Randy Brown, Chris Carlson, Kevin Smith, linuxppc-embedded
In-Reply-To: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06A1F3@MERCURY.inside.istor.com>
On Apr 27, 2007, at 15:58, Charles Krinke wrote:
> A little further on IRQ mapping. I was incorrect in saying enet_tx
> is at
> 19. According to MPC8555ERM.pdf the TSEC1_tx, TSEC_rx and DUART are at
>
> 13 TSEC1_tx (maps to 93)
> 14 TSEC1_rx (maps to 94)
> 26 DUART (maps to 106)
>
> A 'cat /proc/interrupts' shows this 93, 94 & 106 mapping:
Ok that makes sense.
>
> root@sff1:~# cat /proc/interrupts
> CPU0
> 2: 0 i8259 Edge 82c59 secondary cascade
> 32: 0 CPM2 SIU Level ichar
> 93: 10701 OpenPIC Level enet_tx
> 94: 13945 OpenPIC Level enet_rx
> 98: 0 OpenPIC Level enet_error
> 106: 542 OpenPIC Level serial
> 107: 0 OpenPIC Level i2c-mpc
> 110: 0 OpenPIC Level cpm2_cascade
> 128: 0 OpenPIC Level <NULL>
> BAD: 0
> root@sff1:~#
>
> Looking at arch/ppc/platforms/85xx/mpc85xx_cds_common.c, I can see the
> mpc85xx_cds_openpic[] array and since CONFIG_PCI is defined, the first
> four entries for IRQ0..3 (or INTA, INTB, INTC & INTD) have non-zero
> entries containing (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), which
> should be OK.
Are you using arch/ppc? You should probably avoid that. However, it
does mean that you are probably using hard-coded irq offsets (rather
than reading the numbers from the device tree. What you are seeing
is the result of adding the number of I8259 interrupts (16) to the
number of CPM interrupts (64). Then the internal interrupts start at
80, and there are 32 of them, and the external interrupts would start
at 112. If you look at the arch/ppc code, it defines PIRQA-D, and
they will be board-specific.
> This leads to a couple of new questions.
>
> 1. We have no 8259 in our design. Is this a concern as we are always
> calling the i8259_init() routine.
Yeah, don't do that. Just wastes time, and could potentially screw
around with something else on your bus.
>
> 2. The 'cat /proc/interrupts' shows 82c59 secondary cascade. Again,
> does
> this matter?
That's potentially a big problem, as the 8259 cascade is hooked up to
one of the external interrupts. This might cause your kernel to
interpret an interrupt as an i8259 interrupt, which could have all
sorts of strange side-effects.
> 3. The offset between TSEC1_tx of 13-->93 is a constant of 80 decimal.
> Is this a clue to what the irq should be set to for external IRQ0 in
> this design?
Yeah. 112. However, you really should switch to using arch/powerpc,
and device trees. In that instance, you set the irq to the pin
number (1-4), and the kernel will map that based on the interrupt-map
property of the pci node. It was for precisely this type of problem
that the irq numbers were virtualized. The IRQ numbers in arch/ppc
actually change depending on whether you've *configured* the CPM or not.
Andy
^ permalink raw reply
* [PATCH] powerpc: fix suspend states again
From: Johannes Berg @ 2007-04-27 21:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17969.56735.644629.328360@cargo.ozlabs.ibm.com>
In commit 0fba3a1f39f8b0a50b56c8b068fa52131cbc84c2 (a very long time ago,
May 2006), I fixed a bug that caused powermacs to crash when you tried
entering standby/mem suspend states.
As I'm now getting more familiar with the suspend code I notice a few
more things:
1. we previously misunderstood what pm_ops is for, it isn't supposed to be
for doing platform dependent suspend/resume stuff that needs to be done
for suspend to disk (as we currently try to use it!), it is instead for
entering platform dependent suspend states ("standby", "mem").
2. due to the first point, we never properly save FPU and altivec states
when suspending to disk. It probably hasn't hurt yet because the process
that writes the "disk" to /sys/power/state uses neither and its context
is used.
This patch addresses these points as follows:
1. remove all pm_ops from powermac, powermac suspend to ram isn't currently
usable via /sys/power/state but is done via the PMU instead.
2. move the code responsible for storing FPU/altivec state into
save_processor_state and the set_context() call to restore_processor_state.
3. add a call to kernel_enable_spe()
It may look like there is some code removal missing but that is actually because
the new suspend.h file overrides the ppc/suspend.h one which was previously used.
A follow-on patch will create new pm_ops for via-pmu.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Ben's acked-by can be found at
http://thread.gmane.org/gmane.linux.ports.ppc64.devel/17441/focus=17467,
I just reworded the description slightly since then.
arch/powerpc/kernel/Makefile | 1
arch/powerpc/kernel/swsusp.c | 42 ++++++++++++++++++++
arch/powerpc/platforms/powermac/setup.c | 65 --------------------------------
include/asm-powerpc/suspend.h | 9 ++++
4 files changed, 52 insertions(+), 65 deletions(-)
--- linux-2.6.orig/arch/powerpc/platforms/powermac/setup.c 2007-04-27 23:24:57.576021121 +0200
+++ linux-2.6/arch/powerpc/platforms/powermac/setup.c 2007-04-27 23:25:20.396021121 +0200
@@ -420,76 +420,11 @@ static void __init find_boot_device(void
#endif
}
-/* TODO: Merge the suspend-to-ram with the common code !!!
- * currently, this is a stub implementation for suspend-to-disk
- * only
- */
-
-#ifdef CONFIG_SOFTWARE_SUSPEND
-
-static int pmac_pm_prepare(suspend_state_t state)
-{
- printk(KERN_DEBUG "%s(%d)\n", __FUNCTION__, state);
-
- return 0;
-}
-
-static int pmac_pm_enter(suspend_state_t state)
-{
- printk(KERN_DEBUG "%s(%d)\n", __FUNCTION__, state);
-
- /* Giveup the lazy FPU & vec so we don't have to back them
- * up from the low level code
- */
- enable_kernel_fp();
-
-#ifdef CONFIG_ALTIVEC
- if (cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC)
- enable_kernel_altivec();
-#endif /* CONFIG_ALTIVEC */
-
- return 0;
-}
-
-static int pmac_pm_finish(suspend_state_t state)
-{
- printk(KERN_DEBUG "%s(%d)\n", __FUNCTION__, state);
-
- /* Restore userland MMU context */
- set_context(current->active_mm->context.id, current->active_mm->pgd);
-
- return 0;
-}
-
-static int pmac_pm_valid(suspend_state_t state)
-{
- switch (state) {
- case PM_SUSPEND_DISK:
- return 1;
- /* can't do any other states via generic mechanism yet */
- default:
- return 0;
- }
-}
-
-static struct pm_ops pmac_pm_ops = {
- .pm_disk_mode = PM_DISK_SHUTDOWN,
- .prepare = pmac_pm_prepare,
- .enter = pmac_pm_enter,
- .finish = pmac_pm_finish,
- .valid = pmac_pm_valid,
-};
-
-#endif /* CONFIG_SOFTWARE_SUSPEND */
-
static int initializing = 1;
static int pmac_late_init(void)
{
initializing = 0;
-#ifdef CONFIG_SOFTWARE_SUSPEND
- pm_set_ops(&pmac_pm_ops);
-#endif /* CONFIG_SOFTWARE_SUSPEND */
return 0;
}
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6/include/asm-powerpc/suspend.h 2007-04-27 23:25:20.396021121 +0200
@@ -0,0 +1,9 @@
+#ifndef __ASM_POWERPC_SUSPEND_H
+#define __ASM_POWERPC_SUSPEND_H
+
+static inline int arch_prepare_suspend(void) { return 0; }
+
+void save_processor_state(void);
+void restore_processor_state(void);
+
+#endif /* __ASM_POWERPC_SUSPEND_H */
--- linux-2.6.orig/arch/powerpc/kernel/Makefile 2007-04-27 23:24:57.616021121 +0200
+++ linux-2.6/arch/powerpc/kernel/Makefile 2007-04-27 23:25:20.406021121 +0200
@@ -36,6 +36,7 @@ obj-$(CONFIG_GENERIC_TBSYNC) += smp-tbsy
obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
obj-$(CONFIG_6xx) += idle_6xx.o l2cr_6xx.o cpu_setup_6xx.o
obj-$(CONFIG_TAU) += tau_6xx.o
+obj-$(CONFIG_SOFTWARE_SUSPEND) += swsusp.o
obj32-$(CONFIG_SOFTWARE_SUSPEND) += swsusp_32.o
obj32-$(CONFIG_MODULES) += module_32.o
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6/arch/powerpc/kernel/swsusp.c 2007-04-27 23:25:20.406021121 +0200
@@ -0,0 +1,42 @@
+/*
+ * Common powerpc suspend code for 32 and 64 bits
+ *
+ * Copyright 2007 Johannes Berg <johannes@sipsolutions.net>
+ *
+ * GPLv2
+ */
+
+#include <linux/sched.h>
+#include <asm/suspend.h>
+#include <asm/cputable.h>
+#include <asm/system.h>
+#include <asm/current.h>
+#include <asm/mmu_context.h>
+
+#ifdef CONFIG_SPE
+extern void enable_kernel_spe(void);
+#endif
+
+void save_processor_state(void)
+{
+ /* Giveup the lazy FPU & vec so we don't have to back them
+ * up from the low level code
+ */
+ enable_kernel_fp();
+
+#ifdef CONFIG_ALTIVEC
+ if (cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC)
+ enable_kernel_altivec();
+#endif /* CONFIG_ALTIVEC */
+
+#ifdef CONFIG_SPE
+ enable_kernel_spe();
+#endif
+}
+
+void restore_processor_state(void)
+{
+#ifdef CONFIG_PPC32
+ set_context(current->active_mm->context.id, current->active_mm->pgd);
+#endif
+}
^ permalink raw reply
* Re: [PATCH] powerpc: fix suspend states again
From: Olof Johansson @ 2007-04-27 21:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1177710095.3565.64.camel@johannes.berg>
Hi,
On Fri, Apr 27, 2007 at 11:41:35PM +0200, Johannes Berg wrote:
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ linux-2.6/arch/powerpc/kernel/swsusp.c 2007-04-27 23:25:20.406021121 +0200
> @@ -0,0 +1,42 @@
> +/*
> + * Common powerpc suspend code for 32 and 64 bits
> + *
> + * Copyright 2007 Johannes Berg <johannes@sipsolutions.net>
> + *
> + * GPLv2
> + */
A regular GPL copyright blurb isn't that hard to paste in. :-)
> +#include <linux/sched.h>
> +#include <asm/suspend.h>
> +#include <asm/cputable.h>
> +#include <asm/system.h>
> +#include <asm/current.h>
> +#include <asm/mmu_context.h>
> +
> +#ifdef CONFIG_SPE
> +extern void enable_kernel_spe(void);
> +#endif
This should be added to asm-powerpc/system.h instead, and that should
be included here since that has the enable_kernel_altivec() and
enable_kernel_fp() definitions.
-Olof
^ permalink raw reply
* Re: [PATCH] powerpc: fix suspend states again
From: Johannes Berg @ 2007-04-27 21:54 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070427215338.GB17224@lixom.net>
[-- Attachment #1: Type: text/plain, Size: 577 bytes --]
On Fri, 2007-04-27 at 16:53 -0500, Olof Johansson wrote:
> > + * GPLv2
> > + */
>
> A regular GPL copyright blurb isn't that hard to paste in. :-)
Aw, I just hate cluttering all the files with it :)
> > +#ifdef CONFIG_SPE
> > +extern void enable_kernel_spe(void);
> > +#endif
>
> This should be added to asm-powerpc/system.h instead
and it shouldn't be ifdef'ed either ;)
> , and that should
> be included here since that has the enable_kernel_altivec() and
> enable_kernel_fp() definitions.
True. Guess I get to make two new patches.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: fix suspend states again
From: Olof Johansson @ 2007-04-27 21:57 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1177710883.3565.66.camel@johannes.berg>
On Fri, Apr 27, 2007 at 11:54:43PM +0200, Johannes Berg wrote:
> On Fri, 2007-04-27 at 16:53 -0500, Olof Johansson wrote:
>
> > > + * GPLv2
> > > + */
> >
> > A regular GPL copyright blurb isn't that hard to paste in. :-)
>
> Aw, I just hate cluttering all the files with it :)
>
> > > +#ifdef CONFIG_SPE
> > > +extern void enable_kernel_spe(void);
> > > +#endif
> >
> > This should be added to asm-powerpc/system.h instead
>
> and it shouldn't be ifdef'ed either ;)
Nope
> > , and that should
> > be included here since that has the enable_kernel_altivec() and
> > enable_kernel_fp() definitions.
>
> True. Guess I get to make two new patches.
It already was, I missed it. -ENEEDCOFFEE.
-Olof
^ permalink raw reply
* [PATCH] powerpc: put enable_kernel_spe into a header
From: Johannes Berg @ 2007-04-27 22:00 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1177710883.3565.66.camel@johannes.berg>
This patch puts enable_kernel_spe into <asm-powerpc/system.h> along with
enable_kernel_altivec etc.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
include/asm-powerpc/system.h | 1 +
1 file changed, 1 insertion(+)
--- linux-2.6.orig/include/asm-powerpc/system.h 2007-04-27 23:56:42.976021121 +0200
+++ linux-2.6/include/asm-powerpc/system.h 2007-04-27 23:59:50.826021121 +0200
@@ -131,6 +131,7 @@ extern void enable_kernel_altivec(void);
extern void giveup_altivec(struct task_struct *);
extern void load_up_altivec(struct task_struct *);
extern int emulate_altivec(struct pt_regs *);
+extern void enable_kernel_spe(void);
extern void giveup_spe(struct task_struct *);
extern void load_up_spe(struct task_struct *);
extern int fix_alignment(struct pt_regs *);
^ permalink raw reply
* Re: [PATCH 3/13] powerpc: Add bootwrapper support for Marvell/mv64x60 hostbridge
From: Mark A. Greer @ 2007-04-27 22:02 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17969.37331.228482.225919@cargo.ozlabs.ibm.com>
On Fri, Apr 27, 2007 at 04:01:55PM +1000, Paul Mackerras wrote:
> Mark A. Greer writes:
>
> > Makefile | 2
> > mv64x60.c | 581 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > mv64x60.h | 70 +++++++
> > 3 files changed, 652 insertions(+), 1 deletion(-)
>
> 650 lines just to set up a hostbridge - that seems like rather a lot.
Yes, it is. This probably won't make you feel any better but most of
the lines are #define's or table init lines. There's only a couple
hundred or so that are actual code.
> Why do we have to do this here? Isn't there some firmware that should
> do this for us?
Well, the firmware just doesn't do all the init that's required. And,
some of the init that it does do is wrong. For example, the window for
the MPSC (serial ctlr) to access main memory isn't set up so the kernel
mpsc driver can't dma. There are several other examles.
All of this init should be in the firmware but its Motorola/ECC's
firmware and I/we have no control over it. Given that, I/we have to do
the init somewhere. Either in the kernel or the bootwrapper.
I vote for the bootwrapper but then your vote is the only one that actually
counts. :)
Mark
^ permalink raw reply
* [PATCH v2] powerpc: fix suspend states again
From: Johannes Berg @ 2007-04-27 22:02 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1177710883.3565.66.camel@johannes.berg>
In commit 0fba3a1f39f8b0a50b56c8b068fa52131cbc84c2 (a very long time ago,
May 2006), I fixed a bug that caused powermacs to crash when you tried
entering standby/mem suspend states.
As I'm now getting more familiar with the suspend code I notice a few
more things:
1. we previously misunderstood what pm_ops is for, it isn't supposed to be
for doing platform dependent suspend/resume stuff that needs to be done
for suspend to disk (as we currently try to use it!), it is instead for
entering platform dependent suspend states ("standby", "mem").
2. due to the first point, we never properly save FPU and altivec states
when suspending to disk. It probably hasn't hurt yet because the process
that writes the "disk" to /sys/power/state uses neither and its context
is used.
This patch addresses these points as follows:
1. remove all pm_ops from powermac, powermac suspend to ram isn't currently
usable via /sys/power/state but is done via the PMU instead.
2. move the code responsible for storing FPU/altivec state into
save_processor_state and the set_context() call to restore_processor_state.
3. add a call to kernel_enable_spe()
It may look like there is some code removal missing but that is actually because
the new suspend.h file overrides the ppc/suspend.h one which was previously used.
A follow-on patch will create new pm_ops for via-pmu.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
This time without the extern declaration and four new lines of license text ;)
arch/powerpc/kernel/Makefile | 1
arch/powerpc/kernel/swsusp.c | 41 ++++++++++++++++++++
arch/powerpc/platforms/powermac/setup.c | 65 --------------------------------
include/asm-powerpc/suspend.h | 9 ++++
4 files changed, 51 insertions(+), 65 deletions(-)
--- linux-2.6.orig/arch/powerpc/platforms/powermac/setup.c 2007-04-27 23:56:21.466021121 +0200
+++ linux-2.6/arch/powerpc/platforms/powermac/setup.c 2007-04-28 00:00:08.986021121 +0200
@@ -420,76 +420,11 @@ static void __init find_boot_device(void
#endif
}
-/* TODO: Merge the suspend-to-ram with the common code !!!
- * currently, this is a stub implementation for suspend-to-disk
- * only
- */
-
-#ifdef CONFIG_SOFTWARE_SUSPEND
-
-static int pmac_pm_prepare(suspend_state_t state)
-{
- printk(KERN_DEBUG "%s(%d)\n", __FUNCTION__, state);
-
- return 0;
-}
-
-static int pmac_pm_enter(suspend_state_t state)
-{
- printk(KERN_DEBUG "%s(%d)\n", __FUNCTION__, state);
-
- /* Giveup the lazy FPU & vec so we don't have to back them
- * up from the low level code
- */
- enable_kernel_fp();
-
-#ifdef CONFIG_ALTIVEC
- if (cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC)
- enable_kernel_altivec();
-#endif /* CONFIG_ALTIVEC */
-
- return 0;
-}
-
-static int pmac_pm_finish(suspend_state_t state)
-{
- printk(KERN_DEBUG "%s(%d)\n", __FUNCTION__, state);
-
- /* Restore userland MMU context */
- set_context(current->active_mm->context.id, current->active_mm->pgd);
-
- return 0;
-}
-
-static int pmac_pm_valid(suspend_state_t state)
-{
- switch (state) {
- case PM_SUSPEND_DISK:
- return 1;
- /* can't do any other states via generic mechanism yet */
- default:
- return 0;
- }
-}
-
-static struct pm_ops pmac_pm_ops = {
- .pm_disk_mode = PM_DISK_SHUTDOWN,
- .prepare = pmac_pm_prepare,
- .enter = pmac_pm_enter,
- .finish = pmac_pm_finish,
- .valid = pmac_pm_valid,
-};
-
-#endif /* CONFIG_SOFTWARE_SUSPEND */
-
static int initializing = 1;
static int pmac_late_init(void)
{
initializing = 0;
-#ifdef CONFIG_SOFTWARE_SUSPEND
- pm_set_ops(&pmac_pm_ops);
-#endif /* CONFIG_SOFTWARE_SUSPEND */
return 0;
}
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6/include/asm-powerpc/suspend.h 2007-04-28 00:00:08.986021121 +0200
@@ -0,0 +1,9 @@
+#ifndef __ASM_POWERPC_SUSPEND_H
+#define __ASM_POWERPC_SUSPEND_H
+
+static inline int arch_prepare_suspend(void) { return 0; }
+
+void save_processor_state(void);
+void restore_processor_state(void);
+
+#endif /* __ASM_POWERPC_SUSPEND_H */
--- linux-2.6.orig/arch/powerpc/kernel/Makefile 2007-04-27 23:56:21.526021121 +0200
+++ linux-2.6/arch/powerpc/kernel/Makefile 2007-04-28 00:00:08.996021121 +0200
@@ -36,6 +36,7 @@ obj-$(CONFIG_GENERIC_TBSYNC) += smp-tbsy
obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
obj-$(CONFIG_6xx) += idle_6xx.o l2cr_6xx.o cpu_setup_6xx.o
obj-$(CONFIG_TAU) += tau_6xx.o
+obj-$(CONFIG_SOFTWARE_SUSPEND) += swsusp.o
obj32-$(CONFIG_SOFTWARE_SUSPEND) += swsusp_32.o
obj32-$(CONFIG_MODULES) += module_32.o
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6/arch/powerpc/kernel/swsusp.c 2007-04-28 00:02:06.186021121 +0200
@@ -0,0 +1,41 @@
+/*
+ * Common powerpc suspend code for 32 and 64 bits
+ *
+ * Copyright 2007 Johannes Berg <johannes@sipsolutions.net>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/sched.h>
+#include <asm/suspend.h>
+#include <asm/cputable.h>
+#include <asm/system.h>
+#include <asm/current.h>
+#include <asm/mmu_context.h>
+
+void save_processor_state(void)
+{
+ /* Giveup the lazy FPU & vec so we don't have to back them
+ * up from the low level code
+ */
+ enable_kernel_fp();
+
+#ifdef CONFIG_ALTIVEC
+ if (cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC)
+ enable_kernel_altivec();
+#endif /* CONFIG_ALTIVEC */
+
+#ifdef CONFIG_SPE
+ enable_kernel_spe();
+#endif
+}
+
+void restore_processor_state(void)
+{
+#ifdef CONFIG_PPC32
+ set_context(current->active_mm->context.id, current->active_mm->pgd);
+#endif
+}
^ permalink raw reply
* RE: How do external irq's get mapped?
From: Charles Krinke @ 2007-04-27 22:51 UTC (permalink / raw)
To: Andy Fleming; +Cc: Randy Brown, Chris Carlson, Kevin Smith, linuxppc-embedded
In-Reply-To: <A500BD9D-500C-485A-A806-77B8C430F333@freescale.com>
> 3. The offset between TSEC1_tx of 13-->93 is a constant of 80 decimal.
> Is this a clue to what the irq should be set to for external IRQ0 in
> this design?
Yeah. 112. However, you really should switch to using arch/powerpc, =20
and device trees. In that instance, you set the irq to the pin =20
number (1-4), and the kernel will map that based on the interrupt-map =20
property of the pci node. It was for precisely this type of problem =20
that the irq numbers were virtualized. The IRQ numbers in arch/ppc =20
actually change depending on whether you've *configured* the CPM or not.
Andy
Dear Andy:
I appreciate your kind advice, it does help converge understanding
somewhat. I can see how we get the 80 decimal offset with 64 + 32.
I have commented out the call i8259_init(0,0) in
arch/ppc/platforms/85xx/mpc85xx_cds_common.c, but retained the call to
cpm2_init_IRQ(); shortly after that. We are constrained to finish the
current project with the kernel we started with, so changing from ppc to
powerpc is really difficult right now.
When the pci_dev->irq member is set to 112, there is a difference in
behavior. Now open_pic.c:720 is complaining that 112 is "invalid irq
112", so some additional understanding is needed on my part.
If you get a chance to help me continue to understand how the 8541
interrupts are sutured into Linux, it would be greatly appreciated.
Charles Krinke
^ permalink raw reply
* Re: [PATCH v2] powerpc: fix suspend states again
From: Olof Johansson @ 2007-04-27 23:13 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1177711372.3565.73.camel@johannes.berg>
On Sat, Apr 28, 2007 at 12:02:52AM +0200, Johannes Berg wrote:
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Olof Johansson <olof@lixom.net>
^ permalink raw reply
* Re: patches for 2.6.22
From: Arnd Bergmann @ 2007-04-27 23:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, jeremy
In-Reply-To: <17969.56735.644629.328360@cargo.ozlabs.ibm.com>
On Friday 27 April 2007, Paul Mackerras wrote:
> If anyone has patches that I haven't picked up yet which they think
> should go into 2.6.22, please send me either a pointer to the
> patches if previously posted to linuxppc-dev, or post them to
> linuxppc-dev.
I still have around 20 patches pending. Most of them are for spufs,
and I'm waiting to get feedback about them from Jeremy.
http://kernel.org/pub/linux/kernel/people/arnd/patches/2.6.21-rc7-arnd2/2.6.21-rc7-arnd2.log
has a description of what is still pending, the patches in detail are:
#### SPE affinity
cell-be_info-2.diff
cell-spu_indexing-2.diff
cell-spu_indexing_QS20-2.diff
spufs-affinity_create-4.diff
spufs-affinity_placement-4.diff
spufs-affinity_schedulling-2.diff
cell-spu_indexing_FW_vicinity-1.diff
-> waiting for an ack
spu_base-locking-cleanup.diff
-> ok with me, but depends on above
#### SPE oprofile support
re-cell-oprofile-spu-profiling-updated-patch-4.diff
re-add-support-to-oprofile-for-profiling-cell-be-spus-update-2.diff
-> want to do a final review myself
#### spu scheduler updates
spusched-remove-wakeup-races.diff
spusched-kthread.diff
spusched-dynamic-timeslicing.diff
spusched-update-policy.diff
spusched-fix-cpubind.diff
spu-loadavg.diff
-> looks ok to me, but depends on the above
#### under discussion
axon-ram-3.diff
-> This version hasn't been reviewed yet, the author hasn't signed off.
64k-support-for-kexec.diff
-> discussion ongoing, will hopefully come to a conclusion soon
powerpc-uninline-of_iomap.diff
cell-cbe_cpufreq-cleanup-and-crash-fix.diff
-> have been submitted after the previous merge with you, should go in.
Arnd <><
^ permalink raw reply
* Re: [PATCH 9/13] powerpc: Add arch/powerpc mv64x60 I2C platform data setup
From: Dale Farnsworth @ 2007-04-27 23:50 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <200704261704.06790.arnd@arndb.de>
On Thu, Apr 26, 2007 at 05:04:06PM +0200, Arnd Bergmann wrote:
> Maybe you still haven't understood the difference of an of_platform_driver
> compared to the platform_driver glue which you are adding here.
>
> I don't want you to move the glue code into the device driver -- I really
> think the glue code should not be there in the first place.
>
> As you probably understand, the Linux driver model represents every piece
> of hardware as a 'struct device' which can be embedded in things like
> of_device, pci_device or platform_device. Then there are 'struct
> device_driver's than handle all devices of a given bus_type/device_id
> combination.
>
> With the of device tree, you automatically get an of_device for everything
> that is connected to an internal (soc, plb, ssb, ...) bus on the chip
> or on the board. According to the driver model, they should be driven
> by an of_platform_driver.
Well, since our platform hasn't called of_platform_bus_probe() with
a device id for the mv64x60 device node, we don't create an of_device
for each of its sub-devices. Instead, we scan separately and create
platform_devices that the existing drivers require, and for the
benefit of those who join this discussion late, which we must
maintain for use by MIPS platforms.
> What your glue code does is to find a backdoor into the device tree
> (through of_find_compatible_node) and create a second struct device
> for the same hardware, in an unrelated location in the linux device tree.
> This is very confusing if you look at sysfs, e.g. trying to find out
> which driver is attached to a given of_device.
No, we don't create the first struct device you mentioned, so we avoid
the duplication and the confusion.
> It also makes you lose the ability to autoload the driver module,
> because autoloading is not supported for a platform_driver (there
> is no MODULE_DEVICE_TABLE()).
>
> As you made clear, we will need the platform_driver for the forseeable
> future, but I really think that we also need an of_platform_driver
> to drive them on powerpc instead of adding another pile of junk like
> fsl_soc.c.
Heh, I was going to ask if you made these points when fsl_soc.c went in. :)
> I can see multiple ways for you to get there:
I find each of these methods lacking.
> 1. have a driver that binds to all of_devices supported by mv64x60
> and then creates the platform_device for them the way you do in your
> glue, but without adding code that manually iterates through
> the device tree. Make the platform_device a child of the of_device.
> This approach is the closest to what you have right now and would
> at least get the sysfs representation right, but not allow module
> autoloading and it still duplicates all the devices.
Like you, I dislike the resulting dev duplication. Also, having
the platform_device be a child of a superfluous of_device seems weird.
> 2. remove the dependencies on platform_device data structures from
> the current driver code, and add them to a separate file, so you
> can link the module either with the platform_driver or with the
> of_platform_driver, as I suggested in a previous mail.
> I think this would be the best solution.
This is a very OF-centric proposal. IMHO it's a mistake for drivers
to call of_get_property(). There should be a firmware-independent
way of passing parameters to drivers. I'm not a big fan of the
details of platform_device, but at least it's firmware independent.
I think it's a layering violation even when ppc-only drivers
query for parameters via of_get_property().
> 3. Have a small of_device_driver part that gets added to each
> of the device drivers, and that adds the platform_device internally.
> This would be like 1., but also allow autoloading.
Again, I'd like to keep arch-specific code out of drivers, as much
as possible.
Since you now recognize our need for platform_devices, I'd like to
understand your primary objection to our not creating of_devices.
Is it because it violates the assumption that of_devices be created
for all devices on the platform? Is that a hard requirement?
BTW Arnd, thank you for taking the time to comment on this code.
-Dale
^ permalink raw reply
* Re: [PATCH 1/2] ehea: fix for sysfs entries
From: Jeff Garzik @ 2007-04-28 0:13 UTC (permalink / raw)
To: Thomas Klein
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Christoph Raisch, Stefan Roscher, linux-ppc, Marcus Eder
In-Reply-To: <200704261156.13487.osstklei@de.ibm.com>
Thomas Klein wrote:
> Create symbolic link from each logical port to ehea driver
>
> Signed-off-by: Thomas Klein <tklein@de.ibm.com>
> ---
>
>
> This patch applies on top of the netdev upstream branch for 2.6.22
applied 1-2
^ permalink raw reply
* Re: [PATCH 9/13] powerpc: Add arch/powerpc mv64x60 I2C platform data setup
From: Arnd Bergmann @ 2007-04-28 1:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <20070427235040.GA29498@xyzzy.farnsworth.org>
On Saturday 28 April 2007, Dale Farnsworth wrote:
> On Thu, Apr 26, 2007 at 05:04:06PM +0200, Arnd Bergmann wrote:
> > With the of device tree, you automatically get an of_device for everything
> > that is connected to an internal (soc, plb, ssb, ...) bus on the chip
> > or on the board. According to the driver model, they should be driven
> > by an of_platform_driver.
>
> Well, since our platform hasn't called of_platform_bus_probe() with
> a device id for the mv64x60 device node, we don't create an of_device
> for each of its sub-devices. Instead, we scan separately and create
> platform_devices that the existing drivers require, and for the
> benefit of those who join this discussion late, which we must
> maintain for use by MIPS platforms.
We've had discussions about of_platform_bus_probe() on the mailing
lists and on IRC before. My idea of the long-term goal is that we
should not call it from the platform specific code, but instead
globally and add all the devices we find, with exceptions for
stuff that works differently, like PCI.
I think it would be bad to have to add another exception for
mv64x60 just because the drivers work different from the others.
> > 2. remove the dependencies on platform_device data structures from
> > the current driver code, and add them to a separate file, so you
> > can link the module either with the platform_driver or with the
> > of_platform_driver, as I suggested in a previous mail.
> > I think this would be the best solution.
>
> This is a very OF-centric proposal. IMHO it's a mistake for drivers
> to call of_get_property(). There should be a firmware-independent
> way of passing parameters to drivers. I'm not a big fan of the
> details of platform_device, but at least it's firmware independent.
> I think it's a layering violation even when ppc-only drivers
> query for parameters via of_get_property().
Calling of_* functions is the natural thing to do for an
of_platform_driver, just like a PCI driver calls pci_* functions.
Note that what I'm suggestiong here is that you have one file
that encapsulates all the calls to OF functions (of_iomap,
irq_of_parse_and_map, ...) and passes the raw information down
to the main low-level driver.
I think the main difference between your view and mine is that
you see the OF model as an _architecture_ property, while in my
view it is a _bus_type_ that devices are attached to.
It's like the OHCI driver, which has low-level driver for the
a common register interface, but comes with a number of bus
interfaces that it can attach to (PCI, PS3, OF, ...).
[ don't look at the OHCI implementation, the way they did
the code is not a good example, but it can be done properly. ]
> Since you now recognize our need for platform_devices, I'd like to
> understand your primary objection to our not creating of_devices.
> Is it because it violates the assumption that of_devices be created
> for all devices on the platform?
That, and the missing ability to do module autoloading.
> Is that a hard requirement?
Not yet, but I'd like to get there, as I mention above.
Arnd <><
^ permalink raw reply
* XILINX SPI IP core with INTC IP core.
From: Leonid @ 2007-04-28 1:53 UTC (permalink / raw)
To: Grant Likely, linuxppc-embedded; +Cc: Rick Moleres
In-Reply-To: <11777034162194-git-send-email-grant.likely@secretlab.ca>
Hi,
I'm trying to use SPI and INTC IP cores together. Does somebody have
adapter.c for SPI core, using interrupts?
Thanks,
Leonid.
^ permalink raw reply
* RE: How do external irq's get mapped?
From: Zhang Wei-r63237 @ 2007-04-28 2:30 UTC (permalink / raw)
To: Charles Krinke, Fleming Andy-afleming
Cc: Randy Brown, Chris Carlson, Kevin Smith, linuxppc-embedded
In-Reply-To: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06A1F4@MERCURY.inside.istor.com>
Hi, Charles,
Maybe you can try my patches about showing irq-mapping relationship.
http://patchwork.ozlabs.org/linuxppc/patch?id=3D9999
http://patchwork.ozlabs.org/linuxppc/patch?id=3D9997
http://patchwork.ozlabs.org/linuxppc/patch?id=3D9998
http://patchwork.ozlabs.org/linuxppc/patch?id=3D9996
Hope it could help you.
Best Regards,
Zhang Wei
> Subject: RE: How do external irq's get mapped?
>=20
> > 3. The offset between TSEC1_tx of 13-->93 is a constant of=20
> 80 decimal.
> > Is this a clue to what the irq should be set to for external IRQ0 in
> > this design?
>=20
>=20
> Yeah. 112. However, you really should switch to using=20
> arch/powerpc, =20
> and device trees. In that instance, you set the irq to the pin =20
> number (1-4), and the kernel will map that based on the=20
> interrupt-map =20
> property of the pci node. It was for precisely this type of problem =20
> that the irq numbers were virtualized. The IRQ numbers in arch/ppc =20
> actually change depending on whether you've *configured* the=20
> CPM or not.
>=20
> Andy
>=20
> Dear Andy:
>=20
> I appreciate your kind advice, it does help converge understanding
> somewhat. I can see how we get the 80 decimal offset with 64 + 32.
>=20
> I have commented out the call i8259_init(0,0) in
> arch/ppc/platforms/85xx/mpc85xx_cds_common.c, but retained the call to
> cpm2_init_IRQ(); shortly after that. We are constrained to finish the
> current project with the kernel we started with, so changing=20
> from ppc to
> powerpc is really difficult right now.
>=20
> When the pci_dev->irq member is set to 112, there is a difference in
> behavior. Now open_pic.c:720 is complaining that 112 is "invalid irq
> 112", so some additional understanding is needed on my part.
>=20
> If you get a chance to help me continue to understand how the 8541
> interrupts are sutured into Linux, it would be greatly appreciated.
>=20
> Charles Krinke
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ 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