[lkml]   [2004]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[RFC] ioremap() clarification && ioremap_resource()
    What is the general consensus among folks on using ioremap() for
    non-PCI devices? Looking at IO-mapping.txt (which is really really
    oudated) and io.h for various architectures, there really does not
    seem to be any agreement on what the cookie going into ioremap() means.
    IO-mapping.txt just states that it is a bus address. The reason I am
    asking is b/c I have a system that breaks the following assumption
    in IO-mapping.txt by having different bus address domains.

    - bus address. This is the address of memory as seen by OTHER devices,
    not the CPU. Now, in theory there could be many different bus
    addresses, with each device seeing memory in some device-specific way,
    but happily most hardware designers aren't actually actively trying to
    make things any more complex than necessary, so you can assume that all
    external hardware sees the memory the same way.

    The system I am working on has a 32-bit SOC with many on-chip devices
    and SDRAM taking up over 2G of CPU bus ("physical") address space. In
    addition, there is about 3.5GB worth of devices on the PCI bus. The SOC
    has an in direct PCI access mechanism via command/data registers, so there
    is no need to map any PCI devices into kernel VM. ioremap() can simply
    return the incoming value and read*/write* can use the PCI control
    registers on the SOC to perform PCI mem accesses. This does mean that
    PCI mmap won't work, but that's not a requirement on this system.

    The problem I have is that since some of the on-chip devices have
    overlapping CPU bus addresses with devices on the PCI bus, there is no way
    for ioremap() to tell if the incoming address is a PCI bus address or a
    CPU bus address. Therefore, ioremap() does not know if really needs to
    map the incoming region into VM or whether it should simply return
    the value it was given. The same issue exists with read*/write* since
    there are non-PCI drivers that use these interfaces. [1]

    I can easilly get around this issue by having my SOC-specific drivers
    call the low level ARM __ioremap() which is defined as taking a CPU
    physaddr and have my ioremap() assume that it is used only for PCI
    devices, but it seems that we really need a consistent interface for
    mapping devices regardless of the bus they are on. There's been some
    discussion before on providing a ioremap_resource() [2], but it
    looks like the discussion just kind of died off and there were
    still some unresolved issues such as whether this interface should
    take a device pointer or not.

    One thing to note is that simply having a ioremap_resource() is not
    enough and we also need someway of telling read*/write* what bus/device
    we are accessing. In my situation, the PCI address for a device that
    is passed to and returned by ioremap_resource() could easilly overlap
    with the virtual address for a real VM-mapped device or even something
    in the PHYS_OFFSET -> VMALLOC_START region, so I can't just have
    readl/writel assume that it is a PCI address..or are readl/writel only
    supposed to be used with PCI devices?

    What I'd like to propose is something that looks like the following
    from the driver writer's perspective:

    cookie = dev_remap(dev, resource, offset, len);
    value = dev_readl(dev, cookie + register_offset);
    dev_writel(dev, cookie + offset, value);
    dev_unmap(dev, cookie);

    Is anyone else still interested in an API similar to ioremap_resource()
    or am I the only one who really needs this ATM? Is this something that's
    is acceptalbe in 2.6 if we update drivers as needed (I only need e100 and
    e1000 for now) and make the generic case on systems that don't need the
    resource default to ioremap() or is this a 2.7 only change?

    Regardless of the answer, I'll try to throw together a patch in the
    next few days.


    [1] See drivers/serial/8250.c for ioremap && read*/write* on non-PCI


    Deepak Saxena - dsaxena at plexity dot net -

    "Unlike me, many of you have accepted the situation of your imprisonment and
    will die here like rotten cabbages." - Number 6
    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 14:04    [W:0.023 / U:88.140 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site