On Thu, Sep 17, 2015 at 03:11:14PM -0400, Jerome Glisse wrote: > On Thu, Sep 17, 2015 at 03:06:57PM -0400, Konrad Rzeszutek Wilk wrote: > > On Thu, Sep 17, 2015 at 03:02:51PM -0400, Konrad Rzeszutek Wilk wrote: > > > On Thu, Sep 17, 2015 at 02:22:38PM -0400, jgli...@redhat.com wrote: > > > > From: Jérôme Glisse <jgli...@redhat.com> > > > > > > > > The swiotlb dma backend is not appropriate for some devices like > > > > GPU where bounce buffer or slow dma page allocations is just not > > > > acceptable. With that helper device drivers can opt-out from the > > > > swiotlb and just do sane things without wasting CPU cycles inside > > > > the swiotlb code. > > > > > > What if SWIOTLB is the only one available? > > > > > > And what can't the devices use the TTM DMA backend which sets up > > > buffers which don't need bounce buffer or slow dma page allocations? > > > > And then the followup question. If it opts out - how can it do > > sane things without an DMA API available? It would assume physical > > addresses match the bus addresses which is not always the sane > > thing. > > This is why this is an arch specific function, on x86 with pci device, > the driver knows what is the dma mask and thus if it can access directly > all the memory or not. So in the end swiotlb vs no_mmu gives the same > physical address to the device so there is no difference there.
Not with Intel or AMD IOMMUs. The bus address it gives is not the same as the physical address. > > Obviously device driver needs to know what it is doing depending on the > arch and bus the device is use in. > > Cheers, > Jérôme -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
