lkml.org 
[lkml]   [2004]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: DMA API issues
Ian Molton wrote:
> On 18 Jun 2004 13:52:46 -0500
> James Bottomley <James.Bottomley@SteelEye.com> wrote:
>
>
>>You still haven't explained what you want to do though. Apart from the
>>occasional brush with usbstorage, I don't have a good knowledge of the
>>layout of the USB drivers. I assume you simply want to persuade the
>>ohci driver to use your memory area somehow, but what do you actually
>>want the ohci driver to do with it? And how much leeway do you get to
>>customise the driver.

A fair amount, so long as drivers above it don't need to
change much at all (this is "stable"). That includes
usbcore and all the usb drivers.

>
> In *theory* the OHCI driver is doing everything right - its asking for DMAable memory and using it. if the DMA api simply understood the device in question, and alocated accordingly, it would just work.
>
> there are two solutions:
>
> 1) Break up the OHCI driver and make it into a chip driver as you describe

It's heading that way already ... breaking along the lines
where standard APIs solve problems, such as this.

> 2) Make the DMA API do the right thing with these devices
>
> 1) means everyone gets to write their own allocator - not pretty
> 2) means we get to share code and it all just works.
>

For example, if usbaudio uses usb_buffer_alloc to stream data,
that eliminates dma bouncing. That's dma_alloc_coherent at
its core ... it should allocate from that 32K region.

- Dave




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.083 / U:1.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site