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:

algor
bebox
cobalt
evbarm
evbmips
evbppc
evbsh5
ibmnws
iyonix
mvmeppc
pmppc
prep
sandpoint

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
      enabling them
   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
      pci_conf_hook().
   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
      PCI_CONF_ENABLE_ROM).
   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
about it.

    -- Garrett

>	David
>
>  
>


-- 
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