On 25.11.2015 02:01, Rob Herring wrote:
On Tue, Nov 24, 2015 at 12:59:49PM +0200, Adriana Reus wrote:
Add a property to allow changing the default power-saving mode.
By default, at read raw the chip will activate and provide
one measurent, then it will shut itself down. However, the
chip can also work in "continuous" mode which may be more reliable
but is also more power consuming.
Signed-off-by: Adriana Reus <adriana.reus@xxxxxxxxx>
---
Documentation/devicetree/bindings/iio/light/us5182d.txt | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt b/Documentation/devicetree/bindings/iio/light/us5182d.txt
index 6f0a530..a619799 100644
--- a/Documentation/devicetree/bindings/iio/light/us5182d.txt
+++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt
@@ -7,13 +7,24 @@ Required properties:
Optional properties:
- upisemi,glass-coef: glass attenuation factor - compensation factor of
resolution 1000 for material transmittance.
+
- upisemi,dark-ths: array of 8 elements containing 16-bit thresholds (adc
counts) corresponding to every scale.
+
- upisemi,upper-dark-gain: 8-bit dark gain compensation factor(4 int and 4
fractional bits - Q4.4) applied when light > threshold
+
- upisemi,lower-dark-gain: 8-bit dark gain compensation factor(4 int and 4
fractional bits - Q4.4) applied when light < threshold
+- upisemi,continuous: This chip has two power modes: one-shot (chip takes one
+ measurement and then shuts itself down) and continuous (
+ chip takes continuous measurements). The one-shot mode is
+ more power-friendly but the continuous mode may be more
+ reliable. If this property is specified the continuous
+ mode will be used instead of the default one-shot one for
+ raw reads.
I could imagine an OS may want to decide this on its own or use a
mixture of the modes.
Rob
There is no possibility of mixing them up (at the same time), so for
example proximity cannot work in one mode and als the other.
The one-shot mode can only be used for raw reads (for example when
user-space polls in_[proximity|light]_raw). If user-space wants to
enable events (activate interrupts when certain thresholds are met -
patch 5 of the series), then the chip has to switch to continuous
nonetheless because it needs to be active all the time. So one work-flow
scenario would be:
Consumer1 starts polling the raw interface - default_mode
Consumer2 activates events - continuous mode
Consumer2 deactivates events - back to default_mode
The only choice here is the default mode for raw reads, it currently is
one-shot, this patch allows for continuous to be used if preferred.
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html