On 09/06/2016 11:45 PM, 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 .
Well, "Pervasive" should be mentioned somewhere, it is central to PowerPC architecture. I will add a comment for the "PIB" (Pervasive Interconnect Bus) aka XSCOM bus > - 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. ok. So the ADU is the address space holder. > 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, yes, that will be helpful to trigger some behavior from the command line. > or if we ever do cosimulation with a separate BMC, a simulated FSI, > all by just calling the first object's methods. The cosimulation is not a long term goal, for the ipmi-bt part. But yes, having a more complete model would be excellent. Cheers, C.
