From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753323AbdJMGpY (ORCPT ); Fri, 13 Oct 2017 02:45:24 -0400 Received: from mailout1.samsung.com ([203.254.224.24]:51639 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751414AbdJMGpV (ORCPT ); Fri, 13 Oct 2017 02:45:21 -0400 X-AuditID: b6c32a45-d23ff70000001088-17-59e060ffdbf8 MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset="utf-8" Message-id: <59E060FF.1060507@samsung.com> Date: Fri, 13 Oct 2017 15:45:19 +0900 From: Chanwoo Choi Organization: Samsung Electronics User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: "myungjoo.ham@samsung.com" Cc: cwchoi00@gmail.com, Kyungmin Park , "rafael.j.wysocki@intel.com" , Inki Dae , "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" Subject: Re: [PATCH v3 5/8] PM / devfreq: Get the available next frequency on update_devfreq() In-reply-to: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGKsWRmVeSWpSXmKPExsWy7bCmue7/hAeRBh2rRC2eHdW2mHR/AovF 2aY37BaXd81hs/jce4TR4nbjCjaLxyvesjuwe+ycdZfdY/Gel0wefVtWMXp83iQXwBKVapOR mpiSWqSQmpecn5KZl26r5B0c7xxvamZgqGtoaWGupJCXmJtqq+TiE6DrlpkDdICSQlliTilQ KCCxuFhJ386mKL+0JFUhI7+4xFYp2tDQSM/QwFzPyMhIz8Q41srIFKgkITXjwMxbjAUbFSr+ rH/M1sA4Q7KLkZNDQsBE4vmT08xdjFwcQgI7GCUuXznEBOF8Z5SY/PMrO0zVglfzoRIbGCVO H7jPDJLgFRCU+DH5HksXIwcHs4C8xJFL2SBhZgFNiRdfJrFA1N9jlGjZuogdol5L4tLJDSwg NouAqsSCeReYQGw2oPj+FzfYQGx+AUWJqz8eM4LYogIREjvnfwPrFRGwlFg2axLYqcwCs5kk 3rdOBxskLJAgce/PSrBmToFgiYO/drCCFEkInGCTOLamBeoFF4mTO5uhbGGJV8e3QNnSEs9W bWSEaGhnlNg85x4LhNPBKHF/ZSMrRJWxxKmuRiaI5/gkOg7/ZQf5WUKAV6KjTQiixENiw4vn TBBhR4nZS51AwkICl5gk5syWmcAoNwspwGYhAmwWUoAtYGRexSiWWlCcm55abFRgqFecmFtc mpeul5yfu4kRnOa0XHcwzjjnc4hRgINRiYd3R/n9SCHWxLLiytxDjBIczEoivKquDyKFeFMS K6tSi/Lji0pzUosPMZoCw3sis5Rocj4wBeeVxBuaWBqYmJkZmZtZAFOYOG/9tmsRQgLpiSWp 2ampBalFMH1MHJxSDYwGi/fn3JvwIKt0A/vBzHXdOvet7Hy09W/Z/9tbYui1w6WkqvpFiD77 lAWvJ0h6hX7dcmz/LIVJn/8YnNk4WfrX5+/lJk9u2nHx9P9ddzF1xxGZ0wK1i2KWpduUcz7q VE+vVFTkWufcvVNo/0L5vYemf2M78qM8u2Bu6YXtKV5mk3avDLqsVGSoxFKckWioxVxUnAgA t1rOkYkDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsVy+t9jQd1/CQ8iDWY9tbJ4dlTbYtL9CSwW Z5vesFtc3jWHzeJz7xFGi9uNK9gsHq94y+7A7rFz1l12j8V7XjJ59G1ZxejxeZNcAEsUl01K ak5mWWqRvl0CV8aBmbcYCzYqVPxZ/5itgXGGZBcjJ4eEgInEglfzmboYuTiEBNYxShyfeoIN JMErICjxY/I9li5GDg5mAXmJI5eyIUx1iSlTciHKHzBKXPp8nwWiXEvi0skNYDaLgKrEgnkX mEBsNqD4/hc3wEbyCyhKXP3xmBFkjqhAhET3iUqQsIiApcSyWZOYQWYyC8xmkvh98wIjSEJY IEFiU+c/Fohll5gkfj5/wAqS4BQIlrjYe4xxAqPALCSnzkI4dRbCqQsYmVcxSqYWFOem5xYb FRjlpZbrFSfmFpfmpesl5+duYgQG97bDWv07GB8viT/EKMDBqMTDu6P8fqQQa2JZcWXuIUYJ DmYlEV5V1weRQrwpiZVVqUX58UWlOanFhxilOViUxHn5849FCgmkJ5akZqemFqQWwWSZODil Ghh5ZJY+PWyX23X5dLjcx/8Hz9VVnJpyV8TIgq1YPO3HmRJmwUtyLqaVjXVZ8VssPbtmpkcW d3PMTw2R9LneH6nuqNylwsK2I/zOk+3fTNRyV7Jbb26/NbGUVW8m9y3JVdlXPr4Wdo/t3xT4 94Lt9AuT/y73rJ7qOX9W3Heth8l87Ye/lH7OE1JiKc5INNRiLipOBACkThchagIAAA== X-CMS-MailID: 20171013064519epcas2p33168c7a3ddd79296e2601d26bd50bb19 X-Msg-Generator: CA X-Sender-IP: 182.195.42.143 X-Local-Sender: =?UTF-8?B?7LWc7LCs7JqwG1RpemVuIFBsYXRmb3JtIExhYihTL1fshLw=?= =?UTF-8?B?7YSwKRvsgrzshLHsoITsnpAbU2VuaW9yIEVuZ2luZWVy?= X-Global-Sender: =?UTF-8?B?Q2hhbndvbyBDaG9pG1RpemVuIFBsYXRmb3JtIExhYi4bU2Ft?= =?UTF-8?B?c3VuZyBFbGVjdHJvbmljcxtTZW5pb3IgRW5naW5lZXI=?= X-Sender-Code: =?UTF-8?B?QzEwG1RFTEUbQzEwVjgxMTE=?= CMS-TYPE: 102P DLP-Filter: Pass X-CFilter-Loop: Reflected X-CMS-RootMailID: 20171011030947epcas1p1133ca20bb9356453c331751b3e3bba4b X-RootMTR: 20171011030947epcas1p1133ca20bb9356453c331751b3e3bba4b References: <1507691364-3899-1-git-send-email-cw00.choi@samsung.com> <1507691364-3899-6-git-send-email-cw00.choi@samsung.com> <20171011113041epcms1p2c09f39f5db8f3b33cb25fe4c28e18e74@epcms1p2> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 2017년 10월 11일 22:33, Chanwoo Choi wrote: > On Wed, Oct 11, 2017 at 8:30 PM, MyungJoo Ham wrote: >>> The update_devfreq() considers only user frequency (min_freq/max_freq) >>> and the next target_freq provided by the governor. But, the commit >>> a76caf55e5b35 ("thermal: Add devfreq cooling") is able to disable >>> OPP as a cooling device. In result, the update_devfreq() have to >>> consider the 'opp->available' status in order to decicde the next freq >>> by the devfreq_recommended_opp(). >>> >>> Signed-off-by: Chanwoo Choi >>> --- >>> drivers/devfreq/devfreq.c | 9 ++++++++- >>> 1 file changed, 8 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c >>> index 1c4b377cacfb..3b9662ffe603 100644 >>> --- a/drivers/devfreq/devfreq.c >>> +++ b/drivers/devfreq/devfreq.c >>> @@ -255,6 +255,7 @@ static int devfreq_notify_transition(struct devfreq *devfreq, >>> int update_devfreq(struct devfreq *devfreq) >>> { >>> struct devfreq_freqs freqs; >>> + struct dev_pm_opp *opp; >>> unsigned long freq, cur_freq; >>> int err = 0; >>> u32 flags = 0; >>> @@ -273,7 +274,7 @@ int update_devfreq(struct devfreq *devfreq) >>> return err; >>> >>> /* >>> - * Adjust the frequency with user freq and QoS. >>> + * Adjust the frequency with user freq, QoS and available freq. >>> * >>> * List from the highest priority >>> * max_freq >>> @@ -289,6 +290,12 @@ int update_devfreq(struct devfreq *devfreq) >>> flags |= DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use LUB */ >>> } >>> >>> + opp = devfreq_recommended_opp(devfreq->dev.parent, &freq, flags); >>> + if (IS_ERR(opp)) >>> + return PTR_ERR(opp); >>> + freq = dev_pm_opp_get_freq(opp); >>> + dev_pm_opp_put(opp); >>> + >> >> Is this really necessary? > > The requirement is due to devfreq_cooling device using > dev_pm_opp_disable/enable(). I got the better solution. If struct devfreq contains the 'scaling_min/max_freq' variable, this issue could be fixed. I'll update it with scaling_min/max_freq' variables on v4. > > I added the detailed explanation on cover letter as following: > If this code is not included, the notifiee using TRANSITION_NOTIFIER > receives the wrong next target_freq. On the cpufreq, cpufreq doesn't > use the 'dev_pm_opp_disable/enable()' function and then there is no > the same issue on cpufreq. > > [Cover letter's description about this patch] > For example, > - devfreq's min_freq is 100Mhz and max_freq is 700Mhz. > - OPP disabled 500/600/700Mhz due to devfreq-cooling.c. > - simple_ondemand govenor decided the next target_freq (600Mhz) > |----------|-------------------------------------------------------------| > |Freq(MHz) |100 |200 |300 |400 |500 |600 |70 0 | > |Devfreq |min_freq| | | | | |max_freq| > |OPP avail |enabled |enabled|enabled|enabled |Disabled| Disabled|Disabled| > |Ondmenad | | | | | |next_freq| | > |------------------------------------------------------------------------| > > In result, > - Before this patch, target_freq is 600Mhz > and TRANSITION_NOTIFIER sends the next_freq is 600Mhz to the notifiee. > - After this patch, target_freq is 400Mhz because 500/600 were disabled by OPP. > and TRANSITION_NOTIFIER sends the next_freq is 400Mhz to the notifiee. > -------------- > >> >> devfreq_recommended_opp is going to be called by the device driver >> invoked by devfreq->profile->target() function anyway. >> >> We are now going to call devfreq_recommended_opp twice in this context. >> >>> if (devfreq->profile->get_cur_freq) >>> devfreq->profile->get_cur_freq(devfreq->dev.parent, &cur_freq); >>> else >>> -- > > Right. The devfreq_recommended_opp() is called twice. > I wish there was a better way. > -- Best Regards, Chanwoo Choi Samsung Electronics