* Re: BUG: NETDEV WATCHDOG -> Badness in gianfar driver?
From: Andy Fleming @ 2007-04-26 18:58 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <4630E0F3.10100@anagramm.de>
On Apr 26, 2007, at 12:27, Clemens Koller wrote:
> Hi There!
>
> Any ideas of what could be wrong there? I think there could be a
> problem
> in the gianfar network driver. Or is there a physical problem with
> the PHY
> (a Marvell MV88E1111)?
hard to say which.
> Jan 1 03:43:23 ecam kernel: ------------[ cut here ]------------
> Jan 1 03:43:23 ecam kernel: Badness at c003d3d8 [verbose debug
> info unavailable]
> Jan 1 03:43:23 ecam kernel: Call Trace:
> Jan 1 03:43:23 ecam kernel: [C0355C70] [C0008FE0] show_stack+0x3c/
> 0x194 (unreliable)
> Jan 1 03:43:23 ecam kernel: [C0355CA0] [C0135594] report_bug
> +0xa4/0xac
> Jan 1 03:43:23 ecam kernel: [C0355CB0] [C0003784]
> program_check_exception+0x2b8/0x460
> Jan 1 03:43:23 ecam kernel: [C0355CD0] [C0002908]
> ret_from_except_full+0x0/0x4c
> Jan 1 03:43:23 ecam kernel: [C0355D90] [C017B3CC]
> marvell_ack_interrupt+0x14/0x38
> Jan 1 03:43:23 ecam kernel: [C0355DB0] [C01764A8] stop_gfar+0x54/0xd0
> Jan 1 03:43:23 ecam kernel: [C0355DD0] [C01773D0] gfar_timeout
> +0x5c/0x68
This is a bit confusing. Could you identify where in
marvell_ack_interrupt this is?
Andy
^ permalink raw reply
* Re: [PATCH] powerpc: Add EDAC platform devices for 85xx
From: Segher Boessenkool @ 2007-04-26 18:56 UTC (permalink / raw)
To: Dave Jiang; +Cc: linuxppc-dev, david, bluesmoke-devel
In-Reply-To: <4630D9AB.2040605@mvista.com>
>>> + mem-ctrl@2000 {
>>> + device_type = "mem-ctrl";
>>> + compatible = "85xx";
>>>
>> I'm concerned this is too generic.
>>
> I'm supposing not all 85xx uses the same soc? Is there something more
> appropriate you can suggest? Thx!
"name" = "memory-controller"
"compatible" = "fsl,85xx-memory-controller"
(or a more specific 85xx model if the controller
isn't identical across those chips)
No "device_type" at all, since there is no binding
for this kind of device.
Segher
^ permalink raw reply
* IRQ questions & puzzles
From: Charles Krinke @ 2007-04-26 18:36 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Randy Brown, Chris Carlson, Kevin Smith
In-Reply-To: <30f6090e0704260910y383ace08g30a7b6899d86ed7e@mail.gmail.com>
I have a linux-2.6.17.11 source tree that has configs for two boards.
One has an 8241 and the other has an 8541. The kernel code works fine on
the 8241, but appears to lock up in my custom driver in the 8541 when
interrupts are enabled.
What I see happening, based on using a BDI to go/halt after the apparent
lockup is that the kernel is spinning around in routines like
kernel/irq/handle.c:__do_IRQ and an associated
arch/powerpc/kernel/irq.c.
It looks like the interrupt, which should be level triggered and at this
point, is probably continuously asserted is causing the kernel to spin
in a tight loop and be incapable of doing printk's out the serial port
at 115200.
This leads to a few questions:
1. I can see most everything comes from arch/ppc, but do_IRQ comes from
arch/powerpc. Is that OK?
2. What is the most straightforward way to slow down a tight loop like
this slow enough so I can printk what is happening.
3. What might be the likely scenarios leading to such a despicable
state.
Charles Krinke
^ permalink raw reply
* [PATCH] Xilinx framebuffer device driver - 2nd version
From: Andrei Konovalov @ 2007-04-26 18:31 UTC (permalink / raw)
To: arnd, Grant Likely; +Cc: rick.moleres, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 8873 bytes --]
Add support for the video controller IP block included into Xilinx ML300 and
ML403 reference designs.
Signed-off-by: Andrei Konovalov <akonovalov@ru.mvista.com>
---
This patch relies on the "Patchset to establish sanity in Xilinx Virtex support" by Gran Likely to have
the frame buffer device registered on the platform bus. Without this patchset one needs to fill in
the struct platform_device and make sure platform_device_register() is called elsewhere.
The DCR access has been added but not tested - my targets are configured in the "memory mapped IO" way.
I would appreciate if those having the video controller registers accessible as DCRs
test the DCR mode.
This is the 2nd version that addresses what was pointed out by Arnd and Grant.
Please find the interdiff against the 1st version below, and the whole patch attached to this message
Comments are welcome.
Would be nice to get this driver into mainline for the 2.6.22.
Thanks,
Andrei
-----------------------------------------------------------------
Index: linux-2.6.20/drivers/video/Kconfig
===================================================================
--- linux-2.6.20.orig/drivers/video/Kconfig
+++ linux-2.6.20/drivers/video/Kconfig
@@ -1648,6 +1648,16 @@ config FB_XILINX_ROTATE
bool "Rotate display"
depends on FB_XILINX
+config FB_XILINX_SCR_HEIGHT
+ int "Screen height in mm"
+ depends on FB_XILINX
+ default 99
+
+config FB_XILINX_SCR_WIDTH
+ int "Screen width in mm"
+ depends on FB_XILINX
+ default 132
+
config FB_VIRTUAL
tristate "Virtual Frame Buffer support (ONLY FOR TESTING!)"
depends on FB
Index: linux-2.6.20/drivers/video/xilinxfb.c
===================================================================
--- linux-2.6.20.orig/drivers/video/xilinxfb.c
+++ linux-2.6.20/drivers/video/xilinxfb.c
@@ -30,6 +30,7 @@
#include <linux/platform_device.h>
#include <asm/io.h>
+#include <syslib/virtex_devices.h>
#define DRIVER_NAME "xilinxfb"
#define DRIVER_DESCRIPTION "Xilinx TFT LCD frame buffer driver"
@@ -97,19 +98,18 @@ static struct fb_var_screeninfo xilinx_f
.blue = { 0, 8, 0 },
.transp = { 0, 0, 0 },
- .activate = FB_ACTIVATE_NOW,
- .height = 99, /* in mm of NEC NL6448BC20-08 on ML300 */
- .width = 132 /* in mm of NEC NL6448BC20-08 on ML300 */
+ .activate = FB_ACTIVATE_NOW
};
struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
- unsigned long regs_phys; /* phys. address of the control registers */
- u32 *regs; /* virt. address of the control registers */
+ u32 regs_phys; /* phys. address of the control registers */
+ u32 __iomem *regs; /* virt. address of the control registers */
+ u32 use_dcr; /* (use_dcr) ? mtdcr() : out_be32(); */
- unsigned char *fb_virt; /* virt. address of the frame buffer */
+ unsigned char __iomem *fb_virt; /* virt. address of the frame buffer */
dma_addr_t fb_phys; /* phys. address of the frame buffer */
u32 pseudo_palette[16]; /* Fake palette of 16 colors */
@@ -118,6 +118,12 @@ struct xilinxfb_drvdata {
#define to_xilinxfb_drvdata(_info) \
container_of(_info, struct xilinxfb_drvdata, info)
+#define xilinx_fb_out_be32(driverdata, offset, val) \
+ if (driverdata->use_dcr) \
+ mtdcr(driverdata->regs_phys + offset, val); \
+ else \
+ out_be32(driverdata->regs + offset, val)
+
static int
xilinx_fb_setcolreg(unsigned regno, unsigned red, unsigned green, unsigned blue,
unsigned transp, struct fb_info *fbi)
@@ -153,14 +159,14 @@ xilinx_fb_blank(int blank_mode, struct f
switch (blank_mode) {
case VESA_NO_BLANKING:
/* turn on panel */
- out_be32(drvdata->regs + REG_CTRL, REG_CTRL_DEFAULT);
+ xilinx_fb_out_be32(drvdata, REG_CTRL, REG_CTRL_DEFAULT);
break;
case VESA_VSYNC_SUSPEND:
case VESA_HSYNC_SUSPEND:
case VESA_POWERDOWN:
/* turn off panel */
- out_be32(drvdata->regs + REG_CTRL, 0);
+ xilinx_fb_out_be32(drvdata, REG_CTRL, 0);
default:
break;
@@ -193,6 +199,8 @@ static struct fb_ops xilinxfb_ops =
static int
xilinxfb_drv_probe(struct device *dev)
{
+ struct platform_device *pdev;
+ struct xilinxfb_platform_data *pdata;
struct xilinxfb_drvdata *drvdata;
struct resource *regs_res;
int retval;
@@ -200,32 +208,41 @@ xilinxfb_drv_probe(struct device *dev)
if (!dev)
return -EINVAL;
- drvdata = kmalloc(sizeof(struct xilinxfb_drvdata), GFP_KERNEL);
+ pdev = to_platform_device(dev);
+ pdata = (struct xilinxfb_platform_data *)pdev->dev.platform_data;
+
+ if (pdata == NULL) {
+ printk(KERN_ERR "Couldn't find platform data.\n");
+ return -EFAULT;
+ }
+
+ drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
if (!drvdata) {
printk(KERN_ERR "Couldn't allocate device private record\n");
return -ENOMEM;
}
- memset((void*)drvdata, 0, sizeof(struct xilinxfb_drvdata));
dev_set_drvdata(dev, (void *)drvdata);
/* Map the control registers in */
- regs_res = platform_get_resource(to_platform_device(dev),
- IORESOURCE_IO, 0);
+ regs_res = platform_get_resource(pdev, IORESOURCE_IO, 0);
if (!regs_res || (regs_res->end - regs_res->start + 1 < 8)) {
printk(KERN_ERR "Couldn't get registers resource\n");
retval = -EFAULT;
goto failed1;
}
- if (!request_mem_region(regs_res->start, 8, DRIVER_NAME)) {
- printk(KERN_ERR "Couldn't lock memory region at 0x%08lX\n",
- regs_res->start);
- retval = -EBUSY;
- goto failed1;
+ drvdata->use_dcr = pdata->use_dcr;
+ if (!drvdata->use_dcr) {
+ if (!request_mem_region(regs_res->start, 8, DRIVER_NAME)) {
+ printk(KERN_ERR
+ "Couldn't lock memory region at 0x%08X\n",
+ regs_res->start);
+ retval = -EBUSY;
+ goto failed1;
+ }
+ drvdata->regs = (u32 __iomem*) ioremap(regs_res->start, 8);
}
-
drvdata->regs_phys = regs_res->start;
- drvdata->regs = (u32 *) ioremap(regs_res->start, 8);
/* Allocate the framebuffer memory */
drvdata->fb_virt = dma_alloc_coherent(dev, PAGE_ALIGN(FB_SIZE),
@@ -240,10 +257,10 @@ xilinxfb_drv_probe(struct device *dev)
memset((void *) drvdata->fb_virt, 0, FB_SIZE);
/* Tell the hardware where the frame buffer is */
- out_be32(drvdata->regs + REG_FB_ADDR, drvdata->fb_phys);
+ xilinx_fb_out_be32(drvdata, REG_FB_ADDR, drvdata->fb_phys);
/* Turn on the display */
- out_be32(drvdata->regs + REG_CTRL, REG_CTRL_DEFAULT);
+ xilinx_fb_out_be32(drvdata, REG_CTRL, REG_CTRL_DEFAULT);
/* Fill struct fb_info */
drvdata->info.screen_base = drvdata->fb_virt;
@@ -260,6 +277,8 @@ xilinxfb_drv_probe(struct device *dev)
}
drvdata->info.flags = FBINFO_DEFAULT;
+ xilinx_fb_var.height = pdata->screen_height_mm;
+ xilinx_fb_var.width = pdata->screen_width_mm;
drvdata->info.var = xilinx_fb_var;
/* Register new frame buffer */
@@ -279,8 +298,8 @@ failed3:
drvdata->fb_phys);
/* Turn off the display */
- out_be32(drvdata->regs + REG_CTRL, 0);
- iounmap(drvdata->regs);
+ xilinx_fb_out_be32(drvdata, REG_CTRL, 0);
+ if (!drvdata->use_dcr) iounmap(drvdata->regs);
failed2:
release_mem_region(regs_res->start, 8);
@@ -314,8 +333,8 @@ xilinxfb_drv_remove(struct device *dev)
drvdata->fb_phys);
/* Turn off the display */
- out_be32(drvdata->regs + REG_CTRL, 0);
- iounmap(drvdata->regs);
+ xilinx_fb_out_be32(drvdata, REG_CTRL, 0);
+ if (!drvdata->use_dcr) iounmap(drvdata->regs);
release_mem_region(drvdata->regs_phys, 8);
Index: linux-2.6.20/arch/ppc/syslib/virtex_devices.c
===================================================================
--- linux-2.6.20.orig/arch/ppc/syslib/virtex_devices.c
+++ linux-2.6.20/arch/ppc/syslib/virtex_devices.c
@@ -90,6 +90,18 @@ struct plat_serial8250_port virtex_seria
};
+/* ML300/403 reference design framebuffer driver platform data table */
+static struct xilinxfb_platform_data xilinxfb_pdata = {
+#if defined(XPAR_TFT_0_USE_DCR) && (XPAR_TFT_0_USE_DCR != 0)
+ .use_dcr = 1,
+#else
+ .use_dcr = 0,
+#endif
+ .screen_height_mm = CONFIG_FB_XILINX_SCR_HEIGHT,
+ .screen_width_mm = CONFIG_FB_XILINX_SCR_WIDTH,
+};
+
+
struct platform_device virtex_platform_devices[] = {
/* UARTLITE instances */
#if defined(XPAR_UARTLITE_0_BASEADDR)
@@ -127,6 +139,7 @@ struct platform_device virtex_platform_d
{
.name = "xilinxfb",
.id = 0,
+ .dev.platform_data = &xilinxfb_pdata,
.num_resources = 1,
.resource = (struct resource[]) {
{
Index: linux-2.6.20/arch/ppc/syslib/virtex_devices.h
===================================================================
--- linux-2.6.20.orig/arch/ppc/syslib/virtex_devices.h
+++ linux-2.6.20/arch/ppc/syslib/virtex_devices.h
@@ -13,6 +13,13 @@
#include <linux/platform_device.h>
+/* ML300/403 reference design framebuffer driver platform data struct */
+struct xilinxfb_platform_data {
+ u32 use_dcr;
+ u32 screen_height_mm;
+ u32 screen_width_mm;
+};
+
void __init virtex_early_serial_map(void);
/* Prototype for device fixup routine. Implement this routine in the
[-- Attachment #2: ppc32-xilinx_fb.patch --]
[-- Type: text/x-patch, Size: 13819 bytes --]
Add support for the video controller IP block included into Xilinx ML300 and
ML403 reference designs.
arch/ppc/syslib/virtex_devices.c | 13 +
arch/ppc/syslib/virtex_devices.h | 7
drivers/video/Kconfig | 25 ++
drivers/video/Makefile | 1
drivers/video/xilinxfb.c | 377 +++++++++++++++++++++++++++++++++++++++
5 files changed, 423 insertions(+)
Index: linux-2.6.20/drivers/video/Kconfig
===================================================================
--- linux-2.6.20.orig/drivers/video/Kconfig
+++ linux-2.6.20/drivers/video/Kconfig
@@ -1633,6 +1633,31 @@ config FB_PS3_DEFAULT_SIZE_M
The default value can be overridden on the kernel command line
using the "ps3fb" option (e.g. "ps3fb=9M");
+config FB_XILINX
+ tristate "Xilinx frame buffer support"
+ depends on FB && XILINX_VIRTEX
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ ---help---
+ Include support for the Xilinx ML300/ML403 reference design
+ framebuffer. ML300 carries a 640*480 LCD display on the board,
+ ML403 uses a standard DB15 VGA connector.
+
+config FB_XILINX_ROTATE
+ bool "Rotate display"
+ depends on FB_XILINX
+
+config FB_XILINX_SCR_HEIGHT
+ int "Screen height in mm"
+ depends on FB_XILINX
+ default 99
+
+config FB_XILINX_SCR_WIDTH
+ int "Screen width in mm"
+ depends on FB_XILINX
+ default 132
+
config FB_VIRTUAL
tristate "Virtual Frame Buffer support (ONLY FOR TESTING!)"
depends on FB
Index: linux-2.6.20/drivers/video/Makefile
===================================================================
--- linux-2.6.20.orig/drivers/video/Makefile
+++ linux-2.6.20/drivers/video/Makefile
@@ -99,6 +99,7 @@ obj-$(CONFIG_FB_PNX4008_DUM_RGB) += pnx
obj-$(CONFIG_FB_IBM_GXT4500) += gxt4500.o
obj-$(CONFIG_FB_PS3) += ps3fb.o
obj-$(CONFIG_FB_SM501) += sm501fb.o
+obj-$(CONFIG_FB_XILINX) += xilinxfb.o
# Platform or fallback drivers go here
obj-$(CONFIG_FB_VESA) += vesafb.o
Index: linux-2.6.20/drivers/video/xilinxfb.c
===================================================================
--- /dev/null
+++ linux-2.6.20/drivers/video/xilinxfb.c
@@ -0,0 +1,377 @@
+/*
+ * xilinxfb.c
+ *
+ * Xilinx TFT LCD frame buffer driver
+ *
+ * Author: MontaVista Software, Inc.
+ * source@mvista.com
+ *
+ * 2002-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.
+ */
+
+/*
+ * This driver was based on au1100fb.c by MontaVista rewritten for 2.6
+ * by Embedded Alley Solutions <source@embeddedalley.com>, which in turn
+ * was based on skeletonfb.c, Skeleton for a frame buffer device by
+ * Geert Uytterhoeven.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/version.h>
+#include <linux/errno.h>
+#include <linux/string.h>
+#include <linux/mm.h>
+#include <linux/fb.h>
+#include <linux/init.h>
+#include <linux/dma-mapping.h>
+#include <linux/platform_device.h>
+
+#include <asm/io.h>
+#include <syslib/virtex_devices.h>
+
+#define DRIVER_NAME "xilinxfb"
+#define DRIVER_DESCRIPTION "Xilinx TFT LCD frame buffer driver"
+
+/*
+ * The interface to the framebuffer is nice and simple. There are two
+ * control registers. The first tells the LCD interface where in memory
+ * the frame buffer is (only the 11 most significant bits are used, so
+ * don't start thinking about scrolling). The second allows the LCD to
+ * be turned on or off as well as rotated 180 degrees.
+ */
+#define NUM_REGS 2
+#define REG_FB_ADDR 0
+#define REG_CTRL 1
+#define REG_CTRL_ENABLE 0x0001
+#define REG_CTRL_ROTATE 0x0002
+#if defined(CONFIG_FB_XILINX_ROTATE)
+#define REG_CTRL_DEFAULT (REG_CTRL_ENABLE | REG_CTRL_ROTATE)
+#else
+#define REG_CTRL_DEFAULT (REG_CTRL_ENABLE)
+#endif /* CONFIG_FB_XILINX_ROTATE */
+
+/*
+ * The hardware only handles a single mode: 640x480 24 bit true
+ * color. Each pixel gets a word (32 bits) of memory. Within each word,
+ * the 8 most significant bits are ignored, the next 8 bits are the red
+ * level, the next 8 bits are the green level and the 8 least
+ * significant bits are the blue level. Each row of the LCD uses 1024
+ * words, but only the first 640 pixels are displayed with the other 384
+ * words being ignored. There are 480 rows.
+ */
+#define BYTES_PER_PIXEL 4
+#define BITS_PER_PIXEL (BYTES_PER_PIXEL * 8)
+#define XRES 640
+#define YRES 480
+#define XRES_VIRTUAL 1024
+#define YRES_VIRTUAL YRES
+#define LINE_LENGTH (XRES_VIRTUAL * BYTES_PER_PIXEL)
+#define FB_SIZE (YRES_VIRTUAL * LINE_LENGTH)
+
+#define PALETTE_ENTRIES_NO 16 /* passed to fb_alloc_cmap() */
+
+/*
+ * Here are the default fb_fix_screeninfo and fb_var_screeninfo structures
+ */
+static struct fb_fix_screeninfo xilinx_fb_fix __initdata = {
+ .id = "Xilinx",
+ .type = FB_TYPE_PACKED_PIXELS,
+ .visual = FB_VISUAL_TRUECOLOR,
+ .smem_len = FB_SIZE,
+ .line_length = LINE_LENGTH,
+ .accel = FB_ACCEL_NONE
+};
+
+static struct fb_var_screeninfo xilinx_fb_var __initdata = {
+ .xres = XRES,
+ .yres = YRES,
+ .xres_virtual = XRES_VIRTUAL,
+ .yres_virtual = YRES_VIRTUAL,
+
+ .bits_per_pixel = BITS_PER_PIXEL,
+
+ .red = { 16, 8, 0 },
+ .green = { 8, 8, 0 },
+ .blue = { 0, 8, 0 },
+ .transp = { 0, 0, 0 },
+
+ .activate = FB_ACTIVATE_NOW
+};
+
+struct xilinxfb_drvdata {
+
+ struct fb_info info; /* FB driver info record */
+
+ u32 regs_phys; /* phys. address of the control registers */
+ u32 __iomem *regs; /* virt. address of the control registers */
+ u32 use_dcr; /* (use_dcr) ? mtdcr() : out_be32(); */
+
+ unsigned char __iomem *fb_virt; /* virt. address of the frame buffer */
+ dma_addr_t fb_phys; /* phys. address of the frame buffer */
+
+ u32 pseudo_palette[16]; /* Fake palette of 16 colors */
+};
+
+#define to_xilinxfb_drvdata(_info) \
+ container_of(_info, struct xilinxfb_drvdata, info)
+
+#define xilinx_fb_out_be32(driverdata, offset, val) \
+ if (driverdata->use_dcr) \
+ mtdcr(driverdata->regs_phys + offset, val); \
+ else \
+ out_be32(driverdata->regs + offset, val)
+
+static int
+xilinx_fb_setcolreg(unsigned regno, unsigned red, unsigned green, unsigned blue,
+ unsigned transp, struct fb_info *fbi)
+{
+ u32 *palette = fbi->pseudo_palette;
+
+ if (regno >= PALETTE_ENTRIES_NO)
+ return -EINVAL;
+
+ if (fbi->var.grayscale) {
+ /* Convert color to grayscale.
+ * grayscale = 0.30*R + 0.59*G + 0.11*B */
+ red = green = blue =
+ (red * 77 + green * 151 + blue * 28 + 127) >> 8;
+ }
+
+ /* fbi->fix.visual is always FB_VISUAL_TRUECOLOR */
+
+ /* We only handle 8 bits of each color. */
+ red >>= 8;
+ green >>= 8;
+ blue >>= 8;
+ palette[regno] = (red << 16) | (green << 8) | blue;
+
+ return 0;
+}
+
+static int
+xilinx_fb_blank(int blank_mode, struct fb_info *fbi)
+{
+ struct xilinxfb_drvdata *drvdata = to_xilinxfb_drvdata(fbi);
+
+ switch (blank_mode) {
+ case VESA_NO_BLANKING:
+ /* turn on panel */
+ xilinx_fb_out_be32(drvdata, REG_CTRL, REG_CTRL_DEFAULT);
+ break;
+
+ case VESA_VSYNC_SUSPEND:
+ case VESA_HSYNC_SUSPEND:
+ case VESA_POWERDOWN:
+ /* turn off panel */
+ xilinx_fb_out_be32(drvdata, REG_CTRL, 0);
+ default:
+ break;
+
+ }
+ return 0; /* success */
+}
+
+static int
+xilinx_fb_pan_display(struct fb_var_screeninfo *var, struct fb_info *fbi)
+{
+ if (var->xoffset != 0 || var->yoffset != 0)
+ return -EINVAL;
+
+ return 0;
+}
+
+static struct fb_ops xilinxfb_ops =
+{
+ .owner = THIS_MODULE,
+ .fb_setcolreg = xilinx_fb_setcolreg,
+ .fb_blank = xilinx_fb_blank,
+ .fb_pan_display = xilinx_fb_pan_display,
+ .fb_fillrect = cfb_fillrect,
+ .fb_copyarea = cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+};
+
+/* === The device driver === */
+
+static int
+xilinxfb_drv_probe(struct device *dev)
+{
+ struct platform_device *pdev;
+ struct xilinxfb_platform_data *pdata;
+ struct xilinxfb_drvdata *drvdata;
+ struct resource *regs_res;
+ int retval;
+
+ if (!dev)
+ return -EINVAL;
+
+ pdev = to_platform_device(dev);
+ pdata = (struct xilinxfb_platform_data *)pdev->dev.platform_data;
+
+ if (pdata == NULL) {
+ printk(KERN_ERR "Couldn't find platform data.\n");
+ return -EFAULT;
+ }
+
+ drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata) {
+ printk(KERN_ERR "Couldn't allocate device private record\n");
+ return -ENOMEM;
+ }
+ dev_set_drvdata(dev, (void *)drvdata);
+
+ /* Map the control registers in */
+ regs_res = platform_get_resource(pdev, IORESOURCE_IO, 0);
+ if (!regs_res || (regs_res->end - regs_res->start + 1 < 8)) {
+ printk(KERN_ERR "Couldn't get registers resource\n");
+ retval = -EFAULT;
+ goto failed1;
+ }
+
+ drvdata->use_dcr = pdata->use_dcr;
+ if (!drvdata->use_dcr) {
+ if (!request_mem_region(regs_res->start, 8, DRIVER_NAME)) {
+ printk(KERN_ERR
+ "Couldn't lock memory region at 0x%08X\n",
+ regs_res->start);
+ retval = -EBUSY;
+ goto failed1;
+ }
+ drvdata->regs = (u32 __iomem*) ioremap(regs_res->start, 8);
+ }
+ drvdata->regs_phys = regs_res->start;
+
+ /* Allocate the framebuffer memory */
+ drvdata->fb_virt = dma_alloc_coherent(dev, PAGE_ALIGN(FB_SIZE),
+ &drvdata->fb_phys, GFP_KERNEL);
+ if (!drvdata->fb_virt) {
+ printk(KERN_ERR "Could not allocate frame buffer memory\n");
+ retval = -ENOMEM;
+ goto failed2;
+ }
+
+ /* Clear (turn to black) the framebuffer */
+ memset((void *) drvdata->fb_virt, 0, FB_SIZE);
+
+ /* Tell the hardware where the frame buffer is */
+ xilinx_fb_out_be32(drvdata, REG_FB_ADDR, drvdata->fb_phys);
+
+ /* Turn on the display */
+ xilinx_fb_out_be32(drvdata, REG_CTRL, REG_CTRL_DEFAULT);
+
+ /* Fill struct fb_info */
+ drvdata->info.screen_base = drvdata->fb_virt;
+ drvdata->info.fbops = &xilinxfb_ops;
+ drvdata->info.fix = xilinx_fb_fix;
+ drvdata->info.fix.smem_start = drvdata->fb_phys;
+ drvdata->info.pseudo_palette = drvdata->pseudo_palette;
+
+ if (fb_alloc_cmap(&drvdata->info.cmap, PALETTE_ENTRIES_NO, 0) < 0) {
+ printk(KERN_ERR "Fail to allocate colormap (%d entries)\n",
+ PALETTE_ENTRIES_NO);
+ retval = -EFAULT;
+ goto failed3;
+ }
+
+ drvdata->info.flags = FBINFO_DEFAULT;
+ xilinx_fb_var.height = pdata->screen_height_mm;
+ xilinx_fb_var.width = pdata->screen_width_mm;
+ drvdata->info.var = xilinx_fb_var;
+
+ /* Register new frame buffer */
+ if (register_framebuffer(&drvdata->info) < 0) {
+ printk(KERN_ERR "Could not register frame buffer\n");
+ retval = -EINVAL;
+ goto failed4;
+ }
+
+ return 0; /* success */
+
+failed4:
+ fb_dealloc_cmap(&drvdata->info.cmap);
+
+failed3:
+ dma_free_coherent(dev, PAGE_ALIGN(FB_SIZE), drvdata->fb_virt,
+ drvdata->fb_phys);
+
+ /* Turn off the display */
+ xilinx_fb_out_be32(drvdata, REG_CTRL, 0);
+ if (!drvdata->use_dcr) iounmap(drvdata->regs);
+
+failed2:
+ release_mem_region(regs_res->start, 8);
+
+failed1:
+ kfree(drvdata);
+ dev_set_drvdata(dev, NULL);
+
+ return retval;
+}
+
+static int
+xilinxfb_drv_remove(struct device *dev)
+{
+ struct xilinxfb_drvdata *drvdata;
+
+ if (!dev)
+ return -ENODEV;
+
+ drvdata = (struct xilinxfb_drvdata *) dev_get_drvdata(dev);
+
+#if !defined(CONFIG_FRAMEBUFFER_CONSOLE) && defined(CONFIG_LOGO)
+ xilinx_fb_blank(VESA_POWERDOWN, &drvdata->info);
+#endif
+
+ unregister_framebuffer(&drvdata->info);
+
+ fb_dealloc_cmap(&drvdata->info.cmap);
+
+ dma_free_coherent(dev, PAGE_ALIGN(FB_SIZE), drvdata->fb_virt,
+ drvdata->fb_phys);
+
+ /* Turn off the display */
+ xilinx_fb_out_be32(drvdata, REG_CTRL, 0);
+ if (!drvdata->use_dcr) iounmap(drvdata->regs);
+
+ release_mem_region(drvdata->regs_phys, 8);
+
+ kfree(drvdata);
+ dev_set_drvdata(dev, NULL);
+
+ return 0;
+}
+
+
+static struct device_driver xilinxfb_driver = {
+ .name = DRIVER_NAME,
+ .bus = &platform_bus_type,
+
+ .probe = xilinxfb_drv_probe,
+ .remove = xilinxfb_drv_remove
+};
+
+static int __init
+xilinxfb_init(void)
+{
+ /*
+ * No kernel boot options used,
+ * so we just need to register the driver
+ */
+ return driver_register(&xilinxfb_driver);
+}
+
+static void __exit
+xilinxfb_cleanup(void)
+{
+ driver_unregister(&xilinxfb_driver);
+}
+
+module_init(xilinxfb_init);
+module_exit(xilinxfb_cleanup);
+
+MODULE_AUTHOR("MontaVista Software, Inc. <source@mvista.com>");
+MODULE_DESCRIPTION(DRIVER_DESCRIPTION);
+MODULE_LICENSE("GPL");
Index: linux-2.6.20/arch/ppc/syslib/virtex_devices.c
===================================================================
--- linux-2.6.20.orig/arch/ppc/syslib/virtex_devices.c
+++ linux-2.6.20/arch/ppc/syslib/virtex_devices.c
@@ -90,6 +90,18 @@ struct plat_serial8250_port virtex_seria
};
+/* ML300/403 reference design framebuffer driver platform data table */
+static struct xilinxfb_platform_data xilinxfb_pdata = {
+#if defined(XPAR_TFT_0_USE_DCR) && (XPAR_TFT_0_USE_DCR != 0)
+ .use_dcr = 1,
+#else
+ .use_dcr = 0,
+#endif
+ .screen_height_mm = CONFIG_FB_XILINX_SCR_HEIGHT,
+ .screen_width_mm = CONFIG_FB_XILINX_SCR_WIDTH,
+};
+
+
struct platform_device virtex_platform_devices[] = {
/* UARTLITE instances */
#if defined(XPAR_UARTLITE_0_BASEADDR)
@@ -127,6 +139,7 @@ struct platform_device virtex_platform_d
{
.name = "xilinxfb",
.id = 0,
+ .dev.platform_data = &xilinxfb_pdata,
.num_resources = 1,
.resource = (struct resource[]) {
{
Index: linux-2.6.20/arch/ppc/syslib/virtex_devices.h
===================================================================
--- linux-2.6.20.orig/arch/ppc/syslib/virtex_devices.h
+++ linux-2.6.20/arch/ppc/syslib/virtex_devices.h
@@ -13,6 +13,13 @@
#include <linux/platform_device.h>
+/* ML300/403 reference design framebuffer driver platform data struct */
+struct xilinxfb_platform_data {
+ u32 use_dcr;
+ u32 screen_height_mm;
+ u32 screen_width_mm;
+};
+
void __init virtex_early_serial_map(void);
/* Prototype for device fixup routine. Implement this routine in the
^ permalink raw reply
* Re: fads823 ethernet interface does (seams) not send data
From: Jason.Work @ 2007-04-26 17:52 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 368 bytes --]
"In your case, you'll notice that the PA7/ETHTCK from the motherboard is
really connected to PA5/ETHTCK on the daughtercard. I have seen
Ethernet working on the MPC823FADS board, so I know it CAN be done."
I've got half-duplex communication over SNI working but now I want to move
to full-duplex. My changes are not working. Have you seen this done
successfully?
[-- Attachment #2: Type: text/html, Size: 470 bytes --]
^ permalink raw reply
* Re: BUG: NETDEV WATCHDOG -> Badness in gianfar driver?
From: Andy Gospodarek @ 2007-04-26 17:51 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <4630E0F3.10100@anagramm.de>
On 4/26/07, Clemens Koller <clemens.koller@anagramm.de> wrote:
> Hi There!
>
> I am currently using
> Linux ecam.anagramm.de 2.6.21-rc5-g9a5ee4cc #4 Mon Apr 2 21:31:53 CEST 20=
07 ppc e500 GNU/Linux
> on an mpc8540 embedded powerpc system.
>
> The system was running fine for many days and weeks without any problems.
> However, just a few minutes ago I noticed a single clicking sound of the =
harddisk
> (like a head recalibration), so I checked the system.
> I couldn't connect to it via ssh anymore, but via a serial console I got
> at least endless messages as shown below...
> After a reboot, everything looks fine again but the kernel log grew up
> to several MBytes. I pasted the hopefully interesting part below.
>
> Any ideas of what could be wrong there? I think there could be a problem
> in the gianfar network driver. Or is there a physical problem with the PH=
Y
> (a Marvell MV88E1111)?
>
> Any recommendations of how to debug that thingy?
There were some workarounds in the e1000 driver to address some issues
with some Marvell 88E parts, so you might want to check those out.
>
> ----- 8< ----- cut here
> Jan 1 01:00:38 ecam kernel: PHY: 0:00 - Link is Up - 100/Full
> Jan 1 01:00:35 ecam network: Bringing up loopback interface: succeeded
> Jan 1 01:00:47 ecam mount: mount: RPC: Remote system error - No route to=
host
> Jan 1 01:00:47 ecam netfs: Mounting NFS filesystems: failed
> Jan 1 01:00:47 ecam netfs: Mounting other filesystems: succeeded
> Jan 1 01:00:47 ecam xinetd[665]: xinetd Version 2.3.11 started with libw=
rap options compiled in.
> Jan 1 01:00:47 ecam xinetd[665]: Started working: 1 available service
> Jan 1 01:00:50 ecam xinetd: xinetd startup succeeded
> Jan 1 01:00:50 ecam rc: Starting sshd: succeeded
> Jan 1 01:00:51 ecam rc: Starting samba: succeeded
> Jan 1 03:43:23 ecam kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Jan 1 03:43:23 ecam kernel: ------------[ cut here ]------------
> Jan 1 03:43:23 ecam kernel: Badness at c003d3d8 [verbose debug info unav=
ailable]
> Jan 1 03:43:23 ecam kernel: Call Trace:
> Jan 1 03:43:23 ecam kernel: [C0355C70] [C0008FE0] show_stack+0x3c/0x194 =
(unreliable)
> Jan 1 03:43:23 ecam kernel: [C0355CA0] [C0135594] report_bug+0xa4/0xac
> Jan 1 03:43:23 ecam kernel: [C0355CB0] [C0003784] program_check_exceptio=
n+0x2b8/0x460
> Jan 1 03:43:23 ecam kernel: [C0355CD0] [C0002908] ret_from_except_full+0=
x0/0x4c
> Jan 1 03:43:23 ecam kernel: [C0355D90] [C017B3CC] marvell_ack_interrupt+=
0x14/0x38
> Jan 1 03:43:23 ecam kernel: [C0355DB0] [C01764A8] stop_gfar+0x54/0xd0
> Jan 1 03:43:23 ecam kernel: [C0355DD0] [C01773D0] gfar_timeout+0x5c/0x68
> Jan 1 03:43:23 ecam kernel: [C0355DE0] [C020A060] dev_watchdog+0x110/0x1=
18
> Jan 1 03:43:23 ecam kernel: [C0355E00] [C0024228] run_timer_softirq+0x14=
8/0x1a8
> Jan 1 03:43:23 ecam kernel: [C0355E40] [C002006C] __do_softirq+0x78/0xe4
> Jan 1 03:43:23 ecam kernel: [C0355E70] [C0007054] do_softirq+0x54/0x58
> Jan 1 03:43:23 ecam kernel: [C0355E80] [C001FE4C] irq_exit+0x48/0x58
> Jan 1 03:43:23 ecam kernel: [C0355E90] [C0004000] timer_interrupt+0x17c/=
0x224
> Jan 1 03:43:23 ecam kernel: [C0355ED0] [C0002954] ret_from_except+0x0/0x=
18
> Jan 1 03:43:23 ecam kernel: [C0355F90] [C0009FB8] cpu_idle+0xc0/0xd0
> Jan 1 03:43:23 ecam kernel: [C0355FB0] [C0001A7C] rest_init+0x28/0x38
> Jan 1 03:43:23 ecam kernel: [C0355FC0] [C03568E4] start_kernel+0x220/0x2=
9c
> Jan 1 03:43:23 ecam kernel: [C0355FF0] [C0000388] skpinv+0x2b8/0x2f4
> Jan 1 03:43:23 ecam kernel: ------------[ cut here ]------------
> Jan 1 03:43:23 ecam kernel: Badness at c003d3d8 [verbose debug info unav=
ailable]
> Jan 1 03:43:23 ecam kernel: Call Trace:
> Jan 1 03:43:23 ecam kernel: [C0355C70] [C0008FE0] show_stack+0x3c/0x194 =
(unreliable)
> [...repeating forever...]
> ----- 8< ----- cut here
>
> The system time is wrong, because the I2C realtime clock cannot be read
> on this system due to some kernel misconfiguration which I didn't care ab=
out.
>
> Thank you in advance,
> --
> Clemens Koller
> __________________________________
> R&D Imaging Devices
> Anagramm GmbH
> Rupert-Mayer-Stra=DFe 45/1
> Linhof Werksgel=E4nde
> D-81379 M=FCnchen
> Tel.089-741518-50
> Fax 089-741518-19
> http://www.anagramm-technology.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* BUG: NETDEV WATCHDOG -> Badness in gianfar driver?
From: Clemens Koller @ 2007-04-26 17:27 UTC (permalink / raw)
To: linuxppc-embedded
Hi There!
I am currently using
Linux ecam.anagramm.de 2.6.21-rc5-g9a5ee4cc #4 Mon Apr 2 21:31:53 CEST 2007 ppc e500 GNU/Linux
on an mpc8540 embedded powerpc system.
The system was running fine for many days and weeks without any problems.
However, just a few minutes ago I noticed a single clicking sound of the harddisk
(like a head recalibration), so I checked the system.
I couldn't connect to it via ssh anymore, but via a serial console I got
at least endless messages as shown below...
After a reboot, everything looks fine again but the kernel log grew up
to several MBytes. I pasted the hopefully interesting part below.
Any ideas of what could be wrong there? I think there could be a problem
in the gianfar network driver. Or is there a physical problem with the PHY
(a Marvell MV88E1111)?
Any recommendations of how to debug that thingy?
----- 8< ----- cut here
Jan 1 01:00:38 ecam kernel: PHY: 0:00 - Link is Up - 100/Full
Jan 1 01:00:35 ecam network: Bringing up loopback interface: succeeded
Jan 1 01:00:47 ecam mount: mount: RPC: Remote system error - No route to host
Jan 1 01:00:47 ecam netfs: Mounting NFS filesystems: failed
Jan 1 01:00:47 ecam netfs: Mounting other filesystems: succeeded
Jan 1 01:00:47 ecam xinetd[665]: xinetd Version 2.3.11 started with libwrap options compiled in.
Jan 1 01:00:47 ecam xinetd[665]: Started working: 1 available service
Jan 1 01:00:50 ecam xinetd: xinetd startup succeeded
Jan 1 01:00:50 ecam rc: Starting sshd: succeeded
Jan 1 01:00:51 ecam rc: Starting samba: succeeded
Jan 1 03:43:23 ecam kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jan 1 03:43:23 ecam kernel: ------------[ cut here ]------------
Jan 1 03:43:23 ecam kernel: Badness at c003d3d8 [verbose debug info unavailable]
Jan 1 03:43:23 ecam kernel: Call Trace:
Jan 1 03:43:23 ecam kernel: [C0355C70] [C0008FE0] show_stack+0x3c/0x194 (unreliable)
Jan 1 03:43:23 ecam kernel: [C0355CA0] [C0135594] report_bug+0xa4/0xac
Jan 1 03:43:23 ecam kernel: [C0355CB0] [C0003784] program_check_exception+0x2b8/0x460
Jan 1 03:43:23 ecam kernel: [C0355CD0] [C0002908] ret_from_except_full+0x0/0x4c
Jan 1 03:43:23 ecam kernel: [C0355D90] [C017B3CC] marvell_ack_interrupt+0x14/0x38
Jan 1 03:43:23 ecam kernel: [C0355DB0] [C01764A8] stop_gfar+0x54/0xd0
Jan 1 03:43:23 ecam kernel: [C0355DD0] [C01773D0] gfar_timeout+0x5c/0x68
Jan 1 03:43:23 ecam kernel: [C0355DE0] [C020A060] dev_watchdog+0x110/0x118
Jan 1 03:43:23 ecam kernel: [C0355E00] [C0024228] run_timer_softirq+0x148/0x1a8
Jan 1 03:43:23 ecam kernel: [C0355E40] [C002006C] __do_softirq+0x78/0xe4
Jan 1 03:43:23 ecam kernel: [C0355E70] [C0007054] do_softirq+0x54/0x58
Jan 1 03:43:23 ecam kernel: [C0355E80] [C001FE4C] irq_exit+0x48/0x58
Jan 1 03:43:23 ecam kernel: [C0355E90] [C0004000] timer_interrupt+0x17c/0x224
Jan 1 03:43:23 ecam kernel: [C0355ED0] [C0002954] ret_from_except+0x0/0x18
Jan 1 03:43:23 ecam kernel: [C0355F90] [C0009FB8] cpu_idle+0xc0/0xd0
Jan 1 03:43:23 ecam kernel: [C0355FB0] [C0001A7C] rest_init+0x28/0x38
Jan 1 03:43:23 ecam kernel: [C0355FC0] [C03568E4] start_kernel+0x220/0x29c
Jan 1 03:43:23 ecam kernel: [C0355FF0] [C0000388] skpinv+0x2b8/0x2f4
Jan 1 03:43:23 ecam kernel: ------------[ cut here ]------------
Jan 1 03:43:23 ecam kernel: Badness at c003d3d8 [verbose debug info unavailable]
Jan 1 03:43:23 ecam kernel: Call Trace:
Jan 1 03:43:23 ecam kernel: [C0355C70] [C0008FE0] show_stack+0x3c/0x194 (unreliable)
[...repeating forever...]
----- 8< ----- cut here
The system time is wrong, because the I2C realtime clock cannot be read
on this system due to some kernel misconfiguration which I didn't care about.
Thank you in advance,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* [PATCH] bootwrapper: cuboot-83xx: Exclude upper 1MB from heap.
From: Scott Wood @ 2007-04-26 17:19 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
The uppermost part of memory is where u-boot puts the stack, so don't
include that in the heap. It's not currently causing problems, as the
current code allocates from the bottom of the heap, but this will keep
things from potentially breaking if a future implementation were to
allocate from the top.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/boot/cuboot-83xx.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/cuboot-83xx.c b/arch/powerpc/boot/cuboot-83xx.c
index 8f11d1e..6cbc20a 100644
--- a/arch/powerpc/boot/cuboot-83xx.c
+++ b/arch/powerpc/boot/cuboot-83xx.c
@@ -61,7 +61,7 @@ void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
loader_info.cmdline = (char *)r6;
loader_info.cmdline_len = r7 - r6;
- simple_alloc_init(_end, avail_ram, 32, 64);
+ simple_alloc_init(_end, avail_ram - 1024*1024, 32, 64);
ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
serial_console_init();
platform_ops.fixups = platform_fixups;
--
1.5.0.3
^ permalink raw reply related
* [PATCH] bootwrapper: cuImage for 85xx
From: Scott Wood @ 2007-04-26 17:09 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/boot/Makefile | 3 +-
arch/powerpc/boot/cuboot-85xx.c | 69 +++++++++++++++++++++++++++++++++++++++
3 files changed, 72 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/cuboot-85xx.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9b9c00e..a54a9a2 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -169,6 +169,7 @@ config PPC_85xx
select E500
select FSL_SOC
select 85xx
+ select WANT_DEVICE_TREE
config PPC_86xx
bool "Freescale 86xx"
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 3e172ff..6dda40c 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -43,7 +43,7 @@ $(addprefix $(obj)/,$(zlib) main.o): $(addprefix $(obj)/,$(zliblinuxheader)) \
src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
ns16550.c serial.c simple_alloc.c div64.S util.S \
gunzip_util.c elf_util.c $(zlib) devtree.c
-src-plat := of.c cuboot-83xx.c
+src-plat := of.c cuboot-83xx.c cuboot-85xx.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -163,6 +163,7 @@ $(obj)/uImage: vmlinux $(wrapperbits)
$(call if_changed,wrap,uboot)
cuboot-plat-$(CONFIG_83xx) += 83xx
+cuboot-plat-$(CONFIG_85xx) += 85xx
cuboot-plat-y += unknown-platform
dts = $(if $(shell echo $(CONFIG_) | grep '^/'),\
diff --git a/arch/powerpc/boot/cuboot-85xx.c b/arch/powerpc/boot/cuboot-85xx.c
new file mode 100644
index 0000000..b82044e
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-85xx.c
@@ -0,0 +1,69 @@
+/*
+ * Old U-boot compatibility for 85xx
+ *
+ * Author: Scott Wood <scottwood@freescale.com>
+ *
+ * Copyright (c) 2007 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 version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "stdio.h"
+
+#define TARGET_85xx
+#include "ppcboot.h"
+
+static bd_t bd;
+extern char _end[];
+extern char _dtb_start[], _dtb_end[];
+
+static void platform_fixups(void)
+{
+ void *soc;
+
+ dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+ dt_fixup_mac_addresses(bd.bi_enetaddr, bd.bi_enet1addr,
+ bd.bi_enet2addr);
+ dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 8, bd.bi_busfreq);
+
+ /* Unfortunately, the specific model number is encoded in the
+ * soc node name in existing dts files -- once that is fixed,
+ * this can do a simple path lookup.
+ */
+ soc = find_node_by_devtype(NULL, "soc");
+ if (soc) {
+ void *serial = NULL;
+
+ setprop(soc, "bus-frequency", &bd.bi_busfreq,
+ sizeof(bd.bi_busfreq));
+
+ while ((serial = find_node_by_devtype(serial, "serial"))) {
+ if (get_parent(serial) != soc)
+ continue;
+
+ setprop(serial, "clock-frequency", &bd.bi_busfreq,
+ sizeof(bd.bi_busfreq));
+ }
+ }
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ unsigned long end_of_ram = bd.bi_memstart + bd.bi_memsize;
+ unsigned long avail_ram = end_of_ram - (unsigned long)_end;
+
+ memcpy(&bd, (bd_t *)r3, sizeof(bd));
+ loader_info.initrd_addr = r4;
+ loader_info.initrd_size = r4 ? r5 : 0;
+ loader_info.cmdline = (char *)r6;
+ loader_info.cmdline_len = r7 - r6;
+
+ simple_alloc_init(_end, avail_ram - 1024*1024, 32, 64);
+ ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
+ serial_console_init();
+ platform_ops.fixups = platform_fixups;
+}
--
1.5.0.3
^ permalink raw reply related
* Re: [PATCH v2] [2.6.22] pasemi: cpufreq driver
From: Arnd Bergmann @ 2007-04-26 17:11 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, egor, paulus, cpufreq
In-Reply-To: <20070426164835.GA14149@lixom.net>
On Thursday 26 April 2007, Olof Johansson wrote:
> SDC is the system and debug controller, it contains a number of smaller
> devices such as the PIC, the PMU (Gizmo), RNG, and various debug
> features. Some already have drivers submitted, others will later on.
Oh well, these chips all seem to be the same. On cell, we have solved
the problem by introducing the 'cbe_regs' helper library that gives
access to all those miscellaneous registers to the individual device
drivers, so that not all of them need to scan the device tree for
the same registers and map them individually.
The problem with an of_platform_driver for this would be that you
can only have _one_ driver attached to the registers.
> Unfortunately the setting of the current active state is done to an SDC
> register, while information of the states is in the PMU, so access to
> both is needed in the driver.
One thing that you could do is to list only this one register of the
SDC in the reg property, not all of the SDC.
Arnd <><
^ permalink raw reply
* [PATCH] bootwrapper: Fix array handling in dt_xlate_reg().
From: Scott Wood @ 2007-04-26 17:08 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
This fixes a few bugs in how dt_xlate_reg() handles address arrays:
1. copy_val() was copying into the wrong end of the array, resulting
in random stack garbage at the other end.
2. dt_xlate_reg() was getting the result from the wrong end of the array.
3. add_reg() and sub_reg() were treating the arrays as
little-endian rather than big-endian.
4. add_reg() only returned an error on a carry out of the entire
array, rather than out of the naddr portion.
5. The requested reg resource was checked to see if it exceeded
the size of the reg property, but not to see if it exceeded the
size of the buffer.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/boot/devtree.c | 23 +++++++++++------------
1 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/boot/devtree.c b/arch/powerpc/boot/devtree.c
index 23492d7..ac4b5ee 100644
--- a/arch/powerpc/boot/devtree.c
+++ b/arch/powerpc/boot/devtree.c
@@ -123,15 +123,17 @@ static void get_reg_format(void *node, u32 *naddr, u32 *nsize)
static void copy_val(u32 *dest, u32 *src, int naddr)
{
- memset(dest, 0, (MAX_ADDR_CELLS - naddr) * 4);
- memcpy(dest, src, naddr * 4);
+ int pad = MAX_ADDR_CELLS - naddr;
+
+ memset(dest, 0, pad * 4);
+ memcpy(dest + pad, src, naddr * 4);
}
static int sub_reg(u32 *reg, u32 *sub)
{
int i, borrow = 0;
- for (i = 0; i < MAX_ADDR_CELLS; i++) {
+ for (i = MAX_ADDR_CELLS - 1; i >= 0; i--) {
int prev_borrow = borrow;
borrow = reg[i] < sub[i] + prev_borrow;
reg[i] -= sub[i] + prev_borrow;
@@ -140,11 +142,11 @@ static int sub_reg(u32 *reg, u32 *sub)
return !borrow;
}
-static int add_reg(u32 *reg, u32 *add)
+static int add_reg(u32 *reg, u32 *add, int naddr)
{
int i, carry = 0;
- for (i = 0; i < MAX_ADDR_CELLS; i++) {
+ for (i = MAX_ADDR_CELLS - 1; i >= MAX_ADDR_CELLS - naddr; i--) {
u64 tmp = (u64)reg[i] + add[i] + carry;
carry = tmp >> 32;
reg[i] = (u32)tmp;
@@ -228,7 +230,8 @@ int dt_xlate_reg(void *node, int res, unsigned long *addr,
buflen = getprop(node, "reg", buf, sizeof(buf)) / 4;
offset = (naddr + nsize) * res;
- if (buflen < offset + naddr + nsize)
+ if (buflen < offset + naddr + nsize ||
+ sizeof(buf) < offset + naddr + nsize)
return 0;
copy_val(last_addr, buf + offset, naddr);
@@ -263,18 +266,14 @@ int dt_xlate_reg(void *node, int res, unsigned long *addr,
copy_val(this_addr, buf + offset + prev_naddr, naddr);
- if (!add_reg(last_addr, this_addr))
+ if (!add_reg(last_addr, this_addr, naddr))
return 0;
}
if (naddr > 2)
return 0;
- ret_addr = last_addr[0];
- if (naddr == 2) {
- ret_addr <<= 32;
- ret_addr |= last_addr[1];
- }
+ ret_addr = ((u64)last_addr[2] << 32) | last_addr[3];
if (sizeof(void *) == 4 &&
(ret_addr >= 0x100000000ULL || ret_size > 0x100000000ULL ||
--
1.5.0.3
^ permalink raw reply related
* Re: [PATCH] powerpc: Add EDAC platform devices for 85xx
From: Dave Jiang @ 2007-04-26 16:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, bluesmoke-devel, david
In-Reply-To: <9903F55A-5E4E-42CE-8C27-6B7143B9FE25@kernel.crashing.org>
Kumar Gala wrote:
> On Apr 25, 2007, at 7:37 PM, Dave Jiang wrote:
>
>
>> + mem-ctrl@2000 {
>> + device_type = "mem-ctrl";
>> + compatible = "85xx";
>>
> I'm concerned this is too generic.
>
I'm supposing not all 85xx uses the same soc? Is there something more
appropriate you can suggest? Thx!
>> + reg = <2000 1000>;
>> + interrupt-parent = <&mpic>;
>> + interrupts = <2 2>;
>> + };
>> +
>> + l2-cache@20000 {
>> + device_type = "l2-cache";
>> + compatible = "85xx";
>> + reg = <20000 1000>;
>> + cache-line-size = <20>; // 32 bytes
>> + cache-size = <40000>; // L2, 256K
>> + 32-bit;
>>
>
> Why the 32-bit?
>
No reason particular. Bad assumption. I will remove it.
>> diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/
>> fsl_soc.c
>> index 8a123c7..a0beb8b 100644
>> --- a/arch/powerpc/sysdev/fsl_soc.c
>> +++ b/arch/powerpc/sysdev/fsl_soc.c
>> @@ -1103,3 +1103,118 @@ err:
>> arch_initcall(cpm_smc_uart_of_init);
>>
>> #endif /* CONFIG_8xx */
>> +
>> +/* platform device setup for EDAC */
>>
>
> Why not have the EDAC code for 85xx use of_device?
>
>
I will give that a try.
^ permalink raw reply
* Re: [PATCH v2] [2.6.22] pasemi: cpufreq driver
From: Olof Johansson @ 2007-04-26 16:48 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, egor, paulus, cpufreq
In-Reply-To: <200704261055.33739.arnd@arndb.de>
On Thu, Apr 26, 2007 at 10:55:33AM +0200, Arnd Bergmann wrote:
> On Thursday 26 April 2007, Olof Johansson wrote:
>
> > I chose not to do this as an of_platform driver since it doesn't fit
> > that well with the cpufreq driver model; having 3 levels of init/probe
> > functions is excessive.
>
> <snip>
>
> > + dn = of_find_compatible_node(NULL, "sdc", "1682m-sdc");
> > + if (!dn)
> > + goto out;
> > + err = of_address_to_resource(dn, 0, &res);
> > + of_node_put(dn);
> > + if (err)
> > + goto out;
> > + sdcasr_mapbase = ioremap(res.start + SDCASR_OFFSET, 0x2000);
> > + if (!sdcasr_mapbase) {
> > + err = -EINVAL;
> > + goto out;
> > + }
> > +
> > + dn = of_find_compatible_node(NULL, "gizmo", "1682m-gizmo");
> > + if (!dn) {
> > + err = -ENODEV;
> > + goto out_unmap_sdcasr;
> > + }
> > + err = of_address_to_resource(dn, 0, &res);
> > + of_node_put(dn);
> > + if (err)
> > + goto out_unmap_sdcasr;
> > + sdcpwr_mapbase = ioremap(res.start, 0x1000);
> > + if (!sdcpwr_mapbase) {
> > + err = -EINVAL;
> > + goto out_unmap_sdcasr;
> > + }
>
> What are sdc and gizmo anyway? If they are both only used for cpufreq, maybe the
> easiest way to do this with an of_platform_driver would be to have a single
> node that has two register ranges.
SDC is the system and debug controller, it contains a number of smaller
devices such as the PIC, the PMU (Gizmo), RNG, and various debug
features. Some already have drivers submitted, others will later on.
Unfortunately the setting of the current active state is done to an SDC
register, while information of the states is in the PMU, so access to
both is needed in the driver.
That doesn't change the fact that making this an of_platform driver
is excessive:
* module_init to register an of_platform driver
* of_platform walks the tree, calls probes
* of_platform driver probe code to register the cpufreq driver
* cpufreq calls it's registered drivers
* the cpufreq driver in turn will do the inits
Compare to:
* module_init registers cpufreq driver if machine_is_compatible()
* cpufreq calls it's registered drivers
* the cpufreq driver in turn will do the inits
Don't get me wrong, of_platform drivers are often convenient, but I
don't see it being a benefit to use them in this case.
-Olof
^ permalink raw reply
* Re: [PATCH 2/13] powerpc: Add dt_xlate_addr() to bootwrapper
From: Scott Wood @ 2007-04-26 16:44 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070425235543.GD4046@mag.az.mvista.com>
On Wed, Apr 25, 2007 at 04:55:43PM -0700, Mark A. Greer wrote:
> 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.
There's an extra blank line in dt_xlate_addr, but otherwise:
Acked-by: Scott Wood <scottwood@freescale.com>
-Scott
^ permalink raw reply
* Re: [PATCH 11/13] powerpc: Add DTS file for the Motorola PrPMC2800 platform
From: Scott Wood @ 2007-04-26 16:42 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070426000151.GM4046@mag.az.mvista.com>
On Wed, Apr 25, 2007 at 05:01:51PM -0700, Mark A. Greer wrote:
> + chosen {
> + linux,platform = <1>;
> + bootargs = "ip=on console=ttyMM0";
> + linux,stdout-path = "/mv64x60/mpsc@8000";
> + };
Isn't linux,platform obsolete?
-Scott
^ permalink raw reply
* gcj & PPC405
From: Patrick Olinet @ 2007-04-26 16:10 UTC (permalink / raw)
To: linuxppc-embedded
Hello all,
Is there anyone here with experience running gcj (gnu compiler for
java) compiled programs on a PPC405EP CPU ?
The native code produced by gcj runs fine on our embedded target
platform but it crashes when it has to interpret java byte code
("Illegal instruction" error message), although gcj has been compiled
with interpreter enabled.
gcj version is 3.4.3. linux kernel is 2.4.20. Unfortunately, it's hard
for us to upgrade any of them.
Any help would be really appreciated. Thanks in advance.
Regards,
Patrick Olinet
^ permalink raw reply
* Re: [PATCH][RFC] i2c: adds support for i2c bus on 8xx
From: Vitaly Bordug @ 2007-04-26 16:07 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev@ozlabs.org, lkml
In-Reply-To: <20070426175438.391157a1@hyperion.delvare>
On Thu, 26 Apr 2007 17:54:38 +0200
Jean Delvare <khali@linux-fr.org> wrote:
> Hi Vitaly,
>
> On Wed, 25 Apr 2007 21:06:10 +0400, Vitaly Bordug wrote:
> > Jean Delvare wrote:
> > >>>> +/* Structure for a device driver */
> > >>>> +static struct device_driver i2c_rpx_driver = {
> > >>>> + .name = "fsl-i2c-cpm",
> > >>>> + .bus = &platform_bus_type,
> > >>>> + .probe = i2c_rpx_probe,
> > >>>> + .remove = i2c_rpx_remove,
> > >>>> +};
> > >>>>
> > >>> Why don't you declare it as a struct platform_driver, register it with
> > >>> platform_driver_register() and unregister it with
> > >>> platform_driver_unregister()?
> > >>>
> > >> Well. This stuff belongs to CPM1, of the mpc8xx family, but the
> > >> target boards are different, and they may/should provide board
> > >> specific inits and filling of platform data. With
> > >> platform_driver_register we may end up with ifdef stuff here
> > >> (which is evil).
> > >>
> > >
> > > I don't follow you here, sorry. Platform devices are declared by
> > > board-specific code which can include all the needed initialization.
> > > And device-specific data can be carried to the platform driver for
> > > further use. The platform device/driver infrastructure is meant to
> > > handle that kind of situation, so there really is no excuse that I can
> > > see not to use it. i2c-omap and i2c-mpc use it. As a matter of fact you
> > > _are_ declaring a platform driver (.bus = &platform_bus_type), just not
> > > using the standard way.
> > >
> > >
> > Standard way here - platform devices got registered from elsewhere -
> > from arch/ppc/ppc_sys.c if arch/ppc or from
> > arch/powerpc/sysdev/fsl_soc.c if powerpc.
> > Every way (powerpc is more flexible since is pulling the information
> > from the firmware-passed device tree) fills in the resources and
> > platform data, and
> > is capable with device/drive bound you are talking about.
>
> This doesn't explain why you can't use platform_driver_register(),
> which is the right way to register a platform driver.
Ahm, I clearly confused myself (with device/driver stuff), sorry.
Anyway I think we'll look at of_device for this, to reduce extract from OF->insert platform device overhead.
--
Sincerely,
Vitaly
^ permalink raw reply
* ML403 and PPC4xx_DMA ?
From: Joachim Förster @ 2007-04-26 16:06 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I have a question regarding the PowerPC 405 Core on the Xilinx ML403
board and DMA . The Linux kernel has an option called CONFIG_PPC4xx_DMA.
Do all/some PowerPC 4xx Cores have an integrated DMA Controller? I tried
to find some documentation about this DMA Controller in several Xilinx
and IBM manuals which cover the PowerPC 405 Core - but I didn't find
anything.
So, my question is: Does the Virtex-4 FX12 PowerPC 405 Core on the ML403
have such DMA Controller? If yes, is it usable within Linux to transfer
data from RAM to a device's hardware buffers (typical task of a DMA
controller)?
Thanks,
Joachim
PS: I tried to compile a kernel image with CONFIG_PPC4xx_DMA enabled,
but gcc complains about missing definitions in ppc4xx_dma.c ... e.g.
DCRN_DMASR (defined in ibm405.h). Well I guess I have to have
DCRN_MASR_BASE defined in xparameters_ml403.h .... but defined to what?
^ permalink raw reply
* Re: [PATCH][RFC] i2c: adds support for i2c bus on 8xx
From: Jean Delvare @ 2007-04-26 15:54 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev@ozlabs.org, lkml
In-Reply-To: <462F8A82.40604@kernel.crashing.org>
Hi Vitaly,
On Wed, 25 Apr 2007 21:06:10 +0400, Vitaly Bordug wrote:
> Jean Delvare wrote:
> >>>> +/* Structure for a device driver */
> >>>> +static struct device_driver i2c_rpx_driver = {
> >>>> + .name = "fsl-i2c-cpm",
> >>>> + .bus = &platform_bus_type,
> >>>> + .probe = i2c_rpx_probe,
> >>>> + .remove = i2c_rpx_remove,
> >>>> +};
> >>>>
> >>> Why don't you declare it as a struct platform_driver, register it with
> >>> platform_driver_register() and unregister it with
> >>> platform_driver_unregister()?
> >>>
> >> Well. This stuff belongs to CPM1, of the mpc8xx family, but the
> >> target boards are different, and they may/should provide board
> >> specific inits and filling of platform data. With
> >> platform_driver_register we may end up with ifdef stuff here
> >> (which is evil).
> >>
> >
> > I don't follow you here, sorry. Platform devices are declared by
> > board-specific code which can include all the needed initialization.
> > And device-specific data can be carried to the platform driver for
> > further use. The platform device/driver infrastructure is meant to
> > handle that kind of situation, so there really is no excuse that I can
> > see not to use it. i2c-omap and i2c-mpc use it. As a matter of fact you
> > _are_ declaring a platform driver (.bus = &platform_bus_type), just not
> > using the standard way.
> >
> >
> Standard way here - platform devices got registered from elsewhere -
> from arch/ppc/ppc_sys.c if arch/ppc or from
> arch/powerpc/sysdev/fsl_soc.c if powerpc.
> Every way (powerpc is more flexible since is pulling the information
> from the firmware-passed device tree) fills in the resources and
> platform data, and
> is capable with device/drive bound you are talking about.
This doesn't explain why you can't use platform_driver_register(),
which is the right way to register a platform driver.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH v2] powerpc: 64K page support for kexec
From: Luke Browning @ 2007-04-26 15:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Olof Johansson, linuxppc-dev, Paul Mackerras, cbe-oss-dev,
Arnd Bergmann
In-Reply-To: <1177539585.14873.202.camel@localhost.localdomain>
On Thu, 2007-04-26 at 08:19 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2007-04-25 at 16:35 -0300, Luke Browning wrote:
> > This patch fixes a couple of kexec problems related to 64K page
> > support in the kernel. kexec issues a tlbie for each pte. The
> > parameters for the tlbie are the page size and the virtual address.
> > Support was missing for the computation of these two parameters
> > for 64K pages. This patch adds that support.
> >
> > Signed-off-by: Luke Browning <lukebrowning@us.ibm.com>
>
> Quick look: looks good to me. I suppose you verified it works well
> too :-)
yes. but only on cell.
>
> (Have you added some debug to check we get the 16M case right ?)
>
> Note that Milton is against using BUG_ON's in here since that code is
> used for crash dumps.
I would prefer to leave BUG_ON()s in the code as they work in many
cases. It depends on how far you have get in the algorithm. I added
BUG_ON(size == 16M) which is hit after a hundred entries or so have been
processed. See output below. I also put a BUG_ON() at the end of the
table scan but no output was presented so there are limitations, but I
don't believe that there is a downside. The BUG_ON() at the end of the
sequence presented the original symptom so there is no difference from a
user perspective when the algorithm was completely broken. During the
development of this feature, we encountered a lot of false hits though
as the system continued and experienced a bunch of false symptoms. This
is worse as it is better to have the system fail in a deterministic way
than to fail in random way. Some of the failures that we experienced
were dma, timer, and module initialization problems. These were all red
herrings. Having BUG_ONs in the code allows developers to make
assertions about the code which is important when diagnosing strange
system crashes and provides a clue to future developers that they need
to add support for something. Comments are fine, but asserts are better
in that they show up in cscope and other development tools. So all
things considered I think it is better to include them.
Here's the 16M failure I mentioned above.
------------[ cut here ]------------
kernel BUG
at /home/luke/Desktop/code/cell/SDK3.0/Kexec2/linux-2.6.21-rc4/arch/!
cpu 0x0: Vector: 700 (Program Check) at [c000000000527bd0]
pc: c00000000002f648: .native_hpte_clear+0x12c/0x220
lr: c00000000002f568: .native_hpte_clear+0x4c/0x220
sp: c000000000527e50
msr: 9000000000021002
current = 0xc0000000009fe860
paca = 0xc000000000454e80
pid = 1831, comm = sh
kernel BUG
at /home/luke/Desktop/code/cell/SDK3.0/Kexec2/linux-2.6.21-rc4/arch/!
enter ? for help
[c000000000527e50] 0000000000000000 .__start+0x4000000000000000/0x8
(unreliable)
[c000000000527ee0] c0000000000256b4 .kexec_sequence+0x78/0xac
[c000000000527f90] 0000000000000000 .__start+0x4000000000000000/0x8
[c000000001d13830] c00000000002ae00 .default_machine_kexec+0x1ec/0x1f0
[c000000001d138e0] c00000000002a58c .machine_kexec+0x3c/0x54
[c000000001d13950] c0000000000820a8 .crash_kexec+0x130/0x16c
[c000000001d13b30] c0000000001c0cb0 .sysrq_handle_crashdump+0x28/0x40
[c000000001d13bb0] c0000000001c087c .__handle_sysrq+0xe8/0x1c0
[c000000001d13c60] c000000000114dd8 .write_sysrq_trigger+0x7c/0xa8
[c000000001d13cf0] c0000000000c2364 .vfs_write+0xd8/0x1a4
[c000000001d13d90] c0000000000c2d2c .sys_write+0x4c/0x8c
[c000000001d13e30] c000000000008634 syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000000000ff1a8fc
SP (f997f280) is in userspace
> Appart from that,
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Cheers,
> Ben.
>
^ permalink raw reply
* Re: mpc5200 and spi bus
From: Txema Lopez @ 2007-04-26 14:49 UTC (permalink / raw)
To: Asier Llano Palacios; +Cc: linuxppc-embedded
In-Reply-To: <1177595421.9950.4.camel@a.llano.llano>
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
Asier Llano Palacios wrote:
>I've seen some comments about drivers for SPI of the MPC5200. I'm not
>sure about it, but is there anything functional about it?. I want to
>know if there is anything already done, in order to use it or improve
>it. I need a driver of the SPI bus, so if it is not implemented at all
>we should contribute it.
>
>
>
The Denx's 2.4.xx top of tree kernel has MPC5200 SPI support. We are
using the SPI dev interface from a user aplication and it works fine.
[-- Attachment #2: tlopez.vcf --]
[-- Type: text/x-vcard, Size: 324 bytes --]
begin:vcard
fn:Jose Maria Lopez
n:Lopez;Jose Maria
org:Fagor Automation S. Coop.
adr:;;San Andres 19. Apdo. 144;Arrasate-Mondragon;;20500;Spain
email;internet:tlopez@aotek.es
title:Sotware engineer
tel;work:(34) 943719200
tel;fax:(34) 943791712
x-mozilla-html:FALSE
url:http://www.fagorautomation.es
version:2.1
end:vcard
^ permalink raw reply
* Re: [PATCH 7/13] powerpc: Add arch/powerpc mv64x60 MPSC platform data setup
From: Arnd Bergmann @ 2007-04-26 15:14 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070426143001.GC29241@xyzzy.farnsworth.org>
On Thursday 26 April 2007, Dale Farnsworth wrote:
> On Thu, Apr 26, 2007 at 01:24:19PM +0200, Arnd Bergmann wrote:
> > On Thursday 26 April 2007, Dale Farnsworth wrote:
> > > > This looks wrong to me. See drivers/serial/of_serial.c to find how we do it for
> > > > 8250 compatible serial ports. You should probably just add your serial port
> > > > stuff in there as well, instead of doing your own scanning of the device tree.
> > >
> > > Unfortunately, this hardware is very much non-8250 compatible.
> >
> > That shouldn't matter much. The driver is not 8250 specific by itself,
> > it's just that right now it doesn't know about any other chips.
>
> Hmm, I wouldn't call that a driver, I'd call it OF interface
> glue used to register the driver.
I mean driver in the sense that it registers a struct device_driver, not
that it does anything particularly interesting with the hardware
> I guess I could put the
> platform_device_register call for the mpsc driver in that file.
> But I think that will increase, rather than reduce complexity.
Right, I wasn't thinking of that. Instead I meant you should call the
mpsc_drv_probe() function (or some variation of that) directly from
of_platform_serial_probe(), the way that I call serial8250_register_port.
> > > > > +???????????pdev = platform_device_register_simple(MPSC_CTLR_NAME, i, r, 5);
> > > > > +???????????if (IS_ERR(pdev)) {
> > > > > +???????????????????err = PTR_ERR(pdev);
> > > > > +???????????????????goto ret_node_put;
> > > > > +???????????}
>
> Can you coerce your mailer to stop munging tabs?
sorry about that, it always happens when I copy something over from my vim.
> > Ok, I see where some of the limitations come from. However, instead of
> > introducing the new "sdma" and "brg" properties, why not just add the
> > register ranges to the "reg" property, like other drivers do?
>
> The sdma and brg are not simply properties of the serial device, these
> nodes represent hardware modules that may be shared by multiple drivers.
Ok, this looks like a mess that is rather hard to clean up and now might
not be the time to start working on that. If these are shared by multiple
high-level drivers, it sounds like there ought to be a driver for each of
them that also does the necessary locking to serialize register accesses.
Arnd <><
^ permalink raw reply
* Re: [PATCH 9/13] powerpc: Add arch/powerpc mv64x60 I2C platform data setup
From: Arnd Bergmann @ 2007-04-26 15:04 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070426141902.GB29241@xyzzy.farnsworth.org>
On Thursday 26 April 2007, Dale Farnsworth wrote:
>=20
> > The point about the of device tree is that it allows you to probe this
> > kind of device. This means you get automatic module loading based on the
> > device tree, and that the devices show up in sane locations in /sys.
>=20
> I understand the benefits of the DT; that's not the issue.
>
> Here we have platform devices common to MIPS and PowerPC platforms.
> The drivers must continue to support the platform_driver interface
> for MIPS platforms. =A0The question is, where should we put the glue
> that transforms the DT info into the platform_driver format?
>=20
> You seem to suggest putting the ethernet-related glue into
> drivers/net/mv643xx_eth.c. =A0That's bogus, IMHO. The base driver
> shouldn't have to accommodate every arch-specific interface.
> (I know OF isn't strictly arch-specific, but it's far from universal.)
> I put this glue into arch/powerpc/sysdev/mv64x60.c. I still don't see
> the benefit of moving it into the drivers.
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.
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.
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.
I can see multiple ways for you to get there:
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.
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.
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.
Arnd <><
^ permalink raw reply
* Re: [PATCH] Fix interrupt distribution in ppc970
From: Milton Miller @ 2007-04-26 14:42 UTC (permalink / raw)
To: mohan; +Cc: ppcdev, Paul Mackerras, Anton Blanchard, fastboot
In-Reply-To: <20070426092455.GA4144@in.ibm.com>
On Apr 26, 2007, at 4:24 AM, Mohan Kumar M wrote:
> On Fri, Apr 20, 2007 at 12:45:15AM -0500, Milton Miller wrote:
[snip]
> Milton, I hope this patch meets all your requirements.
Closer, much better.
> Cc: Milton Miller <miltonm@bga.com>,
> Michael Ellerman <michael@ellerman.id.au>
> Signed-off-by: Mohan Kumar M <mohan@in.ibm.com>
> ---
> arch/powerpc/platforms/pseries/xics.c | 39
> ++++++++++++++++++++--------------
> 1 file changed, 24 insertions(+), 15 deletions(-)
>
> Index: linux-2.6.21-rc4/arch/powerpc/platforms/pseries/xics.c
> ===================================================================
> --- linux-2.6.21-rc4.orig/arch/powerpc/platforms/pseries/xics.c
> +++ linux-2.6.21-rc4/arch/powerpc/platforms/pseries/xics.c
> @@ -156,9 +156,9 @@ static inline void lpar_qirr_info(int n_
[snipping]
> + if (!cpus_equal(cpumask, CPU_MASK_ALL)) {
> cpus_and(tmp, cpu_online_map, cpumask);
>
> + server = first_cpu(tmp);
> +
> + if (server < NR_CPUS)
> + return get_hard_smp_processor_id(server);
> + else {
> + if(strict_check)
> + return (-1);
No parens around the return value. That is, use return -1;
> + else
> + return default_distrib_server;
> + }
...
> @@ -415,7 +421,10 @@ static void xics_set_affinity(unsigned i
>
> /* For the moment only implement delivery to all cpus or one cpu */
> if (cpus_equal(cpumask, CPU_MASK_ALL)) {
> - newmask = default_distrib_server;
> + if (cpus_equal(cpu_online_map, cpu_present_map))
> + newmask = default_distrib_server;
> + else
> + newmask = default_server;
> } else {
> cpus_and(tmp, cpu_online_map, cpumask);
> if (cpus_empty(tmp))
>
>
> ===================
>> ...
>>> @@ -415,7 +419,10 @@ static void xics_set_affinity(unsigned i
>> ...
>>> /* For the moment only implement delivery to all cpus or one cpu */
>>> if (cpus_equal(cpumask, CPU_MASK_ALL)) {
>>> - newmask = default_distrib_server;
>>> + if (cpus_equal(cpu_online_map, cpu_present_map))
>>>
>>
>> this was supposed to be the call with strict = 1
>
> Do you mean to use 'strict_check' argument in xics_set_affinity?
> set_affinity call is declared in linux/irq.h, so if modifying
> xics_set_affinity will affect other arch's set_affinity also.
Yes. The whole point of
> -static int get_irq_server(unsigned int virq)
> +static int get_irq_server(unsigned int virq, unsigned int
> strict_check)
was to factor out the common code in this function.
I wasn't trying to change the prototype of xics_set_affinity.
Looking at the code a bit, I think part of the confusion is that newmask
is horribly misnamed. Please rename it to server or irqserver.
Obtain its value by calling get_irq_server. If the server returned
is -1 (in strict mode), don't call rtas (just return like today).
I guess a printk could be in order since the function is void, and
only root can request the change.
milton
^ permalink raw reply
* Re: [PATCH 10/13] powerpc: Add arch/powerpc mv64x60 PCI setup
From: Dale Farnsworth @ 2007-04-26 14:42 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <200704261339.18640.arnd@arndb.de>
On Thu, Apr 26, 2007 at 01:39:18PM +0200, Arnd Bergmann wrote:
> On Thursday 26 April 2007, Dale Farnsworth wrote:
> > > /* The probing of PCI controllers from of_platform is currently
> > > ?* 64 bits only, mostly due to gratuitous differences between
> > > ?* the 32 and 64 bits PCI code on PowerPC and the 32 bits one
> > > ?* lacking some bits needed here.
> > > ?*/
> >
> > Is this comment incorrect?
> >
> > I agree that this is more code duplication than I like, and we could
> > benefit from some refactoring. ?However, I find 15 other places in
> > arch/powerpc that largely duplicate this pci initialization code.
> > That doesn't make a 16th right, but at least I'm in good company.
>
> Yes, you're right. I was assuming that the code had been ported to
> 32 bit already, which was incorrect.
>
> While I would very much like you (or someone else) to make it work,
> it should not be a prerequisite to get your code merged in 2.6.22.
>
> The one remaining comment I have about this one is that IMHO it
> should be a separate file, mv64x60-pci.c instead of being
> in the same file as the interrupt controller and other code.
Ah, the debate continues. I remember 4 or 5 years ago there was
campaign to consolidate the xxxx-pci.c files into the core support
files. I have no strong preference. More opinions are welcome.
Thanks,
-Dale
^ 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