[lkml]   [2003]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] fix ppc ioremap prototype
On Thu, 2003-09-04 at 10:28, Christoph Hellwig wrote:
> On Thu, Sep 04, 2003 at 01:10:10AM -0700, David S. Miller wrote:
> > What we could do in the interim is create an ioremap_resource()
> > and then move things over gradually.
> ioremap_resource() looks like a fine idea. It's cleaner, easily
> emulateable on <= 2.4 and solves the problem this hack wanted to
> work around properly.
> This still doesn't make the phys_addr_t a good interims solution,
> though. Just use ioremap_resource from the beginning for those
> drivers that care for the bigger address space on ppc44x.
> Paul, what does actually use this higher addresses?

The great thing with ioremap_resource() is that we can make it work
for PCI IO as well as MMIO and slowly get rid of anything tapping
ports without first ioremapp'ing them. That would help some platforms
with bazillons PCI busses as well so in the end, we don't have to
keep the whole PCI IO space of those machines ioremapped all the time,
this is especially useful on 32 bits archs where we can run short on
virtual space easily.

At first, it would just "do nothing" for PCI IO (just return the same
token), and once enough drivers have been ported, the arch can decide
to change the inx/outx implementation to rely on ioremap_resource
doing the actual mapping.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:48    [W:0.089 / U:2.280 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site