[PATCH 1/2] Documentation: sample averaging for imx6ul_tsc

On 01/12/2016 18:13, Rob Herring wrote:

On Sun, Nov 27, 2016 at 09:44:57AM +0200, Guy Shapiro wrote:

quoted

The i.MX6UL internal touchscreen controller contains an option to
average upon samples. This feature reduces noise from the produced
touch locations.

This patch introduces a new device tree optional property for this
feature. It provides control over the amount of averaged samples per
touch event.

The property was inspired by a similar property on the
"brcm,iproc-touchscreen" binding.

Signed-off-by: Guy Shapiro <redacted>
---
  .../devicetree/bindings/input/touchscreen/imx6ul_tsc.txt          | 8

++++++++

quoted

  1 file changed, 8 insertions(+)

diff --git

a/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
b/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt

quoted

index 853dff9..a66069f 100644

--- a/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt

@@ -17,6 +17,13 @@ Optional properties:
    This value depends on the touch screen.
  - pre-charge-time: the touch screen need some time to precharge.
    This value depends on the touch screen.
+- average-samples: Number of data samples which are averaged for each

read.

quoted

+	Valid values 0-4
+	0 =  1 sample
+	1 =  4 samples
+	2 =  8 samples
+	3 = 16 samples
+	4 = 32 samples

Either this needs a vendor prefix or should be documented as a generic
property. In the latter case, you should use actual number of samples
(1-32) for the values.

In the term "generic property", do you mean to document it on 
bindings/input/touchscreen/touchscreen.txt ?
If so, should I add the "touchscreen-" prefix like all the other 
properties in that file?

Grepping bindings/input/touchscreen/, I found two other device drivers 
that implement a
similar property - "ti-tsc-adc" and "brcm,iproc-touchscreen" (The 
latter, BTW, uses a non
vendor prefixed property name).

Do we want to move from per-vendor properties to a generic one?
If we do, should we deprecate the existing vendor specific properties?