[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <516BE5AE.3020703@stericsson.com>
Date: Mon, 15 Apr 2013 13:34:06 +0200
From: Bengt Jönsson <bengt.g.jonsson@...ricsson.com>
To: Axel Lin <axel.lin@...ics.com>
Cc: Mark Brown <broonie@...nsource.wolfsonmicro.com>,
Lee Jones <lee.jones@...aro.org>,
Yvan FILLION <yvan.fillion@...ricsson.com>,
Liam Girdwood <lgirdwood@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] regulator: ab8500: Fix get_mode for shared mode regulators
On 04/15/2013 10:50 AM, Axel Lin wrote:
>> My understanding is for shared mode regulators:
>> It can be in LP mode only when *BOTH* are in LP mode.
>> If only one of the regulator in HP mode, then *BOTH* should be in HP mode.
>> Did I misunderstand something?
Your understanding is correct.
> Let me put this issue this way:
>
> Current code behavior:
> get_mode() returns IDLE if only one lp_mode_req flag is true, but mode
> register value is HP.
>
> AB8540_LDO_ANAMIC1 AB8540_LDO_ANAMIC2 mode register
> get_mode() returns
> lp_mode_req=true lp_mode_req=true HP
> REGULATOR_MODE_NORMAL
> lp_mode_req=true lp_mode_req=false HP
> REGULATOR_MODE_IDLE
> lp_mode_req=false lp_mode_req=true HP
> REGULATOR_MODE_IDLE
> lp_mode_req=false lp_mode_req=false LP
> REGULATOR_MODE_IDLE
I think it looks like this:
AB8540_LDO_ANAMIC1 AB8540_LDO_ANAMIC2 mode register
get_mode() returns
lp_mode_req=true lp_mode_req=true LP
REGULATOR_MODE_IDLE REGULATOR_MODE_IDLE
lp_mode_req=true lp_mode_req=false HP
REGULATOR_MODE_IDLE REGULATOR_MODE_NORMAL
lp_mode_req=false lp_mode_req=true HP
REGULATOR_MODE_NORMAL REGULATOR_MODE_IDLE
lp_mode_req=false lp_mode_req=false HP
REGULATOR_MODE_NORMAL REGULATOR_MODE_NORMAL
> with this path:
> mode register value is consistent with get_mode().
>
> AB8540_LDO_ANAMIC1 AB8540_LDO_ANAMIC2 mode register
> get_mode() returns
> lp_mode_req=true lp_mode_req=true HP
> REGULATOR_MODE_NORMAL
> lp_mode_req=true lp_mode_req=false HP
> REGULATOR_MODE_NORMAL
> lp_mode_req=false lp_mode_req=true HP
> REGULATOR_MODE_NORMAL
> lp_mode_req=false lp_mode_req=false LP
> REGULATOR_MODE_IDLE
And like this:
AB8540_LDO_ANAMIC1 AB8540_LDO_ANAMIC2 mode register
get_mode() returns
lp_mode_req=true lp_mode_req=true LP
REGULATOR_MODE_IDLE REGULATOR_MODE_IDLE
lp_mode_req=true lp_mode_req=false HP
REGULATOR_MODE_NORMAL REGULATOR_MODE_NORMAL
lp_mode_req=false lp_mode_req=true HP
REGULATOR_MODE_NORMAL REGULATOR_MODE_NORMAL
lp_mode_req=false lp_mode_req=false HP
REGULATOR_MODE_NORMAL REGULATOR_MODE_NORMAL
I guess what you don't like with the current approach is that the driver returns REGULATOR_MODE_IDLE in some cases where the mode register is set to LP. But I think, with patch applied, the control may be wrong in some cases because the regulator framework will call get_mode and see that the mode is already correct and not call set_mode so lp_mode_req will not get updated. I realised my previous example was incorrect so here I describe another example:
0. Start condition:
ANAMIC1 is requested in LP mode (lp_mode_req=true) and ANAMIC2 is requested in HP mode (lp_mode_req=false).
So the mode register is set to HP.
1. Now ANAMIC1 is requested to HP mode from consumer side. The regulator framework checks the current mode with get_mode which returns HP. So the regulator framework returns without calling set_mode because the mode is already correct.
For ANAMIC1 lp_mode_req=true and for ANAMIC2 lp_mode_req=false (still).
The mode register will be correct at HP.
2. If ANAMIC2 is now requested to LP mode from consumer side, the regulator framework calls get_mode which returns HP, so the framework calls set_mode.
In set_mode, the function checks the other regulator's status which is lp_mode_req=true. So the function will continue and set the regulator in LP mode even if it should not be.
Bengt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists