Re: [Xen-devel] [LINUX] dma: Use swiotlb mask for coherent mappings too

[Keir Fraser <keir@xxxxxxxxxxxxx>]

We could fall back to swiotlb_alloc/free_coherent?

I took the patch but renamed io_tlb_dma_bits to dma_bits. This makes more
sense for users anyway I think -- they're unlikely to care whether
allocations go thru swiotlb or not, they just want to specify what device
limitation they require the kernel to handle by whatever means it chooses.
So now it's 'dma_bits=' rather than 'io_tlb_dma_bits=', which happens to
neatly be the same as the Xen boot parameter's name.

 -- Keir

On 20/12/06 11:50, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> As we're going to have a swiotlb_{alloc,free}_coherent implementation after
> the sync
> with lib/swiotlb.c anyway, wouldn't it make sense to have
> dma_{alloc,free}_coherent
> call the former rather than setting up things by itself? If course, this will
> increase
> pressure on the swiotlb memory, but otoh it could reduce the likelihood of the
> contiguous region setup failing (especially if those are of non-zero order).
> 
> Jan
> 
>>>> Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> 20.12.06 06:14 >>>
> Hi Keir:
> 
> [LINUX] dma: Use swiotlb mask for coherent mappings too
> 
> The recent change to use a default DMA bit width of 30 bits (required
> by chips like the b44) only converted the streaming DMA primitives.
> The coherent mappings are still hard-coded to 31 bits.  This means that
> b44 still doesn't work under Xen.
> 
> This patch makes the io_tlb_dma_bits variable global and uses it for
> coherent memory mappings.
> 
> Thanks to Calvin Webster for providing a machine with a b44 and 2G
> of memory I've been able to verify that this finally makes the b44
> work under Xen.
> 
> Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
> 
> Cheers,


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