Em Sat, 06 Sep 2014 22:37:21 +0100 Malcolm Priestley <tvboxspy@xxxxxxxxx> 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@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. 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. Regards, Mauro -- 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
