On 2/22/19 19:11, Stephen Boyd wrote:
> Quoting Jorge Ramirez-Ortiz (2019-01-28 10:32:52)
>> @@ -61,6 +65,25 @@ static int qcom_apcs_msm8916_clk_probe(struct platform_device *pdev)
>> if (!a53cc)
>> return -ENOMEM;
>>
>> + /* check if the parent names are present in the device tree */
>
> This looks odd.
>
>> + ret = devm_clk_bulk_get(parent, ARRAY_SIZE(pclks), pclks);
>> + if (ret == -EPROBE_DEFER)
>> + return ret;
>
> Why can't we use of_clk_parent_fill() if we know this is always a DT
> platform? The parent clks may not be registered at the time of probe?
yes, and AFAICS the important thing at this point is that the clock is
registered hence the handling of defer.
I could use of_clk_parent_fill and then - if needed - call
devm_clk_bulk_get but I am not sure of the gains of doing it (wouldnt
this just make the code more confusing?)
> Maybe this series should wait for the parent registration stuff I'm
> working on so that this can be made simpler.
the need for the clock name is not intrinsic to this driver (the driver
itself doesnt use these names) but it just feeds these to the framework.
I was looking into your parent registration code and I am not sure how
can I use it in this particular driver other than simply removing the
names and hoping that things are handled properly at the lower
levels.... could you clarify please?
>
>> +
>> + if (!ret) {
>> + gpll0_a53cc[0] = __clk_get_name(pclks[0].clk);
>> + gpll0_a53cc[1] = __clk_get_name(pclks[1].clk);
>> + a53cc->pclk = pclks[1].clk;
>> + } else {
>> + /* support old binding where only pll was explicitily defined */
>> + a53cc->pclk = devm_clk_get(parent, NULL);
>> + if (IS_ERR(a53cc->pclk)) {
>> + ret = PTR_ERR(a53cc->pclk);
>> + dev_err(dev, "failed to get clk: %d\n", ret);
>> + return ret;
>> + }
>> + }
>> +
>> init.name = "a53mux";
>> init.parent_names = gpll0_a53cc;
>> init.num_parents = ARRAY_SIZE(gpll0_a53cc);
>
