Re: What's in arm:devel | |
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] | |
Russell, On Sun, 2008-09-07 at 19:33 +0100, Russell King - ARM Linux wrote: > - BIG CHANGE: the way we handle memory types on ARMv6 and higher. > Needs review - note that the result of this is that ARMv6 and ARMv7 > set_pte_ext functions have grown a bit. Also note that Xscale and > Xscale3 TEXCB combinations have changed for devices, and that > MT_DEVICE_IXP2000 has finally become redundant. Tested on a PXA255 > platform, and pre-ARMv6 on qemu OMAP (with manual checking of > resulting page tables.) In addition to this, we should also remove the restrictions from early_cachepolicy(). I think I added this in the past but mainly because it was generating inconsistent mappings (like shareable device for "cachepolicy=buffered"). Fixing the memory types handling is a good thing but I'm not that happy with the handling of the ARMv6 memory type (though I haven't tried an alternative implementation yet). Using 4 bits for the memory type is indeed needed for pre-ARMv6 but make it more difficult to use the TEX remapping on ARMv6/v7. According to pgtable.h in the arm:devel branch, we have the following memory types (10 in total): #define L_PTE_MT_UNCACHED (0x00 << 2) /* 0000 */ #define L_PTE_MT_BUFFERABLE (0x01 << 2) /* 0001 */ #define L_PTE_MT_WRITETHROUGH (0x02 << 2) /* 0010 */ #define L_PTE_MT_WRITEBACK (0x03 << 2) /* 0011 */ #define L_PTE_MT_MINICACHE (0x06 << 2) /* 0110 (sa1100, xscale) */ #define L_PTE_MT_WRITEALLOC (0x07 << 2) /* 0111 */ #define L_PTE_MT_DEV_SHARED (0x04 << 2) /* 0100 */ #define L_PTE_MT_DEV_NONSHARED (0x0c << 2) /* 1100 */ #define L_PTE_MT_DEV_WC (0x09 << 2) /* 1001 */ #define L_PTE_MT_DEV_CACHED (0x0b << 2) /* 1011 */ Should we still have the restrictions that ARMv6 and pre-ARMv6 support be compilable in the same kernel? If not, we could simply alias definitions like L_PTE_MT_DEV_CACHED to L_PTE_MT_WRITEBACK etc. On ARMv6 we don't need more than 6 distinct encodings. With TEX remapping, we can even compress the first 4 and the 6th above into one "normal" memory type and cachepolicy= would only set the corresponding TEX encoding. So, on ARMv6 we could only use 5 types: L_PTE_MT_NORMAL L_PTE_MT_DEV_SHARED L_PTE_MT_DEV_NONSHARED L_PTE_MT_DEV_WC L_PTE_MT_DEV_CACHED There are some situations where people would like different inner and outer cache policies for the normal memory on ARMv6 and this doesn't easily fit into the above unless we use a single L_PTE_MT_NORMAL with TEX remapping (there is also a class of devices that can see the outer cache, so we would need a L_PTE_MT_DEV_OUTERCACHED as optimisation but that's not something to worry about until we see a real device with this configuration). If we keep the same definitions for pre-ARMv6 and ARMv6 CPUs, we could have an additional mem_types_v6 table or we can add an adjustment function called from build_mem_type_table() on ARMv6. Such a function would replace L_PTE_MT_* with something like L_PTE_MT_TEX_REMAP0 etc. (in mem_types table and pgprot_user/kernel) and set the corresponding TEX remapping at the hardware level. This could even be preset in a table and indexed by L_PTE_MT_ as you did with armv6_set_pte_ext but done at boot time via build_mem_type_table(). I think this last approach would be the best we can get to keep the ARMv6 set_pte function simple. -- Catalin ------------------------------------------------------------------- List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
[Site Home] [Linux Arm] [Fedora ARM] [Gcc Help] [Git] [DCCP] [IETF Announce] [Security] [PDAs] [Linux] [Linux Book List] [Linux MIPS] [Yosemite Campsites] [Photos]
![]() |
|