[PATCH net] gianfar : Do right check on num_txbdfree
This patch fixes a wrong check on num_txbdfree. It could lead to num_txbdfree
become nagative.
Result was that the gianfar stops sending data.
Signed-off-by: Rini van Zetten
---
drivers/net/gianfar.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 7ef1ffd..2dc3bd3 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1284,9 +1284,8 @@ static int gfar_start_xmit(struct sk_buff *skb, struct
net_device *dev)
spin_lock_irqsave(&priv->txlock, flags);
/* check if there is space to queue this packet */
- if (nr_frags > priv->num_txbdfree) {
+ if ( (nr_frags+1) > priv->num_txbdfree) {
/* no space, stop the queue */
netif_stop_queue(dev);
dev->stats.tx_fifo_errors++;
spin_unlock_irqrestore(&priv->txlock, flags);
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH net] gianfar : Do right check on num_txbdfree
From: Rini van Zetten
Date: Thu, 26 Feb 2009 09:56:58 +0100
> This patch fixes a wrong check on num_txbdfree. It could lead to
> num_txbdfree become nagative. Result was that the gianfar stops
> sending data.
>
> Signed-off-by: Rini van Zetten - if (nr_frags > priv->num_txbdfree) {
> + if ( (nr_frags+1) > priv->num_txbdfree) {
Please don't put a space between the parens there "( (", like
that.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2 net] gianfar : Do right check on num_txbdfree
This patch fixes a wrong check on num_txbdfree. It could lead to num_txbdfree
become nagative.
Result was that the gianfar stops sending data.
Changes from first version :
- removed a space between parens (David Millers comment)
- full email address in signed off line
Signed-off-by: Rini van Zetten
---
drivers/net/gianfar.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 7ef1ffd..2dc3bd3 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1284,9 +1284,8 @@ static int gfar_start_xmit(struct sk_buff *skb, struct
net_device *dev)
spin_lock_irqsave(&priv->txlock, flags);
/* check if there is space to queue this packet */
-if (nr_frags > priv->num_txbdfree) {
+if ((nr_frags+1) > priv->num_txbdfree) {
/* no space, stop the queue */
netif_stop_queue(dev);
dev->stats.tx_fifo_errors++;
spin_unlock_irqrestore(&priv->txlock, flags);
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/1] Fix 64bit Mapple Host Bridge Address and Size Nodes
In the DTB tree created by firmware on Maple 64bit target, host bridge
parent
node has specified both of these two properties to be 2. However, the actual
"cell" value for host bridge node is 1. we have to provide one fixup
function.
Signed-off-by: Tiejun Chen
---
arch/powerpc/kernel/prom_init.c | 42
+++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c
b/arch/powerpc/kernel/prom_init.c
index 2445945..9cd23b6 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1948,8 +1948,49 @@ static void __init fixup_device_tree_maple(void)
prom_setprop(isa, name, "ranges",
isa_ranges, sizeof(isa_ranges));
}
+
+/* On Maple 64bit target host bridge parent node has specified address and
+ * size properties to be 2. But the actual "cell" value for host bridge
node
+ * is 1 since early MOTLoad internal bug. */
+static void __init fixup_device_tree_maple_hb(void)
+{
+ phandle hb;
+ u32 hb_ranges[4];
+ u32 size_cell, addr_cell;
+ struct prom_t *_prom = &RELOC(prom);
+ char *name;
+
+ name = "/hostbri...@f800";
+ hb = call_prom("finddevice", 1, 1, ADDR(name));
+ if (!PHANDLE_VALID(hb))
+ return;
+
+ if (prom_getproplen(hb, "reg") != 8)
+ return;
+
+ if (prom_getprop(hb, "reg", hb_ranges, (sizeof(hb_ranges))/2)
+ == PROM_ERROR)
+ return;
+
+ prom_getprop(_prom->root, "#address-cells", &addr_cell,
sizeof(addr_cell));
+ prom_getprop(_prom->root, "#size-cells", &size_cell,
sizeof(size_cell));
+
+ if ((addr_cell != 2) || (size_cell != 2) ||
+ (hb_ranges[0] != 0xf800))
+ return;
+
+ prom_printf("Fixing up bogus HOSTBRIDGE reg on Maple/Apache...\n");
+
+ hb_ranges[3] = hb_ranges[1];
+ hb_ranges[1] = hb_ranges[0];
+ hb_ranges[0] = hb_ranges[2] = 0;
+ prom_setprop(hb, name, "reg",
+ hb_ranges, sizeof(hb_ranges));
+}
+
#else
#define fixup_device_tree_maple()
+#define fixup_device_tree_maple_hb()
#endif
#ifdef CONFIG_PPC_CHRP
@@ -2190,6 +2231,7 @@ static void __init fixup_device_tree_efika(void)
static void __init fixup_device_tree(void)
{
fixup_device_tree_maple();
+ fixup_device_tree_maple_hb();
fixup_device_tree_chrp();
fixup_device_tree_pmac();
fixup_device_tree_efika();
--
1.5.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Thu, Feb 26, 2009 at 03:07:24PM +1100, Benjamin Herrenschmidt wrote: >Hi Linus ! > >Please pull a few regression fixes for powerpc. > >Cheers, >Ben. > >The following changes since commit 169d418b127b98a3e464e9c4b807ad083760f98c: > Linus Torvalds (1): >Merge branch 'for-linus' of git://git.kernel.org/.../tiwai/sound-2.6 > >are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge > >Mark Nelson (2): > powerpc: Fix 64bit memcpy() regression > powerpc: Fix 64bit __copy_tofrom_user() regression > >Michael Neuling (1): > powerpc: Fix load/store float double alignment handler You don't seem to have your fix for PCI 2.x stuff on 4xx here. Patchwork has it in accepted state and Geert has been asking if it would go in 2.6.29. Any idea what is up with that one? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Enable hashdist by default on 64bit NUMA
Hi David, > Hmmm... my bad, I think you need to keep the CONFIG_NUMA > there too as there is a TLB usage penalty for non-NUMA > systems if you only use CONFIG_64BIT there. Sorry that was my screwup, here's a fixed version. Anton -- On PowerPC we allocate large boot time hashes on node 0. This leads to an imbalance in the free memory, for example on a 64GB box (4 x 16GB nodes): Free memory: Node 0: 97.03% Node 1: 98.54% Node 2: 98.42% Node 3: 98.53% If we switch to using vmalloc (like ia64 and x86-64) things are more balanced: Free memory: Node 0: 97.53% Node 1: 98.35% Node 2: 98.33% Node 3: 98.33% For many HPC applications we are limited by the free available memory on the smallest node, so even though the same amount of memory is used the better balancing helps. Since all 64bit NUMA capable architectures should have sufficient vmalloc space, it makes sense to enable it via CONFIG_64BIT. Signed-off-by: Anton Blanchard --- diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h index 95837bf..0c4d4b7 100644 --- a/include/linux/bootmem.h +++ b/include/linux/bootmem.h @@ -144,10 +144,10 @@ extern void *alloc_large_system_hash(const char *tablename, #define HASH_EARLY 0x0001 /* Allocating during early boot? */ -/* Only NUMA needs hash distribution. - * IA64 and x86_64 have sufficient vmalloc space. +/* Only NUMA needs hash distribution. 64bit NUMA architectures have + * sufficient vmalloc space. */ -#if defined(CONFIG_NUMA) && (defined(CONFIG_IA64) || defined(CONFIG_X86_64)) +#if defined(CONFIG_NUMA) && defined(CONFIG_64BIT) #define HASHDIST_DEFAULT 1 #else #define HASHDIST_DEFAULT 0 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Enable hashdist by default on 64bit NUMA
From: Anton Blanchard Date: Thu, 26 Feb 2009 22:24:32 +1100 > On PowerPC we allocate large boot time hashes on node 0. This leads to > an imbalance in the free memory, for example on a 64GB box (4 x 16GB > nodes): > > Free memory: > Node 0: 97.03% > Node 1: 98.54% > Node 2: 98.42% > Node 3: 98.53% > > If we switch to using vmalloc (like ia64 and x86-64) things are more > balanced: > > Free memory: > Node 0: 97.53% > Node 1: 98.35% > Node 2: 98.33% > Node 3: 98.33% > > For many HPC applications we are limited by the free available memory on > the smallest node, so even though the same amount of memory is used the > better balancing helps. > > Since all 64bit NUMA capable architectures should have sufficient > vmalloc space, it makes sense to enable it via CONFIG_64BIT. > > Signed-off-by: Anton Blanchard Acked-by: David S. Miller ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Two thoughts about SPI chip-selects in the DTS
As far as I understand the DTS bindings now support an SPI master controller to - use the chip-selects controlled directly by the SPI master controller hardware or - to use GPIO's trough gpiolib as chip selects but not a combination of both, am I right? Now every SPI driver needs to be adapted to provide support for using gpios as chip-selects, Wouldn't it be possible to let the divers/of/of_spi take care of all the work required to use gpios as chip-selects? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8313E-RDB and USB OTG
Leo, sorry for sending this twice. Forgot to cc the list. > I am hoping someone can shed some light on the state of the USB support in > > the > > 2.6.28 kernel for USB OTG on the MPC8313E RDB. The configuration options > are > > a bit different than the ones from the provided LTIB kernel--- for > obvious > > reasons--- > > and I am trying to figure out how to get OTG working in this version of > the > > kernel > > on my board. > > USB OTG support for Freescale USB has not been included in mainline. > So you need to bring the OTG code up-to-date, or stay with the LTIB > kernel. > > - Leo > Thanks Leo. I will look into getting the OTG code included. Do you have a general outline of what would need to be done to it? Any potential trouble spots? Mike ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Add MPC52xx simple interrupt GPIO support
Hello,
I've got a target derived from the Lite5200 that needs to use simple
interrupt GPIO pins. I created a patch to support this kind of GPIO.
I would need your opinion and like to hear any criticism. Esp. the
facts that I ad to split up struct mpc52xx_gpio and that the GPIO
numbering might get mixed up concern me.
Because I'm somewhat new to git, at least when it comes to create and
incorporate patches via mail, you have to point out those errors as
well. The first thing I found lready out ist, that my patch isn't
signed off. I'll do that with an final version if I get the chance to
deliver one.
And here the patch:
Add MPC52xx simple interrupt GPIO support
Split of struct mpc52xx_sint_gpio from struct mpc52xx_gpio to allow a
different reg base address in the device tree.
Add the appropriate functions.
Update Documentation.
---
.../powerpc/mpc52xx-device-tree-bindings.txt |2 +
arch/powerpc/include/asm/mpc52xx.h | 40 +++--
arch/powerpc/platforms/52xx/mpc52xx_gpio.c | 164
+++-
3 files changed, 185 insertions(+), 21 deletions(-)
diff --git a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
index 6f12f1c..b5b31b2 100644
--- a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
+++ b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
@@ -190,6 +190,8 @@ gpt@ gpt fsl,mpc5200-gpt-gpioGeneral
purpose
timers in GPIO mode
gpio@fsl,mpc5200-gpioMPC5200 simple gpio
controller
+gpio@fsl,mpc5200-gpio-sint MPC5200 simple interrupt
+ gpio controller
gpio@fsl,mpc5200-gpio-wkup MPC5200 wakeup gpio
controller
rtc@ rtc mpc5200-rtc Real time clock
diff --git a/arch/powerpc/include/asm/mpc52xx.h
b/arch/powerpc/include/asm/mpc52xx.h
index 7655504..01abe61 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -126,24 +126,28 @@ struct mpc52xx_gpio {
u8 reserved1[3];/* GPIO + 0x19 */
u8 outo_dvo;/* GPIO + 0x1c */
u8 reserved2[3];/* GPIO + 0x1d */
- u8 sint_gpioe; /* GPIO + 0x20 */
- u8 reserved3[3];/* GPIO + 0x21 */
- u8 sint_ode;/* GPIO + 0x24 */
- u8 reserved4[3];/* GPIO + 0x25 */
- u8 sint_ddr;/* GPIO + 0x28 */
- u8 reserved5[3];/* GPIO + 0x29 */
- u8 sint_dvo;/* GPIO + 0x2c */
- u8 reserved6[3];/* GPIO + 0x2d */
- u8 sint_inten; /* GPIO + 0x30 */
- u8 reserved7[3];/* GPIO + 0x31 */
- u16 sint_itype; /* GPIO + 0x34 */
- u16 reserved8; /* GPIO + 0x36 */
- u8 gpio_control;/* GPIO + 0x38 */
- u8 reserved9[3];/* GPIO + 0x39 */
- u8 sint_istat; /* GPIO + 0x3c */
- u8 sint_ival; /* GPIO + 0x3d */
- u8 bus_errs;/* GPIO + 0x3e */
- u8 reserved10; /* GPIO + 0x3f */
+};
+
+/* Simple Interrupt GPIO */
+struct mpc52xx_sint_gpio {
+ u8 sint_gpioe; /* GPIO + 0x00 */
+ u8 reserved3[3];/* GPIO + 0x01 */
+ u8 sint_ode;/* GPIO + 0x04 */
+ u8 reserved4[3];/* GPIO + 0x05 */
+ u8 sint_ddr;/* GPIO + 0x08 */
+ u8 reserved5[3];/* GPIO + 0x09 */
+ u8 sint_dvo;/* GPIO + 0x0c */
+ u8 reserved6[3];/* GPIO + 0x0d */
+ u8 sint_inten; /* GPIO + 0x10 */
+ u8 reserved7[3];/* GPIO + 0x11 */
+ u16 sint_itype; /* GPIO + 0x14 */
+ u16 reserved8; /* GPIO + 0x16 */
+ u8 gpio_control;/* GPIO + 0x18 */
+ u8 reserved9[3];/* GPIO + 0x19 */
+ u8 sint_istat; /* GPIO + 0x1c */
+ u8 sint_ival; /* GPIO + 0x1d */
+ u8 bus_errs;/* GPIO + 0x1e */
+ u8 reserved10; /* GPIO + 0x1f */
};
#define MPC52xx_GPIO_PSC_CONFIG_UART_WITHOUT_CD4
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
index 07f89ae..8595aad 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
@@ -31,9 +31,9 @@ static DEFINE_SPINLOCK(gpio_lock);
struct mpc52xx_gpiochip {
struct of_mm_gpio_chip mmchip;
- unsigned int shadow_dvo;
- unsigned int shadow_gpioe;
- unsigned int shadow_ddr;
+ uint32_t shadow_dvo;
+ uint32_t shadow_gpioe;
+ uint32_t shadow_ddr;
};
/*
@@ -355,6 +355,161 @@ static struct of_platform_driver
mpc52xx_simple_gpiochip_driver = {
};
/*
How to set external interrupts falling edge sensitive
Hi all, I'm using the mpc8313erdb. I got two external interrupt sources which are handled by two UIO drivers. These interrupts shall be triggered on falling edge. Therefore I just added (Kernel version 2.6.24) in arch/powerpc/sysdev/ipic.c in function ipic_set_irq_type at line ~484 "flow_type = IRQ_TYPE_EDGE_FALLING;" /* only EXT IRQ senses are programmable on ipic * internal IRQ senses are LEVEL_LOW */ flow_type = IRQ_TYPE_EDGE_FALLING; // < added this line if (src == IPIC_IRQ_EXT0) edibit = 15; else if (src >= IPIC_IRQ_EXT1 && src <= IPIC_IRQ_EXT7) edibit = (14 - (src - IPIC_IRQ_EXT1)); else return (flow_type & IRQ_TYPE_LEVEL_LOW) ? 0 : -EINVAL; and it seemed to work for me. But when I'm adding this line in Kernel version 2.6.28.7 I'll get these messages on startup: setting trigger mode 8 for irq 38 failed (0xc0017160) setting trigger mode 8 for irq 37 failed (0xc0017160) setting trigger mode 8 for irq 36 failed (0xc0017160) setting trigger mode 8 for irq 35 failed (0xc0017160) setting trigger mode 8 for irq 34 failed (0xc0017160) setting trigger mode 8 for irq 33 failed (0xc0017160) setting trigger mode 8 for irq 32 failed (0xc0017160) ... It seems to me, that this is not the right place to configure the external interrupts as "falling edge" I guess that the dtb file might be the right place, please correct me if I'm wrong. But I have no idea how to add those both external interrupt sources into the dts file. Any hints are appreciated! Thanks regards Frank ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: defining platform_devices in DTS
(note: added the devicetree-discuss mailing list to this thread)
On Wed, Feb 25, 2009 at 2:20 AM, Pieter wrote:
> Hi all
>
> I am busy porting my board to Linux 2.6.27 from 2.6.19. The old Linux
> was compiled using the ppc architecture, and had a "platform_device"
> struct ure containing the custom devices on my board. (
> /arch/ppc/platform/sdh8548.c and /arch/ppc/platform/sdh8548.h )
>
> I assume these devices should now be declared in the device tree source.
> Building the new Linux using the powerpc architecture, but I am
> strugeling translating teh information defined in the "platform_device"
> to a device tree node. In particular what happens to the resource.flags
> could anyone help please?
For the most common flags (IO_RESOURCE_MEM & IO_RESOURCE_IRQ), you use
the 'reg' and 'interrupts' properties respectively to describe your
device. The usage of them is well established.
> Below is the "platform_device" definition and my interpretation of how
> it should look in the device tree. Am I on the right track?
Yes, you're on the right track; comments below
> thanks pieter
>
> platform_device definition:
> {
> .name = "bio",
> .id = 0,
> .dev.platform_data = NULL,
> .num_resources = 2,
> .resource = (struct resource[]) {
> {
> .start = 0xe010,
> .end = 0xe010 + 0x1 -1,
> .flags = IORESOURCE_MEM, /* 0x0200 */
> },
> {
> .name = "int",
> .start = MPC85xx_IRQ_EXT0, /* 48 +
> MPC85xx_OPENPIC_IRQ_OFFSET */
> .end = MPC85xx_IRQ_EXT0,
> .flags = IORESOURCE_IRQ, /*0x0400 */
> },
> },
>
> FDT source:
> local...@e000 {
> #address-cells = <2>;
> #size-cells = <1>;
> compatible = "simple-bus";
> reg = <0xe000 0x5000>;
> interrupt-parent = <&mpic>;
>
> ranges = <
> 0x0 0x0 0xf800 0x07ff /*128MB Flash*/
> 0x1 0x0 0xe020 0x0020 /*2MB FPGA*/
> 0x2 0x0 0xe010 0x0010 /*1MB BIO CPLD*/
> >;
Your ranges property appears to be correct.
> ...@2,0 {
> compatible = "wrs,epld-localbus";
This property is what the whole system hangs of and it is important
that it is unique for the device you are describing. Device drivers
read the compatible property and use it to decide whether or not it
can drive the device. If this is a board-specific EPLD, then the name
of the board should be part of the name. Once you've selected a name,
you must document what the name means in
Documentation/powerpc/dts-bindings/ and what properties are required
in nodes with this value.
> #address-cells = <2>;
> #size-cells = <1>;
Only use #address-cells and #size-cells if there is a child node that
has a 'reg' property.
> //interrupt-parent = <&mpic>;
You don't need interrupt-parent if the parent node already sets it correctly.
> //interrupts = <48>;
This is probably where you are having trouble. To determine the
format of the interrupts property you need to look at the interrupt
parent node. The #interrupt-cells property in the interrupt parent
will tell you how many numbers (cells) need to be in the interrupts
property for each irq line. In this case the mpic specifies
'#interrupt-cells=<2>;'. So, the interrupts property here should be
in the form: "interrupts = < [irq-number] [irq-type] >;"
irq-number is the irq line
irq-type is the sense (edge/level, high/low). See mpic_host_xlate()
in arch/powerpc/sysdev/mpic.c for the mapping (map_mpic_senses)
between the irq-type value and the type of interrupt (duplicated
here):
static unsigned char map_mpic_senses[4] = {
IRQ_TYPE_EDGE_RISING,
IRQ_TYPE_LEVEL_LOW,
IRQ_TYPE_LEVEL_HIGH,
IRQ_TYPE_EDGE_FALLING,
};
> reg = <0x2 0x0 0x001>;
reg looks correct.
> ranges = <0x0 0x0 0x2 0x0 0x0010>;
Only use ranges if there is a child node.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 net] gianfar : Do right check on num_txbdfree
On Thu, 26 Feb 2009, Rini van Zetten wrote: > This patch fixes a wrong check on num_txbdfree. It could lead to num_txbdfree > become nagative. > Result was that the gianfar stops sending data. A quick mental note for your next patch submission: > Changes from first version : > - removed a space between parens (David Millers comment) > - full email address in signed off line Changelogs since previous versions should be ... > Signed-off-by: Rini van Zetten > --- ... here, below the `---', as they're not supposed to be end up in the final commit message. > drivers/net/gianfar.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: geert.uytterhoe...@sonycom.com Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC v2] virtio: add virtio-over-PCI driver
On Tuesday 24 February 2009, Ira Snyder wrote:
> This adds support to Linux for using virtio between two computers linked by
> a PCI interface. This allows the use of virtio_net to create a familiar,
> fast interface for communication. It should be possible to use other virtio
> devices in the future, but this has not been tested.
Wonderful, I like it a lot!
One major aspect that I hope can be improved is the layering
of the driver to make it easier to reuse parts for other
hardware implementations and also for sharing code between
the two sides. Most of my comments below are about this.
A better split I can imagine would be:
1. of_device hardware specific probing, and creation of virtqueues
2. pci hardware specific probing, and detection of virtqueues
3. library with common code, hardware independent
4. library with common code, hardware specific but used by both of_device
and pci.
5. interface to virtio-net on top of that (symmetric)
> +/* Virtio-over-PCI descriptors: 12 bytes. These can chain together via
> "next" */
> +struct vop_desc {
> + /* Address (host physical) */
> + __le32 addr;
> + /* Length (bytes) */
> + __le32 len;
> + /* Flags */
> + __le16 flags;
> + /* Chaining for descriptors */
> + __le16 next;
> +} __attribute__((packed));
I would drop the "packed" attribute in the structure definitions.
It would imply that only byte accesses are allowed on these
data structures, because the attribute invalidates any assumptions
about alignment. None of your structures require padding, so
the attribute does not have any positive effect either.
> +/* MPC8349EMDS specific get_immrbase() */
> +#include
Do you really need get_immrbase? I would expect that you can find
all the registers you need in the device tree, or exported from
other low-level drivers per subsystem.
immrbase is a concept from the time before our device trees.
> +/*
> + * These are internal use only versions of the structures that
> + * are exported over PCI by this driver
> + *
> + * They are used internally to keep track of the PowerPC queues so that
> + * we don't have to keep flipping endianness all the time
> + */
> +struct vop_loc_desc {
> + u32 addr;
> + u32 len;
> + u16 flags;
> + u16 next;
> +};
> +
> +struct vop_loc_avail {
> + u16 index;
> + u16 ring[VOP_RING_SIZE];
> +};
> +
> +struct vop_loc_used_elem {
> + u32 id;
> + u32 len;
> +};
> +
> +struct vop_loc_used {
> + u16 index;
> + struct vop_loc_used_elem ring[VOP_RING_SIZE];
> +};
Are you worried about the overhead of having to do byte flips,
or the code complexity? I would guess that the overhead is
near zero, but I'm not sure about the source code complexity.
Generally, I'd expect that you'd be better off just using the
wire-level data structures directly.
> +/*
> + * DMA Resolver state information
> + */
> +struct vop_dma_info {
> + struct dma_chan *chan;
> +
> + /* The currently processing avail entry */
> + u16 loc_avail;
> + u16 rem_avail;
> +
> + /* The currently processing used entries */
> + u16 loc_used;
> + u16 rem_used;
> +};
> +
> +struct vop_vq {
> +
> + /* The actual virtqueue itself */
> + struct virtqueue vq;
> + struct device *dev;
> +
> + /* The host ring address */
> + struct vop_host_ring __iomem *host;
> +
> + /* The guest ring address */
> + struct vop_guest_ring *guest;
> +
> + /* Our own memory descriptors */
> + struct vop_loc_desc desc[VOP_RING_SIZE];
> + struct vop_loc_avail avail;
> + struct vop_loc_used used;
> + unsigned int flags;
> +
> + /* Data tokens from add_buf() */
> + void *data[VOP_RING_SIZE];
> +
> + unsigned int num_free; /* number of free descriptors in desc */
> + unsigned int free_head; /* start of the free descriptors in desc */
> + unsigned int num_added; /* number of entries added to desc */
> +
> + u16 loc_last_used; /* the last local used entry processed */
> + u16 rem_last_used; /* the current value of remote used_idx */
> +
> + /* DMA resolver state */
> + struct vop_dma_info dma;
> + struct work_struct work;
> + int (*resolve)(struct vop_vq *vq);
> +
> + void __iomem *immr;
> + int kick_val;
> +};
This data structure mixes generic information with fsl-834x specific
members. I think you should try to split this better into a common
part (also common for host and guest) to allow sharing the code
across other low-level implementations:
struct vop_vq {
struct virtqueue vq;
struct vop_host_ring __iomem *host;
struct vop_guest_ring *guest;
...
};
and in another file:
struct fsl834x_vq {
struct vop_vq;
struct fsl834x_vop_regs __iomem *regs; /* instead of immr */
}
If you split the structures this way, the abstraction should
come naturally.
> +/*
> + * This represents a virtio_device for our driver. It follows the memory
> + * layout shown above. It ha
Re: [RFC v2] virtio: add virtio-over-PCI driver
On Thu, 26 Feb 2009, Arnd Bergmann wrote:
> On Tuesday 24 February 2009, Ira Snyder wrote:
> > +/* Virtio-over-PCI descriptors: 12 bytes. These can chain together via
> > "next" */
> > +struct vop_desc {
> > + /* Address (host physical) */
> > + __le32 addr;
Only 32-bit? Is this future-proof?
> > + /* Length (bytes) */
> > + __le32 len;
> > + /* Flags */
> > + __le16 flags;
> > + /* Chaining for descriptors */
> > + __le16 next;
> > +} __attribute__((packed));
>
> I would drop the "packed" attribute in the structure definitions.
> It would imply that only byte accesses are allowed on these
> data structures, because the attribute invalidates any assumptions
> about alignment. None of your structures require padding, so
> the attribute does not have any positive effect either.
>
> > +/* MPC8349EMDS specific get_immrbase() */
> > +#include
>
> Do you really need get_immrbase? I would expect that you can find
> all the registers you need in the device tree, or exported from
> other low-level drivers per subsystem.
>
> immrbase is a concept from the time before our device trees.
>
> > +/*
> > + * These are internal use only versions of the structures that
> > + * are exported over PCI by this driver
> > + *
> > + * They are used internally to keep track of the PowerPC queues so that
> > + * we don't have to keep flipping endianness all the time
> > + */
> > +struct vop_loc_desc {
> > + u32 addr;
^^^
Same here.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: geert.uytterhoe...@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Crash (ext3 ) during 2.6.29-rc6 boot
On Thu, 26 Feb 2009, Mark Nelson wrote: > On Thu, 26 Feb 2009 09:45:41 am Mark Nelson wrote: > > On Thu, 26 Feb 2009 12:31:20 am Geert Uytterhoeven wrote: > > > On Wed, 25 Feb 2009, Mark Nelson wrote: > > > > Does the following patch fix the errors you're seeing? (it applies the > > > > same fix as the previous patch but this time to copy_tofrom_user, which > > > > I updated in a4e22f02f5b6518c1484faea1f88d81802b9feac) > > > > > > Thanks, but I still get crashes in copy_page_range(). > > > > Hmmm... I'm out of ideas for the moment, but thanks for testing anyway! > > If you revert both 25d6e2d7c58ddc4a3b614fc5381591c0cfe66556 and > a4e22f02f5b6518c1484faea1f88d81802b9feac, does it help? You could also > try to revert 57dda6ef5bd5b9e60410477ad29e654097e2cca1 just in case I > need to keep wearing the brown paper bag for a bit longer :) Still doesn't help. However, I noticed I never enabled CONFIG_DEBUG_PAGEALLOC before 2.6.29-rc5. So far I tried 2.6.2[5-8], and they all crash with CONFIG_DEBUG_PAGEALLOC. I guess it never actually worked on PS3. With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: geert.uytterhoe...@sonycom.com Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
OF -> platform_device
I'm trying to use some drivers which are not yet OF aware
(in particular net/dsa). In order to use these drivers, I
need platform_device pointers for my network any MII bus (PHY).
In the OF world, how do I get to these? I have a MPC834x
based board and somehow I need access to these devices (from
my DTS file):
m...@24520 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-mdio";
reg = <0x24520 0x20>;
phy0: ethernet-...@0 {
interrupt-parent = <&ipic>;
interrupts = <17 0x8>;
reg = <0x1>;
device_type = "ethernet-phy";
};
phy1: ethernet-...@1 {
interrupt-parent = <&ipic>;
interrupts = <18 0x8>;
reg = <0x2>;
device_type = "ethernet-phy";
};
};
enet0: ether...@24000 {
cell-index = <0>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <0x24000 0x1000>;
local-mac-address = [ 00 08 e5 11 32 33 ];
interrupts = <32 0x8 33 0x8 34 0x8>;
interrupt-parent = <&ipic>;
phy-handle = <&phy0>;
linux,network-index = <0>;
};
enet1: ether...@25000 {
cell-index = <1>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <0x25000 0x1000>;
local-mac-address = [ 00 08 e5 11 32 34 ];
interrupts = <35 0x8 36 0x8 37 0x8>;
interrupt-parent = <&ipic>;
phy-handle = <&phy1>;
linux,network-index = <1>;
};
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
PHY not found after migration of gianfar driver to an of_platform_driver
Hello everyone, I recently obtained a Mikrotik RB600 and applied the patch from http://cynigram.com/~nfontes/rb600/ to get it up and running with 2.6.28.3 With this patch applied everything was detected on the board and worked. For testing purposes I tried a recent git snapshot and noticed that the gianfar driver had problems. While the the Gianfar was detected [0.549115] Gianfar MII Bus: probed [0.553316] eth0 (fsl-gianfar): not using net_device_ops yet [0.560861] eth0: Gianfar Ethernet Controller Version 1.2, 00:0c: 42:28:de:4e [0.568024] eth0: Running with NAPI enabled [0.572234] eth0: 256/256 RX/TX BD ring size [0.576802] eth1 (fsl-gianfar): not using net_device_ops yet [0.584200] eth1: Gianfar Ethernet Controller Version 1.2, 00:0c: 42:28:de:4f [0.591345] eth1: Running with NAPI enabled [0.595575] eth1: 256/256 RX/TX BD ring size trying to up either of the devices gave me [8.724818] m...@24520:01 not found [8.728330] eth1: Could not attach to PHY [8.732945] m...@24520:01 not found [8.737720] eth1: Could not attach to PHY I tracked this back to commit "b31a1d8b41513b96e9c7ec2f68c5734cef0b26a4 gianfar: Convert gianfar to an of_platform_driver". Reverting this one and applying for fsc_soc.c made the two nics work again. I tried to figure out what was causing the problem in the first place, but failed miserably. I am pretty sure it is just a minor probing issue somewhere in the code but I am not able to spot that. Maybe someone more knowledgeable than me can take a look at it and help me out a little bit. According to lspci the board is a 00:00.0 Power PC: Freescale Semiconductor Inc MPC8343 (rev 30) Please CC me in any replies since I am not subscribed to the ML .. yet. Thanks in advance, Michael ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 01/10] powerpc: Set up OF properties for ppc32 kexec
I have looking for kexec support on pppc32. Where can I find and download all the patches for kernel the kexec-tools? Which kernel version should the patches apply to? Thanks Liang Chai ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC v2] virtio: add virtio-over-PCI driver
On Thu, Feb 26, 2009 at 05:15:27PM +0100, Arnd Bergmann wrote:
> On Tuesday 24 February 2009, Ira Snyder wrote:
> > This adds support to Linux for using virtio between two computers linked by
> > a PCI interface. This allows the use of virtio_net to create a familiar,
> > fast interface for communication. It should be possible to use other virtio
> > devices in the future, but this has not been tested.
>
> Wonderful, I like it a lot!
>
> One major aspect that I hope can be improved is the layering
> of the driver to make it easier to reuse parts for other
> hardware implementations and also for sharing code between
> the two sides. Most of my comments below are about this.
>
> A better split I can imagine would be:
>
> 1. of_device hardware specific probing, and creation of virtqueues
> 2. pci hardware specific probing, and detection of virtqueues
> 3. library with common code, hardware independent
> 4. library with common code, hardware specific but used by both of_device
>and pci.
> 5. interface to virtio-net on top of that (symmetric)
>
I think so too. I was just getting something working, and thought it
would be better to have it "out there" rather than be working on it
forever. I'll try to break things up as I have time.
For the "libraries", would you suggest breaking things into seperate
code files, and using EXPORT_SYMBOL_GPL()? I'm not very familiar with
doing that, I've mostly been writing code within the existing device
driver frameworks. Or do I need export symbol at all? I'm not sure...
> > +/* Virtio-over-PCI descriptors: 12 bytes. These can chain together via
> > "next" */
> > +struct vop_desc {
> > + /* Address (host physical) */
> > + __le32 addr;
> > + /* Length (bytes) */
> > + __le32 len;
> > + /* Flags */
> > + __le16 flags;
> > + /* Chaining for descriptors */
> > + __le16 next;
> > +} __attribute__((packed));
>
> I would drop the "packed" attribute in the structure definitions.
> It would imply that only byte accesses are allowed on these
> data structures, because the attribute invalidates any assumptions
> about alignment. None of your structures require padding, so
> the attribute does not have any positive effect either.
>
I always thought you were supposed to use packed for data structures
that are external to the system. I purposely designed the structures so
they wouldn't need padding.
I'll drop it and check for any problems.
> > +/* MPC8349EMDS specific get_immrbase() */
> > +#include
>
> Do you really need get_immrbase? I would expect that you can find
> all the registers you need in the device tree, or exported from
> other low-level drivers per subsystem.
>
> immrbase is a concept from the time before our device trees.
>
I mostly don't need it. In fact, the only place I'm using registers not
specific to the messaging unit is in the probe routine, where I setup
the 1GB window into host memory and setting up access to the guest
memory on the PCI bus.
Now, I wouldn't need to access these registers at all if the bootloader
could handle it. I just don't know if it is possible to have Linux not
use some memory that the bootloader allocated, other than with the
mem=XXX trick, which I'm sure wouldn't be acceptable. I've just used
regular RAM so this is portable to my custom board (mpc8349emds based)
and a regular mpc8349emds. I didn't want to change anything board
specific.
I would love to have the bootloader allocate (or reserve somewhere in
the memory map) 16K of RAM, and not be required to allocate it with
dma_alloc_coherent(). It would save me plenty of headaches.
> > +/*
> > + * These are internal use only versions of the structures that
> > + * are exported over PCI by this driver
> > + *
> > + * They are used internally to keep track of the PowerPC queues so that
> > + * we don't have to keep flipping endianness all the time
> > + */
> > +struct vop_loc_desc {
> > + u32 addr;
> > + u32 len;
> > + u16 flags;
> > + u16 next;
> > +};
> > +
> > +struct vop_loc_avail {
> > + u16 index;
> > + u16 ring[VOP_RING_SIZE];
> > +};
> > +
> > +struct vop_loc_used_elem {
> > + u32 id;
> > + u32 len;
> > +};
> > +
> > +struct vop_loc_used {
> > + u16 index;
> > + struct vop_loc_used_elem ring[VOP_RING_SIZE];
> > +};
>
> Are you worried about the overhead of having to do byte flips,
> or the code complexity? I would guess that the overhead is
> near zero, but I'm not sure about the source code complexity.
> Generally, I'd expect that you'd be better off just using the
> wire-level data structures directly.
>
Code complexity only. Also, it was easier to write 80-char lines with
something like:
vop_get_desc(vq, idx, &desc);
if (desc.flags & VOP_DESC_F_NEXT) {
/* do something */
}
Instead of:
if (le16_to_cpu(vq->desc[idx].flags) & VOP_DESC_F_NEXT) {
/* do something */
}
Plus, I didn't have to remember how many bits were in each field. I just
thought it made everything simpler to understand. Suggestions?
> > +/*
Re: [RFC v2] virtio: add virtio-over-PCI driver
On Thu, Feb 26, 2009 at 05:53:56PM +0100, Geert Uytterhoeven wrote:
> On Thu, 26 Feb 2009, Arnd Bergmann wrote:
> > On Tuesday 24 February 2009, Ira Snyder wrote:
> > > +/* Virtio-over-PCI descriptors: 12 bytes. These can chain together via
> > > "next" */
> > > +struct vop_desc {
> > > + /* Address (host physical) */
> > > + __le32 addr;
>
> Only 32-bit? Is this future-proof?
>
Probably not. If I use __le64 instead, how do I write 64 bytes over the
PCI bus? There isn't an iowrite64()/ioread64() anywhere in Linux.
Thanks,
Ira
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/1] Fix 64bit Mapple Host Bridge Address and Size Nodes
On Thu, 2009-02-26 at 18:08 +0800, Tiejun Chen wrote:
> In the DTB tree created by firmware on Maple 64bit target, host bridge
> parent
> node has specified both of these two properties to be 2. However, the
> actual
> "cell" value for host bridge node is 1. we have to provide one fixup
> function.
Hi !
Thanks for the patch. A couple of things tho: Can you make it a bit
more robust by properly checking the board type first ?
Also, what is this "hostbridge" node ? ie, what does it represent ?
Can you send me a full dump of /proc/device-tree from the machine ?
(ie tar it up)
Finally, it looks like your patch was whitespace damaged by your mailer.
Cheers,
Ben.
> Signed-off-by: Tiejun Chen
> ---
> arch/powerpc/kernel/prom_init.c | 42
> +++
> 1 files changed, 42 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom_init.c
> b/arch/powerpc/kernel/prom_init.c
> index 2445945..9cd23b6 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -1948,8 +1948,49 @@ static void __init
> fixup_device_tree_maple(void)
>prom_setprop(isa, name, "ranges",
>isa_ranges, sizeof(isa_ranges));
> }
> +
> +/* On Maple 64bit target host bridge parent node has specified
> address and
> + * size properties to be 2. But the actual "cell" value for host
> bridge node
> + * is 1 since early MOTLoad internal bug. */
> +static void __init fixup_device_tree_maple_hb(void)
> +{
> + phandle hb;
> + u32 hb_ranges[4];
> + u32 size_cell, addr_cell;
> + struct prom_t *_prom = &RELOC(prom);
> + char *name;
> +
> + name = "/hostbri...@f800";
> + hb = call_prom("finddevice", 1, 1, ADDR(name));
> + if (!PHANDLE_VALID(hb))
> + return;
> +
> + if (prom_getproplen(hb, "reg") != 8)
> + return;
> +
> + if (prom_getprop(hb, "reg", hb_ranges, (sizeof(hb_ranges))/2)
> + == PROM_ERROR)
> + return;
> +
> + prom_getprop(_prom->root, "#address-cells", &addr_cell,
> sizeof(addr_cell));
> + prom_getprop(_prom->root, "#size-cells", &size_cell,
> sizeof(size_cell));
> +
> + if ((addr_cell != 2) || (size_cell != 2) ||
> + (hb_ranges[0] != 0xf800))
> + return;
> +
> + prom_printf("Fixing up bogus HOSTBRIDGE reg on
> Maple/Apache...\n");
> +
> + hb_ranges[3] = hb_ranges[1];
> + hb_ranges[1] = hb_ranges[0];
> + hb_ranges[0] = hb_ranges[2] = 0;
> + prom_setprop(hb, name, "reg",
> + hb_ranges, sizeof(hb_ranges));
> +}
> +
> #else
> #define fixup_device_tree_maple()
> +#define fixup_device_tree_maple_hb()
> #endif
>
> #ifdef CONFIG_PPC_CHRP
> @@ -2190,6 +2231,7 @@ static void __init fixup_device_tree_efika(void)
> static void __init fixup_device_tree(void)
> {
>fixup_device_tree_maple();
> + fixup_device_tree_maple_hb();
>fixup_device_tree_chrp();
>fixup_device_tree_pmac();
>fixup_device_tree_efika();
> --
> 1.5.6
>
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Thu, 2009-02-26 at 06:28 -0500, Josh Boyer wrote: > On Thu, Feb 26, 2009 at 03:07:24PM +1100, Benjamin Herrenschmidt wrote: > >Hi Linus ! > > > >Please pull a few regression fixes for powerpc. > > > >Cheers, > >Ben. > > > >The following changes since commit 169d418b127b98a3e464e9c4b807ad083760f98c: > > Linus Torvalds (1): > >Merge branch 'for-linus' of git://git.kernel.org/.../tiwai/sound-2.6 > > > >are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge > > > >Mark Nelson (2): > > powerpc: Fix 64bit memcpy() regression > > powerpc: Fix 64bit __copy_tofrom_user() regression > > > >Michael Neuling (1): > > powerpc: Fix load/store float double alignment handler > > You don't seem to have your fix for PCI 2.x stuff on 4xx here. Patchwork > has it in accepted state and Geert has been asking if it would go in 2.6.29. > > Any idea what is up with that one? This isn't a regression is it ? so it's a bit late now, have you checked if it's in my next or test branch ? I would have though it would have gone through your tree, maybe I missed it some way. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC v2] virtio: add virtio-over-PCI driver
On Thursday 26 February 2009, Ira Snyder wrote:
> On Thu, Feb 26, 2009 at 05:15:27PM +0100, Arnd Bergmann wrote:
>
> I think so too. I was just getting something working, and thought it
> would be better to have it "out there" rather than be working on it
> forever. I'll try to break things up as I have time.
Ok, perfect!
> For the "libraries", would you suggest breaking things into seperate
> code files, and using EXPORT_SYMBOL_GPL()? I'm not very familiar with
> doing that, I've mostly been writing code within the existing device
> driver frameworks. Or do I need export symbol at all? I'm not sure...
You have both options. When you list each file as a separate module
in the Makefile, you use EXPORT_SYMBOL_GPL to mark functions that
get called by dependent modules, but this will work only in one way.
You can also link multiple files together into one module, although
it is less common to link a single source file into multiple modules.
> I always thought you were supposed to use packed for data structures
> that are external to the system. I purposely designed the structures so
> they wouldn't need padding.
That would only make sense for structures that are explicitly unaligned,
like a register layout using
struct my_registers {
__le16 first;
__le32 second __attribute__((packed));
__le16 third;
};
Even here, I'd recommend listing the individual members as packed
rather than the entire struct. Obviously if you layout the members
in a sane way, you don't need either.
> I mostly don't need it. In fact, the only place I'm using registers not
> specific to the messaging unit is in the probe routine, where I setup
> the 1GB window into host memory and setting up access to the guest
> memory on the PCI bus.
You could add the registers you need for this to the "reg" property
of your device, to be mapped with of_iomap.
If the registers for setting up this window don't logically fit
into the same device as the one you already use, the cleanest
solution would be to have another device just for this and then
make a function call into that driver to set up the window.
> Now, I wouldn't need to access these registers at all if the bootloader
> could handle it. I just don't know if it is possible to have Linux not
> use some memory that the bootloader allocated, other than with the
> mem=XXX trick, which I'm sure wouldn't be acceptable. I've just used
> regular RAM so this is portable to my custom board (mpc8349emds based)
> and a regular mpc8349emds. I didn't want to change anything board
> specific.
>
> I would love to have the bootloader allocate (or reserve somewhere in
> the memory map) 16K of RAM, and not be required to allocate it with
> dma_alloc_coherent(). It would save me plenty of headaches.
I believe you can do that through the "memory" devices in the
device tree, by leaving out a small part of the description of
main memory, at putting it into the "reg" property of your own
device.
> Code complexity only. Also, it was easier to write 80-char lines with
> something like:
>
> vop_get_desc(vq, idx, &desc);
> if (desc.flags & VOP_DESC_F_NEXT) {
> /* do something */
> }
>
> Instead of:
> if (le16_to_cpu(vq->desc[idx].flags) & VOP_DESC_F_NEXT) {
> /* do something */
> }
>
> Plus, I didn't have to remember how many bits were in each field. I just
> thought it made everything simpler to understand. Suggestions?
hmm, in this particular case, you could change the definition
of VOP_DESC_F_NEXT to
#define VOP_DESC_F_NEXT cpu_to_le16(1)
and then do the code as the even simpler (source and object code wise)
if (vq->desc[idx].flags) & VOP_DESC_F_NEXT)
I'm not sure if you can do something along these lines for the other
cases as well though.
> I used 3 so they would would align to 1024 byte boundaries within a 4K
> page. Then the layout was 16K on the bus, each 4K page is a single
> virtio-device, and each 1K block is a single virtqueue. The first 1K is
> for virtio-device status and feature bits, etc.
>
> Packing them differently isn't a problem. It was just easier to code
> because setting up a window with the correct size is so platform
> specific.
Ok. I guess the important question is what part of the code makes
this decision. Ideally, the virtio-net glue would instantiate
the device with the right number of queues.
> > > +/*
> > > + * This function abuses some of the scatterlist code and implements
> > > + * dma_map_sg() in such a way that we don't need to keep the scatterlist
> > > + * around in order to unmap it.
> > > + *
> > > + * It is also designed to never merge scatterlist entries, which is
> > > + * never what we want for virtio.
> > > + *
> > > + * When it is time to unmap the buffer, you can use dma_unmap_single() to
> > > + * unmap each entry in the chain. Get the address, length, and direction
> > > + * from the descriptors! (keep a local copy for speed)
> > > + */
> >
> > Why is that an advantage over dma_unmap_sg?
> >
>
> When running d
Re: [git pull] Please pull powerpc.git merge branch
On Fri, Feb 27, 2009 at 07:30:21AM +1100, Benjamin Herrenschmidt wrote: >On Thu, 2009-02-26 at 06:28 -0500, Josh Boyer wrote: >> On Thu, Feb 26, 2009 at 03:07:24PM +1100, Benjamin Herrenschmidt wrote: >> >Hi Linus ! >> > >> >Please pull a few regression fixes for powerpc. >> > >> >Cheers, >> >Ben. >> > >> >The following changes since commit 169d418b127b98a3e464e9c4b807ad083760f98c: >> > Linus Torvalds (1): >> >Merge branch 'for-linus' of git://git.kernel.org/.../tiwai/sound-2.6 >> > >> >are available in the git repository at: >> > >> > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge >> > >> >Mark Nelson (2): >> > powerpc: Fix 64bit memcpy() regression >> > powerpc: Fix 64bit __copy_tofrom_user() regression >> > >> >Michael Neuling (1): >> > powerpc: Fix load/store float double alignment handler >> >> You don't seem to have your fix for PCI 2.x stuff on 4xx here. Patchwork >> has it in accepted state and Geert has been asking if it would go in 2.6.29. >> >> Any idea what is up with that one? > >This isn't a regression is it ? so it's a bit late now, have you checked It's a regression from 2.6.28, yes. See: http://ozlabs.org/pipermail/linuxppc-dev/2009-February/067914.html and http://patchwork.ozlabs.org/patch/21527/ (note the Accepted state) >if it's in my next or test branch ? I would have though it would have >gone through your tree, maybe I missed it some way. I can't find it in your tree anywhere. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Thu, 2009-02-26 at 15:46 -0500, Josh Boyer wrote: > It's a regression from 2.6.28, yes. See: > > http://ozlabs.org/pipermail/linuxppc-dev/2009-February/067914.html > > and > > http://patchwork.ozlabs.org/patch/21527/ > > (note the Accepted state) > > >if it's in my next or test branch ? I would have though it would have > >gone through your tree, maybe I missed it some way. > > I can't find it in your tree anywhere. That's weird... I wonder what happened. Accepted state normally means it has been merged. I'll stick it in. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC v2] virtio: add virtio-over-PCI driver
On Thu, Feb 26, 2009 at 09:37:14PM +0100, Arnd Bergmann wrote:
> On Thursday 26 February 2009, Ira Snyder wrote:
> > On Thu, Feb 26, 2009 at 05:15:27PM +0100, Arnd Bergmann wrote:
> >
> > I think so too. I was just getting something working, and thought it
> > would be better to have it "out there" rather than be working on it
> > forever. I'll try to break things up as I have time.
>
> Ok, perfect!
>
> > For the "libraries", would you suggest breaking things into seperate
> > code files, and using EXPORT_SYMBOL_GPL()? I'm not very familiar with
> > doing that, I've mostly been writing code within the existing device
> > driver frameworks. Or do I need export symbol at all? I'm not sure...
>
> You have both options. When you list each file as a separate module
> in the Makefile, you use EXPORT_SYMBOL_GPL to mark functions that
> get called by dependent modules, but this will work only in one way.
>
> You can also link multiple files together into one module, although
> it is less common to link a single source file into multiple modules.
>
Ok. I'm more familiar with the EXPORT_SYMBOL_GPL interface, so I'll do
that. If we decide it sucks later, we'll change it.
> > I always thought you were supposed to use packed for data structures
> > that are external to the system. I purposely designed the structures so
> > they wouldn't need padding.
>
> That would only make sense for structures that are explicitly unaligned,
> like a register layout using
>
> struct my_registers {
> __le16 first;
> __le32 second __attribute__((packed));
> __le16 third;
> };
>
> Even here, I'd recommend listing the individual members as packed
> rather than the entire struct. Obviously if you layout the members
> in a sane way, you don't need either.
>
Ok. I'll drop the __attribute__((packed)) and make sure there aren't
problems. I don't suspect any, though.
> > I mostly don't need it. In fact, the only place I'm using registers not
> > specific to the messaging unit is in the probe routine, where I setup
> > the 1GB window into host memory and setting up access to the guest
> > memory on the PCI bus.
>
> You could add the registers you need for this to the "reg" property
> of your device, to be mapped with of_iomap.
>
> If the registers for setting up this window don't logically fit
> into the same device as the one you already use, the cleanest
> solution would be to have another device just for this and then
> make a function call into that driver to set up the window.
>
The registers are part of the board control registers. They don't fit at
all in the message unit. Doing this in the bootloader seems like a
logical place, but that would require any testers to flash a new U-Boot
image into their mpc8349emds boards.
The first set of access is used to set up a 1GB region in the memory map
that accesses the host's memory. Any reads/writes to addresses
0x8000-0xc000 actually hit the host's memory.
The last access sets up PCI BAR1 to hit the memory from
dma_alloc_coherent(). The bootloader already sets up the window as 16K,
it just doesn't point it anywhere. Maybe this /should/ go into the
bootloader. Like above, it would require testers to flash a new U-Boot
image into their mpc8349emds boards.
> > Now, I wouldn't need to access these registers at all if the bootloader
> > could handle it. I just don't know if it is possible to have Linux not
> > use some memory that the bootloader allocated, other than with the
> > mem=XXX trick, which I'm sure wouldn't be acceptable. I've just used
> > regular RAM so this is portable to my custom board (mpc8349emds based)
> > and a regular mpc8349emds. I didn't want to change anything board
> > specific.
> >
> > I would love to have the bootloader allocate (or reserve somewhere in
> > the memory map) 16K of RAM, and not be required to allocate it with
> > dma_alloc_coherent(). It would save me plenty of headaches.
>
> I believe you can do that through the "memory" devices in the
> device tree, by leaving out a small part of the description of
> main memory, at putting it into the "reg" property of your own
> device.
>
I'll explore this option. I didn't even know you could do this. Is a
driver that requires the trick acceptable for mainline inclusion? Just
like setting up the 16K PCI window, this is very platform specific.
This limits the guest driver to systems which are able to change Linux's
view of their memory somehow. Maybe this isn't a problem.
> > Code complexity only. Also, it was easier to write 80-char lines with
> > something like:
> >
> > vop_get_desc(vq, idx, &desc);
> > if (desc.flags & VOP_DESC_F_NEXT) {
> > /* do something */
> > }
> >
> > Instead of:
> > if (le16_to_cpu(vq->desc[idx].flags) & VOP_DESC_F_NEXT) {
> > /* do something */
> > }
> >
> > Plus, I didn't have to remember how many bits were in each field. I just
> > thought it made everything simpler to understand. Suggestions?
>
> hmm, in this particular case, y
Re: [PATCH v2 net] gianfar : Do right check on num_txbdfree
On Thu, Feb 26, 2009 at 4:25 AM, Rini van Zetten wrote: > This patch fixes a wrong check on num_txbdfree. It could lead to > num_txbdfree become nagative. > Result was that the gianfar stops sending data. > > Changes from first version : > - removed a space between parens (David Millers comment) > - full email address in signed off line > > > Signed-off-by: Rini van Zetten Good catch. Does this solve the bug you reported earlier? Acked-by: Andy Fleming ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] powerpc: oprofile: enable support for ppc750 processors
On Tue, Feb 24, 2009 at 6:09 AM, Octavian Purdila wrote:
> Signed-off-by: Octavian Purdila
> ---
> arch/powerpc/kernel/cputable.c | 6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
> index 923f87a..4e20cfb 100644
> --- a/arch/powerpc/kernel/cputable.c
> +++ b/arch/powerpc/kernel/cputable.c
> @@ -726,6 +726,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
> .cpu_setup = __setup_cpu_750,
> .machine_check = machine_check_generic,
> .platform = "ppc750",
> + .oprofile_cpu_type = "ppc/7450",
> + .oprofile_type = PPC_OPROFILE_G4,
> },
I know this saves you some code, but it seems hacky. It would be
better to modify oprofile to detect the proper cpu type. Also, this
will screw things up if you try to use the different event set that
the 750 has.
Also, one more concern is the long-standing errata which makes this
quite dangerous. All of the versions of the 750 I'm aware of have a
bug where if a Performance Monitor exception occurs within one cycle
of the Decrementer exception, the cpu will lose the ability to return
from the interrupt (SRR0/SRR1 become corrupted). It's possible the
750s you have modified to support oprofile don't have this errata.
Alternatively, we can decide we don't care, as you have to be root to
use oprofile. But this is why I didn't add support for anything
before the 7450.
Andy
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus And here's another little regression fix. For some reason, that one was done and acked ages ago, marked "accepted" in patchwork and never actually merged anywhere ... go figure. The following changes since commit 64e71303e44f3697e4568147caa966de74bdb4fb: Linus Torvalds (1): Merge git://git.kernel.org/.../mason/btrfs-unstable are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Benjamin Herrenschmidt (1): powerpc/44x: Fix address decoding setup of PCI 2.x cells arch/powerpc/sysdev/ppc4xx_pci.c | 17 + 1 files changed, 17 insertions(+), 0 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC v2] virtio: add virtio-over-PCI driver
On Thursday 26 February 2009, Ira Snyder wrote: > On Thu, Feb 26, 2009 at 09:37:14PM +0100, Arnd Bergmann wrote: > > The registers are part of the board control registers. They don't fit at > all in the message unit. Doing this in the bootloader seems like a > logical place, but that would require any testers to flash a new U-Boot > image into their mpc8349emds boards. > > The first set of access is used to set up a 1GB region in the memory map > that accesses the host's memory. Any reads/writes to addresses > 0x8000-0xc000 actually hit the host's memory. > > The last access sets up PCI BAR1 to hit the memory from > dma_alloc_coherent(). The bootloader already sets up the window as 16K, > it just doesn't point it anywhere. Maybe this /should/ go into the > bootloader. Like above, it would require testers to flash a new U-Boot > image into their mpc8349emds boards. Ok, I see. I guess the best option for doing it in Linux then would be to have a board control driver (not sure if this already exists) that exports high-level functions to set up the inbound and outbound windows. > Yeah, virtio doesn't work that way. > > The virtio drivers just call find_vq() with a different index for each > queue they want to use. You have no way of knowing how many queues each > virtio driver will want, unless you go read their source code. > > virtio-net currently uses 3 queues, but we only support the first two. > The third is optional (for now...), and non-symmetric. I mean the part of your driver that calls register_virtio_device() could make the decision, this is the one I was referring to as virtio_net glue because it is the only part that actually needs to know about the features etc. Right now, you just call register_virtio_net from vop_probe(), which is absolutely appropriate for the specific use case. In the most general case though, you would have a user interface on one or both sides that allows a (root) user to trigger the creation of a virtio_net (or other virtio) device with specific characteristics such as MAC address or number of virtqueues. One idea I had earlier was that there could be a special device with just one virtqueue that is always present and that allows you do communicate configuration changes regarding the available devices to the remote VOP driver. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] powerpc: oprofile: enable support for ppc750 processors
On Thu, 2009-02-26 at 16:30 -0600, Andy Fleming wrote: > > I know this saves you some code, but it seems hacky. It would be > better to modify oprofile to detect the proper cpu type. Also, this > will screw things up if you try to use the different event set that > the 750 has. Agreed. Note that Jack Miller (CC) has some patches for the oprofile side. > Also, one more concern is the long-standing errata which makes this > quite dangerous. All of the versions of the 750 I'm aware of have a > bug where if a Performance Monitor exception occurs within one cycle > of the Decrementer exception, the cpu will lose the ability to return > from the interrupt (SRR0/SRR1 become corrupted). It's possible the > 750s you have modified to support oprofile don't have this errata. > Alternatively, we can decide we don't care, as you have to be root to > use oprofile. But this is why I didn't add support for anything > before the 7450. I think we need to advertise it as broken in some way... I -think- the latest batch of IBM 750CL have that bug fixed but I'm not 100% certain. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC v2] virtio: add virtio-over-PCI driver
On Thu, Feb 26, 2009 at 11:34:33PM +0100, Arnd Bergmann wrote: > On Thursday 26 February 2009, Ira Snyder wrote: > > On Thu, Feb 26, 2009 at 09:37:14PM +0100, Arnd Bergmann wrote: > > > > The registers are part of the board control registers. They don't fit at > > all in the message unit. Doing this in the bootloader seems like a > > logical place, but that would require any testers to flash a new U-Boot > > image into their mpc8349emds boards. > > > > The first set of access is used to set up a 1GB region in the memory map > > that accesses the host's memory. Any reads/writes to addresses > > 0x8000-0xc000 actually hit the host's memory. > > > > The last access sets up PCI BAR1 to hit the memory from > > dma_alloc_coherent(). The bootloader already sets up the window as 16K, > > it just doesn't point it anywhere. Maybe this /should/ go into the > > bootloader. Like above, it would require testers to flash a new U-Boot > > image into their mpc8349emds boards. > > Ok, I see. > > I guess the best option for doing it in Linux then would be to have > a board control driver (not sure if this already exists) that exports > high-level functions to set up the inbound and outbound windows. > Nothing like it exists. The OF device tree doesn't even describe these registers. The code in arch/powerpc/sysdev/fsl_pci.c uses some registers near these, but it gets their address by masking the low bits off the addresses from the device tree and adding the offsets of the new registers. Nasty. I'll do this for now: 1) Get the message unit registers from my device tree 2) Encapsulate all use of get_immrbase() to a single function That way it could be easily replaced in the future when something more suitable comes along. > > Yeah, virtio doesn't work that way. > > > > The virtio drivers just call find_vq() with a different index for each > > queue they want to use. You have no way of knowing how many queues each > > virtio driver will want, unless you go read their source code. > > > > virtio-net currently uses 3 queues, but we only support the first two. > > The third is optional (for now...), and non-symmetric. > > I mean the part of your driver that calls register_virtio_device() > could make the decision, this is the one I was referring to > as virtio_net glue because it is the only part that actually needs > to know about the features etc. > > Right now, you just call register_virtio_net from vop_probe(), which > is absolutely appropriate for the specific use case. In the most > general case though, you would have a user interface on one or > both sides that allows a (root) user to trigger the creation of > a virtio_net (or other virtio) device with specific characteristics > such as MAC address or number of virtqueues. > I didn't think about this at all. This driver could be used to boot a (guest) system over NFS, so in that case there isn't a userspace running yet, to allow configuration. This is essentially my use case, though I haven't implemented it yet. Also, I hate designing user interfaces :) Any concrete suggestions on design would be most welcome. > One idea I had earlier was that there could be a special device > with just one virtqueue that is always present and that allows you > do communicate configuration changes regarding the available devices > to the remote VOP driver. > That's an interesting idea that I didn't consider, either. It wouldn't have to be fast, just reliable. When you're doing small transfers, the CPU is just fine. Ira ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PHY not found after migration of gianfar driver to an of_platform_driver
Some more information regarding this board. This is the output of
dtc /proc/device/ree:
I removed all information not relevant to networking
/dts-v1/;
/ {
linux,phandle = <0x100>;
#size-cells = <0x1>;
#address-cells = <0x1>;
compatible = "MPC83xx";
model = "RB600";
soc8...@e000 {
bus-frequency = <0x1>;
reg = <0xe000 0x200>;
ranges = <0x0 0xe000 0x10>;
device_type = "soc";
#interrupt-cells = <0x2>;
#size-cells = <0x1>;
#address-cells = <0x1>;
g...@0 {
reg = <0xc08 0x4>;
device-id = <0x0>;
compatible = "gpio";
device_type = "gpio";
linux,phandle = <0x400>;
};
ether...@24000 {
phy-handle = <0x80001>;
interrupt-parent = <0x700>;
interrupts = <0x20 0x8 0x21 0x8 0x22 0x8>;
mac-address = [00 0c 42 28 de 4f];
reg = <0x24000 0x1000>;
compatible = "gianfar";
model = "TSEC";
device_type = "network";
};
ether...@25000 {
phy-handle = <0x8>;
interrupt-parent = <0x700>;
interrupts = <0x23 0x8 0x24 0x8 0x25 0x8>;
mac-address = [00 0c 42 28 de 4e];
reg = <0x25000 0x1000>;
compatible = "gianfar";
model = "TSEC";
device_type = "network";
};
m...@24520 {
#size-cells = <0x1>;
#address-cells = <0x1>;
linux,phandle = <0x800>;
reg = <0x24520 0x20>;
compatible = "gianfar";
device_type = "mdio";
ethernet-...@1 {
device_type = "ethernet-phy";
reg = <0x1>;
linux,phandle = <0x80001>;
};
ethernet-...@0 {
device_type = "ethernet-phy";
reg = <0x0>;
linux,phandle = <0x8>;
};
};
cpus {
linux,phandle = <0x200>;
#size-cells = <0x0>;
#address-cells = <0x1>;
#cpus = <0x1>;
PowerPC,83...@0 {
linux,boot-cpu;
linux,phandle = <0x201>;
32-bit;
clock-frequency = <0x17d77460>;
timebase-frequency = <0x3f93e10>;
i-cache-size = <0x8000>;
d-cache-size = <0x8000>;
i-cache-line-size = <0x20>;
d-cache-line-size = <0x20>;
reg = <0x0>;
device_type = "cpu";
};
};
I still do not understand why phy_attach fails. Does someone have an
idea or can tell me how to debug this further?
Kind regards,
Michael
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC v2] virtio: add virtio-over-PCI driver
On Friday 27 February 2009, Ira Snyder wrote: > On Thu, Feb 26, 2009 at 11:34:33PM +0100, Arnd Bergmann wrote: > > I guess the best option for doing it in Linux then would be to have > > a board control driver (not sure if this already exists) that exports > > high-level functions to set up the inbound and outbound windows. > > > > Nothing like it exists. The OF device tree doesn't even describe these > registers. The code in arch/powerpc/sysdev/fsl_pci.c uses some registers > near these, but it gets their address by masking the low bits off the > addresses from the device tree and adding the offsets of the new > registers. Nasty. > > I'll do this for now: > 1) Get the message unit registers from my device tree > 2) Encapsulate all use of get_immrbase() to a single function > > That way it could be easily replaced in the future when something more > suitable comes along. Ok. However, I don't expect this to get fixed magically. Ideally, you would start a new file for the board control in arch/powerpc/sysdev and export the function from there, otherwise you do it the way you suggested. Then we can tell the fsl_pci and other people to use the same method and source file to access the board control. > > I didn't think about this at all. This driver could be used to boot a > (guest) system over NFS, so in that case there isn't a userspace running > yet, to allow configuration. This is essentially my use case, though I > haven't implemented it yet. > > Also, I hate designing user interfaces :) Any concrete suggestions on > design would be most welcome. Don't worry about it for now, just put all the hardcoded virtio_net specific stuff into a file separate from the hardware specific files so that we have a nice kernel level abstraction to build a user abstraction on top of. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/1] Fix 64bit Mapple Host Bridge Address and Size Nodes
2009/2/27 Benjamin Herrenschmidt
> On Thu, 2009-02-26 at 18:08 +0800, Tiejun Chen wrote:
> > In the DTB tree created by firmware on Maple 64bit target, host bridge
> > parent
> > node has specified both of these two properties to be 2. However, the
> > actual
> > "cell" value for host bridge node is 1. we have to provide one fixup
> > function.
>
> Hi !
>
> Thanks for the patch. A couple of things tho: Can you make it a bit
> more robust by properly checking the board type first ?
That is ATCA 6101 and the following is from the MOTLoad firmware.
--
Copyright Motorola Inc. 1999-2006, All Rights Reserved
MOTLoad RTOS Version 2.0, PAL Version 1.1 RM01
Built on Tue Jun 13 10:31:56 EDT 2006 by q3316c
bbs 2.0 build 38
Part Number =01-W3930F04A
Serial Number=001
MPU-Type =PPC970FX DD3.1
MPU-Int Clock Speed =1800MHz
Memory Speed =333MHz
PCI bus instance 1 =64 bit, 100 MHz, PCI-X
PCI bus instance 2 =64 bit, 100 MHz, PCI-X
PCI bus instance 3 =64 bit, 100 MHz, PCI-X
PCI bus instance 4 =64 bit, 100 MHz, PCI-X
PCI bus instance 5 =32 bit, 33 MHz, PCI
HT Link instance 1 =16 bit, 400 MHz
HT Link instance 2 = 8 bit, 600 MHz
HT Link instance 3 = 8 bit, 200 MHz
MOTLoad FLASH Image =FLASH Bank A
Local Memory Found =08000 (&2147483648)
User Download Buffer =0611A5000:0613A4FFF
--
Here is some board information I can know:
--
Board revision: 01
Boot loader version: 2.0
Silicon revision: 3.1 (pvr 003c 0301)
--
>
> Also, what is this "hostbridge" node ? ie, what does it represent ?
That means IBM CPC925 system controller resided on the ATCA 6101.
>
> Can you send me a full dump of /proc/device-tree from the machine ?
> (ie tar it up)
>
See the attachment.
>
> Finally, it looks like your patch was whitespace damaged by your mailer.
>
After you confirm others is ok I will send v2 improved patch.
Thanks & Best Regards
Tiejun
>
> Cheers,
> Ben.
>
>
> > Signed-off-by: Tiejun Chen
> > ---
> > arch/powerpc/kernel/prom_init.c | 42
> > +++
> > 1 files changed, 42 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/prom_init.c
> > b/arch/powerpc/kernel/prom_init.c
> > index 2445945..9cd23b6 100644
> > --- a/arch/powerpc/kernel/prom_init.c
> > +++ b/arch/powerpc/kernel/prom_init.c
> > @@ -1948,8 +1948,49 @@ static void __init
> > fixup_device_tree_maple(void)
> >prom_setprop(isa, name, "ranges",
> >isa_ranges, sizeof(isa_ranges));
> > }
> > +
> > +/* On Maple 64bit target host bridge parent node has specified
> > address and
> > + * size properties to be 2. But the actual "cell" value for host
> > bridge node
> > + * is 1 since early MOTLoad internal bug. */
> > +static void __init fixup_device_tree_maple_hb(void)
> > +{
> > + phandle hb;
> > + u32 hb_ranges[4];
> > + u32 size_cell, addr_cell;
> > + struct prom_t *_prom = &RELOC(prom);
> > + char *name;
> > +
> > + name = "/hostbri...@f800";
> > + hb = call_prom("finddevice", 1, 1, ADDR(name));
> > + if (!PHANDLE_VALID(hb))
> > + return;
> > +
> > + if (prom_getproplen(hb, "reg") != 8)
> > + return;
> > +
> > + if (prom_getprop(hb, "reg", hb_ranges, (sizeof(hb_ranges))/2)
> > + == PROM_ERROR)
> > + return;
> > +
> > + prom_getprop(_prom->root, "#address-cells", &addr_cell,
> > sizeof(addr_cell));
> > + prom_getprop(_prom->root, "#size-cells", &size_cell,
> > sizeof(size_cell));
> > +
> > + if ((addr_cell != 2) || (size_cell != 2) ||
> > + (hb_ranges[0] != 0xf800))
> > + return;
> > +
> > + prom_printf("Fixing up bogus HOSTBRIDGE reg on
> > Maple/Apache...\n");
> > +
> > + hb_ranges[3] = hb_ranges[1];
> > + hb_ranges[1] = hb_ranges[0];
> > + hb_ranges[0] = hb_ranges[2] = 0;
> > + prom_setprop(hb, name, "reg",
> > + hb_ranges, sizeof(hb_ranges));
> > +}
> > +
> > #else
> > #define fixup_device_tree_maple()
> > +#define fixup_device_tree_maple_hb()
> > #endif
> >
> > #ifdef CONFIG_PPC_CHRP
> > @@ -2190,6 +2231,7 @@ static void __init fixup_device_tree_efika(void)
> > static void __init fixup_device_tree(void)
> > {
> >fixup_device_tree_maple();
> > + fixup_device_tree_maple_hb();
> >fixup_device_tree_chrp();
> >fixup_device_tree_pmac();
> >fixup_device_tree_efika();
> > --
> > 1.5.6
> >
> >
> >
>
>
maple.dts.gz
Description: GNU Zip compressed data
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Can't load module spi_mpc83xx : No such device
Hi all,
I'm using linux version 2.6.29-rc5.
I've compiled the SPI diver (spi_mpc83xx.c) as a module, but it fails the load
with a "No such device" error.
I've managed to track it down to platform_driver_probe() in
drivers/base/platform.c
which returns -ENODEV because a device list is empty.
Not sure what I'm doing wrong.
Part of my device tree is as follows:
soc8...@e000 {
...
s...@7000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,spi";
reg = <0x7000 0x1000>;
interrupts = <0x10 0x8>;
interrupt-parent = < &ipic >;
m25...@2 {
compatible = "m25p80";
spi-max-frequency = <2500>;
reg = <2>;
};
};
...
};
Thanks
D
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add MPC52xx simple interrupt GPIO support
Hi Roman,
Thanks for this work. Comments below.
On Thu, Feb 26, 2009 at 7:24 AM, Roman Fietze
wrote:
> Hello,
>
> I've got a target derived from the Lite5200 that needs to use simple
> interrupt GPIO pins. I created a patch to support this kind of GPIO.
>
> I would need your opinion and like to hear any criticism. Esp. the
> facts that I ad to split up struct mpc52xx_gpio and that the GPIO
> numbering might get mixed up concern me.
While I understand why this patch is written the way it is, I don't
think it is the right approach.
This patch changes the mpc5200 gpio binding to adapt to a Linux
internal implementation detail. Specifically, the of_mm
infrastructure only allows a 1:1 relationship between a 'struct
of_gpio_chip' and a 'struct gpio_chip'. When working with device
trees, this is the wrong way around. The device tree describes the
hardware, not the Linux implementation details.
An argument could be made that the current binding isn't ideal and
that it would be better to split the simple, interrupt and output-only
gpio pins into separate nodes, but that pretty much comes down to a
matter of opinion as the existing binding describes the hardware just
fine. I'm actually of the opinion that it would be better to fewer
gpio nodes, not more, by merging the simple and wakeup pins into a
single node, but what's done is done and there is no technical reason
for changing the current binding.
So, that leaves the problem working with the of_mm infrastructure. I
think the correct solution is to modify of_gpio_chip to hold an array
of struct gpio_chip and to change of_gpio_simple_xlate() to handle it.
Maybe something like:
struct of_gpio_chip {
int gpio_cells;
int (*xlate)(struct of_gpio_chip *of_gc, struct device_node *np,
const void *gpio_spec, enum of_gpio_flags *flags);
struct gpio_chip gc[1];
};
and add an allocator function that takes care of allocating the
required size of the gc array. There are details to work out of
course, but I thing this would be the more robust solution.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpc52xx: add Phytec phyCORE-MPC5200B-IO board (pcm032)
Thanks for the patch Wolfram. Comments below.
On Wed, Feb 25, 2009 at 8:32 AM, Wolfram Sang wrote:
> Signed-off-by: Wolfram Sang
> ---
> arch/powerpc/boot/dts/pcm032.dts | 391 +++
> arch/powerpc/configs/52xx/pcm032_defconfig | 1394
> ++
Do you really need a separate defconfig for this board? Can it be
merged with an existing defconfig?
> arch/powerpc/platforms/52xx/Kconfig | 1 +
> arch/powerpc/platforms/52xx/mpc5200_simple.c | 3 +-
> 4 files changed, 1788 insertions(+), 1 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/pcm032.dts
> create mode 100644 arch/powerpc/configs/52xx/pcm032_defconfig
>
> diff --git a/arch/powerpc/boot/dts/pcm032.dts
> b/arch/powerpc/boot/dts/pcm032.dts
> new file mode 100644
> index 000..ebaf660
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/pcm032.dts
> @@ -0,0 +1,391 @@
> [...]
> + l...@e400 {
As per generic names recommended practice, this node name should
really be something like "localbus {", and you should drop the node
address since the local bus doesn't really have an address.
> + compatible = "fsl,lpb";
Ideally should be: compatible =
"fsl,mpc5200b-lpb","fsl,mpc5200-lpb","simple-bus";
I know that 'fsl,lpb' has been used in the past, but it is far to
generic and isn't good practice. The 'simple-bus' property ensures
that the bus will get probed.
> + ranges = <0x0 0xe400 0x0800>;
> + #size-cells = <1>;
> + #address-cells = <1>;
Should be #address-cells = <2>;. First cell is CS#, second cell is
offset from base of CS. This is particularly important if the LPB
FIFO is ever used with any of this hardware.
motionpro.dts is a good example of what it should look like.
> +
> + /* free chipselect */
> + c...@ {
> + compatible = "free";
Very bad! If you want to show available chip selects, then add some
commented out sections as examples. Creating nodes with the extremely
generic compatible value of "free" is just asking for trouble
(especially when someone new sees the example and decides to use the
same thing in their driver).
> + l...@f700 {
Another localbus node? Why can't a single localbus node hold all the
child nodes?
> + compatible = "fsl,lpb";
> + ranges = <0x0 0xf700 0x0900>;
> + #size-cells = <1>;
> + #address-cells = <1>;
> +
> + fp...@00e0 {
> + compatible = "fpga1";
Too generic. Be board specific.
> + reg = <0x00e0 0x0200>;
> + bank-width = <4>;
> + };
> +
> + fp...@02e0 {
> + compatible = "fpga2";
Ditto
Otherwise, the rest of the patch looks good to me.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/5200: Add 'simple-bus' to the of_platform probe list.
From: Grant Likely
To better match the ePAPR specification, device nodes which claim
"simple-bus" compatibility should be probed by default.
Signed-off-by: Grant Likely
---
arch/powerpc/platforms/52xx/mpc52xx_common.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c
b/arch/powerpc/platforms/52xx/mpc52xx_common.c
index 98367a0..e9d2cf6 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -28,9 +28,10 @@ static struct of_device_id mpc52xx_xlb_ids[] __initdata = {
static struct of_device_id mpc52xx_bus_ids[] __initdata = {
{ .compatible = "fsl,mpc5200-immr", },
{ .compatible = "fsl,mpc5200b-immr", },
- { .compatible = "fsl,lpb", },
+ { .compatible = "simple-bus", },
/* depreciated matches; shouldn't be used in new device trees */
+ { .compatible = "fsl,lpb", },
{ .type = "builtin", .compatible = "mpc5200", }, /* efika */
{ .type = "soc", .compatible = "mpc5200", }, /* lite5200 */
{}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to bring up fs_enet on 2.6.27?
On Wed, Feb 25, 2009 at 8:25 PM, Mike Ditto wrote: > Daniel Ng wrote: >>> f0010d40:00 not found >>> eth0: Could not attach to PHY > These messages are typical of having the wrong GPIO pins in the mdio > node or the wrong MDIO address (reg property) in the ethernet-phy node. > >>> Currently, our PHY >>> attributes eg. 'auto-negotiate' are not changeable, so we aren't >>> actually using MDC+MDIO even though the MDC+MDIO lines exist. > > The driver definitely tries to talk to the PHY using the GPIO pins > and address specified and if it doesn't respond, it won't attach. > Thanks Mike. I pulled out the PHY-dependancies in the fs-enet code and I'm *almost* there! Here's the relevant boot output with some additional debug: fs_init(): start fs_enet_probe() start fs_enet_get_stats() start eth0: fs_enet: 7e:13:12:53:a1:75 fs_enet_probe(): registered. dev: eth0 ... dev_open(): calling dev_activate for dev: lo dev_open(): finishing for dev: lo fs_enet_open(): start. dev: eth0 dev_open(): calling dev_activate for dev: eth0 dev_open(): finishing for dev: eth0 fs_enet_get_stats() IP-Config: Complete: device=eth0, addr=192.168.1.75, mask=255.255.255.0, gw=255.255.255.255, host=xxx, domain=, nis-domain=(none), bootserver=192.168.1.133, rootserver=192.168.1.133, rootpath= Looking up port of RPC 13/2 on 192.168.1.133 dev_hard_start_xmit(): start. dev: lo dev_hard_start_xmit(): about to call c015baa0 dev_hard_start_xmit(): start. dev: lo dev_hard_start_xmit(): about to call c015baa0 rpcbind: server 192.168.1.133 not responding, timed out As you can see from the above, the NFS client tries to contact the server on the lo interface rather than eth0. This is despite IP-Config reporting 'Complete' for eth0. If I set the Gateway parameter for the NFS client to 192.168.1.133 I get this: fs_init(): start fs_enet_probe() start fs_enet_get_stats() start eth0: fs_enet: 7e:13:12:53:a1:75 fs_enet_probe(): registered. dev: eth0 ... dev_open(): calling dev_activate for dev: lo dev_open(): finishing for dev: lo fs_enet_open(): start. dev: eth0 dev_open(): calling dev_activate for dev: eth0 dev_open(): finishing for dev: eth0 fs_enet_get_stats() IP-Config: Gateway not on directly connected network. Looking up port of RPC 13/2 on 192.168.1.133 dev_hard_start_xmit(): start. dev: lo dev_hard_start_xmit(): about to call c015baa0 dev_hard_start_xmit(): start. dev: lo dev_hard_start_xmit(): about to call c015baa0 rpcbind: server 192.168.1.133 not responding, timed out -IP-Config complains the Gateway (192.168.1.133) is not on a directly-connected network, even though the IP address of eth0 is 192.168.1.75/24. So this implies eth0 is not 100% up. Would someone be able to suggest why this is so? What else could I do to check the state of eth0? Cheers, Daniel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
