ARM: PrimeCell DMA Interface v5
in [Kernel]
|
Prev: Failed to initialize MSI interrupts && ioremap reserve_memtype failed -22
Next: x86: Reserve legacy VGA MMIO area for x86_64 as well as x86_32
From: Linus Walleij on 1 May 2010 19:50 2010/5/2 Dan Williams <dan.j.williams(a)intel.com>: > On Sat, May 1, 2010 at 4:04 PM, Linus Walleij >> When the driver issues a request to perform a DMA transfer, it will pull >> out a physical channel and use that, then return it. If there is too >> much combat about the physical channels, you configure out DMA >> for the least wanted PrimeCells. >> > > Could you simulate this by publishing more struct dma_chans than are > physically present, and then handle the muxing internal to the driver? > �Or am I misunderstanding the usage model? Yes exactly that way. What I had in mind atleast. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Walleij on 1 May 2010 20:30 2010/5/2 Russell King - ARM Linux <linux(a)arm.linux.org.uk>: >> But the implementation of the DMA engine would be better of >> handling the muxing dynamically I believe, so when the PL011 >> driver (say) requests a DMA channel, it doesn't mean it requests the >> *physical* channel and holds it (unless the driver is very naďvely >> implemented) it nominally means it reserves a placeholder in the >> DMA engine. > > So what happens if we try to use DMA with the PL011 but the physical > channels are already in use? From what I can see, it assumes that it > always has access to the transmit channel, and there's no recovery if > it doesn't. > > Plus if we can't get DMA for the RX path, it _permanently_ disables > all DMA for the device. OK now I get it.. the point of crux is that you need the drivers to be coded to switch seamlessly back to interrupt mode and retry with DMA on next transaction nevertheless if possible. That is definately possible with the current API, so it's nothing blocking the stuff pending in Dan's tree. However when it comes to the PL011/PL180 drivers you got me there, it surely does assume you either have the channel and can use it or else there is some permanent error on it. I'll twist these patches around a bit, it shouldn't be too hard to come up with some convincing code. > Three physical channels shared between: AACI Tx, AACI Rx, MMCI 0, MMCI 1, > UART3 Tx, UART3 Rx. > (...) > All you need is to load both the AACI > and MMCI drivers, and if they want to use the DMA channels, you're > already wanting 4 channels with only 3 available. Yep, that's where it kicks in. (What's the name of this DMA controller BTW? Is that PL080?) (I read it as MMCI is bidirectional also on the Versatile, as it is on the U300.) However: this way of using the DMA dynamically instead of statically leads to the situation where a UART or two MMCs are using up the DMA channels and AACI cannot use it, and need to fall back to interrupts. Since the Audio traffic is likely to be more important, this is perhaps not so optimal, so a static assignment of DMA channels may be desired after all in a practical scenario. But I'll surely make a try to make all DMA allocation from the PrimeCells dynamic! Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Russell King - ARM Linux on 2 May 2010 04:20 On Sun, May 02, 2010 at 02:21:13AM +0200, Linus Walleij wrote: > Yep, that's where it kicks in. (What's the name of this DMA controller > BTW? Is that PL080?) It's one of the standard ARM primecells, with a FPGA controlling the routing of the first three channels. > (I read it as MMCI is bidirectional also on the Versatile, as it is > on the U300.) There are two MMCIs on Versatile. > However: this way of using the DMA dynamically instead of statically > leads to the situation where a UART or two MMCs are using up the > DMA channels and AACI cannot use it, and need to fall back to > interrupts. Since the Audio traffic is likely to be more important, this > is perhaps not so optimal, so a static assignment of DMA channels > may be desired after all in a practical scenario. Such a scenario leads to two of the three channels assigned to AACI (one for playback and the other for record - remember, it's full duplex), leaving one to be shared between the UART Tx and Rx, and two MMCIs. I'd disagree with you and say that MMCI would be more important than AACI. The data rate for MMCI is far higher than AACI - and remember ARM MMCIs overflow if you don't read the data fast enough. The MMCI fmax parameter only exists to put a cap on the rate of the transfer so that the CPU can read the data fast enough in PIO mode. However, you only need DMA for MMCI if there's a card inserted in the slot. If there's no card in the slot, there's no point starving AACI of a DMA channel if that's what is being used. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus WALLEIJ on 4 May 2010 09:10
The latest patchset is now also tested on the ARM-RealView PB11MPCore. My best friends over at Ericsson AB helped me out by lending me their board for a short session. See bootlog below... - UART console comes up fine and is interactive - MMCI card mounts and you can list and copy files No DMA in use since the PL081 in this machine does not have a driver yet, but no regressions in sight. This should be similar to Versatile or Integrator. Is this OK now Russell? Yours, Linus Walleij Uncompressing Linux... done, booting the kernel. Linux version 2.6.34-rc6-next-20100503-00033-gc482e92 (linus(a)fecusia) (gcc vers0 CPU: ARMv6-compatible processor [410fb020] revision 0 (ARMv7), cr=00c5387f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: ARM-RealView PB11MPCore Ignoring unrecognised tag 0x00000000 Memory policy: ECC disabled, Data cache writeback Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: root=/dev/nfs nfsroot=192.168.0.3:/export/rootfs/rootfs-ant PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 128MB = 128MB total Memory: 120360k/120360k available, 10712k reserved, 0K highmem Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) DMA : 0xffc00000 - 0xffe00000 ( 2 MB) vmalloc : 0xc8800000 - 0xf8000000 ( 760 MB) lowmem : 0xc0000000 - 0xc8000000 ( 128 MB) modules : 0xbf000000 - 0xc0000000 ( 16 MB) .init : 0xc0008000 - 0xc0672000 (6568 kB) .text : 0xc0672000 - 0xc0909000 (2652 kB) .data : 0xc0922000 - 0xc093d400 ( 109 kB) Hierarchical RCU implementation. NR_IRQS:128 Console: colour dummy device 80x30 Calibrating delay loop... 83.76 BogoMIPS (lpj=418816) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 L2X0 cache controller enabled Serial: AMBA PL011 UART driver dev:uart0: ttyAMA0 at MMIO 0x10009000 (irq = 36) is a AMBA/PL011 console [ttyAMA0] enabled dev:uart1: ttyAMA1 at MMIO 0x1000a000 (irq = 37) is a AMBA/PL011 dev:uart2: ttyAMA2 at MMIO 0x1000b000 (irq = 78) is a AMBA/PL011 fpga:uart3: ttyAMA3 at MMIO 0x1000c000 (irq = 79) is a AMBA/PL011 bio: create slab <bio-0> at 0 Advanced Linux Sound Architecture Driver Version 1.0.23. Switching to clocksource timer3 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 UDP hash table entries: 256 (order: 0, 4096 bytes) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) NET: Registered protocol family 1 RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. msgmni has been set to 235 io scheduler noop registered io scheduler deadline registered (default) CLCD: RealView hardware, XVGA display Console: switching to colour frame buffer device 128x48 armflash.0-0: Found 2 x16 devices at 0x0 in 32-bit bank Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Using buffer write method Using auto-unlock on power-up/resume cfi_cmdset_0001: Erase suspend on write enabled armflash.0-1: Found 2 x16 devices at 0x0 in 32-bit bank Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Using buffer write method Using auto-unlock on power-up/resume cfi_cmdset_0001: Erase suspend on write enabled Concatenating MTD devices: (0): "armflash.0-0" (1): "armflash.0-1" into device "armflash.0" RedBoot partition parsing not available afs partition parsing not available smsc911x: Driver version 2008-10-21. smsc911x-mdio: probed eth0: attached PHY driver [SMSC LAN911x Internal PHY] (mii_bus:phy_addr=0:01, i) net eth0: MAC Address: 00:02:f7:00:3a:80 mice: PS/2 mouse device common for all mice mmci-pl18x fpga:mmc0: mmc0: MMCI/PL180 manf 41 rev 0 cfg 00 at 0x000000001000500 mmci-pl18x fpga:mmc0: IRQ 46, 47 (pio) aaci-pl041 fpga:aaci: ARM AC'97 Interface at 0x0000000010004000, irq 32, fifo 52 ALSA device list: #0: ARM AC'97 Interface at 0x0000000010004000, irq 32 TCP cubic registered NET: Registered protocol family 17 VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 3 mmc0: host does not support reading read-only switch. assuming write-enable. mmc0: new SD card at address e624 mmcblk0: mmc0:e624 SU256 241 MiB mmcblk0: p1 net eth0: SMSC911x/921x identified at 0xc8880000, IRQ: 41 atkbd serio0: keyboard reset failed on fpga:kmi0 IP-Config: Complete: device=eth0, addr=192.168.0.4, mask=255.255.255.0, gw=192.168.0.1, host=arm11mpcore, domain=, nis-domain=(none), bootserver=192.168.0.3, rootserver=192.168.0.3, rootpath= Warning: unable to open an initial console. Freeing init memory: 6568K input: AT Raw Set 2 keyboard as /class/input/input0 Please press Enter to activate this console. starting pid 342, tty '/dev/ttyAMA0': '/bin/sh -sc ". /etc/profile"' root(a)ME:/ root(a)ME:/ Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |