linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Harald Geyer <harald@ccbib.org>
To: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: Question about regulator API
Date: Fri, 16 Dec 2016 14:41:42 +0100	[thread overview]
Message-ID: <E1cHslb-0000g0-0V@stardust.g4.wien.funkfeuer.at> (raw)
In-Reply-To: <20161214181405.7hyn4b6yxdetzn5p@sirena.org.uk>

Mark Brown writes:
> On Wed, Dec 14, 2016 at 03:52:54PM +0100, Harald Geyer wrote:
> 
> > Thus the following constraints should be met:
> > * When user space asks
> >   the driver to read a device, it needs to "claim" the supply and
> >   ensure that it has been up for at least 2 seconds before proceeding
> >   to read the HW. The supply would be "locked" enabled.
> >   (I think this is standard regulator API.)
> > * When HW failure is detected, the driver needs to tell the supply to
> >   turn off for at least 2 seconds, wait for all other devices to
> >   release the supply so it can actually be turned off, then wait
> >   for the off period, then start over again.
> >   (This is easy only with getting the supply exclusively.)
> 
> You need to use a notification to figure out when the supply is actually
> off.

I see.
 
> > * It should be possible to read multiple devices quickly when
> >   everything is okay and working. (Having 6 2-second delays accumulate
> >   would be quite annoying.)
> >   (This won't work with exclusive supply usage.)
> 
> Similarly using a notification to discover when the supply is on would
> help here.

Ok.
 
> > * Optionally: If all devices are idle the supply would be enabled
> > if short response time is desired, but disabled if power saving is
> > desired.
> >
> > Can this somehow be solved with the existing API? If not, do you think
> > it would be reasonable/possible to extend the API to cover situations
> > like the one described above?
> 
> This doesn't feel like a regulator API problem exactly, a lot of what
> you're talking about here seems like you really need the devices to
> coopereate with each other and know what they're doing in order to work
> well together.

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.

It still seems a bit of a limitation to me, that the only way to really
switch off a regulator is with regulator_force_disable(), which is quite
a hard hammer.

> You'd end up with the devices all ignoring each other but keeping track
> of when the supply was last enabled and disabled and individually
> keeping timers to make sure that the needed delays are taken care of.
> Userspace would then turn up and read all the devices, they'd then
> do the enables and disables as though they were working alone but
> coordinate through the notifications. If device A powered things up then
> device B would know the power was already on via the notifications and
> when it came on so could take account of that when doing its own delays.

This only works as long as every consumer of the supply is cooperating
(which is my personal use case but doesn't look very future proof). I guess
there has to be some pain for using quirky, unreliable HW... ;)

Thanks for your input, it has been very helpful!

  reply	other threads:[~2016-12-16 13:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-14 14:52 Question about regulator API Harald Geyer
2016-12-14 18:14 ` Mark Brown
2016-12-16 13:41   ` Harald Geyer [this message]
2016-12-16 16:53     ` Mark Brown
2016-12-16 22:00       ` Harald Geyer
2016-12-19 11:09         ` Mark Brown

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=E1cHslb-0000g0-0V@stardust.g4.wien.funkfeuer.at \
    --to=harald@ccbib.org \
    --cc=broonie@kernel.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;
as well as URLs for NNTP newsgroup(s).