From: Laxman Dewangan <ldewangan@nvidia.com>
To: Bjorn Andersson <bjorn@kryo.se>
Cc: Mark Brown <broonie@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.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>,
Liam Girdwood <lgirdwood@gmail.com>,
"Bjorn Andersson" <bjorn.andersson@sonymobile.com>,
Stephen Warren <swarren@wwwdotorg.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Gandhar Dighe <gdighe@nvidia.com>,
"Stuart Yates" <syates@nvidia.com>
Subject: Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based on platform behavior
Date: Wed, 30 Mar 2016 18:59:07 +0530 [thread overview]
Message-ID: <56FBD4A3.7080208@nvidia.com> (raw)
In-Reply-To: <56ED0F58.7060005@nvidia.com>
On Saturday 19 March 2016 02:05 PM, Laxman Dewangan wrote:
>
> On Saturday 19 March 2016 10:01 AM, Bjorn Andersson wrote:
>> On Tue, Mar 15, 2016 at 6:41 AM, Laxman Dewangan
>> <ldewangan@nvidia.com> wrote:
>>>
>>>
>> Generally the device driver should describe the PMIC and the device
>> tree should describe the board. So the Maxim's numbers should (if
>> specified at all) go into the driver and the measures/calculated
>> characteristics for your board should be specified in the dt.
>>
>> The ramp properties in the generic regulator binding is used to inform
>> the OS about the board's ramp properties.
>>
>>
>> If I understand you correctly the Maxim PMIC can be configured to
>> drive the change at different speed, this should be configured through
>> a Maxim specific property. It should not reuse the generic properties
>> for ramp delays.
>>
>
> Ramp delay configurations are seen on other vendor's PMIC devices also.
> Therefore, I like o me generic property rather than specific to Maxim.
> Parsing can be done in the core framework and applied during setting
> machine constraints.
Any comment on this approach?
Like to add property as "regulator-device-ramp-delay" which will be used
for PMIC configuration and regulator-ramp-delay will be used for delay
calculation. This is case when advertised ramp delay does not match with
the platform measured ramp delay.
If regulator-device-ramp-delay is not provided from platform then
regulator-ramp-delay will be used for PMIC configuration as well as for
the delay calculation. This is case when advertised ramp delay match
with the platform measured ramp delay.
next prev parent reply other threads:[~2016-03-30 13:40 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-29 14:40 [PATCH 1/2] regulator: DT: Add support to scale ramp delay based on platform behavior Laxman Dewangan
2016-02-29 14:40 ` [PATCH 2/2] regulator: " Laxman Dewangan
2016-02-29 17:47 ` [PATCH 1/2] regulator: DT: " Bjorn Andersson
2016-03-01 2:23 ` Mark Brown
2016-03-01 3:48 ` Laxman Dewangan
2016-03-02 3:38 ` Mark Brown
2016-03-02 3:35 ` Laxman Dewangan
2016-03-02 4:35 ` Mark Brown
2016-03-02 6:12 ` Laxman Dewangan
2016-03-15 13:41 ` Laxman Dewangan
2016-03-15 14:48 ` Mark Brown
2016-03-16 11:30 ` Laxman Dewangan
2016-03-19 4:31 ` Bjorn Andersson
2016-03-19 8:35 ` Laxman Dewangan
2016-03-30 13:29 ` Laxman Dewangan [this message]
2016-03-30 18:16 ` Mark Brown
2016-03-31 7:06 ` Laxman Dewangan
2016-03-31 16:51 ` Mark Brown
2016-03-31 17:13 ` Laxman Dewangan
2016-03-31 17:47 ` Mark Brown
2016-03-31 17:47 ` Laxman Dewangan
2016-03-31 18:31 ` Mark Brown
2016-03-31 18:31 ` Laxman Dewangan
2016-03-31 18:45 ` Mark Brown
2016-03-31 18:39 ` Laxman Dewangan
2016-03-31 18:59 ` Mark Brown
2016-03-31 18:59 ` Laxman Dewangan
2016-03-31 19:22 ` Mark Brown
2016-03-31 19:48 ` Laxman Dewangan
2016-03-31 20:39 ` Mark Brown
2016-04-01 7:15 ` Laxman Dewangan
2016-04-01 16:11 ` Mark Brown
2016-04-05 8:01 ` Laxman Dewangan
2016-04-12 1:02 ` Mark Brown
2016-04-12 13:29 ` Laxman Dewangan
2016-04-13 6:53 ` Mark Brown
2016-04-19 10:01 ` Laxman Dewangan
2016-04-19 10:55 ` Mark Brown
2016-04-19 10:56 ` Laxman Dewangan
2016-04-19 15:47 ` Mark Brown
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=56FBD4A3.7080208@nvidia.com \
--to=ldewangan@nvidia.com \
--cc=bjorn.andersson@linaro.org \
--cc=bjorn.andersson@sonymobile.com \
--cc=bjorn@kryo.se \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gdighe@nvidia.com \
--cc=ijc+devicetree@hellion.org.uk \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=swarren@wwwdotorg.org \
--cc=syates@nvidia.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).