[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <525ef5cdefe987c3412249760324eb09.sboyd@kernel.org>
Date: Wed, 25 Jan 2023 13:56:09 -0800
From: Stephen Boyd <sboyd@...nel.org>
To: Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Jassi Brar <jassisinghbrar@...il.com>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Michael Turquette <mturquette@...libre.com>,
Rob Herring <robh+dt@...nel.org>,
Taniya Das <quic_tdas@...cinc.com>
Cc: linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 7/7] clk: qcom: add the driver for the MSM8996 APCS clocks
Quoting Konrad Dybcio (2023-01-25 13:48:54)
>
>
> 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..
So it is waiting for the CPU clk to be stable? The comment is not clear.
Powered by blists - more mailing lists