On 2 August 2011 21:56, Anthony Liguori <anth...@codemonkey.ws> wrote:
> Hrm, this looks like badness to me.
>
> You're effectively using MemoryRegions to implement an ad-hoc interface.
As you'll see below, the hardware intreface is somewhat ad-hoc :-)
> This is not what MemoryRegions are meant to do though. You want something
> like:
>
> class WhateverDevice : public Device, implements SimpleDevice
> {
> MemoryRegion *get_memory_region(void);
> };
>
> class OmapGmc : public Device
> {
> SimpleDevice *slots[8];
> };
>
> In qdev of today, you should implement something other than SysBus as a base
> class and make OmapGmc a bus.
Doesn't this then preclude connecting the memory region of an
existing sysbus device model into the OmapGpmc bus? After all,
it wouldn't be implementing SimpleDevice.
> What's the relationship between the omap_gpmc and the devices in real
> hardware? Are the devices designed to connect to the GPMC explicitly via a
> common set of pins? Is there an intermediate bridge chip or something?
The external interface (ie the one to the outside of the OMAP3 SOC,
into which a board can wire devices) looks like this:
gpmc_a[10:1] output Address (note no bit zero!)
gpmc_d[15:0] i/o Data
gpmc_ncs[7:0] output Chip selects
gpmc_nadv_ale output Address valid (or address latch enable for NAND)
gpmc_noe_nre output Output enable (or read enable for NAND)
gpmc_nwe output Write enable
gpmc_nbe0_cle output Lower byte enable (also command latch enable for NAND)
gpmc_nbe1 output Byte 1 enable
gpmc_nwp output Write protect
gpmc_io_dir output gpmc_d[15:0] direction control (input vs output)
...which you can then use in a number of different modes by programming
the GPMC appropriately:
* multiplexed address-and-data NOR-like device:
gpmc_d[15:0] are a 16 bit data bus and also used for addressing:
gpmc_a[10:1] + gpmc_d[15:0] together give an address bus A26..A1
(no A0, so you can't byte-address, only 16-bit-word address)
* non-multiplexed NOR like device:
gpmc_d[15:0] are a 16 bit data bus only
gpmc_a[10:1] are A10..A1 address bus (again, no A0)
* 16 bit NAND device wired up to gpmc_d[15:0], with the NAND
control pins being gpmc_nadv_ale etc as above
* 8 bit NAND device, as 16 bit NAND but only using gpmc_d[7:0]
Assuming we aren't going to actually try to model this at a pin
level, this disentangles into talking to one of two interfaces:
* a NAND device (which at the moment nand.c implements via
nand_setpins/nand_getpins/nand_setio/nand_getio)
* a random addressable memory region
Typically in the latter case the device we're talking to will
also provide some gpio or irq signals, which will be routed in
a totally different direction having nothing to do with the GPMC.
So it's important that we should be able to take an existing
device model and route its registers through the GPMC and its
GPIO elsewhere.
-- PMM
