* DVBv5 qos/stats driver implementation
@ 2015-05-05 14:26 Jemma Denson
2015-05-05 15:27 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 2+ messages in thread
From: Jemma Denson @ 2015-05-05 14:26 UTC (permalink / raw)
To: linux-media
Cc: mchehab, crope@iki.fi >> Antti Palosaari,
patrick.boettcher@posteo.de >> Patrick Boettcher
Mauro/Antti,
Myself and Patrick are currently in the process of bringing an old out
of tree frontend driver into shape for inclusion, and one of the issues
raised by Mauro was the requirement for the new DVBv5 stats method. I've
noticed there seems to be two different ways of going around this - one
is to run through the collection and cache filling process during the
calls to read_status (as in dib7000p/dib8000p), and the other is to poll
independently every couple of seconds via schedule_delayed_work (as in
af9033, rtl2830/2832).
Is there any reason for the two different ways - is it just a coding
preference or is there some specifics to how these frontends need to be
implemented?
Thanks,
Jemma.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: DVBv5 qos/stats driver implementation
2015-05-05 14:26 DVBv5 qos/stats driver implementation Jemma Denson
@ 2015-05-05 15:27 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 2+ messages in thread
From: Mauro Carvalho Chehab @ 2015-05-05 15:27 UTC (permalink / raw)
To: Jemma Denson; +Cc: linux-media, Antti Palosaari, Patrick Boettcher
Em Tue, 05 May 2015 15:26:07 +0100
Jemma Denson <jdenson@gmail.com> escreveu:
> Mauro/Antti,
>
> Myself and Patrick are currently in the process of bringing an old out
> of tree frontend driver into shape for inclusion, and one of the issues
> raised by Mauro was the requirement for the new DVBv5 stats method. I've
> noticed there seems to be two different ways of going around this - one
> is to run through the collection and cache filling process during the
> calls to read_status (as in dib7000p/dib8000p), and the other is to poll
> independently every couple of seconds via schedule_delayed_work (as in
> af9033, rtl2830/2832).
>
> Is there any reason for the two different ways - is it just a coding
> preference or is there some specifics to how these frontends need to be
> implemented?
Hi Jemma,
It is basically coding preference.
The DVB has already a thread that calls the frontend driver on every
3 seconds, at most (or when an event occurs). So, I don't see any need
for the drivers to start another thread to update status, as 3 seconds
is generally good enough for status update, then the frontend is
already locked, and the events can make status to update earlier during
device lock phase. Also, if needed, it won't be hard to add core support
to adjust the kthread delay time.
The driver may also skip an update if needed. So, I don't see much
gain on having a per-driver thread.
Having a per-driver thread should work too, although it is an overkill
for me to have two status kthreads running (one provided by the core,
and another by the driver).
Regards,
Mauro
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2015-05-05 15:27 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-05 14:26 DVBv5 qos/stats driver implementation Jemma Denson
2015-05-05 15:27 ` Mauro Carvalho Chehab
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).