Em Sat, 06 Sep 2014 06:34:33 +0300 Antti Palosaari <cr...@iki.fi> escreveu:
> On 09/06/2014 06:17 AM, Mauro Carvalho Chehab wrote: > > Em Sat, 06 Sep 2014 06:10:01 +0300 > > Antti Palosaari <cr...@iki.fi> escreveu: > > >> ... I simply don't understand why you want hook that RF strength call > >> via demod? The frontend cache is shared between demod and tuner. We use > >> it for tuner driver as well demod driver. Let the tuner driver make RSSI > >> calculation independently without any unneeded relation to demod driver. > > > > Well, adding kthreads has a cost, with is a way higher than just > > calling a callback function. > > > > Also, it makes a way more complicated to implement several tasks. > > > > For example, devices with kthreads need to stop them during suspend, > > and restart them at resume time, or otherwise suspend and/or resume > > may not work. > > > > Also, the power consumption increases with kthread, as the CPU need > > to be periodically waken. > > > > I'm not saying we shouldn't use kthreads at driver level, but > > the best is to avoid when there are some other simpler ways of doing it. > > And small reality check, how much you think one kthreads, that polls > once per 2 second or so causes, in a case when you are *already > streaming* 20-80 Mbit/sec data stream :) I think CPU does not need wake > up to execute one thread as there is a lot of other interrupts happening > in that use case anyway. You can't assume that all streams received by a tuner uses 20-80Mbps. It could be a sound broadcasting stream, for example, with uses a much lower bandwidth. > We have a remote controller which is polled often as 100ms and it > happens even when device is "sleeping". And lots of drivers have a modprobe parameter to disable it, because it causes too much power consumption. Regards, Mauro -- 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
