Re: [PATCH] i2c: jz4780: Cache clock rate at probe to prevent CCF prepare_lock deadlock

Hi Andi,

> Am 16.07.2026 um 00:07 schrieb Andi Shyti <[email protected]>:
> 
> Hi Nikolaus,
> 
> On Fri, Jul 10, 2026 at 08:58:35AM +0200, H. Nikolaus Schaller wrote:
>> Fix a severe AB/BA deadlock between the Common Clock Framework (CCF)
>> and the I2C adapter lock, which triggers when an I2C-controlled clock
>> generator (like the Si5351) is registered or modified under the CCF.
>> 
>> During a clock frequency change, the CCF acquires its global 'prepare_lock'
>> mutex and calls i2c_transfer() to update the chip registers, stalling
>> for the adapter's I2C bus lock.
> 
> I don't think caching the clock rate once at probe is safe.

Ok, valid point to discuss.


> If the controller clock rate changes afterwards,
> jz4780_i2c_set_speed() will keep using the stale cached value and
> calculate incorrect bus timings.

But: is clock rate ever changed during operation? Usually it is defined
by the device tree constant.

What is the API to change the clock rate during transfers? Is that even
possible?

BCM2835 appears to have a hackish solutions to register its own clock
divider and provides clk_bcm2835_i2c_set_rate(). This never happens
during normal i2c transfers so would not block.

OMAP does the same as we propose: call clk_get_rate() once during
probe inside omap_i2c_init() and never during omap_i2c_xfer_data().

Finally: how else can you prevent the synchronous call to clk_get_rate()
for each i2c transfer?

BR and thanks,
Nikolaus