Re: net_device_ops support in bridging and fec_mpc52xx.c
I must have made a mistake when I tested the previous patch, I
discovered later it still had errors:
- I had accidentally removed the base address in the fec_mpc52xx driver.
- The priv-phydev pointer was sometimes not initialized (NULL) but
still passed by the fec_mpc52xx driver, this pointer is then used
unchecked by the eth_tool_* functions (used by bridging to determine
port priority). As far as I see this depends on whether
mpc52xx_fec_open (or mpc52xx_fec_close) is called which in turn call
mpc52xx_init_phy to initialize priv-phydev. My work around checks the
priv-phydev pointer in the fec_mpc52xx driver and returns -ENODEV to
indicate there's no physical device. Big chance this is not the right
way to handle the problem, but it works, hopefully someone with some
more fundamental Linux network driver experience can pick this up or
give me some hints on this.
At least bridging now works on my board in combination with the
fec_mpc52xx driver.
ifconfig eth0 0.0.0.0 down
ifconfig eth1 0.0.0.0 down
brctl addbr br0
brctl setfd br0 0
brctl stp br0 off
ifconfig br0 192.168.1.30 down
ifconfig br0 up
brctl addif br0 eth0
ifconfig eth0 up
brctl addif br0 eth1
ifconfig eth1 up
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index cd8e98b..e228973 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -847,24 +847,40 @@ static void mpc52xx_fec_get_drvinfo(struct
net_device *dev,
static int mpc52xx_fec_get_settings(struct net_device *dev, struct
ethtool_cmd *cmd)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+
+ if (!priv-phydev)
+ return -ENODEV;
+
return phy_ethtool_gset(priv-phydev, cmd);
}
static int mpc52xx_fec_set_settings(struct net_device *dev, struct
ethtool_cmd *cmd)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+
+ if (!priv-phydev)
+ return -ENODEV;
+
return phy_ethtool_sset(priv-phydev, cmd);
}
static u32 mpc52xx_fec_get_msglevel(struct net_device *dev)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+
+ if (!priv-phydev)
+ return 0;
+
return priv-msg_enable;
}
static void mpc52xx_fec_set_msglevel(struct net_device *dev, u32 level)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+
+ if (!priv-phydev)
+ return;
+
priv-msg_enable = level;
}
@@ -882,12 +898,31 @@ static int mpc52xx_fec_ioctl(struct net_device
*dev, struct ifreq *rq, int cmd)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+ if (!priv-phydev)
+ return -ENODEV;
+
return mpc52xx_fec_phy_mii_ioctl(priv, if_mii(rq), cmd);
}
/* */
/* OF Driver*/
/* */
+static const struct net_device_ops mpc52xx_fec_netdev_ops = {
+ .ndo_open = mpc52xx_fec_open,
+ .ndo_stop = mpc52xx_fec_close,
+ .ndo_start_xmit = mpc52xx_fec_hard_start_xmit,
+ .ndo_tx_timeout = mpc52xx_fec_tx_timeout,
+ .ndo_get_stats = mpc52xx_fec_get_stats,
+ .ndo_set_multicast_list = mpc52xx_fec_set_multicast_list,
+ .ndo_validate_addr = eth_validate_addr,
+ .ndo_set_mac_address= mpc52xx_fec_set_mac_address,
+ .ndo_do_ioctl = mpc52xx_fec_ioctl,
+
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = mpc52xx_fec_poll_controller,
+#endif
+};
+
static int __devinit
mpc52xx_fec_probe(struct of_device *op, const struct of_device_id *match)
@@ -929,20 +964,10 @@ mpc52xx_fec_probe(struct of_device *op, const
struct of_device_id *match)
return -EBUSY;
/* Init ether ndev with what we have */
- ndev-open = mpc52xx_fec_open;
- ndev-stop = mpc52xx_fec_close;
- ndev-hard_start_xmit = mpc52xx_fec_hard_start_xmit;
- ndev-do_ioctl = mpc52xx_fec_ioctl;
ndev-ethtool_ops = mpc52xx_fec_ethtool_ops;
- ndev-get_stats = mpc52xx_fec_get_stats;
- ndev-set_mac_address = mpc52xx_fec_set_mac_address;
- ndev-set_multicast_list = mpc52xx_fec_set_multicast_list;
- ndev-tx_timeout= mpc52xx_fec_tx_timeout;
ndev-watchdog_timeo= FEC_WATCHDOG_TIMEOUT;
ndev-base_addr = mem.start;
-#ifdef CONFIG_NET_POLL_CONTROLLER
- ndev-poll_controller = mpc52xx_fec_poll_controller;
-#endif
+ ndev-netdev_ops = mpc52xx_fec_netdev_ops;
priv-t_irq = priv-r_irq = ndev-irq = NO_IRQ; /* IRQ are free for now
*/
On Wed, Feb 18, 2009 at 10:48 PM, David Miller da...@davemloft.net wrote:
From: Henk Stegeman henk.stege...@gmail.com
Date: Wed, 18 Feb 2009 11:41:14 +0100
Please CC: netdev, now added, on all
Re: [git pull] for both tip and powerpc
* Steven Rostedt rost...@goodmis.org wrote: Ingo and Benjamin, As discussed, I made a branch called mainline/function-graph-tracer based off of Linus's commit: commit d2f8d7ee1a9b4650b4e43325b321801264f7c37a Author: Linus Torvalds torva...@linux-foundation.org Date: Fri Feb 13 15:31:30 2009 -0800 Linux 2.6.29-rc5 and cherry picked the below change. I added Ingo's Acked-by as well. If both of you pull this change in (assuming both trees are already based off of Linus's 2.6.29-rc5) then there should be no conflicts when this gets merged back to Linus's tree. I will not touch this branch again, until it is officially in mainline. Please pull the latest mainline/function-graph tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git mainline/function-graph Steven Rostedt (1): tracing/function-graph-tracer: make arch generic push pop functions arch/x86/include/asm/ftrace.h| 25 --- arch/x86/kernel/dumpstack.c |1 + arch/x86/kernel/ftrace.c | 75 +- include/linux/ftrace.h | 24 +++ kernel/trace/trace_functions_graph.c | 75 ++ 5 files changed, 101 insertions(+), 99 deletions(-) Pulled into tip:tracing/function-graph-tracer, thanks Steve! Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC v1] virtio: add virtio-over-PCI driver
On Thursday 19 February 2009 03:08:35 Ira Snyder wrote: On Wed, Feb 18, 2009 at 05:13:03PM +1030, Rusty Russell wrote: don't restrict yourself to 32 feature bits (only PCI does this, and they're going to have to hack when we reach feature 32). There isn't any problem adding more feature bits. Do you think 128 bits is enough? Probably. We have unlimited bits in lguest and s390, but 128 is reasonable for the forseeable future (if not, you end up using bit 128 to mean look somewhere else for the rest of the bits). How about prepending a 4 byte length on the host buffers? Allows host to specify length (for host-guest), and guest writes it to allow truncated buffers on guest-host. That won't allow you to transfer *more* than one buffersize to the host, but you could use a different method (perhaps the 4 bytes indicates the *total* length?). I don't understand how this will help. I looked at virtio_net's implemention with VIRTIO_NET_F_MRG_RXBUF, which seems like it could really help performance. The problems with that are: 1) virtio_net doesn't write the merged header's num_buffers field 2) virtio_net doesn't actually split packets in xmit ... I'm using two instances of virtio_net to talk to each other, rather than a special userspace implementation like lguest and kvm use. Is this a good approach? Well, virtio in general is guest-host asymmetric. I originally explored symmetry, but it didn't seem to offer any concrete advantages, so we didn't require it. You aren't actually directly connecting two guests, are you? So this is just a simplification for your implementation? You could always add a VIRTIO_NET_F_MRG_TXBUF which did what you want, but note that symmetry breaks down for other virtio uses, too: block definitely isn't symmetric of course, but I haven't audited the others. So I'd recommend asymmetry; hack your host to understand chained buffers. Cheers, Rusty. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ehea: Fix memory hotplug handling
Added missing set_bit() to disable data transfer when a memchange notification is handled Signed-off-by: Thomas Klein tkl...@de.ibm.com --- diff -Nurp -X dontdiff linux-2.6.29-rc4/drivers/net/ehea/ehea.h patched_kernel/drivers/net/ehea/ehea.h --- linux-2.6.29-rc4/drivers/net/ehea/ehea.h2009-02-18 16:59:54.0 +0100 +++ patched_kernel/drivers/net/ehea/ehea.h 2009-02-18 17:01:12.0 +0100 @@ -40,7 +40,7 @@ #include asm/io.h #define DRV_NAME ehea -#define DRV_VERSIONEHEA_0098 +#define DRV_VERSIONEHEA_0099 /* eHEA capability flags */ #define DLPAR_PORT_ADD_REM 1 diff -Nurp -X dontdiff linux-2.6.29-rc4/drivers/net/ehea/ehea_main.c patched_kernel/drivers/net/ehea/ehea_main.c --- linux-2.6.29-rc4/drivers/net/ehea/ehea_main.c 2009-02-18 16:59:54.0 +0100 +++ patched_kernel/drivers/net/ehea/ehea_main.c 2009-02-18 17:01:12.0 +0100 @@ -3517,12 +3517,14 @@ static int ehea_mem_notifier(struct noti /* Readd canceled memory block */ case MEM_ONLINE: ehea_info(memory is going online); + set_bit(__EHEA_STOP_XFER, ehea_driver_flags); if (ehea_add_sect_bmap(arg-start_pfn, arg-nr_pages)) return NOTIFY_BAD; ehea_rereg_mrs(NULL); break; case MEM_GOING_OFFLINE: ehea_info(memory is going offline); + set_bit(__EHEA_STOP_XFER, ehea_driver_flags); if (ehea_rem_sect_bmap(arg-start_pfn, arg-nr_pages)) return NOTIFY_BAD; ehea_rereg_mrs(NULL); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Regarding irq_of_parse_and_map
Because dtc will generate phandles automatically when you reference the node with the operator. Yes the same statement I found in dts-bindings for gpio txt, sorry I missed it somehow ... Do you want your changes to ever make it into the upstream kernel? Yes I would like to do that ... but the reason I asked is as it is my first try so I am thinking that I will edit the same file and do it in the same way ofcourse I will follow for device node gpio-controller the new apporach and later if it works then I will create new dts with upstream Linux base ... Now I have created the mpc8313erdb.dts with gpio-controller device node. I would like to ask that now I should compile it with dtc and generate dtb and I should load this dtb on board/target, Right ? ? ? please correct me if I am wrong ... Also is it possible to compile device tree on Linux host and genreate dtb for powerpc ? ? ? If yes, then how ? ? ? please let me know ... thanks ... Before I tried to generate virtual irq using irq_create_mapping and I got the same number as hw_irq_no i.e. 74 as virtual irq. Also the entry was made in proc/interrupts and trigger was 8 (Level). But when I tried to interrupt and the handler was never called ? ? ? Was it because of gpio device node missing in device tree ? ? ? please let me know ... thanks ... Kindly please acknowledge ... thank you ... Kind Regards, Vijay Nikam On 2/18/09, Scott Wood scottw...@freescale.com wrote: On Wed, Feb 18, 2009 at 05:31:34PM +0530, Vijay Nikam wrote: Don't specify this explicitly. Please base new development off of the device tree that is in upstream Linux, not the very old tree in your BSP. May I know the reason why I should not specify it explicitly ? ? ? Because dtc will generate phandles automatically when you reference the node with the operator. Also what would be the problem if I do in the same way as it is given in BSP mpc8313erdb.dts ? ? ? Do you want your changes to ever make it into the upstream kernel? And should I use gpio-controller as a gpio device node ? ? ? Yes, the node should label itself as a gpio controller. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
BUG: MAX_STACK_TRACE_ENTRIES too low!
When running 2.6.29-rc5+ on PS3 (ppc64), I got the following BUG once during bootup: | Freeing unused kernel memory: 3436k freed | BUG: MAX_STACK_TRACE_ENTRIES too low! | turning off the locking correctness validator. | Call Trace: | [c6e1b640] [c000f850] .show_stack+0x6c/0x16c (unreliable) | [c6e1b6f0] [c007cf6c] .save_trace+0xe0/0x108 | [c6e1b780] [c007d058] .add_lock_to_list+0xc4/0x124 | [c6e1b830] [c00816d0] .__lock_acquire+0x13c4/0x17c8 | [c6e1b930] [c0081b78] .lock_acquire+0xa4/0xec | [c6e1b9f0] [c03be034] ._spin_lock+0x34/0x58 | [c6e1ba80] [c00d3e40] .kmem_cache_free+0x84/0x1a8 | [c6e1bb30] [c01f9abc] .idr_remove+0x214/0x248 | [c6e1bbf0] [c002867c] .destroy_context+0x34/0x64 | [c6e1bc80] [c005008c] .__mmdrop+0x4c/0x7c | [c6e1bd10] [c004de90] .finish_task_switch+0xec/0x14c | [c6e1bdb0] [c004e6fc] .schedule_tail+0x2c/0xa0 | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc | [c6e1be30] [c0007738] .ret_from_fork+0x4/0xcc (There are 65 call trace lines) After that the system continued. 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
Re: [PATCH v2] Configure PSC4 and PSC5 as UART.
Hi Grant, Could you tell me when you are going to apply this patch and Defconfig for mpc5200 updates patch into your repository? Thanks, Grzesiek ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Configure PSC4 and PSC5 as UART.
On Thu, Feb 19, 2009 at 7:09 AM, Grzegorz Bernacki g...@semihalf.com wrote: Hi Grant, Could you tell me when you are going to apply this patch and Defconfig for mpc5200 updates patch into your repository? soon. Busy putting out another fire at the moment, but I'll pick it up soon. 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: New cpu type shows up as unknown even when logical PVR is recognized
On Sun, 2009-02-15 at 01:00 +1100, Michael Ellerman wrote:
On Fri, 2009-02-13 at 14:45 -0600, Dave Kleikamp wrote:
When identify_cpu() is called a second time with a logical PVR, it only
copies a subset of the cpu_spec structure to avoid overwriting the
performance monitor fields that were initialized based on the real PVR.
If the real PVR is not recognized, the structure is initialized with
default data in which the pvr_mask field is zero. Overriding the default
definition with the one based on the logical PVR does not update the
pvr_mask field. Since the pvr_mask field remains zero, show_cpuinfo()
reports the cpu as unknown.
identify_cpu() should update the pvr_mask, so that show_cpuinfo() reports
the logical cpu name, as it would if the kernel recognized the real PVR.
For completeness, this patch also updates pvr_value, although its only
use appears to be in booke_wdt_init() setting ident.firmware_version. I'm
not sure which value (the real or logical) is the most useful here, if it
matters at all.
Signed-off-by: Dave Kleikamp sha...@linux.vnet.ibm.com
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 923f87a..a216fad 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1780,6 +1780,8 @@ struct cpu_spec * __init identify_cpu(unsigned long
offset, unsigned int pvr)
* performance monitor fields.
*/
if (t-num_pmcs !s-num_pmcs) {
+ t-pvr_mask = s-pvr_mask;
+ t-pvr_value = s-pvr_value;
t-cpu_name = s-cpu_name;
t-cpu_features = s-cpu_features;
t-cpu_user_features = s-cpu_user_features;
Seems like we'd be better off copying the whole structure, and then
putting back the performance monitor fields. So we don't end up with
another bug if something's added to struct cpu_spec.
I feel that may be a bit of overkill, but I don't feel strongly either
way. I'd like the patch to be picked up in one fashion or another.
Thanks,
Shaggy
--
David Kleikamp
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Newby trying to get Ethernet going on MPC83xx series device.
On Thu, Feb 19, 2009 at 12:58 AM, Dushara Jayasinghe
dusha...@optiscan.com wrote:
I based my board specific file on mpc834x_itx.c which had
static struct of_device_id __initdata mpc834x_itx_ids[] = {
{ .compatible = fsl,pq2pro-localbus, },
{ .compatible = simple-bus, },
{},
};
Don't know if this is broken?
Actually, it's your device tree that's broken. The above is the right
way to do it. The other way:
static struct of_device_id mpc834x_ids[] = {
{ .type = soc, },
{ .compatible = soc, },
{ .compatible = simple-bus, },
{},
};
is the old way. You're missing a compatible=simple-bus in your device tree.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/83xx: Do not configure or probe disabled FSL DR USB controllers
On MPC837X CPUs Dual-Role USB isn't always available (for example DR USB pins can be muxed away to eSDHC). U-Boot adds status = disabled property into the DR USB nodes to indicate that we must not try to configure or probe Dual-Role USB, otherwise we'll break eSDHC support on targets with MPC837X CPUs. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- arch/powerpc/platforms/83xx/usb.c |3 ++- arch/powerpc/sysdev/fsl_soc.c |4 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/platforms/83xx/usb.c b/arch/powerpc/platforms/83xx/usb.c index cc99c28..11e1fac 100644 --- a/arch/powerpc/platforms/83xx/usb.c +++ b/arch/powerpc/platforms/83xx/usb.c @@ -14,6 +14,7 @@ #include linux/stddef.h #include linux/kernel.h #include linux/errno.h +#include linux/of.h #include asm/io.h #include asm/prom.h @@ -210,7 +211,7 @@ int mpc837x_usb_cfg(void) int ret = 0; np = of_find_compatible_node(NULL, NULL, fsl-usb2-dr); - if (!np) + if (!np || !of_device_is_available(np)) return -ENODEV; prop = of_get_property(np, phy_type, NULL); diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c index 18e49ef..afe8dbc 100644 --- a/arch/powerpc/sysdev/fsl_soc.c +++ b/arch/powerpc/sysdev/fsl_soc.c @@ -22,6 +22,7 @@ #include linux/module.h #include linux/device.h #include linux/platform_device.h +#include linux/of.h #include linux/of_platform.h #include linux/phy.h #include linux/phy_fixed.h @@ -328,6 +329,9 @@ static int __init fsl_usb_of_init(void) struct fsl_usb2_platform_data usb_data; const unsigned char *prop = NULL; + if (!of_device_is_available(np)) + continue; + memset(r, 0, sizeof(r)); memset(usb_data, 0, sizeof(usb_data)); -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC v1] virtio: add virtio-over-PCI driver
On Thu, Feb 19, 2009 at 02:10:08PM +0800, Zang Roy-R61911 wrote: -Original Message- From: linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs.org [mailto:linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs .org] On Behalf Of Ira Snyder Sent: Wednesday, February 18, 2009 6:24 AM To: linux-ker...@vger.kernel.org Cc: linuxppc-dev@ozlabs.org; net...@vger.kernel.org; Rusty Russell; Arnd Bergmann; Jan-Bernd Themann Subject: [RFC v1] virtio: add virtio-over-PCI driver snip diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig index 3dd6294..efcf56b 100644 --- a/drivers/virtio/Kconfig +++ b/drivers/virtio/Kconfig @@ -33,3 +33,25 @@ config VIRTIO_BALLOON If unsure, say M. +config VIRTIO_OVER_PCI_HOST + tristate Virtio-over-PCI Host support (EXPERIMENTAL) + depends on PCI EXPERIMENTAL + select VIRTIO + ---help--- + This driver provides the host support necessary for using virtio + over the PCI bus with a Freescale MPC8349EMDS evaluation board. + + If unsure, say N. + +config VIRTIO_OVER_PCI_FSL + tristate Virtio-over-PCI Guest support (EXPERIMENTAL) + depends on MPC834x_MDS EXPERIMENTAL + select VIRTIO + select DMA_ENGINE + select FSL_DMA + ---help--- + This driver provides the guest support necessary for using virtio + over the PCI bus. + + If unsure, say N. + diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile index 6738c44..f31afaa 100644 --- a/drivers/virtio/Makefile +++ b/drivers/virtio/Makefile @@ -2,3 +2,5 @@ obj-$(CONFIG_VIRTIO) += virtio.o obj-$(CONFIG_VIRTIO_RING) += virtio_ring.o obj-$(CONFIG_VIRTIO_PCI) += virtio_pci.o obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o +obj-$(CONFIG_VIRTIO_OVER_PCI_HOST) += vop_host.o +obj-$(CONFIG_VIRTIO_OVER_PCI_FSL) += vop_fsl.o I suppose we need to build the kernel twice. one for vop_host (on host with pci enabled) and the other is for vop_fsl ( on agent with pci disabled). Is it possible to build one image for both host and agent. We do not scan the pci bus if the controller is configured to agent. You should be able to build a kernel with support for both host and guest operation, and then use the device tree to switch which driver you get. The host driver won't be used without a PCI bus, and the guest driver won't be used without the message unit. Also, is it possible to include mpc85xx architecture? They should be same. There is some code for 85xx in Fresscale BSP. http://www.bitshrine.org/gpp/linux-fsl-2.6.23-MPC8568MDS_PCI_Agent_PCIe_ EP_Drvier.patch I looked at the cardnet driver before I implemented my PCINet driver. I hunch it would be rejected for the same reasons, but maybe not. Also, it makes no use of DMA, which is critical for good transfer speed. Using memcpy() in PCINet gives performance around 10 mbit/sec, which is terrible. I'm sure the driver isn't very hard to port to 85xx, I just don't have any 85xx boards to test with. The driver only directly interacts with the messaging unit, which is a pretty simple piece of hardware. Thanks, Ira ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Gianfar tx-babbling-errors
Kumar, can't think of any. How about adding a BUG_ON() in the tx path to see if the buffer size MTU and re-run your tests. So, here are the checks I've tried in gfar_start_xmit(): BUG_ON(skb-len DEFAULT_RX_BUFFER_SIZE) BUG_ON(skb-len priv-regs-maxfrm) Neither produces a bug check yet ethtool reports non-zero tx-babbling-errors. The last check appears to be the definition of tx-babbling-errors. Is there a transmit path that I have missed? Scott ___ Scott N. Coulter Senior Software Engineer Cyclone Microsystems 370 James Street Phone: 203.786.5536 ext. 118 New Haven, CT 06513-3051 Email: scott.coul...@cyclone.com U.S.A.Web:http://www.cyclone.com ___ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mpc8270 and fs_enet
Turns out the problem was with the PSDMR register. We had a cas latency of 3 and the memory stick required 2. Also, the MPTPR register had a value of 0x1e00 and we changed it to 0x1f00. We use ECC memory sticks. Those 2 changes got rid of the error in the buffer descriptor ready/empty bits. The interesting thing was that our SDRAM memory test passes and there are no errors logged in the TESCR1, TESCR2 or the SDSR registers. Strange problem, and difficult to find. Thought I'd get this out for future reference. On Thu, Jan 29, 2009 at 4:27 PM, James Black jblack...@gmail.com wrote: I thought the same thing. So I verified the memory map. We did have a conflict with the SPI stomping the FCC temp so we moved that. An interesting note is that we drop packets from time to time on the MCC as well due to a similar ready bit problem. The CPM never clears the bit. -- IMMR memory map -- FCC1 Parameters0x8400256 FCC1 Temp buffer 0x9000128 SCC1 Parameters0x8000256 SCC2 Parameters0x8100256 SCC4 Parameters0x8300256 SMC1 Parameters0x 64 SMC2 Parameters0x0040 64 SCC1 Buff Desc 0x0080 64 SCC2 Buff Desc 0x00C0 64 SCC4 Buff Desc 0x0100 64 SPI Param Pointer 0x89FC 2 SPI Parameters0x9000 76 MCC2 Global Param 0x8800128 MCC2 HDLC Param0x2000 8192 MCC2 Extra Param 0xB000 1024 On Thu, Jan 29, 2009 at 4:05 PM, Scott Wood scottw...@freescale.com wrote: James Black wrote: I've got an mpc8270 running the fs_enet v1.0 driver and we are having problems with randomly corrupted tx buffer descriptor ready bits. The CPM never clears the bit. This is a 2.6.19.2 kernel. We have the same kernel with the 8260_io driver (kernel is from the denx ELDK4.2) running on the mpc8250 that works perfect. Is it possible that some other CPM block is configured to use the same DPRAM area that the descriptors are in? -Scott -- Jim Black Senior Software Engineer Aztek Networks, Inc. 2477 55th Street, Suite 202 Boulder, CO 80301 www.azteknetworks.com -- Jim Black Senior Software Engineer Aztek Networks, Inc. 2477 55th Street, Suite 202 Boulder, CO 80301 www.azteknetworks.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: Do not configure or probe disabled FSL DR USB controllers
On Feb 19, 2009, at 10:02 AM, Anton Vorontsov wrote: On MPC837X CPUs Dual-Role USB isn't always available (for example DR USB pins can be muxed away to eSDHC). U-Boot adds status = disabled property into the DR USB nodes to indicate that we must not try to configure or probe Dual-Role USB, otherwise we'll break eSDHC support on targets with MPC837X CPUs. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- arch/powerpc/platforms/83xx/usb.c |3 ++- arch/powerpc/sysdev/fsl_soc.c |4 2 files changed, 6 insertions(+), 1 deletions(-) Mind looking at possibly killing the fsl_soc.c usb code and making the usb a real of-platform driver? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Gianfar tx-babbling-errors
On Feb 19, 2009, at 10:17 AM, Scott Coulter wrote: Kumar, can't think of any. How about adding a BUG_ON() in the tx path to see if the buffer size MTU and re-run your tests. So, here are the checks I've tried in gfar_start_xmit(): BUG_ON(skb-len DEFAULT_RX_BUFFER_SIZE) BUG_ON(skb-len priv-regs-maxfrm) Neither produces a bug check yet ethtool reports non-zero tx-babbling-errors. The last check appears to be the definition of tx-babbling-errors. Is there a transmit path that I have missed? What specific processor rev are you running on? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Gianfar tx-babbling-errors
What specific processor rev are you running on? I've only been running the modified kernel with the added BUG_ON() code on the 8568E processor, but I've seen the errors reported on the 8572E as well. According to the u-boot startup: 8568E, Version: 1.1, (0x807d0011) Core: E500, Version: 2.2 (0x80210022) 8572E, Version: 1.1, (0x80e80011) Core: E500, Version: 3.0 (0x80210030) Scott ___ Scott N. Coulter Senior Software Engineer Cyclone Microsystems 370 James Street Phone: 203.786.5536 ext. 118 New Haven, CT 06513-3051 Email: scott.coul...@cyclone.com U.S.A.Web:http://www.cyclone.com ___ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-mpc: do not allow interruptions when waiting for I2C to complete
On Feb 6, 2009, at 8:00 AM, Timur Tabi wrote: The i2c_wait() function is using wait_event_interruptible_timeout() to wait for the I2C controller to signal that it has completed an I2C bus operation. If the process that causes the I2C operation terminated abruptly, the wait will be interrupted, returning an error. It is better to let the I2C operation finished before the process exits. It is safe to use wait_event_timeout() instead, because the timeout will allow the process to exit if the I2C bus hangs. It's also better to allow the I2C operation to finish, because unacknowledged I2C operations can cause the I2C bus to hang. Signed-off-by: Timur Tabi ti...@freescale.com --- A similar change should probably be done to i2c-cpm.c, and maybe all other I2C drivers. Not many use wait_event_interruptible_timeout(). drivers/i2c/busses/i2c-mpc.c |9 +++-- 1 files changed, 3 insertions(+), 6 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fix the interrupt loss problem on powerpc IPIC(2.6.25-2.6.28)
On Feb 17, 2009, at 11:47 PM, d...@datangmobile.cn d...@datangmobile.cn wrote: From: Da Yu d...@datangmobile.cn Date: Wed, 18 Feb 2009 19:58:20 +0800 Subject: [PATCH] fix the interrupt loss problem on powerpc IPIC (2.6.25-2.6.28) Description: The interrupt pending register is write 1 clear. If there are more than one external interrupts pending at the same time, acking the first interrupt by reading pending register then OR the corresponding bit and write back to pending register will also clear other interrupt pending bits. That will cause loss of interrupt. Signed-off-by: Da Yu d...@datangmobile.cn --- applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: Do not configure or probe disabled FSL DR USB controllers
On Feb 19, 2009, at 10:02 AM, Anton Vorontsov wrote: On MPC837X CPUs Dual-Role USB isn't always available (for example DR USB pins can be muxed away to eSDHC). U-Boot adds status = disabled property into the DR USB nodes to indicate that we must not try to configure or probe Dual-Role USB, otherwise we'll break eSDHC support on targets with MPC837X CPUs. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- arch/powerpc/platforms/83xx/usb.c |3 ++- arch/powerpc/sysdev/fsl_soc.c |4 2 files changed, 6 insertions(+), 1 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC v1] virtio: add virtio-over-PCI driver
On Thu, Feb 19, 2009 at 09:48:04PM +1030, Rusty Russell wrote: On Thursday 19 February 2009 03:08:35 Ira Snyder wrote: On Wed, Feb 18, 2009 at 05:13:03PM +1030, Rusty Russell wrote: don't restrict yourself to 32 feature bits (only PCI does this, and they're going to have to hack when we reach feature 32). There isn't any problem adding more feature bits. Do you think 128 bits is enough? Probably. We have unlimited bits in lguest and s390, but 128 is reasonable for the forseeable future (if not, you end up using bit 128 to mean look somewhere else for the rest of the bits). Ok. There currently isn't an interface to access more than 32 bits anyway. How about prepending a 4 byte length on the host buffers? Allows host to specify length (for host-guest), and guest writes it to allow truncated buffers on guest-host. That won't allow you to transfer *more* than one buffersize to the host, but you could use a different method (perhaps the 4 bytes indicates the *total* length?). I don't understand how this will help. I looked at virtio_net's implemention with VIRTIO_NET_F_MRG_RXBUF, which seems like it could really help performance. The problems with that are: 1) virtio_net doesn't write the merged header's num_buffers field 2) virtio_net doesn't actually split packets in xmit ... I'm using two instances of virtio_net to talk to each other, rather than a special userspace implementation like lguest and kvm use. Is this a good approach? Well, virtio in general is guest-host asymmetric. I originally explored symmetry, but it didn't seem to offer any concrete advantages, so we didn't require it. You aren't actually directly connecting two guests, are you? So this is just a simplification for your implementation? I'm not connecting two guests directly. My eventual setup will have a single x86 computer (the host) and many guest systems. I don't care if the guests cannot communicate between each other, just that they can communicate with the host. I wanted to avoid the extra trip to userspace, so I just connected two instances of virtio_net together. This way you just recv packets in the kernel, rather than jumping to userspace and then using TAP/TUN to drive packets back into the kernel. Plus, I have no idea how I would do a userspace interface. I'd definitely need help. You could always add a VIRTIO_NET_F_MRG_TXBUF which did what you want, but note that symmetry breaks down for other virtio uses, too: block definitely isn't symmetric of course, but I haven't audited the others. I have no need to use virtio_blk, so I pretty much ignored it. In fact, I didn't make any attempt to support RO and WO buffers in the same queue. Virtio_net only uses queues this way, and it was much easier for me to wrap my head around. I don't think that virtio_console is symmetric either, but I haven't really studied it. I was thinking about implementing a virtio_uart which would be symmetric. That would be plenty for my needs. So I'd recommend asymmetry; hack your host to understand chained buffers. It's not that virtio_net doesn't understand chained buffers, it just doesn't write them. Grep for uses of the num_buffers field in virtio_net. It uses them in recv, it just doesn't write them in xmit. It assumes that add_buf() can accept something like: idx address len flags next 0 XXX 12 N1 1 XXX 8000 -2 That would mean it can shove an 8000 byte packet into the virtqueue. It doesn't have any way of knowing to split packets up into chunks, nor how many chunks are available. It assumes that the receiver can read from any address on the sender. I think that this is a perfectly reasonable assumption in a shared memory system, but it breaks down in my case. I cannot just tell the host the packet data is at this address because it cannot do DMA. I have to use the guest system to do DMA. The host has to have pre-allocated the recv memory so the DMA engine has somewhere to copy the data to. Maybe I'm explaining this poorly, but try to think about it this way: 1) Unlike a virtual machine, both systems are NOT sharing memory 2) Both systems have some limited access to each other's memory 3) Both systems can write descriptors equally fast 4) Copying payload data is extremely slow for the host 5) Copying payload data is extremely fast for the guest It would be possible to just alter virtio_net's headers in-flight to set the number of buffers actually used. This would split the 8000 byte packet up into two chunks, 4096 byte and 3904 byte, then set num_buffers to 2. This would add some complexity, but I think it is probably reasonable. Ira ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC v1] virtio: add virtio-over-PCI driver
On Feb 19, 2009, at 12:13 AM, Zang Roy-R61911 wrote: -Original Message- From: linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs.org [mailto:linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs .org] On Behalf Of Kumar Gala Sent: Thursday, February 19, 2009 0:47 AM To: Ira Snyder Cc: Arnd Bergmann; Jan-Bernd Themann; net...@vger.kernel.org; Rusty Russell; linux-ker...@vger.kernel.org; linuxppc-dev@ozlabs.org Subject: Re: [RFC v1] virtio: add virtio-over-PCI driver On Feb 17, 2009, at 4:24 PM, Ira Snyder wrote: Documentation/virtio-over-PCI.txt | 61 ++ arch/powerpc/boot/dts/mpc834x_mds.dts |7 + we'll have to review the .dts and expect a documentation update for the node. But that's pretty minor at this point. drivers/virtio/Kconfig| 22 + drivers/virtio/Makefile |2 + drivers/virtio/vop.h | 119 ++ drivers/virtio/vop_fsl.c | 1911 + make this vop_fsl_mpc83xx.c or something along those lines. why? so we can deal with 85xx as well. We just need to isolate the 83xx specific bits (message usage) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC v1] virtio: add virtio-over-PCI driver
On Thu, Feb 19, 2009 at 10:51:43AM -0600, Kumar Gala wrote: On Feb 19, 2009, at 12:13 AM, Zang Roy-R61911 wrote: -Original Message- From: linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs.org [mailto:linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs .org] On Behalf Of Kumar Gala Sent: Thursday, February 19, 2009 0:47 AM To: Ira Snyder Cc: Arnd Bergmann; Jan-Bernd Themann; net...@vger.kernel.org; Rusty Russell; linux-ker...@vger.kernel.org; linuxppc-dev@ozlabs.org Subject: Re: [RFC v1] virtio: add virtio-over-PCI driver On Feb 17, 2009, at 4:24 PM, Ira Snyder wrote: Documentation/virtio-over-PCI.txt | 61 ++ arch/powerpc/boot/dts/mpc834x_mds.dts |7 + we'll have to review the .dts and expect a documentation update for the node. But that's pretty minor at this point. drivers/virtio/Kconfig| 22 + drivers/virtio/Makefile |2 + drivers/virtio/vop.h | 119 ++ drivers/virtio/vop_fsl.c | 1911 + make this vop_fsl_mpc83xx.c or something along those lines. why? so we can deal with 85xx as well. We just need to isolate the 83xx specific bits (message usage) In fact, most of the driver has nothing to do with hardware, and everything to do with managing memory. Most of the driver could be shared between implementations. The only things that would be hardware specific are setting up the descriptor memory, and raising/handling interrupts. I just wanted to get something working and out here to discuss. I figured that more hardware support, features, etc. could come later. Just like everything else in the kernel, I'm sure this will have to evolve over time as well. Thanks, Ira ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch] powerpc: estimate G5 cpufreq transition latency
Setting G5's cpu frequency transition latency to CPUFREQ_ETERNAL stops
ondemand governor from working. I measured the latency using sched_clock
and haven't seen much higher than 11000ns, so I set this to 12000ns for
my configuration. Possibly other configurations will be different?
Ideally the generic code would be able to measure it in case the platform
does not provide it.
But this simple patch at least makes it throttle again.
Signed-off-by: Nick Piggin npig...@suse.de
---
Index: linux-2.6/arch/powerpc/platforms/powermac/cpufreq_64.c
===
--- linux-2.6.orig/arch/powerpc/platforms/powermac/cpufreq_64.c 2009-02-20
01:42:41.0 +1100
+++ linux-2.6/arch/powerpc/platforms/powermac/cpufreq_64.c 2009-02-20
01:50:15.0 +1100
@@ -86,6 +86,7 @@
static DEFINE_MUTEX(g5_switch_mutex);
+static unsigned long transition_latency;
#ifdef CONFIG_PMAC_SMU
@@ -357,7 +358,7 @@
static int g5_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
- policy-cpuinfo.transition_latency = CPUFREQ_ETERNAL;
+ policy-cpuinfo.transition_latency = transition_latency;
policy-cur = g5_cpu_freqs[g5_query_freq()].frequency;
/* secondary CPUs are tied to the primary one by the
* cpufreq core if in the secondary policy we tell it that
@@ -500,6 +501,7 @@
g5_cpu_freqs[1].frequency = max_freq/2;
/* Set callbacks */
+ transition_latency = 12000;
g5_switch_freq = g5_scom_switch_freq;
g5_query_freq = g5_scom_query_freq;
freq_method = SCOM;
@@ -675,6 +677,7 @@
g5_cpu_freqs[1].frequency = min_freq;
/* Set callbacks */
+ transition_latency = CPUFREQ_ETERNAL;
g5_switch_volt = g5_pfunc_switch_volt;
g5_switch_freq = g5_pfunc_switch_freq;
g5_query_freq = g5_pfunc_query_freq;
Index: linux-2.6/drivers/cpufreq/cpufreq.c
===
--- linux-2.6.orig/drivers/cpufreq/cpufreq.c2009-02-20 01:42:43.0
+1100
+++ linux-2.6/drivers/cpufreq/cpufreq.c 2009-02-20 01:50:15.0 +1100
@@ -1559,9 +1559,11 @@
else {
printk(KERN_WARNING %s governor failed, too long
transition latency of HW, fallback
- to %s governor\n,
+ to %s governor (latency=%lld max=%lld)\n,
policy-governor-name,
- gov-name);
+ gov-name,
+ policy-cpuinfo.transition_latency,
+ policy-governor-max_transition_latency);
policy-governor = gov;
}
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Gianfar tx-babbling-errors
On Feb 19, 2009, at 10:48 AM, sjoy...@wanadoo.fr wrote: Hi Scott, Your issue may come from data setup (or corruption) instead of code path: babbling error may occurs when a TSEC TX descriptor hasn't its last frame bit set or when the data length is greated than max frame length. -- Take a look at TxBD[TR] and see if its getting set ever. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 2/2] powerpc: replace isync with lwsync
OK, here is this patch again. You didn't think I'd let a 2% performance improvement be forgotten? :) Anyway, patch won't work well on architecture without lwsync, but I won't bother fixing that kind of thing and making it merge worthy until you guys say something positive about it. 20 runs of tbench on the G5 unpatched AVG=920.37 STD=2.36 patched AVG=938.89 STD=3.33 (throughput in MB/s) This is a 1.9% throughput increase. --- Index: linux-2.6/arch/powerpc/include/asm/atomic.h === --- linux-2.6.orig/arch/powerpc/include/asm/atomic.h2009-02-20 01:50:20.0 +1100 +++ linux-2.6/arch/powerpc/include/asm/atomic.h 2009-02-20 02:13:22.0 +1100 @@ -55,7 +55,7 @@ PPC405_ERR77(0,%2) stwcx. %0,0,%2 \n\ bne-1b - ISYNC_ON_SMP + LWSYNC_ON_SMP : =r (t) : r (a), r (v-counter) : cc, memory); @@ -91,7 +91,7 @@ PPC405_ERR77(0,%2) stwcx. %0,0,%2 \n\ bne-1b - ISYNC_ON_SMP + LWSYNC_ON_SMP : =r (t) : r (a), r (v-counter) : cc, memory); @@ -125,7 +125,7 @@ PPC405_ERR77(0,%1) stwcx. %0,0,%1 \n\ bne-1b - ISYNC_ON_SMP + LWSYNC_ON_SMP : =r (t) : r (v-counter) : cc, xer, memory); @@ -169,7 +169,7 @@ PPC405_ERR77(0,%1) stwcx. %0,0,%1\n\ bne-1b - ISYNC_ON_SMP + LWSYNC_ON_SMP : =r (t) : r (v-counter) : cc, xer, memory); @@ -202,7 +202,7 @@ PPC405_ERR77(0,%2) stwcx. %0,0,%1 \n\ bne-1b \n - ISYNC_ON_SMP + LWSYNC_ON_SMP subf%0,%2,%0 \n\ 2: : =r (t) @@ -235,7 +235,7 @@ PPC405_ERR77(0,%1) stwcx. %0,0,%1\n\ bne-1b - ISYNC_ON_SMP + LWSYNC_ON_SMP \n\ 2:: =b (t) : r (v-counter) @@ -291,7 +291,7 @@ add %0,%1,%0\n\ stdcx. %0,0,%2 \n\ bne-1b - ISYNC_ON_SMP + LWSYNC_ON_SMP : =r (t) : r (a), r (v-counter) : cc, memory); @@ -325,7 +325,7 @@ subf%0,%1,%0\n\ stdcx. %0,0,%2 \n\ bne-1b - ISYNC_ON_SMP + LWSYNC_ON_SMP : =r (t) : r (a), r (v-counter) : cc, memory); @@ -357,7 +357,7 @@ addic %0,%0,1\n\ stdcx. %0,0,%1 \n\ bne-1b - ISYNC_ON_SMP + LWSYNC_ON_SMP : =r (t) : r (v-counter) : cc, xer, memory); @@ -399,7 +399,7 @@ addic %0,%0,-1\n\ stdcx. %0,0,%1\n\ bne-1b - ISYNC_ON_SMP + LWSYNC_ON_SMP : =r (t) : r (v-counter) : cc, xer, memory); @@ -425,7 +425,7 @@ blt-2f\n\ stdcx. %0,0,%1\n\ bne-1b - ISYNC_ON_SMP + LWSYNC_ON_SMP \n\ 2:: =r (t) : r (v-counter) @@ -458,7 +458,7 @@ add %0,%2,%0 \n stdcx. %0,0,%1 \n\ bne-1b \n - ISYNC_ON_SMP + LWSYNC_ON_SMP subf%0,%2,%0 \n\ 2: : =r (t) Index: linux-2.6/arch/powerpc/include/asm/bitops.h === --- linux-2.6.orig/arch/powerpc/include/asm/bitops.h2009-02-20 01:50:20.0 +1100 +++ linux-2.6/arch/powerpc/include/asm/bitops.h 2009-02-20 02:13:22.0 +1100 @@ -139,7 +139,7 @@ PPC405_ERR77(0,%3) PPC_STLCX %1,0,%3 \n bne- 1b - ISYNC_ON_SMP + LWSYNC_ON_SMP : =r (old), =r (t) : r (mask), r (p) : cc, memory); @@ -160,7 +160,7 @@ PPC405_ERR77(0,%3) PPC_STLCX %1,0,%3 \n bne- 1b - ISYNC_ON_SMP + LWSYNC_ON_SMP : =r (old), =r (t) : r (mask), r (p) : cc, memory); @@ -182,7 +182,7 @@ PPC405_ERR77(0,%3) PPC_STLCX %1,0,%3 \n bne- 1b - ISYNC_ON_SMP + LWSYNC_ON_SMP : =r (old), =r (t) : r (mask), r (p) : cc, memory); @@ -204,7 +204,7 @@ PPC405_ERR77(0,%3) PPC_STLCX %1,0,%3 \n bne- 1b - ISYNC_ON_SMP + LWSYNC_ON_SMP : =r (old), =r (t) : r (mask), r (p) : cc, memory); Index: linux-2.6/arch/powerpc/include/asm/futex.h === --- linux-2.6.orig/arch/powerpc/include/asm/futex.h 2009-02-20 01:50:20.0 +1100 +++ linux-2.6/arch/powerpc/include/asm/futex.h 2009-02-20 02:13:22.0 +1100 @@ -97,7 +97,7 @@ PPC405_ERR77(0,%2) 2: stwcx. %4,0,%2\n\ bne-1b\n -ISYNC_ON_SMP +LWSYNC_ON_SMP 3:.section .fixup,\ax\\n\ 4: li %0,%5\n\ b 3b\n\ Index: linux-2.6/arch/powerpc/include/asm/spinlock.h === --- linux-2.6.orig/arch/powerpc/include/asm/spinlock.h 2009-02-20
[patch 1/2] powerpc: optimise smp_mb
Using lwsync, isync sequence in a microbenchmark is 5 times faster on my G5 than using sync for smp_mb. Although it takes more instructions. Running tbench with 4 clients on my 4 core G5 (20 times) gives the following: unpatched AVG=920.33 STD=2.36 patched AVG=921.27 STD=2.77 So not a big improvement here, actually it could even be in the noise. But other workloads or systems might see a bigger win, and the patch maybe is interesting or could be improved, so I'll ask for comments. --- Index: linux-2.6/arch/powerpc/include/asm/system.h === --- linux-2.6.orig/arch/powerpc/include/asm/system.h2009-02-20 01:51:24.0 +1100 +++ linux-2.6/arch/powerpc/include/asm/system.h 2009-02-20 02:09:41.0 +1100 @@ -52,7 +52,16 @@ #define SMPWMB eieio #endif +#ifdef __powerpc64__ +#define smp_mb() __asm__ __volatile__ ( \ + 1: lwsync \n \ + cmpw0,%%r0,%%r0 \n \ + bne-1b \n \ + isync \n \ + : : : memory) +#else #define smp_mb() mb() +#endif #define smp_rmb() __asm__ __volatile__ (stringify_in_c(LWSYNC) : : :memory) #define smp_wmb() __asm__ __volatile__ (stringify_in_c(SMPWMB) : : :memory) #define smp_read_barrier_depends() read_barrier_depends() ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Regarding irq_of_parse_and_map
On Thu, 2009-02-19 at 17:21 +0530, Vijay Nikam wrote: Also is it possible to compile device tree on Linux host and genreate dtb for powerpc ? ? ? If yes, then how ? ? ? please let me know ... thanks ... Uh, get a copy of the DTC using: $ git clone git://git.jdl.com/software/dtc.git $ cd dtc $ make HTH, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: Do not configure or probe disabled FSL DR USB controllers
On Thu, Feb 19, 2009 at 10:19:05AM -0600, Kumar Gala wrote: On Feb 19, 2009, at 10:02 AM, Anton Vorontsov wrote: On MPC837X CPUs Dual-Role USB isn't always available (for example DR USB pins can be muxed away to eSDHC). U-Boot adds status = disabled property into the DR USB nodes to indicate that we must not try to configure or probe Dual-Role USB, otherwise we'll break eSDHC support on targets with MPC837X CPUs. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- arch/powerpc/platforms/83xx/usb.c |3 ++- arch/powerpc/sysdev/fsl_soc.c |4 2 files changed, 6 insertions(+), 1 deletions(-) Mind looking at possibly killing the fsl_soc.c usb code and making the usb a real of-platform driver? Sure, but it's a bit complicated because of OTG support (which doesn't currently work, btw). Just need to think about whether we want to leave UDC and HOST drivers as pure platform drivers, and implement an of platform driver as a proxy for Host/UDC/OTG... Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Gianfar tx-babbling-errors
-Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: February 19, 2009 12:04PM Your issue may come from data setup (or corruption) instead of code path: babbling error may occurs when a TSEC TX descriptor hasn't its last frame bit set or when the data length is greated than max frame length. -- Take a look at TxBD[TR] and see if its getting set ever. I added two bug checks: - one in gfar_clean_tx_ring() after the check for completed frames: /* see if any transmits were truncated */ BUG_ON(lstatus BD_LFLAG(TXBD_TR)); - one in gfar_start_xmit() at the end to check a flag to see if TXBD_LAST never gets set. Within a couple of minutes it bug checked in gfar_clean_tx_ring(): kernel BUG at drivers/net/gianfar.c:1826! Oops: Exception in kernel mode, sig: 5 [#1] CYC833-8568 Modules linked in: NIP: c019a7b8 LR: c019a824 CTR: REGS: c0307d50 TRAP: 0700 Not tainted (2.6.27.6) MSR: 00021000 ME CR: 44044044 XER: 2000 TASK = c02eb4a8[0] 'swapper' THREAD: c0306000 GPR00: 0001 c0307e00 c02eb4a8 0002 0010 0001 c030dc48 c0e003c0 GPR08: c0314e80 180107a8 efab6dd0 24044022 002ae6bc 007f 0010 GPR16: ef84a800 00029000 ef84abec ef84abc0 0001 0073 01cc GPR24: 00100100 0001 ef84abc0 0400 efab7400 ef0f9f00 efab71c8 NIP [c019a7b8] gfar_poll+0xb0/0x408 LR [c019a824] gfar_poll+0x11c/0x408 Call Trace: [c0307e00] [c019a824] gfar_poll+0x11c/0x408 (unreliable) [c0307e50] [c01cb144] net_rx_action+0xc4/0x180 [c0307e80] [c0036404] __do_softirq+0x74/0xe0 [c0307ea0] [c0004a20] do_softirq+0x54/0x58 [c0307eb0] [c00362b0] irq_exit+0x94/0x98 [c0307ec0] [c0004acc] do_IRQ+0xa8/0xc8 [c0307ed0] [c000e40c] ret_from_except+0x0/0x18 [c0307f90] [c0007c88] cpu_idle+0x50/0xd8 [c0307fb0] [c024b220] __got2_end+0x58/0x68 [c0307fc0] [c02c5808] start_kernel+0x230/0x2ac [c0307ff0] [c3c4] skpinv+0x2ec/0x328 Instruction dump: 3a80 817e0094 a32b0004 57291838 7d3f4a14 7f89e040 7d7b4850 7d295f1e 8129 2f89 419c0160 552003de 0f00 813f 2f19 55290084 Kernel panic - not syncing: Fatal exception in interrupt ___ Scott N. Coulter Senior Software Engineer Cyclone Microsystems 370 James Street Phone: 203.786.5536 ext. 118 New Haven, CT 06513-3051 Email: scott.coul...@cyclone.com U.S.A.Web:http://www.cyclone.com ___ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Newby trying to get Ethernet going on MPC83xx series device.
On Thu, Feb 19, 2009 at 03:26:41PM +1100, Dushara Jayasinghe wrote: I get the following error during the boot sequence: IP-Config: Device `eth0' not found I also found that both gfar_init (in gianfar.c) and gfar_mdio_init (in gianfar_mii.c) are called but the probe handlers of either of these devices are not executed. Check your board code to see if the soc node is being probed by of_platform_bus_probe. Ideally, the soc node would have simple-bus included in the compatible property, as would the of_device_id array. -Scott ___ 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 Thu, Feb 19, 2009 at 05:47:22PM +1100, Daniel Ng wrote: Or, perhaps it is ok for the 'of_platform' bus to have no devices on it, and so I might be using the wrong bus?? Why would this be? Or is it something else?? Either way, I still get the following boot error message: IP-Config: Device `eth0' not found. -and fs_enet_probe() is NEVER called. See this thread: http://ozlabs.org/pipermail/linuxppc-dev/2009-February/068467.html -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] powerpc: setup archdata for {of_}platform via a single platform_notify
Since a number of powerpc chips are SoCs we end up having dma-able
devices that are registered as platform or of_platform devices. We need
to hook the archdata to setup proper dma_ops for these devices.
In the short term the majority of these devices only need the
direct_dma_ops as the platforms don't have any IOMMUs.
In the future to enable 4G DMA support on ppc32 we can hook swiotlb ops.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/include/asm/machdep.h|4
arch/powerpc/kernel/setup-common.c| 22 ++
arch/powerpc/kernel/setup.h |4
arch/powerpc/kernel/setup_32.c|3 +++
arch/powerpc/kernel/setup_64.c|3 +++
arch/powerpc/platforms/cell/qpace_setup.c | 13 -
6 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machdep.h
index 6c34a0d..9a28e5b 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -262,6 +262,10 @@ struct machdep_calls {
void (*suspend_disable_irqs)(void);
void (*suspend_enable_irqs)(void);
#endif
+ /* These are called via the driver core. They mainly exist
+* for setting up archdata properly */
+ int (*platform_notify)(struct device *dev);
+ int (*platform_notify_remove)(struct device *dev);
};
extern void e500_idle(void);
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 705fc4b..62dfa75 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -669,3 +669,25 @@ static int powerpc_debugfs_init(void)
}
arch_initcall(powerpc_debugfs_init);
#endif
+
+int ppc_platform_notify(struct device *dev)
+{
+ if (ppc_md.platform_notify)
+ return ppc_md.platform_notify(dev);
+
+ /* set dma_ops for platform or of_platform bus */
+ if (dev-bus dev-bus-name
+ (!strcmp(dev-bus-name, platform) ||
+!strcmp(dev-bus-name, of_platform)))
+ set_dma_ops(dev, dma_direct_ops);
+
+ return 0;
+}
+
+int ppc_platform_notify_remove(struct device *dev)
+{
+ if (ppc_md.platform_notify_remove)
+ return ppc_md.platform_notify_remove(dev);
+
+ return 0;
+}
diff --git a/arch/powerpc/kernel/setup.h b/arch/powerpc/kernel/setup.h
index 4c67ad7..34899cf 100644
--- a/arch/powerpc/kernel/setup.h
+++ b/arch/powerpc/kernel/setup.h
@@ -1,9 +1,13 @@
#ifndef _POWERPC_KERNEL_SETUP_H
#define _POWERPC_KERNEL_SETUP_H
+#include linux/device.h
+
void check_for_initrd(void);
void do_init_bootmem(void);
void setup_panic(void);
+int ppc_platform_notify(struct device *dev);
+int ppc_platform_notify_remove(struct device *dev);
extern int do_early_xmon;
#endif /* _POWERPC_KERNEL_SETUP_H */
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 9e1ca74..c20a49d 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -328,6 +328,9 @@ void __init setup_arch(char **cmdline_p)
conswitchp = dummy_con;
#endif
+ platform_notify = ppc_platform_notify;
+ platform_notify_remove = ppc_platform_notify_remove;
+
if (ppc_md.setup_arch)
ppc_md.setup_arch();
if ( ppc_md.progress ) ppc_md.progress(arch: exit, 0x3eab);
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 73e16e2..b22a3d9 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -546,6 +546,9 @@ void __init setup_arch(char **cmdline_p)
conswitchp = dummy_con;
#endif
+ platform_notify = ppc_platform_notify;
+ platform_notify_remove = ppc_platform_notify_remove;
+
if (ppc_md.setup_arch)
ppc_md.setup_arch();
diff --git a/arch/powerpc/platforms/cell/qpace_setup.c
b/arch/powerpc/platforms/cell/qpace_setup.c
index be84e6a..775cd80 100644
--- a/arch/powerpc/platforms/cell/qpace_setup.c
+++ b/arch/powerpc/platforms/cell/qpace_setup.c
@@ -81,16 +81,6 @@ static int __init qpace_publish_devices(void)
}
machine_subsys_initcall(qpace, qpace_publish_devices);
-extern int qpace_notify(struct device *dev)
-{
- /* set dma_ops for of_platform bus */
- if (dev-bus dev-bus-name
-!strcmp(dev-bus-name, of_platform))
- set_dma_ops(dev, dma_direct_ops);
-
- return 0;
-}
-
static void __init qpace_setup_arch(void)
{
#ifdef CONFIG_SPU_BASE
@@ -115,9 +105,6 @@ static void __init qpace_setup_arch(void)
#ifdef CONFIG_DUMMY_CONSOLE
conswitchp = dummy_con;
#endif
-
- /* set notifier function */
- platform_notify = qpace_notify;
}
static int __init qpace_probe(void)
--
1.5.6.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] powerpc: expect all devices calling dma ops to have archdata set
Now that we set archdata for of_platform and platform devices via
platform_notify() we no longer need to special case having a NULL device
pointer or NULL archdata. It should be a driver error if this condition
shows up and the driver should be fixed.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/include/asm/dma-mapping.h | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index 86cef7d..c69f2b5 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -109,18 +109,8 @@ static inline struct dma_mapping_ops *get_dma_ops(struct
device *dev)
* only ISA DMA device we support is the floppy and we have a hack
* in the floppy driver directly to get a device for us.
*/
-
- if (unlikely(dev == NULL) || dev-archdata.dma_ops == NULL) {
-#ifdef CONFIG_PPC64
+ if (unlikely(dev == NULL))
return NULL;
-#else
- /* Use default on 32-bit if dma_ops is not set up */
- /* TODO: Long term, we should fix drivers so that dev and
-* archdata dma_ops are set up for all buses.
-*/
- return dma_direct_ops;
-#endif
- }
return dev-archdata.dma_ops;
}
--
1.5.6.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] powerpc/pci: Default to dma_direct_ops for pci dma_ops
This will allow us to remove the ppc32 specific checks in get_dma_ops()
that defaults to dma_direct_ops if the archdata is NULL. We really
should always have archdata set to something going forward.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/kernel/pci-common.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 2ad1731..633e871 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -50,7 +50,7 @@ resource_size_t isa_mem_base;
unsigned int ppc_pci_flags = 0;
-static struct dma_mapping_ops *pci_dma_ops;
+static struct dma_mapping_ops *pci_dma_ops = dma_direct_ops;
void set_pci_dma_ops(struct dma_mapping_ops *dma_ops)
{
--
1.5.6.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/pci: Default to dma_direct_ops for pci dma_ops
On Feb 19, 2009, at 2:49 PM, Kumar Gala wrote: This will allow us to remove the ppc32 specific checks in get_dma_ops() that defaults to dma_direct_ops if the archdata is NULL. We really should always have archdata set to something going forward. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- arch/powerpc/kernel/pci-common.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Ben, If you can look at putting these in testing that would be great. I'd like to see of Josh can get some 4xx/44x runs to see if we break anything there. I don't expect it but good to see. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/pci: Default to dma_direct_ops for pci dma_ops
* Kumar Gala | 2009-02-19 14:49:15 [-0600]: This will allow us to remove the ppc32 specific checks in get_dma_ops() that defaults to dma_direct_ops if the archdata is NULL. We really should always have archdata set to something going forward. Signed-off-by: Kumar Gala ga...@kernel.crashing.org Acked-by: Benjamin Krill b...@codiert.org ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc: setup archdata for {of_}platform via a single platform_notify
* Kumar Gala | 2009-02-19 14:49:16 [-0600]: Since a number of powerpc chips are SoCs we end up having dma-able devices that are registered as platform or of_platform devices. We need to hook the archdata to setup proper dma_ops for these devices. In the short term the majority of these devices only need the direct_dma_ops as the platforms don't have any IOMMUs. In the future to enable 4G DMA support on ppc32 we can hook swiotlb ops. Signed-off-by: Kumar Gala ga...@kernel.crashing.org Acked-by: Benjamin Krill b...@codiert.org ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc: expect all devices calling dma ops to have archdata set
* Kumar Gala | 2009-02-19 14:49:17 [-0600]: Now that we set archdata for of_platform and platform devices via platform_notify() we no longer need to special case having a NULL device pointer or NULL archdata. It should be a driver error if this condition shows up and the driver should be fixed. Signed-off-by: Kumar Gala ga...@kernel.crashing.org Acked-by: Benjamin Krill b...@codiert.org ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Gianfar tx-babbling-errors
Hi Scott, Your issue may come from data setup (or corruption) instead of code path: babbling error may occurs when a TSEC TX descriptor hasn't its last frame bit set or when the data length is greated than max frame length. -- sj 2009/2/19 Scott Coulter scott.coul...@cyclone.com Kumar, can't think of any. How about adding a BUG_ON() in the tx path to see if the buffer size MTU and re-run your tests. So, here are the checks I've tried in gfar_start_xmit(): BUG_ON(skb-len DEFAULT_RX_BUFFER_SIZE) BUG_ON(skb-len priv-regs-maxfrm) Neither produces a bug check yet ethtool reports non-zero tx-babbling-errors. The last check appears to be the definition of tx-babbling-errors. Is there a transmit path that I have missed? Scott ___ Scott N. Coulter Senior Software Engineer Cyclone Microsystems 370 James Street Phone: 203.786.5536 ext. 118 New Haven, CT 06513-3051 Email: scott.coul...@cyclone.com U.S.A.Web:http://www.cyclone.com ___ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- -- Sylvain JOYEAU Freelance Engineer Software RT-OS RD sylvain.joy...@gmail.com Tél: +33-(0)667 477 052 A good idea is one side of the coin. The other side is the practical usefulness. J. Liedke. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Newby trying to get Ethernet going on MPC83xx series device.
Yes I now base it on mpc834x_mds.c and it works (almost) :-(
The devices are successfully probed, but I'm getting this error on the debug
console:
[7.119389] m...@24520:00 not found
[7.161370] eth0: Could not attach to PHY
[7.209600] IP-Config: Failed to open eth0
[7.258879] IP-Config: Device `eth0' not found.
My mdio Ethernet nodes are as follows (commenting out device_type below is an
experiment)
m...@24520 {
/*device_type = mdio;*/
compatible = fsl,gianfar-mdio;
#address-cells = 1;
#size-cells = 0;
reg = 24520 20;
phy0: ethernet-...@0 {
interrupt-parent = ipic;
interrupts = 3 8;
reg = 0;
device_type = ethernet-phy;
};
phy1: ethernet-...@1 {
interrupt-parent = ipic;
interrupts = 3 8;
reg = 1;
device_type = ethernet-phy;
};
};
enet0: ether...@24000 {
cell-index = 0;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 24000 1000;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 20 8 21 8 22 8;
interrupt-parent = ipic;
phy-handle = phy0;
linux,network-index = 0;
};
enet1: ether...@25000 {
cell-index = 1;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 25000 1000;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 23 8 24 8 25 8;
interrupt-parent = ipic;
phy-handle = phy1;
linux,network-index = 1;
phy-connection-type = gmii;
};
Any clues as to where I should start looking?
BTW, I assume CCing all those who replied to me is accepted/expected conduct or
should I avoid this and just write to the list?
Also is top posting ok? I haven't figured out how to enable '' on bloody
Microsoft Outlook, for incoming plain text messages.
Thanks again for all your help.
D
-Original Message-
From: Aggrwal Poonam-B10812 [mailto:poonam.aggr...@freescale.com]
Sent: Thursday, 19 February 2009 6:25 PM
To: Li Yang-R58472; Dushara Jayasinghe
Cc: linuxppc-dev@ozlabs.org
Subject: RE: Newby trying to get Ethernet going on MPC83xx series device.
Probably better would be to check the board file for mpc834x_mds.c
I mean just cross that you probe all the buses which are on the device.
What is fsl,pq2pro-localbus? Do u have such node in dts as the
mpc8349_itx has.
-Original Message-
From: pku@gmail.com [mailto:pku@gmail.com] On Behalf
Of Li Yang-R58472
Sent: Thursday, February 19, 2009 12:50 PM
To: Dushara Jayasinghe
Cc: linuxppc-dev@ozlabs.org; Aggrwal Poonam-B10812
Subject: Re: Newby trying to get Ethernet going on MPC83xx
series device.
On Thu, Feb 19, 2009 at 2:58 PM, Dushara Jayasinghe
dusha...@optiscan.com wrote:
That did it.
I based my board specific file on mpc834x_itx.c which had
static struct of_device_id __initdata mpc834x_itx_ids[] = {
{ .compatible = fsl,pq2pro-localbus, },
{ .compatible = simple-bus, },
{},
};
Don't know if this is broken?
It's not broken as long as you have compatible = simple-bus
for your soc node.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [RFC v1] virtio: add virtio-over-PCI driver
-Original Message- From: Ira Snyder [mailto:i...@ovro.caltech.edu] Sent: Friday, February 20, 2009 0:15 AM To: Zang Roy-R61911 Cc: linux-ker...@vger.kernel.org; linuxppc-dev@ozlabs.org; net...@vger.kernel.org; Rusty Russell; Arnd Bergmann; Jan-Bernd Themann Subject: Re: [RFC v1] virtio: add virtio-over-PCI driver On Thu, Feb 19, 2009 at 02:10:08PM +0800, Zang Roy-R61911 wrote: -Original Message- From: linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs.org [mailto:linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs .org] On Behalf Of Ira Snyder Sent: Wednesday, February 18, 2009 6:24 AM To: linux-ker...@vger.kernel.org Cc: linuxppc-dev@ozlabs.org; net...@vger.kernel.org; Rusty Russell; Arnd Bergmann; Jan-Bernd Themann Subject: [RFC v1] virtio: add virtio-over-PCI driver snip diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig index 3dd6294..efcf56b 100644 --- a/drivers/virtio/Kconfig +++ b/drivers/virtio/Kconfig @@ -33,3 +33,25 @@ config VIRTIO_BALLOON If unsure, say M. +config VIRTIO_OVER_PCI_HOST + tristate Virtio-over-PCI Host support (EXPERIMENTAL) + depends on PCI EXPERIMENTAL + select VIRTIO + ---help--- + This driver provides the host support necessary for using virtio + over the PCI bus with a Freescale MPC8349EMDS evaluation board. + + If unsure, say N. + +config VIRTIO_OVER_PCI_FSL + tristate Virtio-over-PCI Guest support (EXPERIMENTAL) + depends on MPC834x_MDS EXPERIMENTAL + select VIRTIO + select DMA_ENGINE + select FSL_DMA + ---help--- + This driver provides the guest support necessary for using virtio + over the PCI bus. + + If unsure, say N. + diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile index 6738c44..f31afaa 100644 --- a/drivers/virtio/Makefile +++ b/drivers/virtio/Makefile @@ -2,3 +2,5 @@ obj-$(CONFIG_VIRTIO) += virtio.o obj-$(CONFIG_VIRTIO_RING) += virtio_ring.o obj-$(CONFIG_VIRTIO_PCI) += virtio_pci.o obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o +obj-$(CONFIG_VIRTIO_OVER_PCI_HOST) += vop_host.o +obj-$(CONFIG_VIRTIO_OVER_PCI_FSL) += vop_fsl.o I suppose we need to build the kernel twice. one for vop_host (on host with pci enabled) and the other is for vop_fsl ( on agent with pci disabled). Is it possible to build one image for both host and agent. We do not scan the pci bus if the controller is configured to agent. You should be able to build a kernel with support for both host and guest operation, and then use the device tree to switch which driver you get. The host driver won't be used without a PCI bus, and the guest driver won't be used without the message unit. Good. Is it necssary to commit a extra dts for the agent mode? or just document it? Also, is it possible to include mpc85xx architecture? They should be same. There is some code for 85xx in Fresscale BSP. http://www.bitshrine.org/gpp/linux-fsl-2.6.23-MPC8568MDS_PCI_A gent_PCIe_ EP_Drvier.patch I looked at the cardnet driver before I implemented my PCINet driver. I hunch it would be rejected for the same reasons, but maybe not. That is also our concern :-( Also, it makes no use of DMA, which is critical for good transfer speed. Using memcpy() in PCINet gives performance around 10 mbit/sec, which is terrible. I can see your improvement for performance. I'm sure the driver isn't very hard to port to 85xx, I just don't have any 85xx boards to test with. The driver only directly interacts with the messaging unit, which is a pretty simple piece of hardware. No matter. It is OK to just support 83xx boards currently. 85xx baords can be dealed with later. Finally, I hope this driver can support 83xx /85xx boards pci and pci express mode. Roy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [RFC v1] virtio: add virtio-over-PCI driver
-Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Friday, February 20, 2009 0:52 AM To: Zang Roy-R61911 Cc: Ira Snyder; Arnd Bergmann; Jan-Bernd Themann; net...@vger.kernel.org; Rusty Russell; linux-ker...@vger.kernel.org; linuxppc-dev@ozlabs.org Subject: Re: [RFC v1] virtio: add virtio-over-PCI driver On Feb 19, 2009, at 12:13 AM, Zang Roy-R61911 wrote: -Original Message- From: linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs.org [mailto:linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs .org] On Behalf Of Kumar Gala Sent: Thursday, February 19, 2009 0:47 AM To: Ira Snyder Cc: Arnd Bergmann; Jan-Bernd Themann; net...@vger.kernel.org; Rusty Russell; linux-ker...@vger.kernel.org; linuxppc-dev@ozlabs.org Subject: Re: [RFC v1] virtio: add virtio-over-PCI driver On Feb 17, 2009, at 4:24 PM, Ira Snyder wrote: Documentation/virtio-over-PCI.txt | 61 ++ arch/powerpc/boot/dts/mpc834x_mds.dts |7 + we'll have to review the .dts and expect a documentation update for the node. But that's pretty minor at this point. drivers/virtio/Kconfig| 22 + drivers/virtio/Makefile |2 + drivers/virtio/vop.h | 119 ++ drivers/virtio/vop_fsl.c | 1911 + make this vop_fsl_mpc83xx.c or something along those lines. why? so we can deal with 85xx as well. After some modificaiton, the driver should be used on 85xx. For 85xx, most of the cases are for pci express. We just need to isolate the 83xx specific bits (message usage) Yes. Roy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Add alignment handler for new lfiwzx instruction
lfiwzx is a new floating point load instruction in 2.06 that needs an
alignment handler for Linux.
Turns out to be the worlds easiest handler to add.
Signed-off-by: Michael Neuling mi...@neuling.org
---
Benh: this is for 2.6.30, but would be nice to be back in 2.6.27/28/29
too.
arch/powerpc/kernel/align.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/align.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/align.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/align.c
@@ -187,7 +187,7 @@ static struct aligninfo aligninfo[128] =
{ 4, ST+F+S+U },/* 11 1 1010: stfsux */
{ 8, ST+F+U }, /* 11 1 1011: stfdux */
INVALID,/* 11 1 1100 */
- INVALID,/* 11 1 1101 */
+ { 4, LD+F },/* 11 1 1101: lfiwzx */
INVALID,/* 11 1 1110 */
INVALID,/* 11 1 */
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Fix load/store float double alignment handler
When we introduced VSX, we changed the way FPRs are stored in the
thread_struct. Unfortunately we missed the load/store float double
alignment handler code when updating how we access FPRs in the
thread_struct.
Below fixes this and merges the little/big endian case.
Signed-off-by: Michael Neuling mi...@neuling.org
---
benh: this needs to go into 27,28 and 29. Sorry :-)
arch/powerpc/kernel/align.c | 29 +
1 file changed, 13 insertions(+), 16 deletions(-)
Index: linux-bml/arch/powerpc/kernel/align.c
===
--- linux-bml.orig/arch/powerpc/kernel/align.c
+++ linux-bml/arch/powerpc/kernel/align.c
@@ -367,27 +367,24 @@ static int emulate_multiple(struct pt_re
static int emulate_fp_pair(unsigned char __user *addr, unsigned int reg,
unsigned int flags)
{
- char *ptr = (char *) current-thread.TS_FPR(reg);
- int i, ret;
+ char *ptr0 = (char *) current-thread.TS_FPR(reg);
+ char *ptr1 = (char *) current-thread.TS_FPR(reg+1);
+ int i, ret, sw = 0;
if (!(flags F))
return 0;
if (reg 1)
return 0; /* invalid form: FRS/FRT must be even */
- if (!(flags SW)) {
- /* not byte-swapped - easy */
- if (!(flags ST))
- ret = __copy_from_user(ptr, addr, 16);
- else
- ret = __copy_to_user(addr, ptr, 16);
- } else {
- /* each FPR value is byte-swapped separately */
- ret = 0;
- for (i = 0; i 16; ++i) {
- if (!(flags ST))
- ret |= __get_user(ptr[i^7], addr + i);
- else
- ret |= __put_user(ptr[i^7], addr + i);
+ if (flags SW)
+ sw = 7;
+ ret = 0;
+ for (i = 0; i 8; ++i) {
+ if (!(flags ST)) {
+ ret |= __get_user(ptr0[i^sw], addr + i);
+ ret |= __get_user(ptr1[i^sw], addr + i + 8);
+ } else {
+ ret |= __put_user(ptr0[i^sw], addr + i);
+ ret |= __put_user(ptr1[i^sw], addr + i + 8);
}
}
if (ret)
___
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 Fri, Feb 20, 2009 at 5:44 AM, Scott Wood scottw...@freescale.com wrote:
See this thread:
http://ozlabs.org/pipermail/linuxppc-dev/2009-February/068467.html
Great, that's helped. Thanks Scott.
Now, I'm seeing these boot messages:
f0010d40:00 not found
eth0: Could not attach to PHY
IP-Config: Failed to open eth0
IP-Config: Device `eth0' not found.
Previous mailing list discussions suggest that I use the correct PHY,
which I am sure about because my 8272-based board only has the one PHY
ie. PHY0 with reg = 0x0.
Note the relevant parts of my Device Tree below. Currently, our PHY
attributes eg. 'auto-negotiate' are not changeable, so we aren't
actually using MDC+MDIO even the MDC+MDIO lines exist. Also, the PHY
interrupt line is not wired up. Hence the PHY0 interrupts field is 0
8 (or should it be removed altogether?).
I am usig FCC2.
What might I need to change to get the ethernet driver working?
ether...@11320 {
device_type = network;
compatible = fsl,mpc8272-fcc-enet,
fsl,cpm2-fcc-enet;
// FCC2-
reg = 0x11320 0x20 0x8500 0x100 0x113b0 0x1;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 33 8;
interrupt-parent = PIC;
phy-handle = PHY0;
linux,network-index = 0;
fsl,cpm-command = 0x16200300;
};
m...@10d40 {
device_type = mdio;
compatible = fsl,mpc8272ads-mdio-bitbang,
fsl,mpc8272-mdio-bitbang,
fsl,cpm2-mdio-bitbang;
reg = 0x10d40 0x14;
#address-cells = 1;
#size-cells = 0;
fsl,mdio-pin = 5;
fsl,mdc-pin = 19;
PHY0: ethernet-...@0 {
interrupt-parenn = PIC;
interrupts = 0 8;
reg = 0x0;
device_type = ethernet-phy;
};
.
.
.
PIC: interrupt-control...@10c00 {
#interrupt-cells = 2;
interrupt-controller;
reg = 0x10c00 0x80;
compatible = fsl,mpc8272-pic, fsl,cpm2-pic;
};
Cheers,
Daniel
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Enable hashdist by default on PowerPC
Hi David, I should probably do this on sparc64 too. Why don't we just change this thing to CONFIG_64BIT? I agree. How does this look? 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 an...@samba.org --- diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h index 95837bf..aa861d5 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_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: Newby trying to get Ethernet going on MPC83xx series device.
Hi Dushara,
Sorry, I'm a late comer here, but I might have an idea. First off, I don't
see below what
kernel version you are using? I may have missed it somewhere.
The devices are successfully probed, but I'm getting this error on the
debug console:
[7.119389] m...@24520:00 not found
[7.161370] eth0: Could not attach to PHY
[7.209600] IP-Config: Failed to open eth0
[7.258879] IP-Config: Device `eth0' not found.
I have similar output on my MPC8313E RDB. In my case, eth0 shared lines with
the external USB OTG and its PHY. I modified the resister banks on the board
that essentially cuts off the interrupt to the eth0 PHY. So, I don't expect
it to find it. Here is the kernel output at init time:
24520:01 not found
eth0: Could not attach to PHY
My mdio Ethernet nodes are as follows (commenting out device_type below is
an experiment)
m...@24520 {
/*device_type = mdio;*/
compatible = fsl,gianfar-mdio;
#address-cells = 1;
#size-cells = 0;
reg = 24520 20;
Hmm, well, the first thing I catch is this is an old dts format. Depending
on your kernel version, you
may want to comply with the dts v1 spec. The v1 spec is much more strict on
the format of the values
that are provided for the properties.
ex. reg = 0x24520 0x20 makes it very clear that these values are hex, not
decimal.
You will notice this ambiguity below with the 'interrupts' properties. Are
the values decimal or hex?
Turns out that the values are hex. You will find dts version specifier
/dts-v1/; at the top or just before
the root node in any dts file that meets the v1 spec.
phy0: ethernet-...@0 {
interrupt-parent = ipic;
interrupts = 3 8;
reg = 0;
device_type = ethernet-phy;
};
phy1: ethernet-...@1 {
interrupt-parent = ipic;
interrupts = 3 8;
reg = 1;
device_type = ethernet-phy;
};
};
Are you sure both PHY's use interrupt 3? I would think not.
enet0: ether...@24000 {
cell-index = 0;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 24000 1000;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 20 8 21 8 22 8;
interrupt-parent = ipic;
phy-handle = phy0;
linux,network-index = 0;
};
enet1: ether...@25000 {
cell-index = 1;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 25000 1000;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 23 8 24 8 25 8;
interrupt-parent = ipic;
phy-handle = phy1;
linux,network-index = 1;
phy-connection-type = gmii;
};
Finally, I don't know which silicon rev that you are using, but I have seen
the enet0 and enet1 interrupts swapped.
As in the very latest silicon may have the interrupt lines switched between
them. You can find a statement to that
affect on this list somewhere. I am using a revB MPC8313E and I specify the
interrupts as you have them here.
However, the dts file for the mpc8313erdb in the 2.6.28 kernel has them
reversed. Presumably for a revC chip.
ex.
enet0: ether...@24000 {
...
interrupts = 23 8 24 8 25 8;
...
};
enet1: ether...@25000 {
...
interrupts = 20 8 21 8 22 8;
...
};
BTW, I assume CCing all those who replied to me is accepted/expected
conduct or should I avoid this and just write to the list?
Yes, you should cc those who have replied. It is expected --- well, at least
by me.
Also is top posting ok? I haven't figured out how to enable '' on bloody
Microsoft Outlook, for incoming plain text messages.
I'm a little new to this list, but in general top posting is frowned upon.
Unfortunately, I can't help you with the Outlook problem.
I can tell you that not being able to determine what part of a message came
when is extremely annoying. I hope you find a fix
for it. Or, you could try Thunderbird :)
Mike
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Newby trying to get Ethernet going on MPC83xx series device.
Sorry, I'm a late comer here, but I might have an idea. First off, I don't see
below what
kernel version you are using? I may have missed it somewhere.
[dj]
Sorry I should have mentioned that earlier. I'm using 2.6.29-rc5 (pulled couple
of days ago)
Hmm, well, the first thing I catch is this is an old dts format. Depending on
your kernel version, you
may want to comply with the dts v1 spec. The v1 spec is much more strict on
the format of the values
that are provided for the properties.
[dj]
I've fixed that since. Thanks.
phy0: ethernet-...@0 {
interrupt-parent = ipic;
interrupts = 3 8;
reg = 0;
device_type = ethernet-phy;
};
phy1: ethernet-...@1 {
interrupt-parent = ipic;
interrupts = 3 8;
reg = 1;
device_type = ethernet-phy;
};
};
Are you sure both PHY's use interrupt 3? I would think not.
[dj]
I need to follow that through and see.
Also is top posting ok? I haven't figured out how to enable '' on bloody
Microsoft Outlook, for incoming plain text messages.
I'm a little new to this list, but in general top posting is frowned upon.
Unfortunately, I can't help you with the Outlook problem.
I can tell you that not being able to determine what part of a message came
when is extremely annoying. I hope you find a fix
for it. Or, you could try Thunderbird :)
[dj]
I'm using the HTML format. I've tagged my comments just in case the context is
lost.
Consequently, I found, some further insights into the issue. Here's a debug
output.
[7.124188] {
[7.143107] bus_id=m...@24520:00 - -
printed in drivers/net/phy/phy_device.c : phy_connect()
[7.181907] match check m...@24520:1f- - printed in
drivers/base/bus.c : match_name()
[7.225946] m...@24520:00 not found
[7.267883] }
Where does the :1f or :00 get added?
Thanks
D
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
