On Sunday 27 November 2005 12:24 am, Chris Humbert wrote:
> > * struct device.dma_mem is there specifically to handle cases
> > like this for dma-coherent memory ... one implementation is
> > in arch/i386/kernel/pci-dma.c but there are others too.
>
> I agree that this is the best solution, but you may remember the
> arm-kernel and LKML discussions over a year ago regarding this
> specific HC that concluded that the DMA-mapping API should only
> be used for host RAM and that the driver should handle allocation
> and bouncing of a device's memory. More recently, Russel King
> didn't accept a patch to implement struct device.dma_mem on ARM,
> ...
> http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-July/030099.html
>
> But alas, this is a matter that I will take to the appropriate
> lists, so for our discussion here, I'll assume I can use struct
> device.dma_mem and dmabounce.
I confess I still don't buy Russell's argument as applied to
the dma_alloc_coherent(dev,...) issue; not at all. I see a
benefit to being _consistent_ in how memory is handled, no
matter where it happens to land in the address space ... and
no value to treating memory as if it weren't memory, just
because it lives in a slightly unusual location. The "dev"
parameter to dma_alloc_coherent() was included specifically
to handle cases like this.
The dmabounce stuff is much easier to dislike, but on the
other hand this usage is _exactly_ the sort of "hack around
platform problems" scenario he likes. (Except that he only
listed Intel hardware as appropriate for such hacks...)
> > What that means is that on your hardware, drivers would be
> > getting URB submission failures and thus tripping some fault
> > paths that may not be all that well tested
>
> How frequently should URB submission failures happen?
Whenever the stack can't handle the URB, fail its submission. :)
> I want to implement URB queueing, where URB submission succeeds
> if the URB could be mapped later. This would prevent sporadic
> submission failures, usb_submit_urb() could return a better error
> like -EMSGSIZE for too large URBs, and the URB scheduler can
> round-robin EPs to prevent one device from hogging the bus.
When you get into that territory, I'm thinking that maybe you
should plan on forking the OHCI code. These issues only come
up because your hardware is, effectively, not a DMA driver.
(Except potentially for coherent buffers allocated in that 32KB.)
OHCI doesn't need those sorts of behaviors on any other hardware.
Trying to make the OHCI driver handle DMA normally _and_ do that
other stuff for your PIO-ish hardware would create a mess that's
hard to maintain.
> +
> + if (dma_mapping_error (urb->transfer_dma)) {
> + status = -ENOMEM;
> + goto done;
> + }
Yeah, this is another hole in the DMA APIs. The problem is that
nobody has seemed interested in allowing them all to properly
report errors. Maybe it's time to bring up the issue again; I
suspect that a DMA_ADDR_INVALID constant (platform-specfic) may
be salable, if for no other reason than to flag cases where the
mapping hasn't "yet" been performed.
- Dave
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
