On 11.09.2012, at 21:05, Scott Wood <scottw...@freescale.com> wrote:
> On 09/11/2012 06:33 AM, Alexander Graf wrote: >> On 09/07/2012 08:58 PM, Scott Wood wrote: >>> I wasn't suggesting that they be different devices. I was suggesting >>> that this isn't a property of the PCI controller, but rather of some >>> other entity to which the PCI controller connects. So maybe a reference >>> to the associated CCSR object would be a qdev parameter, but not the >>> size of that CCSR. >> >> The first common place of information we get is the machine description. >> So here we can do: >> >> create_device(e500_ccsr, CCSR_SIZE); >> create_device(e500_pci_host_controller, CCSR_SIZE); >> >> Obviously code-wise this would look quite different from above, as >> object constructor parameters go through qdev properties. > > Keep in mind that in order to make MSIs work we need the BAR to actually > be hooked up to CCSR, not just sized properly. If qdev properties are > really stable API as you indicated recently, we want to get this right > and not introduce a short-term hack. Right. So I like Andreas' proposal. We pass in a reference to the ccsr object into our host controller object as parameter. That reference could maybe be a real pointer (if supported) or by-path. We can then use that to request the memory region that ccsr resides in. From that we can enumerate the size and also hook it up as BAR MMIO backing. Alex > > -Scott > >
