[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200424114058.21199-1-benjamin.gaignard@st.com>
Date: Fri, 24 Apr 2020 13:40:55 +0200
From: Benjamin Gaignard <benjamin.gaignard@...com>
To: <rjw@...ysocki.net>, <viresh.kumar@...aro.org>,
<hugues.fruchet@...com>, <mchehab@...nel.org>,
<mcoquelin.stm32@...il.com>, <alexandre.torgue@...com>,
<pavel@....cz>, <len.brown@...el.com>
CC: <linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-media@...r.kernel.org>,
<linux-stm32@...md-mailman.stormreply.com>,
<linux-arm-kernel@...ts.infradead.org>,
Benjamin Gaignard <benjamin.gaignard@...com>
Subject: [RFC 0/3] Introduce cpufreq minimum load QoS
When start streaming from the sensor the CPU load could remain very low
because almost all the capture pipeline is done in hardware (i.e. without
using the CPU) and let believe to cpufreq governor that it could use lower
frequencies. If the governor decides to use a too low frequency that
becomes a problem when we need to acknowledge the interrupt during the
blanking time.
The delay to ack the interrupt and perform all the other actions before
the next frame is very short and doesn't allow to the cpufreq governor to
provide the required burst of power. That led to drop the half of the frames.
To avoid this problem, DCMI driver informs the cpufreq governors by adding
a cpufreq minimum load QoS resquest.
Benjamin Gaignard (3):
PM: QoS: Introduce cpufreq minimum load QoS
cpufreq: governor: Use minimum load QoS
media: stm32-dcmi: Inform cpufreq governors about cpu load needs
drivers/cpufreq/cpufreq_governor.c | 5 +
drivers/media/platform/stm32/stm32-dcmi.c | 8 ++
include/linux/pm_qos.h | 12 ++
kernel/power/qos.c | 213 ++++++++++++++++++++++++++++++
4 files changed, 238 insertions(+)
--
2.15.0
Powered by blists - more mailing lists