Hi,

On Tue, Nov 22, 2011 at 3:58 AM, Antti Palosaari <cr...@iki.fi> wrote:
> Hello
>
> On 11/21/2011 11:09 PM, Manu Abraham wrote:
>>
>>        /* program tuner */
>> -       if (fe->ops.tuner_ops.set_params)
>> -               fe->ops.tuner_ops.set_params(fe, params);
>> +       tstate.delsys = SYS_DVBC_ANNEX_AC;
>> +       tstate.frequency = c->frequency;
>> +
>> +       if (fe->ops.tuner_ops.set_state) {
>> +               fe->ops.tuner_ops.set_state(fe,
>> +                                           DVBFE_TUNER_DELSYS    |
>> +                                           DVBFE_TUNER_FREQUENCY,
>> +                                       &tstate);
>
> I want to raise that point, switch from .set_params() to .set_state() when
> programming tuner. I don't see it reasonable to introduce (yes, it have
> existed ages but not used) new way to program tuner.


I didn't introduce set_state() now. It was there for quite a long
while, as old v5API itself, IIRC.


>
> Both demod and tuner got same params;
> .set_frontend(struct dvb_frontend *, struct dvb_frontend_parameters *)
> .set_params(struct dvb_frontend *, struct dvb_frontend_parameters *)


The argument passed to set_params: struct dvb_frontend_parameters is
useless for any device that's been around recently. Although one can
get the parameters from the property_cache.

Using set_state(), makes it independant and less kludgy, simplifying
things. on the other hand it may be used with analog as well, llly to
Michael Krufky said.

Eventually, it just provides the tuner an independence from struct
dvb_frontend_parameters (which is rigid) and the frontend cache.

That said, a few tuners already uses the mentioned callback, stb6100,
tda8261, tda665x,

If you imply that you feel overly depressed by the use of the
set_state in the cxd2820r module ;-), then as a workaround, the
parameters required for operation can be retrieved from the property
cache, but then if tuner drivers are cleaned up by someone to remove
obsolete ? set_params, then you wouldn't have any other option, but to
later on fall back to set_state.

I am fine with either way, but for the tuners themselves, set_state
behaves a bit more better as it provides independence from the legacy
dvb_frontend_properties. It takes a bit of time for someone new to
understand that (he cannot use dvb_frontend_properties anymore)


>
> and can get access to APIv5 property_cache similarly. Both, demod and tuner,
> can read all those params that are now passed using .set_state()


If you want to pass other parameters, as what exists already in
tuner_state, that is not possible with set_params. If you can't have
the required parameters through a parameters which is passed, but then
why would you want to have such a parameter itself passed in the first
case ?

>
> There is some new tuner drivers which are already using APIv5.
>
>
> regards
> Antti


Eventually it is all a matter of taste. I am fine with either. ;-)

Regards,
Manu
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to