On Wed, 16 Jun 2021 at 18:07, Dmitry Baryshkov
<dmitry.baryshkov@xxxxxxxxxx> wrote:
> > diff --git a/drivers/clk/qcom/clk-rcg.h b/drivers/clk/qcom/clk-rcg.h
> > index 99efcc7f8d88..a1f05281d950 100644
> > --- a/drivers/clk/qcom/clk-rcg.h
> > +++ b/drivers/clk/qcom/clk-rcg.h
> > @@ -149,6 +149,10 @@ struct clk_rcg2 {
> > const struct freq_tbl *freq_tbl;
> > struct clk_regmap clkr;
> > u8 cfg_off;
> > + u8 flags;
> > +#define FORCE_ENABLE_RCG BIT(0)
> > +#define HW_CLK_CTRL_MODE BIT(1)
>
> Downstream also has these flags for 8250, but the upstream driver ended
> up not using them for the dispcc clocks. Could you please check that you
> realy need HW_CLK_CTRL for dispcc clocks?
HW_CLK_CTRL being flagged in dispcc causes the CFG_HW_CLK_CTRL flag to
be set in the RCG_CFG registers of dispcc.
This flag simply marks the clock as having hardware control enabled or disabled.
As for the question if it is really needed, I can't answer that since
no documentation or downstream comments explain the exact behaviour.
As far as I know the only way to figure out if it is required is
disabling the flag and checking for bugs. I did find this[1] patch,
which enabled HW_CLK_CTRL_MODE.
Should I err on the side of the downstream implementation, or try to
create a minimum functional driver based on the downstream driver?
[1] https://patchwork.kernel.org/project/linux-arm-msm/patch/1514877987-8082-2-git-send-email-anischal@xxxxxxxxxxxxxx/
