Subject: Re: access to external proms for PCI#
To: David Laight <email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 12/18/2005 12:07:10
David Laight wrote:
>On Sun, Dec 18, 2005 at 09:21:52AM -0800, Garrett D'Amore wrote:
>>The current cardbus code, as I read it, only accesses the expansion rom
>>data if the configuration code (BIOS or elsewhere) writes a reasonable
>>address into the BAR register. I think therefore that using the PCI
>>code I was suggesting will be OK. (I.e. having it go ahead and map
>>expansion roms without enabling them.)
>Ok, if they've been allocated a physical address - but not a virtual one
>then you don't have a massive problem.
Myabe I wasn't clear. The idea here is to allocate a physical address
for expansion roms.
*But*, we will only do this on platforms that make use of the pci
configuration code in pciconf.c. (I.e. have PCI_NETBSD_CONFIGURE defined.)
Frankly, most platforms don't use the PCI_NETBSD_CONFIGURE code,
especially "full fledged" platforms like i386 and macppc. Instead, they
just use the windows that firmware set up.
Really, this change is going to have the largest impact on the various
eval boards out there that lack PCI configuration in their firmware (or
have horribly broken firmware.)
Here's a sample list of platforms that might use PCI_NETBSD_CONFIGURE:
Note the absence of most of the mass produced consumer platforms, i.e.
i386, sparc64, macppc, sgimips, hpc*, hppa, etc.
Now as far as Cardbus support goes, the cardbus code should probably use
the pci_mapreg_map() code to assign *virtual* addresses.
I have no idea how to get *physical* addresses assigned if the system
firmware has not already done so. It looks to me like the
PCI_NETBSD_CONFIGURE code does not know about CardBus bridges, and
therefore doesn't configure subordinate cardbus bridges.
Unifying that code to work is likely to be somewhat of a challenge. I'm
not sure how important Cardbus is likely to be on the platforms that use
PCI_NETBSD_CONFIGURE. My first reaction is that most of these platforms
probably only support the old 16-bit PCMCIA anyway, but maybe I'm
wrong. If so, then adding Cardbus support to these platforms may
require adding cardbus bridge support to pciconf.c. That's a bigger
issue, and not one that I feel an immediate need to address.
So, the nutshell is, can PCI_NETBSD_CONFIGURE code be changed so that
the following is true:
1. PCI_CONF_MAP_ROM sets up physical addresses for ROMs without
2. a new PCI_CONF_ENABLE_ROM will be a new bit that indicates to
actually enable expansion ROM address decoders (possibly only for
those ROMs that have reasonable physical addresses configured).
This can be set up so that platforms can use it in their MD
3. PCI_CONF_ALL will *not* include PCI_CONF_ENABLE_ROM.
4. the default for platforms without pci_conf_hook() will be
PCI_CONF_ALL (i.e. it will include PCI_CONF_MAP_ROM, but not
5. pci_mapreg_map should add a test to make sure that the rom address
decoder is enabled when type is PCI_MAPREG_TYPE_ROM
Then, we have two options for devices that need access to expansion roms:
1. pci_mapreg_map could automatically enable (and pci_mapreg_unmap
disable) access to expansion roms when called with type set to
PCI_MAPREG_TYPE_ROM (instead of step 5 above), or...
2. the actual device driver can do the enable/disable directly by
accessing pci configuration registers. So it would enable, then
call pci_mapreg_map, pci_mapreg_unmap, and finally disable access.
I'm in favor of the 2nd approach, because it minimizes changes to the
pci_mapreg_map API (no extra side effects for expansion ROM), although
it does put a small extra burden on device drivers that need expansion
ROM access. But since there are likely to be very, very few of these
(my radeonfb driver is the first one so far), I'm not overly concerned
Garrett D'Amore http://www.tadpolecomputer.com/
Sr. Staff Engineer Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc. Phone: (951) 325-2134