All, sorry to bring this up again, but I don't think we had a final
consensus.  I would like to reach one so that I can submit a patch. 
(Alternatively, I can submit a patch and let people hammer on it.  But I
cannot commit directly as I don't have a CVS account, so someone else
would have to do that for me.)

Recall, I want to change the code with PCI_NETBSD_CONFIGURE so that we
create a new bit, PCI_CONF_ENABLE_ROM, which actually enables the PCI
expansion ROM address decoders, and change the behavior of
PCI_CONF_MAP_ROM so that all it does is assign them address space
(without actually enabling them.)

Additionally, I want PCI_CONF_ALL to *not* include PCI_CONF_ENABLE_ROM,
or I want to have a new default, perhaps called PCI_CONF_DEFAULT, which
includes all bits except PCI_CONF_ENABLE_ROM.

I'm willing to defer the logic to enable the ROM address decoders to
those device drivers which have to enable the decoder for now, though it
might be nice to have a common function which toggles the enable bit --
or perhaps have it performed automatically by pci_mapreg_map() for
PCI_MAPREG_TYPE_ROM.  But again, I can defer this part of the decision,
if we have consensus about the bits and behaviors above.

Thanks.

    -- Garrett

Garrett D'Amore wrote:

>David Laight wrote:
>
>  
>
>>On Sun, Dec 18, 2005 at 06:04:02PM -0500, Nathan J. Williams wrote:
>> 
>>
>>    
>>
>>>"Garrett D'Amore" <garrett_damore@tadpole.com> writes:
>>>
>>>   
>>>
>>>      
>>>
>>>>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.
>>>>     
>>>>
>>>>        
>>>>
>>>Any platforms that have PCI could easily have a PCI->Cardbus bridge
>>>chip.
>>>   
>>>
>>>      
>>>
>>If not you could always plug in a card that contains one...
>>
>>Also you can get cardbus cards that connect an external PCI chassis
>>to a notebook...  (This is where you need bus resources for the
>>cardbus slot - especially bus numbers.)
>> 
>>
>>    
>>
>Yes, I know about these (both cases).  (I looked into adding support for
>a userland Fcode interpreter for Cardbus devices on Solaris,
>specifically to provide support for certain brain damaged PCI devices
>that need system firmware to initialize them.  Someone wanted to use
>these devices from a magma chassis over cardbus.)
>
>Fixing up PCI and CardBus configuration for platforms that have no
>firmware would not be very hard.  My point is that I don't think anyone
>is using these configurations *today*.  Most Cardbus users probably have
>laptop class machines, with an occasional desktop class thrown in.  
>These systems are likely to have a reasonable host firmware.
>
>Most eval and single board systems are likely to include PCMCIA as a way
>to get to 802.11b, CompactFlash and IDE cheaply.  CardBus is not "cheap"
>by comparision, and designers for development boards are more likely to
>be interested in miniPCI than Cardbus for these kinds of solutions.
>
>In any case, I'm not interested in fixing Cardbus on these systems
>*right now*.  I *am* interested in providing access to PCI expansion
>ROMs right now.  So I need to know whether we can commit my proposed
>changes to how PCI_NETBSD_CONFIGURE works.
>
>In the longer term, maybe we need to look more closely at cleaning up
>and unifying PCI configuration for all platforms.  But I would want to
>have platform experts helping out with that -- folks who know the BIOS
>and OpenBoot well enough to understand implications.
>
>For PC systems where reprogramming the BAR (e.g. for VGA that was
>alluded to ealier) has bad consequences, then we have to accomodate that.
>
>Perhaps PCI_NETBSD_CONFIGURE should be modified so that it optionally
>includes a preliminary pass to discover devices that are already
>configured by system firmware, and avoid disrupting those
>(PCI_CONF_MERGE anyone?)  This would mean that the extents supplied to
>the configuration routine would have to match those used by system
>firmware.  Again, this points to needing platform experts to help out
>with getting this "right".  (If no one else steps forward, I can help
>out with SPARC, but it will require some research on my part because I
>am not familiar with OpenBoot internals, specifically.)
>
>    -- 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