Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp164918pxb; Wed, 3 Feb 2021 02:24:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJw5NyUwWXHxpPU8YjS8Z8uuY0X34DRY7Xy0jVZ/X6Dbzl9UNDxOUphkowZzf6/Is6OSMaSs X-Received: by 2002:a17:907:c1f:: with SMTP id ga31mr2580386ejc.192.1612347870826; Wed, 03 Feb 2021 02:24:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612347870; cv=none; d=google.com; s=arc-20160816; b=nq8CAFaKAZd84Ai+2lagL+ndcQKb6XIzVc+8KDbvXg7J7w2PoFT/i5rI7a7kG74q0B kW6em5HSojlQA4TiU7eCtBzUWHiVEvms5eHb/ZOhrVofKd0ffI7mEg5GphQEjVEq7cdc Lxxc1siqZpqNHWmwe4S9fNiAg/fCwY7dx43ogjRt6hCfkSCrEAZ8Q8wdQy12Yd/NfFQe XuQcXMZLNlmMWlabLek4sG876c9vj2EYuW+5OmWnpZuzHqPtfsHuuzDlACHe1XZzzYSi ILV5+3QqiNbMO5jYCJ6Jylx7VIYvNqtYB1muBxAw8qwXoVkfQ5cSeyTwz6pMbwTA2AeI R2Ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=JG0i1eYABUAD7vv58HqBW/2Kg058yyt5jncUhkFhOS8=; b=ccmmnZULdF9ZFCpk/5CkZwZYCSbrXTGwQ8/GZrTY4d6DJuOx9kP6W6fCdPVDoFix4g B/qItep3KAM78h8TAM7t/Hk70mi3iyM6Jufr3T6AuTxq85rYLxb5R0VmWJ8P1kgzCkBN dSAbMeGbasUSjNmOB8hea2L1+FM+3DlWxFWbOfTGQP0Q31pr/GCb6ecv2Z/+EsC/So1E GL9T9UtST4Ub1aQj5aSiTuZ6k+r6MMgJLxaJHcuvSB59nNBxC7lrGa8zjyS0dY4/lpw/ po6yGsUE639g/l0ob3nysuQYd0OWnZ84TIHoOPs/6FjqeJ5O+oRo1ZhJyo5VvtqIQ3GU KNrQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r11si900854edh.225.2021.02.03.02.24.06; Wed, 03 Feb 2021 02:24:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233658AbhBCKWl (ORCPT + 99 others); Wed, 3 Feb 2021 05:22:41 -0500 Received: from foss.arm.com ([217.140.110.172]:37324 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233405AbhBCKWl (ORCPT ); Wed, 3 Feb 2021 05:22:41 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EEE7BD6E; Wed, 3 Feb 2021 02:21:49 -0800 (PST) Received: from [10.57.13.36] (unknown [10.57.13.36]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7A47C3F719; Wed, 3 Feb 2021 02:21:47 -0800 (PST) Subject: Re: [RFC][PATCH 1/3] PM /devfreq: add user frequency limits into devfreq struct To: Chanwoo Choi Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, vireshk@kernel.org, rafael@kernel.org, daniel.lezcano@linaro.org, Dietmar.Eggemann@arm.com, amitk@kernel.org, rui.zhang@intel.com, myungjoo.ham@samsung.com, kyungmin.park@samsung.com References: <20210126104001.20361-1-lukasz.luba@arm.com> <20210126104001.20361-2-lukasz.luba@arm.com> From: Lukasz Luba Message-ID: <5bd13e13-202f-d059-da29-f82806c33a38@arm.com> Date: Wed, 3 Feb 2021 10:21:45 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Chanwoo, Thank you for looking at this. On 2/3/21 10:11 AM, Chanwoo Choi wrote: > Hi Lukasz, > > When accessing the max_freq and min_freq at devfreq-cooling.c, > even if can access 'user_max_freq' and 'lock' by using the 'devfreq' instance, > I think that the direct access of variables (lock/user_max_freq/user_min_freq) > of struct devfreq are not good. > > Instead, how about using the 'DEVFREQ_TRANSITION_NOTIFIER' > notification with following changes of 'struct devfreq_freq'? I like the idea with devfreq notification. I will have to go through the code to check that possibility. > Also, need to add codes into devfreq_set_target() for initializing > 'new_max_freq' and 'new_min_freq' before sending the DEVFREQ_POSTCHANGE > notification. > > diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h > index 147a229056d2..d5726592d362 100644 > --- a/include/linux/devfreq.h > +++ b/include/linux/devfreq.h > @@ -207,6 +207,8 @@ struct devfreq { > struct devfreq_freqs { > unsigned long old; > unsigned long new; > + unsigned long new_max_freq; > + unsigned long new_min_freq; > }; > > > And I think that new 'user_min_freq'/'user_max_freq' are not necessary. > You can get the current max_freq/min_freq by using the following steps: > > get_freq_range(devfreq, &min_freq, &max_freq); > dev_pm_opp_find_freq_floor(pdev, &min_freq); > dev_pm_opp_find_freq_floor(pdev, &max_freq); > > So that you can get the 'max_freq/min_freq' and then > initialize the 'freqs.new_max_freq and freqs.new_min_freq' > with them as following: > > in devfreq_set_target() > get_freq_range(devfreq, &min_freq, &max_freq); > dev_pm_opp_find_freq_floor(pdev, &min_freq); > dev_pm_opp_find_freq_floor(pdev, &max_freq); > freqs.new_max_freq = min_freq; > freqs.new_max_freq = max_freq; > devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE); I will plumb it in and check that option. My concern is that function get_freq_range() would give me the max_freq value from PM QoS, which might be my thermal limit - lower that user_max_freq. Then I still need I've been playing with PM QoS notifications because I thought it would be possible to be notified in thermal for all new set values - even from devfreq sysfs user max_freq write, which has value higher that the current limit set by thermal governor. Unfortunately PM QoS doesn't send that information by design. PM QoS also by desing won't allow me to check first two limits in the plist - which would be thermal and user sysfs max_freq. I will experiment with this notifications and share the results. That you for your comments. Regards, Lukasz