[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c118f69d-db32-4544-83d5-14de089d5b51@sirena.org.uk>
Date: Thu, 20 Jul 2023 16:46:06 +0100
From: Mark Brown <broonie@...nel.org>
To: Martin Kurbanov <mmkurbanov@...rdevices.ru>
Cc: Jerome Brunet <jbrunet@...libre.com>,
Neil Armstrong <neil.armstrong@...aro.org>,
Andy Shevchenko <andy.shevchenko@...il.com>,
linux-spi@...r.kernel.org, linux-amlogic@...ts.infradead.org,
linux-kernel@...r.kernel.org, kernel@...rdevices.ru
Subject: Re: [PATCH v2 2/2] spi: amlogic-spifc-a1: add support for
max_speed_hz
On Thu, Jul 20, 2023 at 06:41:11PM +0300, Martin Kurbanov wrote:
> On 11.07.2023 10:25, Jerome Brunet wrote:
> >> + ret = clk_set_rate(spifc->clk, freq);
> >> + if (ret)
> >> + return ret;
> >> + spifc->curr_speed_hz = freq;
> > There is no guarantee that clk_set_rate() has set the rate you have
> > requested, at least not precisely. You should call clk_get_rate() here.
> Are you referring to a situation where there is a change in the rate due
> to a request from another client, such as a sibling driver with the same
> parent clock?
The clock may simply not be able to generate exactly the rate you
requested, the rate will be rounded to some value that the clock can
actually generate.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists