Re: [Qemu-devel] modelling omap_gpmc with the hierarchical memory API

[Avi Kivity <avi@redhat.com>]

On 08/02/2011 06:47 PM, Peter Maydell wrote:
> 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?

Yes.

>
> 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".

You can interpose you own container region:


  system_memory
      |
      +--- cs_region-0
              |
              +--- device-connected-to-that-region

cs-region-0 will clip anything under it.


>
> (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?

I don't think those devices should be connected to the sysbus (since 
they aren't on real hardware).  Connect them to your gpmc instead.  If 
the devices are already designed for sysbus, maybe we can dual-bus them, 
or make gpmc have eight sysbuses hanging off it.

>
> [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


-- 
error compiling committee.c: too many arguments to function