docs: misc-devices/apds990x.txt: convert to ReST format

- Adjust title markup;
- Adjust identation.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/444743782e5c8b8085d8016c8be3baabe4d23b53.1592203650.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

diff --git a/Documentation/misc-devices/apds990x.rst b/Documentation/misc-devices/apds990x.rst
new file mode 100644 (file)
index 0000000..e2f7557
--- /dev/null
+++ b/Documentation/misc-devices/apds990x.rst
@@ -0,0 +1,128 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================
+Kernel driver apds990x
+======================
+
+Supported chips:
+Avago APDS990X
+
+Data sheet:
+Not freely available
+
+Author:
+Samu Onkalo <samu.p.onkalo@nokia.com>
+
+Description
+-----------
+
+APDS990x is a combined ambient light and proximity sensor. ALS and proximity
+functionality are highly connected. ALS measurement path must be running
+while the proximity functionality is enabled.
+
+ALS produces raw measurement values for two channels: Clear channel
+(infrared + visible light) and IR only. However, threshold comparisons happen
+using clear channel only. Lux value and the threshold level on the HW
+might vary quite much depending the spectrum of the light source.
+
+Driver makes necessary conversions to both directions so that user handles
+only lux values. Lux value is calculated using information from the both
+channels. HW threshold level is calculated from the given lux value to match
+with current type of the lightning. Sometimes inaccuracy of the estimations
+lead to false interrupt, but that doesn't harm.
+
+ALS contains 4 different gain steps. Driver automatically
+selects suitable gain step. After each measurement, reliability of the results
+is estimated and new measurement is triggered if necessary.
+
+Platform data can provide tuned values to the conversion formulas if
+values are known. Otherwise plain sensor default values are used.
+
+Proximity side is little bit simpler. There is no need for complex conversions.
+It produces directly usable values.
+
+Driver controls chip operational state using pm_runtime framework.
+Voltage regulators are controlled based on chip operational state.
+
+SYSFS
+-----
+
+
+chip_id
+       RO - shows detected chip type and version
+
+power_state
+       RW - enable / disable chip. Uses counting logic
+
+            1 enables the chip
+            0 disables the chip
+lux0_input
+       RO - measured lux value
+
+            sysfs_notify called when threshold interrupt occurs
+
+lux0_sensor_range
+       RO - lux0_input max value.
+
+            Actually never reaches since sensor tends
+            to saturate much before that. Real max value varies depending
+            on the light spectrum etc.
+
+lux0_rate
+       RW - measurement rate in Hz
+
+lux0_rate_avail
+       RO - supported measurement rates
+
+lux0_calibscale
+       RW - calibration value.
+
+            Set to neutral value by default.
+            Output results are multiplied with calibscale / calibscale_default
+            value.
+
+lux0_calibscale_default
+       RO - neutral calibration value
+
+lux0_thresh_above_value
+       RW - HI level threshold value.
+
+            All results above the value
+            trigs an interrupt. 65535 (i.e. sensor_range) disables the above
+            interrupt.
+
+lux0_thresh_below_value
+       RW - LO level threshold value.
+
+            All results below the value
+            trigs an interrupt. 0 disables the below interrupt.
+
+prox0_raw
+       RO - measured proximity value
+
+            sysfs_notify called when threshold interrupt occurs
+
+prox0_sensor_range
+       RO - prox0_raw max value (1023)
+
+prox0_raw_en
+       RW - enable / disable proximity - uses counting logic
+
+            - 1 enables the proximity
+            - 0 disables the proximity
+
+prox0_reporting_mode
+       RW - trigger / periodic.
+
+            In "trigger" mode the driver tells two possible
+            values: 0 or prox0_sensor_range value. 0 means no proximity,
+            1023 means proximity. This causes minimal number of interrupts.
+            In "periodic" mode the driver reports all values above
+            prox0_thresh_above. This causes more interrupts, but it can give
+            _rough_ estimate about the distance.
+
+prox0_reporting_mode_avail
+       RO - accepted values to prox0_reporting_mode (trigger, periodic)
+
+prox0_thresh_above_value
+       RW - threshold level which trigs proximity events.

diff --git a/Documentation/misc-devices/apds990x.txt b/Documentation/misc-devices/apds990x.txt
deleted file mode 100644 (file)
index 454d95d..0000000
--- a/Documentation/misc-devices/apds990x.txt
+++ /dev/null
@@ -1,111 +0,0 @@
-Kernel driver apds990x
-======================
-
-Supported chips:
-Avago APDS990X
-
-Data sheet:
-Not freely available
-
-Author:
-Samu Onkalo <samu.p.onkalo@nokia.com>
-
-Description
------------
-
-APDS990x is a combined ambient light and proximity sensor. ALS and proximity
-functionality are highly connected. ALS measurement path must be running
-while the proximity functionality is enabled.
-
-ALS produces raw measurement values for two channels: Clear channel
-(infrared + visible light) and IR only. However, threshold comparisons happen
-using clear channel only. Lux value and the threshold level on the HW
-might vary quite much depending the spectrum of the light source.
-
-Driver makes necessary conversions to both directions so that user handles
-only lux values. Lux value is calculated using information from the both
-channels. HW threshold level is calculated from the given lux value to match
-with current type of the lightning. Sometimes inaccuracy of the estimations
-lead to false interrupt, but that doesn't harm.
-
-ALS contains 4 different gain steps. Driver automatically
-selects suitable gain step. After each measurement, reliability of the results
-is estimated and new measurement is triggered if necessary.
-
-Platform data can provide tuned values to the conversion formulas if
-values are known. Otherwise plain sensor default values are used.
-
-Proximity side is little bit simpler. There is no need for complex conversions.
-It produces directly usable values.
-
-Driver controls chip operational state using pm_runtime framework.
-Voltage regulators are controlled based on chip operational state.
-
-SYSFS
------
-
-
-chip_id
-       RO - shows detected chip type and version
-
-power_state
-       RW - enable / disable chip. Uses counting logic
-            1 enables the chip
-            0 disables the chip
-lux0_input
-       RO - measured lux value
-            sysfs_notify called when threshold interrupt occurs
-
-lux0_sensor_range
-       RO - lux0_input max value. Actually never reaches since sensor tends
-            to saturate much before that. Real max value varies depending
-            on the light spectrum etc.
-
-lux0_rate
-       RW - measurement rate in Hz
-
-lux0_rate_avail
-       RO - supported measurement rates
-
-lux0_calibscale
-       RW - calibration value. Set to neutral value by default.
-            Output results are multiplied with calibscale / calibscale_default
-            value.
-
-lux0_calibscale_default
-       RO - neutral calibration value
-
-lux0_thresh_above_value
-       RW - HI level threshold value. All results above the value
-            trigs an interrupt. 65535 (i.e. sensor_range) disables the above
-            interrupt.
-
-lux0_thresh_below_value
-       RW - LO level threshold value. All results below the value
-            trigs an interrupt. 0 disables the below interrupt.
-
-prox0_raw
-       RO - measured proximity value
-            sysfs_notify called when threshold interrupt occurs
-
-prox0_sensor_range
-       RO - prox0_raw max value (1023)
-
-prox0_raw_en
-       RW - enable / disable proximity - uses counting logic
-            1 enables the proximity
-            0 disables the proximity
-
-prox0_reporting_mode
-       RW - trigger / periodic. In "trigger" mode the driver tells two possible
-            values: 0 or prox0_sensor_range value. 0 means no proximity,
-            1023 means proximity. This causes minimal number of interrupts.
-            In "periodic" mode the driver reports all values above
-            prox0_thresh_above. This causes more interrupts, but it can give
-            _rough_ estimate about the distance.
-
-prox0_reporting_mode_avail
-       RO - accepted values to prox0_reporting_mode (trigger, periodic)
-
-prox0_thresh_above_value
-       RW - threshold level which trigs proximity events.

diff --git a/Documentation/misc-devices/index.rst b/Documentation/misc-devices/index.rst
index edf66b5..46072ce 100644 (file)
--- a/Documentation/misc-devices/index.rst
+++ b/Documentation/misc-devices/index.rst
@@ -15,6 +15,7 @@ fit into other categories.
    :maxdepth: 2
 
    ad525x_dpot
+   apds990x
    bh1770glc
    eeprom
    c2port