[PATCH] ARM: dts: allwinner: minimize irq debounce filter per default

[pelzi at flying-snail.de]

Am 13.02.23 um 09:43 schrieb Maxime Ripard:
> On Fri, Feb 10, 2023 at 10:18:14AM +0000, Andre Przywara wrote:
>>>> Not sure if you were actually arguing this, but the change I sketched
>>>> above (interpreting 0 as 24MHz/1) is separate though, as the current
>>>> default is "no DT property", and not 0. There is no input-debounce
>>>> property user in the kernel tree at the moment, so we wouldn't break
>>>> anyone. The only thing that would change is if a downstream user was
>>>> relying on "0" being interpreted as "skip the setup", which isn't
>>>> really documented and could be argued to be an implementation detail.
>>>>
>>>> So I'd suggest to implement 0 as "lowest possible", and documenting that
>>>> and the 32KHz/1 default if no property is given.
>>> Ah, my bad.
>>>
>>> There's another thing to consider: there's already a generic per-pin
>>> input-debounce property in pinctrl.
>>>
>>> Since we can't control it per pin but per bank, we moved it to the
>>> controller back then, but there's always been this (implicit)
>>> expectation that it was behaving the same way.
>>>
>>> And the generic, per-pin, input-debounce documentation says:
>>>
>>>> Takes the debounce time in usec as argument or 0 to disable debouncing
>>> I agree that silently ignoring it is not great, but interpreting 0 as
>>> the lowest possible is breaking that behaviour which, I believe, is a
>>> worse outcome.
>> Is it really? If I understand the hardware manuals correctly, we cannot
>> really turn that feature off, so isn't the lowest possible time period (24
>> MHz/1 at the moment) the closest we can get to "turn it off"? So
>> implementing this would bring us actually closer to the documented
>> behaviour? Or did I get the meaning of this time period wrong?
>> At least that's my understanding of how it fixed Andreas' problem: 1µs
>> is still not "off", but much better than the 31µs of the default. The new
>> 0 would then be 0.041µs.
> My point was that the property we share the name (and should share the
> semantics with) documents 0 as disabled. We would have a behavior that
> doesn't disable it. It's inconsistent.
>
> The reason doesn't really matter, we would share the same name but have
> a completely different behavior, this is super confusing to me.

I got the point. As far as I can tell from the datasheet, it is not possible
to actually switch off input-debounce. But as a debounce filter is actually
a low-pass filter, setting the cut-off frequency as high as possible,
appears to be the equivalent to switching it off.
To me it does not appear inconsistent, as any hardware will have an
implicit cut-off frequency given by its physical capabilites.

Cheers,

Andreas.