Re: [PATCH] Input: ads7846: add regulator support

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Fri, Feb 05, 2010 at 10:45:09PM +0200, Mike Rapoport wrote:
> On Thu, Feb 4, 2010 at 6:21 PM, Mark Brown

> > The bodge I'm thinking of would do something like log an error and
> > substitute in a dummy regulator when regulator_get() would have failed
> > so that the driver sees behaviour equivalent to the stubbed regulator
> > API if the bodge is active.  A central thing seems much more sensible
> > here - there's nothing specific to this driver going on here and having
> > the API behave in a consistent manner seems good.

> I agree that such approach have more sense than checking for -ENODEV
> in each and every driver that uses the regulator framework. I just
> wonder, if there should be some mechanism that  can switch the
> substitution of the dummy regulators on and off. And if yes, how
> should the platform code communicate with the regulator core the need
> for such dummy regulators...

So, having thought about this a bit more we actually have two different
use cases here.  One is where you've got a system which has software
controllable regulators for everything but may not have plumbed in all
the supplies, the other is for systems where only a very few supplies
are on software controlled regulators which are just trying to save the
hassle of hooking up the bulk of the supplies to fixed voltage
regulators.  These two use cases should probably be handled differently
- the first one is really expected to have all the supplies hooked up
and so should warn when using the bodge regulator but the warning isn't
helpful in the second case.

We already have some support for boards to set up the API in the form of
regulator_set_full_constraints() so we could do something similar for
dummy regulators, or create a new single API to set a bunch of options
via a struct which is probably less hassle going forward.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html