On Mon, Aug 26, 2024 at 04:25:39PM +0530, Imran Shaik wrote:
>
>
> On 8/23/2024 1:29 AM, Andrew Lunn wrote:
> > > +static int gcc_qcs8300_probe(struct platform_device *pdev)
> > > +{
> > > + struct regmap *regmap;
> > > + int ret;
> > > +
> > > + regmap = qcom_cc_map(pdev, &gcc_qcs8300_desc);
> > > + if (IS_ERR(regmap))
> > > + return PTR_ERR(regmap);
> > > +
> > > + ret = qcom_cc_register_rcg_dfs(regmap, gcc_dfs_clocks,
> > > + ARRAY_SIZE(gcc_dfs_clocks));
> > > + if (ret)
> > > + return ret;
> > > +
> > > + /* Keep some clocks always enabled */
> >
> > Sorry, but you need to explain why. Why cannot the camera driver
> > enable these clocks when it loads? Why cannot the display driver
> > enable these clocks when it loads.
> >
>
> These clocks are recommended to be kept always ON as per the HW design and
> also exposing clock structures and marking them critical in the kernel would
> lead to redundant code. Based on previous discussions with clock
> maintainers, it is recommended to keep such clocks enabled at probe and not
> model them. This approach is consistently followed for all other targets as
> well.
I don't see why it would add redundant code. It is a few lines of code
in the driver, which every driver using clocks has. If you really
don't want the clock turned off because it is unused, you can use
CLK_IGNORE_UNUSED, along with a comment explaining why.
What i was actually guessing is that you don't actually have open
drivers for these hardware blocks, just a blob running in user
space. As such, it cannot turn the clocks on. If that is the case, i
would much prefer you are honest about this, and document it.
Andrew
