Re: Request review of device tree documentation

[Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>]

On Sun, Jun 13, 2010 at 11:23:45PM -0600, Grant Likely wrote:
> >> Or perhaps the MMU and caches can be turned off for the duration of the
> >> callback.
> >> I don't have the details of ARM MMUs and caches reloaded into my head
> >> yet.  Maybe next week...

We've had these kinds of questions in the past.  Doing what you're asking
above is not really an option - it requires:

1. disable all IRQs
2. setup 1:1 MMU mappings for code to turn off MMU
   (requires new page table)
3. disable imprecise exceptions
4. flush caches and TLBS
5. jump to 1:1 mapping area for code to disable MMU
6. disable caches and mmu
7. call function
8. flush caches and TLBs
9. re-enable caches and mmu
10. re-enable imprecise exceptions
11. switch back to original MMU mappings
12. re-enable all IRQs

This is fine if you don't care at all about interrupt latency.
Unfortunately, most people do care about interrupt latency because
that directly affects interactivity and system performance.  The
called function could not enable interrupts or exceptions - as the
CPU vectors are in virtual space, disabling the MMU effectively
makes them disappear.

Moreover, with the MMU and caches disabled, the CPU performance is
extremely poor, so the called function will run slowly.

So, disabling the MMU isn't really viable.

Now, if the external code was fully PIC, we could then run it with
the MMU enabled.  However, this wouldn't really help - the external
code could not access any devices without knowledge of how the kernel
setup the V:P translations.

So you'd need to pass some kind of data structure giving locations of
devices to the called code - but then what if the kernel doesn't have
the device mapped?