On Mon, 26 Feb 2007, Michael Krufky wrote:
> Trent Piepho wrote:
> > I think the problem is not with firmware for the tuner, but firmware for
> > the bridge. For instance, all the other dvb-pll tuners used in cxusb.c
> > have NULL specified for the i2c adapter.
>
> That is just a correlation. Those that you are thinking of are mt352 and / or
> zl10353-based frontends, which have the tuners behind the demod in the i2c path.
> This is a non-issue for the LG H06xF -- I promise you that. I tested your
> changes with the cxusb driver and it works just fine.
I remember someone on IRC having a problem with some device, I don't
remember which one, where the dvb-pll probe would fail the first time the
drivers were loaded after a cold boot, but if the module was re-loaded it
would work the second time. The problem was the the tuner wasn't reachable
over I2C until after some more initialization was done. Not like an Mt352,
where the tuner is never reachable.
> > I thought about that, but there are a dozen other drivers that use DVB_PLL,
> > and all of them select it unconditionally. The DVB_PLL entry is a "hidden"
> > one with no name that won't show up it the config menu. Of course, there
> > is no reason a separate patch can't add the ability to turn DVB_PLL on or
> > off from the DVB_FE_CUSTOMISE menu.
>
> That's a good point... but the detail that you are missing is the fact that
> those other drivers have static calls to dvb_pll_configure() ... Due to that
> fact, those drivers _require_ dvb-pll (until they get cleaned up / refactored)
>
> The changes that you are making here only introduce usage of dvb-pll using
> dvb_attach() , so the presence of dvb-pll is optional.
Unfortunately, that doesn't work. For example, b2c2-flexcop.ko only uses
dvb_pll in this one line in flexcop-fe-tuner.c:
dvb_attach(dvb_pll_attach, fc->fe, 0x61, NULL, &dvb_pll_samsung_tbmv);
But try compiling without dvb-pll: (* see note)
WARNING: "dvb_pll_samsung_tbmv" [/home/xyzzy/v4l-dvb-quick/v4l/b2c2-flexcop.ko] undefined!
And loading the module:
b2c2_flexcop: Unknown symbol dvb_pll_samsung_tbmv
Only the first parameter of dvb_attach() is a dynamic or weak reference,
the rest are normal.
In order to make dvb-pll dynamically loaded like the front-end modules,
something needs to be done to get rid of the static references to the pll
descriptions.
The v4l tuner module gives each PLL description a numeric ID. That way
they can be referred to without using any symbols from the tuner module.
Another way would be to refer to the description by name,
"dvb_pll_samsung_tbmv", and then have the dvb_pll_attach() function use
symbol_get() to turn the name into an address.
Or do the same thing, but somehow have dvb_attach(), or some variant of it,
be the one to call symbol_get(). e.g. dvb_attach_pll(dvb_pll_samsung_tbmv,
fc->fe, 0x61, NULL) which will use &dvb_pll_samsung_tbmv or
symbol_get("dvb_pll_samsung_tbmv") depending on whether dynamic attachment
is on or off, the same way dvb_attach() works.
Or put the PLL descriptions inside the card drivers that uses them. The
could go in the card drivers' code, or in a common header file (like
dvb-pll.h). I think if they are static with __attribute__((unused)), then
gcc won't actually put them into the object file, or emit a warning, if
they aren't used.
* note about modpost undefined symbol warnings
In order for these to work, you must edit your kernel's Module.symvers file
and delete all the v4l/dvb symbols. Otherwise modpost will think it's ok
for dvb-pll symbols to be undefined in the v4l-dvb Hg compile, since it
will find those symbols from your kernel compile. You should also delete
v4l/Module.symvers. make clean and make distclean don't delete it like
they should. So if you had dvb-pll enabled on a previous compile, the
dvb-pll symbols will still be in v4l/Module.symvers after you disable
dvb-pll.
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
