Em Sat, 06 Sep 2014 13:36:14 +0300 Antti Palosaari <crope@xxxxxx> escreveu: > 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. For RSSI measurements, in general there's no minimal time, but for measures like BER, PER, UCB, you'll need to wait for a while before the stats to be updated. So, you'll need to at least track those. > 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; Don't use jiffies like that. jiffies can be overflowed and the update will never occur. The right way is to use the macros time_after() and time_before(), or, alternatively, time_is_after_jiffies() and time_is_before_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?). No, get_frontend() is not automatically called by the dvb kthread after lock has gained. Just double-checked. > 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. Probably, the application you're using for tests are calling it periodically. What the core calls periodically for sure is read_status(). That's why most drivers that provide DVBv5 stats hook the cache update there. > Signal strength and SNR are typically provided by chip without any waiting. > > regards > Antti > -- 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
