On Fri, Aug 03, 2018 at 09:03:30AM +0900, Chanwoo Choi wrote: > Hi Matthias, > > On 2018년 08월 03일 08:36, Matthias Kaehlcke wrote: > > Hi Chanwoo, > > > > this patch and "PM / devfreq: Fix handling of min/max_freq == 0" > > address issues not directly related with the throttler. It seems it > > could still take a while for the throttler to move forward, do you > > want me to spin out these two patches so that they can get merged > > independently from the rest of the series? > > How about resend the devfreq patches(patch1/2/3/4/6) which don't depend on > throttler core with my reviewed tag? Maybe, it is easy to merge them through > Myungjoo.
Sure, I can do this if you think it is reasonable to merge all these patches without the throttler. These are the patches we are talking about and my interpretation of their status: [01] PM / devfreq: Init user limits from OPP limits, not viceversa landed in Rafaels tree [02] PM / devfreq: Fix handling of min/max_freq == 0 independent fix, can land [03] PM / devfreq: Don't adjust to user limits in governors independent improvement, can land [04] PM / devfreq: Add struct devfreq_policy edge case, can land if devfreq maintainers think that factoring out some fields to the policy struct is an improvement independently of the throttler [05] PM / devfreq: Add support for policy notifiers under heavy discussion ;-), can't land [06] PM / devfreq: Make update_devfreq() public has no user without the throttler, not sure if it should be merged without it. up to devfreq maintainers. Please let me know what you think Thanks Matthias
