On 5/27/20 2:22 PM, Vincent Guittot wrote: > On Wed, 27 May 2020 at 13:17, Benjamin GAIGNARD > <benjamin.gaignard@xxxxxx> wrote: >> >> >> On 5/27/20 12:09 PM, Valentin Schneider wrote: >>> Hi Benjamin, >>> >>> On 26/05/20 16:16, Benjamin Gaignard wrote: >>>> 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. >>>> >>> Apologies for sleeping on that previous thread. >>> >>> So what had been suggested over there was to use uclamp to boost the >>> frequency of the handling thread; however if you use threaded IRQs you >>> get RT threads, which already get the max frequency by default (at least >>> with schedutil). >>> >>> Does that not work for you, and if so, why? >> That doesn't work because almost everything is done by the hardware blocks >> without charge the CPU so the thread isn't running. I have done the >> tests with schedutil >> and ondemand scheduler (which is the one I'm targeting). I have no >> issues when using >> performance scheduler because it always keep the highest frequencies. > IMHO, the only way to ensure a min frequency for anything else than a > thread is to use freq_qos_add_request() just like cpufreq cooling > device but for the opposite QoS. This can be applied only on the > frequency domain of the CPU which handles the interrupt. I will give a try with this idea. Thanks. > Have you also checked the wakeup latency of your idle state ? It just could go in WFI so latency should be minimal. > >> >>>> 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(+)
