On Friday 15 July 2005 05:17 pm, Patrick Boettcher wrote:
> On Fri, 15 Jul 2005, Mac Michaels wrote:
> > Michael,
> >
> > Like I said, I don't really like my proposed solution.
> >
> > Obviously it would be implemented so that it only
> > switches input connectors for the DViCO FusionHDTV 3
> > Gold-Q board. It would have no affect on any other
> > board used by the lgdt3302 driver.
> >
> > I am fishing for other solutions.
>
> This is what came into my mind: (very schematic)
>
> in the lgdt3302-driver there will be a
>
> int lgdt3302_set_rf_input(*fe, index)
> {
> /* set the correct rf_input-path */
> }
> EXPORT_SYMBOL(lgdt3302_set_rf_input);
>
> add a pll_set-callback to the dt3302_config. This
> callback is called in set_frontend.
>
> if (state->config->pll_set)
> state->config->pll_set(fe,fep);
>
> in cx88-dvb.c you set the pll_set-callback for the Gold-Q
> card to a function which could look like this:
>
> int cx88_gold_q_pll_set(*fe,frontend_parameters)
> {
> /* do the stuff, eg. set pll1 for 8VSB and/or pll2 for
> QAM or so */
>
> lgdt3302_set_rf_input(fe,appropriate_rf_input);
> }
Thank you Patrick, your suggestion makes sense. How does the
application learn about the multiple RF input capability?
Is an additional FE_CAN_SEL_RF needed? Would this be added
to the documention for the DVB API somewhere.
> Along with this, you could also remove the dvb_pll_desc
> from the frontend to use a (common) pll_set-callback.
> IMHO tuner-progamming should not be in the frontend.
I agree, this is separate clean up. I will look into it.
-- Mac
