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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
