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
|
Home