From: "Inbaraj E" <inbaraj.e@samsung.com>
To: "'Krzysztof Kozlowski'" <krzk@kernel.org>,
"'Stephen Boyd'" <sboyd@kernel.org>, <alim.akhtar@samsung.com>,
<cw00.choi@samsung.com>, <linux-clk@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-samsung-soc@vger.kernel.org>, <mturquette@baylibre.com>,
<s.nawrocki@samsung.com>
Cc: <pankaj.dubey@samsung.com>, <gost.dev@samsung.com>
Subject: RE: [PATCH] clk: samsung: fsd: Mark PLL_CAM_CSI as critical
Date: Thu, 10 Oct 2024 16:15:51 +0530 [thread overview]
Message-ID: <08d001db1b01$94a9b9f0$bdfd2dd0$@samsung.com> (raw)
In-Reply-To: <2b3566dd-71ac-4ef7-abdc-524277879aa6@kernel.org>
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: 01 October 2024 15:30
> To: Inbaraj E <inbaraj.e@samsung.com>; 'Stephen Boyd'
> <sboyd@kernel.org>; alim.akhtar@samsung.com; cw00.choi@samsung.com;
> linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org; linux-samsung-
> soc@vger.kernel.org; mturquette@baylibre.com; s.nawrocki@samsung.com
> Cc: pankaj.dubey@samsung.com; gost.dev@samsung.com
> Subject: Re: [PATCH] clk: samsung: fsd: Mark PLL_CAM_CSI as critical
>
> On 01/10/2024 11:24, Inbaraj E wrote:
> >>>>>>>> CSI stop streaming through pm_runtime_put system is getting
> >> halted.
> >>>>>>>> So marking PLL_CAM_CSI as critical to prevent disabling.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Inbaraj E <inbaraj.e@samsung.com>
> >>>>>>>> ---
> >>>>>>>
> >>>>>>> Please add a fixes tag. Although this is likely a band-aid fix
> >>>>>>> because marking something critical leaves it enabled forever.
> >>>>>>
> >>>>>> Sure, will add fixes tag. As per HW manual, this PLL_CAM_CSI is
> >>>>>> supplying clock even for CMU SFR access of CSI block, so we can't
> >>>>>> gate this.
> >>>>>
> >>>>> Hm, I am not so sure. The CMU driver should just take appropriate
> clock.
> >>>>> Sprinkling CLK_CRITICAL looks as substitute of missing clock
> >>>>> handling/
> >>>>
> >>>> As per HW design, PLL_CAM_CSI is responsible for suppling clock to
> >>>> CSI SFR, CMU SFR and some internal block of CAM_CSI. In this some
> >>>> of the clock is not handled by any driver but it is required for
> >>>> CSI to work properly. For example CSI NOC clock. So this is the
> >>>> reason we are
> >> marking PLL_CAM_CSI as critical.
> >>>>
> >>>
> >>> This is clock hierarchy for CMU_CAM_CSI block.
> >>>
> >>> PLL_CAM_CSI -----> DIVIDER --------> CSI_SFR clock
> >>> |
> >>> |----> DIVIDER --------> CMU_SFR clock
> >>> |
> >>> |----> DIVIDER --------> CSI NOC clock.
> >>>
> >>
> >> And what is the problem in adding proper handling in the driver? You
> >> just described case valid for 99% of SoC components.
> >
> > Hi Kryzstof,
> >
> > Sorry, but it seems I was not able to explain the issue. Let me add
> > more
> > details:
> > So for CSI IP we have two clocks as ACLK and PCLK which needs to be
> > handled by the driver during start and stop streaming.
> >
> > In BLK_CSI we have CSI IP along with other bunch supporting modules
> > such as CMU_CSI, NOC_CSI, CSI_SFR. For all these components of BLK_CSI
> > we have a single top level parent PLL clock as PLL_CAM_CSI.
> >
> > Now if we look into CSI driver perspective it needs only ACLK and PCLK
> > clocks for it's operations. But to access CMU SFRs (including
> > ACLK/PCLK or any other CMU SFR of BLK_CSI) we need parent clock keep
> > supplying clocks. While we try to gate ACLK clock, due to propagation
> > logic of clock gating the CCF scans all the clocks from leaf level to
> > the parent clock and tries to gate clocks if enable/disable ops is
> > valid for any such clock.
> >
> > Issue here is that we are trying to gate PLL_CAM_CSI which itself is
> > accessible only when this clock is enabled. In fact none of CMU_SFR
> > will be accessible as soon as PLL_CAM_CSI is gated. CSI driver is not
> > intended
>
> Obviously, but your CMU is taking the necessary clock and enabled it so what
> is the problem?
>
> > to gate this PLL clock but only the leaf level clock which is
> > supplying to CSI IP. So in absence of any alternate source of clock
> > hierarchy which can supply clock for CMU_CSI we can't gate PLL_CAM_CSI.
> >
> > Please let us know if you have any other queries why we are insisting
> > on marking PLL_CAM_CSI as CRITICAL clock.
>
> This is so far quite obvious - just like in all other cases, you need the top clock
> taken by proper driver. I don't think you are looking at right drivers and right
> problem here.
>
Hi Krzysztof,
In this case, platform driver need to get this PLL clock and keep it
enabled always. As PLL_CAM_CSI is source clock for accessing CMU
registers of CSI block, and PLL_CAM_CSI itself lies in CSI_CMU,
driver need to prepare and keep it enabled always. This way other PCLK
and ACLK clocks can be gated. But the PLL_CAM_CSI which is parent of the
PCLK and ACLK gate clock won't be disabled. Hope this should not be a
concern.
Regards,
Inbaraj E
> Best regards,
> Krzysztof
next prev parent reply other threads:[~2024-10-10 10:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20240917101102epcas5p3b17d2774cb74fd4cf61ea52fde85c300@epcas5p3.samsung.com>
2024-09-17 10:10 ` [PATCH] clk: samsung: fsd: Mark PLL_CAM_CSI as critical Inbaraj E
2024-09-19 10:21 ` Stephen Boyd
2024-09-19 11:33 ` Inbaraj E
2024-09-19 12:03 ` Krzysztof Kozlowski
2024-09-20 4:04 ` Inbaraj E
2024-09-20 4:15 ` Inbaraj E
2024-09-20 12:36 ` Krzysztof Kozlowski
2024-10-01 9:24 ` Inbaraj E
2024-10-01 10:00 ` Krzysztof Kozlowski
2024-10-10 10:45 ` Inbaraj E [this message]
2024-10-21 9:50 ` Krzysztof Kozlowski
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='08d001db1b01$94a9b9f0$bdfd2dd0$@samsung.com' \
--to=inbaraj.e@samsung.com \
--cc=alim.akhtar@samsung.com \
--cc=cw00.choi@samsung.com \
--cc=gost.dev@samsung.com \
--cc=krzk@kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=pankaj.dubey@samsung.com \
--cc=s.nawrocki@samsung.com \
--cc=sboyd@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.