| Message ID | 20200708110725.18017-2-sudeep.holla@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] firmware: arm_scmi: Keep the discrete clock rates sorted | expand |
On Wed, Jul 08, 2020 at 12:07:25PM +0100, Sudeep Holla wrote: > Currently we are not initializing the scmi clock with discrete rates > correctly. We fetch the min_rate and max_rate value only for clocks with > ranges and ignore the ones with discrete rates. This will lead to wrong > initialization of rate range when clock supports discrete rate. > > Fix this by using the first and the last rate in the sorted list of the > discrete clock rates while registering the clock. > > Fixes: 6d6a1d82eaef7 ("clk: add support for clocks provided by SCMI") > Reported-by: Dien Pham <dien.pham.ry@renesas.com> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > --- > drivers/clk/clk-scmi.c | 22 +++++++++++++++++++--- > 1 file changed, 19 insertions(+), 3 deletions(-) > > Hi Stephen, > > If you fine, I can take this via ARM SoC along with the change in firmware > driver. But it is fine if you want to merge this independently as it should > be fine. Let me know either way. > > Regards, > Sudeep > > diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c > index c491f5de0f3f..ea65b7bf1408 100644 > --- a/drivers/clk/clk-scmi.c > +++ b/drivers/clk/clk-scmi.c > @@ -103,6 +103,8 @@ static const struct clk_ops scmi_clk_ops = { > static int scmi_clk_ops_init(struct device *dev, struct scmi_clk *sclk) > { > int ret; > + unsigned long min_rate, max_rate; > + > struct clk_init_data init = { > .flags = CLK_GET_RATE_NOCACHE, > .num_parents = 0, > @@ -112,9 +114,23 @@ static int scmi_clk_ops_init(struct device *dev, struct scmi_clk *sclk) > > sclk->hw.init = &init; > ret = devm_clk_hw_register(dev, &sclk->hw); > - if (!ret) > - clk_hw_set_rate_range(&sclk->hw, sclk->info->range.min_rate, > - sclk->info->range.max_rate); > + if (ret) > + return ret; > + > + if (sclk->info->rate_discrete) { > + int num_rates = sclk->info->list.num_rates; > + > + if (num_rates <= 0) > + return -EINVAL; > + > + min_rate = sclk->info->list.rates[0] I seem to have sent a version with ; missing above though I fixed but sent the old stale version as I had written a note to you
diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c index c491f5de0f3f..ea65b7bf1408 100644 --- a/drivers/clk/clk-scmi.c +++ b/drivers/clk/clk-scmi.c @@ -103,6 +103,8 @@ static const struct clk_ops scmi_clk_ops = { static int scmi_clk_ops_init(struct device *dev, struct scmi_clk *sclk) { int ret; + unsigned long min_rate, max_rate; + struct clk_init_data init = { .flags = CLK_GET_RATE_NOCACHE, .num_parents = 0, @@ -112,9 +114,23 @@ static int scmi_clk_ops_init(struct device *dev, struct scmi_clk *sclk) sclk->hw.init = &init; ret = devm_clk_hw_register(dev, &sclk->hw); - if (!ret) - clk_hw_set_rate_range(&sclk->hw, sclk->info->range.min_rate, - sclk->info->range.max_rate); + if (ret) + return ret; + + if (sclk->info->rate_discrete) { + int num_rates = sclk->info->list.num_rates; + + if (num_rates <= 0) + return -EINVAL; + + min_rate = sclk->info->list.rates[0] + max_rate = sclk->info->list.rates[num_rates - 1]; + } else { + min_rate = sclk->info->range.min_rate; + max_rate = sclk->info->range.max_rate; + } + + clk_hw_set_rate_range(&sclk->hw, min_rate, max_rate); return ret; }
Currently we are not initializing the scmi clock with discrete rates correctly. We fetch the min_rate and max_rate value only for clocks with ranges and ignore the ones with discrete rates. This will lead to wrong initialization of rate range when clock supports discrete rate. Fix this by using the first and the last rate in the sorted list of the discrete clock rates while registering the clock. Fixes: 6d6a1d82eaef7 ("clk: add support for clocks provided by SCMI") Reported-by: Dien Pham <dien.pham.ry@renesas.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> --- drivers/clk/clk-scmi.c | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) Hi Stephen, If you fine, I can take this via ARM SoC along with the change in firmware driver. But it is fine if you want to merge this independently as it should be fine. Let me know either way. Regards, Sudeep -- 2.17.1