| Message ID | c70729588f2f21d10fa5d53e5189890af4248a93.1376116345.git.viresh.kumar@linaro.org |
|---|---|
| State | New |
| Headers | show |
Around Sat 10 Aug 2013 12:14:07 +0530 or thereabout, Viresh Kumar wrote: > Most of the CPUFreq drivers do similar things in .exit() and .verify() routines > and .attr. So its better if we have generic routines for them which can be used > by cpufreq drivers then. > > This patch uses these generic routines for this driver. Nice, thanks for cleaning up (-: > Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> > --- > drivers/cpufreq/at32ap-cpufreq.c | 12 +----------- > 1 file changed, 1 insertion(+), 11 deletions(-) <snipp diff>
On 10 August 2013 13:53, Hans-Christian Egtvedt <egtvedt@samfundet.no> wrote: > Around Sat 10 Aug 2013 12:14:07 +0530 or thereabout, Viresh Kumar wrote: >> Most of the CPUFreq drivers do similar things in .exit() and .verify() routines >> and .attr. So its better if we have generic routines for them which can be used >> by cpufreq drivers then. >> >> This patch uses these generic routines for this driver. > > Nice, thanks for cleaning up (-: > >> Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no> >> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > > Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Thanks for your Ack but I have to NACK it :) My patch was wrong.. It was based on the assumption that everybody who had implemented a .target() also implements a frequency table and exposes it.. And the generic routines I have exposed depend on that frequency table. And this cpufreq driver doesn't expose that freq table... And so this patch is dropped :( -- viresh
Around Mon 12 Aug 2013 11:37:45 +0530 or thereabout, Viresh Kumar wrote: > On 10 August 2013 13:53, Hans-Christian Egtvedt <egtvedt@samfundet.no> wrote: >> Around Sat 10 Aug 2013 12:14:07 +0530 or thereabout, Viresh Kumar wrote: >>> Most of the CPUFreq drivers do similar things in .exit() and .verify() routines >>> and .attr. So its better if we have generic routines for them which can be used >>> by cpufreq drivers then. >>> >>> This patch uses these generic routines for this driver. >> >> Nice, thanks for cleaning up (-: >> >>> Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no> >>> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> >> >> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> > > Thanks for your Ack but I have to NACK it :) > > My patch was wrong.. It was based on the assumption that everybody who > had implemented a .target() also implements a frequency table and exposes > it.. And the generic routines I have exposed depend on that frequency table. > And this cpufreq driver doesn't expose that freq table... Right, my bad, I just looked at the code flow and saw that the generic path did pretty much the same as the AVR32 implementation. Didn't consider the table part as missing. > And so this patch is dropped :( > Ok, AVR32 driver should expose a frequency table then, which is quite simple.
On 12 August 2013 12:40, Hans-Christian Egtvedt <egtvedt@samfundet.no> wrote:
> Ok, AVR32 driver should expose a frequency table then, which is quite simple.
It would be really nice if you can provide that patch, that will make
my life simple :)
I thought I can get a table for it but wasn't able to find out
necessary information
for that.
Around Mon 12 Aug 2013 12:43:37 +0530 or thereabout, Viresh Kumar wrote: > On 12 August 2013 12:40, Hans-Christian Egtvedt <egtvedt@samfundet.no> wrote: >> Ok, AVR32 driver should expose a frequency table then, which is quite simple. > > It would be really nice if you can provide that patch, that will make > my life simple :) > > I thought I can get a table for it but wasn't able to find out > necessary information > for that. I'll add it on my todo-list and have a look at it in the evening (-: How hard can it be™
On 12 August 2013 13:00, Hans-Christian Egtvedt <egtvedt@samfundet.no> wrote: > I'll add it on my todo-list and have a look at it in the evening (-: Thanks. > How hard can it be™ Its not about being hard but about knowing your platform well..
Around Mon 12 Aug 2013 13:09:25 +0530 or thereabout, Viresh Kumar wrote: > On 12 August 2013 13:00, Hans-Christian Egtvedt <egtvedt@samfundet.no> wrote: >> I'll add it on my todo-list and have a look at it in the evening (-: > > Thanks. > >> How hard can it be™ > > Its not about being hard but about knowing your platform well.. Turned out to be quite easy, but I couldn't get around to test it on hardware (excuse: just moved, all HW is still in a box somewhere). I'll submit the patch to cpufreq@vger.kernel.org for a sanity check, perhaps you'll pull it into your series?
On 13 August 2013 00:41, Hans-Christian Egtvedt <egtvedt@samfundet.no> wrote: > Around Mon 12 Aug 2013 13:09:25 +0530 or thereabout, Viresh Kumar wrote: >> On 12 August 2013 13:00, Hans-Christian Egtvedt <egtvedt@samfundet.no> wrote: >>> I'll add it on my todo-list and have a look at it in the evening (-: >> >> Thanks. >> >>> How hard can it be™ >> >> Its not about being hard but about knowing your platform well.. > > Turned out to be quite easy, but I couldn't get around to test it on > hardware (excuse: just moved, all HW is still in a box somewhere). I had a quick look at it and yes it is pretty much hadware specific :) Thanks. > I'll submit the patch to cpufreq@vger.kernel.org for a sanity check, perhaps > you'll pull it into your series? Yes, I will.
diff --git a/drivers/cpufreq/at32ap-cpufreq.c b/drivers/cpufreq/at32ap-cpufreq.c index e0c38d9..b27f750 100644 --- a/drivers/cpufreq/at32ap-cpufreq.c +++ b/drivers/cpufreq/at32ap-cpufreq.c @@ -22,16 +22,6 @@ static struct clk *cpuclk; -static int at32_verify_speed(struct cpufreq_policy *policy) -{ - if (policy->cpu != 0) - return -EINVAL; - - cpufreq_verify_within_limits(policy, policy->cpuinfo.min_freq, - policy->cpuinfo.max_freq); - return 0; -} - static unsigned int at32_get_speed(unsigned int cpu) { /* No SMP support */ @@ -109,7 +99,7 @@ static int __init at32_cpufreq_driver_init(struct cpufreq_policy *policy) static struct cpufreq_driver at32_driver = { .name = "at32ap", .init = at32_cpufreq_driver_init, - .verify = at32_verify_speed, + .verify = cpufreq_generic_frequency_table_verify, .target = at32_set_target, .get = at32_get_speed, .flags = CPUFREQ_STICKY,
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines for this driver. Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> --- drivers/cpufreq/at32ap-cpufreq.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-)