rcblach at raleigh.ibm.com
Tue Oct 16 23:12:44 EST 2001
Paul Mackerras wrote:
> I'm pretty sure this comment in pci_dma_sync_single in pci.h is wrong:
> /* The bus_to_virt() can't be used here, in case dma_handle
> * points to something that doesn't have the same cache attributes
> * as the 1:1 mapped kernel memory. If we used it, we could
> * get a cache line alias with the wrong attributes.
> * Since there isn't any Linux way to get the real VA from a PA,
> * it is just easier to flush the whole cache. The code to
> * determine VA from PA would probably do the same :-).
> * I don't know why these functions don't pass VA, since the
> * cache operations use VA and the caller has this information.
> * -- Dan
> There are basically two ways to get a dma_handle: through
> pci_alloc_consistent, which might map some memory with caching disable
> (I'm talking about the non-cache-coherent processors here), or through
> mapping some memory with pci_map_single, pci_map_sg, or pci_map_page.
> Now in the first instance, which is what the comment seems to be
> referring to, we get the consistency by having the uncached mapping,
> and you don't need to, and in fact shouldn't, call pci_dma_sync_single.
> In the second instance the CPU's mapping of the page would be a
> cacheable mapping since the caller would have got the memory via
> kmalloc or get_free_page, and so the possibility of cache paradoxes
> doesn't arise there either.
> So in the absence of highmem it seems to me that pci_dma_sync_single
> could just do bus_to_virt quite safely. With highmem, the (new)
> pci_map_page routine lets us do dma to highmem pages directly, and so
> bus_to_virt won't work there, but it would be relatively easy to kmap
> the page and flush that virtual address.
> However, I have just realized that the best way of all is probably to
> have a cache-flush routine which just turns off DR and flushes using
> physical addresses, which will be identical to the dma addresses
> (except for an offset on some platforms).
This would probably work, except on Book E platforms, where DR off
simpley gets you another translaton and NOT
a physical address.
> Thoughts? Have I got the wrong end of the stick?
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-dev