Re: [PATCH v2 1/5] dvb-core: add a new tuner ops to dvb_frontend for APIv5

[Antti Palosaari <crope@iki.fi>]

On 09/07/2014 01:37 AM, Mauro Carvalho Chehab wrote:
> Em Sat, 06 Sep 2014 22:37:21 +0100
> Malcolm Priestley <tvboxspy@gmail.com> escreveu:
>
>> On 06/09/14 17:24, Malcolm Priestley wrote:
>>> On 06/09/14 03:51, Mauro Carvalho Chehab wrote:
>>>> Em Sat, 06 Sep 2014 05:09:55 +0300
>>>> Antti Palosaari <crope@iki.fi> escreveu:
>>>>
>>>>> Moro!
>>>>>
>>>>> On 08/29/2014 01:45 PM, Akihiro TSUKADA wrote:
>>>>>> moikka,
>>>>>>
>>>>>>> Start polling thread, which polls once per 2 sec or so, which reads
>>>>>>> RSSI
>>>>>>> and writes value to struct dtv_frontend_properties. That it is, in my
>>>>>>> understanding. Same for all those DVBv5 stats. Mauro knows better
>>>>>>> as he
>>>>>>> designed that functionality.
>>>>>>
>>>>>> I understand that RSSI property should be set directly in the tuner
>>>>>> driver,
>>>>>> but I'm afraid that creating a kthread just for updating RSSI would be
>>>>>> overkill and complicate matters.
>>>>>>
>>>>>> Would you give me an advice? >> Mauro
>>>>>
>>>>> Now I know that as I implement it. I added kthread and it works
>>>>> correctly, just I though it is aimed to work. In my case signal strength
>>>>> is reported by demod, not tuner, because there is some logic in firmware
>>>>> to calculate it.
>>>>>
>>>>> Here is patches you would like to look as a example:
>>>>>
>>>>> af9033: implement DVBv5 statistic for signal strength
>>>>> https://patchwork.linuxtv.org/patch/25748/
>>>>
>>>> Actually, you don't need to add a separate kthread to collect the stats.
>>>> The DVB frontend core already has a thread that calls the frontend status
>>>> on every 3 seconds (the time can actually be different, depending on
>>>> the value for fepriv->delay. So, if the device doesn't have any issues
>>>> on getting stats on this period, it could just hook the DVBv5 stats logic
>>>> at ops.read_status().
>>>>
>>>
>>> Hmm, fepriv->delay missed that one, 3 seconds is far too long for lmedm04.
>>
>> The only way change this is by using algo DVBFE_ALGO_HW using the
>> frontend ops tune.
>>
>> As most frontends are using dvb_frontend_swzigzag it could be
>> implemented by patching the frontend ops tune code at the lock
>> return in this function or in dvb_frontend_swzigzag_update_delay.
>
> Well, if a different value is needed, it shouldn't be hard to add a
> way to customize it, letting the demod to specify it, in the same way
> as fe->ops.info.frequency_stepsize (and other similar demot properties)
> are passed through the core.

DVBFE_ALGO_SW, which is used normally, polls read_status rather rapidly. 
For statics problem is that it is too rapid, not that it is too slow. If 
you want re-use that as a timer for statistics, you could simply make 
own ratelimit very easily using kernel jiffies.

Not going to implement details, but here is skeleton, which is almost as 
many lines of code as actual implementation:

if (jiffies < jiffies_prev + 2 sec)
   return 0; // limit on
else
   jiffies_prev = jiffies;

... statistics polling code here.

regards
Antti

-- 
http://palosaari.fi/