Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp358988pxk; Wed, 2 Sep 2020 03:28:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx0o0b1EJQGNzFmpjd8jAJUNfguM6Hy1JQ+z2qg9RcLM8xuAiknpBEvcGIAwOydPQuqW9eD X-Received: by 2002:a17:906:178d:: with SMTP id t13mr5903390eje.410.1599042505630; Wed, 02 Sep 2020 03:28:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599042505; cv=none; d=google.com; s=arc-20160816; b=TlfNCeEUVPuw4EEMBNMLdqpR/4j1FCZPZwH1BnrbGKdYbXRehz0l08EeCkTjQd1dyD aZgOgpcMaPFh5oiGgol3KUYeev4vCI2Hk5IBTU6OCqDqdRHvjkgV6TINNcY0f2fg7awp n+AmucMIZ2q8yKnEiTrC8byRcZJgTj5JARAgqMRfGxSYHU3ALCCVlS9hMoIhg2BpNRhv Ut1OHLBgOAV1U3K+KLHa+/RBDSHPkDp6ZjDGqTQX4amt+8SOvNCUOFHmbwFAiMN39hq1 78QbJG/QfMXFmaM1PIIOTmmZo6cZFOLHTe9EFnvtyi2PbrAN6SBnIxiQVg/35sPJQCyb bM3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=aMFSwCl6QWGcuy+SACJpyJmDyJsD9U1EIJxyzvlRpM8=; b=VEuGnM6fwr09NrILt5NPNtjPh9tqUZ/wBSUDFpEML3F4RTSddch5SqKtL9p+nvVAMb 7h8jCosH2HuunKlT5Ri6vwTOVvpZBU/pIkuTT5x9U+gd0M8+3GH0XnFELM5ZrKzDHeb0 944mHmCDbV/yllJtaTycXGotI2TnUcZhdcPoVtFgxM0OUYRMOX6VtMdV6b2MSrCSDFpB abbxwfUA4YlFPb39CPMc4gI+UvWO7VmBM8z+imH82p0OZf2KIazp69vuJwFJHI9maUu3 1deuTv1DrN3c+YFsnT08EDC0TG2DO1x/sucUt5MJNI6B9cHp8WpeJoX4yMxPnVUUi0LT uPOg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z25si2284590eje.701.2020.09.02.03.28.02; Wed, 02 Sep 2020 03:28:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726426AbgIBKZZ (ORCPT + 99 others); Wed, 2 Sep 2020 06:25:25 -0400 Received: from jabberwock.ucw.cz ([46.255.230.98]:47058 "EHLO jabberwock.ucw.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726247AbgIBKZZ (ORCPT ); Wed, 2 Sep 2020 06:25:25 -0400 Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 4090B1C0B7F; Wed, 2 Sep 2020 12:25:23 +0200 (CEST) Date: Wed, 2 Sep 2020 12:25:21 +0200 From: Pavel Machek To: Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Sean Young , Mauro Carvalho Chehab , Sasha Levin Subject: Re: [PATCH 4.19 053/125] media: gpio-ir-tx: improve precision of transmitted signal due to scheduling Message-ID: <20200902102521.GC3765@duo.ucw.cz> References: <20200901150934.576210879@linuxfoundation.org> <20200901150937.150292200@linuxfoundation.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="t0UkRYy7tHLRMCai" Content-Disposition: inline In-Reply-To: <20200901150937.150292200@linuxfoundation.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --t0UkRYy7tHLRMCai Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! >=20 > [ Upstream commit ea8912b788f8144e7d32ee61e5ccba45424bef83 ] >=20 > usleep_range() may take longer than the max argument due to scheduling, > especially under load. This is causing random errors in the transmitted > IR. Remove the usleep_range() in favour of busy-looping with udelay(). >=20 > Signed-off-by: Sean Young I don't believe this should be in stable. Yes, it probably fixes someone's remote control. It also introduces > half a second (!) with interrupts disabled (according to the code comments), which will break other devices on the system. Less intrusive solutions should be explored, first. Like.. if that part is time-critical, perhaps it should set itself at realtime priority, so that scheduler has motivation to schedule it at the right times? Perhaps usleep_range should be delta, delta+1? Perhaps udelay makes sense to use for more than 10usec? Best regards, Pavel > @@ -87,13 +87,8 @@ static int gpio_ir_tx(struct rc_dev *dev, unsigned int= *txbuf, > // space > edge =3D ktime_add_us(edge, txbuf[i]); > delta =3D ktime_us_delta(edge, ktime_get()); > - if (delta > 10) { > - spin_unlock_irqrestore(&gpio_ir->lock, flags); > - usleep_range(delta, delta + 10); > - spin_lock_irqsave(&gpio_ir->lock, flags); > - } else if (delta > 0) { > + if (delta > 0) > udelay(delta); > - } > } else { > // pulse > ktime_t last =3D ktime_add_us(edge, txbuf[i]); > --=20 > 2.25.1 >=20 >=20 --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --t0UkRYy7tHLRMCai Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCX09zEQAKCRAw5/Bqldv6 8gtmAJ4whLb6KgxDaQ4G9FMHnFplfwvEUwCgo8yL6i1TXMs6lZakoDrMzLqk9mI= =/W/6 -----END PGP SIGNATURE----- --t0UkRYy7tHLRMCai--