Re: Overo broken after recent mainline merge

[Mark Brown <broonie@sirena.org.uk>]

On Sat, Mar 14, 2009 at 02:14:05PM -0700, David Brownell wrote:

> But thinking about how to handle the video support makes
> it clear that's not always the best solution.  One needs
> bootloaders to be able to throw a splash screen which
> stays active until the window system kicks in ... but
> turning off video regulators would clearly blacken the
> screen, which is the wrong model.  (And marking them as
> "always on" or "boot_on" is wrong for other reasons.)

Yes, this sounds like one of those cases where just leaving the
regulator alone and letting the drivers figure things out will probably
work best.

> The way clocks handle that is with a late disable,
> so drivers have a chance to start up.  You rejected

This behaviour is specific to the OMAP implementation of the clock API
(and is an optional feature of that from the looks of it).  It's
probably also worth rembembering that the clock API is working in a very
much more controlled domain (in that it mostly only covers well known
devices on a given architecture), requires little if any per-machine
setup and isn't an optional feature.  Most of the clock API setup is a
feature of the SoC CPU rather than of the board.

> the REGULATOR_DISABLE_UNUSED patch I sent, applying
> that model ... and that's why I started to think about
> other approaches, as in the "early disable" patch I
> sent earlier in this thread.

I didn't reject the concept - I asked for some changes in the interface
to make it be something that the machine drivers can control rather than
have it be a Kconfig option that's selected by end users and can't be
part of the power description that the machine has to have anyway.  As I
said at the time if it were something that could be enabled by the
machine driver, either per regulator or per system, then I'd be happy
with this approach.  I think that it is a better approach than the one
you're currently going for.

Unlike the clock API the machines are going to have to provide some
configuration for the regulators for this feature to be useful (to
specify the supplies that are actually in use) so there is little
additional cost to them in requesting this feature.  If it were only a
Kconfig option then people building the kernel have to know somehow how
well set up the regulators are for their system and some people will end
up with suboptimal configurations because they don't
know if they can turn the option on or not.

> A third approach (after applying that one patch that's
> in the regulator-next tree) would be

> 	if (rdev->is_enabled() > 0)
> 		rdev->use_count = 1;

That won't work with consumers that can share their supply - they can't
tell if the regulator was enabled because it was left on at startup or
if it was enabled by some other consumer.