Google
  Web www.spinics.net

Re: What's in arm:devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

BTW, with this approach, you're into having one table for pre-ARMv6,
another for Xscale, another for Xscale3 which is almost but not quite
ARMv6, and another for ARMv7 with remapping enabled - because:

Pre-ARMv6 only has the C and B bits.
Xscale has C, B and X bits where XCB=101: device, XCB=110: minicache.
Xscale3 like ARMv6 but TEXCB=00001: write combine TEXCB=00101: device
ARMv6 has TEXCB=00001: device TEXCB=00101: reserved
ARMv7 with remapping: TEXCB=xxNNN where NNN = remapped settings.

So you actually need to have 5 tables to do it this way.  Plus you
need to pass 5 bits via the LPTE to access all the TEXCB features
across the range, which then pushes out the permissions bit
manipulations from single instruction masks to multiple bit masks,
resulting in _all_ set_pte_ext functions growing in size.

> I think this last approach would be the best we can get to keep the
> ARMv6 set_pte function simple.

What's more simple than a lookup table?  You've already told me that
loads are cheap here on ARMv6.

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