I2O controllers have two resource needs not currently handled
1. The want to be able to allocate physical address space that is free.
This isn't used by any I2O 1.5 controller I know of, but I2O 2.0
requires it for hot-plug (for the same reason the host OS will)
2. The i2o controller can claim devices it can access from its bus
(normally just PCI devices). For MCA bus we have the notion of
claiming a device (mark_as_used/mark_as_unused), we need the
equivalent for PCI etc too. A good API would probably be
mark_as_used_by(struct bus_host *) or similar.
> > What about platforms with multiple spaces where an 'address' (ie a void *)
> > is insufficient to describe an object ?
>
> :-(( Until now I didn't know about any such architecture. I'm afraid that
> any solution to this problem will be ugly. For accessing the devices in the
> kernel we can make ioremap() a bus-dependent function, but it does solve
> neither resource management issues nor user-level access via /dev/mem.
Intel Xeon - 32bit void* 36 bit addressing for one. If we want to support
this lets not dig a hole now. physaddr_t as was suggested by JJ seems smart
> swaps bytes _always_, but many devices are able to switch their MMIO
> to big endian, so that the driver can avoid swaps at all. I'm only not sure
> whether the complexity of making use of this is adequate to the speed gain.
Ok so we want the option for ioremap_be and ioremap_le if supported.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/