Re: What's in arm:devel

[Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>]

On Mon, Sep 08, 2008 at 11:30:32AM +0100, Catalin Marinas wrote:
> 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").

The only one which looks sensible to remove is:

        if (cpu_architecture() >= CPU_ARCH_ARMv6) {
                printk(KERN_WARNING "Only cachepolicy=writeback supported on ARMv6 and later\n");
                cachepolicy = CPOLICY_WRITEBACK;
        }

> 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.

I was in part expecting this complaint...

However, you're actually wrong about that - the bit patterns have been
cunningly chosen to make this all work.

1. Drop the top bit of the memory types, leaving you with three bits
   which you can put into TEX[0], C, B.

   This results in the following aliases:

   L_PTE_MT_DEV_NONSHARED	=> L_PTE_MT_DEV_SHARED
   L_PTE_MT_DEV_WC		=> L_PTE_MT_BUFFERABLE
   L_PTE_MT_DEV_CACHED		=> L_PTE_MT_WRITEBACK

   which is very close to what you want.  The latter two of these
   mappings _aren't_ of ARMv6 'device' type but are 'normal' memory.

2. Arrange for the top bit when set to also set the S bit, and arrange
   for TEXCB=100 mappings to have an inverted S bit

And it all works out.

> 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.

Incorrect - we need at least the uncached type (or buffered type if we
decide to go for writecombining) for DMA coherent mappings.

> 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

Which means we're up to 6.  We also need to support 'uncached' (for
O_SYNC /dev/mem) and 'writecombine' for framebuffers.  In combination
with DMA mappings, that brings us to 7.  Plus the bit combination for
the implementation defined combination, brings us to 8.  So we've
used all TEX remapping combinations.

With my scheme, at least you end up with one bit combination spare:
0x05, which along with the S bit, gives you a variation in the
sharing of that type.  This can be used to support your outer cacheable
inner uncacheable mapping type.

-------------------------------------------------------------------
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