Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> You have FIX_PCIE_MCFG in there too (keyed off CONFIG_PCI_MMCONFIG
> which we don't have and don't want to have).  If you need to map in
> PCIe config space, what's wrong with just using ioremap?  Why do you
> need to have a fixed virtual address for it?

Well, that was the whole point for doing the fixmap stuff actually, to
be able to have a non-HIGHMEM version of a quick kmap_atomic for ...
PCIe config space :-)

On some PCIe host brigdes like the ones used on 4xx or FSL chips, the
config space is physically mapped as a large linear space, too large to
ioremap permanently, and we can't ioremap from within the low level
config ops.

So the idea is to use a fixmap as a "window" to the config space,
possibly per-cpu. Ultimately, we should even be able to directly insert
TLB entries in kmap_atomic/fixmap to make it even faster.

> More generally, I think we need to take an overall look at what things
> we are using fixed virtual addresses for, and why they need to be
> fixed.  If there are indeed several such things then we can introduce
> the fixmap stuff.

The virtual address doesn't _need_ to be fixed in our case. It's more
like x86 builds kmap on top of fixmap and we were thinking about doing
the same, having it fixed makes it slightly easier to whack things but I
agree it's not necessarily the best option.

We could instead have something allocated a chunk of virtual space at
boot and provide a quick map/unmap.

But by using fixmap, we can use common code with kmap_atomic quickly and
easily.

Ben.