qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-ppc] [PATCH] e500-pci: Factor into distinct mpc85


From: Alexander Graf
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] e500-pci: Factor into distinct mpc8540 and p4080 PCI Hosts
Date: Sun, 3 Jun 2012 13:21:48 +0200

On 03.06.2012, at 13:10, Ben Collins wrote:

> 
> On May 31, 2012, at 2:20 PM, Scott Wood wrote:
> 
>> On 05/30/2012 06:25 PM, Ben Collins wrote:
>>> In order to provide a closer virtualization, factor out e500-pci into 
>>> seperate
>>> PCI hosts, namely fsl,mpc8540-pci and fsl,p4080-pcie (to match the 
>>> device-tree
>>> node naming).
>>> 
>>> Make use of the mpc8540 variant (basically a NOP) for ppce500_mpc8544 
>>> machine
>>> type. The p4080-pcie variant can be used later for a P4080DS specific 
>>> machine
>>> description.
>>> 
>>> The major differences between the two are the host-bridge PCI device ID and 
>>> the
>>> difference in starting slot number. Eventually I'd like to get the p4080 
>>> variant
>>> to support any valid slot number, and actually move the bus behind the host
>>> bridge as is done in the physical hardware.
>> 
>> Do these really need to be totally separate implementations?  If we then
>> want to support another FSL PPC chip's PCI that has some subtle
>> differences, do we need a third?  If the emulation of these host bridges
>> is made more complete, we'll have to add that code to every one of these
>> forks.
>> 
>> I'd rather see one driver that is parameterizable to implement any
>> mpc85xx/mpc86xx/QorIQ PCI(e).
> 
> 
> I'm completely ok with that. My original intent was to remove the limitations 
> of the e500-pci driver, but Alexander had reservations about making the 
> mpc8540-pci implementation non-compliant to the original hardware. My main 
> goal is to make it so users (and myself) don't have to be limited by this 
> lowest-common-denominator (2-4 PCI slots, forced at 0x17 starting point).
> 
> I'll look into making this configurable. Are there any current PCI 
> implementations that allow for such configurability that I can base work on?

I'm not sure, but if you just pass all the differences as qdev parameters, you 
should be able to basically spawn your different PCI host bridge by just 
overriding those :)


Alex




reply via email to

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