Re: [Qemu-devel] [PATCH v2 3/7] ppc/pnv: Add XSCOM infrastructure

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

On Wed, Sep 07, 2016 at 07:45:49AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2016-09-06 at 16:42 +0200, Cédric Le Goater wrote:
> > > Alternatively.. it might be simpler to just drop the SCOM as a
> > > separate device.  I think you could just hang the scom bus directly
> > > off the chip object.  IIUC the scom is basically the only chip-
> > level
> > > control mechanism, so this does make a certain amount of sense.
> > 
> > yes. I am exposing more and more stuff of the chip object under the 
> > xscom object so we should merge them. I agree. We will still need 
> > some XScomDevice of some sort.
> 
> What you can do is split it this way which matches the HW:
> 
>  - The chip object is the XSCOM parent, it owns the XSCOM bus,
> and expose functions (methods) to read/write XSCOMs. WE could rename
> XSCOM to "PIB" or "PCB" which is the real name of the bus ;-) But that
> might confuse things more than help .
> 
>  - A separate ADU object on each chip that is a SysDevice and does the
> MMIO bridge to XSCOM. It decodes the MMIO range for that chip and calls
> the above accessors.
> 
> That makes it easy to generate XSCOMs using different mechanisms if we
> wish to do so, which could come in handy, such as monitor commands, or
> if we ever do cosimulation with a separate BMC, a simulated FSI, all by
> just calling the first object's methods.

Not what I had in mind - I still was thinking of having the xscom
access unit do the translation and re-issue into the pcb bus address
space.

But sounds like this other approach could have some advantages.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]