Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp300292ybg; Wed, 3 Jun 2020 00:52:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJye4eGqzqMtPD1NsKpx79bd7qUCNY58CSA49nT/iiDCVq7jZBFWFdS27/uA2yR2Ta5auLji X-Received: by 2002:a17:906:f0e:: with SMTP id z14mr26011049eji.375.1591170751563; Wed, 03 Jun 2020 00:52:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591170751; cv=none; d=google.com; s=arc-20160816; b=D0vAbY30IgrH9pjMTfIfOa240ZeDJC6PCIAGtewlqbwUvoXJm5OcitCVmEyXHgd798 N2OAa3Jg+abfeWxu3D9qFZ3qy0unDDsIbngfdE+SDV160Oz6NxTjSuCzlYnU/5vUqdPY KbEz4lcp1cfZT5w1WHi5on0Y4R1O1vTQl1+0F09d1wQV+qXhQL7sCHMnfQL8A9aXU8iQ P1lvdsyRVyZniuGWLtoRVMddWg8jv9S7UpVefbIJi6ejrjTVoWC4SCf5L54fq5OaKA0l x6eWzMkIeRGN8K3jqsUa3QWiNhgQyrO1cIEIOS9GQtOo3VhHefP3+hLhSlWiP78tFW71 jNPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=RI6iXB0qMqr3xlMnwnNSpUiS3SZYn3+NS4HUs4hvuFk=; b=urzHzVJonsGrB8QmEUVYD9LiRmT83vaQEuGp7w1uH+20MrvObQLqz3SVzsjK4Jly/i RWezUHmziRyhpPj+6pZc7BuFaYWJaSXUi1U+ABmDzEx78SxirxQa/UKYj3X9t/yt3xtX yhv02/J0JBUSBShdSN5gTtk+5uZgqlFTcNWaywFtOua8J+7ZN0d2FsyCCuah8be84FP5 sNaXeRiiheI1nDkhvxBfYcS0RME7YOAz0D9hTqCthduY9ezjzyMaZYG8eakwVuxsfG72 rCz2JyhcFfx7fG08KYvN8gxl6bx/vNAYuLIKFUDKCkhTwe30XCli8OrxLlsw+o/mkSUY PA/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Bv2NGZRk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w4si678257edj.532.2020.06.03.00.52.08; Wed, 03 Jun 2020 00:52:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Bv2NGZRk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725954AbgFCHuV (ORCPT + 99 others); Wed, 3 Jun 2020 03:50:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50666 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725828AbgFCHuU (ORCPT ); Wed, 3 Jun 2020 03:50:20 -0400 Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF181C05BD1E for ; Wed, 3 Jun 2020 00:50:19 -0700 (PDT) Received: by mail-lf1-x143.google.com with SMTP id 202so702285lfe.5 for ; Wed, 03 Jun 2020 00:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RI6iXB0qMqr3xlMnwnNSpUiS3SZYn3+NS4HUs4hvuFk=; b=Bv2NGZRkizy50GG012REDa+Ac6WD7Cdlhp9SBQUZne2ONByEmjbrF1ObuaG8BusUuc tT4fFF6bOT7sbpGB8srbSU8sAzLauoqfKgAnHEMe+Njoiq8cN8L4/OILOwpNPvXxVoRH Pnb1931Hl0DGZD17DmZWdVQg3OicSRvDhOV3hpc3knBMfWL7aYPz7QcGjsOC6+dIYy1Z BBA8Nzqwm/A2HE/lLI5xIt/BnG1w3KfdtF35Eoo4b/oIXYE9IQp3jdFlXdXmLTzZjFuK x6SKMLDcFQfsamwJtMSktvo/Ma8v/iZmfw/yQqiVXjsUKZjmCLRSvusNarN0vntWMQ8c P4bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RI6iXB0qMqr3xlMnwnNSpUiS3SZYn3+NS4HUs4hvuFk=; b=ON1BQmMu/OKsaZM2hfl7l1h38PqAx6KdPyWwDYRUyYCn1bVwCOmP5jY6pOoATE9OQu 5Jll306Rq/nkVH+hSpSDXdqiKMWkjZAQRjUZzTPPcNQTLb8+JQdYqLTu6Hev1TQPG7ze 3+xKfS6rg4JjT57pk+HAQBwNF1wpvvLAnJNStht+mrIzKplMiLmq+hi/rqmrdc+Vxlvf v5fZ9mzD7XgzysJmUNzHnfma/llig0O1tYdlg2kA3Ar3RQ7cPgC8scshS6AMPoilzA3L KS5JCl1Rgxuk5Xjv16JVe7rgbpni7HmcDa8EFwzUenUuvyGwmVS159IKIqaj61bJqfjU +xdg== X-Gm-Message-State: AOAM531Dx3fmwNT7Tkyr30KwFjLlworlZ+Kqf/8j+vaPMpiv4nfheP96 WJFRbhgWwd6l/Ph1Je2hNkYElXZm6dIK81VZ75vF2g== X-Received: by 2002:a19:5013:: with SMTP id e19mr1725514lfb.95.1591170618304; Wed, 03 Jun 2020 00:50:18 -0700 (PDT) MIME-Version: 1.0 References: <20200527151613.16083-1-benjamin.gaignard@st.com> <1b0ace18-e7f8-0b75-f6fe-968a269626b0@st.com> In-Reply-To: <1b0ace18-e7f8-0b75-f6fe-968a269626b0@st.com> From: Vincent Guittot Date: Wed, 3 Jun 2020 09:50:06 +0200 Message-ID: Subject: Re: [PATCH] media: stm32-dcmi: Set minimum cpufreq requirement To: Benjamin GAIGNARD Cc: Valentin Schneider , Hugues FRUCHET , "mchehab@kernel.org" , "mcoquelin.stm32@gmail.com" , Alexandre TORGUE , "linux-media@vger.kernel.org" , "linux-stm32@st-md-mailman.stormreply.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "rjw@rjwysocki.net" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 3 Jun 2020 at 09:34, Benjamin GAIGNARD wrote: > > > > On 6/2/20 3:35 PM, Valentin Schneider wrote: > > On 02/06/20 12:37, Benjamin GAIGNARD wrote: > >> On 6/2/20 11:31 AM, Valentin Schneider wrote: > >>>> @@ -99,6 +100,8 @@ enum state { > >>>> > >>>> #define OVERRUN_ERROR_THRESHOLD 3 > >>>> > >>>> +#define DCMI_MIN_FREQ 650000 /* in KHz */ > >>>> + > >>> This assumes the handling part is guaranteed to always run on the same CPU > >>> with the same performance profile (regardless of the platform). If that's > >>> not guaranteed, it feels like you'd want this to be configurable in some > >>> way. > >> Yes I could add a st,stm32-dcmi-min-frequency (in KHz) parameter the > >> device tree node. > >> > > Something like that - I'm not sure how well this fits with the DT > > landscape, as you could argue it isn't really a description of the > > hardware, more of a description of the performance expectations of the > > software. I won't really argue here. > > > >>>> struct dcmi_graph_entity { > >>>> struct v4l2_async_subdev asd; > >>>> > >>> [...] > >>>> @@ -2020,6 +2042,8 @@ static int dcmi_probe(struct platform_device *pdev) > >>>> goto err_cleanup; > >>>> } > >>>> > >>>> + dcmi->policy = cpufreq_cpu_get(0); > >>>> + > >>> Ideally you'd want to fetch the policy of the CPU your IRQ (and handling > >>> thread) is affined to; The only compatible DTS I found describes a single > >>> A7, which is somewhat limited in the affinity area... > >> If I move this code just before start streaming and use get_cpu(), would > >> it works ? > >> > > AFAIA streaming_start() is not necessarily executing on the same CPU as the > > one that will handle the interrupt. I was thinking you could use the IRQ's > > effective affinity as a hint of which CPU(s) to boost, i.e. something like: > > > > --- > > struct cpumask_var_t visited; > > struct irq_data *d = irq_get_irq_data(irq); > > > > err = alloc_cpumask_var(visited, GFP_KERNEL); > > /* ... */ > > for_each_cpu(cpu, irq_data_get_effective_affinity_mask(d)) { > > /* check if not already spanned */ > > if (cpumask_test_cpu(cpu, visited)) > > continue; > > > > policy = cpufreq_cpu_get(cpu); > > cpumask_or(visited, visited, policy->cpus); > > /* do the boost for that policy here */ > > /* ... */ > > cpufreq_cpu_put(policy); > > } > > --- > > > > That of course falls apart when hotplug gets involved, and the effective > > affinity changes... There's irq_set_affinity_notifier() out there, but it > > seems it's only about the affinity, not the effective_affinity, I'm not > > sure how valid it would be to query the effective_affinity in that > > notifier. > If I wait to be in the irq it will be too late so I think I will do a > loop over all possible CPUs > before start the streaming to change the policies. Can't you use irq_get_affinity_mask and loop over it ? Also You should better use freq_qos_add/remove_request during probe and remove of the driver and use freq_qos_update_request in dcmi_start/stop_streaming to set/unset your constraint. > > > > >> Benjamin > >>>> dev_info(&pdev->dev, "Probe done\n"); > >>>> > >>>> platform_set_drvdata(pdev, dcmi); > >>>> @@ -2049,6 +2073,9 @@ static int dcmi_remove(struct platform_device *pdev) > >>>> > >>>> pm_runtime_disable(&pdev->dev); > >>>> > >>>> + if (dcmi->policy) > >>>> + cpufreq_cpu_put(dcmi->policy); > >>>> + > >>>> v4l2_async_notifier_unregister(&dcmi->notifier); > >>>> v4l2_async_notifier_cleanup(&dcmi->notifier); > >>>> media_entity_cleanup(&dcmi->vdev->entity);