On 26.09.23 г. 10:37 ч., Tony Lindgren wrote:
* Sean Young <sean@xxxxxxxx> [230926 07:16]:
On Mon, Sep 25, 2023 at 07:06:44PM +0300, Ivaylo Dimitrov wrote:
On 1.09.23 г. 17:18 ч., Sean Young wrote:
The ir-rx51 is a pwm-based TX driver specific to the N900. This can be
handled entirely by the generic pwm-ir-tx driver, and in fact the
pwm-ir-tx driver has been compatible with ir-rx51 from the start.
Unfortunately, pwm-ir-tx does not work on n900. My investigation shows that
for some reason usleep_range() sleeps for at least 300-400 us more than what
interval it is requested to sleep. I played with cyclictest from rt-tests
package and it gives similar results - increasing the priority helps, but I
was not able to make it sleep for less that 300 us in average. I tried
cpu_latency_qos_add_request() in pwm-ir-tx, but it made no difference.
I get similar results on motorola droid4 (OMAP4), albeit there average sleep
is in 200-300 us range, which makes me believe that either OMAPs have issues
with hrtimers or the config we use has some issue which leads to scheduler
latency. Or, something else...
The pwm-ir-tx driver does suffer from this problem, but I was under the
impression that the ir-rx51 has the same problem.
In either case help is appreciated to dig further trying to find the reason
for such a big delay.
pwm-ir-tx uses usleep_range() and ir-rx51 uses hrtimers. I thought that
usleep_range() uses hrtimers; however if you're not seeing the same delay
on ir-rx51 then maybe it's time to switch pwm-ir-tx to hrtimers.
Maybe using fsleep() fixes this issue? See commit c6af13d33475 ("timer: add
fsleep for flexible sleeping"), and Documentation/timers/timers-howto.rst.
I doubt, time intervals we are talking about are > 500 us, which means
fsleep will always use usleep_range() (or even worse, msleep()), see
https://elixir.bootlin.com/linux/v6.6-rc3/source/include/linux/delay.h#L82
The long wake-up time for an idle state could explain the values. I think
Ivaylo already tested with most cpuidle states disabled via sysfs though.
Yes, I disabled all idle states on both n900 and droid4 (when doing
cyclictest experiments), with no difference. I also locked frequency on
n900 to 500MHz, which improved the things a bit, by some 20-50 us
(IIRC), which makes sense, but also makes me think frequency scaling is
not the one to blame either.
I don't have a n900 to test on, unfortunately.
If you want one for development, the maemo folks cc:ed here likely have
some available devices.
I think we can arrange one, yes, but my gut feeling tells me the issue
is not n900 specific, it is just a bit worse there as the device is
relatively slow already. I have no sane explanation why one would see
similar latencies on droid4, given that it is times faster than n900.
Regards,
Ivo
Regards,
Tony
