All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Rob Herring <robh+dt@kernel.org>
Cc: Oleksij Rempel <o.rempel@pengutronix.de>,
	kernel@pengutronix.de, linux-kernel@vger.kernel.org,
	linux-input@vger.kernel.org, David Jander <david@protonic.nl>,
	Benjamin Gaignard <benjamin.gaignard@st.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Mark Brown <broonie@kernel.org>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	devicetree@vger.kernel.org
Subject: [PATCH v1] dt-bindings: touchscreen: add touchscreen-read-duration-us and touchscreen-settling-time-us properties
Date: Thu, 12 Nov 2020 12:20:48 +0100	[thread overview]
Message-ID: <20201112112048.12134-1-o.rempel@pengutronix.de> (raw)

According to the TI application bulletin [1] we deal with two generic
mechanisms which would affect the precision of provided input events:

|TOUCH SCREEN SETTLING TIME
|
|When the touch  panel is pressed or touched, there are
|two mechanisms that will affect the voltage level at the contact point of
|the touch panel. These two mechanisms will cause the voltage across the
|touch panel to “ring” (oscillate), and then slowly settle (decay)
|down to a stable DC value.
|
|The two mechanisms are:
| 1) Mechanical bouncing caused by vibration of the top layer sheet  of
|    the touch  panel  when  the  panel  is  pressed.
|
| 2) Electrical  ringing  due  to  parasitic  capacitance  between the top
|    and bottom layer sheets of the touch panel and at the  input  of  ADS7843
|    that  causes  the  voltage  to  “ring”(oscillate).

Since both of this mechanisms are board specific and reflect the
mechanical, and electrical properties of end product, it is better to
provide a generic properties to address them.

The touchscreen-read-duration-us property should address 1. mechanism.
This effect can be triggered by device specific design. The duration ma be
dependent on the use case of the end device. For example a touch where
writing is required may have other timing requirements as the device
where only "buttons" should be pressed.

The touchscreen-settling-time-us property should address 2. mechanism
where the size and construction of touch screen plates affect the parasitic
capacitance and time needed between enabling power supply for the
plates, and actual usable voltage level to detect the position of touch event.

[1] https://www.ti.com/lit/an/sbaa036/sbaa036.pdf

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
 .../bindings/input/touchscreen/touchscreen.yaml          | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
index a771a15f053f..8ba845f68d5c 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
@@ -55,6 +55,15 @@ properties:
       values dependent on the controller)
     $ref: /schemas/types.yaml#/definitions/uint32
 
+  touchscreen-read-duration-us:
+    description: Averaged time to sample each read to detect waves within
+      specified duration (valid values dependent on the controller)
+
+  touchscreen-settling-time-us:
+    description: Time it takes for the touchscreen ADC to produce valid samples
+      again after switching between axes (valid values dependent on the
+      controller)
+
   touchscreen-inverted-x:
     description: X axis is inverted
     type: boolean
-- 
2.28.0


             reply	other threads:[~2020-11-12 11:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-12 11:20 Oleksij Rempel [this message]
2020-11-21 12:56 ` [PATCH v1] dt-bindings: touchscreen: add touchscreen-read-duration-us and touchscreen-settling-time-us properties Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201112112048.12134-1-o.rempel@pengutronix.de \
    --to=o.rempel@pengutronix.de \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=benjamin.gaignard@st.com \
    --cc=broonie@kernel.org \
    --cc=david@protonic.nl \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=krzk@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.