I'm trying to update omap_gpmc to (a) support OMAP3/Beagle features and (b) use sysbus/qdev rather than ad-hocery, and I'm having difficulty figuring out how it fits into the new memory API.
Specifically, omap_gpmc lets you attach up to 8 devices to its chip selects, and has registers which specify base address and size for each attached device. I want the attached device to be an arbitrary sysbus device, because some boards use this (for instance the overo board hangs a lan9118 off the gpmc, and the n8x0 connects up the tusb6010; the other usual attached devices are nand and onenand). This kind of "I want to manage the memory layout of a pile of other things" seems like what the hierarchical memory API should provide, but there's a bit of a difficulty here in that sysbus MMIOs aren't necessarily MemoryRegions (and sysbus doesn't provide a "MemoryRegion* sysbus_get_memoryregion(SysBusDevice dev, int regionnumber)" anyway). How are we planning to move forward here? Will all sysbus MMIOs eventually be converted to MemoryRegions? Secondly, I'm not sure how to implement the gpmc size registers with the memory API: memory_region_add_subregion() lets you specify the offset you want to put the subregion at, but doesn't provide any way to say "limit the size of the mapping to this many bytes, regardless of how big the underlying device thinks it is". (My pre-memory-API version of these changes implemented a new sysbus_mmio_resize(), but you can't restrict the size of a MemoryRegion based sysbus MMIO.) So maybe I'm approaching the problem wrong -- how should I be doing this? [More detailed summary of how the GPMC base and size registers work: the base register gives the top 6 bits of the base address, and there is also a 6 bit mask register which effectively gives the size of the region: the device is selected if (address[31:26] & mask) == base. If the device is smaller than the specified size then it just repeats throughout the region. Note that you can specify funny masks that give 'holes' in the region, although the TRM says not to do that :-). Access to a region which was programmed to map to two different chip selects generates a bus error instead. I don't think we need to model the finer details of holes, repeat-through-region or overlap if that is too tricky, though.] thanks -- PMM
