qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Cédric Le Goater
Subject: Re: [Qemu-ppc] [PATCH v2 3/7] ppc/pnv: Add XSCOM infrastructure
Date: Wed, 7 Sep 2016 17:55:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

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.
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]