[PATCH v5 2/2] media: rc: remove ir-rx51 in favour of generic pwm-ir-tx

[Ivaylo Dimitrov]

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
>