From: Mark Brown <broonie@kernel.org>
To: Martin Fuzzey <mfuzzey@parkeon.com>
Cc: Javier Martinez Canillas <javier@osg.samsung.com>,
linux-kernel@vger.kernel.org
Subject: Re: Regulator: drivers that need to know their supply
Date: Mon, 11 Apr 2016 00:18:56 +0100 [thread overview]
Message-ID: <20160410231856.GE18319@sirena.org.uk> (raw)
In-Reply-To: <5706A435.4050304@parkeon.com>
[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]
On Thu, Apr 07, 2016 at 08:17:25PM +0200, Martin Fuzzey wrote:
> On 07/04/16 19:02, Mark Brown wrote:
> >No, this is not sensible. You should be telling the framework about the
> >slew rate and letting the framework work out how long it's going to take
> >to transition. Your driver shouldn't be peering around inside other
> >regulators, it should be telling the framework what it does itself and
> >any handling of interrelationships should be in the framework.
> Ok, but I fail to see any way to do that (at least with the framework as
> is).
Then send patches for the framework. One of the great things about
working on Linux is that the whole OS is free software so you don't have
to work around things in your driver! I've not looked at the code for
this specific case.
> Or are you saying I should extend the framework to add a .get_ramp_delay
> driver callback and make the framework do the calculation itself?
Yes.
> While moving it to the framework will avoid the driver knowing about other
> regulators it won't fix the underlying issues I mentionned.
> For a regulator configured as always-on the framework doesn't lookup and
> enable the parent regulators until regulator_register_resolve_supply()
> is caused right at the end of regulator_register().
> This means that, when the always-on register is enabled it has no supply
> assigned, even at the framework level.
You might find this changing very shortly but in any case the answer is
still the same, change the framework if it needs changing.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
prev parent reply other threads:[~2016-04-10 23:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-07 13:25 Martin Fuzzey
2016-04-07 17:02 ` Mark Brown
2016-04-07 18:17 ` Martin Fuzzey
2016-04-10 23:18 ` Mark Brown [this message]
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=20160410231856.GE18319@sirena.org.uk \
--to=broonie@kernel.org \
--cc=javier@osg.samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mfuzzey@parkeon.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
all inboxes | Powered by JetHome®