Re: map_page() and pinned TLB entries

[Dan Malek <dan@embeddededge.com>]

On Jun 16, 2005, at 12:47 PM, Marcelo Tosatti wrote:

> Well it is expected that mapin_ram() flushes the va for the
> PTE's being created.
>
> That is the only well known occurence of _tlbie() on
> a possibly pinned region.

Crap ... no, it's not.  It's map_page() that does the flush,
which happens on ioremap() as well.  When we pin
entries, we also pin some IO space as well.  We need
to update ioremap() to be smart about pinned entries
like it does BATs and CAMs.  I wonder if we can just
make this a generic test in ioremap().  It doesn't have
to know how the spaces are "pinned", just that they are
and how they are mapped.

> What does MOL stand for?

MacOS on Linux.  I don't think 8xx will run this any
time soon :-)

> If b) is chosen alone, which is what you seem to suggest, we
> will get tons of warnings (or traps) anyway from mapin_ram().

It's from more than just mapin_ram().  As I said, we also
use some of the entries to pin IO space.  We used to pin only
8M of instructions, which is more than sufficient, then various
8M windows of data space.  I think we used to pin 24M of
data and 8M of IMMR (plus anything above that, which could
be flash or other IO).

> So having that said, isnt the correct way out of this to change
> both a) and b)?

We certainly have to implement b) to catch all pinned spaces,
then update accordingly to ensure none of the wired entries
get evicted.

Thanks.


	-- Dan