devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  reply	other threads:[~2013-06-13 14:58 UTC|newest]

Thread overview: 15+ 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 ` [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP 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 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 17:51             ` Nishanth Menon
     [not found]               ` <CAGo_u6ov=yaCwt8apbvW57ErAvhgUBHHw9gwADBC1fJUrfucUQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-10 18:01                 ` Mark Brown
2013-06-13 13:39                   ` Nishanth Menon
2013-06-13 14:47                     ` Mark Brown
2013-06-13 14:58                       ` Nishanth Menon [this message]
2013-06-13 15:07                         ` Mark Brown
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   ` [RFC PATCH 3/4] PM / AVS: Introduce support for OMAP Voltage Processor(VP) " Nishanth Menon
2013-05-22 18:18 ` [RFC PATCH 4/4] HACK: OMAP4460/TPS/TWL/PandaBoardES - Enable VP regulator for cpufreq 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 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).