[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [patch 2/2] qemu: switch pci device init functions to a
From: |
Brian Wheeler |
Subject: |
Re: [Qemu-devel] [patch 2/2] qemu: switch pci device init functions to accept devfn |
Date: |
Mon, 13 Apr 2009 09:47:39 -0400 |
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