Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <d47932c5-492c-32a6-f36c-f7dbef91bc0a@gmail.com>
Date:   Fri, 14 Oct 2022 05:13:58 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH v2] devfreq: Support device update function
Content-Language: en-US
To:     Johnny Liu <johnliu@nvidia.com>
Cc:     cw00.choi@samsung.com, kyungmin.park@samsung.com,
        linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
        myungjoo.ham@samsung.com
References: <24e701e9-b560-5350-a2f7-89e2a4a1c97a@gmail.com>
 <20221013051627.17171-1-johnliu@nvidia.com>
From:   Chanwoo Choi <cwchoi00@gmail.com>
In-Reply-To: <20221013051627.17171-1-johnliu@nvidia.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 22. 10. 13. 14:16, Johnny Liu wrote:
> Thanks for your quick response and detailed comments. I will prepare a new patch
> series to include the user of the proposed function. But still I answer your
> concerns in the following sections.
> 
> On Thu, 13 Oct 2022 04:44, Chanwoo Choi wrote:
>> Hi,
>>
>> Basically, struct devfreq_dev_profile is used to pass the devfreq device data
>> from devfreq driver to governor. But, This means that it passes
>> the data from governor to devfreq driver reversely?
> 
> Yes, it means that governor can pass data to devfreq driver reversely.

Until now, all governors just passed the next target frequency to devfreq core.
It is different behavior against before governors. When you send v2,
I'll check them more detailed.

> 
>> On 22. 10. 3. 15:02, Johnny Liu wrote:
>>> To realize interrupt-driven closed-loop governors, governors need to be
>>
>> Could you explain the detailed means of 'interrupt-driven closed-loop governors'?
> 
> For term "interrupt-driven", it means the DFS logic is triggered by interrupts
> rather than performing DFS in a polling fashion. This can reduce the CPU load.

Thanks.

> 
> For term "closed-loop", it means that there is a target metric the governor will
> try to keep it at certain value/level. For example, if the target metric means
> device utilization, then the governor should perform DFS so that it will keep
> device utilization at certain level specified by the user.

If I understand right, the device utilization is such as 
exynos-nocp.c, exynos-ppmu.c, rockchip-dfi.c under drivers/devfreq/event.

Usually, governor keeps the following step to decide the next frequency:
1. governor collects the device status by using profile->get_dev_status
2. the specific devfreq driver try to get dev_status in case of that exynos-bus.c
   has used the drivers/devfreq/event/exynos-ppmu.c to get the device utilization.
3. governor decides the next target frequency by using the collected dev_status
4. devfreq core adjusts the target frequency
	with both user-input via /sys/class/devfreq/*/min_freq, max_freq
	and qos-value of DEV_PM_QOS_MIN_FREQUENCY, DEV_PM_QOS_MAX_FREQUENCY

As I understand, you mentioned that need to limit the min/max device utilization
scope such as DEV_PM_QOS_MIN_FREQUENCY, DEV_PM_QOS_MAX_FREQUENCY?

Instead of setting the min/max value of device utilization,
the devfreq core has already adjusted the final target frequency
on above 4 step by using user-inpu and qos-value.

If possible, I'd like you to explain it with the more detailed example
why user should specify the level of device utilization. 

> 
>>> able to send data to the underlying devfreq driver to ask for updating
>>> the device settings, such as hardware registers for frequency limits,
>>
>> I think that governor is not able to get the hardware information direclty
>> instead of devfreq driver. Usually, the devfreq driver should get the
>> h/w info and then passed to governor if required.
> 
> Yes, governor should not be able to the HW info directly. From my perspective,
> I think governor should be able to pass down hint, such as device utilization
> specified by the user in the governor, to the devfreq driver. Then, the
> devfreq driver can configure the device accordingly so that interrupts get
> triggered when device utilization exceeds or drops by certain amount.

As I mentioned above, the device utilization was transferred from devfreq driver
to governor by using struct devfreq_dev_status as following sequence.
	devfreq driver -> devfreq core -> governor

We better to discuss with your next version patches
with real use-case for understanding because your suggestion is different
from existing communication between governor and devfreq core/driver.

I'll expect of what is meaning of 'down hint'.

> 
>> Lastly, this patch doesn't contain the any use-case of devfreq_update_dev().
>> I prefer to post the real use-case of this patch.
> 
> I will include the user of it in a new patch series.

Thanks. I'll expect v2 patches.

> 
>>> which are compared against the device frequency to generate interrupts
>>>
>>> Since governors might export several tunable parameters, users can
>>> enforce different policies for the control logics. Under different
>>> policies, governors need to send different information to inform the
>>> devfreq driver to configure the device accordingly.
>>>
>>> The introduced update function improves the flexibility of governors
>>> and acts as a communication interface between governors and devfreq
>>> drivers.
>>>
>>> Signed-off-by: Johnny Liu <johnliu@nvidia.com>
>>> ---
>>> v2: Correct the function signature of devfreq_update_dev
>>>
>>>  drivers/devfreq/governor.h | 8 ++++++++
>>>  include/linux/devfreq.h    | 8 ++++++++
>>>  2 files changed, 16 insertions(+)
>>>
>>> diff --git a/drivers/devfreq/governor.h b/drivers/devfreq/governor.h
>>> index 0adfebc0467a..b5781fa549c7 100644
>>> --- a/drivers/devfreq/governor.h
>>> +++ b/drivers/devfreq/governor.h
>>> @@ -124,4 +124,12 @@ static inline int devfreq_update_stats(struct devfreq *df)
>>>
>>>  	return df->profile->get_dev_status(df->dev.parent, &df->last_status);
>>>  }
>>> +
>>> +static inline int devfreq_update_dev(struct devfreq *df, void *data)
>>> +{
>>> +	if (!df->profile->update)
>>> +		return -EINVAL;
>>> +
>>> +	return df->profile->update(df->dev.parent, data);
>>> +}
>>>  #endif /* _GOVERNOR_H */
>>> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
>>> index 34aab4dd336c..91648e8f8d76 100644
>>> --- a/include/linux/devfreq.h
>>> +++ b/include/linux/devfreq.h
>>> @@ -92,6 +92,8 @@ struct devfreq_dev_status {
>>>   *			devfreq.last_status.
>>>   * @get_cur_freq:	The device should provide the current frequency
>>>   *			at which it is operating.
>>> + * @update:		An optional function to allow governors send data back
>>> + *			to the devfreq driver to update the device settings.
>>
>> IMO, 'update' word is too generic. I think that 'update_device_data' is better
>> to improve the readability.
> 
> Yes, "update_device_data" has better readability compared to "update".
> 
>>>   * @exit:		An optional callback that is called when devfreq
>>>   *			is removing the devfreq object due to error or
>>>   *			from devfreq_remove_device() call. If the user
>>> @@ -114,6 +116,7 @@ struct devfreq_dev_profile {
>>>  	int (*get_dev_status)(struct device *dev,
>>>  			      struct devfreq_dev_status *stat);
>>>  	int (*get_cur_freq)(struct device *dev, unsigned long *freq);
>>> +	int (*update)(struct device *dev, void *data);
>>>  	void (*exit)(struct device *dev);
>>>
>>>  	unsigned long *freq_table> @@ -451,6 +454,11 @@ static inline int devfreq_update_stats(struct devfreq *df)
>>>  {
>>>  	return -EINVAL;
>>>  }
>>> +
>>> +static inline int devfreq_update_dev(struct devfreq *df, void *data)
>>> +{
>>> +	return -EINVAL;
>>> +}
>>>  #endif /* CONFIG_PM_DEVFREQ */
>>>
>>>  #endif /* __LINUX_DEVFREQ_H__ */
> 
> --
> Best Regards,
> Johnny Liu


-- 
Best Regards,
Samsung Electronics
Chanwoo Choi