On Wed, Mar 18, 2009 at 12:25:11PM -0700, David Brownell wrote:
> On Tuesday 17 March 2009, Mark Brown wrote:
> > The drivers can essentially ignore the physical status of the regulator
> > when they start,
> That is, shared supplies should adopt a different model?
I think that's a bit strong, once we get past init the problem pretty
much goes away AFAICT.
> That approach can't be used with drivers, as for MMC slots,
> which need to ensure they start with a "power off" state as
> part of a clean reset/init sequence.
Pretty much. They could cope if they used the enable/disable bounce
hack but if they urgently need to have a specific power state they won't
be able to cope with shared regulators anyway so it doesn't really make
any odds.
> Maybe "sharable" should be a regulator constraint flag, so
> the regulator framework can avoid committing nastiness like
> allocating multiple consumer handles for them.
Or vice versa - it's as much a property of the consumer driver that it
requires exclusivity. From the point of view of the regulator API
there's very little difference between the two cases.
Note that for well behaved consumers that use mapped supply names we
already know about them all in advance anyway...
> > It will also work well with a
> > late_initcall which disables any unreferenced regulators -
> The $SUBJECT patch will prevent such things from existing.
I sent a patch backing that specific change out along with the
late_initcall() patch.
> Also, regulator use that kicks in before that particular
> late_initcall will still see self-inconsistent state in
> the regulator framework ... of course, $SUBJECT patch (and
> its predecessors) is all about preventing self-inconsistency.
A driver that can cope with sharing the regulator is not going to be
able to observe anything here: it must always enable the regulator when
it is using it even if it is already enabled (since otherwise some other
consumer could cause it to be turned off) and it should expect that the
regulator might be enabled by something else. It can't do an unbalanced
disable since otherwise it could be reversing an enable something else
did. It's also not possible for it to inspect the use count.
If a consumer can't play with that model then I'm reasonably happy with
it having to state any additional requirements it has in some way - if
nothing else it gives us a bit of documentation about what's going on.
> That self-inconsistency doesn't seem to concern you much.
I think it's more that I'm viewing the use count as being useful
information which the API can take advantage of ("do any consumers
actually want this on right now?"). I think we should be able to handle
this without changing the use count and that this is preferable because
otherwise we make more work with shared consumers, which should be the
simplest case.
The trick is getting the non-shared regulators into sync with the
internal status, ideally without doing things like bouncing supplies
during init. I think either using regulator_force_disable() or saying
that the consmer wants exclusive access on get and then bumping the use
count for it if the regulator is already enabled ought to cover it.
I've not thought the latter option through fully, though.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
