Google
  Web www.spinics.net

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]

Add to Google Google PageRank Checking tool