[PATCH] Move the logic for matching devices out of probe routine.

[Mario Limonciello]

Hi Gaetan:

Gaetan Nadon wrote:
> Hi,
>
> A while ago I looked through the pci ids and found that a few were
> missing in the NVKnownChipsets array. It did not cause a problem because
> the case statement would recognize it. I see a case statement being
> deleted, so it would be safer to check that the following ids are
> recognized, otherwise some cards will be dropped from support.
>
> The comment I made beside refers to the id, for example, 0190, not 0191
> or 0192, and so on.
> NVIsG80(int chipType)
> {    switch(chipType & 0xfff0) {
>         case 0x0190:	"GeForce 8800 GTS"
>         case 0x05e0:	"GeForce GTX 295"	
>            return TRUE;
>     } return FALSE;
> }
>
> NVIsSupported(CARD32 id)
> {    /* look for a compatible devices which may be newer than
>        the NVKnownChipsets list above.  */
>     switch(id & 0xfff0) {
>     case 0x0390:	"GeForce 7650 GS"
>     case 0x03D0:	"Geforce 6150 SE / nForce 430"	-- C61 integrated
> graphics. 
>         return TRUE;
>     }
>     return FALSE;
> }
>
> These case statements are trying to look forward in time, making
> assumptions about future ids assignment.  
>   
In the table (and consequently the generated headers) I've tried to
explicitly call out anything that would have matched that bitmask.  This
means that when there is a new set of cards that doesn't match those
IDs, 12 more would have to be added.
> HSI bridge
> -------------
>
> During the transition between AGP to PCI, cards were released with a
> bridge to allow an AGP chispet to work on a PCI bridge and vice-versa.
> The reported id on the bus is the one from the bridge, not the one from
> the chipset. The nv driver made a call to find the id of the chipset. At
> first, there was a one to one mapping between the bridge id and chip id.
> Later, different chips were released behind the same bridge id. A bridge
> id may map to multiple chip id, some we support, others we don't.
>
> This makes it difficult to produce a static list of supported ids as we
> don't know what is behind the bridge. I was wondering if the existing
> behaviour for ids 00f0->00ff and 02e0->02e4 was preserved or changed by
> the generated list.
>   
So I'll resubmit with some of the probing code back in so that those
cards whose ID is hiding behind a bridge at least can be caught at probe
time.  As long as the IDs from the bridge are valid, we'll make it to
the probing portion of the code.  After that change, the behavior for
these devices shouldn't change, but this bug with the logic matching
would remain on those devices.
> Blank lines in the new list
> ----------------------------------
>
> +"10DE","0049",, This is the first blank line in the list. I think it
> comes from the case statements for all those ids it deems unassigned but
> supportable. However, some of the blank lines have been filled with
> newly released cards recently. Here are those ids for which we now have
> a name for:
>
> 0197    Tesla C870    I doubt nv supports this card
> 05E6    GeForce GTX 275
> 05E7    Tesla C1060
> 05ED    Quadro Plex 2200 D2
> 0618    GeForce GTX 260M
> 0619    Quadro FX 4700 X2
> 061B    Quadro FX 2700 / VX 200
> 0631    GeForce GTS 160M
> 0632    GeForce GTS 150M
> 0644    GeForce 9500 GS
> 0645    GeForce 9500 GS
> 0651    GeForce G 110M
> 0652    GeForce GT 130M
> 0653    GeForce GT 120M
> 065A    Quadro FX 1700M
> 065B    GeForce 9400 GT
> 06E2    GeForce 8400
> 06E3    GeForce 8300 GS
> 06EC    GeForce G 105M
> 06EF    GeForce G 103M
> 06FB    Quadro FX 370M
> 0A20    GeForce GT 220
> 0A60    GeForce G210
> 0A65    GeForce G210
>   
I'll add these in, but I'll resend the series with these as a separate
patch.
>
> Duplicate lines for the same id
> ---------------------------------------
>
> +"10DE","0194",," GeForce 8800 Ultra"
> +"10DE","0194",,
>
> +"10DE","019D",," Quadro FX 5600"
> +"10DE","019D",,
>
> +"10DE","019E",,
> +"10DE","019E",," Quadro FX 4600"
>
>   
Oversight on my part.  I'll pull these out.

Thanks for the feedback,

-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello at dell.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.x.org/archives/xorg-devel/attachments/20090914/03511b07/attachment.pgp