Ben and I are talking about using fixmap on ppc for similar
applications to it use on x86. However in poking around other arch's
(sparc, mips) they appear to have some support but not as complete as
x86.
For example both SPARC & MIPS reference __set_fixmap() in asm/fixmap.h
but I can't find an implementation on either.
So I was wondering if there was some reason fixmap isn't as well
supported or if its just used for a specific function on those SPARC,
MIPS, etc. and they dont need as much functionality out of it as x86
does.
- k
On Fri, Nov 30, 2007 at 04:14:55PM -0600, Kumar Gala wrote:
> Ben and I are talking about using fixmap on ppc for similar
> applications to it use on x86. However in poking around other arch's
> (sparc, mips) they appear to have some support but not as complete as
> x86.
>
> For example both SPARC & MIPS reference __set_fixmap() in asm/fixmap.h
> but I can't find an implementation on either.
>
That's probably because people got lazy with copying around the
definitions -- perhaps surprisingly this happens quite frequently in arch
headers ;-)
MIPS has a fixrange_init() which does things in more or less one shot.
__set_fixmap() is a good abstraction if you're interested in poking at
individual fixmaps, but at least the kmap fixmaps have special handling all
over the place (look for kmap_pte in the various highmem implementations),
and there are few fixmaps otherwise.
> So I was wondering if there was some reason fixmap isn't as well
> supported or if its just used for a specific function on those SPARC,
> MIPS, etc. and they dont need as much functionality out of it as x86
> does.
>
There are of course things that make this more attractive on x86,
especially with regards to the global bit and preservation across a TLB
flush, there's a note in arch/sh/mm/init.c above __set_fixmap() about
that. fixmap doesn't really have any special behaviour that makes an
architecture implementation problematic at least.
On Sat, 2007-12-01 at 10:03 +0900, Paul Mundt wrote:
> There are of course things that make this more attractive on x86,
> especially with regards to the global bit and preservation across a
> TLB
> flush, there's a note in arch/sh/mm/init.c above __set_fixmap() about
> that. fixmap doesn't really have any special behaviour that makes an
> architecture implementation problematic at least.
On ppc, we are mostly looking into memory mapped config space, which for
some new PCIe bridges is huge (about 512M per port on the 440SPe). Those
processors have 36 bits physical addresses and 32 bits virtual.
So I suppose we can just move our current kmap_atomic implementation out
of highmem, call it fixmap, and add a slot for use by PCI config space
access (those are fully spinlocked, so the per-cpu aspect is just what
we need, just like kmap_atomic).
Ben.
On Fri, Nov 30, 2007 at 04:14:55PM -0600, Kumar Gala wrote:
> Ben and I are talking about using fixmap on ppc for similar applications to
> it use on x86. However in poking around other arch's (sparc, mips) they
> appear to have some support but not as complete as x86.
>
> For example both SPARC & MIPS reference __set_fixmap() in asm/fixmap.h but
> I can't find an implementation on either.
>
> So I was wondering if there was some reason fixmap isn't as well supported
> or if its just used for a specific function on those SPARC, MIPS, etc. and
> they dont need as much functionality out of it as x86 does.
MIPS uses fixmap for two purposes:
o In some cases it is possibly to avoid or optimize a cacheflush by creating
a temporary mapping. The mechanism works very similar to what x86 and
MIPS use for atomic kmaps.
o Highmem.
Both manipulate pagetables directly or even insert entries directly into
the TLB without pagetables as intermediate stage so __set_fixmap is indeed
unused.
Ralf