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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <99f0042f-538c-bcaf-96fd-bac24a87f88e@gmail.com>
Date:   Mon, 25 Sep 2023 19:06:44 +0300
From:   Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>
To:     Sean Young <sean@...s.org>, linux-media@...r.kernel.org,
        Tony Lindgren <tony@...mide.com>,
        Russell King <linux@...linux.org.uk>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
Cc:     Timo Kokkonen <timo.t.kokkonen@....fi>,
        Pali Rohár <pali.rohar@...il.com>,
        "Sicelo A . Mhlongo" <absicsz@...il.com>,
        linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linux-pwm@...r.kernel.org
Subject: Re: [PATCH v5 2/2] media: rc: remove ir-rx51 in favour of generic
 pwm-ir-tx

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...

In either case help is appreciated to dig further trying to find the 
reason for such a big delay.

Regards,
Ivo