Hi,

On Mon, Feb 8, 2016 at 12:39 PM, Viresh Kumar <viresh.ku...@linaro.org> wrote:
> Hi Rafael,
>
> Things look much much better now. I have rebased this series over
> pm/bleeding-edge, that has all your patches.
>
> I have moved ahead and done few more changes in this series, that should
> get rid of all the lockdeps we were getting earlier, that includes
> fixing lockdep issue in update_sampling_rate() that we were chasing.
>
> These are pushed here again:
> git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git 
> cpufreq/governor-kobject
>
> @Juri/Shilpa: Can you please confirm if all the issues got resolved now
> ?
>
> V2->V3:
> - The first patch from V2, that was moving min_sampling_rate to
>   per governor structure was dropped, as you suggested.
> - Also, I have moved common tunables to struct dbs_data now, which you
>   also suggested sometime back.
> - Last 5 patches are all new and fix rest of the issues we were facing.
>
> --
> viresh
>
> Viresh Kumar (13):
>   cpufreq: governor: Create generic macro for global tuners
>   cpufreq: governor: Move common tunables to 'struct dbs_data'
>   cpufreq: governor: New sysfs show/store callbacks for governor
>     tunables
>   cpufreq: governor: Drop unused macros for creating governor tunable
>     attributes
>   Revert "cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT"
>   cpufreq: Merge cpufreq_offline_prepare/finish routines
>   cpufreq: Call __cpufreq_governor() with policy->rwsem held
>   cpufreq: Remove cpufreq_governor_lock
>   cpufreq: governor: Move common sysfs tunables to cpufreq_governor.c
>   cpufreq: governor: No need to manage state machine now
>   cpufreq: governor: Keep list of policy_dbs within dbs_data
>   cpufreq: ondemand: Traverse list of policy_dbs in
>     update_sampling_rate()
>   cpufreq: conservative: Update sample_delay_ns immediately

This is OK overall, but we'll need to reorder it somewhat.

I have reviewed patches [1-5,12/13].  Where I didn't send comments, I had none.

In my opinion, those 6 patches should go in first.  At least I don't
see why [12/13] cannot be reworked on top of [1-5/13].  If there is
any fundamental reason, please let me know what it is.  Otherwise,
please first send new versions of those 6 patches, preferably as a new
series.

The rest of the patchset will require more review time, so please send
them again later, when you're done with the first item.

Thanks,
Rafael

Reply via email to