Hi,
On Fri, 15 Jul 2005, Mac Michaels wrote:
>> 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?
This is a good questions. To avoid the API extension it could be enough to
program the correct PLL against the modulation-type:
1) in the pll_set-callback for the Gold Q card:
if (modulation == QAM64 || modulation == QAM256) {
set_pll1_marked_with_cable();
lgdt3302_set_rf_input(fe,0);
} else {
set_pll2_marked_with_ant();
lgdt3302_set_rf_input(fe,1);
}
I'm not sure if that is obvious enough to the user. He/she would need to
stick to the labels of the connectors when connecting the source.
> Is an additional FE_CAN_SEL_RF needed? Would this be added
> to the documention for the DVB API somewhere.
2) That would be difficult to handle. You would need to extend all
DVB/ATSC applications adding an option to choose the RF-input.
3) I heard, that the V3 API does not support multiple frontends per
device, otherwise this would have been an option, too. (The frontend is
registered twice, one time for the ANT-Input-PLL and a second time for the
CABLE-Input-PLL)
I'm for 1). ;)
Patrick.
--
Mail: patrick.boettcher@xxxxxxx
WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/
