Re: [PATCH v5 3/6] dt-bindings: touchscreen: add touchscreen-glitch-threshold-ns property

[Rob Herring <robh@kernel.org>]

On Fri, Sep 19, 2025 at 05:12:42PM +0200, Dario Binacchi wrote:
> On Fri, Sep 19, 2025 at 4:38 PM Rob Herring <robh@kernel.org> wrote:
> >
> > On Thu, Sep 18, 2025 at 10:37:37PM +0200, Dario Binacchi wrote:
> > > On Thu, Sep 18, 2025 at 10:04 PM Rob Herring <robh@kernel.org> wrote:
> > > >
> > > > On Thu, Sep 18, 2025 at 05:52:31PM +0200, Dario Binacchi wrote:
> > > > > Add support for glitch threshold configuration. A detected signal is valid
> > > > > only if it lasts longer than the set threshold; otherwise, it is regarded
> > > > > as a glitch.
> > > > >
> > > > > Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> > > > > Acked-by: Conor Dooley <conor.dooley@microchip.com>
> > > > >
> > > > > ---
> > > > >
> > > > > Changes in v5:
> > > > > - Add Acked-by tag of Conor Dooley
> > > > >
> > > > > Changes in v2:
> > > > > - Added in v2.
> > > > >
> > > > >  .../devicetree/bindings/input/touchscreen/touchscreen.yaml    | 4 ++++
> > > > >  1 file changed, 4 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
> > > > > index 3e3572aa483a..a60b4d08620d 100644
> > > > > --- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
> > > > > +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
> > > > > @@ -206,6 +206,10 @@ properties:
> > > > >
> > > > >          unevaluatedProperties: false
> > > > >
> > > > > +  touchscreen-glitch-threshold-ns:
> > > > > +    description: Minimum duration in nanoseconds a signal must remain stable
> > > > > +      to be considered valid.
> > > >
> > > > What's wrong with debounce-delay-ms?
> > >
> > > Do you mean that I should rename touchscreen-glitch-threshold-ns to
> > > debounce-delay-ms?
> >
> > I mean that's the common property we already have, so use it or explain
> > why you aren't using it. I suppose the definition is technically a bit
> > different if it's purely a s/w delay vs. h/w monitoring of the signal
> > state. I don't think it matters if the interpretation by each driver is
> > a bit different.
> >
> > Maybe msec is not enough resolution for you could be another reason?
> 
> Yes, this is the main reason. As specified in the following patch:
>   v5 4/6 dt-bindings: touchscreen: fsl,imx6ul-tsc: support glitch threshold
> 
> Drivers must convert this value to IPG clock cycles and map
> it to one of the four discrete thresholds exposed by the
> TSC_DEBUG_MODE2 register:
> 
>   0: 8191 IPG cycles
>   1: 4095 IPG cycles
>   2: 2047 IPG cycles
>   3: 1023 IPG cycles
> 
> In my case, the IPG clock runs at 66 MHz, which corresponds to:
> 
> 124 µs for 0
> 62 µs for 1
> 31 us for 2
> 15 us for 3
> 
> So using milliseconds would not fit my use case. A possible trade-off
> could be to use debounce-delay-us. Would that be acceptable?

I agree it wouldn't map to what the h/w provides, but is what the h/w 
provides actually useful? There's plenty of h/w designed that's not 
useful. 15us is quite short for a glitch. Do you have an actual cases 
where the different values above are needed?

Rob