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
signature.asc
Description: PGP signature