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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 11 Sep 2015 14:55:46 +0300
From:	Adriana Reus <adriana.reus@...el.com>
To:	Rob Herring <robherring2@...il.com>,
	Jonathan Cameron <jic23@...nel.org>
Cc:	Peter Meerwald <pmeerw@...erw.net>, daniel.baluta@...el.com,
	"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>
Subject: Re: [PATCH v6 2/2] devicetree: Add documentation for UPISEMI us5182d
 ALS and Proximity sensor


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@...nel.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@...el.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/