On 11/15/24 06:08, MyungJoo Ham wrote:
Hey Dmitry,
Thanks for taking time to review the series.
+ Devfreq maintainers to comment (I thought you already added
them by name)
Hey MyungJoo/Kyungmin/Chanwoo,
Can you weigh in here? Does it make sense to add a new
class of devfreq devices that don't have governors
associated with them just for them to export a few
essential data to userspace? In this scenario the
scaling algorithm is in a SCP and we just start
them from the kernel. We do have ways to get the
current frequency of various buses but does this
warrant adding a new class of governor less devices?
-Sibi
If voltage/frequency is controlled by SCP
(it's an SoC's internal hardware IP, right?),
it's good to have a userspace governer
with the driver not accepting updates from userspace.
E.g., Let "target" callback not update the frequency value,
or let "target" callback always return an error with
a dev_err message that you don't accept frequency changes
from userspace.
Thanks for the input. Will implement something similar to
what you suggested for the next re-spin.
-Sibi
Cheers,
MyungJoo.
