First cut at large page support on 40x

[Paul Mackerras]

Dan Malek writes:

> > 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 :-)

Not by me, doing a range check in virt_to_* would be perfectly
appropriate.

>  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.

Drivers shouldn't be doing virt_to_* on the address they get from a
consistent-alloc function.  Given that doing it the right way is easy
(just remember the physical address that the consistent alloc function
gives you) I don't have any qualms about breaking drivers that do it
the wrong way.

(I should note that I'm not intending to break them in 2.4, not even
in 2_4_devel; virt_to_* can continue to use iopa there.  But in 2.5 we
can be more brutal.)

> So, just toss iopa(), use the macros in their standard way, and see how
> long we run before the system crashes (SCSI drivers, eepro100,... :-)

There is the issue of making sure that we don't have DMA buffers and
other variables in the same cache line.  This is being thrashed out on
linux-kernel at the moment. :)

Paul.

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