Re: [PATCH v2 05/10] clk: qcom: Fix sc7180 dispcc parent data

From: Doug Anderson
Date: Thu Jan 30 2020 - 16:27:02 EST


Hi,

On Tue, Jan 28, 2020 at 4:51 PM Stephen Boyd <sboyd@xxxxxxxxxx> wrote:
>
> Quoting Douglas Anderson (2020-01-24 14:42:20)
> >
> > diff --git a/drivers/clk/qcom/dispcc-sc7180.c b/drivers/clk/qcom/dispcc-sc7180.c
> > index 30c1e25d3edb..380eca3f847d 100644
> > --- a/drivers/clk/qcom/dispcc-sc7180.c
> > +++ b/drivers/clk/qcom/dispcc-sc7180.c
> > @@ -76,40 +76,32 @@ static struct clk_alpha_pll_postdiv disp_cc_pll0_out_even = {
> >
> > static const struct parent_map disp_cc_parent_map_0[] = {
> > { P_BI_TCXO, 0 },
> > - { P_CORE_BI_PLL_TEST_SE, 7 },
> > };
> >
> > static const struct clk_parent_data disp_cc_parent_data_0[] = {
> > - { .fw_name = "bi_tcxo" },
> > - { .fw_name = "core_bi_pll_test_se", .name = "core_bi_pll_test_se" },
> > + { .fw_name = "xo" },
>
> If we can make the binding match the code here and keep saying "bi_tcxo"
> then that is preferred. That way we don't have to see bi_tcxo changing
> and qcom folks are happy to keep the weird name. The name in the binding
> is really up to the binding writer.

v3 is now out and it still says "bi_tcxo" and generally uses the
"internal" name. The big exception is msm8998's gpucc. It seems like
a whole bunch of work has been done to move that over to more "purist"
(AKA logical) names and I didn't want to undo that work. If we should
move msm8998 to match everyone else then hopefully someone can do it
as a followup patch?


> > };
> >
> > static const struct parent_map disp_cc_parent_map_1[] = {
> > { P_BI_TCXO, 0 },
> > { P_DP_PHY_PLL_LINK_CLK, 1 },
> > { P_DP_PHY_PLL_VCO_DIV_CLK, 2 },
> > - { P_CORE_BI_PLL_TEST_SE, 7 },
> > };
> [...]
> > @@ -203,7 +188,7 @@ static struct clk_rcg2 disp_cc_mdss_dp_aux_clk_src = {
> > .clkr.hw.init = &(struct clk_init_data){
> > .name = "disp_cc_mdss_dp_aux_clk_src",
> > .parent_data = disp_cc_parent_data_0,
> > - .num_parents = 2,
> > + .num_parents = ARRAY_SIZE(disp_cc_parent_data_0),
>
> Can you split this ARRAY_SIZE() stuff to another patch? That will keep
> focus on what's relevant here without distracting from the patch
> contents. I know that parent array size is changing, but I don't want it
> to be changing this line too.

It has been done.

-Doug