On 29 May 2014 01:10, Doug Anderson wrote:
> As far as I can tell this notification says "I tried to switch from
> "intermediate_freq" to "policy->restore_freq" but I failed, so I'm
> still at "intermediate_freq". I think you probably want to pass 0 as
> the last argument to
On 29 May 2014 01:10, Doug Anderson diand...@chromium.org wrote:
As far as I can tell this notification says I tried to switch from
intermediate_freq to policy-restore_freq but I failed, so I'm
still at intermediate_freq. I think you probably want to pass 0 as
the last argument to
Viresh,
On Wed, May 21, 2014 at 1:59 AM, Viresh Kumar wrote:
> @@ -1841,9 +1876,23 @@ static int __target_index(struct cpufreq_policy
> *policy,
> pr_err("%s: Failed to change cpu frequency: %d\n", __func__,
>retval);
>
> - if (notify)
> + if
Viresh,
On Wed, May 21, 2014 at 1:59 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
@@ -1841,9 +1876,23 @@ static int __target_index(struct cpufreq_policy
*policy,
pr_err(%s: Failed to change cpu frequency: %d\n, __func__,
retval);
- if
On 23 May 2014 21:26, Stephen Warren wrote:
> Oh OK, I guess the "notify" value is static then, and driver defined, so
> this is fine.
Correct!! Can you reply on the tegra patch also? So that we can close this
thread ASAP?
--
To unsubscribe from this list: send the line "unsubscribe
On 23 May 2014 21:26, Stephen Warren swar...@wwwdotorg.org wrote:
Oh OK, I guess the notify value is static then, and driver defined, so
this is fine.
Correct!! Can you reply on the tegra patch also? So that we can close this
thread ASAP?
--
To unsubscribe from this list: send the line
On 05/22/2014 10:24 PM, Viresh Kumar wrote:
> On 22 May 2014 22:07, Stephen Warren wrote:
>> It seems rather odd to set both freqs->old and freqs->new to the
>> intermediate frequency upon success. It feels like it would make more
>> sense to remove that final else clause above, and do the
On 05/22/2014 10:24 PM, Viresh Kumar wrote:
On 22 May 2014 22:07, Stephen Warren swar...@wwwdotorg.org wrote:
It seems rather odd to set both freqs-old and freqs-new to the
intermediate frequency upon success. It feels like it would make more
sense to remove that final else clause above, and
On 22 May 2014 22:07, Stephen Warren wrote:
> It seems rather odd to set both freqs->old and freqs->new to the
> intermediate frequency upon success. It feels like it would make more
> sense to remove that final else clause above, and do the following where
> this function is called:
>
>
On 05/21/2014 02:59 AM, Viresh Kumar wrote:
> Douglas Anderson, recently pointed out an interesting problem due to which
> udelay() was expiring earlier than it should.
>
> While transitioning between frequencies few platforms may temporarily switch
> to
> a stable frequency, waiting for the
On 05/21/2014 02:59 AM, Viresh Kumar wrote:
Douglas Anderson, recently pointed out an interesting problem due to which
udelay() was expiring earlier than it should.
While transitioning between frequencies few platforms may temporarily switch
to
a stable frequency, waiting for the main PLL
On 22 May 2014 22:07, Stephen Warren swar...@wwwdotorg.org wrote:
It seems rather odd to set both freqs-old and freqs-new to the
intermediate frequency upon success. It feels like it would make more
sense to remove that final else clause above, and do the following where
this function is
Douglas Anderson, recently pointed out an interesting problem due to which
udelay() was expiring earlier than it should.
While transitioning between frequencies few platforms may temporarily switch to
a stable frequency, waiting for the main PLL to stabilize.
For example: When we transition
Douglas Anderson, recently pointed out an interesting problem due to which
udelay() was expiring earlier than it should.
While transitioning between frequencies few platforms may temporarily switch to
a stable frequency, waiting for the main PLL to stabilize.
For example: When we transition
14 matches
Mail list logo
