On 03/06/2015 06:25 PM, Tony Lindgren wrote:
* Tero Kristo <t-kristo@xxxxxx> [150306 08:10]:
On 03/06/2015 05:32 PM, Tony Lindgren wrote:
* Tero Kristo <t-kristo@xxxxxx> [150306 04:29]:
The legacy support is wrong and dangerous, as it doesn't take any
OPPs into account and does not scale voltages. Switching mpurate should
be handled through cpufreq.
Hmm I wonder if some systems actually rely on the mpurate cmdline
parameter. If this cannot be fixed properly, you should at least
print an error here.
Yea, I was kind of worried about this comment. We have also an option of
doing this through clock driver, but I was hesitant of doing this either.
Isn't having a global kernel option like this frowned upon anyway? I believe
this piece of init code gets executed on every board on multiarch kernel.
Well the option has been there probably for 10 years already so we
can't just drop it like that. Chances are it's unused though, so I
suggest you just print out a warning for it.
It's called from omap_arch_initcall which checks for soc_is_omap()
so that's not an issue. But when moving the code, you naturally
need to check the moved code initcall usage.
This patch is not really needed for the set itself btw, it can just be
dropped if you feel it actually is used by someone. Reverting it from
the set just causes a minor merge conflict and you can't remove two of
the otherwise empty clock files.
You could also just move the code over to clock.c maybe, merge these and
do a soc type check to reach the same behaviour.
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
