* Tero Kristo <t-kristo@xxxxxx> [150309 05:56]: > 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. How about set it up in a way where it can be easily reverted later on if there is need for that? > 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. If it's needed yeah. Regards, Tony -- 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
