Hi Alexander,
On Tue, Oct 17, 2023 at 03:54:36PM +0200, Alexander Stein wrote:
> From: Alexander Sverdlin <alexander.sverdlin@xxxxxxxxxxx>
>
> One of the reasons to do it is to save some CPU cycles on cpu_freq_get()
do what and how did you do it?
> under mutex. The second reason if the (false-positive) lockdep splat caused
> by the recursive feature of the "prepare_lock" (one clock instance is I2C
> peripheral clock and another is pcf85063 RTC as clock provider):
...
> + /*
> + * Lock the clock rate to avoid rate change between clk_get_rate() and
> + * atomic_set()
> + */
> + ret = clk_rate_exclusive_get(lpi2c_imx->clks[0].clk);
> + if (ret) {
> + dev_err(&pdev->dev, "can't lock I2C peripheral clock rate\n");
> + return ret;
return dev_err_probe() ?
> + }
> + atomic_set(&lpi2c_imx->rate_per, clk_get_rate(lpi2c_imx->clks[0].clk));
> + clk_rate_exclusive_put(lpi2c_imx->clks[0].clk);
> + if (!atomic_read(&lpi2c_imx->rate_per)) {
> + dev_err(&pdev->dev, "can't get I2C peripheral clock rate\n");
return dev_err_probe() ?
> + return -EINVAL;
> + }
