Re: PATCH 12/13: 0012-CXD2820r-Query-DVB-frontend-delivery-capabilities

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 21, 2011 at 6:01 PM, Manu Abraham <abraham.manu@xxxxxxxxx> wrote:
> Hi,
>
> On Tue, Nov 22, 2011 at 3:58 AM, Antti Palosaari <crope@xxxxxx> 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


Antti is correct, this *can* be done by accessing the property cache,
and I would naturally agree with him that we should not add yet a 3rd
entry point for tuning.

However, this set_state is v4l/dvb agnostic.  if we go with this
set_state callback, we can in fact eliminate both set_params *and*
set_analog_params callbacks, finally having a single entry point for
setting the tuner.

If the community would prefer to use set_params, I am fine with
that... but I also like the idea of unifying the set_params and
set_analog_params into a single call.  If the community wants to see
*that*, then lets go ahead with set_state.  I think this is a good
step into that direction.

Agreeing with Manu, it is indeed a matter of taste and I am fine with
either way.  If we choose the set_state way, then future steps can
unify the calls into a single entry point -- that would be the best,
ultimately, in my opinion.

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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux