From: Christer Weinigel <christer@weinigel.se>
To: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Nathan Laredo <laredo@gnu.org>, Jiri Slaby <jirislaby@gmail.com>,
Christer Weinigel <christer@weinigel.se>,
linux-kernel@vger.kernel.org, video4linux-list@redhat.com,
v4l-dvb maintainer list <v4l-dvb-maintainer@linuxtv.org>
Subject: Re: Stradis driver conflicts with all other SAA7146 drivers
Date: 28 May 2006 19:58:41 +0200 [thread overview]
Message-ID: <m3k686hvzi.fsf@zoo.weinigel.se> (raw)
In-Reply-To: <1148837483.1170.65.camel@praia>
Mauro Carvalho Chehab <mchehab@infradead.org> 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 <christer@weinigel.se> http://www.weinigel.se
next prev parent reply other threads:[~2006-05-28 17:58 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-28 12:33 Stradis driver conflicts with all other SAA7146 drivers Christer Weinigel
2006-05-28 12:53 ` Jiri Slaby
2006-05-28 14:04 ` Mauro Carvalho Chehab
2006-05-28 16:01 ` Nathan Laredo
2006-05-28 16:17 ` Jiri Slaby
2006-05-28 17:31 ` Mauro Carvalho Chehab
2006-05-28 17:58 ` Christer Weinigel [this message]
2006-05-28 18:40 ` Mauro Carvalho Chehab
2006-05-29 12:46 ` [v4l-dvb-maintainer] " Michael Hunold
2006-05-29 13:33 ` Mauro Carvalho Chehab
2006-05-29 13:43 ` Michael Hunold
2006-05-29 13:58 ` Mauro Carvalho Chehab
2006-05-29 14:38 ` Gerd Hoffmann
2006-05-31 14:01 ` Alan Cox
2006-05-31 14:29 ` Arjan van de Ven
2006-05-29 12:44 ` Michael Hunold
2006-05-29 22:51 ` Christer Weinigel
2006-05-28 16:02 ` Christer Weinigel
2006-05-28 16:36 ` Jiri Slaby
2006-05-28 17:17 ` Christer Weinigel
2006-05-28 17:36 ` Jiri Slaby
2006-05-28 17:46 ` matthieu castet
2006-05-28 20:29 ` Jiri Slaby
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3k686hvzi.fsf@zoo.weinigel.se \
--to=christer@weinigel.se \
--cc=jirislaby@gmail.com \
--cc=laredo@gnu.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@infradead.org \
--cc=v4l-dvb-maintainer@linuxtv.org \
--cc=video4linux-list@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox