Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1220187 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v6 2/2] devicetree: Add documentation for UPISEMI us5182d  ALS and Proximity sensor Adriana Reus <adriana.reus@intel.com> - 2015-09-07 16:10 +0200
    Re: [PATCH v6 2/2] devicetree: Add documentation for UPISEMI us5182d  ALS and Proximity sensor Rob Herring <robherring2@gmail.com> - 2015-09-09 07:50 +0200
      Re: [PATCH v6 2/2] devicetree: Add documentation for UPISEMI us5182d  ALS and Proximity sensor Adriana Reus <adriana.reus@intel.com> - 2015-09-11 14:00 +0200

#1220187 — Re: [PATCH v6 2/2] devicetree: Add documentation for UPISEMI us5182d ALS and Proximity sensor

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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1221244

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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222742

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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web