First cut at large page support on 40x
Dan Malek
dan at embeddededge.com
Thu Jun 13 10:28:51 EST 2002
Paul Mackerras wrote:
> This is an issue which is much wider than the question of what the PPC
> port should do. The linux-kernel at vger.kernel.org list is the
> appropriate place to discuss this sort of thing.
Yeah, right :-) I can't bear the signal to noise ratio out there :-)
> The PCI DMA API is designed so that drivers never need to translate
> between virtual and physical addresses themselves. Our API for local
> peripherals on embedded chips should do the same.
As far as I know, they do. Just call consistent_alloc() and keep track
of the addresses. At the time I implemented consistent_alloc(), I
updated all drivers I could test (and some that I couldn't :-) to do this.
At the time, there were PCI drivers on 4xx and 8xx that didn't do the
right thing with the pci_* functions, so I had to keep some kind of mapping
to make them work.
> "Well don't do that then" :) If you are calling pci_map_single on a
> vmalloc'd address you are living dangerously even if virt_to_* does
> use iopa, since vmalloc'd memory is not physically contiguous.
>
>
>>doing this or are they doing it correctly? I don't know, but I do know
>>if they call these functions we better return the right answer.
>
>
> Hitting a BUG() would be more appropriate in these cases.
I know, but the higher level functions are sufficiently disjoint that you
can't keep context across them to know if someone is doing something bad.
I guess we could just check for an address in the VMALLOC space and not
translate that, but then I'll get criticized for adding code into that
fast virt_to_* path :-) You also don't know, in the case of noncoherent
processors, that the virtual mapping you received is from a 'vmalloc'
space, even though it was done properly for DMA. It's one thing to call
vmalloc() and try to do DMA, and it's another to use an alternate mapping
to properly implement a feature under a standard interface.
So, just toss iopa(), use the macros in their standard way, and see how
long we run before the system crashes (SCSI drivers, eepro100,... :-)
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-embedded
mailing list