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?
Hello,
Am Donnerstag, den 26.06.2008, 13:24 -0400 schrieb Ben Collins:
> 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?
>
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
On Fri, 2008-06-27 at 01:56 +0200, hermann pitton wrote:
> Hello,
>
> Am Donnerstag, den 26.06.2008, 13:24 -0400 schrieb Ben Collins:
> > 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?
> >
>
> 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.
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 :)
Am Donnerstag, den 26.06.2008, 20:06 -0400 schrieb Ben Collins:
> On Fri, 2008-06-27 at 01:56 +0200, hermann pitton wrote:
> > Hello,
> >
> > Am Donnerstag, den 26.06.2008, 13:24 -0400 schrieb Ben Collins:
> > > 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?
> > >
> >
> > 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.
>
> 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
Am Freitag, den 27.06.2008, 02:59 +0200 schrieb hermann pitton:
> Am Donnerstag, den 26.06.2008, 20:06 -0400 schrieb Ben Collins:
> > On Fri, 2008-06-27 at 01:56 +0200, hermann pitton wrote:
[snip]
> 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