Re: __ioremap_at() in 2.4.0-test9-pre2

[Dan Malek <dan@mvista.com>]

Paul Mackerras wrote:

> Now, are those addresses physical or virtual?

Both.  They get mapped 1:1 in the mmu initialization, ioremap, and
work while the mmu is disabled.  Simple, easy, debuggers work, everyone
is happy.

> ... If you are saying "but we have device registers at
> physical address 0xff000000" my response is "so why is that a
> problem?".

Because you are taking something that works just fine and complicating
it for me without adding any value.  The whole PCI subsystem
implementation
needs lots of work, and adding a little VM mapping doesn't solve much
of the problem.  This is probably a bad time for me to comment on this
because I am trying to get a PPC750 cPCI board running with 2.4.  It
worked great in a 2.2 kernel, with all of its multiple bridges and Prep
memory map.  It does the same stupid thing as a PMac right now, claiming
everything is a mapping collision and you can't get there from here.
The interrupt routing is all screwed up as well.  There were a bunch of
PCI updates from Matt Porter in the 2.2 kernel for this, and I
don't know why they didn't make it into 2.4.  I suspect if they did
we could utilize it for PMacs too and just get on with life.

Yeah, I can add more code to head.S, have multiple mappings for the
same thing, and add more "fixup" functions for those places where it
has to be adjusted during the initialization.  The kernel is bigger,
executing more code, and making it more complicated for others to
understand....just so I can map my PCI like a PMac.....

I've had enough of PCI for today.  Maybe after I sleep on this for
a few hours I'll see the light :-).

Oh....and then there is his CONFIG_ALL_PPC thing.....


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/