[RFC] ioremap() clarification && ioremap_resource()

[Deepak Saxena]

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.

~Deepak

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

[2] http://www.uwsg.iu.edu/hypermail/linux/kernel/0309.0/1117.html

-- 
Deepak Saxena - dsaxena at plexity dot net - http://www.plexity.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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/