On 2 August 2011 21:56, Anthony Liguori<address@hidden> 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