From: Jordan Crouse <jorcrous@amazon.com>
To: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc: <linux-media@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Robert Foss <rfoss@kernel.org>, Todor Tomov <todor.too@gmail.com>,
<linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 2/2] media: camss: Avoid overwriting vfe clock rates for 8250
Date: Tue, 6 Aug 2024 22:38:26 +0000 [thread overview]
Message-ID: <20240806223822.GA24117@amazon.com> (raw)
In-Reply-To: <cc737b05-4476-4ded-9d1c-5924cfbce316@linaro.org>
On Fri, Aug 02, 2024 at 11:20:17PM +0100, Bryan O'Donoghue wrote:
>
> On 02/08/2024 16:24, Jordan Crouse wrote:
> >On sm8250 targets both the csid and vfe subsystems share a number of
> >clocks. Commit b4436a18eedb ("media: camss: add support for SM8250 camss")
> >reorganized the initialization sequence so that VFE gets initialized first
> >but a side effect of that was that the CSID subsystem came in after and
> >overwrites the set frequencies on the shared clocks.
> >
> >Empty the frequency tables for the shared clocks in the CSID resources so
> >they won't overwrite the clock rates that the VFE has already set.
> >
> >Signed-off-by: Jordan Crouse <jorcrous@amazon.com>
> >---
> >
> > drivers/media/platform/qcom/camss/camss.c | 21 +++++++++++++++------
> > 1 file changed, 15 insertions(+), 6 deletions(-)
> >
> >diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> >index 51b1d3550421..d78644c3ebe9 100644
> >--- a/drivers/media/platform/qcom/camss/camss.c
> >+++ b/drivers/media/platform/qcom/camss/camss.c
> >@@ -915,6 +915,15 @@ static const struct camss_subdev_resources csiphy_res_8250[] = {
> > }
> > };
> >
> >+/*
> >+ * Both CSID and VFE use some of the same vfe clocks and both
> >+ * should prepare/enable them but only the VFE subsystem should be in charge
> >+ * of setting the clock rates.
> >+ *
> >+ * Set the frequency tables for those clocks in the CSID resources to
> >+ * be empty so the csid subsystem doesn't overwrite the clock rates that the
> >+ * VFE already set.
> >+ */
> > static const struct camss_subdev_resources csid_res_8250[] = {
> > /* CSID0 */
> > {
> >@@ -922,8 +931,8 @@ static const struct camss_subdev_resources csid_res_8250[] = {
> > .clock = { "vfe0_csid", "vfe0_cphy_rx", "vfe0", "vfe0_areg", "vfe0_ahb" },
> > .clock_rate = { { 400000000 },
> > { 400000000 },
> >- { 350000000, 475000000, 576000000, 720000000 },
> >- { 100000000, 200000000, 300000000, 400000000 },
> >+ { 0 },
> >+ { 0 },
> > { 0 } },
> > .reg = { "csid0" },
> > .interrupt = { "csid0" },
> >@@ -939,8 +948,8 @@ static const struct camss_subdev_resources csid_res_8250[] = {
> > .clock = { "vfe1_csid", "vfe1_cphy_rx", "vfe1", "vfe1_areg", "vfe1_ahb" },
> > .clock_rate = { { 400000000 },
> > { 400000000 },
> >- { 350000000, 475000000, 576000000, 720000000 },
> >- { 100000000, 200000000, 300000000, 400000000 },
> >+ { 0 },
> >+ { 0 },
> > { 0 } },
> > .reg = { "csid1" },
> > .interrupt = { "csid1" },
> >@@ -956,7 +965,7 @@ static const struct camss_subdev_resources csid_res_8250[] = {
> > .clock = { "vfe_lite_csid", "vfe_lite_cphy_rx", "vfe_lite", "vfe_lite_ahb" },
> > .clock_rate = { { 400000000 },
> > { 400000000 },
> >- { 400000000, 480000000 },
> >+ { 0 },
> > { 0 } },
> > .reg = { "csid2" },
> > .interrupt = { "csid2" },
> >@@ -973,7 +982,7 @@ static const struct camss_subdev_resources csid_res_8250[] = {
> > .clock = { "vfe_lite_csid", "vfe_lite_cphy_rx", "vfe_lite", "vfe_lite_ahb" },
> > .clock_rate = { { 400000000 },
> > { 400000000 },
> >- { 400000000, 480000000 },
> >+ { 0 },
> > { 0 } },
> > .reg = { "csid3" },
> > .interrupt = { "csid3" },
>
> Hi Jordan.
>
> Thanks for your patch. Just looking at the clocks you are zeroing here,
> I think _probably_ these zeroized clocks can be removed from the CSID
> set entirely.
>
> Could you investigate that ?
I think that will work. It will cement the need for to VFE always run
first but we can add documentation warnings about that. It looks like
we can do this optimization for 845, sm8250 and sm2850xp.
>
> Also please add
>
> Fixes: b4436a18eedb ("media: camss: add support for SM8250 camss") and
> cc stable@vger.kernel.org
Will do.
Jordan
prev parent reply other threads:[~2024-08-06 22:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-02 15:24 [PATCH v1 0/2] media: camss: Fixups for large capture frames Jordan Crouse
2024-08-02 15:24 ` [PATCH v1 1/2] media: camss: Increase the maximum frame size Jordan Crouse
2024-08-06 23:09 ` Bryan O'Donoghue
2024-08-07 8:16 ` Bryan O'Donoghue
2024-12-06 14:51 ` Luca Weiss
2025-04-07 15:59 ` Bryan O'Donoghue
2024-08-02 15:24 ` [PATCH v1 2/2] media: camss: Avoid overwriting vfe clock rates for 8250 Jordan Crouse
2024-08-02 22:20 ` Bryan O'Donoghue
2024-08-06 22:38 ` Jordan Crouse [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240806223822.GA24117@amazon.com \
--to=jorcrous@amazon.com \
--cc=bryan.odonoghue@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=rfoss@kernel.org \
--cc=todor.too@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox