Hi,
[Nathan Laredo is the maintainer of the stradis driver but Jiri Slaby
submitted the PCI probing change that went into 2.6.16 so I'm Cc-ing
him too. I'm not a member of the video4linux mailing list so please
Cc me on any responses.]
The stradis driver in the 2.6.16 kernel only looks at the SAA7146
vendor and product ID and binds to any SAA7146 based device even if it
is not a stradis card. This stops all other SAA7146 drivers from
working, for example my WinTV Nova-T card using the budget-ci driver
doesn't work any longer. A lot of other people have also been bitten
by this.
So could you please modify your driver so that it only binds to real
stradis cards? If stradis cards have a subvendor and subdevice ID you
could just modify the pci_device_id table to look something like this:
static struct pci_device_id stradis_pci_tbl[] = {
{
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7146,
.subvendor = 0xdead,
.subdevice = 0xbeef,
},
{ 0 }
};
>From the code it looks as if some boards don't have a good subsystem
vendor and device ID:
if (!pdev->subsystem_vendor)
dev_info(&pdev->dev, "%d: rev1 decoder\n", saa_num);
else
dev_info(&pdev->dev, "%d: SDM2xx found\n", saa_num);
Are those rev1 boards out in the real world or are they just
prototypes? If they are prototypes, can you add the subvendor ID
anway and add a module parameter so that your driver only binds to
unspecified vendor IDs if you use that module parameter? Something
like this:
static int bind_to_anything = 0;
module_param(bind_to_anything, int, 0);
int __init stradis_init(void)
{
...
if (bind_to_anything) {
stradis_pci_tbl[0].subvendor = PCI_ANY_ID;
stradis_pci_tbl[0].subdevice = PCI_ANY_ID;
}
...
pci_register_driver(&stradis_driver);
...
}
For anyone submitting a new SAA7146 driver to the kernel in the
future, please be aware that your card isn't the only one that uses
that chip, so always add a subvendor/subdevice to your drivers.
/Christer
--
"Just how much can I get away with and still go to heaven?"
Freelance consultant specializing in device driver programming for Linux
Christer Weinigel <[email protected]> http://www.weinigel.se
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Christer Weinigel napsal(a):
> Hi,
>
> [Nathan Laredo is the maintainer of the stradis driver but Jiri Slaby
> submitted the PCI probing change that went into 2.6.16 so I'm Cc-ing
> him too. I'm not a member of the video4linux mailing list so please
> Cc me on any responses.]
>
> The stradis driver in the 2.6.16 kernel only looks at the SAA7146
> vendor and product ID and binds to any SAA7146 based device even if it
> is not a stradis card. This stops all other SAA7146 drivers from
> working, for example my WinTV Nova-T card using the budget-ci driver
> doesn't work any longer. A lot of other people have also been bitten
> by this.
>
> So could you please modify your driver so that it only binds to real
> stradis cards? If stradis cards have a subvendor and subdevice ID you
> could just modify the pci_device_id table to look something like this:
>
> static struct pci_device_id stradis_pci_tbl[] = {
> {
> .vendor = PCI_VENDOR_ID_PHILIPS,
> .device = PCI_DEVICE_ID_PHILIPS_SAA7146,
> .subvendor = 0xdead,
> .subdevice = 0xbeef,
> },
> { 0 }
> };
>
>>From the code it looks as if some boards don't have a good subsystem
> vendor and device ID:
>
> if (!pdev->subsystem_vendor)
> dev_info(&pdev->dev, "%d: rev1 decoder\n", saa_num);
> else
> dev_info(&pdev->dev, "%d: SDM2xx found\n", saa_num);
>
> Are those rev1 boards out in the real world or are they just
> prototypes? If they are prototypes, can you add the subvendor ID
> anway and add a module parameter so that your driver only binds to
> unspecified vendor IDs if you use that module parameter? Something
> like this:
>
> static int bind_to_anything = 0;
> module_param(bind_to_anything, int, 0);
>
> int __init stradis_init(void)
> {
> ...
> if (bind_to_anything) {
> stradis_pci_tbl[0].subvendor = PCI_ANY_ID;
> stradis_pci_tbl[0].subdevice = PCI_ANY_ID;
> }
> ...
> pci_register_driver(&stradis_driver);
> ...
> }
>
> For anyone submitting a new SAA7146 driver to the kernel in the
> future, please be aware that your card isn't the only one that uses
> that chip, so always add a subvendor/subdevice to your drivers.
The only difference is in order of searching for devices. Stradis now gets
control before your "real" driver. Kick stradis from your config or blacklist
it. Or, why you ever load module, you don't want to use?
There is no change in searching devices, it didn't check for subvendors before
not even now. If Nathan knows, there are some subvendor/subdevices ids, which we
should compare to, then yes, we can change the behaviour, otherwise, I am
afraid, we can't. It's vendors' problem, that they don't use this pci registers
(and it's evil) -- i think, that stradis cards have that two zeroed.
regards,
- --
Jiri Slaby http://www.fi.muni.cz/~xslaby
\_.-^-._ [email protected] _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEeZ0kMsxVwznUen4RAoh5AJ4lmYmYd6PYUZsnKOEw6nBnd+BIyACgim5k
PWpWmQPZc5PDpJdntNQ3eic=
=O7It
-----END PGP SIGNATURE-----
Em Dom, 2006-05-28 ?s 14:52 +0159, Jiri Slaby escreveu:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > For anyone submitting a new SAA7146 driver to the kernel in the
> > future, please be aware that your card isn't the only one that uses
> > that chip, so always add a subvendor/subdevice to your drivers.
The better is to use the existent driver instead of creating newer
ones.
> The only difference is in order of searching for devices. Stradis now gets
> control before your "real" driver. Kick stradis from your config or blacklist
> it.
This sucks. Distros should compile all drivers to support as much
hardware as possible. For now, it is better to implement Christer
suggestions.
> Or, why you ever load module, you don't want to use?
There's no safe way to make a driver to get control after the others, if
both are modules, so the option is to use the saa7146 driver instead of
stradis.
> There is no change in searching devices, it didn't check for subvendors before
> not even now. If Nathan knows, there are some subvendor/subdevices ids, which we
> should compare to, then yes, we can change the behaviour, otherwise, I am
> afraid, we can't. It's vendors' problem, that they don't use this pci registers
> (and it's evil) -- i think, that stradis cards have that two zeroed.
This is, in fact, a trouble on several video capture boards. A real
merge work should be done by migrating stradis to use the generic
support for SAA7146. Then, having just one board, those conflicts won't
happen.
>
> regards,
> - --
> Jiri Slaby http://www.fi.muni.cz/~xslaby
Cheers,
Mauro.
I agree that the real fix is to unify the stradis driver so that it
uses the existing saa7146 driver (and extending the saa7146 driver if
it doesn't have all the support necessary yet). Keep in mind that at
the time the driver was written, there was no other saa7146-based card
on the market (mid 1999).
Until the pci change there was never a single complaint.
Unfortunately it was ill timed to happen when I was busiest at work,
and even now I'm on my way to New Zealand for a month where I'll be
out of touc as well, so the "right" fix is not likely to happen soon.
I didn't even know that other saa7146 cards had been developed until
the bug reports about the conflicts started pouring in. I don't run
bleeding edge kernels anymore due to work having a rhel3 requirement
because the lame cad tool vendors are so far behind the curve.
- Nathan Laredo
[email protected]
On 5/28/06, Mauro Carvalho Chehab <[email protected]> wrote:
> Em Dom, 2006-05-28 ?s 14:52 +0159, Jiri Slaby escreveu:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
>
> > > For anyone submitting a new SAA7146 driver to the kernel in the
> > > future, please be aware that your card isn't the only one that uses
> > > that chip, so always add a subvendor/subdevice to your drivers.
> The better is to use the existent driver instead of creating newer
> ones.
> > The only difference is in order of searching for devices. Stradis now gets
> > control before your "real" driver. Kick stradis from your config or blacklist
> > it.
> This sucks. Distros should compile all drivers to support as much
> hardware as possible. For now, it is better to implement Christer
> suggestions.
> > Or, why you ever load module, you don't want to use?
> There's no safe way to make a driver to get control after the others, if
> both are modules, so the option is to use the saa7146 driver instead of
> stradis.
> > There is no change in searching devices, it didn't check for subvendors before
> > not even now. If Nathan knows, there are some subvendor/subdevices ids, which we
> > should compare to, then yes, we can change the behaviour, otherwise, I am
> > afraid, we can't. It's vendors' problem, that they don't use this pci registers
> > (and it's evil) -- i think, that stradis cards have that two zeroed.
> This is, in fact, a trouble on several video capture boards. A real
> merge work should be done by migrating stradis to use the generic
> support for SAA7146. Then, having just one board, those conflicts won't
> happen.
> >
> > regards,
> > - --
> > Jiri Slaby http://www.fi.muni.cz/~xslaby
>
> Cheers,
> Mauro.
>
>
Jiri Slaby <[email protected]> writes:
> Christer Weinigel napsal(a):
> > Hi,
> >
> > [Nathan Laredo is the maintainer of the stradis driver but Jiri Slaby
> > submitted the PCI probing change that went into 2.6.16 so I'm Cc-ing
> > him too. I'm not a member of the video4linux mailing list so please
> > Cc me on any responses.]
> >
> > The stradis driver in the 2.6.16 kernel only looks at the SAA7146
> > vendor and product ID and binds to any SAA7146 based device even if it
> > is not a stradis card. This stops all other SAA7146 drivers from
> > working, for example my WinTV Nova-T card using the budget-ci driver
> > doesn't work any longer. A lot of other people have also been bitten
> > by this.
> The only difference is in order of searching for devices. Stradis now gets
> control before your "real" driver. Kick stradis from your config or blacklist
> it. Or, why you ever load module, you don't want to use?
> There is no change in searching devices, it didn't check for subvendors before
> not even now. If Nathan knows, there are some subvendor/subdevices ids, which we
> should compare to, then yes, we can change the behaviour, otherwise, I am
> afraid, we can't. It's vendors' problem, that they don't use this pci registers
> (and it's evil) -- i think, that stradis cards have that two zeroed.
I'm running the stock Fedora Core 5 kernels, and for some reason the
stradis driver is loaded. I suppose there's some magic in the FC5
hotplug scripts that tries to load all device drivers that claim to
support a certain PCI device.
I have blacklisted the stradis driver on my system, which fixes it for
me, but it does feels as a workaround for a problem that ought to be
fixed in the driver. If the card doesn't have a subvendor/subdevice,
is there some way of doing a sanity check on the board to see if it
actually is a stradis card and then release the board if it isn't?
If the driver isn't fixed I'll file a bug report on the Fedora
bugzilla asking them to blacklist or just not compile that driver.
/Christer
--
"Just how much can I get away with and still go to heaven?"
Freelance consultant specializing in device driver programming for Linux
Christer Weinigel <[email protected]> http://www.weinigel.se
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nathan Laredo napsal(a):
> I agree that the real fix is to unify the stradis driver so that it
> uses the existing saa7146 driver (and extending the saa7146 driver if
> it doesn't have all the support necessary yet).
Yup, the best way to solve it.
>
> Until the pci change there was never a single complaint.
There was no pci_device_id table before (and no MODULE_DEVICE_TABLE), so
userspace didn't load the driver at all.
cheers,
- --
Jiri Slaby http://www.fi.muni.cz/~xslaby
\_.-^-._ [email protected] _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEeczoMsxVwznUen4RAm7QAKCUavRhZmwp4KzxdbSioaSpGNIlrACeLRU/
WU2a51USyUrMG55XTdHHV78=
=5cCd
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Christer Weinigel napsal(a):
> I'm running the stock Fedora Core 5 kernels, and for some reason the
> stradis driver is loaded. I suppose there's some magic in the FC5
> hotplug scripts that tries to load all device drivers that claim to
> support a certain PCI device.
Userspace now knows, that stradis can take control of this hardware, so US loads
it, because MODULE_DEVICE_TABLE is present in the driver (you may compare old
and new /lib/modules/`uname -r`/modules.pcimap). It shows us the next way, how
to solve this -- delete this TABLE line from the driver, to not advertise "I can
take control of it".
>
> I have blacklisted the stradis driver on my system, which fixes it for
> me, but it does feels as a workaround for a problem that ought to be
> fixed in the driver. If the card doesn't have a subvendor/subdevice,
> is there some way of doing a sanity check on the board to see if it
> actually is a stradis card and then release the board if it isn't?
Unfortunately not.
>
> If the driver isn't fixed I'll file a bug report on the Fedora
> bugzilla asking them to blacklist or just not compile that driver.
It is the best short-term solution, I think.
So, what to do now, Mauro, Nathan? Fix it in US (i.e. blacklist) or KS (i.e.
delete TABLE entry -- hope this helps) for the time until the driver will be
integrated?
regards,
- --
Jiri Slaby http://www.fi.muni.cz/~xslaby
\_.-^-._ [email protected] _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEedFnMsxVwznUen4RAnv3AKCthKpF67t+R+iAu0cs31icG1KH2ACgnwXw
UKrSzuXdr/sBAr+rDmAdPIk=
=2R9i
-----END PGP SIGNATURE-----
Jiri Slaby <[email protected]> writes:
> Christer Weinigel napsal(a):
> > fixed in the driver. If the card doesn't have a subvendor/subdevice,
> > is there some way of doing a sanity check on the board to see if it
> > actually is a stradis card and then release the board if it isn't?
> Unfortunately not.
Why not? There's an I2C bus with a bunch of devices on it. Isn't it
possible to do an I2C scan and if it doesn't match what's supposed to
be on the card fail the probe and release the PCI resources?
If there is no FPGA or the FPGA fails to respond, that should also be
a fairly good indicator that it is not a stradis board.
And it seems that at least some of the cards have a value in the
subvendor field since the driver says "SDM2xx found" if
pdev->subsystem_vendor is nonzero. So how common are the rev1 boards
(which I assume have zeroes in the subvendor/subdevice fields) and
what does "lspci -vn" for the SDM2xx boards say?
/Christer
--
"Just how much can I get away with and still go to heaven?"
Freelance consultant specializing in device driver programming for Linux
Christer Weinigel <[email protected]> http://www.weinigel.se
Em Dom, 2006-05-28 ?s 09:01 -0700, Nathan Laredo escreveu:
> I agree that the real fix is to unify the stradis driver so that it
> uses the existing saa7146 driver (and extending the saa7146 driver if
> it doesn't have all the support necessary yet). Keep in mind that at
> the time the driver was written, there was no other saa7146-based card
> on the market (mid 1999).
> Until the pci change there was never a single complaint.
It seems that both drivers were developed independently, and both went
to kernel in the past. Only some time after Jiri we realized that PCI
IDs were conflicting.
>
> Unfortunately it was ill timed to happen when I was busiest at work,
> and even now I'm on my way to New Zealand for a month where I'll be
> out of touc as well, so the "right" fix is not likely to happen soon.
So, we need a quick fix. Maybe the better for now is to do a quick
workaround to 2.6.17, backported also to 2.6.16. We can work for a
definitive solution to 2.6.18 or 2.6.19.
>
> I didn't even know that other saa7146 cards had been developed until
> the bug reports about the conflicts started pouring in. I don't run
> bleeding edge kernels anymore due to work having a rhel3 requirement
> because the lame cad tool vendors are so far behind the curve.
There are some new boards from a very well known vendor in Europe
(Hauppauge) that uses also saa7146.
Currently, there are some drivers probing for saa7146 PCI IDs:
probing all PCI IDs:
dpc7146.c, hexium_orion.c, mxb.c, stradis.c
probing specific IDs:
hexium_gemini.c
I can imagine some possible solutions for this right now:
1) to include an insmod flag to allow PCI generic detection for each
driver. So, the default behavior would be the one at the previous
kernels;
2) We may create one saa7146_driver that probes the required PCI IDs and
then load the corresponding driver of the above listed. For those boards
whose don't have its own ID, an insmod parameter (or an autodetection
procedure) may specify if it is a dpc7146, hexium_orion, mxb or stradis
board.
(2) would be an interim solution until we integrate all stuff into just
one driver.
> - Nathan Laredo
> [email protected]
>
> On 5/28/06, Mauro Carvalho Chehab <[email protected]> wrote:
> > Em Dom, 2006-05-28 ?s 14:52 +0159, Jiri Slaby escreveu:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> >
> > > > For anyone submitting a new SAA7146 driver to the kernel in the
> > > > future, please be aware that your card isn't the only one that uses
> > > > that chip, so always add a subvendor/subdevice to your drivers.
> > The better is to use the existent driver instead of creating newer
> > ones.
> > > The only difference is in order of searching for devices. Stradis now gets
> > > control before your "real" driver. Kick stradis from your config or blacklist
> > > it.
> > This sucks. Distros should compile all drivers to support as much
> > hardware as possible. For now, it is better to implement Christer
> > suggestions.
> > > Or, why you ever load module, you don't want to use?
> > There's no safe way to make a driver to get control after the others, if
> > both are modules, so the option is to use the saa7146 driver instead of
> > stradis.
> > > There is no change in searching devices, it didn't check for subvendors before
> > > not even now. If Nathan knows, there are some subvendor/subdevices ids, which we
> > > should compare to, then yes, we can change the behaviour, otherwise, I am
> > > afraid, we can't. It's vendors' problem, that they don't use this pci registers
> > > (and it's evil) -- i think, that stradis cards have that two zeroed.
> > This is, in fact, a trouble on several video capture boards. A real
> > merge work should be done by migrating stradis to use the generic
> > support for SAA7146. Then, having just one board, those conflicts won't
> > happen.
> > >
> > > regards,
> > > - --
> > > Jiri Slaby http://www.fi.muni.cz/~xslaby
> >
> > Cheers,
> > Mauro.
> >
> >
Cheers,
Mauro.
Christer Weinigel napsal(a):
> Jiri Slaby <[email protected]> writes:
>
>> Christer Weinigel napsal(a):
>>> fixed in the driver. If the card doesn't have a subvendor/subdevice,
>>> is there some way of doing a sanity check on the board to see if it
>>> actually is a stradis card and then release the board if it isn't?
>> Unfortunately not.
>
> Why not? There's an I2C bus with a bunch of devices on it. Isn't it
> possible to do an I2C scan and if it doesn't match what's supposed to
> be on the card fail the probe and release the PCI resources?
This is an older method not used for device drivers, but only for searching for
busses or i2c et al, of which drivers stands aside and controls the device.
>
> If there is no FPGA or the FPGA fails to respond, that should also be
> a fairly good indicator that it is not a stradis board.
Yup, but pci probing doesn't have such mechanism.
>
> And it seems that at least some of the cards have a value in the
> subvendor field since the driver says "SDM2xx found" if
> pdev->subsystem_vendor is nonzero. So how common are the rev1 boards
> (which I assume have zeroes in the subvendor/subdevice fields) and
> what does "lspci -vn" for the SDM2xx boards say?
If it happens that way, it's easy to add sub*ids into pci device id table too
and the problem will go away.
regards,
--
Jiri Slaby http://www.fi.muni.cz/~xslaby
\_.-^-._ [email protected] _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
Jiri Slaby wrote:
> Christer Weinigel napsal(a):
>
>>Jiri Slaby <[email protected]> writes:
>>
>>
>>>Christer Weinigel napsal(a):
>>>
>>>>fixed in the driver. If the card doesn't have a subvendor/subdevice,
>>>>is there some way of doing a sanity check on the board to see if it
>>>>actually is a stradis card and then release the board if it isn't?
>>>
>>>Unfortunately not.
>>
>>Why not? There's an I2C bus with a bunch of devices on it. Isn't it
>>possible to do an I2C scan and if it doesn't match what's supposed to
>>be on the card fail the probe and release the PCI resources?
>
> This is an older method not used for device drivers, but only for searching for
> busses or i2c et al, of which drivers stands aside and controls the device.
>
>>If there is no FPGA or the FPGA fails to respond, that should also be
>>a fairly good indicator that it is not a stradis board.
>
> Yup, but pci probing doesn't have such mechanism.
Hum ?
The driver have to return an error (negative value) in the probbing
function if it detect that the card fails to respond correctly.
Same happen for i2c.
If the driver didn't manage to find what it expect on the i2c bus, the
driver won't be usefull for the device, so the driver should release the
device.
Matthieu
Mauro Carvalho Chehab <[email protected]> writes:
> Em Dom, 2006-05-28 ?s 09:01 -0700, Nathan Laredo escreveu:
> > I agree that the real fix is to unify the stradis driver so that it
> > uses the existing saa7146 driver (and extending the saa7146 driver if
> > it doesn't have all the support necessary yet). Keep in mind that at
> > the time the driver was written, there was no other saa7146-based card
> > on the market (mid 1999).
> > Until the pci change there was never a single complaint.
> It seems that both drivers were developed independently, and both went
> to kernel in the past. Only some time after Jiri we realized that PCI
> IDs were conflicting.
> >
> > Unfortunately it was ill timed to happen when I was busiest at work,
> > and even now I'm on my way to New Zealand for a month where I'll be
> > out of touc as well, so the "right" fix is not likely to happen soon.
> So, we need a quick fix. Maybe the better for now is to do a quick
> workaround to 2.6.17, backported also to 2.6.16. We can work for a
> definitive solution to 2.6.18 or 2.6.19.
> >
> > I didn't even know that other saa7146 cards had been developed until
> > the bug reports about the conflicts started pouring in. I don't run
> > bleeding edge kernels anymore due to work having a rhel3 requirement
> > because the lame cad tool vendors are so far behind the curve.
> There are some new boards from a very well known vendor in Europe
> (Hauppauge) that uses also saa7146.
>
> Currently, there are some drivers probing for saa7146 PCI IDs:
> probing all PCI IDs:
> dpc7146.c, hexium_orion.c, mxb.c, stradis.c
> probing specific IDs:
> hexium_gemini.c
dpc7146, hexium_orion and mxb don't match all PCI IDs, they only match
boards with zero as a board ID. So they won't conflict with
non-broken boards that have valid subvendor IDs. But they will
conflict with each other.
How may of these boards are broken and have zeroes in the
subvendor/subdevice fields? Apparently some of the dpc7146f,
hexium_orion, mxb, and stradis boards are broken. How many of the
boards supported by the generic saa7146 driver are broken the same
way?
Can't the stradis driver do the same thing as the other drivers and
explicitly match the broken zero subvendor id and the non-broken
subvendor IDs?
static struct pci_device_id pci_tbl[] = {
{
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7146,
.subvendor = 0x0000,
.subdevice = 0x0000,
},
{
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7146,
.subvendor = STRADIS_SUBVENDOR_ID,
.subdevice = STRADIS_SUBDEVICE_ID,
},
{ }
}
That would fix the problem for me and make it SEP. :-)
Can somebody with a SDM2xx stradis board mail me the output from
"lspci -vn" and I'll cobble together a patch that does this?
This still needs solving properly, but at least it makes it less of
a problem for people with non-broken hardware.
/Christer
--
"Just how much can I get away with and still go to heaven?"
Freelance consultant specializing in device driver programming for Linux
Christer Weinigel <[email protected]> http://www.weinigel.se
Em Dom, 2006-05-28 ?s 19:58 +0200, Christer Weinigel escreveu:
> Mauro Carvalho Chehab <[email protected]> writes:
> dpc7146, hexium_orion and mxb don't match all PCI IDs, they only match
> boards with zero as a board ID. So they won't conflict with
> non-broken boards that have valid subvendor IDs. But they will
> conflict with each other.
Yes. it is this I was trying to say :)
>
> How may of these boards are broken and have zeroes in the
> subvendor/subdevice fields? Apparently some of the dpc7146f,
> hexium_orion, mxb, and stradis boards are broken. How many of the
> boards supported by the generic saa7146 driver are broken the same
> way?
I don't have any saa7146 board, but, on bttv, most boards don't have its
own PCI ID.
>
> Can't the stradis driver do the same thing as the other drivers and
> explicitly match the broken zero subvendor id and the non-broken
> subvendor IDs?
>
> That would fix the problem for me and make it SEP. :-)
This seems to be an interesting idea: to make stradis just probe the
recognized IDs and the generic one. It won't solve, however, the probing
intersection for dpc7146f, hexium_orion, mxb, and stradis when no
subvendor ID is specified on the board.
>
> Can somebody with a SDM2xx stradis board mail me the output from
> "lspci -vn" and I'll cobble together a patch that does this?
>
> This still needs solving properly, but at least it makes it less of
> a problem for people with non-broken hardware.
>
> /Christer
>
Cheers,
Mauro.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
matthieu castet napsal(a):
> Jiri Slaby wrote:
>> Christer Weinigel napsal(a):
>>> Why not? There's an I2C bus with a bunch of devices on it. Isn't it
>>> possible to do an I2C scan and if it doesn't match what's supposed to
>>> be on the card fail the probe and release the PCI resources?
>>
>> This is an older method not used for device drivers, but only for
>> searching for
>> busses or i2c et al, of which drivers stands aside and controls the
>> device.
>>
>>> If there is no FPGA or the FPGA fails to respond, that should also be
>>> a fairly good indicator that it is not a stradis board.
>>
>> Yup, but pci probing doesn't have such mechanism.
> Hum ?
> The driver have to return an error (negative value) in the probbing
> function if it detect that the card fails to respond correctly.
I meant something other. Now it's clear, ignore that sentence in my reply,
please. Of course, there is a mechanism how driver can tell layers upwards it
can't drive the device.
regrads,
- --
Jiri Slaby http://www.fi.muni.cz/~xslaby
\_.-^-._ [email protected] _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEeggJMsxVwznUen4RAprXAKCNwSJpVIItEPm7cPSLvtS5xeT/gwCeI6UP
4SXefweIJhM0j2DA1wxlyZ4=
=RmKM
-----END PGP SIGNATURE-----
Hello,
sorry for jumping into this thread so late.
on 28.05.2006 19:58 Christer Weinigel said the following:
> Mauro Carvalho Chehab <[email protected]> writes:
>>Em Dom, 2006-05-28 ?s 09:01 -0700, Nathan Laredo escreveu:
> dpc7146, hexium_orion and mxb don't match all PCI IDs, they only match
> boards with zero as a board ID. So they won't conflict with
> non-broken boards that have valid subvendor IDs. But they will
> conflict with each other.
That's unfortunately right.
> How may of these boards are broken and have zeroes in the
> subvendor/subdevice fields? Apparently some of the dpc7146f,
> hexium_orion, mxb, and stradis boards are broken.
I would not call them broken.
They simply don't have subvendor/subdevice informations, but when these
informations are requested, the card gives back zeroes.
> How many of the
> boards supported by the generic saa7146 driver are broken the same
> way?
I can confirm this for the dpc7146, the mxb and the hexium_orion.
> This still needs solving properly, but at least it makes it less of
> a problem for people with non-broken hardware.
Up to now, this problem did not show up so drastically. On the one hand,
just a few dozen people use the MXB, a handful use the hexium_orion and
the dpc7146 is really rare. All these users then simply tweaked their
environment so that it works for the next boot.
In order to fix this, these drivers should not be autoloaded because
there is no sane way to autodetect these cards. In theory, you could do
an i2c bus scan and check if all devices are there. But since MXB and
dpc7146 both use the saa7111 video decoder on address 0x11 IIRC, the
dpc7146 will grab any MXB device if loaded before.
Distributions probably should keep these drivers from being autoloaded.
> /Christer
Best regards
Michael.
Hi,
on 28.05.2006 20:40 Mauro Carvalho Chehab said the following:
> I don't have any saa7146 board, but, on bttv, most boards don't have its
> own PCI ID.
As I said in the other mail, dpc7146, mxb and hexium_orion don't have
subvendor/subdevice ids.
> It won't solve, however, the probing
> intersection for dpc7146f, hexium_orion, mxb, and stradis when no
> subvendor ID is specified on the board.
Probing is probably not possible for the devices mentioned above.
> Cheers,
> Mauro.
CU
Michael.
Hi, Michael,
Em Seg, 2006-05-29 ?s 14:46 +0200, Michael Hunold escreveu:
> Hi,
>
> on 28.05.2006 20:40 Mauro Carvalho Chehab said the following:
> > I don't have any saa7146 board, but, on bttv, most boards don't have its
> > own PCI ID.
>
> As I said in the other mail, dpc7146, mxb and hexium_orion don't have
> subvendor/subdevice ids.
>
> > It won't solve, however, the probing
> > intersection for dpc7146f, hexium_orion, mxb, and stradis when no
> > subvendor ID is specified on the board.
>
> Probing is probably not possible for the devices mentioned above.
On bttv and other boards, were we have such conflicts, we have an option
to specify what board is used (called card). When the driver locates a
board without PCI subvendor ID, it shows a help msg at dmesg and exits
(or load a generic handler). The user may then use card=xx (where xx is
the number of the board). IMHO, this is the better for saa7146 boards.
>
> > Cheers,
> > Mauro.
>
> CU
> Michael.
Cheers,
Mauro.
Hi,
on 29.05.2006 15:33 Mauro Carvalho Chehab said the following:
> On bttv and other boards, were we have such conflicts, we have an option
> to specify what board is used (called card). When the driver locates a
> board without PCI subvendor ID, it shows a help msg at dmesg and exits
> (or load a generic handler). The user may then use card=xx (where xx is
> the number of the board). IMHO, this is the better for saa7146 boards.
bttv is a monolithic driver for all devices using Bt8x8 chipsets,
whereas saa7146 and saa7146_vv only hold the core infrastructure that is
common for all saa7146 cards.
saa7146 does not know anything about a card, but the so-called extension
driver (like mxb, hexium_orion or dpc7146) does. It holds the PCI IDs
and is responsible for telling the system what card it supports and do
any probing if necessary.
I don't know where to put the card=xx parameter in that case, because
the hexium_orion does not know mxb nor dpc7146. 8-(
Since these cards don't have subvendor/subdevice IDs, it's impossible to
find out which card is in the system.
CU
Michael.
Em Seg, 2006-05-29 ?s 15:43 +0200, Michael Hunold escreveu:
> Hi,
>
> on 29.05.2006 15:33 Mauro Carvalho Chehab said the following:
> > On bttv and other boards, were we have such conflicts, we have an option
> > to specify what board is used (called card). When the driver locates a
> > board without PCI subvendor ID, it shows a help msg at dmesg and exits
> > (or load a generic handler). The user may then use card=xx (where xx is
> > the number of the board). IMHO, this is the better for saa7146 boards.
>
> bttv is a monolithic driver for all devices using Bt8x8 chipsets,
> whereas saa7146 and saa7146_vv only hold the core infrastructure that is
> common for all saa7146 cards.
>
> saa7146 does not know anything about a card, but the so-called extension
> driver (like mxb, hexium_orion or dpc7146) does. It holds the PCI IDs
> and is responsible for telling the system what card it supports and do
> any probing if necessary.
>
> I don't know where to put the card=xx parameter in that case, because
> the hexium_orion does not know mxb nor dpc7146. 8-(
>
> Since these cards don't have subvendor/subdevice IDs, it's impossible to
> find out which card is in the system.
We have two tasks:
1) Integrate your code and Nathan one;
2) create a generic handler for all saa7146 boards, moving all PCI probe
to the newer module. After detecting the card number, it should request
the specific module.
>
> CU
> Michael.
Cheers,
Mauro.
>> Since these cards don't have subvendor/subdevice IDs, it's impossible to
>> find out which card is in the system.
>
> We have two tasks:
>
> 1) Integrate your code and Nathan one;
>
> 2) create a generic handler for all saa7146 boards, moving all PCI probe
> to the newer module. After detecting the card number, it should request
> the specific module.
Well, that doesn't solve the fundamental problem that you can't get it
right without help of the user. Maybe the best solution would be that
no driver is allowed to occupy a device without subsystem id unless
explicitly asked by the user to do so (that would also a good idea for
bttv btw). A small PCI probing module would be one way to do that, but
it is certainly not the only one. You could also do something like
adding a pcislot=... insmod option to the existing drivers.
just my 2 cent,
Gerd
--
Gerd Hoffmann <[email protected]>
http://www.suse.de/~kraxel/julika-dora.jpeg
Michael Hunold <[email protected]> writes:
> Up to now, this problem did not show up so drastically. On the one hand,
> just a few dozen people use the MXB, a handful use the hexium_orion and
> the dpc7146 is really rare. All these users then simply tweaked their
> environment so that it works for the next boot.
>
> In order to fix this, these drivers should not be autoloaded because
> there is no sane way to autodetect these cards. In theory, you could do
> an i2c bus scan and check if all devices are there. But since MXB and
> dpc7146 both use the saa7111 video decoder on address 0x11 IIRC, the
> dpc7146 will grab any MXB device if loaded before.
Ouch. Oh well, that means that those cards will need some kind of
manual intervention.
> Distributions probably should keep these drivers from being autoloaded.
I'm not too sure of how the module autoloading works, but would it
help just remove the line with:
MODULE_DEVICE_TABLE(pci, pci_tbl);
from those drivers? If I understand correctly, the contens of
MODULE_DEVICE_TABLE is what ends up in modules.pcimap. That should
fix it for most distributions and the owners of those cards have to
add a manual modprobe command to their rc.local.
/Christer
--
"Just how much can I get away with and still go to heaven?"
Freelance consultant specializing in device driver programming for Linux
Christer Weinigel <[email protected]> http://www.weinigel.se
On Mon, May 29, 2006 at 10:58:59AM -0300, Mauro Carvalho Chehab wrote:
> 1) Integrate your code and Nathan one;
>
> 2) create a generic handler for all saa7146 boards, moving all PCI probe
> to the newer module. After detecting the card number, it should request
> the specific module.
#2 breaks some existing setups that build modules to load based on the PCI
tables or built initrds this way. You can have two drivers for the same
PCI identifier providing that they both know how to bail out for the wrong
type of card
On Wed, 2006-05-31 at 10:01 -0400, Alan Cox wrote:
> On Mon, May 29, 2006 at 10:58:59AM -0300, Mauro Carvalho Chehab wrote:
> > 1) Integrate your code and Nathan one;
> >
> > 2) create a generic handler for all saa7146 boards, moving all PCI probe
> > to the newer module. After detecting the card number, it should request
> > the specific module.
>
> #2 breaks some existing setups that build modules to load based on the PCI
> tables or built initrds this way.
not if you make this meta module depend on the other two, that way all
this infrastructure will just pull the right stuff in.. at the price
of some wasted memory for the one you don't need
