Skip to contentSkip to conversation

saa7134 duplicate device in module, but different device_data?

DISCUSSION Ben Collins 2 participants 5 messages Jun 26, 2008 – Jun 27, 2008 Media (V4L/DVB)

lore
Share & tools
lore
#0 lore raw

In the saa7134 module, there are these two entries in MODULE_DEVICE_TABLE():

        },{
                .vendor       = PCI_VENDOR_ID_PHILIPS,
                .device       = PCI_DEVICE_ID_PHILIPS_SAA7133,
                .subvendor    = 0x185b,
                .subdevice    = 0xc100,
                .driver_data  = SAA7134_BOARD_VIDEOMATE_TV,
        },{
                .vendor       = PCI_VENDOR_ID_PHILIPS,
                .device       = PCI_DEVICE_ID_PHILIPS_SAA7133,
                .subvendor    = 0x185b,
                .subdevice    = 0xc100,
                .driver_data  = SAA7134_BOARD_VIDEOMATE_TV_GOLD_PLUS,
        },{

Both will exactly match, and I assume only the first one will ever be used, hence the second is just a wasted dupe. At least, I would assume if not for the differing driver_data. Anyway to clear up this ambiguity?

#1 lore raw

Hello,

Am Donnerstag, den 26.06.2008, 13:24 -0400 schrieb Ben Collins:

Quoted 18 lines

In the saa7134 module, there are these two entries in MODULE_DEVICE_TABLE():

        },{
                .vendor       = PCI_VENDOR_ID_PHILIPS,
                .device       = PCI_DEVICE_ID_PHILIPS_SAA7133,
                .subvendor    = 0x185b,
                .subdevice    = 0xc100,
                .driver_data  = SAA7134_BOARD_VIDEOMATE_TV,
        },{
                .vendor       = PCI_VENDOR_ID_PHILIPS,
                .device       = PCI_DEVICE_ID_PHILIPS_SAA7133,
                .subvendor    = 0x185b,
                .subdevice    = 0xc100,
                .driver_data  = SAA7134_BOARD_VIDEOMATE_TV_GOLD_PLUS,
        },{
Quoted 4 lines

Both will exactly match, and I assume only the first one will ever be used, hence the second is just a wasted dupe. At least, I would assume if not for the differing driver_data. Anyway to clear up this ambiguity?

there are even more devices with the same PCI device and subsystem ID from that vendor and the problem goes also over saa7133 and saa7135 devices, for which we have no means to detect them as different, but the saa7133 does only NTSC-M system TV sound decoding and saa7135 and the even later saa7131e global analog TV sound.

For the early saa7133 SAA7134_BOARD_VIDEOMATE_TV we don't have eeprom readout data and the contributor doesn't have the card anymore. A request for helping out with such on the list had no result so far.

As of now, we can't try to separate them by eeprom differences, which would be the best attempt and is done for some other Compro products with similar flaws already.

Before that likely possible eeprom detection ever happens, we have two options left to make you feel better.

Kick both out of the auto detection and the users will get a list of supported devices printed out, from which they have to choose.

Leave the oldest one in and print some warnings that they have to look it up for their newer cards. Naming is quite consistent, except some early Gold Plus II variants seen first in New Zealand coming with Gold Plus only stickers. They also come with different tuners, latest have a separate silicon radio tuner and all such usual ...

Patches are always welcome.

Internally it was only a reminder for missing eeprom data to be investigated.

Cheers,
Hermann

#2 lore raw
Quoted 52 lines · hermann pitton

Hello,

Am Donnerstag, den 26.06.2008, 13:24 -0400 schrieb Ben Collins:

Quoted 18 lines

In the saa7134 module, there are these two entries in MODULE_DEVICE_TABLE():

        },{
                .vendor       = PCI_VENDOR_ID_PHILIPS,
                .device       = PCI_DEVICE_ID_PHILIPS_SAA7133,
                .subvendor    = 0x185b,
                .subdevice    = 0xc100,
                .driver_data  = SAA7134_BOARD_VIDEOMATE_TV,
        },{
                .vendor       = PCI_VENDOR_ID_PHILIPS,
                .device       = PCI_DEVICE_ID_PHILIPS_SAA7133,
                .subvendor    = 0x185b,
                .subdevice    = 0xc100,
                .driver_data  = SAA7134_BOARD_VIDEOMATE_TV_GOLD_PLUS,
        },{
Quoted 4 lines

Both will exactly match, and I assume only the first one will ever be used, hence the second is just a wasted dupe. At least, I would assume if not for the differing driver_data. Anyway to clear up this ambiguity?

there are even more devices with the same PCI device and subsystem ID from that vendor and the problem goes also over saa7133 and saa7135 devices, for which we have no means to detect them as different, but the saa7133 does only NTSC-M system TV sound decoding and saa7135 and the even later saa7131e global analog TV sound.

For the early saa7133 SAA7134_BOARD_VIDEOMATE_TV we don't have eeprom readout data and the contributor doesn't have the card anymore. A request for helping out with such on the list had no result so far.

As of now, we can't try to separate them by eeprom differences, which would be the best attempt and is done for some other Compro products with similar flaws already.

Before that likely possible eeprom detection ever happens, we have two options left to make you feel better.

Kick both out of the auto detection and the users will get a list of supported devices printed out, from which they have to choose.

Leave the oldest one in and print some warnings that they have to look it up for their newer cards. Naming is quite consistent, except some early Gold Plus II variants seen first in New Zealand coming with Gold Plus only stickers. They also come with different tuners, latest have a separate silicon radio tuner and all such usual ...

Quoted 4 lines

Patches are always welcome.

Internally it was only a reminder for missing eeprom data to be investigated.

Well I was thinking that mainly, this was just a table for loading and binding the driver with a device. In that case, only one entry is needed. The probing would have to decide which device it is.

I'm not up for suggesting a fix, because I don't know enough about the background. This email is just a friendly reminder that there exists ambiguity, and at least for one of these devices, the driver isn't going to detect it properly anyway :)

#3 lore raw

Am Donnerstag, den 26.06.2008, 20:06 -0400 schrieb Ben Collins:

Quoted 58 lines · hermann pitton
Quoted 52 lines

Hello,

Am Donnerstag, den 26.06.2008, 13:24 -0400 schrieb Ben Collins:

Quoted 18 lines

In the saa7134 module, there are these two entries in MODULE_DEVICE_TABLE():

        },{
                .vendor       = PCI_VENDOR_ID_PHILIPS,
                .device       = PCI_DEVICE_ID_PHILIPS_SAA7133,
                .subvendor    = 0x185b,
                .subdevice    = 0xc100,
                .driver_data  = SAA7134_BOARD_VIDEOMATE_TV,
        },{
                .vendor       = PCI_VENDOR_ID_PHILIPS,
                .device       = PCI_DEVICE_ID_PHILIPS_SAA7133,
                .subvendor    = 0x185b,
                .subdevice    = 0xc100,
                .driver_data  = SAA7134_BOARD_VIDEOMATE_TV_GOLD_PLUS,
        },{
Quoted 4 lines

Both will exactly match, and I assume only the first one will ever be used, hence the second is just a wasted dupe. At least, I would assume if not for the differing driver_data. Anyway to clear up this ambiguity?

there are even more devices with the same PCI device and subsystem ID from that vendor and the problem goes also over saa7133 and saa7135 devices, for which we have no means to detect them as different, but the saa7133 does only NTSC-M system TV sound decoding and saa7135 and the even later saa7131e global analog TV sound.

For the early saa7133 SAA7134_BOARD_VIDEOMATE_TV we don't have eeprom readout data and the contributor doesn't have the card anymore. A request for helping out with such on the list had no result so far.

As of now, we can't try to separate them by eeprom differences, which would be the best attempt and is done for some other Compro products with similar flaws already.

Before that likely possible eeprom detection ever happens, we have two options left to make you feel better.

Kick both out of the auto detection and the users will get a list of supported devices printed out, from which they have to choose.

Leave the oldest one in and print some warnings that they have to look it up for their newer cards. Naming is quite consistent, except some early Gold Plus II variants seen first in New Zealand coming with Gold Plus only stickers. They also come with different tuners, latest have a separate silicon radio tuner and all such usual ...

Quoted 4 lines

Patches are always welcome.

Internally it was only a reminder for missing eeprom data to be investigated.

Quoted 9 lines

Well I was thinking that mainly, this was just a table for loading and binding the driver with a device. In that case, only one entry is needed. The probing would have to decide which device it is.

I'm not up for suggesting a fix, because I don't know enough about the background. This email is just a friendly reminder that there exists ambiguity, and at least for one of these devices, the driver isn't going to detect it properly anyway :)

I do agree and will be happy with any patch you provide to get it out of sight ;)

Comes back to mind, there is another Compro one on M systems with a NEC "deghoster", converting to s-video for that and hence hangs on unusally TV vmux 7.

All through so far, but not on the ground enough, since users went away, after they have it working ...

Cheers,
Hermann

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

#4 lore raw

Am Freitag, den 27.06.2008, 02:59 +0200 schrieb hermann pitton:

Quoted 2 lines

Am Donnerstag, den 26.06.2008, 20:06 -0400 schrieb Ben Collins:

Quoted 1 line · hermann pitton

[snip]

Quoted 3 lines

I do agree and will be happy with any patch you provide to get it out of sight ;)

Ben,

just move the duplicate stuff out of the auto detection until we have something better and send that patch.

Previous hopes, to be able to do something more, are for sure disappointed now and no reason to wait any longer.

We rely on the eeprom gimmicks and they did use them mainly previously to shot down each other as best they can ...

Cheers,
Hermannn