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 cpufreq_freq_transiti
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 (
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 linux-kernel"
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 followi
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:
>
> i
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
6 matches
Mail list logo
