On 09/07/2016 11:53 PM, Benjamin Herrenschmidt wrote: > On Wed, 2016-09-07 at 17:47 +0200, Cédric Le Goater wrote: >> >> +static uint64_t pnv_lpc_xscom_mr_read(void *opaque, hwaddr addr, >> unsigned size) >> +{ >> + XScomDevice *xd = XSCOM_DEVICE(opaque); >> + uint64_t val = 0; >> + >> + pnv_lpc_xscom_read(xd, 0, xscom_to_pcb_addr(xd->chip_type, >> addr), &val); >> + return val; >> +} >> + >> +static void pnv_lpc_xscom_mr_write(void *opaque, hwaddr addr, >> + uint64_t val, unsigned size) >> +{ >> + XScomDevice *xd = XSCOM_DEVICE(opaque); >> + pnv_lpc_xscom_write(xd, 0, xscom_to_pcb_addr(xd->chip_type, >> addr), val); >> +} >> > > I don't understand. That's not at all why I suggested or I'm missing > something.
This was a preliminary hack on the full powernv tree to study the question. I made the two options cohabitate in the same qemu to see what were the issues and possible solutions. The result is very much what you describe below. I need to start from the beginning now, and not the end, to make something cleaner. > What I suggest is that you have a memory region per-chip (which is NOT > hooked onto the main address space) which represents the PCB space. > Calling xscom_region. Hook it up to its own address_space. > > Thus, the various devices (LPC, OCC, etc...) all just register a sub- > region of that address space using the PCB addresses directly (well, > shifted left by 3 because it's 8 bytes registers but that's it). > > The XSCOM "controller" AKA ADU is the one doing the bridge. It > registers an MMIO region in the main address space (SysBusDevice ?) > and from the MMIO accessors, it does the address mangling, and use > address_space_rw() to trigger accesses onto that chip's xscom_region. yes. this is what your XSCOM bridge does already. name = g_strdup_printf("xscom-%x", s->chip_id); memory_region_init_io(&s->mem, OBJECT(s), &xscom_ops, s, name, XSCOM_SIZE); sysbus_init_mmio(sbd, &s->mem); sysbus_mmio_map(sbd, 0, XSCOM_BASE(s->chip_id)); Thanks, C.