On Mon, Jan 07, 2008 at 10:49:57AM -0800, Jared Hulbert wrote: > > ARM is going to have to use the three remaining bits we have in the PTE > > to store the memory type to resolve bugs on later platforms. Once they're > > used, ARM will no longer have any room for any further PTE expansion. > > Russell, > > Can you explain this a little more. 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). Of course, not all CPUs support all the above - for example, if write back caches aren't supported then the result is a write through cache. The write allocation setting is a "hint" - if the hardware doesn't support write allocate, it'll just be read allocate. There are now CPUs out there where the old combinations (TEX=0) are broken - and causes nasty effects like writes to bypass the write protection under certain circumstances, or the data cache to hang if you're using a strongly ordered mapping. The "workaround" for these is to avoid the problematical mapping mode - which is CPU specific, and depends on knowledge of what's being mapped. For instance, you might use a sharable device mapping instead of strongly ordered for devices. However, you might want to use an outer cacheable but inner uncacheable mapping instead of strongly ordered for memory. Now, couple this with the fix for shared mmaps - where we normally turn a cacheable mapping into a bufferable mapping, or if the write buffer has visible side effects, a strongly ordered mapping, or if strongly ordered mappings are buggy... etc. Also note that there are devices (typically "unshared" devices) on some ARM CPUs that you can only access if you set the TEX bits correctly. Currently, Linux is able to setup mappings in kernel space to cover any combination of settings. However, userspace is much more limited because we don't carry the additional bits around in the Linux version of the PTE - and as such shared mmaps on some systems can end up locking the CPU. A few attempts have been made at solving these without using the additional PTE bits, but they've been less that robust. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - 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
