All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robherring2@gmail.com>
To: Adriana Reus <adriana.reus@intel.com>,
	Jonathan Cameron <jic23@kernel.org>
Cc: Peter Meerwald <pmeerw@pmeerw.net>,
	daniel.baluta@intel.com,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>
Subject: Re: [PATCH v6 2/2] devicetree: Add documentation for UPISEMI us5182d ALS and Proximity sensor
Date: Tue, 8 Sep 2015 20:05:41 -0500	[thread overview]
Message-ID: <55EF85E5.5070708@gmail.com> (raw)
In-Reply-To: <55ED985E.8070806@intel.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Adriana Reus
	<adriana.reus-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Peter Meerwald <pmeerw-jW+XmwGofnusTnJN9+BGXg@public.gmane.org>,
	daniel.baluta-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	"linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	Ian Campbell
	<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
	Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Subject: Re: [PATCH v6 2/2] devicetree: Add documentation for UPISEMI us5182d ALS and Proximity sensor
Date: Tue, 8 Sep 2015 20:05:41 -0500	[thread overview]
Message-ID: <55EF85E5.5070708@gmail.com> (raw)
In-Reply-To: <55ED985E.8070806-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>>> 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

  reply	other threads:[~2015-09-09  5:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-20 10:12 [PATCH v6 0/2] Add support and documentation for UPISEMI us5182d als and proximity sensor Adriana Reus
2015-08-20 10:12 ` Adriana Reus
2015-08-20 10:12 ` [PATCH v6 1/2] iio: light: Add support for UPISEMI uS5182d " Adriana Reus
2015-08-27 20:16   ` Jonathan Cameron
2015-08-27 20:16     ` Jonathan Cameron
2015-08-20 10:12 ` [PATCH v6 2/2] devicetree: Add documentation for UPISEMI us5182d ALS and Proximity sensor Adriana Reus
2015-08-27 20:23   ` Jonathan Cameron
2015-08-27 20:23     ` Jonathan Cameron
2015-08-31 15:38     ` Rob Herring
2015-08-31 15:38       ` Rob Herring
2015-09-07 13:59       ` Adriana Reus
2015-09-07 13:59         ` Adriana Reus
2015-09-09  1:05         ` Rob Herring [this message]
2015-09-09  1:05           ` Rob Herring
2015-09-11 11:55           ` Adriana Reus
2015-09-11 11:55             ` Adriana Reus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55EF85E5.5070708@gmail.com \
    --to=robherring2@gmail.com \
    --cc=adriana.reus@intel.com \
    --cc=daniel.baluta@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=pmeerw@pmeerw.net \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.