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

On Fri, Sep 19, 2025 at 05:12:42PM +0200, Dario Binacchi wrote:

On Fri, Sep 19, 2025 at 4:38 PM Rob Herring [off-list ref] wrote:

quoted

On Thu, Sep 18, 2025 at 10:37:37PM +0200, Dario Binacchi wrote:

quoted

On Thu, Sep 18, 2025 at 10:04 PM Rob Herring [off-list ref] wrote:

quoted

On Thu, Sep 18, 2025 at 05:52:31PM +0200, Dario Binacchi wrote:

quoted

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