* Re: [CURIOUSITY] When will we stop caring about arch/ppc?
From: Josh Boyer @ 2007-06-25 20:50 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <0FBD8D7C-1A60-4305-992C-5C28ECE41278@kernel.crashing.org>
On Mon, 2007-06-25 at 14:42 -0500, Kumar Gala wrote:
> On Jun 25, 2007, at 1:40 PM, Josh Boyer wrote:
>
> > On Mon, 2007-06-25 at 11:23 -0700, Mark A. Greer wrote:
> >> Any opinions on when we stop worrying about arch/ppc and start
> >> getting
> >> rid of it for real?
> >
> > There are lots of boards in the 4xx family that don't exist yet in
> > powerpc. I don't think we want it to die until they get moved
> > over, or
> > at least marked as in a "danger zone" for a while.
>
> Agreed, we need to go through and figure out what all really needs to
> get moved over for other boards. I know 4xx has only one board
> supported in arch/powerpc and I dont believe the support is complete.
Right. Ebony boots at least. Needs PCI to be completed. There are
lots of other 44x boards that should probably be brought over and are in
various stages of completion. Bamboo, Taishan, Sequoia, Katmai, etc.
For 40x, I hope to get working on a Walnut port soon. Not sure much
else is really needed there.
There's also the Xilinx boards.
> > Maybe what we could do is designate a kernel release where we'll stop
> > taking new arch/ppc submissions?
>
> I think we stopped taking new submissions to arch/ppc a while ago...
> someone sneak something in on us? We tend to only do bug fixes or
> deal with issues related to moving things between arch/ppc & arch/
> powerpc.
Well, there's definitely been an aversion to it. But I meant adding
something in the Documentation/powerpc/ directory and maybe
feature-removal-schedule.txt. Basically a written down thing in the
kernel source to refer people to.
josh
^ permalink raw reply
* Re: [PATCH v2] pcmcia: CompactFlash driver for PA Semi Electra boards
From: Olof Johansson @ 2007-06-25 20:43 UTC (permalink / raw)
To: Christoph Hellwig, linux-kernel, linux-pcmcia, linuxppc-dev,
Russell King
In-Reply-To: <20070625193909.GA26021@infradead.org>
On Mon, Jun 25, 2007 at 08:39:09PM +0100, Christoph Hellwig wrote:
> On Mon, Jun 25, 2007 at 12:12:21PM -0500, Olof Johansson wrote:
> > Driver for the CompactFlash slot on the PA Semi Electra eval board. It's
> > a simple device sitting on localbus, with interrupts and detect/voltage
> > control over GPIO.
> >
> > The driver is implemented as an of_platform driver, and adds localbus
> > as a bus being probed by the of_platform framework.
>
> Looks good to me. The only odd thing is the inconsistant use of
> #ifdef CONFIG_PCMCIA in setup.c.
Thanks, and thanks for the review.
The ifdef is needed since for CONFIG_PCMCIA=n builds, the bus notifier
isn't available. I wanted to do the bus notifier registration explicitly
before the of_platform bus probe to avoid later surprises due to reordered
initcalls in case it was split up in it's own initcall.
I could add the code under ifdef as well, but it didn't seem too
critical. Once the second major board comes along I'll probably move it
out to a per-board file, there's no real need for it just yet.
-Olof
^ permalink raw reply
* Re: [CURIOUSITY] When will we stop caring about arch/ppc?
From: Kumar Gala @ 2007-06-25 19:42 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1182796800.23775.51.camel@weaponx.rchland.ibm.com>
On Jun 25, 2007, at 1:40 PM, Josh Boyer wrote:
> On Mon, 2007-06-25 at 11:23 -0700, Mark A. Greer wrote:
>> Any opinions on when we stop worrying about arch/ppc and start
>> getting
>> rid of it for real?
>
> There are lots of boards in the 4xx family that don't exist yet in
> powerpc. I don't think we want it to die until they get moved
> over, or
> at least marked as in a "danger zone" for a while.
Agreed, we need to go through and figure out what all really needs to
get moved over for other boards. I know 4xx has only one board
supported in arch/powerpc and I dont believe the support is complete.
> Maybe what we could do is designate a kernel release where we'll stop
> taking new arch/ppc submissions?
I think we stopped taking new submissions to arch/ppc a while ago...
someone sneak something in on us? We tend to only do bug fixes or
deal with issues related to moving things between arch/ppc & arch/
powerpc.
- k
^ permalink raw reply
* RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
From: Greg Crocker @ 2007-06-25 19:42 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 409 bytes --]
I was able to achieve ~320 Mbit/sec data rate using the Gigabit System
Reference Design (GSRD XAPP535/536) from Xilinx. This utilizes the
LocalLink TEMAC to perform the transfers. The reference design provides the
Linux 2.4 drivers that can be ported to Linux 2.6 with a little effort.
This implementation did not use checksum offloading and the data rates were
achieved using TCP_STREAM on netperf.
Greg
[-- Attachment #2: Type: text/html, Size: 443 bytes --]
^ permalink raw reply
* Re: [PATCH v2] pcmcia: CompactFlash driver for PA Semi Electra boards
From: Christoph Hellwig @ 2007-06-25 19:39 UTC (permalink / raw)
To: Olof Johansson
Cc: Christoph Hellwig, linuxppc-dev, Russell King, linux-pcmcia,
linux-kernel
In-Reply-To: <20070625171221.GA6684@lixom.net>
On Mon, Jun 25, 2007 at 12:12:21PM -0500, Olof Johansson wrote:
> Driver for the CompactFlash slot on the PA Semi Electra eval board. It's
> a simple device sitting on localbus, with interrupts and detect/voltage
> control over GPIO.
>
> The driver is implemented as an of_platform driver, and adds localbus
> as a bus being probed by the of_platform framework.
Looks good to me. The only odd thing is the inconsistant use of
#ifdef CONFIG_PCMCIA in setup.c.
^ permalink raw reply
* Katmai w/ DENX git - "init has generated signal 4" error
From: Stephen Winiecki @ 2007-06-25 19:03 UTC (permalink / raw)
To: linuxppc-embedded
I'm using the Denx linux-2.6-denx.git repository with a Katmai board. I
want to boot off a disk (initialized w/ Debian 4.0). I've installed a
Promise Ultra133 Tx2 IDE controller card in the PCI slot, and configured
it in the kernel. I boot this same disk w/ IDE card on other 4xx boards
without a problem (Bamboo w/ Denx 4.1 for example). I am getting an error
"init has generated signal 4 but has no handler for it".
## Booting image at 00200000 ...
Image Name: Linux-2.6.22-rc5-gc8144983-dirty
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1328285 Bytes = 1.3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Linux version 2.6.22-rc5-gc8144983-dirty (root@cellhost.raleigh.ibm.com)
(gcc ve
rsion 4.0.0 (DENX ELDK 4.1 4.0.0)) #4 Mon Jun 25 13:59:54 EDT 2007
AMCC PowerPC 440SPe Katmai Platform
Zone PFN ranges:
DMA 0 -> 131072
Normal 131072 -> 131072
early_node_map[1] active PFN ranges
0: 0 -> 131072
Built 1 zonelists. Total pages: 130048
Kernel command line: console=ttyS0,115200 root=/dev/hde3 rw ip=dhcp
PID hash table entries: 2048 (order: 11, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 516864k available (2008k kernel code, 676k data, 160k init, 0k
highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 16384 (order: 4, 65536 bytes)
TCP established hash table entries: 65536 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 65536 bind 65536)
TCP reno registered
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
serial8250: ttyS2 at MMIO 0x0 (irq = 37) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
xsysace xsysace.0: Xilinx SystemACE revision 1.0.12
xsysace xsysace.0: capacity: 256512 sectors
xsa: xsa1
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2
Copyright (c) 1999-2006 Intel Corporation.
PPC 4xx OCP EMAC driver, version 3.54
mal0: initialized, 1 TX channels, 1 RX channels
eth0: emac0, MAC 00:01:73:77:55:27
eth0: found Generic MII PHY (0x01)
e100: Intel(R) PRO/100 Network Driver, 3.5.17-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
PDC20269: IDE controller at PCI slot 0000:00:01.0
PDC20269: chipset revision 2
PDC20269: ROM enabled at 0x000dc000
PDC20269: PLL input clock is 33309 kHz
PDC20269: 100% native mode on irq 52
ide2: BM-DMA at 0xffd0-0xffd7, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xffd8-0xffdf, BIOS settings: hdg:pio, hdh:pio
hde: FUJITSU MHT2040AH, ATA DISK drive
hde: host side 80-wire cable detection failed, limiting max speed to
UDMA33
ide2 at 0xfff8-0xffff,0xfff6 on irq 52
hde: max request size: 128KiB
hde: 78140160 sectors (40007 MB) w/8192KiB Cache, CHS=65535/16/63,
UDMA(33)
hde: cache flushes supported
hde: hde1 hde2 hde3
i2c /dev entries driver
IBM IIC driver v2.1
ibm-iic0: using standard (100 kHz) mode
ds1307 1-0068: rtc core: registered ds1307 as rtc0
ibm-iic1: using standard (100 kHz) mode
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
ds1307 1-0068: setting the system clock to 2000-04-30 08:13:25 (957082405)
eth0: link is up, 100 FDX
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 255.255.255.255, my address is
9.27.218.226
IP-Config: Complete:
device=eth0, addr=9.27.218.226, mask=255.255.255.128,
gw=9.27.218.129,
host=9.27.218.226, domain=raleigh.ibm.com, nis-domain=(none),
bootserver=255.255.255.255, rootserver=255.255.255.255, rootpath=
kjournald starting. Commit interval 5 seconds
EXT3 FS on hde3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem).
Freeing unused kernel memory: 160k init
init has generated signal 4 but has no handler for it
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 180 seconds..
Not sure if I'm missing something obvious - any help appreciated.
Thanks,
Steve
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Vladislav Buzov @ 2007-06-25 19:00 UTC (permalink / raw)
To: segher; +Cc: linuxppc-dev
In-Reply-To: <db0d38e5b5e1a9a3a7fe35d25ebd357a@kernel.crashing.org>
Segher Boessenkool wrote:
>> I read the MPC7450 reference manual and it describes a method to flush
>> the cache using L2 hardware flushing feature. The cache flushing
>> procedure consist of several steps and some of them are dictated by
>> MPC7448 errata (www.freescale.com/files/32bit/doc/errata/MPC7448CE.pdf,
>> Erratum no.3).
>
>
> Are these errata 7448-only? If not, I wonder what is
> done on PowerMacs?
>
>> First, I'm looking for a help and advice why the current _set_L2CR()
>> implementation may not work for MPC7450 (namely 7448 with 1Mb L2 cache
>> installed). Is it a bug in _set_L2CR() or a hardware problem.
>
>
> I think that if anyone here could answer this straight
> away, the source code would have been fixed already ;-)
I think I can try to answer this question. Please, look through my
thoughts below and correct me if I'm somewhere wrong.
The current scheme of flushing the caches is based on a number of
consecutive lwz/dcbf instructions. A contiguous memory region (started
from zero) is read by series of lwz commands and then cache is flushed
using a sequence of dcbf instructions with addresses from this memory
range. If I understand correctly, to get this approach working it is
required to guarantee that after reading the memory region, each line in
a cache should be used and keep data from this region. Otherwise, if
some cache lines keep data from another address range they will not be
flushed by the dcbf instructions sequence.
Further, how cache lines are utilized is dictated by a cache lines
replacement policy. I didn't go in to details deeply, but on MPC7450 L1
cache lines replacement policy seems to satisfy the requirement above.
At least the MPC7450 reference manual describes L1 cache flushing
algorithm based on a sequence of lwz/dcbf instructions.
But regarding to L2/L3 caches, the manual describes two different cache
line replacement policies. And the both are pseudo-random and differ by
implementation of random number generator. It means that a cache line in
a set is chosen randomly, and that, in turn, means that there is a
probability that some cache lines are not used during reading of the
contiguous memory region and not flushed by the dcbf instruction sequence.
For example, on MPC7448 there is a eight-way set-associative 1Mb L2
cache that consist of 2048 sets x 8 ways per set. And even if a set N
has been accessed M times (M > 8) there is a chance that some cache line
is set N has never been used, but another line has been used twice or
more. Of course, the probability of such situation decreases with
increasing of N.
Current _set_L2CR() implementation reads first 4Mb of memory to flush
the L2 cache. I have increased this size up to 16 Mb and now things work
fine. But I don't think that is a right way to fix the problem because
there is no any way to define the upper limit of memory size to
guarantee flushing of each cache line. 16Mb is too large though. It
seems more reasonable to use a stable and guaranteed way to flush the
cache implemented in hardware.
Vlad.
>
>> I've
>> mentioned above about MPC7450 hardware bug in L2 hardware flushing
>> mechanism. May it be applicable to common cache flushing procedure based
>> on sequence of lwz/dcbf instructions?
>
>
> Dunno, too lazy to download that PDF, perhaps you can
> quote the relevant part?
>
>> Second, Is this patch acceptable?
>
>
> Looks reasonable enough to me... if it works (on all
> things considered "7450" by the kernel).
>
>> /* TODO: use HW flush assist when available */
>
>
> You want to get rid of this old comment though -- and
> perhaps branch over the non-hardware-assisted cache
> flushing code.
>
>
> Segher
>
^ permalink raw reply
* Re: [CURIOUSITY] When will we stop caring about arch/ppc?
From: Josh Boyer @ 2007-06-25 18:40 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20070625182304.GC31840@mag.az.mvista.com>
On Mon, 2007-06-25 at 11:23 -0700, Mark A. Greer wrote:
> Any opinions on when we stop worrying about arch/ppc and start getting
> rid of it for real?
There are lots of boards in the 4xx family that don't exist yet in
powerpc. I don't think we want it to die until they get moved over, or
at least marked as in a "danger zone" for a while.
Maybe what we could do is designate a kernel release where we'll stop
taking new arch/ppc submissions?
josh
^ permalink raw reply
* [CURIOUSITY] When will we stop caring about arch/ppc?
From: Mark A. Greer @ 2007-06-25 18:23 UTC (permalink / raw)
To: linuxppc-dev
Any opinions on when we stop worrying about arch/ppc and start getting
rid of it for real?
Mark
^ permalink raw reply
* Re: Mem-2-Mem DMA - Generalized API
From: Clifford Wolf @ 2007-06-25 18:01 UTC (permalink / raw)
To: Matt Sealey; +Cc: Arnd Bergmann, linuxppc-embedded
In-Reply-To: <467FD1DF.4000602@genesi-usa.com>
Hi,
On Mon, Jun 25, 2007 at 03:31:59PM +0100, Matt Sealey wrote:
> > The main question remains: Is it possible to have a flexible cross platform
> > DMA API which handles even complex requests and does scheduling,
> > prioritizing, queuing, locking, (re-)building/caching of SG lists... automagically.
>
> I would think so. I think there is a fairly generic example in many parts
> of the Linux kernel. Dare I say the Via Unichrome AGP subsystem? And a
> bunch of the ARM/OMAP platforms..? A lot of the code is even identical,
> I wonder why it isn't some library rather than platform drivers.
I've put a 'draft header file' of an api as I would have expected it
online:
http://www.clifford.at/priv/dmatransfer.h
I'd love to hear your feedback on it.
One issue I'm absolutely not sure about atm are the different busses and
their address spaces. The design in the header file is working directly on
'bus addresses' (the thing accessable thru /dev/mem). Does anyone know a
case where this may be insufficient?
> > Filling memory with zero is also a simple task for a DMA engine.
> > (Thinking about malloc() and memset())
>
> Also xor and logical operations, byte swapping huge chunks of data, that
> kind of thing. Most DMA engines in SoCs have cute features like that. I
> think BestComm can even calculate CRCs for IP packets.
I havent added it yet but such things could be encoded using the
DMATRANSFER_CHUNK_* and DMATRANSFER_* flags.
However, i don't think that implementing stuff like memset() in a dma
controller is any good because that would just flood the memory bus which
would then block in 99% of all cases the cpu until the dma is finished.
It would however cost less power than doing that in the CPU. ;-)
> Indeed. I wonder if we could pull apart the IOAT/DMA stuff and genericise
> it (it should be possible) or simply add to it, or if making a powerpc
> specific dma engine abstraction would be an easier idea.
I don't think that this would actually be powerpc specific in any way. But
since such general purpose dma controllers are more common in embedded
hardware this still seams to be the right place to discuss the issue.
yours,
- clifford
--
Relax, its only ONES and ZEROS!
^ permalink raw reply
* Re: Mem-2-Mem DMA - Generalized API
From: Clifford Wolf @ 2007-06-25 17:48 UTC (permalink / raw)
To: Olof Johansson; +Cc: Arnd Bergmann, linuxppc-embedded
In-Reply-To: <20070625170003.GA6484@lixom.net>
Hi,
On Mon, Jun 25, 2007 at 12:00:03PM -0500, Olof Johansson wrote:
> That's the case with the dma engine framework today. Expand it, extend
> it, fix it and improve it. Don't duplicate, re-invent and re-implement.
I'm not sure if I can agree with that.
The core idea befind the dma engine framework seams to be to statically
assign dma channels to device drivers. I think that the channels should
be dynamically assigned.
Imo writing an alternative implementation is much easier than hacking that
into the existing framework. Especially since the existing framework has
only one backend driver and only one user.
yours,
- clifford
--
/* You are not expected to understand this */
^ permalink raw reply
* RE: Follow up on 4 Gig of DDR on MPC8548E
From: Rune Torgersen @ 2007-06-25 17:23 UTC (permalink / raw)
To: Morrison, Tom, linuxppc-dev, ltib, linuxppc-embedded
In-Reply-To: <BD261180E6D35F4D9D32F3E44FD3D90108361D90@EMPBEDEX.empirix.com>
> From: Morrison, Tom
> Sent: Friday, June 22, 2007 12:50 PM
> Setup:
> 1) 4 Gig of DDR RAM (at physical addresses 0-0xF_FFFF_FFFF)
0x0000_0000 to 0xffff_ffff or do you have 64GB of mem...
> >> EXT2-fs warning: mounting unchecked fs, running e2fsck is=20
> recommended
> >> VFS: Mounted root (ext2 filesystem).
> >> 316k init
> >> EXT2-fs error (device sda1): ext2_check_page: bad entry in=20
> directory
> #2: >> unaligned directory entry - offset=3D0, inode=3D128,
> rec_len=3D8961,name_len=3D69
> >> Warning: unable to open an initial console.
> My gut tells me this might be something to do with the 2=20
> Gig boundary and specifically a "signed" versus "unsigned"=20
> address/offsets mismatch maybe somewhere in the file system??
If you have all physical mem in the first 32bit, where are your PCI
windows set?
And in modst cases the PCI devices (if they are bus-mastring ) need 1-1
inbound mapping to be able to write to memory.
^ permalink raw reply
* Re: [patch] powerpc: sysfs fix compiler warning
From: Christian Krafft @ 2007-06-25 17:07 UTC (permalink / raw)
To: Michael Buesch; +Cc: linuxppc-dev
In-Reply-To: <200706231146.54959.mb@bu3sch.de>
[-- Attachment #1: Type: text/plain, Size: 2150 bytes --]
On Sat, 23 Jun 2007 11:46:54 +0200
Michael Buesch <mb@bu3sch.de> wrote:
> On Friday 22 June 2007 19:48:53 Christian Krafft wrote:
> > From: Christian Krafft <krafft@de.ibm.com>
> >
> > This patch fixes the following compiler warning:
> > arch/powerpc/kernel/sysfs.c:385: warning: ignoring return value of
> > `sysfs_create_group',
> >
> > Signed-off-by: Christian Krafft <krafft@de.ibm.com>
> >
> > Index: linux-2.6.22-rc5/arch/powerpc/kernel/sysfs.c
> > ===================================================================
> > --- linux-2.6.22-rc5.orig/arch/powerpc/kernel/sysfs.c
> > +++ linux-2.6.22-rc5/arch/powerpc/kernel/sysfs.c
> > @@ -380,16 +380,23 @@ int cpu_add_sysdev_attr_group(struct att
> > {
> > int cpu;
> > struct sys_device *sysdev;
> > + int error;
Looks like I introduced a new warning while fixing another.
Have checked the patch with sparse just after sending it ;-)
> >
> > mutex_lock(&cpu_mutex);
> >
> > for_each_possible_cpu(cpu) {
> > sysdev = get_cpu_sysdev(cpu);
> > - sysfs_create_group(&sysdev->kobj, attrs);
> > + error |= sysfs_create_group(&sysdev->kobj, attrs);
>
> That is probably dangerous, if multiple sysfs_create_group fail
> with different error codes. So it will wiggle the error codes
> together.
Yeah, that's right, will fix it to do a break in case of error.
>
> > }
> >
> > + if(error)
> {
> > + for_each_possible_cpu(cpu) {
> > + sysdev = get_cpu_sysdev(cpu);
> > + sysfs_remove_group(&sysdev->kobj, attrs);
> > + }
> probably do something like
> error = -ENOENT;
> }
> or some other error code here to fix it.
> > +
> > mutex_unlock(&cpu_mutex);
> > - return 0;
> > + return error;
> > }
> > EXPORT_SYMBOL_GPL(cpu_add_sysdev_attr_group);
> >
> >
> >
>
>
>
--
Mit freundlichen Gruessen,
kind regards,
Christian Krafft
IBM Systems & Technology Group,
Linux Kernel Development
IT Specialist
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Herbert Kircher
Sitz der Gesellschaft: Boeblingen
Registriergericht: Amtsgericht Stuttgart, HRB 243294
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH v2] pcmcia: CompactFlash driver for PA Semi Electra boards
From: Olof Johansson @ 2007-06-25 17:12 UTC (permalink / raw)
To: linux-kernel, linux-pcmcia; +Cc: Christoph Hellwig, linuxppc-dev, Russell King
In-Reply-To: <20070625010311.GA31355@lixom.net>
Driver for the CompactFlash slot on the PA Semi Electra eval board. It's
a simple device sitting on localbus, with interrupts and detect/voltage
control over GPIO.
The driver is implemented as an of_platform driver, and adds localbus
as a bus being probed by the of_platform framework.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
Chances since last post:
* Comments from Christoph:
- Moved bus notifier to arch code
- Checking for bus (socket driver) type before changing dma ops
Index: mainline/drivers/pcmcia/Kconfig
===================================================================
--- mainline.orig/drivers/pcmcia/Kconfig
+++ mainline/drivers/pcmcia/Kconfig
@@ -270,6 +270,13 @@ config AT91_CF
Say Y here to support the CompactFlash controller on AT91 chips.
Or choose M to compile the driver as a module named "at91_cf".
+config ELECTRA_CF
+ bool "Electra CompactFlash Controller"
+ depends on PCMCIA=y && PPC_PASEMI
+ help
+ Say Y here to support the CompactFlash controller on the
+ PA Semi Electra eval board.
+
config PCCARD_NONSTATIC
tristate
Index: mainline/drivers/pcmcia/Makefile
===================================================================
--- mainline.orig/drivers/pcmcia/Makefile
+++ mainline/drivers/pcmcia/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_PCMCIA_VRC4171) += vrc417
obj-$(CONFIG_PCMCIA_VRC4173) += vrc4173_cardu.o
obj-$(CONFIG_OMAP_CF) += omap_cf.o
obj-$(CONFIG_AT91_CF) += at91_cf.o
+obj-$(CONFIG_ELECTRA_CF) += electra_cf.o
sa11xx_core-y += soc_common.o sa11xx_base.o
pxa2xx_core-y += soc_common.o pxa2xx_base.o
Index: mainline/drivers/pcmcia/electra_cf.c
===================================================================
--- /dev/null
+++ mainline/drivers/pcmcia/electra_cf.c
@@ -0,0 +1,359 @@
+/*
+ * Copyright (C) 2007 PA Semi, Inc
+ *
+ * Maintained by: Olof Johansson <olof@lixom.net>
+ *
+ * Based on drivers/pcmcia/omap_cf.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/sched.h>
+#include <linux/platform_device.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+
+#include <pcmcia/ss.h>
+#include <asm/of_platform.h>
+
+static const char driver_name[] = "electra-cf";
+
+struct electra_cf_socket {
+ struct pcmcia_socket socket;
+
+ struct timer_list timer;
+ unsigned present:1;
+ unsigned active:1;
+
+ struct of_device *ofdev;
+ unsigned long mem_phys;
+ void __iomem * mem_base;
+ unsigned long mem_size;
+ void __iomem * io_virt;
+ unsigned int io_base;
+ unsigned int io_size;
+ u_int irq;
+ struct resource iomem;
+ void __iomem * gpio_base;
+ int gpio_detect;
+ int gpio_vsense;
+ int gpio_3v;
+ int gpio_5v;
+};
+
+#define POLL_INTERVAL (2 * HZ)
+
+
+static int electra_cf_present(struct electra_cf_socket *cf)
+{
+ unsigned int gpio;
+
+ gpio = in_le32(cf->gpio_base+0x40);
+ return !(gpio & (1 << cf->gpio_detect));
+}
+
+static int electra_cf_ss_init(struct pcmcia_socket *s)
+{
+ return 0;
+}
+
+/* the timer is primarily to kick this socket's pccardd */
+static void electra_cf_timer(unsigned long _cf)
+{
+ struct electra_cf_socket *cf = (void *) _cf;
+ int present = electra_cf_present(cf);
+
+ if (present != cf->present) {
+ cf->present = present;
+ pcmcia_parse_events(&cf->socket, SS_DETECT);
+ }
+
+ if (cf->active)
+ mod_timer(&cf->timer, jiffies + POLL_INTERVAL);
+}
+
+static irqreturn_t electra_cf_irq(int irq, void *_cf)
+{
+ electra_cf_timer((unsigned long)_cf);
+ return IRQ_HANDLED;
+}
+
+static int electra_cf_get_status(struct pcmcia_socket *s, u_int *sp)
+{
+ struct electra_cf_socket *cf;
+
+ if (!sp)
+ return -EINVAL;
+
+ cf = container_of(s, struct electra_cf_socket, socket);
+
+ /* NOTE CF is always 3VCARD */
+ if (electra_cf_present(cf)) {
+ struct electra_cf_socket *cf;
+
+ *sp = SS_READY | SS_DETECT | SS_POWERON | SS_3VCARD;
+ cf = container_of(s, struct electra_cf_socket, socket);
+ s->pci_irq = cf->irq;
+ } else
+ *sp = 0;
+ return 0;
+}
+
+static int electra_cf_set_socket(struct pcmcia_socket *sock,
+ struct socket_state_t *s)
+{
+ unsigned int gpio;
+ unsigned int vcc;
+ struct electra_cf_socket *cf;
+
+ cf = container_of(sock, struct electra_cf_socket, socket);
+
+ /* "reset" means no power in our case */
+ vcc = (s->flags & SS_RESET) ? 0 : s->Vcc;
+
+ switch (vcc) {
+ case 0:
+ gpio = 0;
+ break;
+ case 33:
+ gpio = (1 << cf->gpio_3v);
+ break;
+ default:
+ /* CF is 3.3V only */
+ return -EINVAL;
+ }
+
+ gpio |= 1 << (cf->gpio_3v + 16); /* enwr */
+ gpio |= 1 << (cf->gpio_5v + 16); /* enwr */
+ out_le32(cf->gpio_base+0x90, gpio);
+
+ pr_debug("%s: Vcc %d, io_irq %d, flags %04x csc %04x\n",
+ driver_name, s->Vcc, s->io_irq, s->flags, s->csc_mask);
+
+ return 0;
+}
+
+static int electra_cf_set_io_map(struct pcmcia_socket *s,
+ struct pccard_io_map *io)
+{
+ return 0;
+}
+
+static int electra_cf_set_mem_map(struct pcmcia_socket *s,
+ struct pccard_mem_map *map)
+{
+ struct electra_cf_socket *cf;
+
+ if (map->card_start)
+ return -EINVAL;
+ cf = container_of(s, struct electra_cf_socket, socket);
+ map->static_start = cf->mem_phys;
+ map->flags &= MAP_ACTIVE|MAP_ATTRIB;
+ if (!(map->flags & MAP_ATTRIB))
+ map->static_start += 0x800;
+ return 0;
+}
+
+static struct pccard_operations electra_cf_ops = {
+ .init = electra_cf_ss_init,
+ .get_status = electra_cf_get_status,
+ .set_socket = electra_cf_set_socket,
+ .set_io_map = electra_cf_set_io_map,
+ .set_mem_map = electra_cf_set_mem_map,
+};
+
+static int __devinit electra_cf_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct device *device = &ofdev->dev;
+ struct device_node *np = ofdev->node;
+ struct electra_cf_socket *cf;
+ struct resource mem, io;
+ int status;
+ const unsigned int *prop;
+ int err;
+
+ err = of_address_to_resource(np, 0, &mem);
+ if (err)
+ return -EINVAL;
+
+ err = of_address_to_resource(np, 1, &io);
+ if (err)
+ return -EINVAL;
+
+ cf = kzalloc(sizeof *cf, GFP_KERNEL);
+ if (!cf)
+ return -ENOMEM;
+
+ init_timer(&cf->timer);
+ cf->timer.function = electra_cf_timer;
+ cf->timer.data = (unsigned long) cf;
+
+ cf->ofdev = ofdev;
+ cf->mem_phys = mem.start;
+ cf->mem_base = ioremap(mem.start, mem.end - mem.start);
+ cf->io_size = PAGE_ALIGN(io.end - io.start);
+
+ cf->io_virt = reserve_phb_iospace(cf->io_size);
+
+ cf->gpio_base = ioremap(0xfc103000, 0x1000);
+ dev_set_drvdata(device, cf);
+
+ if (!cf->mem_base || !cf->io_virt || !cf->gpio_base) {
+ dev_err(device, "can't ioremap ranges\n");
+ status = -ENOMEM;
+ goto fail1;
+ }
+
+ __ioremap_explicit(io.start, (unsigned long)cf->io_virt, cf->io_size,
+ _PAGE_NO_CACHE | _PAGE_GUARDED);
+
+ cf->io_base = (unsigned long)cf->io_virt - VMALLOC_END;
+
+ cf->iomem.start = (unsigned long)cf->mem_base;
+ cf->iomem.end = (unsigned long)cf->mem_base + (mem.end - mem.start);
+ cf->iomem.flags = IORESOURCE_MEM;
+
+ cf->irq = irq_of_parse_and_map(np, 0);
+
+ status = request_irq(cf->irq, electra_cf_irq, IRQF_SHARED,
+ driver_name, cf);
+ if (status < 0) {
+ dev_err(device, "request_irq failed\n");
+ goto fail1;
+ }
+
+ cf->socket.pci_irq = cf->irq;
+
+ prop = get_property(np, "card-detect-gpio", NULL);
+ cf->gpio_detect = *prop;
+ prop = get_property(np, "card-vsense-gpio", NULL);
+ cf->gpio_vsense = *prop;
+ prop = get_property(np, "card-3v-gpio", NULL);
+ cf->gpio_3v = *prop;
+ prop = get_property(np, "card-5v-gpio", NULL);
+ cf->gpio_5v = *prop;
+
+ cf->socket.io_offset = cf->io_base;
+
+ /* reserve chip-select regions */
+ if (!request_mem_region(mem.start, mem.end + 1 - mem.start,
+ driver_name)) {
+ status = -ENXIO;
+ dev_err(device, "Can't claim memory region\n");
+ goto fail1;
+ }
+
+ if (!request_region(cf->io_base, cf->io_size, driver_name)) {
+ status = -ENXIO;
+ dev_err(device, "Can't claim I/O region\n");
+ goto fail2;
+ }
+
+ cf->socket.owner = THIS_MODULE;
+ cf->socket.dev.parent = &ofdev->dev;
+ cf->socket.ops = &electra_cf_ops;
+ cf->socket.resource_ops = &pccard_static_ops;
+ cf->socket.features = SS_CAP_PCCARD | SS_CAP_STATIC_MAP |
+ SS_CAP_MEM_ALIGN;
+ cf->socket.map_size = 0x800;
+
+ status = pcmcia_register_socket(&cf->socket);
+ if (status < 0) {
+ dev_err(device, "pcmcia_register_socket failed\n");
+ goto fail3;
+ }
+
+ dev_info(device, "at mem 0x%lx io 0x%lx irq %d\n",
+ mem.start, io.start, cf->irq);
+
+ cf->active = 1;
+ electra_cf_timer((unsigned long)cf);
+ return 0;
+
+fail3:
+ release_mem_region(io.start, io.end + 1 - io.start);
+fail2:
+ release_mem_region(mem.start, mem.end + 1 - mem.start);
+fail1:
+ /* XXX No way to undo the io reservation at this time */
+ if (cf->mem_base)
+ iounmap(cf->mem_base);
+ if (cf->gpio_base)
+ iounmap(cf->gpio_base);
+ device_init_wakeup(&ofdev->dev, 0);
+ kfree(cf);
+ return status;
+
+}
+
+static int __devexit electra_cf_remove(struct of_device *ofdev)
+{
+ struct device *device = &ofdev->dev;
+ struct electra_cf_socket *cf;
+
+ cf = dev_get_drvdata(device);
+
+ cf->active = 0;
+ pcmcia_unregister_socket(&cf->socket);
+ free_irq(cf->irq, cf);
+ del_timer_sync(&cf->timer);
+
+ iounmap(cf->mem_base);
+ iounmap(cf->gpio_base);
+ release_mem_region(cf->mem_phys, cf->mem_size);
+ release_region(cf->io_base, cf->io_size);
+
+ kfree(cf);
+
+ return 0;
+}
+
+static struct of_device_id electra_cf_match[] =
+{
+ {
+ .compatible = "electra-cf",
+ },
+ {},
+};
+
+static struct of_platform_driver electra_cf_driver =
+{
+ .name = (char *)driver_name,
+ .match_table = electra_cf_match,
+ .probe = electra_cf_probe,
+ .remove = electra_cf_remove,
+};
+
+static int __init electra_cf_init(void)
+{
+ return of_register_platform_driver(&electra_cf_driver);
+}
+module_init(electra_cf_init);
+
+static void __exit electra_cf_exit(void)
+{
+ of_unregister_platform_driver(&electra_cf_driver);
+}
+module_exit(electra_cf_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR ("Olof Johansson <olof@lixom.net>");
+MODULE_DESCRIPTION("PA Semi Electra CF driver");
+
Index: mainline/arch/powerpc/platforms/pasemi/setup.c
===================================================================
--- mainline.orig/arch/powerpc/platforms/pasemi/setup.c
+++ mainline/arch/powerpc/platforms/pasemi/setup.c
@@ -37,6 +37,10 @@
#include <asm/time.h>
#include <asm/of_platform.h>
+#include <pcmcia/ss.h>
+#include <pcmcia/cistpl.h>
+#include <pcmcia/ds.h>
+
#include "pasemi.h"
static void __iomem *reset_reg;
@@ -204,7 +208,41 @@ static void __init pas_init_early(void)
iommu_init_early_pasemi();
}
+static int pcmcia_notify(struct notifier_block *nb, unsigned long action,
+ void *data)
+{
+ struct device *dev = data;
+ struct device *parent;
+ struct pcmcia_device *pdev = to_pcmcia_dev(dev);
+
+ /* We are only intereted in device addition */
+ if (action != BUS_NOTIFY_ADD_DEVICE)
+ return 0;
+
+ parent = pdev->socket->dev.parent;
+
+ /* We know electra_cf devices will always have of_node set, since
+ * electra_cf is an of_platform driver.
+ */
+ if (!parent->archdata.of_node)
+ return 0;
+
+ if (!of_device_is_compatible(parent->archdata.of_node, "electra-cf"))
+ return 0;
+
+ /* We use the direct ops for localbus */
+ dev->archdata.dma_ops = &dma_direct_ops;
+
+ return 0;
+}
+
+static struct notifier_block pcmcia_notifier = {
+ .notifier_call = pcmcia_notify,
+};
+
+
static struct of_device_id pasemi_bus_ids[] = {
+ { .type = "localbus", },
{ .type = "sdc", },
{},
};
@@ -214,6 +252,10 @@ static int __init pasemi_publish_devices
if (!machine_is(pasemi))
return 0;
+#ifdef CONFIG_PCMCIA
+ bus_register_notifier(&pcmcia_bus_type, &pcmcia_notifier);
+#endif
+
/* Publish OF platform devices for SDC and other non-PCI devices */
of_platform_bus_probe(NULL, pasemi_bus_ids, NULL);
^ permalink raw reply
* Re: Mem-2-Mem DMA - Generalized API
From: Olof Johansson @ 2007-06-25 17:00 UTC (permalink / raw)
To: Matt Sealey; +Cc: Arnd Bergmann, linuxppc-embedded
In-Reply-To: <467FD1DF.4000602@genesi-usa.com>
On Mon, Jun 25, 2007 at 03:31:59PM +0100, Matt Sealey wrote:
>
> Indeed. I wonder if we could pull apart the IOAT/DMA stuff and genericise
> it (it should be possible) or simply add to it, or if making a powerpc
> specific dma engine abstraction would be an easier idea.
It's hard to anticipate all possible uses of a framework when you first
write it. So, when you first write it with one device in mind, it's
fairly obvious that it might not fit well with the second device that
will use it. That's the case of drivers/dma and IOAT today.
That's the case with the dma engine framework today. Expand it, extend
it, fix it and improve it. Don't duplicate, re-invent and re-implement.
-Olof
^ permalink raw reply
* Re: [PATCH] powerpc: fix MAC address entries for 83xx, 85xx, and 86xx device trees
From: Jon Loeliger @ 2007-06-25 16:19 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org, Timur Tabi
In-Reply-To: <70d005ce549921cc56481fe0b26faaa4@kernel.crashing.org>
On Sat, 2007-06-23 at 10:50, Segher Boessenkool wrote:
> > For the 83xx, 85xx, and 86xx device trees, add a "local-mac-address"
> > property
> > to every Ethernet node that didn't have one. Add a comment indicating
> > that
> > the "address" and/or "mac-address" properties are deprecated in DTS
> > files
> > and will be removed at a later time. Change all MAC address
> > properties to
> > have a zero MAC address value.
>
> Shouldn't you use the "??" notation instead, or is that
> still not implemented?
That is correct. It is still not implemented.
jdl
^ permalink raw reply
* Re: [PATCH] powerpc: setup Marvell mv64x60 platform devices for EDAC
From: Dave Jiang @ 2007-06-25 16:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Doug Thompson, dfarnsworth, linuxppc-dev
In-Reply-To: <18047.24840.233508.259767@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Dave Jiang writes:
>
>> The mv64x60 EDAC driver can be found at:
>> http://bluesmoke.sourceforge.net/
>>
>> It's in development to be pushed into the kernel.
>
> Am I correct in thinking this patch is useless without that driver?
>
> Is that driver being submitted for 2.6.23? If so, who is submitting
> it and to whom? Does it look like it will be accepted?
>
> Paul.
Paul,
Yes you are correct. I have not yet submitted the driver to akpm. I'm waiting
for the core EDAC changes to be accepted, which are in the mm tree right now.
The driver relies on some new API changes to EDAC that are in the mm tree.
Without those changes the driver is pretty useless. The driver is publicly
available from the sourceforge EDAC SVN at the moment and patches against the
latest mm tree. If you like I can ask Doug Thompson (the EDAC maintainer) to
put the driver in the mm tree.
This is also the same for the mpc85xx EDAC driver. Of course that needs the
publish of the of_device patch.
--
------------------------------------------------------
Dave Jiang
Software Engineer
MontaVista Software, Inc.
http://www.mvista.com
------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] powerpc: fix MAC address entries for 83xx, 85xx, and 86xx device trees
From: Timur Tabi @ 2007-06-25 16:01 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <05ae4090f00e42580b7dcbf0619cc0b7@kernel.crashing.org>
Segher Boessenkool wrote:
> Yup, they're both marked for removal so let's just remove them
> at the same time.
As soon as Paul creates a "for-2.6.25" branch, that's when I was planning on doing it.
> Does the kernel provide a warning to users of too-old firmware^Wuboot
> telling them to update btw?
Nope. The current U-Boot code updates mac-address and/or local-mac-address, whichever
ones exist. If neither exists, it doesn't do anything. If both exists, it updates both
with the same value. This makes it DTS-agnostic, so to speak.
The kernel looks at each of the properties and uses the first one that has a valid MAC
address. Again, this is U-Boot- and DTS-agnostic.
Some older U-Boots would panic if the property it looks for didn't exist. Some Linux
drivers would simply not find a MAC address and then fail to load.
In other words, the current U-Boot and Linux code is written to not care what the other
one does. I have no plans to remove the code in the kernel that looks for obsolete
entries (I'm talking about function of_get_mac_address), because it's "safe".
However, now that you mention it, I could update function of_get_mac_address() to display
a warning if it only finds the 'address' property. That property is definitely wrong and
should never be in the DTS or any device tree passed to the kernel.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] powerpc: fix MAC address entries for 83xx, 85xx, and 86xx device trees
From: Segher Boessenkool @ 2007-06-25 15:46 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <467FDA2C.8020607@freescale.com>
>> Shouldn't you use the "??" notation instead, or is that
>> still not implemented?
>
> I just tested the very latest dtc, and it does not support ??.
Yeah too bad.
>> [I would have preferred if you had removed "address" right
>> away (replaced by "mac-address"), but since it is marked
>> for removal anyway, that's fine with me].
>
> My initial patch removed address and mac-address, but Kumar reminded
> me that we don't want to break things so quickly. I didn't want to
> run any regression tests on all these platforms and versions to see
> which obsolete properties could be removed from which DTS.
Yup, they're both marked for removal so let's just remove them
at the same time.
Does the kernel provide a warning to users of too-old firmware^Wuboot
telling them to update btw?
Segher
^ permalink raw reply
* Re: [PATCH] pcmcia: CompactFlash driver for PA Semi Electra boards
From: Olof Johansson @ 2007-06-25 15:50 UTC (permalink / raw)
To: Christoph Hellwig, linux-kernel, linux-pcmcia, linuxppc-dev,
Russell King
In-Reply-To: <20070625055636.GB1057@infradead.org>
On Mon, Jun 25, 2007 at 06:56:36AM +0100, Christoph Hellwig wrote:
> > +static int bus_notify(struct notifier_block *nb, unsigned long action,
> > + void *data)
> > +{
> > + struct device *dev = data;
> > +
> > + printk("bus notify called\n");
> > +
> > + /* We are only intereted in device addition */
> > + if (action != BUS_NOTIFY_ADD_DEVICE)
> > + return 0;
> > +
> > + /* We use the direct ops for localbus */
> > + dev->archdata.dma_ops = &dma_direct_ops;
> > +
> > + return 0;
> > +}
>
> Sorry for not coming back to you after the last posting of the patch,
> but I still really this bit of the code. We don't set dma ops from
> a driver anywhere else in the tree, so I'd really prefer if you could
> handle this in architecture code somewhere. Especially as dma_direct_ops
> and the pcmcia_bug_type shouldn't really be something exported to users.
>
> Also this code is unlogic if not buggy. Just because you have one
> electra bridge it doesn't mean all pcmcia is driven by it. In fact I'm
> pretty sure there are cardbus/pcmcia bridges that can be plugged into
> plain pci slots.
Yeah, all good points. Also, I obviously missed to take out the debug
printk. I'll post an updated patch separately.
Thanks!
-Olof
^ permalink raw reply
* RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
From: Glenn.G.Hart @ 2007-06-25 15:21 UTC (permalink / raw)
To: eemingliu; +Cc: akonovalov, linuxppc-embedded, mamsadegh
[-- Attachment #1: Type: text/plain, Size: 7622 bytes --]
All,
I am also very interested in the network throughput. I am using the Avenet
Mini-Module which has a V4FX12. The ML403 is very close to the
Mini-Module. I am getting a throughput of about 100 Mbps. The biggest
difference was turning on the cache. 100 MHz vs. 300 MHz only improved the
performance slightly. Using the checksum offloading was also a big help in
getting the throughput up. The RX Threshhold also helped, but the jumbo
frames did not seem to help. I am not sure what I can do to get the 300
Mbps Ming is getting. I saw on a previous post someone was using 128k
FIFO depth. I am using a 32k depth.
Glenn
(Embedded "Ming Liu" <eemingliu@hotmail.com>@ozlabs.org
image moved 06/25/2007 06:03 AM
to file:
pic11478.jpg)
Sent by:
linuxppc-embedded-bounces+glenn.g.hart=us.westinghouse.com@ozlabs.org
To: mamsadegh@hotmail.com
cc: akonovalov@ru.mvista.com, linuxppc-embedded@ozlabs.org
Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
Security Level:? Internal
Dear Mohammad,
>The results are as follows:
>PC-->ML403
>TCP_SENDFILE : 38Mbps
>
>ML403--->PC
>TCP_SENDFILE: 155Mbps
This result is unreasonable. Because PC is more powerful than your board,
so PC->board should be faster than board->PC.
>The transfer rate from ML403 to PC has improved by a factor of 2,
>I see on the posts here in the mailing list that you have reached a band
width of 301Mbps.
Yes, with all features which could improve performance enabled, we can get
around 300Mbps for TCP transfer. one more hint, did you enable caches on
your system? perhaps it will help. Anyway, double check your hardware
design to make sure all features are enabled.That's all I can suggest.
BR
Ming
>
>
>
>
>----------------------------------------
> > From: eemingliu@hotmail.com
> > To: mamsadegh@hotmail.com; akonovalov@ru.mvista.com;
linuxppc-embedded@ozlabs.org; grant.likely@secretlab.ca
> > Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > Date: Sat, 23 Jun 2007 19:10:16 +0000
> >
> > Use the following command in Linux please:
> >
> > ifconfig eth0 mtu 8982
> >
> > As well you should do that on your PC in the measurement.
> >
> > Ming
> >
> >
> > >From: Mohammad Sadegh Sadri
> > >To: Ming Liu ,
> > ,,
> >
> > >Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > >Date: Sat, 23 Jun 2007 19:08:29 +0000
> > >
> > >
> > >Dear Ming,
> > >
> > >Really thanks for reply,
> > >
> > >about thresholds and waitbound OK! I'll adjust them in adapter.c ,
> > >
> > >but what about enabling jumbo frames? should I do any thing special to
> > enable Jumbo fram support?
> > >
> > >we were thinking that it is enabled by default. Is it?
> > >
> > >thanks
> > >
> > >
> > >
> > >
> > >----------------------------------------
> > > > From: eemingliu@hotmail.com
> > > > To: mamsadegh@hotmail.com; akonovalov@ru.mvista.com;
> > linuxppc-embedded@ozlabs.org; grant.likely@secretlab.ca
> > > > Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > > > Date: Sat, 23 Jun 2007 18:48:19 +0000
> > > >
> > > > Dear Mohammad,
> > > > There are some parameters which could be adjusted to improve the
> > > > performance. They are: TX and RX_Threshold TX and RX_waitbound. In
my
> > > > system, we use TX_Threshold=16 and Rx_Threshold=8 and both
waitbound=1.
> > > >
> > > > Also Jumbo frame of 8982 could be enable.
> > > >
> > > > Try those hints and share your improvement with us.
> > > >
> > > > BR
> > > > Ming
> > > >
> > > > >From: Mohammad Sadegh Sadri
> > > > >To: Andrei Konovalov , Linux PPC Linux
> > > > PPC, Grant Likely
> > > > >Subject: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > > > >Date: Sat, 23 Jun 2007 12:19:12 +0000
> > > > >
> > > > >
> > > > >Dear all,
> > > > >
> > > > >Recently we did a set of tests on performance of virtex 4FX hard
TEMAC
> > > > module using ML403
> > > > >
> > > > >we studied all of the posts here carefully: these are the system
> > > > characteristics;
> > > > >
> > > > >Board : ML403
> > > > >EDK : EDK9.1SP2
> > > > >Hard TEMAC version and PLTEMAC version are both 3.0.a
> > > > >PPC clock frequency : 300MHz
> > > > >Kernel : 2.6.21-rc7 , downloaded from grant's git tree some thing
near
> > one
> > > > week ago
> > > > >DMA type: 3 (sg dma)
> > > > >DRE : enabled for TX and RX, (2)
> > > > >CSUM offload is enabled for both of TX and RX
> > > > >tx and rx fifo sizes : 131072 bits
> > > > >
> > > > >the board comes up over NFS root file system completely and
without
> > any
> > > > problems.
> > > > >
> > > > >PC system used for these tests is : CPU P4 Dual Core, 3.4GHz ,
> > 2Gigabytes
> > > > memory, Dual gigabit ethernet port, running linux 2.6.21.3
> > > > >We have tested the PC system band width and it can easily reach
> > 966mbits/s
> > > > when connected to the same PC. ( using the same cross cable used
for
> > ml403
> > > > test)
> > > > >
> > > > >Netperf is compiled with TCP SEND FILE enabled, ( -DHAVE_SENDFILE)
> > > > >
> > > > >(from board to PC)
> > > > >netperf -t TCP_SENDFILE -H 10.10.10.250 -F /boot/zImage.elf -- -m
> > 16384 -s
> > > > 87380 -S 87380
> > > > >
> > > > >the measured bandwidth for this test was just 40.66Mbits.
> > > > >It is also true for netperf from PC to board.
> > > > >
> > > > >we do not have any more idea about what we should do to improve
the
> > > > bandwidth.
> > > > >any help or ideas is appreciated...
> > > > >
> > > > >_________________________________________________________________
> > > > >Connect to the next generation of MSN
> > > >
> >
Messenger?>http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline
> >
> > > >
> > > > >_______________________________________________
> > > > >Linuxppc-embedded mailing list
> > > > >Linuxppc-embedded@ozlabs.org
> > > > >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > > >
> > > > _________________________________________________________________
> > > > 免费下载 MSN Explorer: http://explorer.msn.com/lccn/
> > > >
> > >
> > >_________________________________________________________________
> > >News, entertainment and everything you care about at Live.com. Get it
now!
> > >http://www.live.com/getstarted.aspx
> >
> > _________________________________________________________________
> > 免费下载 MSN Explorer: http://explorer.msn.com/lccn/
> >
>
>_________________________________________________________________
>Discover the new Windows Vista
>http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn/
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: pic11478.jpg --]
[-- Type: image/jpeg, Size: 2170 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: fix MAC address entries for 83xx, 85xx, and 86xx device trees
From: Timur Tabi @ 2007-06-25 15:07 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <70d005ce549921cc56481fe0b26faaa4@kernel.crashing.org>
Segher Boessenkool wrote:
> Shouldn't you use the "??" notation instead, or is that
> still not implemented?
I just tested the very latest dtc, and it does not support ??.
> [I would have preferred if you had removed "address" right
> away (replaced by "mac-address"), but since it is marked
> for removal anyway, that's fine with me].
My initial patch removed address and mac-address, but Kumar reminded me that we don't want
to break things so quickly. I didn't want to run any regression tests on all these
platforms and versions to see which obsolete properties could be removed from which DTS.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: libfdt merged into DTC repo!
From: Josh Boyer @ 2007-06-25 14:51 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, u-boot-users
In-Reply-To: <E1I2pUz-0008MH-3F@jdl.com>
On Mon, 2007-06-25 at 09:25 -0500, Jon Loeliger wrote:
> Folks,
>
> David Gibson has successfully wrestled the libfdt legal beast!
> As a result, I have merged the current versions of the libfdt
> into the DTC repository as maintained on jdl.com.
Cool. Congrats David.
So I'm assuming the DTC git tree will be the canonical source for libfdt
then?
josh
^ permalink raw reply
* UART for MPC5200 with DTR, DSR, RI and DCD?
From: Mattias Boström @ 2007-06-25 14:23 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Does anybody know of an UART driver for the MPC5200 that supports use of
the DTR, DSR, RI and DCD signals?
Regards,
Mattias
^ permalink raw reply
* Re: Mem-2-Mem DMA - Generalized API
From: Matt Sealey @ 2007-06-25 14:31 UTC (permalink / raw)
To: Clemens Koller; +Cc: Arnd Bergmann, linuxppc-embedded
In-Reply-To: <467FBABD.9040103@anagramm.de>
Clemens Koller wrote:
> Hello, Matt!
>
>> There is so much you can do with most SoC DMA controllers, and it's not
>> even limited to PowerPC (most ARM/XScale SoCs have very capable devices
>> inside too). I can only imagine that nobody got excited over IOAT because
>> the entire programming interface stinks of "offloading gigabit ethernet"
>> and not much else.
>
> The main question remains: Is it possible to have a flexible cross platform
> DMA API which handles even complex requests and does scheduling,
> prioritizing, queuing, locking, (re-)building/caching of SG lists... automagically.
I would think so. I think there is a fairly generic example in many parts
of the Linux kernel. Dare I say the Via Unichrome AGP subsystem? And a
bunch of the ARM/OMAP platforms..? A lot of the code is even identical,
I wonder why it isn't some library rather than platform drivers.
> Filling memory with zero is also a simple task for a DMA engine.
> (Thinking about malloc() and memset())
Also xor and logical operations, byte swapping huge chunks of data, that
kind of thing. Most DMA engines in SoCs have cute features like that. I
think BestComm can even calculate CRCs for IP packets.
> The problem is IMHO similar to video acceleration. Within the
> Xorg's XAA/EXA/whatever framework, the drivers accelerate certain
> calls if the hardware has the capability to do so. Other calls fall back
> to some default non accelerated memcpy() & friends.
>
> Sounds like a lot of fun... replacing kernel's and libc's memcpy() with
> memcpy_with_dma_if_possible(). :-)
Indeed. I wonder if we could pull apart the IOAT/DMA stuff and genericise
it (it should be possible) or simply add to it, or if making a powerpc
specific dma engine abstraction would be an easier idea.
Probably the latter to be merged with the former at a later date would
be easier to manage. Take inspiration but don't be bound by Intel's
weird "new" (i.e. 15 year old) concept?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ 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