Documentation: devicetree: iio: sensors
Erik Lilliebjerg [Thu, 4 Jun 2015 22:57:07 +0000 (15:57 -0700)]
Bug 1658829

Change-Id: I9cce8ae4ae09663dfa4b589237d2a8f0af63c9d6
Signed-off-by: Erik Lilliebjerg <elilliebjerg@nvidia.com>
Reviewed-on: http://git-master/r/760776
(cherry picked from commit e7f003e142278633fc258888df7f3dce6848a7f5)
Reviewed-on: http://git-master/r/764332
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Robert Collins <rcollins@nvidia.com>
Tested-by: Robert Collins <rcollins@nvidia.com>

Documentation/devicetree/bindings/iio/iqs253-ps.txt
Documentation/devicetree/bindings/iio/ltr659-ps.txt

index 54aa694..6a1717c 100644 (file)
@@ -3,14 +3,6 @@
 nvs_ drivers use the NVidia Sensor (NVS) framework.
 See the nvs.txt documentation for NVS DT capabilities.
 The nvs_iqs2x3 proximity sensor driver supports the IQS253 and IQS263 devices.
-These two parts are not register compatible and therefore should be specified
-in the device tree.  Example: iqs263@44.  By specifying a device this way, the
-driver will assume this specific device is populated during system boot and
-will not verify its existence.
-If, however, the device is unknown or may not be populated, then the label,
-iqs2x3, (e.g. iqs2x3@44), must be used.  This tells the driver to find which
-device is used.  If the device is not found, the driver will unload itself.
-This also requires that regulators be setup correctly for the probe function.
 
 Required properties:
 - compatible: Device or generic name.
@@ -119,53 +111,74 @@ The error can be due to truly out of buffer memory to non-existent register or
 incorrect register length.  Once the driver has loaded, a debug feature that
 will dump the parsed byte stream can be done by doing the following at the
 device's sysfs directory in an adb terminal prompt:
-$echo 10 > nvs
-$cat nvs
-The results will be something like:
-       IQS driver v. 6
-       os_options=0
-       stream_mode=0
-       watchdog_timeout_ms=30000
-       i2c_retry=10
-       gpio_rdy_retry=25
-       gpio_rdy 1=1
-       gpio_sar 173=1
-       irq=2
-       irq_disable=0
-       SAR_proximity_binary_hw=1
-       touch_proximity_binary_hw=1
-       IQS263 initialization:
+#echo 0xXXYYZZ1E > nvs
+where XX = part device ID (0x29=IQS253, 0x3C=IQS263)
+           If XX is 0, then the part in use will be used.
+      YY = command
+           Possible commands are:
+          1: initialization
+          2: enable
+          3: disable
+          4: event
+          If YY is 0, then all the commands will be displayed.
+      ZZ = device
+          Possible devices are:
+          1: SAR_proximiy
+          2: touch_proximity
+          If ZZ is 0, then all the devices will be displayed.
+Ideally, the 0x1E command would always be used.  However, if not all the data
+or corruption is displayed due to an undersized buffer (out of the driver's
+control) then the above formatting allows a smaller amount of data to be shown.
+#cat nvs
+The results for 0x1001E will be something like:
+       iqs263 initialization:
        len=5 reg=9 data/mask=40/ff 3/ff 0/ff 1/ff 3/ff
        len=1 reg=d data/mask=9/ff
        len=1 reg=1 data/mask=0/ff
        len=5 reg=7 data/mask=1b/ff 8/ff 8/ff 0/ff 11/ff
        len=8 reg=a data/mask=8/ff 10/ff 10/ff 2/ff 4/ff 8/ff 14/ff 3f/ff
        len=3 reg=b data/mask=0/ff 64/ff 80/ff
-       IQS263 proximity enable:
-       len=1 reg=9 data/mask=10/18
-       flush write and mdelay=0
-       len=1 reg=9 data/mask=8/18
-       IQS263 touch enable:
+The results for 0x2001E will be something like:
+       iqs263 SAR_proximity enable:
        len=1 reg=9 data/mask=10/18
        flush write and mdelay=0
        len=1 reg=9 data/mask=8/18
-       IQS253 initialization:
+       iqs263 touch_proximity enable:
+       <empty>
+
 Also, a register dump can be done:
-$echo 4 > nvs
-$cat nvs
+#echo 4 > nvs
+#cat nvs
 During the tuning process, a debug feature can write a byte to a register:
-$echo 0xXXYYZZ1D > nvs
+#echo 0xXXYYZZ1D > nvs
 where XX = the register
       YY = the register offset
       ZZ = the byte value
 Other driver debug commands:
-$echo 0x??1C > nvs
+#echo 0x??1C > nvs
 writes ?? to the gpio_sar GPIO.
-$echo 0x??1B > nvs
+#echo 0x??1B > nvs
 writes ?? to the gpio_rdy GPIO.
-$echo 0x1A > nvs
+#echo 0x1A > nvs
 switches the gpio_rdy GPIO to input.
 
+For overall information:
+#echo 10 > nvs
+#cat nvs
+The results will be something like:
+       IQS driver v. 8
+       os_options=0
+       stream_mode=0
+       watchdog_timeout_ms=30000
+       i2c_retry=10
+       gpio_rdy_retry=25
+       gpio_rdy 1=1
+       gpio_sar 173=1
+       irq=2
+       irq_disable=0
+       SAR_proximity_binary_hw=1
+       touch_proximity_binary_hw=1
+
 In the case the part populated could be either IQS253 or IQS263, both the 253
 and 263 commands can be defined in the DT.  The driver will use the one
 according to the part identified.
index 23ea415..10856cb 100644 (file)
@@ -4,14 +4,6 @@ nvs_ drivers use the NVidia Sensor (NVS) framework.
 See the nvs.txt documentation for NVS DT capabilities.
 The nvs_ltr659 ALS/proximity sensor driver supports the LTR558 and LTR659
 devices.
-If the part is known and is populated, then it can be specified in the DT:
-Example: ltr659@23.
-By specifying a device this way, the driver will assume this specific device
-is populated during system boot and will not verify its existence. If, however,
-the device is unknown or may not be populated, then the label, ltrX5X,
-(e.g. ltrX5X@23), must be used.  This tells the driver to find which device is
-used.  If the device is not found, the driver will unload itself.  This also
-requires that regulators be setup correctly for the probe function.
 
 Required properties:
 - compatible: Device or generic name.