Trent Piepho wrote:
> 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.
That was the Avermedia A180, using the nxt2004 demod, which needs to have its
firmware loaded before attempting to communicate with the tuner via i2c.
I repeat: this is not an issue for the LG TDVS H06xF
>>> 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.
You're right There's no sense in breaking the pll descriptions up into separate
files simply for the sake of making dvb-pll optional. It is more valuable, IMHO,
to have all of the descriptions stored in a central location so that they can be
shared amongst multiple card-level drivers.
> 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.
I'm not so against either of these options, but let's save it for a separate
change later on. This is the sort of thing that would need an RFC on the
linux-dvb list before moving forward. For now, let's move on with dvb-pll
statically linked in.
> 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.
I'm against this option. (see above)
> * 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.
Cheers,
Mike
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
