* Re: [PATCH] 86xx: Enable the AC97 interface on 8641D board.
From: Olof Johansson @ 2007-05-03 17:26 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1178209046.17201.55.camel@ld0161-tx32>
On Thu, May 03, 2007 at 11:17:26AM -0500, Jon Loeliger wrote:
> On Thu, 2007-05-03 at 11:10, Olof Johansson wrote:
>
> >
> > This sounds like something that firmware should take care of, not
> > hardcoded in the board code. Seems like the device is just a PCI device
> > that doesn't have a device tree entry.
>
> Well, it's not a PCI device at all.
Really? You use a PCI quirk to manipulate it.
> > Why not do this in u-boot instead?
>
> Why do it there? We'd have to do it _again_ in Linux
> if we didn't come in from U-Boot anyway.
The same argument could be used to motivate not doing any kind of board
inits in any firmware and do it all from the board code in linux.
Don't you guys use M1575 on other eval boards too, so you'll need the
same board quirk duplicated?
-Olof
^ permalink raw reply
* Re: [PATCH] Xilinx framebuffer device driver - 3d version
From: Andrei Konovalov @ 2007-05-03 17:29 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Arnd Bergmann
In-Reply-To: <463A1B58.8000804@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 648 bytes --]
Hello,
Andrei Konovalov wrote:
> 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>
>
> -----
> The driver has been tested with Xilinx ML300 and ML403 reference designs.
>
> The two first version has been posted to linuxppc-embedded, and this
> version tries to address all the comments and criticism received.
>
> The platform device registration for Xilinx ML300 and ML403
> moved into separate patch (will be posted to linuxppc-embedded
> in couple minutes).
Here is the platform device registration part.
Thanks,
Andrei
[-- Attachment #2: ppc32-enable-xilinx_fb.patch --]
[-- Type: text/x-patch, Size: 2684 bytes --]
Index: linux-2.6.20/arch/ppc/platforms/4xx/xilinx_ml403.c
===================================================================
--- linux-2.6.20.orig/arch/ppc/platforms/4xx/xilinx_ml403.c
+++ linux-2.6.20/arch/ppc/platforms/4xx/xilinx_ml403.c
@@ -118,3 +118,20 @@ platform_init(unsigned long r3, unsigned
#endif
}
+static struct xilinxfb_platform_data xilinxfb_ml403_pdata = {
+ .rotate_screen = 0,
+ .screen_height_mm = -1,
+ .screen_width_mm = -1,
+};
+
+int __init virtex_device_fixup(struct platform_device *dev)
+{
+ if (strcmp(dev->name, "xilinxfb") == 0) {
+ if (dev->id != 0) /* paranoic */
+ return 1;
+ dev->dev.platform_data = &xilinxfb_ml403_pdata;
+ return 0;
+ }
+ return 0;
+}
+
Index: linux-2.6.20/arch/ppc/platforms/4xx/xilinx_ml300.c
===================================================================
--- linux-2.6.20.orig/arch/ppc/platforms/4xx/xilinx_ml300.c
+++ linux-2.6.20/arch/ppc/platforms/4xx/xilinx_ml300.c
@@ -116,3 +116,20 @@ platform_init(unsigned long r3, unsigned
#endif
}
+static struct xilinxfb_platform_data xilinxfb_ml300_pdata = {
+ .rotate_screen = 1,
+ .screen_height_mm = 99,
+ .screen_width_mm = 132,
+};
+
+int __init virtex_device_fixup(struct platform_device *dev)
+{
+ if (strcmp(dev->name, "xilinxfb") == 0) {
+ if (dev->id != 0) /* paranoic */
+ return 1;
+ dev->dev.platform_data = &xilinxfb_ml300_pdata;
+ return 0;
+ }
+ return 0;
+}
+
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
@@ -71,7 +71,23 @@
}, \
}
+/*
+ * ML300/ML403 Video Device: shortcut macro for single instance
+ */
+#define XPAR_TFT(num) { \
+ .name = "xilinxfb", \
+ .id = num, \
+ .num_resources = 1, \
+ .resource = (struct resource[]) { \
+ { \
+ .start = XPAR_TFT_##num##_BASEADDR, \
+ .end = XPAR_TFT_##num##_BASEADDR+7, \
+ .flags = IORESOURCE_IO, \
+ }, \
+ }, \
+}
+
/* UART 8250 driver platform data table */
struct plat_serial8250_port virtex_serial_platform_data[] = {
#if defined(XPAR_UARTNS550_0_BASEADDR)
@@ -146,20 +162,12 @@ struct platform_device virtex_platform_d
XPAR_SYSACE(1),
#endif
- /* ML300/403 reference design framebuffer */
+ /* ML300/ML403 reference design framebuffer */
#if defined(XPAR_TFT_0_BASEADDR)
- {
- .name = "xilinxfb",
- .id = 0,
- .num_resources = 1,
- .resource = (struct resource[]) {
- {
- .start = XPAR_TFT_0_BASEADDR,
- .end = XPAR_TFT_0_BASEADDR+7,
- .flags = IORESOURCE_IO,
- },
- },
- },
+ XPAR_TFT(0),
+#endif
+#if defined(XPAR_TFT_1_BASEADDR)
+ XPAR_TFT(1),
#endif
};
^ permalink raw reply
* [PATCH] Xilinx framebuffer device driver - 3d version
From: Andrei Konovalov @ 2007-05-03 17:26 UTC (permalink / raw)
To: linuxppc-embedded, linux-fbdev-devel
[-- Attachment #1: Type: text/plain, Size: 637 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>
-----
The driver has been tested with Xilinx ML300 and ML403 reference designs.
The two first version has been posted to linuxppc-embedded, and this
version tries to address all the comments and criticism received.
The platform device registration for Xilinx ML300 and ML403
moved into separate patch (will be posted to linuxppc-embedded
in couple minutes).
Would be nice to get this driver into mainline for the 2.6.22.
Reviews and comments are welcome.
Thanks,
Andrei
[-- Attachment #2: xilinx_fb.patch --]
[-- Type: text/x-patch, Size: 12956 bytes --]
Add support for the video controller IP block included into Xilinx ML300 and
ML403 reference designs.
arch/ppc/syslib/virtex_devices.h | 7
drivers/video/Kconfig | 11 +
drivers/video/Makefile | 1
drivers/video/xilinxfb.c | 389 +++++++++++++++++++++++++++++++++++++++
4 files changed, 408 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,17 @@ 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_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,389 @@
+/*
+ * 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"
+
+/*
+ * Xilinx calls it "PLB TFT LCD Controller" though it can also be used for
+ * the VGA port on the Xilinx ML40x board. This is a hardware display controller
+ * for a 640x480 resolution TFT or VGA screen.
+ *
+ * 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
+
+/*
+ * 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 RED_SHIFT 16
+#define GREEN_SHIFT 8
+#define BLUE_SHIFT 0
+
+#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 = { RED_SHIFT, 8, 0 },
+ .green = { GREEN_SHIFT, 8, 0 },
+ .blue = { BLUE_SHIFT, 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 */
+
+ unsigned char __iomem *fb_virt; /* virt. address of the frame buffer */
+ dma_addr_t fb_phys; /* phys. address of the frame buffer */
+
+ u32 reg_ctrl_default;
+
+ u32 pseudo_palette[PALETTE_ENTRIES_NO];
+ /* Fake palette of 16 colors */
+};
+
+#define to_xilinxfb_drvdata(_info) \
+ container_of(_info, struct xilinxfb_drvdata, info)
+
+/*
+ * The LCD controller has DCR interface to its registers, but all
+ * the boards and configurations the driver has been tested with
+ * use opb2dcr bridge. So the registers are seen as memory mapped.
+ * This macro is to make it simple to add the direct DCR access
+ * when it's needed.
+ */
+#define xilinx_fb_out_be32(driverdata, offset, val) \
+ 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 << RED_SHIFT) | (green << GREEN_SHIFT) |
+ (blue << BLUE_SHIFT);
+
+ 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, drvdata->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;
+ }
+
+ 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 */
+ if (pdata->rotate_screen) {
+ drvdata->reg_ctrl_default = REG_CTRL_ENABLE | REG_CTRL_ROTATE;
+ } else {
+ drvdata->reg_ctrl_default = REG_CTRL_ENABLE;
+ }
+ xilinx_fb_out_be32(drvdata, REG_CTRL, drvdata->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);
+ 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);
+ 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.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 rotate_screen;
+ 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: powerpc_flash_init(), wtf!?
From: Sergei Shtylyov @ 2007-05-03 17:17 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <71e4c68de5240a652b561d8cfa2e05f3@kernel.crashing.org>
Hello.
Segher Boessenkool wrote:
>>>> We weren't aware of the of_platform.c work when writing the MTD
>>>> support.
>>>> Note that this function usually probes only the specified set of
>>>> (SoC)
>>>> busses, none of which usully contains NOR flash (which is located at
>>>> the
>>>> root level).
>>> The root level? Um... I don't think so...
>> "Trust me". :-)
>> NOR flashes are at the same level as the "memory" node (where else
>> you
>> expect them to appear I wonder?).
> The "memory" node doesn't describe the RAM devices;
> it describes the RAM address space, instead. You can
> have separate nodes for the actual devices.
If you can remember our prior discussion, the "rom" nodes don't describe
"the actual devices" as well, only their mapping into the address space. ;-)
> Now for ROM/flash/NVRAM, nodes _can_ appear directly
> under the root, but only if that is where they belong
> on your platform (i.e., they sit directly on the "system
> bus" (whatever that means on your platform); on most
> platforms though, such devices are connected via some
> I/O busses, so the nodes should appear under their
> respective controllers.
Yeah, you're right here, and I've probably misunderstood what "memory"
node was. In fact, the flash in my system resides on the same local bus as
RAM, so the proper place would be behind the "lbc" (or whatever -- it doesn't
exist as yet) node on the "soc" bus. Do you think I need to go and document
it as well for such cause? :-]
>>> I believe the arrangement is similar for most other 4xx systems. More
>>> PC or desktop like systems sometimes have boot flash connected to the
>>> south bridge, which I believe puts it on the ISA bus, topologically
>>> speaking.
> Some have it on the LPC bus as an LPC device, some
> have it on the LPC bus but accessed with a separate
> protocol, some have it attached to another LPC device
> (some "superio" typically), some have it attached
> directly to the "south bridge".
>> Not exactly. Boot flash is mapped beyond ISA address space on 386+
>> -- at
>> the top of 4GB (where the "reset vector" is). Although it may be dual
>> mapped
>> below 1MB as well (I'm starting to forget x86 :-).
> Most "north bridges" have some bits that enable
> translation of accesses in the "low bios" area to
> the 4GB-minus-a-bit area. There are many variations
> and it all is a big mess :-)
Human perversion knows no limits. O:-)
> Now, back to the case at hand -- it would be nice to
> have a platform-independent way to probe the simple
> case -- a single direct-mapped device -- but it isn't
> obvious how to make that not clash with the not-so-simple
> cases. A helper function that does the work but is
> only called by the platforms that want it would do, I
> suppose?
It probably doesn't even worth a helper (since out of those 15 lines, 6
were pretty useless anyway)
> Segher
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] Remove CPU_FTR_NEED_COHERENT for 7448.
From: Adrian Cox @ 2007-05-03 17:07 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1178208838.17201.52.camel@ld0161-tx32>
On Thu, 2007-05-03 at 11:13 -0500, Jon Loeliger wrote:
> > The problem is that many 32-bit PowerPC machines needed
> > CPU_FTR_NEED_COHERENT set for a second reason: compatibility with the
> > cache in the MPC107. This was handled by CPU_FTR_COMMON in cputable.h
> > before the L2 prefetch bug was known. There may be other host bridges
> > that cache, but nobody will have noticed because all the CPUs had
> > CPU_FTR_NEED_COHERENT set already.
> Yes, you are correct and your concern is valid. However,
> this case is still being handled by CONFIG_MPC10X_BRIDGE
> to deal with the MPC106/MPC107/etc north bridges.
My only concern here is that some other Northbridges may have a similar
cache issue to the MPC107, but that we haven't noticed because the
cputable entry has been a crutch for them. If we remove the entry, will
some other 7448 designs quietly stop working? I think the Tsi108/109
are probably safe, but I don't know about other bridges.
> The CPU doesn't impose this requirement, the north bridge does.
> It might even better be named something like
> CPU_FTR_NORTHBRDIGE_NEEDS_COHERENT.
Yes - we end up turning on coherency for multiple reasons - SMP, the L2
prefetch bug, or the cache in the MPC107. I quite like Ben H's idea of
doing this in machine_probe().
--
Adrian Cox <adrian@humboldt.co.uk>
^ permalink raw reply
* Re: powerpc_flash_init(), wtf!?
From: Sergei Shtylyov @ 2007-05-03 16:59 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <a8625bde363025ce23393d5b2bb6ec07@kernel.crashing.org>
Hello.
Segher Boessenkool wrote:
>> BTW, is it legal/appropriate to specify device (not bus) types for
>> of_platform_bus_probe()?
> In almost all cases you should probe on "name"/"compatible",
Probing on name is not a good idea, since those are mostly generic.
> and not use "device_type" at all.
Heh, SPARC device trees I saw seem to not have this "useless" prop at all. :-)
> Segher
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] powermac: support G5 CPU hotplug
From: Segher Boessenkool @ 2007-05-03 16:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Johannes Berg, Paul Mackerras
In-Reply-To: <1178158307.17299.55.camel@localhost.localdomain>
>> Isn't it just a GPIO, like on older Macs? Of course, we
>> cannot bring a CPU back online after doing that so it's
>> pretty useless I suppose.
>
> We don't know for sure what the gpio does... wether it does a CPU soft
> reset or tickles the SPU to make it do special things that cause us to
> branch at 0x100. We do get the CPU back after that though. We use that
> to bring them in after boot.
Yeah. It's probably the SRESET pin, come to think of it.
It doesn't seem logical that this would save more power
than (deep) NAP mode, so forget the whole idea. Or
someone could measure it if they think it might help
still.
Segher
^ permalink raw reply
* Re: [PATCH v2] gianfar: Add I/O barriers when touching buffer descriptor ownership.
From: Segher Boessenkool @ 2007-05-03 16:38 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <463A0732.2060802@freescale.com>
>> So what about some thing like this where we do the read only once?
>>
>> - k
>>
>> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
>> index a06d8d1..9cd7d1e 100644
>> --- a/drivers/net/gianfar.c
>> +++ b/drivers/net/gianfar.c
>> @@ -1438,31 +1438,35 @@ int gfar_clean_rx_ring(struct net_device
>> *dev, int rx_work_limit)
>> {
>> struct rxbd8 *bdp;
>> struct sk_buff *skb;
>> - u16 pkt_len;
>> + u16 pkt_len, status;
>> + u32 bd_info;
>
>
> I suggested that on IRC yesterday, and Segher was concerned that the
> compiler might, in theory, "optimize" it into to two lhz instructions.
Yes. The same is true of the original code btw, but since
you test only one bit there, all is fine.
> I'm rather skeptical that it would actually do so (even if it needs to
> load twice due to register pressure, why not just use lwz both times?),
Sure. That doesn't make this code correct though.
> and there's probably many other places that would break if it did,
Most other network drivers read from an MMIO reg to see
which RX ring entries are kernel owned AFAICS.
> but I wasn't up for digging around GCC to prove otherwise.
It doesn't matter what current GCC does -- simply look
at what it is *allowed* to do instead.
If you want a 32-bit read to be atomic, you should
do the read via a (volatile u32 *). Doing this with
a cast in the places where you need the atomic access
makes sure you don't get unnecessary rereads.
> Plus, that wouldn't synchronize the bd_info read with the buffer data
> reads.
Yes, you still need the rmb().
Segher
^ permalink raw reply
* MPC832xEMDS: ttyS0 output stops mid boot
From: Alex Zeffertt @ 2007-05-03 16:39 UTC (permalink / raw)
To: linuxppc-embedded, u-boot-users, Alex Zeffertt
Hi,
Sorry about the cross posting, but I'm not sure which list I should send to....
I'm trying to boot an up-to-date kernel on my MPC8323E-MDS-PB board, but I the
console output stops early on during the kernel boot.
I'm running the latest u-boot (git://www.denx.de/git/u-boot-mpc83xx.git) with
its default environment. The kernel is built from Paulus' powerpc.git, after
checking out tag 2.6.21-rc5. The dtb is build from
arch/powerpc/boot/dts/mpc832x_mds.dts
with the latest compiler (git://www.jdl.com/software/dtc.git).
Has anyone else been here before...? If so I'd appreciate any help you can
offer.
TIA,
Alex
-------------------my ttyS0 output------------------
=>
=> printenv
bootcmd=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath
ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off
console=$consoledev,$baudrate $othbootargs;tftp $loadaddr
$bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr
ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate
$othbootargs;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr
$bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr
nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath
ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off
console=$consoledev,$baudrate $othbootargs;tftp $loadaddr
$bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr
bootdelay=6
baudrate=115200
loads_echo=1
ethaddr=00:04:9f:ef:03:01
eth1addr=00:04:9f:ef:03:02
loadaddr=200000
netdev=eth0
consoledev=ttyS0
ramdiskaddr=1000000
ramdiskfile=ramfs.83xx
fdtaddr=400000
fdtfile=mpc832xemds.dtb
stdin=serial
stdout=serial
stderr=serial
ethact=FSL UEC0
Environment size: 979/8188 bytes
=> setenv ramdiskfile uRamdisk
=> setenv fdtfile mpc832x_mds.dtb
=> setenv bootfile uImage
=> setenv serverip 10.0.0.107
=> setenv ipaddr 10.0.6.65
=> run ramboot
Using FSL UEC0 device
TFTP from server 10.0.0.107; our IP address is 10.0.6.65
Filename 'uRamdisk'.
Load address: 0x1000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
###########################################################
done
Bytes transferred = 3296770 (324e02 hex)
Using FSL UEC0 device
TFTP from server 10.0.0.107; our IP address is 10.0.6.65
Filename 'uImage'.
Load address: 0x200000
Loading: #################################################################
#################################################################
#################################################################
##########################################
done
Bytes transferred = 1212615 (1280c7 hex)
Using FSL UEC0 device
TFTP from server 10.0.0.107; our IP address is 10.0.6.65
Filename 'mpc832x_mds.dtb'.
Load address: 0x400000
Loading: ###
done
Bytes transferred = 12288 (3000 hex)
## Booting image at 00200000 ...
Image Name: Linux-2.6.21-rc5
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1212551 Bytes = 1.2 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 01000000 ...
Image Name: uboot ext2 ramdisk rootfs
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 3296706 Bytes = 3.1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Booting using flat device tree at 0x400000
Loading Ramdisk to 07c87000, end 07fabdc2 ... OK
Using MPC832x MDS machine description
Linux version 2.6.21-rc5 (ajz@zambia) (gcc version 3.4.3) #2 Thu May 3
16:42:54 BST 2007
Found initrd at 0xc7c87000:0xc7fabdc2
setup_arch: bootmem
mpc832x_sys_setup_arch()
Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bus number: 0->0
arch: exit
Zone PFN ranges:
DMA 0 -> 32768
Normal 32768 -> 32768
early_node_map[1] active PFN ranges
0: 0 -> 32768
Built 1 zonelists. Total pages: 32512
Kernel command line: root=/dev/ram rw console=ttyS0,115200
IPIC (128 IRQ sources) at fddf3700
QEIC (64 IRQ sources) at fddf2080
PID hash table entries: 512 (order: 9, 2048 bytes)
^ permalink raw reply
* Re: [U-Boot-Users] Where do you find *.dtb files?
From: Jon Loeliger @ 2007-05-03 16:24 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: Jerry Van Baren, linuxppc-embedded@ozlabs.org
In-Reply-To: <4639E9BF.40902@cambridgebroadband.com>
On Thu, 2007-05-03 at 08:55, Alex Zeffertt wrote:
> ... but when I try to compile it I get an error:
>
> $ /opt/freescale/ltib/usr/bin/dtc -I dts -O dtb powerpc/arch/powerpc/boot/dts/mpc832x_mds.dts
> DTC: dts->dtb on file "powerpc/arch/powerpc/boot/dts/mpc832x_mds.dts"
> syntax error at line 14
> FATAL ERROR: Couldn't read input tree
>
> Perhaps my dtc is out of date - it came with the BSP from freescale which uses
> the 2.6.11 kernel.
>
> Do you know where I can find an up to date dtc? Is there any documentation regarding its use?
Read:
linux-2.6/Documentation/powerpc/booting-without-of.txt
Get current DTC from:
www.jdl.com/git_repos
HTH,
jdl
^ permalink raw reply
* Re: powerpc_flash_init(), wtf!?
From: Segher Boessenkool @ 2007-05-03 16:21 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <4639E389.4040604@ru.mvista.com>
> BTW, is it legal/appropriate to specify device (not bus) types for
> of_platform_bus_probe()?
In almost all cases you should probe on "name"/"compatible",
and not use "device_type" at all.
Segher
^ permalink raw reply
* Re: powerpc_flash_init(), wtf!?
From: Segher Boessenkool @ 2007-05-03 16:20 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <4639DDE1.40904@ru.mvista.com>
>>> We weren't aware of the of_platform.c work when writing the MTD
>>> support.
>>> Note that this function usually probes only the specified set of
>>> (SoC)
>>> busses, none of which usully contains NOR flash (which is located at
>>> the
>>> root level).
>
>> The root level? Um... I don't think so...
>
> "Trust me". :-)
> NOR flashes are at the same level as the "memory" node (where else
> you
> expect them to appear I wonder?).
The "memory" node doesn't describe the RAM devices;
it describes the RAM address space, instead. You can
have separate nodes for the actual devices.
Now for ROM/flash/NVRAM, nodes _can_ appear directly
under the root, but only if that is where they belong
on your platform (i.e., they sit directly on the "system
bus" (whatever that means on your platform); on most
platforms though, such devices are connected via some
I/O busses, so the nodes should appear under their
respective controllers.
>> I believe the arrangement is similar for most other 4xx systems. More
>> PC or desktop like systems sometimes have boot flash connected to the
>> south bridge, which I believe puts it on the ISA bus, topologically
>> speaking.
Some have it on the LPC bus as an LPC device, some
have it on the LPC bus but accessed with a separate
protocol, some have it attached to another LPC device
(some "superio" typically), some have it attached
directly to the "south bridge".
> Not exactly. Boot flash is mapped beyond ISA address space on 386+
> -- at
> the top of 4GB (where the "reset vector" is). Although it may be dual
> mapped
> below 1MB as well (I'm starting to forget x86 :-).
Most "north bridges" have some bits that enable
translation of accesses in the "low bios" area to
the 4GB-minus-a-bit area. There are many variations
and it all is a big mess :-)
Now, back to the case at hand -- it would be nice to
have a platform-independent way to probe the simple
case -- a single direct-mapped device -- but it isn't
obvious how to make that not clash with the not-so-simple
cases. A helper function that does the work but is
only called by the platforms that want it would do, I
suppose?
Segher
^ permalink raw reply
* Re: [PATCH] 86xx: Enable the AC97 interface on 8641D board.
From: Kumar Gala @ 2007-05-03 16:19 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Olof Johansson, linuxppc-dev@ozlabs.org
In-Reply-To: <1178209046.17201.55.camel@ld0161-tx32>
On May 3, 2007, at 11:17 AM, Jon Loeliger wrote:
> On Thu, 2007-05-03 at 11:10, Olof Johansson wrote:
>
>>
>> This sounds like something that firmware should take care of, not
>> hardcoded in the board code. Seems like the device is just a PCI
>> device
>> that doesn't have a device tree entry.
>
> Well, it's not a PCI device at all.
>
>> Why not do this in u-boot instead?
>
> Why do it there? We'd have to do it _again_ in Linux
> if we didn't come in from U-Boot anyway.
I agree with Jon here. This is in board specific code so I don't see
any issue with it.
- k
^ permalink raw reply
* Re: [PATCH] 86xx: Enable the AC97 interface on 8641D board.
From: Jon Loeliger @ 2007-05-03 16:17 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20070503161000.GA31881@lixom.net>
On Thu, 2007-05-03 at 11:10, Olof Johansson wrote:
>
> This sounds like something that firmware should take care of, not
> hardcoded in the board code. Seems like the device is just a PCI device
> that doesn't have a device tree entry.
Well, it's not a PCI device at all.
> Why not do this in u-boot instead?
Why do it there? We'd have to do it _again_ in Linux
if we didn't come in from U-Boot anyway.
jdl
^ permalink raw reply
* Re: [PATCH] Remove CPU_FTR_NEED_COHERENT for 7448.
From: Jon Loeliger @ 2007-05-03 16:13 UTC (permalink / raw)
To: Adrian Cox; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1178187440.20944.12.camel@localhost.localdomain>
On Thu, 2007-05-03 at 05:17, Adrian Cox wrote:
> On Wed, 2007-05-02 at 16:34 -0500, Jon Loeliger wrote:
> > From: James.Yang <James.Yang@freescale.com>
> >
> > Remove CPU_FTR_NEED_COHERENT for MPC7448 (and single-core MPC86xx).
> > This prevents needlessly setting M=1 when not SMP.
>
> There may be side effects to removing this. Most of the 74xx processors
> had this flag added because of the L2 prefetch bug (erratum #16 on the
> 7447A). I see that bug is missing from the 7448 errata.
>
> The problem is that many 32-bit PowerPC machines needed
> CPU_FTR_NEED_COHERENT set for a second reason: compatibility with the
> cache in the MPC107. This was handled by CPU_FTR_COMMON in cputable.h
> before the L2 prefetch bug was known. There may be other host bridges
> that cache, but nobody will have noticed because all the CPUs had
> CPU_FTR_NEED_COHERENT set already.
Adrian,
Yes, you are correct and your concern is valid. However,
this case is still being handled by CONFIG_MPC10X_BRIDGE
to deal with the MPC106/MPC107/etc north bridges.
Here:
include/asm-powerpc/cputable.h:183
/* We need to mark all pages as being coherent if we're SMP or we
* have a 74[45]x and an MPC107 host bridge. Also 83xx requires
* it for PCI "streaming/prefetch" to work properly.
*/
#if defined(CONFIG_SMP) || defined(CONFIG_MPC10X_BRIDGE) \
|| defined(CONFIG_PPC_83xx)
#define CPU_FTR_COMMON CPU_FTR_NEED_COHERENT
#else
#define CPU_FTR_COMMON 0
#endif
The CPU doesn't impose this requirement, the north bridge does.
It might even better be named something like
CPU_FTR_NORTHBRDIGE_NEEDS_COHERENT.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] 86xx: Enable the AC97 interface on 8641D board.
From: Olof Johansson @ 2007-05-03 16:10 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1178207725.17201.33.camel@ld0161-tx32>
On Thu, May 03, 2007 at 10:55:25AM -0500, Jon Loeliger wrote:
> On Thu, 2007-05-03 at 09:44, Kumar Gala wrote:
> > On May 2, 2007, at 4:53 PM, Jon Loeliger wrote:
> >
> > > From: Jason Jin <jason.jin@freescale.com>
> > >
> > > HD interface and AC97 interface share some pins and they are
> > > enabled at
> > > the same time, In order to use AC97 interface, we need to disable
> > > the HD
> > > interface first.
> > >
> > > Signed-off-by:Jason Jin<jason.jin@freescale.com>
> > > Acked-by: Jon Loeliger <jdl@freescale.com>
> > > ---
> > > arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 7 ++++++-
> > > 1 files changed, 6 insertions(+), 1 deletions(-)
> >
> > Is the HD feature not used at all? Is there a AC97 Driver CONFIG_
> > that makes sense to wrap that with? Just wondering about the mutual
> > exclusion (and how to provide flexibility to the user).
> >
> > - k
>
>
> The ULI supports both the HD and AC97 interfaces, but the 8641
> only supports the AC97 interface. Thus we can straight disable
> the HD and convert/configure the shared pins to be AC97. Thus,
> there is no real CONFIG_ need at all. It's only AC97. And then
> ultimately, the presence of sound support is controlled by
> the ALSA config options as per normal.
This sounds like something that firmware should take care of, not
hardcoded in the board code. Seems like the device is just a PCI device
that doesn't have a device tree entry.
Why not do this in u-boot instead?
-Olof
^ permalink raw reply
* Re: [PATCH] Remove CPU_FTR_NEED_COHERENT for 7448.
From: Jon Loeliger @ 2007-05-03 16:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <17977.49450.564147.751969@cargo.ozlabs.ibm.com>
On Thu, 2007-05-03 at 06:02, Paul Mackerras wrote:
> Do you have any benchmark results showing a real performance
> improvement from these?
>
> Paul.
Yes. We have the data to back this claim up.
jdl
^ permalink raw reply
* Re: [PATCH] 86xx: Enable the AC97 interface on 8641D board.
From: Jon Loeliger @ 2007-05-03 16:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <10979137-FCDB-40D4-98F4-45CC00AE3358@kernel.crashing.org>
On Thu, 2007-05-03 at 11:01, Kumar Gala wrote:
> Ok. I'm guessing HD here isn't hard disk, but some audio thing.
That is correct.
jdl
^ permalink raw reply
* Re: [PATCH] 86xx: Enable the AC97 interface on 8641D board.
From: Kumar Gala @ 2007-05-03 16:01 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1178207725.17201.33.camel@ld0161-tx32>
On May 3, 2007, at 10:55 AM, Jon Loeliger wrote:
> On Thu, 2007-05-03 at 09:44, Kumar Gala wrote:
>> On May 2, 2007, at 4:53 PM, Jon Loeliger wrote:
>>
>>> From: Jason Jin <jason.jin@freescale.com>
>>>
>>> HD interface and AC97 interface share some pins and they are
>>> enabled at
>>> the same time, In order to use AC97 interface, we need to disable
>>> the HD
>>> interface first.
>>>
>>> Signed-off-by:Jason Jin<jason.jin@freescale.com>
>>> Acked-by: Jon Loeliger <jdl@freescale.com>
>>> ---
>>> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 7 ++++++-
>>> 1 files changed, 6 insertions(+), 1 deletions(-)
>>
>> Is the HD feature not used at all? Is there a AC97 Driver CONFIG_
>> that makes sense to wrap that with? Just wondering about the mutual
>> exclusion (and how to provide flexibility to the user).
>>
>> - k
>
>
> The ULI supports both the HD and AC97 interfaces, but the 8641
> only supports the AC97 interface. Thus we can straight disable
> the HD and convert/configure the shared pins to be AC97. Thus,
> there is no real CONFIG_ need at all. It's only AC97. And then
> ultimately, the presence of sound support is controlled by
> the ALSA config options as per normal.
Ok. I'm guessing HD here isn't hard disk, but some audio thing.
- k
^ permalink raw reply
* Re: [PATCH v2] gianfar: Add I/O barriers when touching buffer descriptor ownership.
From: Scott Wood @ 2007-05-03 16:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0705022109350.1690@localhost.localdomain>
Kumar Gala wrote:
> So what about some thing like this where we do the read only once?
>
> - k
>
> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
> index a06d8d1..9cd7d1e 100644
> --- a/drivers/net/gianfar.c
> +++ b/drivers/net/gianfar.c
> @@ -1438,31 +1438,35 @@ int gfar_clean_rx_ring(struct net_device *dev, int rx_work_limit)
> {
> struct rxbd8 *bdp;
> struct sk_buff *skb;
> - u16 pkt_len;
> + u16 pkt_len, status;
> + u32 bd_info;
I suggested that on IRC yesterday, and Segher was concerned that the
compiler might, in theory, "optimize" it into to two lhz instructions.
I'm rather skeptical that it would actually do so (even if it needs to
load twice due to register pressure, why not just use lwz both times?),
and there's probably many other places that would break if it did, but I
wasn't up for digging around GCC to prove otherwise.
Plus, that wouldn't synchronize the bd_info read with the buffer data reads.
-Scott
^ permalink raw reply
* Re: [PATCH] 86xx: Enable the AC97 interface on 8641D board.
From: Jon Loeliger @ 2007-05-03 15:55 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <08D3A1CE-12E0-4759-B055-DE227EA4135E@kernel.crashing.org>
On Thu, 2007-05-03 at 09:44, Kumar Gala wrote:
> On May 2, 2007, at 4:53 PM, Jon Loeliger wrote:
>
> > From: Jason Jin <jason.jin@freescale.com>
> >
> > HD interface and AC97 interface share some pins and they are
> > enabled at
> > the same time, In order to use AC97 interface, we need to disable
> > the HD
> > interface first.
> >
> > Signed-off-by:Jason Jin<jason.jin@freescale.com>
> > Acked-by: Jon Loeliger <jdl@freescale.com>
> > ---
> > arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 7 ++++++-
> > 1 files changed, 6 insertions(+), 1 deletions(-)
>
> Is the HD feature not used at all? Is there a AC97 Driver CONFIG_
> that makes sense to wrap that with? Just wondering about the mutual
> exclusion (and how to provide flexibility to the user).
>
> - k
The ULI supports both the HD and AC97 interfaces, but the 8641
only supports the AC97 interface. Thus we can straight disable
the HD and convert/configure the shared pins to be AC97. Thus,
there is no real CONFIG_ need at all. It's only AC97. And then
ultimately, the presence of sound support is controlled by
the ALSA config options as per normal.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] [POWERPC] 8xx: mpc885ads pcmcia support
From: Segher Boessenkool @ 2007-05-03 15:43 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, linux-pcmcia, linux-kernel
In-Reply-To: <200705030948.03984.arnd@arndb.de>
>> + pcmcia@0080 {
>> + compatible = "8xx";
> The compatible property should be a little more specific, imho. Since
> there
> are differences in how things are done depending on the board, it
> would be
> good to tell the exact method from the pcmcia node itself.
Just "8xx" isn't good enough -- at a very minimum it
needs to say this is a PCMCIA controller!
> For example, you could make this
>
> compatible = "8xx\0mpc885ads";
"mpc885ads-pcmcia\0mpc8xx-pcmcia" or something like that.
Segher
^ permalink raw reply
* Re: [PATCH] Fix interrupt distribution in ppc970
From: Mohan Kumar M @ 2007-05-03 14:47 UTC (permalink / raw)
To: Milton Miller; +Cc: fastboot, kexec, ppcdev, Paul Mackerras, Anton Blanchard
In-Reply-To: <4cb567d635b4ac3333e6b4b2c27c12f2@bga.com>
On Thu, Apr 26, 2007 at 09:42:50AM -0500, Milton Miller wrote:
> 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,
How about this patch?
It is observed that in some PPC970 based machines, When the kernel is
booted with maxcpus=1, interrupts were distributed to offline cpus
also. So a condition is included to check whether the cpu online
map and cpu present map are equal or not. If they are equal
default_distrib_server is used as the interrupt server otherwise
default_server(ie boot cpu) is used as the interrupt server.
In addition to this, if an interrupt is assigned to a specific cpu (ie
smp affinity) and if that cpu is not online, the earlier code used to
return the default_distrib_server as interrupt server. This patch
introduces an additional paramter to the get_irq function ie
strict_check, based on this parameter, if the cpu is not online either
default_distrib_server or -1 is returned.
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 | 63 +++++++++++++++++++++-------------
1 file changed, 39 insertions(+), 24 deletions(-)
Index: linux-2.6.21.1/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- linux-2.6.21.1.orig/arch/powerpc/platforms/pseries/xics.c
+++ linux-2.6.21.1/arch/powerpc/platforms/pseries/xics.c
@@ -156,9 +156,9 @@ static inline void lpar_qirr_info(int n_
#ifdef CONFIG_SMP
-static int get_irq_server(unsigned int virq)
+static int get_irq_server(unsigned int virq, unsigned int strict_check)
{
- unsigned int server;
+ int server;
/* For the moment only implement delivery to all cpus or one cpu */
cpumask_t cpumask = irq_desc[virq].affinity;
cpumask_t tmp = CPU_MASK_NONE;
@@ -166,22 +166,28 @@ static int get_irq_server(unsigned int v
if (!distribute_irqs)
return default_server;
- if (cpus_equal(cpumask, CPU_MASK_ALL)) {
- server = default_distrib_server;
- } else {
+ if (!cpus_equal(cpumask, CPU_MASK_ALL)) {
cpus_and(tmp, cpu_online_map, cpumask);
- if (cpus_empty(tmp))
- server = default_distrib_server;
+ server = first_cpu(tmp);
+
+ if (server < NR_CPUS)
+ return get_hard_smp_processor_id(server);
+ else {
+ if (strict_check)
+ return -1;
+ else
+ return default_distrib_server;
+ }
+ } else {
+ if (cpus_equal(cpu_online_map, cpu_present_map))
+ return default_distrib_server;
else
- server = get_hard_smp_processor_id(first_cpu(tmp));
+ return default_server;
}
-
- return server;
-
}
#else
-static int get_irq_server(unsigned int virq)
+static int get_irq_server(unsigned int virq, unsigned int strict_check)
{
return default_server;
}
@@ -192,7 +198,7 @@ static void xics_unmask_irq(unsigned int
{
unsigned int irq;
int call_status;
- unsigned int server;
+ int server;
pr_debug("xics: unmask virq %d\n", virq);
@@ -201,7 +207,7 @@ static void xics_unmask_irq(unsigned int
if (irq == XICS_IPI || irq == XICS_IRQ_SPURIOUS)
return;
- server = get_irq_server(virq);
+ server = get_irq_server(virq, 0);
call_status = rtas_call(ibm_set_xive, 3, 1, NULL, irq, server,
DEFAULT_PRIORITY);
@@ -398,8 +404,7 @@ static void xics_set_affinity(unsigned i
unsigned int irq;
int status;
int xics_status[2];
- unsigned long newmask;
- cpumask_t tmp = CPU_MASK_NONE;
+ int irq_server;
irq = (unsigned int)irq_map[virq].hwirq;
if (irq == XICS_IPI || irq == XICS_IRQ_SPURIOUS)
@@ -413,18 +418,28 @@ static void xics_set_affinity(unsigned i
return;
}
- /* For the moment only implement delivery to all cpus or one cpu */
- if (cpus_equal(cpumask, CPU_MASK_ALL)) {
- newmask = default_distrib_server;
- } else {
- cpus_and(tmp, cpu_online_map, cpumask);
- if (cpus_empty(tmp))
+ /* Get current irq_server for the given irq */
+ irq_server = get_irq_server(irq, 1);
+ if (irq_server == -1) {
+ printk(KERN_ERR "xics_set_affinity: Invalid cpumask\n");
+ return;
+ }
+
+ /* For the moment only implement delivery to all cpus or one cpu.
+ * Compare the irq_server with the new cpumask. If the irq_server
+ * is specified in cpumask, do the required rtas_call, otherwise
+ * return by printing an error message
+ */
+ if (!cpus_equal(cpumask, CPU_MASK_ALL)) {
+ if (!cpu_isset(irq_server, cpumask)) {
+ printk(KERN_ERR "xics_set_affinity: Invalid "
+ "cpumask\n");
return;
- newmask = get_hard_smp_processor_id(first_cpu(tmp));
+ }
}
status = rtas_call(ibm_set_xive, 3, 1, NULL,
- irq, newmask, xics_status[1]);
+ irq, irq_server, xics_status[1]);
if (status) {
printk(KERN_ERR "xics_set_affinity: irq=%u ibm,set-xive "
^ permalink raw reply
* Re: [PATCH] 86xx: Enable the AC97 interface on 8641D board.
From: Kumar Gala @ 2007-05-03 14:44 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1178142818.32136.51.camel@ld0161-tx32>
On May 2, 2007, at 4:53 PM, Jon Loeliger wrote:
> From: Jason Jin <jason.jin@freescale.com>
>
> HD interface and AC97 interface share some pins and they are
> enabled at
> the same time, In order to use AC97 interface, we need to disable
> the HD
> interface first.
>
> Signed-off-by:Jason Jin<jason.jin@freescale.com>
> Acked-by: Jon Loeliger <jdl@freescale.com>
> ---
> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
Is the HD feature not used at all? Is there a AC97 Driver CONFIG_
that makes sense to wrap that with? Just wondering about the mutual
exclusion (and how to provide flexibility to the user).
- k
>
> diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/
> powerpc/platforms/86xx/mpc86xx_hpcn.c
> index 3d3d98f..13a14dd 100644
> --- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> +++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> @@ -168,7 +168,7 @@ static void __devinit quirk_uli1575(struct
> pci_dev *dev)
> {
> unsigned short temp;
> struct pci_controller *hose = pci_bus_to_host(dev->bus);
> - unsigned char irq2pin[16];
> + unsigned char irq2pin[16], c;
> unsigned long pirq_map_word = 0;
> u32 irq;
> int i;
> @@ -288,6 +288,11 @@ static void __devinit quirk_uli1575(struct
> pci_dev *dev)
> outb(0x1e, 0x4d1);
>
> #undef ULI1575_SET_DEV_IRQ
> +
> + /* Disable the HD interface and enable the AC97 interface. */
> + pci_read_config_byte(dev, 0xb8, &c);
> + c &= 0x7f;
> + pci_write_config_byte(dev, 0xb8, c);
> }
>
> static void __devinit quirk_uli5288(struct pci_dev *dev)
> --
> 1.5.0.3
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [U-Boot-Users] Where do you find *.dtb files?
From: Jerry Van Baren @ 2007-05-03 14:05 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <4639E9BF.40902@cambridgebroadband.com>
Alex Zeffertt wrote:
> Jerry Van Baren wrote:
>> Alex Zeffertt wrote:
>>> Hi all,
>>>
>>> I'm trying to boot linux-2.6.21-rc5 on my mpc832xemds board which is
>>> running
>>> u-boot 1.2.0.
>>>
>>> According to u-boot I need a device tree blob:
>>>
>>> => help bootm
>>> bootm [addr [arg ...]]
>>> - boot application image stored in memory
>>> passing arguments 'arg ...'; when booting a Linux kernel,
>>> 'arg' can be the address of an initrd image
>>> When booting a Linux kernel which requires a flat
>>> device-tree
>>> a third argument is required which is the address of the
>>> of the
>>> device-tree blob. To boot that kernel without an initrd
>>> image,
>>> use a '-' for the second argument. If you do not pass a
>>> third
>>> a bd_info struct will be passed instead
>>>
>>>
>>> Can anybody tell me where I can find one for this board?
>>>
>>> TIA,
>>>
>>> Alex
>>
>> Kernel tree under arch/powerpc/boot/dts?
>> <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=arch/powerpc/boot/dts;h=2591d25045401b8beea474a1b4e117527e478521;hb=HEAD>
>>
>>
>> Best regards,
>> gvb
>
> Thanks Jerry. I've found
>
> powerpc/arch/powerpc/boot/dts/mpc832x_mds.dts
>
> ... but when I try to compile it I get an error:
>
> $ /opt/freescale/ltib/usr/bin/dtc -I dts -O dtb
> powerpc/arch/powerpc/boot/dts/mpc832x_mds.dts
> DTC: dts->dtb on file "powerpc/arch/powerpc/boot/dts/mpc832x_mds.dts"
> syntax error at line 14
> FATAL ERROR: Couldn't read input tree
>
> Perhaps my dtc is out of date - it came with the BSP from freescale
> which uses
> the 2.6.11 kernel.
>
> Do you know where I can find an up to date dtc? Is there any
> documentation regarding its use?
>
> Regards,
> Alex
Hi Alex,
Yes, you need to update your dtc. The latest dtc can be gotten from:
http://jdl.com/git_repos/
My makefile looks like this (WARNING: it is whitespace damaged, you must
replace the eight spaces in the rules with tabs):
8<--------------------------------------------------------------------
#
# Make device tree blobs
#
src = $(wildcard *.dts)
out = $(src:.dts=.dtb)
asm = $(src:.dts=.dtb)
QUIET = #-q
RESERVE = -R 4
SIZE = -S 0x3000
all: $(out)
%.dtb : %.dts
dtc $(QUIET) $(RESERVE) $(SIZE) -b 0 -O dtb -f -o $@ $^
%.asm : %.dts
dtc $(QUIET) $(RESERVE) $(SIZE) -b 0 -O asm -f -o $@ $^
8<--------------------------------------------------------------------
Best regards,
gvb
^ 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