devfreq: Support device update function

PATCH In review Johnny Liu 2 participants 4 messages Oct 3, 2022 – Oct 13, 2022 Device frequency (devfreq)

Share & tools

Johnny Liu

author

2022-10-03 06:02 UTC #0 lore raw

PATCH v2 1/1 devfreq: Support device update function

To realize interrupt-driven closed-loop governors, governors need to be able to send data to the underlying devfreq driver to ask for updating the device settings, such as hardware registers for frequency limits, 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 <[email protected]>

---
v2: Correct the function signature of devfreq_update_dev

 drivers/devfreq/governor.h | 8 ++++++++
 include/linux/devfreq.h    | 8 ++++++++
 2 files changed, 16 insertions(+)

drivers/devfreq/governor.h +8 -0

index 0adfebc0467a..b5781fa549c7 100644
@@ -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 */

include/linux/devfreq.h +8 -0

index 34aab4dd336c..91648e8f8d76 100644
@@ -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.
  * @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__ */

Signature · 1 line

2.17.1

Chanwoo Choi

2022-10-12 19:44 UTC #1 lore raw

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?

Quoted 1 line · Johnny Liu

To realize interrupt-driven closed-loop governors, governors need to be

Could you explain the detailed means of 'interrupt-driven closed-loop governors'?

Quoted 2 lines

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.

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.

Quoted 41 lines

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 <[email protected]>
---
v2: Correct the function signature of devfreq_update_dev
 drivers/devfreq/governor.h | 8 ++++++++
 include/linux/devfreq.h    | 8 ++++++++
 2 files changed, 16 insertions(+)
drivers/devfreq/governor.h +8 -0
index 0adfebc0467a..b5781fa549c7 100644
@@ -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 */
include/linux/devfreq.h +0 -0
index 34aab4dd336c..91648e8f8d76 100644

include/linux/devfreq.h struct devfreq_dev_status { · line 96

Quoted 5 lines

include/linux/devfreq.h +2 -0

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

Quoted 22 lines

include/linux/devfreq.h +1 -0

  * @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)

{

include/linux/devfreq.h +5 -0

 	return -EINVAL;
 }
+
+static inline int devfreq_update_dev(struct devfreq *df, void *data)
+{
+	return -EINVAL;
+}
 #endif /* CONFIG_PM_DEVFREQ */
 
 #endif /* __LINUX_DEVFREQ_H__ */

Signature · 3 lines

Best Regards,
Samsung Electronics
Chanwoo Choi

Johnny Liu

author

2022-10-13 05:16 UTC #2 lore raw

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.

Quoted 5 lines · Chanwoo Choi

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.

Quoted 4 lines · Johnny Liu

Quoted 1 line
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.

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.

Quoted 6 lines

Quoted 2 lines
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.

Quoted 2 lines

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.

Quoted 41 lines

Quoted 41 lines
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 <[email protected]>
---
v2: Correct the function signature of devfreq_update_dev
 drivers/devfreq/governor.h | 8 ++++++++
 include/linux/devfreq.h    | 8 ++++++++
 2 files changed, 16 insertions(+)
drivers/devfreq/governor.h +8 -0
index 0adfebc0467a..b5781fa549c7 100644
@@ -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 */
include/linux/devfreq.h +0 -0
index 34aab4dd336c..91648e8f8d76 100644
@@ -92,6 +92,8 @@ struct devfreq_dev_status {

Quoted 8 lines

include/linux/devfreq.h struct devfreq_dev_status { · line 96
Quoted 5 lines
include/linux/devfreq.h +2 -0
  *			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".

Quoted 21 lines

include/linux/devfreq.h +1 -0

  * @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)

{

include/linux/devfreq.h +5 -0

 	return -EINVAL;
 }
+
+static inline int devfreq_update_dev(struct devfreq *df, void *data)
+{
+	return -EINVAL;
+}
 #endif /* CONFIG_PM_DEVFREQ */

Quoted 1 line

Quoted 1 line
#endif /* __LINUX_DEVFREQ_H__ */

--
Best Regards,
Johnny Liu

Chanwoo Choi

2022-10-13 20:14 UTC #3 lore raw

Quoted 4 lines · Johnny Liu

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.

Quoted 8 lines

Quoted 5 lines · Chanwoo Choi
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.

Quoted 8 lines

Quoted 5 lines · Johnny Liu
Quoted 1 line
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.

Quoted 5 lines

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.

Quoted 8 lines

Quoted 7 lines
Quoted 3 lines
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.

Quoted 5 lines

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

Quoted 5 lines

Quoted 3 lines
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.

Quoted 79 lines

Quoted 42 lines
Quoted 42 lines
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 <[email protected]>
---
v2: Correct the function signature of devfreq_update_dev
 drivers/devfreq/governor.h | 8 ++++++++
 include/linux/devfreq.h    | 8 ++++++++
 2 files changed, 16 insertions(+)
drivers/devfreq/governor.h +8 -0
index 0adfebc0467a..b5781fa549c7 100644
@@ -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 */
include/linux/devfreq.h +0 -0
index 34aab4dd336c..91648e8f8d76 100644
@@ -92,6 +92,8 @@ struct devfreq_dev_status {
Quoted 8 lines
include/linux/devfreq.h struct devfreq_dev_status { · line 96
Quoted 5 lines
include/linux/devfreq.h +2 -0
  *			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".
Quoted 21 lines
Quoted 21 lines
include/linux/devfreq.h +1 -0
  * @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)
{
include/linux/devfreq.h +5 -0
 	return -EINVAL;
 }
+
+static inline int devfreq_update_dev(struct devfreq *df, void *data)
+{
+	return -EINVAL;
+}
 #endif /* CONFIG_PM_DEVFREQ */
Quoted 1 line
Quoted 1 line
#endif /* __LINUX_DEVFREQ_H__ */
--
Best Regards,
Johnny Liu

Signature · 3 lines

Best Regards,
Samsung Electronics
Chanwoo Choi