Newbie question about PCI detection...

[Philip Prindeville]

Luc Verhaegen wrote:

>On Tue, Jul 26, 2005 at 12:54:02PM -0600, Philip Prindeville wrote:
>  
>
>>I was wondering why a lot of drivers go for subsystem vendor ids
>>and subsystem device ids, rather than just going off the vendor ids
>>and device ids.  For example, I have an MSI K8MM-V motherboard
>>(1462:7142), which has onboard graphics using the Via Tech S3
>>Unichrome Pro chipset (1106:3108).
>>
>>A quick look at the drivers for this card show that it detects based on
>>the card id, and not on the chipset.  This is fairly common.
>>
>>Wouldn't it be simpler to detect first on the card id (since some cards are
>>quirky), and then detect on the chipset?
>>
>>What am I missing here?
>>
>>Thanks,
>>
>>-Philip
>>    
>>
>The main pciids are still checked here, the loading of this driver, since 
>it handles only pci era devices, entirely depends on the main pci ids.
>
>The subsystem/card ids are checked to see if there is any extra 
>initialisation that is needed. This is currently there for laptops only, i 
>have no means of checking wether the unichrome comes with a panel or not 
>(except for those cases where a probeable LVDS encoder is present). 
>Checking the subsystem ids is a very clean way to achieve this. Even 
>though some manufacturers don't properly set them.
>  
>

That's fine, I understand that.  But it seems that if the motherboard is
absent in the list of PCIDs, then the card isn't detected (despite the fact
that the driver should at least recognize the chipset generically).

Doing *additional* initialization based on the card-instance is one thing.
Failing to generically recognize the chipset and thereby detect the
graphic subsystem strikes me as overly pessimistic.

-Philip


>Another option is checking DMI information. A version written for 
>unichrome by Bernhard Rosenkraenzer grabbed a part of the bios and then 
>compared a given field with a laptop specific string. So, in effect, a 
>whole table of strings would have to be checked to know wether the panel 
>should be forced or not. Not only is this more work than simply getting 
>two 32bit integers from the pci header and comparing those to a table, it 
>is also more prone to BIOS quirks.
>
>This is very driver specific and i wish i didn't have to go through all of 
>this, but, as far as workarounds go, it could be worse.
>
>Luc Verhaegen.
>  
>