On 25.01.2023 22:38, Stephen Boyd wrote:
> Quoting Dmitry Baryshkov (2023-01-18 05:22:54)
>> diff --git a/drivers/clk/qcom/apcs-msm8996.c b/drivers/clk/qcom/apcs-msm8996.c
>> new file mode 100644
>> index 000000000000..7e46ea8ed444
>> --- /dev/null
>> +++ b/drivers/clk/qcom/apcs-msm8996.c
>> @@ -0,0 +1,76 @@
> [...]
>> +
>> +static int qcom_apcs_msm8996_clk_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct device *parent = dev->parent;
>> + struct regmap *regmap;
>> + struct clk_hw *hw;
>> + unsigned int val;
>> + int ret = -ENODEV;
>> +
>> + regmap = dev_get_regmap(parent, NULL);
>> + if (!regmap) {
>> + dev_err(dev, "failed to get regmap: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + regmap_read(regmap, APCS_AUX_OFFSET, &val);
>> + regmap_update_bits(regmap, APCS_AUX_OFFSET, APCS_AUX_DIV_MASK,
>> + FIELD_PREP(APCS_AUX_DIV_MASK, APCS_AUX_DIV_2));
>> +
>> + /* Hardware mandated delay */
>
> Delay for what? Setting the divider? What if the register value didn't
> change at all? Can you skip the delay in that case?
Waiting 5 us unconditionally in exchange for ensured CPU clock
source stability sounds like a rather fair deal.. Checking if
the register value changed would not save us much time..
Konrad
>
>> + udelay(5);
>> +
>> + /*
>> + * Register the clock as fixed rate instead of being a child of gpll0
>> + * to let the driver register probe as early as possible.
>
> The function doesn't block or return EPROBE_DEFER if the clk is orphaned
> when registered. Why is this necessary? Are you getting defered by the
> fw_devlink logic thinking it needs to defer probe of this driver until
> gpll0 provider probes? We should fix fw_devlink to not do that. Maybe if
> the node is a clk provider (#clock-cells exists) then we don't wait for
> clocks property to be provided, because the clk core already handles
> that itself.
>
>> + */
>> + hw = devm_clk_hw_register_fixed_rate(dev, "sys_apcs_aux", NULL, 0, 300000000);
