diff mbox

[v6,2/2] devicetree: Add documentation for UPISEMI us5182d ALS and Proximity sensor

Message ID 1440065534-8601-3-git-send-email-adriana.reus@intel.com
State Superseded, archived
Headers show

Commit Message

Adriana Reus Aug. 20, 2015, 10:12 a.m. UTC
Added entries in i2c/vendor-prefixes for the us5182d als and proximity sensor.
Also added a documentation file for this sensor's properties.

Signed-off-by: Adriana Reus <adriana.reus@intel.com>
---
 .../devicetree/bindings/iio/light/us5182d.txt      | 23 ++++++++++++++++++++++
 .../devicetree/bindings/vendor-prefixes.txt        |  1 +
 2 files changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/light/us5182d.txt

Comments

Jonathan Cameron Aug. 27, 2015, 8:23 p.m. UTC | #1
On 20/08/15 11:12, Adriana Reus wrote:
> Added entries in i2c/vendor-prefixes for the us5182d als and proximity sensor.
> Also added a documentation file for this sensor's properties.
> 
> Signed-off-by: Adriana Reus <adriana.reus@intel.com>
This isn't that trivial so I'd like some device tree maintainer
input if possible.

For now I've backed out the driver from my tree (given timing we have
loads of time to sort this out!)

Anyhow, anyone device tree related able to take a look at this.

Adriana, btw these should be cc'd to the device tree maintainers in
the first place (now added).

Jonathan
> ---
>  .../devicetree/bindings/iio/light/us5182d.txt      | 23 ++++++++++++++++++++++
>  .../devicetree/bindings/vendor-prefixes.txt        |  1 +
>  2 files changed, 24 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/light/us5182d.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt b/Documentation/devicetree/bindings/iio/light/us5182d.txt
> new file mode 100644
> index 0000000..7785c56
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt
> @@ -0,0 +1,23 @@
> +* UPISEMI us5182d I2C ALS and Proximity sensor
> +
> +Required properties:
> +- compatible: must be "upisemi,usd5182"
> +- reg: the I2C address of the device
> +
> +Optional properties:
> +- upisemi,glass-coef: glass attenuation factor
> +- upisemi,dark-ths: array of thresholds (adc counts) corresponding to every scale
> +- upisemi,upper-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4) applied when light > threshold
> +- upisemi,lower-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4) applied when light < threshold
> +
> +Example:
> +
> +    usd5182@39 {
> +                compatible = "upisemi,usd5182";
> +                reg = <0x39>;
> +                upisemi,glass-coef = < 1000 >;
> +                upisemi,dark-ths = /bits/ 16 <170 200 512 512 800 2000 4000 8000>;
> +                upisemi,upper-dark-gain = /bits/ 8 <0x00>;
> +                upisemi,lower-dark-gain = /bits/ 8 <0x16>;
> +    };
> +
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index d444757..5b40bab 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -211,6 +211,7 @@ toshiba	Toshiba Corporation
>  toumaz	Toumaz
>  tplink	TP-LINK Technologies Co., Ltd.
>  truly	Truly Semiconductors Limited
> +upisemi	uPI Semiconductor Corp.
>  usi	Universal Scientific Industrial Co., Ltd.
>  v3	V3 Semiconductor
>  variscite	Variscite Ltd.
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rob Herring Aug. 31, 2015, 3:38 p.m. UTC | #2
On Thu, Aug 27, 2015 at 3:23 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> On 20/08/15 11:12, Adriana Reus wrote:
>> Added entries in i2c/vendor-prefixes for the us5182d als and proximity sensor.
>> Also added a documentation file for this sensor's properties.
>>
>> Signed-off-by: Adriana Reus <adriana.reus@intel.com>
> This isn't that trivial so I'd like some device tree maintainer
> input if possible.

It seems fairly reasonable to me. Would other ALS or proximity sensors
need similar properties?

> For now I've backed out the driver from my tree (given timing we have
> loads of time to sort this out!)
>
> Anyhow, anyone device tree related able to take a look at this.
>
> Adriana, btw these should be cc'd to the device tree maintainers in
> the first place (now added).
>
> Jonathan
>> ---
>>  .../devicetree/bindings/iio/light/us5182d.txt      | 23 ++++++++++++++++++++++
>>  .../devicetree/bindings/vendor-prefixes.txt        |  1 +
>>  2 files changed, 24 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/iio/light/us5182d.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt b/Documentation/devicetree/bindings/iio/light/us5182d.txt
>> new file mode 100644
>> index 0000000..7785c56
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt
>> @@ -0,0 +1,23 @@
>> +* UPISEMI us5182d I2C ALS and Proximity sensor
>> +
>> +Required properties:
>> +- compatible: must be "upisemi,usd5182"
>> +- reg: the I2C address of the device
>> +
>> +Optional properties:

Do you expect certain defaults if not present? Some description of how
all these values are determined would be useful.


>> +- upisemi,glass-coef: glass attenuation factor
>> +- upisemi,dark-ths: array of thresholds (adc counts) corresponding to every scale

What is the size of the array and valid range of values?

Be specific this is 16-bit property.

>> +- upisemi,upper-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4) applied when light > threshold
>> +- upisemi,lower-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4) applied when light < threshold

Be specific this is an 8-bit property.

>> +
>> +Example:
>> +
>> +    usd5182@39 {
>> +                compatible = "upisemi,usd5182";
>> +                reg = <0x39>;
>> +                upisemi,glass-coef = < 1000 >;
>> +                upisemi,dark-ths = /bits/ 16 <170 200 512 512 800 2000 4000 8000>;
>> +                upisemi,upper-dark-gain = /bits/ 8 <0x00>;
>> +                upisemi,lower-dark-gain = /bits/ 8 <0x16>;
>> +    };
>> +
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index d444757..5b40bab 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -211,6 +211,7 @@ toshiba   Toshiba Corporation
>>  toumaz       Toumaz
>>  tplink       TP-LINK Technologies Co., Ltd.
>>  truly        Truly Semiconductors Limited
>> +upisemi      uPI Semiconductor Corp.
>>  usi  Universal Scientific Industrial Co., Ltd.
>>  v3   V3 Semiconductor
>>  variscite    Variscite Ltd.
>>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Adriana Reus Sept. 7, 2015, 1:59 p.m. UTC | #3
Thanks for your feedback, some comments inline.

On 31.08.2015 18:38, Rob Herring wrote:
> On Thu, Aug 27, 2015 at 3:23 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>> On 20/08/15 11:12, Adriana Reus wrote:
>>> Added entries in i2c/vendor-prefixes for the us5182d als and proximity sensor.
>>> Also added a documentation file for this sensor's properties.
>>>
>>> Signed-off-by: Adriana Reus <adriana.reus@intel.com>
>> This isn't that trivial so I'd like some device tree maintainer
>> input if possible.
>
> It seems fairly reasonable to me. Would other ALS or proximity sensors
> need similar properties?
The "glass-coef" is intended to compensate for the material (glass) that 
may be covering the sensor if it's integrated in a phone, tablet etc. I 
chose 1000 as resolution for this scaling factor (i'll add a more 
detailed description). So possibly similar properties could be used for 
other als sensors as well.

The last 3 tuning parameters are specific to this particular sensor.
>
>> For now I've backed out the driver from my tree (given timing we have
>> loads of time to sort this out!)
>>
>> Anyhow, anyone device tree related able to take a look at this.
>>
>> Adriana, btw these should be cc'd to the device tree maintainers in
>> the first place (now added).
>>
>> Jonathan
>>> ---
>>>   .../devicetree/bindings/iio/light/us5182d.txt      | 23 ++++++++++++++++++++++
>>>   .../devicetree/bindings/vendor-prefixes.txt        |  1 +
>>>   2 files changed, 24 insertions(+)
>>>   create mode 100644 Documentation/devicetree/bindings/iio/light/us5182d.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt b/Documentation/devicetree/bindings/iio/light/us5182d.txt
>>> new file mode 100644
>>> index 0000000..7785c56
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt
>>> @@ -0,0 +1,23 @@
>>> +* UPISEMI us5182d I2C ALS and Proximity sensor
>>> +
>>> +Required properties:
>>> +- compatible: must be "upisemi,usd5182"
>>> +- reg: the I2C address of the device
>>> +
>>> +Optional properties:
>
> Do you expect certain defaults if not present? Some description of how
> all these values are determined would be useful.
Yes, if not present they will fall back to default values - the values 
in the example.
- the glass-coef one is 1000 by default - so no glass compensation by 
default (lux = lux * 1000/1000)
- the others were determined experimentally - by fine tuning starting 
from the default values in those registers).
>
>
>>> +- upisemi,glass-coef: glass attenuation factor
>>> +- upisemi,dark-ths: array of thresholds (adc counts) corresponding to every scale
>
> What is the size of the array and valid range of values?
>
> Be specific this is 16-bit property.
Ok, I'll add this info in a following patch set.
>
>>> +- upisemi,upper-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4) applied when light > threshold
>>> +- upisemi,lower-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4) applied when light < threshold
>
> Be specific this is an 8-bit property.
ok
>
>>> +
>>> +Example:
>>> +
>>> +    usd5182@39 {
>>> +                compatible = "upisemi,usd5182";
>>> +                reg = <0x39>;
>>> +                upisemi,glass-coef = < 1000 >;
>>> +                upisemi,dark-ths = /bits/ 16 <170 200 512 512 800 2000 4000 8000>;
>>> +                upisemi,upper-dark-gain = /bits/ 8 <0x00>;
>>> +                upisemi,lower-dark-gain = /bits/ 8 <0x16>;
>>> +    };
>>> +
>>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
>>> index d444757..5b40bab 100644
>>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>>> @@ -211,6 +211,7 @@ toshiba   Toshiba Corporation
>>>   toumaz       Toumaz
>>>   tplink       TP-LINK Technologies Co., Ltd.
>>>   truly        Truly Semiconductors Limited
>>> +upisemi      uPI Semiconductor Corp.
>>>   usi  Universal Scientific Industrial Co., Ltd.
>>>   v3   V3 Semiconductor
>>>   variscite    Variscite Ltd.
>>>
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rob Herring Sept. 9, 2015, 1:05 a.m. UTC | #4
On 09/07/2015 08:59 AM, Adriana Reus wrote:
> Thanks for your feedback, some comments inline.
> 
> On 31.08.2015 18:38, Rob Herring wrote:
>> On Thu, Aug 27, 2015 at 3:23 PM, Jonathan Cameron <jic23@kernel.org>
>> wrote:
>>> On 20/08/15 11:12, Adriana Reus wrote:
>>>> Added entries in i2c/vendor-prefixes for the us5182d als and
>>>> proximity sensor.
>>>> Also added a documentation file for this sensor's properties.
>>>>
>>>> Signed-off-by: Adriana Reus <adriana.reus@intel.com>
>>> This isn't that trivial so I'd like some device tree maintainer
>>> input if possible.
>>
>> It seems fairly reasonable to me. Would other ALS or proximity sensors
>> need similar properties?
> The "glass-coef" is intended to compensate for the material (glass) that
> may be covering the sensor if it's integrated in a phone, tablet etc. I
> chose 1000 as resolution for this scaling factor (i'll add a more
> detailed description). So possibly similar properties could be used for
> other als sensors as well.

Seems like amstaos,cover-comp-gain would be doing the same thing. But it
is defined as an integer, so I'm not sure how that would work.

> 
> The last 3 tuning parameters are specific to this particular sensor.
>>
>>> For now I've backed out the driver from my tree (given timing we have
>>> loads of time to sort this out!)
>>>
>>> Anyhow, anyone device tree related able to take a look at this.
>>>
>>> Adriana, btw these should be cc'd to the device tree maintainers in
>>> the first place (now added).
>>>
>>> Jonathan
>>>> ---
>>>>   .../devicetree/bindings/iio/light/us5182d.txt      | 23
>>>> ++++++++++++++++++++++
>>>>   .../devicetree/bindings/vendor-prefixes.txt        |  1 +
>>>>   2 files changed, 24 insertions(+)
>>>>   create mode 100644
>>>> Documentation/devicetree/bindings/iio/light/us5182d.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt
>>>> b/Documentation/devicetree/bindings/iio/light/us5182d.txt
>>>> new file mode 100644
>>>> index 0000000..7785c56
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt
>>>> @@ -0,0 +1,23 @@
>>>> +* UPISEMI us5182d I2C ALS and Proximity sensor
>>>> +
>>>> +Required properties:
>>>> +- compatible: must be "upisemi,usd5182"
>>>> +- reg: the I2C address of the device
>>>> +
>>>> +Optional properties:
>>
>> Do you expect certain defaults if not present? Some description of how
>> all these values are determined would be useful.
> Yes, if not present they will fall back to default values - the values
> in the example.
> - the glass-coef one is 1000 by default - so no glass compensation by
> default (lux = lux * 1000/1000)
> - the others were determined experimentally - by fine tuning starting
> from the default values in those registers).

So the default if the properties are not present is a default register
value or a default in the driver?

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Adriana Reus Sept. 11, 2015, 11:55 a.m. UTC | #5
Hi,

Sorry for my delayed response, answers inline.

Thank you,
Adriana
On 09.09.2015 04:05, Rob Herring wrote:
> On 09/07/2015 08:59 AM, Adriana Reus wrote:
>> Thanks for your feedback, some comments inline.
>>
>> On 31.08.2015 18:38, Rob Herring wrote:
>>> On Thu, Aug 27, 2015 at 3:23 PM, Jonathan Cameron <jic23@kernel.org>
>>> wrote:
>>>> On 20/08/15 11:12, Adriana Reus wrote:
>>>>> Added entries in i2c/vendor-prefixes for the us5182d als and
>>>>> proximity sensor.
>>>>> Also added a documentation file for this sensor's properties.
>>>>>
>>>>> Signed-off-by: Adriana Reus <adriana.reus@intel.com>
>>>> This isn't that trivial so I'd like some device tree maintainer
>>>> input if possible.
>>>
>>> It seems fairly reasonable to me. Would other ALS or proximity sensors
>>> need similar properties?
>> The "glass-coef" is intended to compensate for the material (glass) that
>> may be covering the sensor if it's integrated in a phone, tablet etc. I
>> chose 1000 as resolution for this scaling factor (i'll add a more
>> detailed description). So possibly similar properties could be used for
>> other als sensors as well.
>
> Seems like amstaos,cover-comp-gain would be doing the same thing. But it
> is defined as an integer, so I'm not sure how that would work.
Indeed it seems similar. I had a quick look over it and from what I 
understand it seems to act like a straightforward scaling factor, only 
difference being that it's an int, I opted to float for a better tuning 
and resolution.
>
>>
>> The last 3 tuning parameters are specific to this particular sensor.
>>>
>>>> For now I've backed out the driver from my tree (given timing we have
>>>> loads of time to sort this out!)
>>>>
>>>> Anyhow, anyone device tree related able to take a look at this.
>>>>
>>>> Adriana, btw these should be cc'd to the device tree maintainers in
>>>> the first place (now added).
>>>>
>>>> Jonathan
>>>>> ---
>>>>>    .../devicetree/bindings/iio/light/us5182d.txt      | 23
>>>>> ++++++++++++++++++++++
>>>>>    .../devicetree/bindings/vendor-prefixes.txt        |  1 +
>>>>>    2 files changed, 24 insertions(+)
>>>>>    create mode 100644
>>>>> Documentation/devicetree/bindings/iio/light/us5182d.txt
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt
>>>>> b/Documentation/devicetree/bindings/iio/light/us5182d.txt
>>>>> new file mode 100644
>>>>> index 0000000..7785c56
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt
>>>>> @@ -0,0 +1,23 @@
>>>>> +* UPISEMI us5182d I2C ALS and Proximity sensor
>>>>> +
>>>>> +Required properties:
>>>>> +- compatible: must be "upisemi,usd5182"
>>>>> +- reg: the I2C address of the device
>>>>> +
>>>>> +Optional properties:
>>>
>>> Do you expect certain defaults if not present? Some description of how
>>> all these values are determined would be useful.
>> Yes, if not present they will fall back to default values - the values
>> in the example.
>> - the glass-coef one is 1000 by default - so no glass compensation by
>> default (lux = lux * 1000/1000)
>> - the others were determined experimentally - by fine tuning starting
>> from the default values in those registers).
>
> So the default if the properties are not present is a default register
> value or a default in the driver?

A default in the driver.
>
> Rob
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt b/Documentation/devicetree/bindings/iio/light/us5182d.txt
new file mode 100644
index 0000000..7785c56
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt
@@ -0,0 +1,23 @@ 
+* UPISEMI us5182d I2C ALS and Proximity sensor
+
+Required properties:
+- compatible: must be "upisemi,usd5182"
+- reg: the I2C address of the device
+
+Optional properties:
+- upisemi,glass-coef: glass attenuation factor
+- upisemi,dark-ths: array of thresholds (adc counts) corresponding to every scale
+- upisemi,upper-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4) applied when light > threshold
+- upisemi,lower-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4) applied when light < threshold
+
+Example:
+
+    usd5182@39 {
+                compatible = "upisemi,usd5182";
+                reg = <0x39>;
+                upisemi,glass-coef = < 1000 >;
+                upisemi,dark-ths = /bits/ 16 <170 200 512 512 800 2000 4000 8000>;
+                upisemi,upper-dark-gain = /bits/ 8 <0x00>;
+                upisemi,lower-dark-gain = /bits/ 8 <0x16>;
+    };
+
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d444757..5b40bab 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -211,6 +211,7 @@  toshiba	Toshiba Corporation
 toumaz	Toumaz
 tplink	TP-LINK Technologies Co., Ltd.
 truly	Truly Semiconductors Limited
+upisemi	uPI Semiconductor Corp.
 usi	Universal Scientific Industrial Co., Ltd.
 v3	V3 Semiconductor
 variscite	Variscite Ltd.