On Wed, May 27, 2020 at 4:54 PM Benjamin GAIGNARD
[off-list ref] wrote:

On 5/27/20 2:48 PM, Benjamin GAIGNARD wrote:

quoted

On 5/27/20 2:22 PM, Vincent Guittot wrote:

quoted

On Wed, 27 May 2020 at 13:17, Benjamin GAIGNARD
[off-list ref] wrote:

quoted

On 5/27/20 12:09 PM, Valentin Schneider wrote:

quoted

Hi Benjamin,

On 26/05/20 16:16, Benjamin Gaignard wrote:

quoted

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.

Adding freq_qos_add_request(FREQ_QOS_MIN) when starting streaming frames
solve my problem. I remove the request at the end of the streaming to
restore
the default value.

You may as well add the request once at the init time with the request
value set to PM_QOS_MIN_FREQUENCY_DEFAULT_VALUE initially and update
it as needed going forward.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel