@@ -24,6 +24,7 @@
#include <linux/of_graph.h>
#include <linux/pinctrl/consumer.h>
#include <linux/platform_device.h>
+#include <linux/pm_qos.h>
#include <linux/pm_runtime.h>
#include <linux/reset.h>
#include <linux/videodev2.h>
@@ -173,6 +174,8 @@ struct stm32_dcmi {
struct media_device mdev;
struct media_pad vid_cap_pad;
struct media_pipeline pipeline;
+
+ struct pm_qos_request qos_request;
};
static inline struct stm32_dcmi *notifier_to_dcmi(struct v4l2_async_notifier *n)
@@ -827,6 +830,9 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
else
reg_set(dcmi->regs, DCMI_IER, IT_OVR | IT_ERR);
+ cpufreq_minload_qos_add_request(&dcmi->qos_request,
+ CPUFREQ_GOV_QOS_MIN_LOAD_MAX_VALUE);
+
return 0;
err_pipeline_stop:
@@ -859,6 +865,8 @@ static void dcmi_stop_streaming(struct vb2_queue *vq)
struct stm32_dcmi *dcmi = vb2_get_drv_priv(vq);
struct dcmi_buf *buf, *node;
+ cpufreq_minload_qos_remove_request(&dcmi->qos_request);
+
dcmi_pipeline_stop(dcmi);
media_pipeline_stop(&dcmi->vdev->entity);
When start streaming 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. To avoid this problem, DCMI driver informs the cpufreq governors by adding a cpufreq minimum load QoS resquest. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com> --- drivers/media/platform/stm32/stm32-dcmi.c | 8 ++++++++ 1 file changed, 8 insertions(+)