[lkml]   [2004]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: modprobe + request_module() deadlock
    > > They can't actually probe themself.  It's _one_ PCI device (driven by
    > > the saa7134 module) which can handle (among other v4l-related things)
    > > the DMA transfer of mpeg streams. That can be used in different ways
    > > (or not at all) and the different use cases are handled by the
    > > sub-modules.
    > >
    > > So the way it is intended to work is that saa7134 has the pci table and
    > > gets autoloaded by hotplug, it will have a look at the hardware and then
    > > load either saa7134-empress or saa7134-dvb or none of them, so you'll
    > > get everything nicely autoloaded.
    > The saa7146 driver seems to have a working solution for this
    > problem: The PCI ids are registered to the subdrivers (e.g. dvb-ttpci
    > or mxb) so that these are loaded via hotplug. They then register to the
    > saa7146 core as an "extension" module, and the core then does the probing.
    > Grep for saa7146_register_extension().

    That would be kida ugly because I'd need a dummy module then for the
    cards which need neither saa7134-empress nor saa7134-dvb (which is true
    for most of the existing cards btw).

    I can fix that in the driver, by delaying the request_module() somehow
    until the saa7134 module initialization is finished. I don't think that
    this is a good idea through as it looks like I'm not the only one with
    that problem ...


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:08    [W:0.020 / U:58.032 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site