[Xen-devel] Re: [ivtv-devel] Problems loading ivtv in Xen - DMA issues?

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 8 Jul 2005, at 16:38, David Muench wrote:

> Hi Keir,
>
> Looks like it didn't quite work. I started a capture and then ended it
> 20 seconds later, and I still have a zero byte file. Ivtv has some new
> messages in dmesg though:
Well, it's not clear whether this is a bug in Xen or the ivtv driver. 
:-)
Basically, my fix for dma_map_single() introduces bounce buffers. These 
should work okay if:
 (a) I haven't screwed up the bounce-buffer code; and
 (b) The ivtv driver is scrupulously careful in its use of the 
streaming DMA interface.
For example, it is not good for the driver to read/write the buffer 
without calling unmap, or sync_for_cpu. I see that the driver does do 
the right thing at least most of the time but, of course, if there are 
any bugs they won't actually cause problems on most architectures (i386 
in particular).
OTOH, the bounce buffer code is not exactly thoroughly tested, so it is 
feasible the bug lies there. Although the implementation is pretty 
simple.
I think the bottom line is that this will need fixing by someone with 
the hardware -- probably by adding tracing to the map/sync functions to 
check that they are used correctly, and to sanity-check the bounce 
buffer code.
Some more detail on how the bounce buffers are implemented. It's very 
similar to what arch/arm does for these streaming DMA calls:
 * dma_map_single() allocates a physically contiguous bounce buffer 
and, if dir!=DMA_FROM_DEVICE, copies the host buffer into the bounce 
buffer.
 * dma_unmap_single() copies bounce -> host (if dir!=DMA_TO_DEVICE) and 
then frees the bounce buffer
 * dma_sync_single_to_{cpu,device}() copy to/from the bounce buffer as 
appropriate, if teh direction argument is in the matching direction.
 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel