On 9 August 2013 00:20, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: > I don't think so. I think it's reasonable to have a per-SoC cpufreq > driver whose primary content is the parameterization data and/or custom > hooks for a unified core cpufreq driver. The duplicate parts of each > cpufreq driver can be moved into the core cpufreq driver, but the > non-duplicate parts remain. That's how many other subsystems work (MMC, > USB, ASoC spring to mind). Guys in the --to list: Please shout before its too late... I can understand why Stephen is asking not to implement a virtual clock driver for cpu as there is no clock corresponding to that.. We are just playing with existing clocks there.. But I thought these clock APIs can be considered as hooks that we were looking for and so shouldn't be a problem.. But yes, different people see things differently.. So, if I take Stephen's suggestions then I need to implement hooks into cpufreq-cpu0 driver for taking freq-table/ setting clk rates, etc... Let me know if anybody has a issue with that before we actually implement that.. -- viresh -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
