* Re: [PATCH] USB_DR host support for FSL MPC831x
From: Vitaly Bordug @ 2007-07-17 14:52 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: Greg KH, linuxppc-dev
In-Reply-To: <989B956029373F45A0B8AF0297081890F06271@zch01exm26.fsl.freescale.net>
On Tue, 17 Jul 2007 20:18:35 +0800
"Li Yang-r58472" <LeoLi@freescale.com> wrote:
> Hi Vitaly,
>
> I believe that your patch is addresses by my patch in 2.6.23 queue:
> http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/2.6/2.6.22/usb-
> ehci_fsl-update-for-mpc831x-support.patch
>
okay, nm then. I'll revalidate with these 2 patches
and come up with something ontop if it won't work.
> - Leo
>
> > -----Original Message-----
> > From: linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org
> > [mailto:linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org]
> > On Behalf Of Vitaly Bordug
> > Sent: Tuesday, July 17, 2007 8:59 AM
> > To: Greg KH
> > Cc: linuxppc-dev@ozlabs.org
> > Subject: [PATCH] USB_DR host support for FSL MPC831x
> >
> >
> > Modifies fsl_ehci code so that to get USB host working on
> > mpc831x platform. Verified with MPC8313RDB reference board.
> >
> > Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> >
> > ---
> >
> > arch/powerpc/boot/dts/mpc8313erdb.dts | 1 +
> > drivers/usb/host/ehci-fsl.c | 4 +++-
> > drivers/usb/host/ehci-hcd.c | 2 +-
> > 3 files changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts
> > b/arch/powerpc/boot/dts/mpc8313erdb.dts
> > index 1b351dc..c330e79 100644
> > --- a/arch/powerpc/boot/dts/mpc8313erdb.dts
> > +++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
> > @@ -90,6 +90,7 @@
> > interrupt-parent = < &ipic >;
> > interrupts = <26 8>;
> > phy_type = "utmi_wide";
> > + control_init = <00000280>; // UTMI ext
> > 48 MHz clk
> > };
> >
> > mdio@24520 {
> > diff --git a/drivers/usb/host/ehci-fsl.c
> > b/drivers/usb/host/ehci-fsl.c index c7a7c59..3e3187b 100644
> > --- a/drivers/usb/host/ehci-fsl.c
> > +++ b/drivers/usb/host/ehci-fsl.c
> > @@ -185,12 +185,14 @@ static void mpc83xx_usb_setup(struct
> > usb_hcd *hcd)
> > struct ehci_hcd *ehci = hcd_to_ehci(hcd);
> > struct fsl_usb2_platform_data *pdata;
> > void __iomem *non_ehci = hcd->regs;
> > + u32 temp;
> >
> > pdata =
> > (struct fsl_usb2_platform_data *)hcd->self.controller->
> > platform_data;
> > /* Enable PHY interface in the control reg. */
> > - out_be32(non_ehci + FSL_SOC_USB_CTRL, 0x00000004);
> > + temp = in_be32(non_ehci + FSL_SOC_USB_CTRL);
> > + out_be32(non_ehci + FSL_SOC_USB_CTRL, temp | 0x00000004);
> > out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0000001b);
> >
> > #if defined(CONFIG_PPC32) && !defined(CONFIG_NOT_COHERENT_CACHE)
> > diff --git a/drivers/usb/host/ehci-hcd.c
> > b/drivers/usb/host/ehci-hcd.c index 099aff6..994a127 100644
> > --- a/drivers/usb/host/ehci-hcd.c
> > +++ b/drivers/usb/host/ehci-hcd.c
> > @@ -925,7 +925,7 @@ MODULE_LICENSE ("GPL");
> > #define PCI_DRIVER ehci_pci_driver
> > #endif
> >
> > -#ifdef CONFIG_MPC834x
> > +#if defined(CONFIG_MPC834x) || defined(CONFIG_PPC_MPC831x)
> > #include "ehci-fsl.c"
> > #define PLATFORM_DRIVER ehci_fsl_driver
> > #endif
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
--
Sincerely,
Vitaly
^ permalink raw reply
* Memory Corruption in Linux kernel MPC8347 revision 3
From: Boris Shteinbock @ 2007-07-17 14:42 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 7772 bytes --]
Hi Everyone.
I am working on the Linux port for MPC8347 revision 3 custom build board
with DDR2 memory.
I've successfully ported U-boot (latest git) and the kernel itself,
however during kernel boot I am encountering serious memory corruption
errors. The log for one of the examples is at the bottom of this
message.
Basically, the corruption is always happening somewhere at memory
management intensive tasks such as networking, JFFS2 mounting etc.
As far as I can see, it is not related to some specific driver, because
even it happens even at kernel configured at absolute minimum, ( console
serial driver only and even without it)
The place of the corruption depends on kernel configuration.
The DDR2 memory controller is configured correctly as far as I can tell,
since :
1. DDR2 controller register values are taken from VxWorks bootrom
that works on this board without any problems.
2. u-boot mtest passes successfully
3. u-boot alternative mtest passes successfully
4. My own custom mem tests in u-boot pass successfully
5. If I manage two boot the board into shell prompt (with absolute
minimum configuration) memtester application is also successful.
The minimum configuration that is one I am able to boot into shell is a
kernel configured with serial console and small busybox JFFS2 file
system in the flash. In this configuration, the boot fails the first
time JFFS2 root FS is mounted. However it does boot after reset.
I've tried different kernels with the same results starting from, I
think, 2.6.16 up to 2.6.22
I tried the kernel that is provided by Freescale for 834x reference
boards. ( with my board support of course)
I tried booting both OF flat trees (powerpc) and bd_t based builds (ppc)
I've also tried all memory management options :
SLAB, SLOB and SLUB (in the latest kernel). They all failed at some
point of time, so the assumption is that the problem is not in the
memory management facilities.
The board manufacturer swears that DDR2 memory controller values are
correct and should work perfectly.
So now I almost out of options and I am seeking your help.
Any type of input on this issue would be greatly appreciated.
Thanks,
Boris
PS. Note that an below example represents failure during DHCP
autoconfiguration. However the similar error happens even when
networking is disabled completely. just in a different place.
=> bootm
## Booting image at 00400000 ...
Image Name: Linux-.6.21.5
Created: 2007-07-10 14:20:19 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 898361 Bytes = 877.3 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x07FA3CF8 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF41
bd address = 0x07FA3FBC
memstart = 0x00000000
memsize = 0x08000000
flashstart = 0xFE000000
flashsize = 0x02000000
flashoffset = 0x00033000
sramstart = 0x00000000
sramsize = 0x00000000
bootflags = 0x00000001
intfreq = 528 MHz
busfreq = 264 MHz
ethaddr = 00:04:9F:EF:23:35
eth1addr = 00:E0:0C:00:7E:25
IP addr = 10.2.222.20
baudrate = 115200 bps
No initrd
## Transferring control to Linux (at address 00000000) ...
!!!! of_flat_tree = 00000000
Booting without OF Flat tree
Linux version .6.21.5 (me@localhost) (gcc version
4.0.0 (DENX ELDK 4.1 4.0.0)) #24 Tue Jul 10 17:20:09 IDT 2007
Zone PFN ranges:
DMA 0 -> 32768
Normal 32768 -> 32768
early_node_map[1] active PFN ranges
0: 0 -> 32768
Built 1 zonelists. Total pages: 32512
Kernel command line: console=ttyS0,115200 root=/dev/mtdblock1
rootfstype=jffs2 ip=dhcp
IPIC (128 IRQ sources, 8 External IRQs) at fe000700
PID hash table entries: 512 (order: 9, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 127744k available (1584k kernel code, 444k data, 84k init, 0k
highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
Setup MTD partitions
Generic PHY: Registered new driver
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing
disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 9) is a 16550A
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 10) is a 16550A
Gianfar MII Bus: probed
eth0: Gianfar Ethernet Controller Version 1.2, 00:04:9f:ef:23:35
eth0: Running with NAPI disabled
eth0: 64/64 RX/TX BD ring size
Broadcom BCM5241: Registered new driver
physmap platform flash device: 02000000 at fe000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
physmap-flash.0: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
cmdlinepart partition parsing not available
RedBoot partition parsing not available
Using physmap partition information
Creating 2 MTD partitions on "physmap-flash.0":
0x00000000-0x00100000 : "uboot"
0x00100000-0x02000000 : "rootfs"
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
!!!! Gianfar init_phy. phy_id = 0:01
!!!! phy_attach. phy_id = 0:01
!!!! phy_attach device found. phy_id = 0:01
Sending DHCP requests .<3>slab: Internal list corruption detected in
cache 'files_cache'(21), slabp c0344000(16). Hexdump:
000: 00 10 01 00 00 20 02 00 00 00 00 70 c0 34 40 70
010: 00 00 00 10 00 00 ff 10 00 00 00 00 ff ff ff fe
020: ff ff ff fe ff ff ff fe ff ff ff fe ff ff ff fe
030: ff ff ff fe ff ff ff fe ff ff ff fe ff ff ff fe
040: ff ff ff fe ff ff ff fe ff ff ff fe ff ff ff fe
050: ff ff ff fe ff ff ff fe ff ff ff fd 00 00 00 11
060: 00 00 00 12 00 00 00 13 00 00 00 14 ff ff ff ff
------------[ cut here ]------------
kernel BUG at mm/slab.c:2936!
Oops: Exception in kernel mode, sig: 5 [#1]
NIP: C0050F80 LR: C0050F80 CTR: 00000000
REGS: c034fe00 TRAP: 0700 Not tainted (.6.21.5)
MSR: 00021032 <ME,IR,DR> CR: 24004002 XER: 00000000
TASK = c032a3c0[3] 'events/0' THREAD: c034e000
GPR00: C0050F80 C034FEB0 C032A3C0 00000001 00000DF5 FFFFFFFF C00F5B54
00000010
GPR08: C01D0000 C01E0000 00000DF5 00000DF5 00000000 00F1C5DB 07FFD000
FFFFFFFF
GPR16: 00000001 00000000 00000000 00800000 00000000 007FFF00 00000000
C033DAA0
GPR24: C0339C90 00000007 00000000 C01B0000 C01B0000 C0344000 C033DAA0
00000070
NIP [C0050F80] check_slabp+0xe4/0x11c
LR [C0050F80] check_slabp+0xe4/0x11c
Call Trace:
[C034FEB0] [C0050F80] check_slabp+0xe4/0x11c (unreliable)
[C034FED0] [C0051450] free_block+0x88/0x138
[C034FF00] [C0052188] drain_array+0xa0/0xe0
[C034FF20] [C0052228] cache_reap+0x60/0x144
[C034FF40] [C00257B0] run_workqueue+0xd0/0x170
[C034FF60] [C0025960] worker_thread+0x110/0x144
[C034FFC0] [C00298E4] kthread+0x74/0xb0
[C034FFF0] [C0005F38] kernel_thread+0x44/0x60
Instruction dump:
387b6538 7c9df8ae 4bfc2b49 3bff0001 813e0020 5529103a 3929001c 7f9f4840
419cffcc 3c60c01b 3863336c 4bfc2b25 <0fe00000> 48000000 80030020
2f800000
[-- Attachment #2: Type: text/html, Size: 9637 bytes --]
^ permalink raw reply
* Re: [PATCH] Add StorCenter DTS first draft.
From: Segher Boessenkool @ 2007-07-17 14:57 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IAnwC-0003Xm-6U@jdl.com>
> Comments welcome, of course.
Well you asked for it :-)
> +/ {
> + model = "StorCenter";
If you can find a real model number, put it in here,
instead.
> + compatible = "storcenter";
Needs a manufacturer name in there.
> + PowerPC,603e { /* Really 8241 */
So say "PowerPC,8241@0", or "PowerPC,e300@0" (or whatever
the CPU core in there is), or simply "cpu@0", following
the generic naming recommended practice.
> + bus-frequency = <0>;
Is this filled in anywhere? Please document that, if so.
> + /* Following required by dtc but not used */
> + i-cache-line-size = <0>;
> + d-cache-line-size = <0>;
> + i-cache-size = <4000>;
> + d-cache-size = <4000>;
Not used _by the Linux kernel_, it's required by the
PowerPC binding. Perhaps that should be modified
for flat device tree use, there are many more required
properties that no flat tree has anyway.
> + flash@ff800000 {
> + device_type = "rom";
I'm sure you know I find this "rom" binding to be crap.
However, I didn't yet write up the "cfi" binding, so I
can't complain ;-)
> + partitions = <
> + 00000000 0000E000
> + 0000E000 00002000
> + 00010000 00040000
> + 00050000 00200000
> + 00250000 004B0000
> + 00700000 00020000
> + 00720000 00010000
> + 00730000 00010000
> + 00740000 000B0000
> + >;
Nothing from 7f0000 to 7fffff?
> + soc10x {
Bad name. Where is the binding for this? I don't think
I saw it before.
> + compatible = "mpc10x";
"manufacturer,106-host" or similar. But this isn't an 10x
at all, is it?
> + store-gathering = <0>; /* 0 == off, !0 == on */
Don't define this as "!0", but as "1".
> + i2c@fdf03000 {
> + device_type = "i2c";
No device_type, there is no I2C binding.
> + compatible = "fsl-i2c";
Needs to be more specific.
> + mpic: pic@fdf40000 {
interrupt-controller@fdf40000
> + #interrupt-cells = <2>;
> + #address-cells = <0>;
No #address-cells here.
> + device_type = "open-pic";
device_type = "interrupt-controller" I believe, unless
the mpic binding does something weird.
> + pci@fe800000 {
> + clock-frequency = <d# 100000000>; /* Hz */
100MHz PCI? Interesting.
> + interrupt-map = <
> + /* IDSEL 0x15 - ETH */
> + 7800 0 0 1 &mpic 0 1
7800 isn't device 0x15. I think you meant 15.
Segher
^ permalink raw reply
* Re: [PATCH 2/3] 82xx: Parse SMC serial device node in DTS
From: Segher Boessenkool @ 2007-07-17 15:08 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707171406.03455.arnd@arndb.de>
>>>> + if (strstr(model, "SMC")) {
>>>> + cpm_uart_dev =
>>>> platform_device_register_simple("fsl-cpm-smc:uart",
>>>> + i, &r
>>>> [0], 3);
>>>> + } else if (strstr(model, "SCC")) {
>>> You should probably use of_device_is_compatible() to check
>>> if a given device can be used by a particular driver.
>>
>> I think, the function of_find_compatible_node(), which is called
>> in the
>> for loop, has already done that. So definitely, no need to call
>> of_device_is_compatible() any more.
>
> It's a little more complicated than that. The "compatible" property
> should
> indicate the exact interface of that device, so the "model" does
> not really
> matter here.
"model" is meant to be an exact manufacturer model number.
This can be used for workaround code or such if the "compatible"
entry isn't specific enough. You should try to make sure your
"compatible" entries are, though.
Oh, and strstr() is asking for trouble. Just do a full
compare.
> I don't know the difference between smc and scc, but if you
> need to register them as different pplatform devices, they should
> normally also have different names in "compatible", possibly in
> addition
> to the existing one.
Either that, or if they are identical device, just used in
different ways / connected differently, show that via some
other properties or such.
> If the compatible property contains "fsl,cpm-smc\0cpm_uart", you
> can scan for
> either of them. The loop will iterate over all cpm_uart compatible
> devices,
> while the later test will look for an fsl,cpm-smc compatible device.
Well, "fsl,cpm-uart" (note the two differences), but yes.
Segher
^ permalink raw reply
* Re: [PATCH 2/3] 82xx: Parse SMC serial device node in DTS
From: Arnd Bergmann @ 2007-07-17 14:18 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1184682576.18501.62.camel@mark>
On Tuesday 17 July 2007, Mark Zhan wrote:
>
> > Well, AFAICS, all of them currently use scc. The 8xx platforms don't
> > even build correctly in the mainline kernel, so I guess it would
> > be good to change them to also list fsl,cpm-smc in the compatible
> > property.
>
> That probably could be done by another series of patches, and I really
> don't want to introduce those kinds of patches in my BSP patches. I
> don't know if the 8xx/82xx series patches from Scott Wood will cover
> this issue or not.
I guess he can best answer that himself. Scott, what are your plans
to deal with the different types of cpm ports?
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/3] 82xx: Parse SMC serial device node in DTS
From: Segher Boessenkool @ 2007-07-17 15:12 UTC (permalink / raw)
To: Mark Zhan; +Cc: linuxppc-dev, paulus, Arnd Bergmann
In-Reply-To: <1184680385.18501.51.camel@mark>
> but, the current situation is that: in all DTS files that are using
> smc
> or scc as uart device, all device node definitions have the same
> "compatible" property -- "cpm_uart"
>
> So what I do here is just following the upstream source tree.
True enough. OTOH, it doesn't help to continue supporting
the "bad old stuff", esp. if new extra workarounds are
needed for it.
Segher
^ permalink raw reply
* Re: [PATCH 2/3] 82xx: Parse SMC serial device node in DTS
From: Arnd Bergmann @ 2007-07-17 14:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <3D0E2A2D-9ADE-4931-9C73-8E65550C728F@kernel.crashing.org>
On Tuesday 17 July 2007, Segher Boessenkool wrote:
> > If the compatible property contains "fsl,cpm-smc\0cpm_uart", you =A0
> > can scan for
> > either of them. The loop will iterate over all cpm_uart compatible =A0
> > devices,
> > while the later test will look for an fsl,cpm-smc compatible device.
>=20
> Well, "fsl,cpm-uart" (note the two differences), but yes.
My point was about the 'smc' part that needs to be added, so I guess
if we want to have that in there, it should be "fsl,cpm-smc-uart"
really, and "fsl,cpm-scc-uart", respectively.
Arnd <><
^ permalink raw reply
* [PATCH 1/4] ibmveth: Enable TCP checksum offload
From: Brian King @ 2007-07-17 15:17 UTC (permalink / raw)
To: santil; +Cc: linuxppc-dev, rcjenn, brking, netdev
This patchset enables TCP checksum offload support for IPV4
on ibmveth. This completely eliminates the generation and checking of
the checksum for packets that are completely virtual and never
touch a physical network. A simple TCP_STREAM netperf run on
a virtual network with maximum mtu set yielded a ~30% increase
in throughput. This feature is enabled by default on systems that
support it, but can be disabled with a module option.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 58 ++++++++++++++++++++++++++++++++
linux-2.6-bjking1/drivers/net/ibmveth.h | 41 +++++++++++++++++++++-
2 files changed, 97 insertions(+), 2 deletions(-)
diff -puN drivers/net/ibmveth.c~ibmveth_csum_offload drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_csum_offload 2007-07-12 08:27:47.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-07-12 09:35:55.000000000 -0500
@@ -47,6 +47,8 @@
#include <linux/mm.h>
#include <linux/ethtool.h>
#include <linux/proc_fs.h>
+#include <linux/in.h>
+#include <linux/ip.h>
#include <asm/semaphore.h>
#include <asm/hvcall.h>
#include <asm/atomic.h>
@@ -103,12 +105,15 @@ static struct proc_dir_entry *ibmveth_pr
static const char ibmveth_driver_name[] = "ibmveth";
static const char ibmveth_driver_string[] = "IBM i/pSeries Virtual Ethernet Driver";
+static unsigned int ibmveth_csum_offload = 1;
#define ibmveth_driver_version "1.03"
MODULE_AUTHOR("Santiago Leon <santil@us.ibm.com>");
MODULE_DESCRIPTION("IBM i/pSeries Virtual Ethernet Driver");
MODULE_LICENSE("GPL");
MODULE_VERSION(ibmveth_driver_version);
+module_param_named(csum_offload, ibmveth_csum_offload, uint, 0);
+MODULE_PARM_DESC(csum_offload, "Checksum offload (0/1). Default: 1");
/* simple methods of getting data from the current rxq entry */
static inline int ibmveth_rxq_pending_buffer(struct ibmveth_adapter *adapter)
@@ -131,6 +136,11 @@ static inline int ibmveth_rxq_frame_leng
return (adapter->rx_queue.queue_addr[adapter->rx_queue.index].length);
}
+static inline int ibmveth_rxq_csum_good(struct ibmveth_adapter *adapter)
+{
+ return (adapter->rx_queue.queue_addr[adapter->rx_queue.index].csum_good);
+}
+
/* setup the initial settings for a buffer pool */
static void ibmveth_init_buffer_pool(struct ibmveth_buff_pool *pool, u32 pool_index, u32 pool_size, u32 buff_size, u32 pool_active)
{
@@ -684,6 +694,24 @@ static int ibmveth_start_xmit(struct sk_
desc[0].fields.length, DMA_TO_DEVICE);
desc[0].fields.valid = 1;
+ if (skb->ip_summed == CHECKSUM_PARTIAL &&
+ ip_hdr(skb)->protocol != IPPROTO_TCP && skb_checksum_help(skb)) {
+ ibmveth_error_printk("tx: failed to checksum packet\n");
+ tx_dropped++;
+ goto out;
+ }
+
+ if (skb->ip_summed == CHECKSUM_PARTIAL) {
+ unsigned char *buf = skb_transport_header(skb) + skb->csum_offset;
+
+ desc[0].fields.no_csum = 1;
+ desc[0].fields.csum_good = 1;
+
+ /* Need to zero out the checksum */
+ buf[0] = 0;
+ buf[1] = 0;
+ }
+
if(dma_mapping_error(desc[0].fields.address)) {
ibmveth_error_printk("tx: unable to map initial fragment\n");
tx_map_failed++;
@@ -702,6 +730,10 @@ static int ibmveth_start_xmit(struct sk_
frag->size, DMA_TO_DEVICE);
desc[curfrag+1].fields.length = frag->size;
desc[curfrag+1].fields.valid = 1;
+ if (skb->ip_summed == CHECKSUM_PARTIAL) {
+ desc[curfrag+1].fields.no_csum = 1;
+ desc[curfrag+1].fields.csum_good = 1;
+ }
if(dma_mapping_error(desc[curfrag+1].fields.address)) {
ibmveth_error_printk("tx: unable to map fragment %d\n", curfrag);
@@ -792,7 +824,11 @@ static int ibmveth_poll(struct net_devic
} else {
int length = ibmveth_rxq_frame_length(adapter);
int offset = ibmveth_rxq_frame_offset(adapter);
+ int csum_good = ibmveth_rxq_csum_good(adapter);
+
skb = ibmveth_rxq_get_buffer(adapter);
+ if (csum_good)
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
ibmveth_rxq_harvest_buffer(adapter);
@@ -962,8 +998,10 @@ static void ibmveth_poll_controller(stru
static int __devinit ibmveth_probe(struct vio_dev *dev, const struct vio_device_id *id)
{
int rc, i;
+ long ret;
struct net_device *netdev;
struct ibmveth_adapter *adapter = NULL;
+ union ibmveth_illan_attributes set_attr, ret_attr;
unsigned char *mac_addr_p;
unsigned int *mcastFilterSize_p;
@@ -1058,6 +1096,26 @@ static int __devinit ibmveth_probe(struc
ibmveth_debug_printk("registering netdev...\n");
+ if (ibmveth_csum_offload) {
+ ret = h_illan_attributes(dev->unit_address, 0, 0, &ret_attr.desc);
+
+ if (ret == H_SUCCESS && !ret_attr.fields.active_trunk &&
+ !ret_attr.fields.trunk_priority &&
+ ret_attr.fields.csum_offload_padded_pkt_support) {
+ set_attr.desc = 0;
+ set_attr.fields.tcp_csum_offload_ipv4 = 1;
+
+ ret = h_illan_attributes(dev->unit_address, 0, set_attr.desc,
+ &ret_attr.desc);
+
+ if (ret == H_SUCCESS)
+ netdev->features |= NETIF_F_IP_CSUM;
+ else
+ ret = h_illan_attributes(dev->unit_address, set_attr.desc,
+ 0, &ret_attr.desc);
+ }
+ }
+
rc = register_netdev(netdev);
if(rc) {
diff -puN drivers/net/ibmveth.h~ibmveth_csum_offload drivers/net/ibmveth.h
--- linux-2.6/drivers/net/ibmveth.h~ibmveth_csum_offload 2007-07-12 08:27:47.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.h 2007-07-12 09:32:54.000000000 -0500
@@ -67,6 +67,21 @@ static inline long h_send_logical_lan(un
return rc;
}
+static inline long h_illan_attributes(unsigned long unit_address,
+ unsigned long reset_mask, unsigned long set_mask,
+ unsigned long *ret_attributes)
+{
+ long rc;
+ unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
+
+ rc = plpar_hcall(H_ILLAN_ATTRIBUTES, retbuf, unit_address,
+ reset_mask, set_mask);
+
+ *ret_attributes = retbuf[0];
+
+ return rc;
+}
+
#define h_multicast_ctrl(ua, cmd, mac) \
plpar_hcall_norets(H_MULTICAST_CTRL, ua, cmd, mac)
@@ -144,7 +159,9 @@ struct ibmveth_adapter {
struct ibmveth_buf_desc_fields {
u32 valid : 1;
u32 toggle : 1;
- u32 reserved : 6;
+ u32 reserved : 4;
+ u32 no_csum : 1;
+ u32 csum_good : 1;
u32 length : 24;
u32 address;
};
@@ -154,10 +171,30 @@ union ibmveth_buf_desc {
struct ibmveth_buf_desc_fields fields;
};
+struct ibmveth_illan_attributes_fields {
+ u32 reserved;
+ u32 reserved2 : 18;
+ u32 csum_offload_padded_pkt_support : 1;
+ u32 reserved3 : 1;
+ u32 trunk_priority : 4;
+ u32 reserved4 : 5;
+ u32 tcp_csum_offload_ipv6 : 1;
+ u32 tcp_csum_offload_ipv4 : 1;
+ u32 active_trunk : 1;
+};
+
+union ibmveth_illan_attributes {
+ u64 desc;
+ struct ibmveth_illan_attributes_fields fields;
+};
+
struct ibmveth_rx_q_entry {
u16 toggle : 1;
u16 valid : 1;
- u16 reserved : 14;
+ u16 reserved : 4;
+ u16 no_csum : 1;
+ u16 csum_good : 1;
+ u16 reserved2 : 8;
u16 offset;
u32 length;
u64 correlator;
_
^ permalink raw reply
* [PATCH 2/4] ibmveth: Implement ethtool hooks to enable/disable checksum offload
From: Brian King @ 2007-07-17 15:17 UTC (permalink / raw)
To: santil; +Cc: linuxppc-dev, rcjenn, brking, netdev
In-Reply-To: <11846854701127-patch-mail.ibm.com>
This patch adds the appropriate ethtool hooks to allow for enabling/disabling
of hypervisor assisted checksum offload for TCP.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 120 +++++++++++++++++++++++++++++++-
linux-2.6-bjking1/drivers/net/ibmveth.h | 1
2 files changed, 119 insertions(+), 2 deletions(-)
diff -puN drivers/net/ibmveth.c~ibmveth_csum_offload_ethtool drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_csum_offload_ethtool 2007-07-12 09:36:01.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-07-12 09:41:15.000000000 -0500
@@ -644,12 +644,127 @@ static u32 netdev_get_link(struct net_de
return 1;
}
+static void ibmveth_set_rx_csum_flags(struct net_device *dev, u32 data)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+
+ if (data)
+ adapter->rx_csum = 1;
+ else {
+ adapter->rx_csum = 0;
+ dev->features &= ~NETIF_F_IP_CSUM;
+ }
+}
+
+static void ibmveth_set_tx_csum_flags(struct net_device *dev, u32 data)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+
+ if (data) {
+ dev->features |= NETIF_F_IP_CSUM;
+ adapter->rx_csum = 1;
+ } else
+ dev->features &= ~NETIF_F_IP_CSUM;
+}
+
+static int ibmveth_set_csum_offload(struct net_device *dev, u32 data,
+ void (*done) (struct net_device *, u32))
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+ union ibmveth_illan_attributes set_attr, clr_attr, ret_attr;
+ long ret;
+ int rc1 = 0, rc2 = 0;
+ int restart = 0;
+
+ if (netif_running(dev)) {
+ restart = 1;
+ adapter->pool_config = 1;
+ ibmveth_close(dev);
+ adapter->pool_config = 0;
+ }
+
+ set_attr.desc = 0;
+ clr_attr.desc = 0;
+
+ if (data)
+ set_attr.fields.tcp_csum_offload_ipv4 = 1;
+ else
+ clr_attr.fields.tcp_csum_offload_ipv4 = 1;
+
+ ret = h_illan_attributes(adapter->vdev->unit_address, 0, 0, &ret_attr.desc);
+
+ if (ret == H_SUCCESS && !ret_attr.fields.active_trunk &&
+ !ret_attr.fields.trunk_priority &&
+ ret_attr.fields.csum_offload_padded_pkt_support) {
+ ret = h_illan_attributes(adapter->vdev->unit_address, clr_attr.desc,
+ set_attr.desc, &ret_attr.desc);
+
+ if (ret != H_SUCCESS) {
+ rc1 = -EIO;
+ ibmveth_error_printk("unable to change checksum offload settings."
+ " %d rc=%ld\n", data, ret);
+
+ ret = h_illan_attributes(adapter->vdev->unit_address,
+ set_attr.desc, clr_attr.desc, &ret_attr.desc);
+ } else
+ done(dev, data);
+ } else {
+ rc1 = -EIO;
+ ibmveth_error_printk("unable to change checksum offload settings."
+ " %d rc=%ld ret_attr=%lx\n", data, ret, ret_attr.desc);
+ }
+
+ if (restart)
+ rc2 = ibmveth_open(dev);
+
+ return rc1 ? rc1 : rc2;
+}
+
+static int ibmveth_set_rx_csum(struct net_device *dev, u32 data)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+
+ if (data && adapter->rx_csum)
+ return 0;
+ if (!data && !adapter->rx_csum)
+ return 0;
+
+ return ibmveth_set_csum_offload(dev, data, ibmveth_set_rx_csum_flags);
+}
+
+static int ibmveth_set_tx_csum(struct net_device *dev, u32 data)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+ int rc = 0;
+
+ if (data && (dev->features & NETIF_F_IP_CSUM))
+ return 0;
+ if (!data && !(dev->features & NETIF_F_IP_CSUM))
+ return 0;
+
+ if (data && !adapter->rx_csum)
+ rc = ibmveth_set_csum_offload(dev, data, ibmveth_set_tx_csum_flags);
+ else
+ ibmveth_set_tx_csum_flags(dev, data);
+
+ return rc;
+}
+
+static u32 ibmveth_get_rx_csum(struct net_device *dev)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+ return adapter->rx_csum;
+}
+
static const struct ethtool_ops netdev_ethtool_ops = {
.get_drvinfo = netdev_get_drvinfo,
.get_settings = netdev_get_settings,
.get_link = netdev_get_link,
.get_sg = ethtool_op_get_sg,
.get_tx_csum = ethtool_op_get_tx_csum,
+ .set_tx_csum = ibmveth_set_tx_csum,
+ .get_rx_csum = ibmveth_get_rx_csum,
+ .set_rx_csum = ibmveth_set_rx_csum
};
static int ibmveth_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
@@ -1108,9 +1223,10 @@ static int __devinit ibmveth_probe(struc
ret = h_illan_attributes(dev->unit_address, 0, set_attr.desc,
&ret_attr.desc);
- if (ret == H_SUCCESS)
+ if (ret == H_SUCCESS) {
+ adapter->rx_csum = 1;
netdev->features |= NETIF_F_IP_CSUM;
- else
+ } else
ret = h_illan_attributes(dev->unit_address, set_attr.desc,
0, &ret_attr.desc);
}
diff -puN drivers/net/ibmveth.h~ibmveth_csum_offload_ethtool drivers/net/ibmveth.h
--- linux-2.6/drivers/net/ibmveth.h~ibmveth_csum_offload_ethtool 2007-07-12 09:36:01.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.h 2007-07-12 09:36:01.000000000 -0500
@@ -140,6 +140,7 @@ struct ibmveth_adapter {
struct ibmveth_buff_pool rx_buff_pool[IbmVethNumBufferPools];
struct ibmveth_rx_q rx_queue;
int pool_config;
+ int rx_csum;
/* adapter specific stats */
u64 replenish_task_cycles;
_
^ permalink raw reply
* [PATCH 3/4] ibmveth: Add ethtool TSO handlers
From: Brian King @ 2007-07-17 15:18 UTC (permalink / raw)
To: santil; +Cc: linuxppc-dev, rcjenn, brking, netdev
In-Reply-To: <11846854701127-patch-mail.ibm.com>
Add handlers for get_tso and get_ufo to prevent errors being printed
by ethtool.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -puN drivers/net/ibmveth.c~ibmveth_ethtool_get_tso drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_ethtool_get_tso 2007-07-12 09:39:20.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-07-12 09:39:20.000000000 -0500
@@ -764,7 +764,9 @@ static const struct ethtool_ops netdev_e
.get_tx_csum = ethtool_op_get_tx_csum,
.set_tx_csum = ibmveth_set_tx_csum,
.get_rx_csum = ibmveth_get_rx_csum,
- .set_rx_csum = ibmveth_set_rx_csum
+ .set_rx_csum = ibmveth_set_rx_csum,
+ .get_tso = ethtool_op_get_tso,
+ .get_ufo = ethtool_op_get_ufo
};
static int ibmveth_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
_
^ permalink raw reply
* Re: [PATCH] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Segher Boessenkool @ 2007-07-17 15:18 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20070717024246.GA6482@localhost.localdomain>
>>>> Yeah. Giving the warning is a good thing though.
>>>
>>> No, it isn't; it's just noise, if we're not ever going to do
>>> anything
>>> to prevent the behaviour - and we can't.
>>
>> The same userland code will not run correctly on PPC64 or BookE
>> systems. Is that not a reason to warn?
>
> Way back when, I distinctly recall aborting my plans to implement
> per-page exec on 40x, precisely because of executables like this.
I noticed some comments to that effect in the BookE code,
yes. It seems userland has been fixed enough that you
could think about enabling it again FWIW.
Segher
^ permalink raw reply
* [PATCH 4/4] ibmveth: Add ethtool driver stats hooks
From: Brian King @ 2007-07-17 15:18 UTC (permalink / raw)
To: santil; +Cc: linuxppc-dev, rcjenn, brking, netdev
In-Reply-To: <11846854701127-patch-mail.ibm.com>
Add ethtool hooks to ibmveth to retrieve driver statistics.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 53 +++++++++++++++++++++++++++++++-
1 file changed, 52 insertions(+), 1 deletion(-)
diff -puN drivers/net/ibmveth.c~ibmveth_ethtool_driver_stats drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_ethtool_driver_stats 2007-07-12 09:39:23.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-07-12 09:39:23.000000000 -0500
@@ -115,6 +115,28 @@ MODULE_VERSION(ibmveth_driver_version);
module_param_named(csum_offload, ibmveth_csum_offload, uint, 0);
MODULE_PARM_DESC(csum_offload, "Checksum offload (0/1). Default: 1");
+struct ibmveth_stat {
+ char name[ETH_GSTRING_LEN];
+ int offset;
+};
+
+#define IBMVETH_STAT_OFF(stat) offsetof(struct ibmveth_adapter, stat)
+#define IBMVETH_GET_STAT(a, off) *((u64 *)(((unsigned long)(a)) + off))
+
+struct ibmveth_stat ibmveth_stats[] = {
+ { "replenish_task_cycles", IBMVETH_STAT_OFF(replenish_task_cycles) },
+ { "replenish_no_mem", IBMVETH_STAT_OFF(replenish_no_mem) },
+ { "replenish_add_buff_failure", IBMVETH_STAT_OFF(replenish_add_buff_failure) },
+ { "replenish_add_buff_success", IBMVETH_STAT_OFF(replenish_add_buff_success) },
+ { "rx_invalid_buffer", IBMVETH_STAT_OFF(rx_invalid_buffer) },
+ { "rx_no_buffer", IBMVETH_STAT_OFF(rx_no_buffer) },
+ { "tx_multidesc_send", IBMVETH_STAT_OFF(tx_multidesc_send) },
+ { "tx_linearized", IBMVETH_STAT_OFF(tx_linearized) },
+ { "tx_linearize_failed", IBMVETH_STAT_OFF(tx_linearize_failed) },
+ { "tx_map_failed", IBMVETH_STAT_OFF(tx_map_failed) },
+ { "tx_send_failed", IBMVETH_STAT_OFF(tx_send_failed) }
+};
+
/* simple methods of getting data from the current rxq entry */
static inline int ibmveth_rxq_pending_buffer(struct ibmveth_adapter *adapter)
{
@@ -756,6 +778,32 @@ static u32 ibmveth_get_rx_csum(struct ne
return adapter->rx_csum;
}
+static void ibmveth_get_strings(struct net_device *dev, u32 stringset, u8 *data)
+{
+ int i;
+
+ if (stringset != ETH_SS_STATS)
+ return;
+
+ for (i = 0; i < ARRAY_SIZE(ibmveth_stats); i++, data += ETH_GSTRING_LEN)
+ memcpy(data, ibmveth_stats[i].name, ETH_GSTRING_LEN);
+}
+
+static int ibmveth_get_stats_count(struct net_device *dev)
+{
+ return ARRAY_SIZE(ibmveth_stats);
+}
+
+static void ibmveth_get_ethtool_stats(struct net_device *dev,
+ struct ethtool_stats *stats, u64 *data)
+{
+ int i;
+ struct ibmveth_adapter *adapter = dev->priv;
+
+ for (i = 0; i < ARRAY_SIZE(ibmveth_stats); i++)
+ data[i] = IBMVETH_GET_STAT(adapter, ibmveth_stats[i].offset);
+}
+
static const struct ethtool_ops netdev_ethtool_ops = {
.get_drvinfo = netdev_get_drvinfo,
.get_settings = netdev_get_settings,
@@ -766,7 +814,10 @@ static const struct ethtool_ops netdev_e
.get_rx_csum = ibmveth_get_rx_csum,
.set_rx_csum = ibmveth_set_rx_csum,
.get_tso = ethtool_op_get_tso,
- .get_ufo = ethtool_op_get_ufo
+ .get_ufo = ethtool_op_get_ufo,
+ .get_strings = ibmveth_get_strings,
+ .get_stats_count = ibmveth_get_stats_count,
+ .get_ethtool_stats = ibmveth_get_ethtool_stats
};
static int ibmveth_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
diff -puN drivers/net/ibmveth.h~ibmveth_ethtool_driver_stats drivers/net/ibmveth.h
_
^ permalink raw reply
* Re: [PATCH] Change the pci express controller node name from pci to pcie
From: Segher Boessenkool @ 2007-07-17 15:22 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1184643035.23157.3.camel@localhost.localdomain>
> From: Roy Zang <tie-fei.zang@freescale.com>
>
> Change the pci express controller node name from pci
> to pcie in device tree.
>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Looks good, thanks!
Segher
^ permalink raw reply
* Re: [PATCH] USB_DR host support for FSL MPC831x
From: Kumar Gala @ 2007-07-17 15:34 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Greg KH, linuxppc-dev
In-Reply-To: <20070717185229.0f66e227@vitb.ru.mvista.com>
On Jul 17, 2007, at 9:52 AM, Vitaly Bordug wrote:
> On Tue, 17 Jul 2007 20:18:35 +0800
> "Li Yang-r58472" <LeoLi@freescale.com> wrote:
>
>> Hi Vitaly,
>>
>> I believe that your patch is addresses by my patch in 2.6.23 queue:
>> http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/
>> 2.6/2.6.22/usb-
>> ehci_fsl-update-for-mpc831x-support.patch
>>
> okay, nm then. I'll revalidate with these 2 patches
> and come up with something ontop if it won't work.
>
FYI, Leo's patches are now in Linus's tree.
- k
^ permalink raw reply
* Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
From: Segher Boessenkool @ 2007-07-17 15:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Wei.Zhang
In-Reply-To: <18076.42297.26124.137770@cargo.ozlabs.ibm.com>
>> The device tree describes _all_ hardware in the system,
>> not just the things that are somewhat harder to probe
>> for.
>
> Actually, for embedded systems, the device tree is really only
> required to describe the things that it's useful for the Linux kernel
> to know.
Sure, for example it could provide a "SoC" node with only
an address range, and not describe all the devices on that
SoC separately. It still describes all of the hardware,
not in quite so much detail though. It also won't get all
the benefits of using the OF device tree, but that is a
trade off, for each group to decide on their own.
> The point of the device tree for embedded systems is to provide
> configuration information, not to be able to claim compliance with
> some set of legalistic requirements. :)
Well, if you use some certain binding, you better use it
correctly, no? Ill-defined and ill-used interfaces aren't
the nicest thing to deal with.
> I think in some cases we have gone a little over the top in trying to
> put everything in the device tree, in fact. Ultimately I think it has
> to be up to the more experienced embedded developers to say how much
> detail in the device tree is actually helpful and how much is dead
> weight.
Yes, more complex device bindings need a lot of time to get
right, and need a lot of input from all parties using it.
In general, it is better to leave out things from a binding
until it is very clear it is needed and is the right thing
to do.
Segher
^ permalink raw reply
* Re: Linuxppc-embedded Digest, Vol 35, Issue 33
From: Scott Wood @ 2007-07-17 16:02 UTC (permalink / raw)
To: suresh suresh; +Cc: linuxppc-embedded, Siva Prasad
In-Reply-To: <e5eb93010707162259l2e78c524s32ff260b3d930bdb@mail.gmail.com>
suresh suresh wrote:
> MPC8280 has internal memory space which contains Dualport(Dp) RAM. In the
> DpRAM we allocate some tables and these has to store pointer of the buffers
> which are allocated in external memory. Core will use this pointer to
> access
> the buffers, basically these buffers are used for DMA.
>
> Using IMMR register we can get physical address of the internal memory. Now
> can I store the address return by the kmalloc() function? or I should
> convert it into physical?
Yes, you need to convert it to physical. As I said earlier, use the DMA
mapping API (described in Documentation/DMA-mapping.txt) to do so.
Specifically, look at the dma_map_single() function.
-Scott
^ permalink raw reply
* Re: [PATCH 2/3] 82xx: Parse SMC serial device node in DTS
From: Scott Wood @ 2007-07-17 16:06 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200707171618.54903.arnd@arndb.de>
Arnd Bergmann wrote:
> On Tuesday 17 July 2007, Mark Zhan wrote:
>
>>>Well, AFAICS, all of them currently use scc. The 8xx platforms don't
>>>even build correctly in the mainline kernel, so I guess it would
>>>be good to change them to also list fsl,cpm-smc in the compatible
>>>property.
>>
>>That probably could be done by another series of patches, and I really
>>don't want to introduce those kinds of patches in my BSP patches. I
>>don't know if the 8xx/82xx series patches from Scott Wood will cover
>>this issue or not.
>
>
> I guess he can best answer that himself. Scott, what are your plans
> to deal with the different types of cpm ports?
My patchset converts the CPM enet and serial drivers to of platform
devices when CONFIG_PPC_MERGE is defined, and signficantly overhauls the
device tree binding. A 885 CPM UART would have a compatible like this:
compatible = "fsl,mpc885-smc-uart", "fsl,cpm1-smc-uart",
"fsl,cpm1-uart", "fsl,cpm-smc-uart", "fsl,cpm-uart";
-Scott
^ permalink raw reply
* [PATCH] iommu virtual merge no longer experimental
From: Linas Vepstas @ 2007-07-17 16:09 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Benjamin Herrenschmidt, Arnd Bergmann, Tim Schimke
Per conversations with BenH, iommu virtual merging should no longer
be considered to be an "experimental" feature. In particular,
CONFIG_VMERGE has been set to "y" in te defconfigs for quite a while.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/Kconfig | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
Index: linux-2.6.22-git2/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.22-git2.orig/arch/powerpc/Kconfig 2007-07-08 18:32:17.000000000 -0500
+++ linux-2.6.22-git2/arch/powerpc/Kconfig 2007-07-17 11:08:18.000000000 -0500
@@ -430,16 +430,17 @@ config MATH_EMULATION
instructions to run.
config IOMMU_VMERGE
- bool "Enable IOMMU virtual merging (EXPERIMENTAL)"
- depends on EXPERIMENTAL && PPC64
- default n
+ bool "Enable IOMMU virtual merging"
+ depends on PPC64
+ default y
help
Cause IO segments sent to a device for DMA to be merged virtually
by the IOMMU when they happen to have been allocated contiguously.
This doesn't add pressure to the IOMMU allocator. However, some
drivers don't support getting large merged segments coming back
- from *_map_sg(). Say Y if you know the drivers you are using are
- properly handling this case.
+ from *_map_sg().
+
+ Most drivers don't have this problem; it is safe to say Y here.
config HOTPLUG_CPU
bool "Support for enabling/disabling CPUs"
^ permalink raw reply
* Re: [PATCH 1/3] 82xx: some 82xx platform hook functions can be shared by different boards
From: Scott Wood @ 2007-07-17 16:15 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707170259.47098.arnd@arndb.de>
On Tue, Jul 17, 2007 at 02:59:46AM +0200, Arnd Bergmann wrote:
> This is a step in the wrong direction. CPUINFO_{VENDOR,MACHINE}
> comes from a platform specific header file, so you can not
> use these definitions in platform independent code without
> breaking multiplatform kernels.
My patchset just drops the vendor field, and uses ppc_md.name for the
machine name. The vendor name can be included in the latter.
> I know you're just moving that code, but it looks horribly wrong
> nonetheless. cpm2_immr is an __iomem variable, so you must not
> dereference it but instead should use the in_8() macro to
> access it.
>
> Once you get that right, you don't need the volatile variable
> any more.
My patchset addresses this.
-Scott
^ permalink raw reply
* Re: [PATCH] Add StorCenter DTS first draft.
From: Josh Boyer @ 2007-07-17 16:26 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <630B6BC9-389F-4F5C-AE8F-9C3131C4543E@kernel.crashing.org>
On Tue, 2007-07-17 at 16:57 +0200, Segher Boessenkool wrote:
>
> > + flash@ff800000 {
> > + device_type = "rom";
>
> I'm sure you know I find this "rom" binding to be crap.
> However, I didn't yet write up the "cfi" binding, so I
> can't complain ;-)
Not all chips are CFI compliant. Be sure to write up the "jedec" and
"nand" bindings while you're at it ;)
josh
^ permalink raw reply
* Re: Machine check exception. 2.6.20 powerpc tree.
From: Kumar Gala @ 2007-07-17 16:29 UTC (permalink / raw)
To: Ramirez-Ortiz, Jorge; +Cc: linuxppc-embedded
In-Reply-To: <35786B99AB3FDC45A8215724617919730136DA91@gbrwgceumf01.eu.xerox.net>
On Jul 17, 2007, at 9:21 AM, Ramirez-Ortiz, Jorge wrote:
> Running our multithreaded application on ppc8548 (E500 core) =20
> generates a machine check exception when trying to access some =20
> ASIC=92s registers mapped on the PCI space (This application maps a =20=
> PCI device to access its registers)
>
>
>
> machine_check_exception: task my_process, MCSR=3D0x10008, =
NIP=3D0x10153530
>
> Machine check in user mode.
>
> Caused by (from MCSR=3D10008): Guarded Load or Cache-Inhibited stwcx.
>
> Bus - Read Data Bus Error
>
>
>
> Here is the assembly dump of the region of code containing the =20
> offending instruction in user-space, with SRR0 pointing us at =20
> 0x10153530 when the exception is raised:
>
>
>
> 0x10153528 <_ZN2vk7in_le32EPVKj+16>: lwz r0,8(r31)
>
> 0x1015352c <_ZN2vk7in_le32EPVKj+20>: lwz r9,8(r31)
>
> 0x10153530 <_ZN2vk7in_le32EPVKj+24>: lwbrx r0,0,r0
>
> 0x10153534 <_ZN2vk7in_le32EPVKj+28>: twi 0,r0,0
>
> 0x10153538 <_ZN2vk7in_le32EPVKj+32>: isync
Can you get the code to dump the value of r0. I'm wondering if =20
you're really getting a read data bus error due to the fact that r0 =20
is pointing to a PCI address that doesn't have a device that will =20
respond.
- k
^ permalink raw reply
* Re: [PATCH] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Kumar Gala @ 2007-07-17 16:30 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, Paul Mackerras, Arnd Bergmann, David Gibson
In-Reply-To: <4CB813ED-9D8B-4A32-B4AC-65D27741D46C@kernel.crashing.org>
On Jul 17, 2007, at 10:18 AM, Segher Boessenkool wrote:
>>>>> Yeah. Giving the warning is a good thing though.
>>>>
>>>> No, it isn't; it's just noise, if we're not ever going to do
>>>> anything
>>>> to prevent the behaviour - and we can't.
>>>
>>> The same userland code will not run correctly on PPC64 or BookE
>>> systems. Is that not a reason to warn?
>>
>> Way back when, I distinctly recall aborting my plans to implement
>> per-page exec on 40x, precisely because of executables like this.
>
> I noticed some comments to that effect in the BookE code,
> yes. It seems userland has been fixed enough that you
> could think about enabling it again FWIW.
Did I miss the posting of the patch with the fix?
- k
^ permalink raw reply
* Re: [PATCH 3/3] 82xx: SBCPQ2 board platform support
From: Segher Boessenkool @ 2007-07-17 16:30 UTC (permalink / raw)
To: Mark Zhan; +Cc: linuxppc-dev, paulus, Arnd Bergmann
In-Reply-To: <1184679661.18501.41.camel@mark>
>>>>> + np = of_find_compatible_node(NULL, "cpm-pic", "CPM2");
>>>>> + if (np == NULL) {
>>>>> + printk(KERN_ERR "PIC init: can not find cpm-pic node\n");
>>>>> + return;
>>>>> + }
>>>>
>>>> This looks like your device tree is wrong. Shouldn't the interrupt
>>>> controller have device_type="interrupt-controller" and a specific
>>>> compatible property instead of having the name in the device_type?
So, I looked it up :-)
The device_type should specify the specific interrupt
controller programming model, because a real OF typically
needs to know the meaning of the interrupt specifiers;
also, when the interrupt binding recommended practice
isn't used, it is needed to know the #interrupt-cells
(which is implicit from the device_type in that case).
If there is no defined binding for your interrupt
controller, just don't put a device_type in your tree at
all, for flat device trees.
>>> Here, I just copy the codes from mpc82xx_ads, is there anything
>>> wrong?
>>
>> I just checked the Recommended Practice document for interrupt
>> mapping
>> and it seems that it's ok. The interrupt controller needs to have
>> an property named "interrupt-controller", but does not need a
>> specific
>> device_type. So it appears to be correct here.
Please also look at the base specifications, not just
the imap thing. But you reached the correct conclusion.
Segher
^ permalink raw reply
* Re: [PATCH] POWERPC: Added RTC support for mpc8313RDB and utilize "clock-frequency"
From: Scott Wood @ 2007-07-17 16:36 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070717004913.21682.50282.stgit@localhost.localdomain>
On Tue, Jul 17, 2007 at 04:49:13AM +0400, Vitaly Bordug wrote:
> + np = of_find_node_by_type(NULL, "cpu");
> + if (np != 0) {
> + const unsigned int *fp =
> + get_property(np, "clock-frequency", NULL);
> + if (fp != 0)
> + loops_per_jiffy = *fp / HZ;
> + else
> + loops_per_jiffy = 50000000 / HZ;
> + of_node_put(np);
> + }
This is not necessary. It's only used for /proc/cpuinfo (delays are done
using tb_ticks_per_usec), and it'll be overwritten by the generic
calibrate_delay() anyway.
We should be removing this from board files that have it, not adding it
to ones that don't.
> +#if defined (CONFIG_SENSORS_DS1337) && defined (CONFIG_I2C)
> +
> +extern int ds1337_do_command(int id, int cmd, void *arg);
> +extern spinlock_t rtc_lock;
> +#define DS1337_GET_DATE 0
> +#define DS1337_SET_DATE 1
> +
> +static void mpc8313rdb_get_rtc_time(struct rtc_time *tm)
> +{
> + int result;
> +
> + result = ds1337_do_command(0, DS1337_GET_DATE, tm);
> +
> + if (result == 0)
> + result = mktime(tm->tm_year, tm->tm_mon, tm->tm_mday, tm->tm_hour, tm->tm_min, tm->tm_sec);
> +}
> +
> +static int mpc8313rdb_set_rtc_time(struct rtc_time *tm)
> +{
> + int result;
> +
> + result = ds1337_do_command(0, DS1337_SET_DATE, tm);
> +
> + return result;
> +}
> +
> +static int __init rtc_hookup(void)
> +{
> + ppc_md.get_rtc_time = mpc8313rdb_get_rtc_time;
> + ppc_md.set_rtc_time = mpc8313rdb_set_rtc_time;
> + return 0;
> +}
> +late_initcall(rtc_hookup);
> +#endif
Please don't do this; drivers/i2c/chips/ds1337.c is deprecated. You
should be using the RTC-class driver in drivers/rtc/rtc-ds1307.c, which
has a non-device-specific API that can be used.
The ppc_md RTC functions should really just go away, though -- setting
the clock on bootup can be done by generic code, and periodically
updating the RTC when using NTP can be done from userspace.
-Scott
^ permalink raw reply
* Re: [PATCH] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Segher Boessenkool @ 2007-07-17 16:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, Arnd Bergmann, David Gibson
In-Reply-To: <B07FAF3D-A8F4-45F5-8EEF-4506F4A31DF2@kernel.crashing.org>
>>> Way back when, I distinctly recall aborting my plans to implement
>>> per-page exec on 40x, precisely because of executables like this.
>>
>> I noticed some comments to that effect in the BookE code,
>> yes. It seems userland has been fixed enough that you
>> could think about enabling it again FWIW.
>
> Did I miss the posting of the patch with the fix?
glibc-2.2 seems to be the last "bad" one. We are at
glibc-2.6 or so nowadays...
Segher
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox