public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Nishanth Menon <nm@ti.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>,
	"Tony Lindgren" <tony@atomide.com>,
	"Kevin Hilman" <khilman@deeprootsystems.com>,
	devicetree-discuss@lists.ozlabs.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	"Grygorii Strashko" <grygorii.strashko@ti.com>,
	"Taras Kondratiuk" <taras@ti.com>
Subject: Re: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to control PMIC over VC/VP
Date: Wed, 10 Jul 2013 10:19:52 +0100	[thread overview]
Message-ID: <20130710091952.GF3179@sirena.org.uk> (raw)
In-Reply-To: <51DC3487.2080503@ti.com>

[-- Attachment #1: Type: text/plain, Size: 1996 bytes --]

On Tue, Jul 09, 2013 at 11:04:23AM -0500, Nishanth Menon wrote:
> On 07/09/2013 10:29 AM, Mark Brown wrote:

> >This seems like something we should be able to cope with by for example
> >adding a bus for the custom PMIC interface or otherwise finding a way to

> I had considered introducing a custom bus for custom PMIC interface,
> but as you stated below, standard regulators will probably need some
> custom monkeying around.

We should just be able to use the platform bus here.

> >get to the data at runtime based on the compatible string.  This would
> >need some custom code in the regulators but would have the advantage of
> >keeping the data the same at least.  Hrm.

> Ofcourse,this will be to add custom set/get_voltage implementation
> using this "custom API" which we discussed was'nt that good an idea.

No, if the regulator isn't being interacted with directly then it
doesn't need to export any operations - just data.  The operations would
come from the magic SoC hardware that controls the regulator.  The code
in the drivers should be very small, if it isn't there's no point in
doing this.

> >>between PMICs? yep, twl4030 does 4mV/uSec, 6030 can do 6mV/uSec,
> >>TPS62361 can do 32mV/uSec, TWL6035/37 does 0.220mV/uSec

> >Those are ramp rates, they're not I2C I/O limits.  Ramp rates we already
> >know about.  I think what you're saying here is that this latency value
> >is actually about worst case ramp times?

> Arrgh.. my bad. I confused ramp time with I2C transfer timeout
> parameter. I know that I2C bus can be held[1] by PMIC as long as it
> is busy. Some custom ASIC can do some weird stuff I suppose. I dont
> seem to have clear data points in the sketchy TRMs for 6030/2 ,
> 6035, 5030, for these other than to state it is i2c specification
> compliant (/me grumbles). So, I just have emperical value which is a
> bit conservative and seem to work on the devices.

OK, no problem - like we said further up the thread I think adding
something to get the data

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2013-07-10  9:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-21 21:25 [RFC PATCH V2 0/8] regulator/OMAP: support VC/VP support in dts Nishanth Menon
2013-06-21 21:25 ` [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to control PMIC over VC/VP Nishanth Menon
2013-07-04 15:41   ` Mark Brown
2013-07-05 13:55     ` Nishanth Menon
2013-07-05 14:08       ` Mark Brown
2013-07-05 14:50         ` Nishanth Menon
2013-07-05 16:52           ` Mark Brown
2013-07-05 17:33             ` Nishanth Menon
2013-07-05 17:47               ` Mark Brown
2013-07-08 17:22                 ` Nishanth Menon
2013-07-09 15:29                   ` Mark Brown
2013-07-09 16:04                     ` Nishanth Menon
2013-07-10  9:19                       ` Mark Brown [this message]
2013-06-21 21:25 ` [RFC PATCH V2 2/8] PM / AVS: Introduce support for OMAP Voltage Controller(VC) with device tree nodes Nishanth Menon
2013-06-21 21:25 ` [RFC PATCH V2 3/8] PM / AVS: Introduce support for OMAP Voltage Processor(VP) " Nishanth Menon
2013-06-21 21:25 ` [RFC PATCH V2 4/8] ARM: dts: OMAP4: add voltage controller nodes Nishanth Menon
2013-06-21 21:25 ` [RFC PATCH V2 5/8] ARM: dts: OMAP4: add voltage processor nodes Nishanth Menon
2013-06-21 21:25 ` [RFC PATCH V2 6/8] ARM: dts: TWL6030/OMAP4: Add OMAP voltage path linkage Nishanth Menon
2013-06-21 21:25 ` [RFC PATCH V2 7/8] ARM: dts: omap4-panda-es: add TPS62361 supply for vdd_mpu Nishanth Menon
2013-06-21 21:25 ` [RFC PATCH V2 8/8] ARM: dts: OMAP4-panda-es: use tps regulator as cpu0 supply 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=20130710091952.GF3179@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=b-cousson@ti.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grygorii.strashko@ti.com \
    --cc=khilman@deeprootsystems.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=nm@ti.com \
    --cc=taras@ti.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