From: Mark Brown <broonie@kernel.org>
To: Harald Geyer <harald@ccbib.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: Question about regulator API
Date: Mon, 19 Dec 2016 11:09:36 +0000 [thread overview]
Message-ID: <20161219110936.c3acatecdqdvzq7b@sirena.org.uk> (raw)
In-Reply-To: <E1cI0YN-0000LW-8z@stardust.g4.wien.funkfeuer.at>
[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]
On Fri, Dec 16, 2016 at 11:00:35PM +0100, Harald Geyer wrote:
> Mark Brown writes:
> > > I was hoping, that I somehow could get the necessary coordination from
> > > the regulator framework. If the best I can get ATM is notifications, then
> > > I'll try it and see what kind of code falls out of this.
> Ok, tried that and it turns out there is no notification at
> regulator_enable() ATM. I guess you'd merge a patch that added this
> notification?
Probably.
> Sure, this is why regulator_force_disable() is the wrong tool for the job.
> I was more looking for something (call it regulator_shutdown()) that
> * blocked until the regulator is actually off
> * made all calls to regulator_enable() from other consumers block (or fail)
> * maybe sent notifications to consumers, so that they have a chance to
> cooperate and call regulator_disable() at their earliest convenience.
> * was undone by a call to either regulator_disable() or regulator_enable()
> from the consumer that initially called regulator_shutdown()
> I haven't explored this in detail - maybe there are good reasons not to
> have it.
That sounds like a complete mess from a user point of view - unless the
other devices are actually cooperating it's going to have the same
effect as doing nothing at all except it'll block the initiating
consumer and possibly others doing enables, and as far as I can see it
doesn't solve your problems with needing the regulator to be powered off
for a specific amount of time. If it made enable calls block it'd be
very disruptive for other users as they would suddenly find operations
taking vastly longer than they were expecting which could end up being
visible all the way back up to userspace.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2016-12-19 11:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-14 14:52 Harald Geyer
2016-12-14 18:14 ` Mark Brown
2016-12-16 13:41 ` Harald Geyer
2016-12-16 16:53 ` Mark Brown
2016-12-16 22:00 ` Harald Geyer
2016-12-19 11:09 ` 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=20161219110936.c3acatecdqdvzq7b@sirena.org.uk \
--to=broonie@kernel.org \
--cc=harald@ccbib.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/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®