[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.021 / U:1.280 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site