| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Xen 3.0 Status update
"Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx> writes:
> > Unfortunately, there still seems to be some places where
> > kmallocs are done for dma buffers. (i tried putting all linux
> > memory into ZONE_NORMAL and caught a couple of these places)
>
> Can you give examples? What size are the allocations? Do you know what
> the official position is i.e. is using kmalloc with ZONE_DMA deprecated?
If you do this:
fd = open("/dev/video0"); // open bttv grabber card
ioctl(fd, ...); // configure tvnorm, size, ...
read(fd, somelargebuf); // capture a single frame
bttv will try to send the video frame directly to the buffer passed.
Lock pages, kick DMA, wait until finished, unlock pages, done. And
bttv has no control at all about how these pages are allocated.
DMA memory really can be almost anything. There is no way around
having a swiotlb-like bounce buffer mechanism hooked into the dma
mapping API as fallback.
At the moment the linux kernel provides no way to hint that you want
to use the specific piece of memory you are asking for for 32-bit PCI
DMA. ZONE_DMA is historical stuff, 16MB only for ISA DMA IIRC, not
really useful. Maybe Andy finally finds some time to polish & submit
the ZONE_DMA32 patch.
bttv tries to allocate buffers from ZONE_NORMAL (i.e. avoid highmem)
in case it has control over the allocations, which is far from being
perfect. Works reliable only on 32 bit, doesn't work on 64-bit
without iommu and >4GB for example ...
Gerd
--
panic("it works"); /* avoid being flooded with debug messages */
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home