On Mon, Aug 19, 2013 at 10:07 AM, Viresh Kumar [off-list ref] wrote:

Hi Amit,

Thanks for your feedback :)

On 18 August 2013 16:11, amit daniel kachhap [off-list ref] wrote:

quoted

This new API is fine but I have another idea.

good.

quoted

Say During the registration of the frequency table cpufreq_policy can
be registered as SCALE_DIRECT or SCALE_STEPS. With SCALE_DIRECT flag,
valid frequency will be requested. With this flags the governor itself
can  can figure out if frequency scaling is required or not and very
few calls to __cpufreq_driver_target will happen.

Honestly speaking I couldn't get what your idea is :) ... but governor is
in no position to make this direct call to drivers.. Taking such stuff to
governors will replicate this code again.. Its better all governors call
some common part of cpufreq.c which then decides what to do..

I meant that something like 2 policies can be registered SCALE_DIRECT/STEPS.
if SCALE_DIRECT is registered than target will be called with exact
frequency. SCALE_STEPS will behave as currently happening. This way
target_index api may not be needed. But looks like Rafael and others
are fine with your approach so you can ignore this :)

quoted

But i agree that in this approach cpufreq_frequency_table_target is
still required but again it can be optimized by binary search as
currently the search is linear.

Frequencies in this table aren't required to be in ascending order :)

OK right. Actually I had thought only about the case when opp library
is used to create the cpufreq table and then it creates the table in
ascending order. Anyways not all platform uses opp libraries so it is
not generic enough.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

On Mon, Aug 19, 2013 at 10:07 AM, Viresh Kumar [off-list ref] wrote:

Hi Amit,

Thanks for your feedback :)

On 18 August 2013 16:11, amit daniel kachhap [off-list ref] wrote:

quoted

This new API is fine but I have another idea.

good.

quoted

Say During the registration of the frequency table cpufreq_policy can
be registered as SCALE_DIRECT or SCALE_STEPS. With SCALE_DIRECT flag,
valid frequency will be requested. With this flags the governor itself
can  can figure out if frequency scaling is required or not and very
few calls to __cpufreq_driver_target will happen.

Honestly speaking I couldn't get what your idea is :) ... but governor is
in no position to make this direct call to drivers.. Taking such stuff to
governors will replicate this code again.. Its better all governors call
some common part of cpufreq.c which then decides what to do..

quoted

But i agree that in this approach cpufreq_frequency_table_target is
still required but again it can be optimized by binary search as
currently the search is linear.

Frequencies in this table aren't required to be in ascending order :)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel