On 09/06/2014 07:08 AM, Akihiro TSUKADA wrote:
Moikka!,
thanks for the comments and advices.
I had been updating my code and during that, I also found that
updating property cache in tuner_ops.get_signal_strength() was
simple and (seemed to me) better than using a kthread,
so the current implementation (under testing) is just like
what Mauro proposed, but,
In time: not implementing its own thread has one drawback: the driver needs
to check if the minimal time needed to get a new stats were already archived.
since I don't know the minimal time and
whether there's a limit in the first place,
I'd like to let users take the responsibility.
You could add some simple jiffie (some kind of kernel global time) which
limits calls to some reasonable level.
if (jiffies > jiffies_previous + 1 sec)
return 0;
else
jiffies_previous = jiffies;
... continue
... 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 drivr as well demod driver. Let the tuner driver make RSSI
calculation independently without any unneeded relation to demod driver.
I think the main reason for the hook is because the dvb-core calls
ops.get_frontend() everytime before reading of any property cache,
so it is already a nice place to trigger property updates,
and reading any property involves demod (FE as a whole) anyway.
That must be changed 'resently'. IIRC originally get_frontend() was
called by dvb-core only once, just after demod lock was gained. Also
userspace could call it using some IOCTL (GET_FRONTEND?).
But if it is not called periodically by dvb-core, you could not use it
for bit error measurements, as you will usually need to start
measurement, then wait complete, read values and return.
Signal strength and SNR are typically provided by chip without any waiting.
regards
Antti
--
http://palosaari.fi/
--
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
