Here is my attempt to make BAT allocations dynamic instead of hard coded. The first patch changes setbat() to dynamically assign BATs instead of requiring the caller to select a BAT on its own.
A primary user of setbat is mmu_mapin_ram() which used to hard code BATs 2 and 3 for mapping as much of RAM as can fit in 2 BATs. The first patch changes the routine to try to use as many BATs as it needs to map all of RAM. (Note: I've still got BAT0 reserved for mapping RAM, so even if lots of other users of setbat() appear, RAM is guaranteed to be allocated at least 1 BAT). The first patch also adds an ioremap_bat() function which works like ioremap(), but uses BATs instead of page tables and can be called really early (before MMU_init()). ioremap_bat() mappings persist after MMU_init is called too so it can be used to map all of an SoC's IMMR region, or any other IO device for that matter. I've seen about a 2.5% performance improvement by using this on a simple network workload with SoC registers BAT mapped. The second patch is just a utility function required by the third patch. The third patch is a new user of ioremap_bat() to implement early debug support for the mpc5200 platform. The first patch is the one I really want feedback on. It shouldn't break any 32 bit platforms, but I need testing to make sure. Also, this is my first attempt at messing with MMU code, so please let me know if I'm doing anything foolish or dangerous. Kumar, Josh; I'd appreciate testing to make sure patch 1 doesn't break stuff. Thanks, g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
