On 09/06/2016 11:49 PM, Benjamin Herrenschmidt wrote: > On Wed, 2016-09-07 at 07:47 +1000, Benjamin Herrenschmidt wrote: >> d be an extra op in the xscom device model I guess. >> >> No. If you split the XSCOM bus from the MMIO -> XSCOM bridge (the >> ADU) >> then the conversion only happens in the former. You don't directly >> route the MMIOs over ! You intercept the MMIOs and use use the >> address_space_rw to "generate" the XSCOM accesses on the other side, >> like I do for the LPC bus. >> >> We need that anyway because of the way XSCOMs can manipulate the HMER >> etc... >> >>> >>> Also, the main purpose of the XscomBus is to loop on the devices >>> to populate the device tree. I am wondering if we could just use >>> a simple list under the chip for that purpose. > > In fact, if you do the above, you no longer need a XSCOM device... > > A number of "devices" can exist below a chip, all they need to have > XSCOMs is to register memory regions that are child of that chip's > xscom_region.
yes. To hack my way through again, I have added a memory region under the XScomDevice, but we should have a list like the ranges[] because of the PHB3 PCBQs. > For device-tree, well, we could have a generic interface that anything > that can populate DT has and iterate through them. Or make a "chiplet" > class or something. yes, something like the XScomDeviceClass, which serves well the purpose anyhow. Thanks, C. > Cheers, > Ben. >
