Mark,
On Wed, Mar 4, 2015 at 3:27 AM, Mark Brown wrote:
> On Tue, Mar 03, 2015 at 03:21:21PM -0800, Doug Anderson wrote:
>
>> It looks as if "ena_gpio_state" is not quite what I thought it was and
>> I think is not actually consistent in the regulator framework itself.
>> In _regulator_do_enable(
On Tue, Mar 03, 2015 at 03:21:21PM -0800, Doug Anderson wrote:
> It looks as if "ena_gpio_state" is not quite what I thought it was and
> I think is not actually consistent in the regulator framework itself.
> In _regulator_do_enable() and _regulator_do_disable() is clear that
> ena_gpio_state is
Hi,
On Tue, Mar 3, 2015 at 6:23 AM, Mark Brown wrote:
>> My assumption is that regulator drivers themselves shouldn't do
>> reference counting. That is: if you call
>> rdev->desc->ops->enable(rdev) twice you should not have to call
>> rdev->desc->ops->disable(rdev) twice to disable. Right? Tha
On Mon, Mar 02, 2015 at 09:21:45PM +0100, Javier Martinez Canillas wrote:
> On 03/02/2015 07:57 PM, Mark Brown wrote:
> > a specific per client count here... I've not looked at the code and I
> Sorry, I'm not sure I understood what you meant. The suspend path:
We need to check if this specific
On Mon, Mar 02, 2015 at 01:13:56PM -0800, Doug Anderson wrote:
> On Mon, Mar 2, 2015 at 10:47 AM, Mark Brown wrote:
> > Looking at the code it seems that you're adding checks to skip calls in
> > the standard enable and disable paths but not touching other paths,
> > based on this patch by itself
Mark,
On Mon, Mar 2, 2015 at 10:47 AM, Mark Brown wrote:
> On Fri, Feb 27, 2015 at 11:41:03AM -0800, Doug Anderson wrote:
>> It is possible for _regulator_do_enable() to be called for an
>> already-enabled rdev, like in regulator_suspend_finish(). If we were
>> using an enable pin (rdev->ena_pin
Hello Mark,
On 03/02/2015 07:57 PM, Mark Brown wrote:
> On Fri, Feb 27, 2015 at 10:01:23PM +0100, Javier Martinez Canillas wrote:
>
>> I noticed the same problem in regulator_suspend_finish() when I was working
>> on S2R for Exynos a couple of months ago and had patch [0] on my local tree
>> but
On Fri, Feb 27, 2015 at 10:01:23PM +0100, Javier Martinez Canillas wrote:
> I noticed the same problem in regulator_suspend_finish() when I was working
> on S2R for Exynos a couple of months ago and had patch [0] on my local tree
> but never found the time to do extensive testing so I never posted
On Fri, Feb 27, 2015 at 11:41:03AM -0800, Doug Anderson wrote:
> It is possible for _regulator_do_enable() to be called for an
> already-enabled rdev, like in regulator_suspend_finish(). If we were
> using an enable pin (rdev->ena_pin is set) then we'd end up
> incrementing the reference count in
Hello Doug,
On 02/27/2015 08:41 PM, Doug Anderson wrote:
> It is possible for _regulator_do_enable() to be called for an
> already-enabled rdev, like in regulator_suspend_finish(). If we were
> using an enable pin (rdev->ena_pin is set) then we'd end up
> incrementing the reference count in regul
On Fri, Feb 27, 2015 at 11:41:03AM -0800, Doug Anderson wrote:
> It is possible for _regulator_do_enable() to be called for an
> already-enabled rdev, like in regulator_suspend_finish(). If we were
> using an enable pin (rdev->ena_pin is set) then we'd end up
> incrementing the reference count in
It is possible for _regulator_do_enable() to be called for an
already-enabled rdev, like in regulator_suspend_finish(). If we were
using an enable pin (rdev->ena_pin is set) then we'd end up
incrementing the reference count in regulator_ena_gpio_ctrl() over and
over again without a decrement. Tha
12 matches
Mail list logo
