Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Subject: Re: [PATCH v5 2/2] media: rc: remove ir-rx51 in favour of generic
 pwm-ir-tx
To:     Sean Young <sean@mess.org>, linux-media@vger.kernel.org,
        Tony Lindgren <tony@atomide.com>,
        Russell King <linux@armlinux.org.uk>,
        Mauro Carvalho Chehab <mchehab@kernel.org>,
        Thierry Reding <thierry.reding@gmail.com>,
        =?UTF-8?Q?Uwe_Kleine-K=c3=b6nig?= <u.kleine-koenig@pengutronix.de>
Cc:     Timo Kokkonen <timo.t.kokkonen@iki.fi>,
        =?UTF-8?Q?Pali_Roh=c3=a1r?= <pali.rohar@gmail.com>,
        "Sicelo A . Mhlongo" <absicsz@gmail.com>,
        linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org
References: <cover.1693577725.git.sean@mess.org>
 <e5325e826935f0bd8566152b6a5fa799b2429d43.1693577725.git.sean@mess.org>
From:   Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Message-ID: <99f0042f-538c-bcaf-96fd-bac24a87f88e@gmail.com>
Date:   Mon, 25 Sep 2023 19:06:44 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Firefox/60.0 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <e5325e826935f0bd8566152b6a5fa799b2429d43.1693577725.git.sean@mess.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Precedence: bulk


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