V3
--
Fix type where data argument was not passed in
blocking_notifier_call_chain.
edits to check in comments (below)
V2
--
Incorporate performance suggestions made by Mark Brown
Use linux-next as base code rather than mmc-next
The voltage being set should be passed to the call in handler
requesting the callback. Currently this is not done.
The callin handler cannot call regulator_get_voltage() to get the
information since the mutex is held by the regulator and
deadlock occurs.
Without this change the receiver of the call in cannot know what
action to take. This is used, for example, to set PAD voltages
when doing SD vccq voltage changes.
Signed-off-by: Philip Rakity <[email protected]>
---
drivers/regulator/core.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 63507a5..cdf6905 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2153,7 +2153,7 @@ static int _regulator_do_set_voltage(struct regulator_dev *rdev,
if (rdev->desc->ops->list_voltage)
best_val = rdev->desc->ops->list_voltage(rdev, selector);
else
- best_val = -1;
+ best_val = _regulator_get_voltage(rdev);
/* Call set_voltage_time_sel if successfully obtained old_selector */
if (_regulator_is_enabled(rdev) && ret == 0 && old_selector >= 0 &&
@@ -2176,9 +2176,9 @@ static int _regulator_do_set_voltage(struct regulator_dev *rdev,
udelay(delay);
}
- if (ret == 0)
+ if (ret == 0 && best_val >= 0)
_notifier_call_chain(rdev, REGULATOR_EVENT_VOLTAGE_CHANGE,
- NULL);
+ (void *)best_val);
trace_regulator_set_voltage_complete(rdev_get_name(rdev), best_val);
@@ -2692,7 +2692,7 @@ static void _notifier_call_chain(struct regulator_dev *rdev,
unsigned long event, void *data)
{
/* call rdev chain first */
- blocking_notifier_call_chain(&rdev->notifier, event, NULL);
+ blocking_notifier_call_chain(&rdev->notifier, event, data);
}
/**
--
1.7.0.4
On Jun 15, 2012, at 10:58 AM, Pankaj Jangra wrote:
> Hi Philip,
>
> Just a cosmetic comments.
>
> On Fri, Jun 15, 2012 at 3:36 AM, Philip Rakity <[email protected]> wrote:
> V2
> --
>
> Incorporate performance suggestions made by Mark Brown
> Use linux-next as base code rather than mmc-next
>
> The voltage being set should be passed to the handler requesting
> the callback. Currently this is not done.
thanks -- my typo when redoing the patch -- V3 has this fixed.
>
> The callback cannot call regulator_get_voltage() to get the
> information since the mutex is held by the regulator and
> deadlock occurs.
>
> Without this change the receiver of the notify cannot now what
>
> You mean to say "cannot know what" ?
>
> action to take. This is used, for example, to set PAD voltages
> when doing SD vccq voltage changes.
if you call in that receives the notify does not know the new voltage
then in our case we do not know if we should switch the pad from
3.3v to 1.8v for example. vccq signaling in SD is normally 3.3V
but in UHS mode it is lowered to 1.8V
>
> Signed-off-by: Philip Rakity <[email protected]>
> ---
> drivers/regulator/core.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 63507a5..5b04916 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -2153,7 +2153,7 @@ static int _regulator_do_set_voltage(struct regulator_dev *rdev,
> if (rdev->desc->ops->list_voltage)
> best_val = rdev->desc->ops->list_voltage(rdev, selector);
> else
> - best_val = -1;
> + best_val = _regulator_get_voltage(rdev);
>
> /* Call set_voltage_time_sel if successfully obtained old_selector */
> if (_regulator_is_enabled(rdev) && ret == 0 && old_selector >= 0 &&
> @@ -2176,9 +2176,9 @@ static int _regulator_do_set_voltage(struct regulator_dev *rdev,
> udelay(delay);
> }
>
> - if (ret == 0)
> + if (ret == 0 && best_val >= 0)
> _notifier_call_chain(rdev, REGULATOR_EVENT_VOLTAGE_CHANGE,
> - NULL);
> + (void *)best_val);
>
>
> I am also curious to know if you pass the voltage here to notifier call how does it make any difference, since in
> blocking_notifier_call_chain() again passes the NULL. So does your patch should modify the arguments to this function also?
> Please let me know if i am missing something in understanding.
>
> Regards,
> Pankaj Jangra
>
> trace_regulator_set_voltage_complete(rdev_get_name(rdev), best_val);
>
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hi,
On Fri, Jun 15, 2012 at 11:59 PM, Philip Rakity <[email protected]> wrote:
>
> On Jun 15, 2012, at 10:58 AM, Pankaj Jangra wrote:
>
>> Hi Philip,
>>
>> Just a cosmetic comments.
>>
>> On Fri, Jun 15, 2012 at 3:36 AM, Philip Rakity <[email protected]> wrote:
>> V2
>> --
>>
>> Incorporate performance suggestions made by Mark Brown
>> Use linux-next as base code rather than mmc-next
>>
>> The voltage being set should be passed to the handler requesting
>> the callback. ?Currently this is not done.
>
> thanks -- my typo when redoing the patch -- V3 has this fixed.
>
>>
>> The callback cannot call regulator_get_voltage() to get the
>> information since the mutex is held by the regulator and
>> deadlock occurs.
>>
>> Without this change the receiver of the notify cannot now what
>>
>> You mean to say "cannot know what" ?
>>
>> action to take. ?This is used, for example, to set PAD voltages
>> when doing SD vccq voltage changes.
>
>
> if you call in that receives the notify does not know the new voltage
> then in our case we do not know if we should switch the pad from
> 3.3v to 1.8v for example. ?vccq signaling in SD is normally 3.3V
> but in UHS mode it is lowered to 1.8V
>
Yes right. So that means we need to make change in
blocking_notifier_call_chain() too in order to send the voltage back?
Regards,
Pankaj Jangra
Hi,
On Fri, Jun 15, 2012 at 11:57 PM, Philip Rakity
<[email protected]> wrote:
> V3
> --
>
> Fix type where data argument was not passed in
> blocking_notifier_call_chain.
>
> edits to check in comments (below)
>
> V2
> --
>
> Incorporate performance suggestions made by Mark Brown
> Use linux-next as base code rather than mmc-next
>
> The voltage being set should be passed to the call in handler
> requesting the callback. ?Currently this is not done.
>
> The callin handler cannot call regulator_get_voltage() to get the
"The calling"
> information since the mutex is held by the regulator and
> deadlock occurs.
>
> Without this change the receiver of the call in cannot know what
> action to take. ?This is used, for example, to set PAD voltages
> when doing SD vccq voltage changes.
>
> Signed-off-by: Philip Rakity <[email protected]>
> ---
Since you are submitting your patch from the different email than your
Singed-off email. So you should put in first line of message
From: <your real email>.
Regards,
Pankaj Jangra
On Jun 15, 2012, at 11:50 AM, Pankaj Jangra wrote:
> Hi,
>
> On Fri, Jun 15, 2012 at 11:57 PM, Philip Rakity
> <[email protected]> wrote:
>> V3
>> --
>>
>> Fix type where data argument was not passed in
>> blocking_notifier_call_chain.
>>
>> edits to check in comments (below)
>>
>> V2
>> --
>>
>> Incorporate performance suggestions made by Mark Brown
>> Use linux-next as base code rather than mmc-next
>>
>> The voltage being set should be passed to the call in handler
>> requesting the callback. Currently this is not done.
>>
>> The callin handler cannot call regulator_get_voltage() to get the
>
> "The calling"
I am not sure what the correct term for this. The blocking_notifier_call_chain calls
what ? calling might imply blocking_notifier_call_chain() since it is doing the calling.
What is the receiver of the call named ?
>
>> information since the mutex is held by the regulator and
>> deadlock occurs.
>>
>> Without this change the receiver of the call in cannot know what
>> action to take. This is used, for example, to set PAD voltages
>> when doing SD vccq voltage changes.
>>
>> Signed-off-by: Philip Rakity <[email protected]>
>> ---
>
> Since you are submitting your patch from the different email than your
> Singed-off email. So you should put in first line of message
> From: <your real email>.
>
> Regards,
> Pankaj Jangra
Hi,
On Sat, Jun 16, 2012 at 12:48 AM, Philip Rakity <[email protected]> wrote:
>
> On Jun 15, 2012, at 11:50 AM, Pankaj Jangra wrote:
>
>> Hi,
>>
>> On Fri, Jun 15, 2012 at 11:57 PM, Philip Rakity
>> <[email protected]> wrote:
>>> V3
>>> --
>>>
>>>
>>> The callin handler cannot call regulator_get_voltage() to get the
>>
>> "The calling"
>
> I am not sure what the correct term for this. ?The blocking_notifier_call_chain calls
> what ? ? calling might imply blocking_notifier_call_chain() since it is doing the calling.
> What is the receiver of the call named ?
>
I was trying to bring up the spelling typo s/callin/calling though
Regards,
Pankaj Jangra
On Fri, Jun 15, 2012 at 11:27:36AM -0700, Philip Rakity wrote:
> V3
> --
Applied, thanks (though this changelog should've come in the --- after
the main changelog rather than before so it didn't appear in the
changelog). I made the spelling fix Pankaj pointed out as well.