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@xxxxxx> 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.
Regards
Malcolm
--
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
