From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
To: Rob Herring <robh+dt@kernel.org>, Lee Jones <lee.jones@linaro.org>
Cc: Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Johan Hovold <jhovold@gmail.com>,
Kumar Gala <galak@codeaurora.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 1/3] devicetree: mfd: Add binding for the TI LM3533
Date: Fri, 30 Oct 2015 12:41:50 -0700 [thread overview]
Message-ID: <20151030194150.GD24668@usrtlx11787.corpusers.net> (raw)
In-Reply-To: <20151030184220.GJ4058@x1>
On Fri 30 Oct 11:42 PDT 2015, Lee Jones wrote:
Rob, please see the discussion regarding ti,boost-freq-khz below. Should
we both specify unit at the same time as we use standard units? (This is
not the first time I have to change this back and forth)
> On Tue, 27 Oct 2015, Bjorn Andersson wrote:
>
[..]
> > +- ti,hwen-gpios:
> > + Usage: required
> > + Value type: <prop-encoded-array>
> > + Definition: reference to gpio pin connected to the HWEN input; as
> > + specified in "gpio/gpio.txt"
>
> Why have you made this a vendor binding?
>
> *-gpios is a generic property.
>
Because the hwen gpio is a ti lm3533 specific thing, but I get what
you're saying. Will drop the prefix.
> > +- ti,als-supply:
> > + Usage: optional
> > + Value type: <prop-encoded-array>
> > + Definition: reference to regulator powering the V_als input; as
> > + specified in "regulator/regulator.txt"
>
> Same goes for *-supply.
>
Same here
> > +- ti,boost-freq-khz:
> > + Usage: required
> > + Value type: <u32>
> > + Definition: switch-frequency of the boost converter, must be either:
> > + 500 or 1000
>
> Quite a few vendors are using 'boost' now.
>
The ti,boost-low-freq from the bq25890 binding is the only other
property I can find that describes the same thing. So I'm not sure I
follow you here.
> Perhaps we need to create a set of generic bindings.
>
> Also, we usually measure DT bindings in HZ, not kHz.
>
I thought we had defined frequencies to be in HZ and HZ only, but then
Rob's comment that I need to actually specify the unit doesn't make any
sense.
Do we want these properties in a standard unit or do we want them
specifying the unit? Having both seems excessive.
> > +- ti,boost-ovp:
> > + Usage: required
> > + Value type: <u32>
> > + Definition: over voltage protection limit, must be one of: 16, 24, 32
> > + or 40
>
> Is this in volts? If so, it should be microvolts.
>
Okay, will update.
[..]
> > += ALS SUBNODE
> > +The als subnode must be named "als", it carries the als related properties.
>
> Perfect time to tell us what ALS is/means.
>
You're right, I'll expand this.
> > +- ti,als-resistance-ohm:
> > + Usage: required (unless ti,pwm-mode is specified)
> > + Value type: <u32>
> > + Definition: specifies the resistor value (R_als), in Ohm. Valid values
> > + ranges from 200kOhm to 1574Ohm.
>
> Might be worth specifying the values which you are actually going to
> use here i.e. "200kOhm" is not a valid u32.
>
I'll drop the units.
> > +- ti,pwm-mode:
> > + Usage: optional
> > + Value type: <empty>
> > + Definition: specifies, if present, that the als should operate in pwm
>
> Suggest s/pwm/PWM/
>
OK
[..]
> > +- ti,pwm-zones:
> > + Usage: optional
> > + Value type: <u32 list>
> > + Definition: lists the ALS zones to be PWM controlled for this backlight,
> > + the values in the list are in the range [0 - 4]
> > +
>
> It's usually a good idea to point to where all of the aforementioned
> generic properties are documented. I personally like the format
> (See: ../<subsystem>/<binding>.txt)
>
OK
> > += LED NODES
Regards,
Bjorn
WARNING: multiple messages have this Message-ID (diff)
From: bjorn.andersson@sonymobile.com (Bjorn Andersson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/3] devicetree: mfd: Add binding for the TI LM3533
Date: Fri, 30 Oct 2015 12:41:50 -0700 [thread overview]
Message-ID: <20151030194150.GD24668@usrtlx11787.corpusers.net> (raw)
In-Reply-To: <20151030184220.GJ4058@x1>
On Fri 30 Oct 11:42 PDT 2015, Lee Jones wrote:
Rob, please see the discussion regarding ti,boost-freq-khz below. Should
we both specify unit at the same time as we use standard units? (This is
not the first time I have to change this back and forth)
> On Tue, 27 Oct 2015, Bjorn Andersson wrote:
>
[..]
> > +- ti,hwen-gpios:
> > + Usage: required
> > + Value type: <prop-encoded-array>
> > + Definition: reference to gpio pin connected to the HWEN input; as
> > + specified in "gpio/gpio.txt"
>
> Why have you made this a vendor binding?
>
> *-gpios is a generic property.
>
Because the hwen gpio is a ti lm3533 specific thing, but I get what
you're saying. Will drop the prefix.
> > +- ti,als-supply:
> > + Usage: optional
> > + Value type: <prop-encoded-array>
> > + Definition: reference to regulator powering the V_als input; as
> > + specified in "regulator/regulator.txt"
>
> Same goes for *-supply.
>
Same here
> > +- ti,boost-freq-khz:
> > + Usage: required
> > + Value type: <u32>
> > + Definition: switch-frequency of the boost converter, must be either:
> > + 500 or 1000
>
> Quite a few vendors are using 'boost' now.
>
The ti,boost-low-freq from the bq25890 binding is the only other
property I can find that describes the same thing. So I'm not sure I
follow you here.
> Perhaps we need to create a set of generic bindings.
>
> Also, we usually measure DT bindings in HZ, not kHz.
>
I thought we had defined frequencies to be in HZ and HZ only, but then
Rob's comment that I need to actually specify the unit doesn't make any
sense.
Do we want these properties in a standard unit or do we want them
specifying the unit? Having both seems excessive.
> > +- ti,boost-ovp:
> > + Usage: required
> > + Value type: <u32>
> > + Definition: over voltage protection limit, must be one of: 16, 24, 32
> > + or 40
>
> Is this in volts? If so, it should be microvolts.
>
Okay, will update.
[..]
> > += ALS SUBNODE
> > +The als subnode must be named "als", it carries the als related properties.
>
> Perfect time to tell us what ALS is/means.
>
You're right, I'll expand this.
> > +- ti,als-resistance-ohm:
> > + Usage: required (unless ti,pwm-mode is specified)
> > + Value type: <u32>
> > + Definition: specifies the resistor value (R_als), in Ohm. Valid values
> > + ranges from 200kOhm to 1574Ohm.
>
> Might be worth specifying the values which you are actually going to
> use here i.e. "200kOhm" is not a valid u32.
>
I'll drop the units.
> > +- ti,pwm-mode:
> > + Usage: optional
> > + Value type: <empty>
> > + Definition: specifies, if present, that the als should operate in pwm
>
> Suggest s/pwm/PWM/
>
OK
[..]
> > +- ti,pwm-zones:
> > + Usage: optional
> > + Value type: <u32 list>
> > + Definition: lists the ALS zones to be PWM controlled for this backlight,
> > + the values in the list are in the range [0 - 4]
> > +
>
> It's usually a good idea to point to where all of the aforementioned
> generic properties are documented. I personally like the format
> (See: ../<subsystem>/<binding>.txt)
>
OK
> > += LED NODES
Regards,
Bjorn
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Andersson <bjorn.andersson-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org>
To: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Johan Hovold <jhovold-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@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>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH v2 1/3] devicetree: mfd: Add binding for the TI LM3533
Date: Fri, 30 Oct 2015 12:41:50 -0700 [thread overview]
Message-ID: <20151030194150.GD24668@usrtlx11787.corpusers.net> (raw)
In-Reply-To: <20151030184220.GJ4058@x1>
On Fri 30 Oct 11:42 PDT 2015, Lee Jones wrote:
Rob, please see the discussion regarding ti,boost-freq-khz below. Should
we both specify unit at the same time as we use standard units? (This is
not the first time I have to change this back and forth)
> On Tue, 27 Oct 2015, Bjorn Andersson wrote:
>
[..]
> > +- ti,hwen-gpios:
> > + Usage: required
> > + Value type: <prop-encoded-array>
> > + Definition: reference to gpio pin connected to the HWEN input; as
> > + specified in "gpio/gpio.txt"
>
> Why have you made this a vendor binding?
>
> *-gpios is a generic property.
>
Because the hwen gpio is a ti lm3533 specific thing, but I get what
you're saying. Will drop the prefix.
> > +- ti,als-supply:
> > + Usage: optional
> > + Value type: <prop-encoded-array>
> > + Definition: reference to regulator powering the V_als input; as
> > + specified in "regulator/regulator.txt"
>
> Same goes for *-supply.
>
Same here
> > +- ti,boost-freq-khz:
> > + Usage: required
> > + Value type: <u32>
> > + Definition: switch-frequency of the boost converter, must be either:
> > + 500 or 1000
>
> Quite a few vendors are using 'boost' now.
>
The ti,boost-low-freq from the bq25890 binding is the only other
property I can find that describes the same thing. So I'm not sure I
follow you here.
> Perhaps we need to create a set of generic bindings.
>
> Also, we usually measure DT bindings in HZ, not kHz.
>
I thought we had defined frequencies to be in HZ and HZ only, but then
Rob's comment that I need to actually specify the unit doesn't make any
sense.
Do we want these properties in a standard unit or do we want them
specifying the unit? Having both seems excessive.
> > +- ti,boost-ovp:
> > + Usage: required
> > + Value type: <u32>
> > + Definition: over voltage protection limit, must be one of: 16, 24, 32
> > + or 40
>
> Is this in volts? If so, it should be microvolts.
>
Okay, will update.
[..]
> > += ALS SUBNODE
> > +The als subnode must be named "als", it carries the als related properties.
>
> Perfect time to tell us what ALS is/means.
>
You're right, I'll expand this.
> > +- ti,als-resistance-ohm:
> > + Usage: required (unless ti,pwm-mode is specified)
> > + Value type: <u32>
> > + Definition: specifies the resistor value (R_als), in Ohm. Valid values
> > + ranges from 200kOhm to 1574Ohm.
>
> Might be worth specifying the values which you are actually going to
> use here i.e. "200kOhm" is not a valid u32.
>
I'll drop the units.
> > +- ti,pwm-mode:
> > + Usage: optional
> > + Value type: <empty>
> > + Definition: specifies, if present, that the als should operate in pwm
>
> Suggest s/pwm/PWM/
>
OK
[..]
> > +- ti,pwm-zones:
> > + Usage: optional
> > + Value type: <u32 list>
> > + Definition: lists the ALS zones to be PWM controlled for this backlight,
> > + the values in the list are in the range [0 - 4]
> > +
>
> It's usually a good idea to point to where all of the aforementioned
> generic properties are documented. I personally like the format
> (See: ../<subsystem>/<binding>.txt)
>
OK
> > += LED NODES
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-10-30 19:41 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-25 18:09 [PATCH 1/3] devicetree: mfd: Add binding for the TI LM3533 Bjorn Andersson
2015-10-25 18:09 ` Bjorn Andersson
2015-10-25 18:09 ` Bjorn Andersson
2015-10-25 18:09 ` [PATCH 2/3] iio: light: lm3533-als: Print error message on invalid resistance Bjorn Andersson
2015-10-25 18:09 ` Bjorn Andersson
2015-10-27 19:18 ` Joe Perches
2015-10-27 19:18 ` Joe Perches
2015-10-28 18:37 ` Bjorn Andersson
2015-10-28 18:37 ` Bjorn Andersson
2015-10-28 18:53 ` Joe Perches
2015-10-28 18:53 ` Joe Perches
2015-10-25 18:09 ` [PATCH 3/3] mfd: lm3533: Support initialization from Device Tree Bjorn Andersson
2015-10-25 18:09 ` Bjorn Andersson
2015-10-27 7:57 ` [PATCH 1/3] devicetree: mfd: Add binding for the TI LM3533 Rob Herring
2015-10-27 7:57 ` Rob Herring
2015-10-27 7:57 ` Rob Herring
2015-10-27 16:29 ` [PATCH v2 " Bjorn Andersson
2015-10-27 16:29 ` Bjorn Andersson
2015-10-27 16:29 ` Bjorn Andersson
2015-10-27 16:29 ` [PATCH v2 2/3] iio: light: lm3533-als: Print error message on invalid resistance Bjorn Andersson
2015-10-27 16:29 ` Bjorn Andersson
2015-10-27 16:29 ` [PATCH v2 3/3] mfd: lm3533: Support initialization from Device Tree Bjorn Andersson
2015-10-27 16:29 ` Bjorn Andersson
2015-10-27 16:43 ` kbuild test robot
2015-10-27 16:43 ` kbuild test robot
2015-10-27 16:53 ` kbuild test robot
2015-10-27 16:53 ` kbuild test robot
2015-10-28 11:40 ` Lee Jones
2015-10-28 11:40 ` Lee Jones
2015-10-28 11:50 ` Joe Perches
2015-10-28 11:50 ` Joe Perches
2015-10-28 18:41 ` Bjorn Andersson
2015-10-28 18:41 ` Bjorn Andersson
2015-10-27 19:21 ` [PATCH v2 1/3] devicetree: mfd: Add binding for the TI LM3533 Rob Herring
2015-10-27 19:21 ` Rob Herring
2015-10-30 18:42 ` Lee Jones
2015-10-30 18:42 ` Lee Jones
2015-10-30 18:42 ` Lee Jones
2015-10-30 19:41 ` Bjorn Andersson [this message]
2015-10-30 19:41 ` Bjorn Andersson
2015-10-30 19:41 ` Bjorn Andersson
2015-10-30 20:18 ` Rob Herring
2015-10-30 20:18 ` Rob Herring
2015-10-30 21:16 ` Bjorn Andersson
2015-10-30 21:16 ` Bjorn Andersson
2015-10-30 21:16 ` Bjorn Andersson
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=20151030194150.GD24668@usrtlx11787.corpusers.net \
--to=bjorn.andersson@sonymobile.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=jhovold@gmail.com \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--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.