On Thu, Jul 30, 2020 at 09:35:42PM +0800, Dongdong Yang wrote: > From: Dongdong Yang <yangdongdong@xxxxxxxxxx> > > This patch provides USF(User Sensitive Feedback factor) > auxiliary cpufreq governor to support high level layer > sysfs inodes setting for utils adjustment purpose from > the identified scenario on portable equipment. > Because the power consumption and UI response are more > cared for by portable equipment users. And the "screen > off" status stands for no request from the user, however, > the kernel is still expected to notify the user in time > on modem, network or powerkey events occur. USF provides > "sched_usf_non_ux_r" sysfs inode to cut down the utils > from user space tasks according to high level scenario. > In addition, it usually hints more cpufreq demand that > the preemptive counts of the tasks on the cpu burst and > over the user expecting completed time such as the ratio > sysctl_sched_latency to sysctl_sched_min_granularity > on "screen on" status, which more likely with more UI. > The sysfs inodes "sched_usf_up_l0_r" and "sched_usf_down_r" > have been provided to adjust the utils according to high > level identified scenario to alloc the cpufreq in time. > > Dongdong Yang (1): > sched: Provide USF for portable equipment. > > drivers/staging/Kconfig | 2 + > drivers/staging/Makefile | 1 + > drivers/staging/fbsched/Kconfig | 10 ++ > drivers/staging/fbsched/Makefile | 2 + > drivers/staging/fbsched/usf.c | 351 +++++++++++++++++++++++++++++++++++++++ > kernel/sched/cpufreq_schedutil.c | 11 +- > 6 files changed, 376 insertions(+), 1 deletion(-) > create mode 100644 drivers/staging/fbsched/Kconfig > create mode 100644 drivers/staging/fbsched/Makefile > create mode 100644 drivers/staging/fbsched/usf.c For new staging drivers/code, we need a TODO file that lists what remains to be done on the code to get it out of staging/ I don't see any good reason why this has to go to staging now, what prevents it from being merged to the "real" part of the kernel today? thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
