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]
Date:   Tue, 26 Sep 2023 10:37:44 +0300
From:   Tony Lindgren <tony@...mide.com>
To:     Sean Young <sean@...s.org>
Cc:     Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
        linux-media@...r.kernel.org, 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>,
        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

* Sean Young <sean@...s.org> [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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ