From: Nishanth Menon <nm@ti.com>
To: Mark Brown <broonie@kernel.org>
Cc: Paul Walmsley <paul@pwsan.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Kevin Hilman <khilman@deeprootsystems.com>,
Tony Lindgren <tony@atomide.com>,
devicetree-discuss@lists.ozlabs.org,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
linux-doc@vger.kernel.org, lkml <linux-kernel@vger.kernel.org>,
linux-omap <linux-omap@vger.kernel.org>,
Grygorii Strashko <grygorii.strashko@ti.com>
Subject: Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
Date: Thu, 13 Jun 2013 09:58:03 -0500 [thread overview]
Message-ID: <20130613145803.GA32324@kahuna> (raw)
In-Reply-To: <20130613144726.GY1403@sirena.org.uk>
On 15:47-20130613, Mark Brown wrote:
> On Thu, Jun 13, 2013 at 08:39:50AM -0500, Nishanth Menon wrote:
>
> > I am having a bit of a difficulty trying to understand your concern
> > here.
>
> Your device tree for this stuff appears to mostly consist of repeating
> the description of the PMIC that we already have - this really doesn't
> seem like a great result.
>
> > Problem statement:
>
> > OMAP has this weird custom h/w where one programs the voltage and that
> > voltage is send over i2c - this is not same as Tegra's lookup table
> > array which automatically sends out entries, in OMAP, software has to trigger
> > the voltage transition
>
> The basic idea that's important here is that you need to figure out how
> to tell the hardware what to write - how those writes get triggered is a
> separate problem.
>
> > If your concern was describing PMIC parameters in dts, I can easily move
> > them inside the omap_pmic driver and provide required compatible flags.
> > If, on the other hand, the entire approach followed is flawed, I'd like to
> > understand the rationale for the same.
>
> That's the biggest problem I saw so far but to be honest I've not
> drilled down too much into the specifics. From my point of view the
> main thing is how this fits into the frameworks and so on, having the
> register information in the DT was an alarm flag that suggested the
> overall approach was a concern.
OK. would you be ok with an generic omap_pmic driver if the PMIC
specific data set is moved into OF compatible data?
I am proposing moving the following into OF match data.
ti,i2c-slave-address
ti,i2c-voltage-register
ti,i2c-command-register
ti,slew-rate-microvolt
ti,step-size-micro-volts
ti,voltage-selector-set-bits
ti,voltage-selector-mask
ti,voltage-selector-offset
ti,non-zero-voltage-selector
The only thing I propose to retain is board specific variations - e.g.
gpios, boot voltage and standard regulator min,max overrides if any.
I can also do voltage selector based operations while at it.
--
Regards,
Nishanth Menon
WARNING: multiple messages have this Message-ID (diff)
From: nm@ti.com (Nishanth Menon)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
Date: Thu, 13 Jun 2013 09:58:03 -0500 [thread overview]
Message-ID: <20130613145803.GA32324@kahuna> (raw)
In-Reply-To: <20130613144726.GY1403@sirena.org.uk>
On 15:47-20130613, Mark Brown wrote:
> On Thu, Jun 13, 2013 at 08:39:50AM -0500, Nishanth Menon wrote:
>
> > I am having a bit of a difficulty trying to understand your concern
> > here.
>
> Your device tree for this stuff appears to mostly consist of repeating
> the description of the PMIC that we already have - this really doesn't
> seem like a great result.
>
> > Problem statement:
>
> > OMAP has this weird custom h/w where one programs the voltage and that
> > voltage is send over i2c - this is not same as Tegra's lookup table
> > array which automatically sends out entries, in OMAP, software has to trigger
> > the voltage transition
>
> The basic idea that's important here is that you need to figure out how
> to tell the hardware what to write - how those writes get triggered is a
> separate problem.
>
> > If your concern was describing PMIC parameters in dts, I can easily move
> > them inside the omap_pmic driver and provide required compatible flags.
> > If, on the other hand, the entire approach followed is flawed, I'd like to
> > understand the rationale for the same.
>
> That's the biggest problem I saw so far but to be honest I've not
> drilled down too much into the specifics. From my point of view the
> main thing is how this fits into the frameworks and so on, having the
> register information in the DT was an alarm flag that suggested the
> overall approach was a concern.
OK. would you be ok with an generic omap_pmic driver if the PMIC
specific data set is moved into OF compatible data?
I am proposing moving the following into OF match data.
ti,i2c-slave-address
ti,i2c-voltage-register
ti,i2c-command-register
ti,slew-rate-microvolt
ti,step-size-micro-volts
ti,voltage-selector-set-bits
ti,voltage-selector-mask
ti,voltage-selector-offset
ti,non-zero-voltage-selector
The only thing I propose to retain is board specific variations - e.g.
gpios, boot voltage and standard regulator min,max overrides if any.
I can also do voltage selector based operations while at it.
--
Regards,
Nishanth Menon
WARNING: multiple messages have this Message-ID (diff)
From: Nishanth Menon <nm@ti.com>
To: Mark Brown <broonie@kernel.org>
Cc: Paul Walmsley <paul@pwsan.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Kevin Hilman <khilman@deeprootsystems.com>,
Tony Lindgren <tony@atomide.com>,
<devicetree-discuss@lists.ozlabs.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
<linux-doc@vger.kernel.org>, lkml <linux-kernel@vger.kernel.org>,
linux-omap <linux-omap@vger.kernel.org>,
Grygorii Strashko <grygorii.strashko@ti.com>
Subject: Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
Date: Thu, 13 Jun 2013 09:58:03 -0500 [thread overview]
Message-ID: <20130613145803.GA32324@kahuna> (raw)
In-Reply-To: <20130613144726.GY1403@sirena.org.uk>
On 15:47-20130613, Mark Brown wrote:
> On Thu, Jun 13, 2013 at 08:39:50AM -0500, Nishanth Menon wrote:
>
> > I am having a bit of a difficulty trying to understand your concern
> > here.
>
> Your device tree for this stuff appears to mostly consist of repeating
> the description of the PMIC that we already have - this really doesn't
> seem like a great result.
>
> > Problem statement:
>
> > OMAP has this weird custom h/w where one programs the voltage and that
> > voltage is send over i2c - this is not same as Tegra's lookup table
> > array which automatically sends out entries, in OMAP, software has to trigger
> > the voltage transition
>
> The basic idea that's important here is that you need to figure out how
> to tell the hardware what to write - how those writes get triggered is a
> separate problem.
>
> > If your concern was describing PMIC parameters in dts, I can easily move
> > them inside the omap_pmic driver and provide required compatible flags.
> > If, on the other hand, the entire approach followed is flawed, I'd like to
> > understand the rationale for the same.
>
> That's the biggest problem I saw so far but to be honest I've not
> drilled down too much into the specifics. From my point of view the
> main thing is how this fits into the frameworks and so on, having the
> register information in the DT was an alarm flag that suggested the
> overall approach was a concern.
OK. would you be ok with an generic omap_pmic driver if the PMIC
specific data set is moved into OF compatible data?
I am proposing moving the following into OF match data.
ti,i2c-slave-address
ti,i2c-voltage-register
ti,i2c-command-register
ti,slew-rate-microvolt
ti,step-size-micro-volts
ti,voltage-selector-set-bits
ti,voltage-selector-mask
ti,voltage-selector-offset
ti,non-zero-voltage-selector
The only thing I propose to retain is board specific variations - e.g.
gpios, boot voltage and standard regulator min,max overrides if any.
I can also do voltage selector based operations while at it.
--
Regards,
Nishanth Menon
next prev parent reply other threads:[~2013-06-13 14:58 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-22 18:18 [RFC PATCH 0/4] regulator/OMAP: support VC/VP support in dts Nishanth Menon
2013-05-22 18:18 ` Nishanth Menon
2013-05-22 18:18 ` Nishanth Menon
2013-05-22 18:18 ` [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP Nishanth Menon
2013-05-22 18:18 ` Nishanth Menon
2013-05-22 18:18 ` Nishanth Menon
[not found] ` <1369246717-4167-2-git-send-email-nm-l0cyMroinI0@public.gmane.org>
2013-06-10 10:31 ` Mark Brown
2013-06-10 10:31 ` Mark Brown
2013-06-10 10:31 ` Mark Brown
2013-06-10 16:16 ` Nishanth Menon
2013-06-10 16:16 ` Nishanth Menon
[not found] ` <CAGo_u6qTiPpd0DDe3jnPh_UxTwox22azhcMGy=fftL8H+DGeyw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-10 16:49 ` Mark Brown
2013-06-10 16:49 ` Mark Brown
2013-06-10 16:49 ` Mark Brown
2013-06-10 17:51 ` Nishanth Menon
2013-06-10 17:51 ` Nishanth Menon
[not found] ` <CAGo_u6ov=yaCwt8apbvW57ErAvhgUBHHw9gwADBC1fJUrfucUQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-10 18:01 ` Mark Brown
2013-06-10 18:01 ` Mark Brown
2013-06-10 18:01 ` Mark Brown
2013-06-13 13:39 ` Nishanth Menon
2013-06-13 13:39 ` Nishanth Menon
2013-06-13 13:39 ` Nishanth Menon
2013-06-13 14:47 ` Mark Brown
2013-06-13 14:47 ` Mark Brown
2013-06-13 14:47 ` Mark Brown
2013-06-13 14:58 ` Nishanth Menon [this message]
2013-06-13 14:58 ` Nishanth Menon
2013-06-13 14:58 ` Nishanth Menon
2013-06-13 15:07 ` Mark Brown
2013-06-13 15:07 ` Mark Brown
2013-06-13 15:12 ` Nishanth Menon
2013-06-13 15:12 ` Nishanth Menon
[not found] ` <1369246717-4167-1-git-send-email-nm-l0cyMroinI0@public.gmane.org>
2013-05-22 18:18 ` [RFC PATCH 2/4] PM / AVS: Introduce support for OMAP Voltage Controller(VC) with device tree nodes Nishanth Menon
2013-05-22 18:18 ` Nishanth Menon
2013-05-22 18:18 ` Nishanth Menon
2013-05-22 18:18 ` [RFC PATCH 3/4] PM / AVS: Introduce support for OMAP Voltage Processor(VP) " Nishanth Menon
2013-05-22 18:18 ` Nishanth Menon
2013-05-22 18:18 ` Nishanth Menon
2013-05-22 18:18 ` [RFC PATCH 4/4] HACK: OMAP4460/TPS/TWL/PandaBoardES - Enable VP regulator for cpufreq Nishanth Menon
2013-05-22 18:18 ` Nishanth Menon
2013-05-22 18:18 ` Nishanth Menon
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=20130613145803.GA32324@kahuna \
--to=nm@ti.com \
--cc=broonie@kernel.org \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grygorii.strashko@ti.com \
--cc=khilman@deeprootsystems.com \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=tony@atomide.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 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.