* Sean Young <[email protected]> [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.
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.
> 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.
Regards,
Tony
On 26.09.23 г. 10:37 ч., Tony Lindgren wrote:
> * Sean Young <[email protected]> [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
>