[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241119-prudent-jasmine-lizard-195cef@houat>
Date: Tue, 19 Nov 2024 15:43:29 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Paul Kocialkowski <paulk@...-base.io>
Cc: linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
linux-kernel@...r.kernel.org, Uwe Kleine-König <ukleinek@...nel.org>,
Chen-Yu Tsai <wens@...e.org>, Jernej Skrabec <jernej.skrabec@...il.com>,
Samuel Holland <samuel@...lland.org>, Linus Walleij <linus.walleij@...aro.org>,
Paul Kocialkowski <contact@...lk.fr>
Subject: Re: [PATCH] pinctrl: sunxi: Use minimal debouncing period as default
On Tue, Nov 19, 2024 at 03:08:05PM +0100, Paul Kocialkowski wrote:
> From: Paul Kocialkowski <contact@...lk.fr>
>
> The sunxi external interrupts (available from GPIO pins) come with a
> built-in debouncing mechanism that cannot be disabled. It can be
> configured to use either the low-frequency oscillator (32 KHz) or the
> high-frequency oscillator (24 MHz), with a pre-scaler.
>
> The pinctrl code supports an input-debounce device-tree property to set
> a specific debouncing period and choose which clock source is most
> relevant. However the property is specified in microseconds, which is
> longer than the minimal period achievable from the high-frequency
> oscillator without a pre-scaler.
That can be fixed by introducing a new property with a ns resolution.
> When the property is missing, the reset configuration is kept, which
> selects the low-frequency oscillator without pre-scaling. This severely
> limits the possible interrupt periods that can be detected.
>
> Instead of keeping this default, use the minimal debouncing period from
> the high-frequency oscillator without a pre-scaler to allow the largest
> possible range of interrupt periods.
>
> This issue was encountered with a peripheral that generates active-low
> interrupts for 1 us. No interrupt was detected with the default setup,
> while it is now correctly detected with this change.
I don't think it's wise. If the debouncing is kept as is, the worst case
scenario is the one you had: a device doesn't work, you change it,
everything works.
If we set it up as fast as it can however, then our risk becomes
thousands of spurious interrupts, which is much more detrimental to the
system.
And that's without accounting the fact that devices might have relied on
that default for years
Maxime
Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)
Powered by blists - more mailing lists