DMA support for USB
in [Linux Hardware]
|
From: JMC on 10 Feb 2010 11:04 Hi all, Maybe a newbie question for you: In x86 motherboards there is a DMA controller in the Shouthbridge chip that allows DMA transactions between peripherals and RAM. I have read some manuals about these chips, like Intel's ICH7, and I can't see that it can (or can't) be assigned a DMA channel to an USB interface. I think that all modern chipsets can do this. Am I wrong? Where can I learn more about this? Let's assume that DMA supports USB. Then the USB host driver handles the configuration of the channel and the specific device driver configures the transactions, isn't it? Greetings, JMC
From: Clemens Ladisch on 10 Feb 2010 11:37 JMC wrote: > Maybe a newbie question for you: In x86 motherboards there is a DMA > controller in the Shouthbridge chip that allows DMA transactions > between peripherals and RAM. I have read some manuals about these > chips, like Intel's ICH7, and I can't see that it can (or can't) be > assigned a DMA channel to an USB interface. I think that all modern > chipsets can do this. DMA controllers are needed only if the device itself is not able to initiate memory accesses. DMA controllers (and their channels) were required for ISA devices, but PCI devices are allowed to access memory directly. http://en.wikipedia.org/wiki/Direct_memory_access#PCI HTH Clemens
From: JMC on 10 Feb 2010 12:34 On Feb 10, 5:37 pm, Clemens Ladisch <clem...(a)ladisch.de> wrote: > JMC wrote: > > Maybe a newbie question for you: In x86 motherboards there is a DMA > > controller in the Shouthbridge chip that allows DMA transactions > > between peripherals and RAM. I have read some manuals about these > > chips, like Intel's ICH7, and I can't see that it can (or can't) be > > assigned a DMA channel to an USB interface. I think that all modern > > chipsets can do this. > > DMA controllers are needed only if the device itself is not able to > initiate memory accesses. DMA controllers (and their channels) were > required for ISA devices, but PCI devices are allowed to access memory > directly. > > http://en.wikipedia.org/wiki/Direct_memory_access#PCI > > HTH > Clemens Thanks Clemens. So you are saying that USB interfaces are seen as PCI devices by the nothbridge? Certainly, if I make a "lspci |grep USB" in my PC I can see 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) 00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) and I could assume that it is the same in other x86 boards. The kernel uses the PCI driver at the lower level and the USB host driver communicates with it. Then, why some devices, like USB hard disks, use so much CPU time in data transfers if USB can send data directly to RAM? JMC
From: Aragorn on 11 Feb 2010 00:50 On Wednesday 10 February 2010 18:34 in comp.os.linux.hardware, somebody identifying as JMC wrote... > On Feb 10, 5:37 pm, Clemens Ladisch <clem...(a)ladisch.de> wrote: > >> JMC wrote: >> >> > Maybe a newbie question for you: In x86 motherboards there is a DMA >> > controller in the Shouthbridge chip that allows DMA transactions >> > between peripherals and RAM. I have read some manuals about these >> > chips, like Intel's ICH7, and I can't see that it can (or can't) be >> > assigned a DMA channel to an USB interface. I think that all modern >> > chipsets can do this. >> >> DMA controllers are needed only if the device itself is not able to >> initiate memory accesses. DMA controllers (and their channels) were >> required for ISA devices, but PCI devices are allowed to access >> memory directly. >> >> http://en.wikipedia.org/wiki/Direct_memory_access#PCI > > So you are saying that USB interfaces are seen as PCI devices by the > nothbridge? Certainly, if I make a "lspci |grep USB" in my PC I can > see > > 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev > a3) > 00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev > a3) > > and I could assume that it is the same in other x86 boards. The kernel > uses the PCI driver at the lower level and the USB host driver > communicates with it. > > Then, why some devices, like USB hard disks, use so much CPU time in > data transfers if USB can send data directly to RAM? Because USB is only a serial connection, not a disk controller. The kernel still has to see the device as being a storage device, and access it accordingly, and if the internal hard disk of your computer is of the IDE flavor - be it PATA or SATA - then the processor must double as a disk controller for that, as opposed to SAS and SCSI disks, which are generally attached to their own controller. In other words, most of the CPU activity when doing transfers to and from a USB storage device is probably due to the requirement that the internal hard disk is being controlled by the CPU. This is native to all motherboard-implemented IDE adapters and to a great deal of IDE add-on cards in the lower pricerange. -- *Aragorn* (registered GNU/Linux user #223157)
From: Wolfgang Draxinger on 11 Feb 2010 04:32
JMC wrote: > and I could assume that it is the same in other x86 boards. The kernel > uses the PCI driver at the lower level and the USB host driver > communicates with it. > > Then, why some devices, like USB hard disks, use so much CPU time in > data transfers if USB can send data directly to RAM? Because USB, and I mean the bus itself, does neither provide direct access to host resources or even device initiated transfer. In fact the USB host controller must continously poll each device connected, querying if there is data to be transferred. If so, then the data is transferred from a so called "endpoint" into a buffer allocated by the operating systems USB subsystem. After the transfer has been finished some other program does its thing with the data, depending on which kind of device delivered. In case of a USB storage device, its the USB storage driver, which then again copies stuff around. This is much unlike IEEE1394, aka FireWire, aka iLink which has been very popular between 1998 and 2005 - and still can be found on higher class motherboards. IEEE1394 allows for device initiated transfer and DMA to any device, which has mapped (some of) its memory to the IEEE1394 controller. Whilst being a design feature, today this is also seen as a security hole, since it allows to freely extract and manipulate any part of the accessible memories' contents, potentially containing secret data like passwords, cryptographic keys and such. But it also provides some neat methods of system debugging. Wolfgang |