[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] pvops dom0: no sound after boot; possibly caused by swiotlb
> But thats not quite all whats dma_alloc_coherent does. As it only returns a > 32-bit variable all coherent_dma_mask over 32-bit get casted down. This way > bare-metal makes sure that the dma-mask is never over 32-bit. Ooooh. I completly failed to notice that your dom0 was 32-bit. But having that there would make the mask always be below 4GB, irregardless if the dom0 is 32 or 64-bit. Which is exactly what it does on bare-metal. Hmmm, ok: http://kerneltrap.org/mailarchive/git-commits-head/2008/10/28/3841954 shows what made that happen. I am bit worried on the casting - it does not seem to have been the purpose of that change to utilize that, but that is a upstream problem. I am curious - if you dom0 is 64-bit, does the sound card work? > > Or are you are saying that when the hardware supports 64 bit and has set the > coherent_dma_mask accordingly and dom0 is 32-bit that the allocation of DMA > after the 4 GB should work fine? Because thats the assumption i see in the > pvops-code. Yes. It should have worked fine. > > And from what i understood so far the DMA memory should be allocated > preferably in the 24-bit address space or max. 32 bit address space, at least > in a 32-bit kernel. > > >The only difference here is that under pvops we behave badly with > >devices that have GFP_DMA set and don't have the coherent_dma_mask > >(which it does not seem to be the case?). > > As i understand it the opposite is the case. If coherent_dma_mask is not set > xen_swiotlb_alloc_coherent sets it to 32-bit. That should work usually > (except the device needs the dma-memory in the 24-bit space). > You are right. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |