[PATCH v6 1/1] i2c: lpi2c: cache peripheral clock rate

[Andi Shyti]

Hi Alexander,

On Tue, Oct 17, 2023 at 03:54:36PM +0200, Alexander Stein wrote:
> From: Alexander Sverdlin <alexander.sverdlin at siemens.com>
> 
> 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;
> +	}