Hi Matthias,

On 2018년 08월 03일 09:24, Matthias Kaehlcke wrote:
> 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.

IMO, patch1/2/3/6 looks good. I replied with my reviewed-tag for them.

patch4 defines the 'struct devfreq_policy' and then patch5
send notification with 'struct devfreq_policy' on original patch.
But, when we discussed it on patch5, new devfreq notification
send 'struct devfreq_freq_limits' better than 'struct devfreq_policy'.
So, patch4 would be required with more discussion. If myungjoo agree
the current patch4, I'm okay.

> 
> 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

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Reply via email to