Hello Alexander, On Wed, Jan 17, 2024 at 08:02:19AM +0100, Alexander Stein wrote: > Am Donnerstag, 11. Januar 2024, 09:51:30 CET schrieb Uwe Kleine-König: > > On Wed, Jan 10, 2024 at 01:05:56PM +0100, Alexander Stein wrote: > > > + lpi2c_imx->clk_change_nb.notifier_call = lpi2c_imx_clk_change_cb; > > > + ret = devm_clk_notifier_register(&pdev->dev, lpi2c_imx->clks[0].clk, > > > + &lpi2c_imx->clk_change_nb); > > > + if (ret) > > > + return dev_err_probe(&pdev->dev, ret, > > > + "can't register peripheral clock notifier\n"); > > > + /* > > > + * 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) > > > + return dev_err_probe(&pdev->dev, ret, > > > + "can't lock I2C peripheral clock rate\n"); > > > + > > > + 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)) > > > + return dev_err_probe(&pdev->dev, -EINVAL, > > > + "can't get I2C peripheral clock rate\n"); > > > + > > > > If the clkrate isn't expected to actually change, you can just delay the > > call to clk_rate_exclusive_put() until driver unbind time and not > > register a notifier at all. The result would be more lightweight, you > > wouldn't even need an atomic variable for .rate_per. > > On imx93 I don't expect the parent clock rate to change, as each lpi2c > peripheral has its own dedicated root clock. > On imx8qxp and imx8qm lpi2c has it's own "clock tree", but these clocks are > managed by the system controller. > Now idea about imx95 as this one apparently uses SCMI based clock driver. > No idea about imx7ulp, imx8ulp and imx8dxl. Then maybe pick the easier approach and only start with a notifier when the need arises? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
