Re: constraints on rbus_min_start?

[David Laight <david%l8s.co.uk@localhost>]

On Sun, Jan 06, 2008 at 10:13:38AM -0500, Nathan J. Williams wrote:
> "Steven M. Bellovin" <smb%cs.columbia.edu@localhost> writes:
> 
> >> The only way to determine the used addresses is to enumerate all the
> >> devices. That is potentially dangerous since you have to rewrite the
> >> BARs with a base address of 0 in order to determine the size.
> >> Presumably the NetBSD PCI device grope code will have done this
> >> during boot and remembered the addresses that are in use.
> >
> > Which should, then, be in some data structure somewhere...
> 
> NetBSD doesn't normally do this on desktop boxes; we assume that the
> firmware has done it. The option to probe and allocate all the BARs
> ourself (PCI_NETBSD_CONFIGURE) is more commonly used on embedded
> systems with minimal or PCI-unaware firmware. 

Ok, I wasn't sure whether we read the sizes, or just relied on the driver
to request the correct size be mapped.
I know that the only code that has enough info to assign the addresses
is really the system bios.
Which is why the bios options to not map all device registers (usually
something like 'pnp os') are silly.

> If PCI_CONFIG_DUMP is enabled, we will read the existing values and do
> the read/write/read/rewrite dance to size the BAR but restore the
> firmware-programmed value; I don't think that data is saved anywhere
> but the dmesg output.

Hmmm... hot-plug pci (and hence cardbus) does rather need to know this info.
Of course, it would be adequate if you could (BOIS) configure the amount
of memory and io space (etc) assigned to the PCI-PCI (aka cardbus) bridge.

        David

-- 
David Laight: david%l8s.co.uk@localhost