On 11/05/16 07:01, Linus Walleij wrote: > On Tue, May 10, 2016 at 6:40 PM, Crestez Dan Leonard > <leonard.crestez@xxxxxxxxx> wrote: >> [Me] >>> ChangeLog v5->v6: >>> - Add a loop counter to the threaded value poll function: let's >>> just loop here for at maximum 10 loops before we exit and >>> let the thread re-trigger if more interrupts arrived. >> >> This only serves to hide the problem. > > Not really. The system can preempt after exiting the thread but > before processing the next set of samples. > >> Version 5 seems preferable. Or >> even just adding msleep(10) in that infinite loop. > > That provides a preemption point I guess but usleep_range() > is usually preferrable for such cases. 10ms is way to long > time to wait, because the max sample frequency will be > 1/10ms = 100Hz and some ST sensors I have support > 1kHz updates even. The usleep range would need to be > very short. These devices are getting slower in their old age - the venerable lis3l02dq supports 4.48 kHz. See the thread in response to Leonard's patch. I 'fear' we may need a combination of the two approaches. Perhaps one of the ST guys can confirm these devices really are doing level interrupts in all cases as it gets even more complex if only some devices are... > > Yours, > Linus Walleij > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
