A first round [1] of discussions and suggestions have already be done on this series but without found a solution to the problem. I resend it to progress on this topic. 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 [1] https://lkml.org/lkml/2020/4/24/360 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
