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

[Adriana Reus]

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