/dev/dvb device nodes not being created?
Jarod Wilson
jwilson at redhat.com
Sat Mar 24 18:49:18 UTC 2007
Chuck Ebbert wrote:
> Jarod Wilson wrote:
>> Chris Brown wrote:
>>> On 22/03/07, *Dave Jones* <davej at redhat.com <mailto:davej at redhat.com>>
>>> wrote:
>>>
>>> On Thu, Mar 22, 2007 at 11:15:32AM -0400, Chuck Ebbert wrote:
>>>
>>> > What are we supposed to do when this kind of thing happens? It
>>> appears that
>>> > multiple drivers claim to support the same hardware.
>>>
>>> Grr, this happens far too often. We have the same with for eg,
>>> orinoco and hostap right now. The usual deal is that we either
>>> just build the 'best' driver for that hardware, or if there's a case
>>> where both drivers support the same hardware _and_ some hardware unique
>>> to them, we nobble the pci table so that the crappier driver
>>> doesn't load on that hardware.
>>>
>>> As to which is the best one in this case.. I really don't know.
>>>
>>> Or maybe this is a situation where it's valid to have both drivers
>>> loaded?
>>> We don't actually support that right now, but patches went to
>>> linux-pci list
>>> last week that should be showing up in GregKHs tree adding an
>>> alternative
>>> method for drivers to bind to a device in situations where it's
>>> possible
>>> for two drivers to drive different parts of the same chip.
>>> (This case has been showing up more and more recently too..
>>> agp vs edac, matroxfb vs lm_sensors,..)
>>>
>>>
>>> Taking a look at:
>>>
>>> http://lwn.net/Articles/212535/
>>>
>>> which may be able to shed some light on the changes.
>> Yep.
>>
>>> Even with the
>>> blackbird driver blacklisted, the v4l2 loads but the dvb driver does
>>> not. It should be noted that the two co-exist peacefully when loaded but
>>> something is preventing the latter from loading - perhaps because the
>>> kernel "sees" the driver requirements as being satisfied by the v4l2 module?
>>>
>>> In any case, in this instance it is just that the cx88-dvb driver is
>>> failing to load as opposed to anything more sinister.
>> Interestingly enough, I was talking to one of the vl4-dvb maintainers
>> (Michael Krufky) on irc about this very driver two days ago. The
>> cx88-dvb driver is *supposed* to auto-load via a request_module() call
>> in cx8802. Similar for cx88-blackbird. Things broke when support for the
>> Hauppauge HVR1300 was added, because it actually needs *both* cx88-dvb
>> and cx88-blackbird. Upstream v4l-dvb has this fixed, verified by me from
>> 20070302 snapshot cx88-dvb/cx8802 drivers.
>
> So can they send a patch for -stable to fix it in 2.6.20?
Okay, patches are good to go for both cx88-dvb and dvb-bt8xx autoload
support. The cx88-dvb patch is a roll-up of three patches from upstream
v4l-dvb. I've successfully tested this patch atop 2.6.20 with a pcHDTV
HD-3000 card.
http://people.redhat.com/jwilson/misc/dvb-updates/linux-2.6-cx88-dvb-autoload.patch
The dvb-bt8xx patch is a newly-created patch by myself (with pointers
from Michael) that is essentially a clone of the cx88-dvb autoload bits.
It works flawlessly in my testing with a pcHDTV HD-2000 card. Its in
Michael's hands now, and he says he'll get it committed to the v4l-dvb
tree this afternoon.
http://people.redhat.com/jwilson/misc/dvb-updates/linux-2.6-cx88-dvb-autoload.patch
Semi-related to these patches is another cx88-dvb fix that we could
optionally add to fix some buffer issues on nxt200x-based cx88-dvb cards:
http://people.redhat.com/jwilson/misc/dvb-updates/linux-2.6-nxt200x-buffer.patch
All three apply cleanly to the current FC6 2.6.20 kernel tree, as
Patch30-32.
Lemme know if I can provide any further info!
--
Jarod Wilson
jwilson at redhat.com
More information about the Fedora-kernel-list
mailing list