On 26.09.23 г. 10:16 ч., Sean Young wrote:
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.
Could you elaborate on the "pwm-ir-tx driver does suffer from this
problem"? Where do you see that?
ir-rx51 does not suffer from the same problem (albeit it has its own
one, see bellow)
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.
usleep_range() is backed by hrtimers already, however the difference
comes from how hrtimer is used in ir-rx51: it uses timer callback
function that gets called in softirq context, while usleep_range() puts
the task in TASK_UNINTERRUPTIBLE state and then calls
schedule_hrtimeout_range(). For some reason it takes at least 200-400 us
(on average) even on OMAP4 to switch back to TASK_RUNNING state.
The issue with ir-rx51 and the way it uses hrtimers is that it calls
pwm_apply_state() from hrtimer function, which is not ok, per the
comment here
https://elixir.bootlin.com/linux/v6.6-rc3/source/drivers/pwm/core.c#L502
I can make pwm-ir-tx switch to hrtimers, that's not an issue, but I am
afraid that there is some general scheduler or timers (or something
else) issue that manifests itself with usleep_range() misbehaving.
I don't have a n900 to test on, unfortunately.
I have and once I have an idea what's going on will port pwm-ir-tx to
hrtimers, if needed. Don't want to do it now as I am afraid the
completion I will have to use will have the same latency problems as
usleep_range()
Thanks,
Ivo
Thanks
Sean
