Re: Athlon/AGP issue update

[Val Henson]

On Sat, Jan 26, 2002 at 01:20:45AM +0100, Benjamin Herrenschmidt wrote:
> >
> >Looking at bat_mapin_ram, it looks like we only map the first 512MB of
> >RAM with BATs, so we actually map the 512MB - 768MB range with PTEs
> >(and highmem starts at 768MB).  Two of the DBATs are used by I/O
> >mappings, so that only leaves two DBATs of 256MB each to map lowmem
> >anyway.  Am I missing something?
> 
> No, except maybe my last patch that actually limits lowmem to 512Mb ;)

:)

> I don't think we use the io mapping BATs any more, do we ? (well,
> maybe on PReP...) I don't on pmac.

Lots and lots of PPC platforms use BATs for io mappings:

val@evilcat </sys/linuxppc_2_4_devel_pristine/arch/ppc/platforms>$ grep -l ppc_md.setup_io_mappings *
grep: SCCS: Is a directory
adir_setup.c
apus_setup.c
chrp_setup.c
gemini_setup.c
k2_setup.c
lopec_setup.c
mcpn765_setup.c
menf1_setup.c
mvme5100_setup.c
pcore_setup.c
powerpmc250.c
pplus_setup.c
prep_setup.c
prpmc750_setup.c
prpmc800_setup.c
sandpoint_setup.c
spruce_setup.c
zx4500_setup.c

I'm trying to get highmem working on Gemini, hence my interest.

> >By the way, does the "nobats" option currently work on PowerMac?
> 
> No, nor on any other BAT-capable PPC (and that's the reason why I
> did the above). Basically, our exception return path and some of
> the hash manipulation functions aren't safe without BAT mapping,
> especially on SMP when you can get evicted from the hash table
> by the other CPU in places where taking hash faults isn't safe.

Hm, that's what I thought.  Thanks for confirming that.

-VAL