Re: [Qemu-devel] [Qemu-ppc] [PATCH] e500-pci: Factor into distinct mpc8540 and p4080 PCI Hosts

Re: [Qemu-devel] [Qemu-ppc] [PATCH] e500-pci: Factor into distinct mpc8540 and p4080 PCI Hosts

[Andreas Färber]

Am 31.05.2012 01:25, schrieb Ben Collins:
> 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.
> 
> Signed-off-by: Ben Collins <bcollins@ubuntu.com>

Please always cc qemu-devel on patches and the respective maintainers,
here ppc and pci.

Thanks,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [Qemu-ppc] [PATCH] e500-pci: Factor into distinct mpc8540 and p4080 PCI Hosts

[Ben Collins]

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?

--
Bluecherry: http://www.bluecherrydvr.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu    : http://www.ubuntu.com/
My Blog   : http://ben-collins.blogspot.com/

Re: [Qemu-devel] [Qemu-ppc] [PATCH] e500-pci: Factor into distinct mpc8540 and p4080 PCI Hosts

[Alexander Graf]

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