Re: [Qemu-devel] [patch 2/2] qemu: switch pci device init functions to accept devfn

[Brian Wheeler <bdwheele@indiana.edu>]

On Mon, 2009-04-13 at 10:30 -0300, Marcelo Tosatti wrote:
> On Mon, Apr 13, 2009 at 01:27:34PM +0100, Paul Brook wrote:
> > On Monday 13 April 2009, Marcelo Tosatti wrote:
> > > Some pci device initialization functions do not accept a devfn parameter,
> > > but instead use "-1", which caused pci_register_device to find the first
> > > free slot on the given bus.
> > >
> > > Have them accept a "devfn" parameter, and use the newly introduced
> > > pci_bus_assign_dev_addr function on platform init code to perform
> > > the "first free" enumeration.
> > 
> > I don't see how this is better. If anything we want the platform code to get 
> > smaller, not larger.
> 
> Paul,
> 
> This is a intermediate step. Later you'd get rid of
> pci_bus_assign_dev_addr in platform code.
> 
> Ideally you'd have (I think):
> 
> - generic machine initialization code fills in details of pci device
>   address in pci device structure (or a temporary placeholder) taken from
>   machine description (optionally auto assigns from a free slot).

> - pci driver init functions take generic device pointer as an
>   argument (either containing the pre allocated pci device or temporary
>   placeholder), and pass that to pci_register_device, which does
>   actual registration of pci device on particular bus.
> 
> Does that make sense?
> 
> A benefit of the proposed patch is that it moves assumptions about pci  
> device address assignment from drivers up to platform code. Later you'd
> remove that from platform code to devtree data.
> 

Does this mean that there would be a mechanism for a platform to map the
pci memory address to a platform specific linear address?  Alpha uses 

0x8000000000 + (0x20000000 * bus) + address

to determine where the pci memory is mapped in the cpu address space...


Brian