On Mon, 2009-11-30 at 07:28 +0100, Albert Herranz wrote:
>
>
> Heh, I was told to identity map it :)
Hah ? By whome ? :-)
> Originally it used kernel address space (
> 0xc{c,d}006800).
In any case, kernel space also needs to be reserved. There is no magic
free spot in the kernel virtual space unless you reserve some either by
lowering ioremap_bot early at boot or by using the fixmap (well, there
is if you don't enable HIGHMEM but that's going away soon :-)
> I've never worked with fixmap entries. I'll look into it. Thanks.
Look at fixmap.h, basically it's an emum of reserved pages starting near
the top of the address space and walking down from there. The kernel
ensure that space stays reserved and it gives you things calculated at
compile time (so via asm-offsets.h you can feed them into your asm).
I'm half tempted to say we should just bluntly reserve the top 128K (or
whatever is the min size of a BAT) for that sort of debug crap though
and be done with it :-) Always handy to have some space we know we can
mess around with.
> But we can use then a known mapping scheme, and have all the i/o
> region covered by bats there.
We could yes. I was hoping Grant would produce something there but he
hadn't had time yet.,
> We can do that already, yes, but setup_io_mappings purpose was
> originally that, no?
Sort-of. I don't like hard coding virtual addresses, it causes all sort
of problems (other than in the fixmap). It wouldn't be very hard to
bring back some variant of io_block_mapping() though that works by
moving ioremap_bot down early during boot, and allows you to setup some
IO BATs for perfs reasons. Subsequent ioremaps would automatically pick
up that space and benefit from it.
Cheers,
Ben.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
