On 19/10/15 09:33, Jon Medhurst (Tixy) wrote:
On Wed, 2015-10-14 at 09:48 +0100, Sudeep Holla wrote:
[...]
OK, I understand what you mean now. I don't have a strong opinion, but
here is the reason why I prefer the approach I said earlier:
clk_set_rate doesn't return error if the h/w or
On Wed, 2015-10-14 at 09:48 +0100, Sudeep Holla wrote:
>
> On 14/10/15 08:12, Jon Medhurst (Tixy) wrote:
> > On Tue, 2015-10-13 at 11:36 +0100, Sudeep Holla wrote:
> >>
> >> On 13/10/15 08:19, Jon Medhurst (Tixy) wrote:
> > [...]
> >>> But then we wouldn't get the WARN_ON and pr_err triggered
On Wed, 2015-10-14 at 09:48 +0100, Sudeep Holla wrote:
>
> On 14/10/15 08:12, Jon Medhurst (Tixy) wrote:
> > On Tue, 2015-10-13 at 11:36 +0100, Sudeep Holla wrote:
> >>
> >> On 13/10/15 08:19, Jon Medhurst (Tixy) wrote:
> > [...]
> >>> But then we wouldn't get the WARN_ON and pr_err triggered
On 19/10/15 09:33, Jon Medhurst (Tixy) wrote:
On Wed, 2015-10-14 at 09:48 +0100, Sudeep Holla wrote:
[...]
OK, I understand what you mean now. I don't have a strong opinion, but
here is the reason why I prefer the approach I said earlier:
clk_set_rate doesn't return error if the h/w or
On 14/10/15 08:12, Jon Medhurst (Tixy) wrote:
On Tue, 2015-10-13 at 11:36 +0100, Sudeep Holla wrote:
On 13/10/15 08:19, Jon Medhurst (Tixy) wrote:
[...]
But then we wouldn't get the WARN_ON and pr_err triggered when we detect
the clock rate isn't set, which surely is half the reason for
On Tue, 2015-10-13 at 11:36 +0100, Sudeep Holla wrote:
>
> On 13/10/15 08:19, Jon Medhurst (Tixy) wrote:
[...]
> > But then we wouldn't get the WARN_ON and pr_err triggered when we detect
> > the clock rate isn't set, which surely is half the reason for the check
> > in the first place?
> >
>
>
On Tue, 2015-10-13 at 11:36 +0100, Sudeep Holla wrote:
>
> On 13/10/15 08:19, Jon Medhurst (Tixy) wrote:
[...]
> > But then we wouldn't get the WARN_ON and pr_err triggered when we detect
> > the clock rate isn't set, which surely is half the reason for the check
> > in the first place?
> >
>
>
On 14/10/15 08:12, Jon Medhurst (Tixy) wrote:
On Tue, 2015-10-13 at 11:36 +0100, Sudeep Holla wrote:
On 13/10/15 08:19, Jon Medhurst (Tixy) wrote:
[...]
But then we wouldn't get the WARN_ON and pr_err triggered when we detect
the clock rate isn't set, which surely is half the reason for
On 13/10/15 08:19, Jon Medhurst (Tixy) wrote:
On Mon, 2015-10-12 at 14:20 +0100, Sudeep Holla wrote:
On 08/10/15 10:23, Jon Medhurst (Tixy) wrote:
[...]
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index f1e42f8..59115a4 100644
---
On Mon, 2015-10-12 at 14:20 +0100, Sudeep Holla wrote:
>
> On 08/10/15 10:23, Jon Medhurst (Tixy) wrote:
> [...]
>
> > diff --git a/drivers/cpufreq/arm_big_little.c
> > b/drivers/cpufreq/arm_big_little.c
> > index f1e42f8..59115a4 100644
> > --- a/drivers/cpufreq/arm_big_little.c
> > +++
On Mon, 2015-10-12 at 14:20 +0100, Sudeep Holla wrote:
>
> On 08/10/15 10:23, Jon Medhurst (Tixy) wrote:
> [...]
>
> > diff --git a/drivers/cpufreq/arm_big_little.c
> > b/drivers/cpufreq/arm_big_little.c
> > index f1e42f8..59115a4 100644
> > --- a/drivers/cpufreq/arm_big_little.c
> > +++
On 13/10/15 08:19, Jon Medhurst (Tixy) wrote:
On Mon, 2015-10-12 at 14:20 +0100, Sudeep Holla wrote:
On 08/10/15 10:23, Jon Medhurst (Tixy) wrote:
[...]
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index f1e42f8..59115a4 100644
---
On 08/10/15 10:23, Jon Medhurst (Tixy) wrote:
[...]
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index f1e42f8..59115a4 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -149,6 +149,18 @@ bL_cpufreq_set_rate(u32 cpu,
On 08/10/15 10:23, Jon Medhurst (Tixy) wrote:
[...]
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index f1e42f8..59115a4 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -149,6 +149,18 @@ bL_cpufreq_set_rate(u32 cpu,
On 08/10/15 13:55, Jon Medhurst (Tixy) wrote:
On Thu, 2015-10-08 at 16:54 +0530, Viresh Kumar wrote:
On 08-10-15, 10:23, Jon Medhurst (Tixy) wrote:
On Wed, 2015-10-07 at 23:09 +0530, Viresh Kumar wrote:
[...]
You are right, I had misread the code. I guess my problem is that I'm
actually
On 08-10-15, 13:55, Jon Medhurst (Tixy) wrote:
> Looking a bit more carefully, the reason your fix doesn't work is that
> bL_cpufreq_get_rate returns the last requested rate for this CPU,
> whereas target_rate/new_rate is the maximum rate requested by any CPU on
> the cluster (which is what we
On Thu, 2015-10-08 at 16:54 +0530, Viresh Kumar wrote:
> On 08-10-15, 10:23, Jon Medhurst (Tixy) wrote:
> > On Wed, 2015-10-07 at 23:09 +0530, Viresh Kumar wrote:
[...]
> > > @@ -140,9 +140,11 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32
> > > new_cluster, u32 rate)
> > >
On 08-10-15, 10:23, Jon Medhurst (Tixy) wrote:
> On Wed, 2015-10-07 at 23:09 +0530, Viresh Kumar wrote:
> [...]
> > And why not fix it properly by doing this:
> >
> > diff --git a/drivers/cpufreq/arm_big_little.c
> > b/drivers/cpufreq/arm_big_little.c
> > index f1e42f8ce0fc..5b36657a76d6 100644
On Wed, 2015-10-07 at 23:09 +0530, Viresh Kumar wrote:
[...]
> And why not fix it properly by doing this:
>
> diff --git a/drivers/cpufreq/arm_big_little.c
> b/drivers/cpufreq/arm_big_little.c
> index f1e42f8ce0fc..5b36657a76d6 100644
> --- a/drivers/cpufreq/arm_big_little.c
> +++
On Wed, 2015-10-07 at 23:09 +0530, Viresh Kumar wrote:
[...]
> And why not fix it properly by doing this:
>
> diff --git a/drivers/cpufreq/arm_big_little.c
> b/drivers/cpufreq/arm_big_little.c
> index f1e42f8ce0fc..5b36657a76d6 100644
> --- a/drivers/cpufreq/arm_big_little.c
> +++
On 08-10-15, 10:23, Jon Medhurst (Tixy) wrote:
> On Wed, 2015-10-07 at 23:09 +0530, Viresh Kumar wrote:
> [...]
> > And why not fix it properly by doing this:
> >
> > diff --git a/drivers/cpufreq/arm_big_little.c
> > b/drivers/cpufreq/arm_big_little.c
> > index f1e42f8ce0fc..5b36657a76d6 100644
On Thu, 2015-10-08 at 16:54 +0530, Viresh Kumar wrote:
> On 08-10-15, 10:23, Jon Medhurst (Tixy) wrote:
> > On Wed, 2015-10-07 at 23:09 +0530, Viresh Kumar wrote:
[...]
> > > @@ -140,9 +140,11 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32
> > > new_cluster, u32 rate)
> > >
On 08-10-15, 13:55, Jon Medhurst (Tixy) wrote:
> Looking a bit more carefully, the reason your fix doesn't work is that
> bL_cpufreq_get_rate returns the last requested rate for this CPU,
> whereas target_rate/new_rate is the maximum rate requested by any CPU on
> the cluster (which is what we
On 08/10/15 13:55, Jon Medhurst (Tixy) wrote:
On Thu, 2015-10-08 at 16:54 +0530, Viresh Kumar wrote:
On 08-10-15, 10:23, Jon Medhurst (Tixy) wrote:
On Wed, 2015-10-07 at 23:09 +0530, Viresh Kumar wrote:
[...]
You are right, I had misread the code. I guess my problem is that I'm
actually
On 02-10-15, 18:38, Jon Medhurst (Tixy) wrote:
> The check for correct frequency being set in bL_cpufreq_set_rate is
> broken when the big.LITTLE switcher is active, for two reasons.
>
> 1. The 'new_rate' variable gets overwritten before the test by the
> code calculating the frequency of the old
On 02-10-15, 18:38, Jon Medhurst (Tixy) wrote:
> The check for correct frequency being set in bL_cpufreq_set_rate is
> broken when the big.LITTLE switcher is active, for two reasons.
>
> 1. The 'new_rate' variable gets overwritten before the test by the
> code calculating the frequency of the old
The check for correct frequency being set in bL_cpufreq_set_rate is
broken when the big.LITTLE switcher is active, for two reasons.
1. The 'new_rate' variable gets overwritten before the test by the
code calculating the frequency of the old cluster.
2. The frequency returned by
The check for correct frequency being set in bL_cpufreq_set_rate is
broken when the big.LITTLE switcher is active, for two reasons.
1. The 'new_rate' variable gets overwritten before the test by the
code calculating the frequency of the old cluster.
2. The frequency returned by
28 matches
Mail list logo