Hi Marc, Am Freitag, 21. April 2023, 15:59:52 CEST schrieb Marc Kleine-Budde: > * PGP Signed by an unknown key > > On 21.04.2023 15:48:59, Alexander Stein wrote: > [...] > > > Now lpi2c_runtime_resume will call into clk_prepare() which also calls > > clk_prepare_lock() (identical to clk_get_rate). > > IIRC this is a general problem^w limitation of the clock framework, > clock providers cannot use clocks themselves in certain callback, e.g. > set_rate. Well, that's essentially impossible when this clock provider is attached via i2c. i2c transfers potentially need to change or prepare clocks. One problem is that during clock registration (__clk_core_init) in the call to clk_ops.recalc_rate an i2c transfer is issued (via regmap). This is the inverse lock order to a regular transfer runtime resuming the i2c master and preparing the clocks. While looking at this, is_prepared is also affected by this. It's reading a register, thus issuing a i2c transfer. But this function can also be called from within clk_unprepare_unused_subtree, which holds clk_prepare_lock as well. This might be avoided by using regcache, but I'm not really sure this catches every case. Best regards, Alexander -- TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany Amtsgericht München, HRB 105018 Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider http://www.tq-group.com/
