Re: [Dri-devel] PPC Lockup (ati-pcigart-branch)

Roman Zippel wrote:

Hi,

On Mon, 22 Jan 2001, Dan Malek wrote:

quoted

quoted

......  Currently there is no kernel function to do
this explicitly

I'm working on that.  The PowerPC port cheated by using BATs and
trivial macros, but this doesn't work on some of the newer processors
and more complex applications.  Other architectures did the same, and
I am surprised there aren't generic kernel functions to track down this
information.  In fact, these functions are already present for 4xx and
8xx processors, so don't write anything new.

AFAIK such tricks are used for mapping normal (low) memory and ioremapped
areas. For normal memory you can use phys_to_virt()/virt_to_phys() and for
ioremapped memory, you have to store the physical and virtual address
yourself. What am I missing?

bye, Roman

Take a look at Documentation/DMA-mapping.txt.

I've done something for the 405 that I'm especially wary of, but have been
hoping I can continue to get away with in the future.  I map all of physical
SDRAM to the kernel virtual address space:

  0xc000'0000 through (0xc000'0000 + size of memory - 1)

via large TLB entries (each entry typically covering a range of 8MB).

This means that I can't just change the TLB entry of a 4KB page if I want it
to be mapped uncached.  I instead allocate a new virtual address range and
map that single page as uncachable via the new virtual address.  Thus phys_to_virt()
incorrectly returns the cacheable virtual address instead of the uncacheable virtual
address.

Currently, my biggest user of this method is pci_alloc_consistent().  This use is
because the 405 is not IO cache coherent.  In this case, the "physical" address
is really a bus address, which pci_alloc_consistent calls "dma_handle".
DMA-mapping.txt says drivers should not use bus_to_virt(), which is a close
relative of phys_to_virt().

-Frank
--
Frank Rowand [off-list ref]
MontaVista Software, Inc

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/