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