On Mon, 2008-01-07 at 19:45 +0000, Russell King wrote: > In old ARM CPUs, there were two bits that defined the characteristics of > the mapping - the C and B bits (C = cacheable, B = bufferable) > > Some ARMv5 (particularly Xscale-based) and all ARMv6 CPUs extend this to > five bits and introduce "memory types" - 3 bits of TEX, and C and B. > > Between these bits, it defines: > > - strongly ordered > - bufferable only * > - device, sharable * > - device, unsharable > - memory, bufferable and cacheable, write through, no write allocate > - memory, bufferable and cacheable, write back, no write allocate > - memory, bufferable and cacheable, write back, write allocate > - implementation defined combinations (eg, selecting "minicache") > - and a set of 16 states to allow the policy of inner and outer levels > of cache to be defined (two bits per level). Can we not restrict these to a maximum of 8 base types at run-time? If yes, we can only use 3 bits for encoding and also benefit from the automatic remapping in later ARM CPUs. For those not familiar with ARM, 8 combinations of the TEX, C, B and S (shared) bits can be specified in separate registers and the pte would only use 3 bits to refer to those. Even older cores would benefit from this as I think it is faster to read the encoding from an array in set_pte than doing all the bit comparisons to calculate the hardware pte in the current implementation. -- Catalin - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
