> > OK, the consumer just cares about the regulator(s) which is(are)
> obtained.
> > However it doesn't show exact state of regulator in case that enable
> GPIOs are
> > shared.
>
> It would do if my suggestion that we use a shared state for the GPIO
> were implemented!
>
> > (6) CB tries to get
On Mon, Jan 14, 2013 at 02:44:08AM +, Kim, Milo wrote:
> > So, clearly that's going to be the behaviour at the system level but
> > the
> > consumers aren't going to know that. If the consumer supports some of
> > the supplies being enabled and disabled separately then it will rely on
> > the
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
>
> So, clearly that's going to be the behaviour at the system level but
> the
> consumers aren't going to know that. If the consumer supports some of
> the supplies being enabled and disabled separately then it will rely on
> the re
On Sun, Jan 13, 2013 at 11:35:03PM +, Kim, Milo wrote:
> Thanks for your opinion.
> My understanding is 'shared' enable pin means regulators are enabled/disabled
> at the same time.
> Any other case is possible?
So, clearly that's going to be the behaviour at the system level but the
consumer
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
>
> This isn't quite going to work properly - we need to actually move the
> state (and also a reference count) into some sort of shared state.
> Otherwise consider what happens in this scenario:
>
> 1. regulator 1 enables
>
On Thu, Jan 10, 2013 at 09:46:12AM +, Kim, Milo wrote:
> + /* Update shared enable pin state */
> + list_for_each_entry(r, ®ulator_list, list) {
> + if (r->ena_gpio == gpio)
> + r->ena_gpio_state = enable ? 1 : 0;
> + }
> +}
This isn't quite going t
When a regulator is enabled or disabled, enable GPIO state is changed if it is
used.
If multiple regulators are controlled by one shared GPIO, pin states of other
GPIOs should be updated also.
Look up the list of regulators and change the enable pin state if same GPIO
is used. It guarantees
7 matches
Mail list logo
