From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 36926C2D0A3 for ; Mon, 9 Nov 2020 14:41:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E9FC320853 for ; Mon, 9 Nov 2020 14:41:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604932895; bh=yAypb4Z+4goyWfKuvwVWnsSV+ZMyJbAKwefaPjlJpIU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:List-ID:From; b=oyEr/2o3uMel8r3n89txtaW6VmhymNNVytnIMlmkYDXzhXT1Y6U56p2V/sDeRjrX9 jAZT4dhUqANnmPZF4fu4evbJRqgIV17qFgtOecc8V5Vl7HF3dMM7NdVfOOhWc53JJ+ NWCCLxhlqb4X/2ieJ8eR5A+Xzyaob7j8fLhYkgbw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731143AbgKIOle (ORCPT ); Mon, 9 Nov 2020 09:41:34 -0500 Received: from mail.kernel.org ([198.145.29.99]:55926 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726952AbgKIOld (ORCPT ); Mon, 9 Nov 2020 09:41:33 -0500 Received: from saruman (88-113-213-94.elisa-laajakaista.fi [88.113.213.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E7FEE20789; Mon, 9 Nov 2020 14:41:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604932892; bh=yAypb4Z+4goyWfKuvwVWnsSV+ZMyJbAKwefaPjlJpIU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=fuCpaK/GXwQcADBF293ZmU1fhjQnR9mQAqKGemh/yOLWxyYokGyxeYRc3r/nofDL6 CXScDlLVxe0eNh3QBA2inEmCMoafenPJEwLA+HaWDNWgapdp1/1i/OAiwdbhGxX/3w MD19d3/NtL3ufoVNaC9koH7LUSOBMK3sXVUuPEFI= From: Felipe Balbi To: Andy Shevchenko , Jamie McClymont , Hans de Goede , Dmitry Torokhov Cc: "open list:GPIO SUBSYSTEM" , linux-input , Benjamin Tissoires Subject: Re: How to handle a level-triggered interrupt that is slow to de-assert itself In-Reply-To: References: Date: Mon, 09 Nov 2020 16:41:24 +0200 Message-ID: <87tuty384r.fsf@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Andy Shevchenko writes: > On Mon, Nov 9, 2020 at 2:57 PM Jamie McClymont wrote: > > Looking into the problem I think the better people to answer are ones > from the input subsystem (or closer), so I have added a few to the Cc > list. > >> Background context: >> >> I'm continuing my efforts to reverse-engineer and write a driver for >> the Goodix GXFP5187 fingerprint sensor in my Huawei Matebook X Pro >> (the host is an Intel i5-8250U). >> >> The device is connected via SPI plus a GPIO Interrupt pin, defined >> like so in the ACPI tables: >> >> GpioInt (Level, ActiveLow, ExclusiveAndWake, PullUp, 0x0000, >> "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer, ,) { 0x0000 } >> >> This line is held down by the device when it has a message for the >> host, and stays held down until the host finishes reading the message >> out over SPI. >> >> I'm handling this with a devm_request_threaded_irq-type handler, >> where the irq part is just "return IRQ_WAKE_THREAD", and the threaded I think you should pass NULL as the top half and make sure you have IRQF_ONESHOT flag while requesting the interrupt. This way, the line will be disabled by IRQ subsystem for the duration of the bottom half. >> part does all the work. My understanding is that this is a reasonable >> approach since I don't have tight latency requirements (and the >> sleeping spi functions are convenient, plus I don't want to introduce >> any unnecessary jitter to the system) -- please correct me if I >> shouldn't actually be using a threaded handler here. >> >> --- >> >> Here's my problem: >> >> the IRQ line actually stays held down for roughly 180us after I've >> finished reading out the message over SPI. That means that as soon as >> the handler finishes, a new one starts, and it reads out corrupted >> data, since the sensor doesn't have anything to say. >> >> This is okay in theory -- the corrupted message header can be >> detected by its checksum, and disregarded. However, this leads to a >> race condition where the chip can decide it DOES have something to >> say to the host, WHILE the host is reading out the corrupted >> header. At that point, the two sides de-sync in their ideas of what >> needs to be read, and everything stops working. >> >> So, I'd like some way to pause interrupt handling for 200us+, and >> only re-run the handler if the line is still held down after that >> time. usleep_range(180, 200) before exitting the handler? You're in the bottom half anyway. >> My first approach was to add a sleep (usleep_range) at the end of the >> threaded handler, right before returning IRQ_HANDLED. However, it >> appears that after the sleep finishes, the IRQ is triggered one more >> time -- presumably it has been set as pending before/during the >> sleep? >> >> My new workaround is to save a ktime_get_ns timestamp at the end of >> the handler, and check it against the current ktime at the start, >> returning early if not enough time has yet elapsed. This is >> unsatisfactory, as it is effectively a 180us busy-wait, and gets in >> the way of whatever the core could better be doing (presumably idling >> and saving power :). >> >> Is it possible to return to the first approach, but prevent that one >> spurious interrupt from firing after the handler ends? IRQF_ONESHOT would probably help with this part, I guess. Could you give it a shot? =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJFBAEBCAAvFiEElLzh7wn96CXwjh2IzL64meEamQYFAl+pVRQRHGJhbGJpQGtl cm5lbC5vcmcACgkQzL64meEamQY+UQ//bLX8KcF3VEkMeNM7YV4X3jAWEY54hIyM nf719I8+D77AhzbEPhUYSNNKe80qimbvaSPG6caoIIMC7PRlrkwVrlDjtgoPpmmz 60fyTY6ynUCgeH7P/rpDQtgxmA6o/km/plc6TTlsPg9XlRTScIVssV9ZD5gvLSlH B0EfOvWuWO8ZCsHqRRY3nwBRT4z7V1K0iOjv3j3KyRwFdxovCECRnVGP+0P9tkL0 CJoEplQ2DWj2l28NmxbAqk5opnU72dYLr6+zdHmMVJygxFnwUdQsTbk8jcK3QRi5 DFClPusJC99/jDvPDX5vlPnGxBWNksPQnQa3xnTEpQeri9D8c87xG0hNQyQKKDIu i1odsnUOgKsjXgmT2PrUUFr7NqKYaF2Qm6NWJbStqMna/gG+BEqCYmqG6Bujj5UG kEWkeqmPQf0Sd83q1c8dAqGZE9WenMquqzfJwOtLNqCUQiUvl63rdhynyInOb1ov C18HkipaZJuTOTQTdFxESGvikDg9E+dAMS2ZFtNyTVVrhGcyrBm72F8E64gmjF1k 0sRHLcMDy0CybWwPCru7f4neecxiT901gEiT3l+iOsS+jz2WKsYsfbDKm3qQS0qj RpD+xQoCiriYeJwwpJS0HdNZPYsJgIHIxk9cusDGih1K6CgUt0FvfGBT/ii8Myqn vG6RIVtJA0g= =vKK3 -----END PGP SIGNATURE----- --=-=-=--