[PATCH clk-fixes v1 1/2] clk: composite: Also consider .determine_rate for rate + mux composites

Alex Bee knaerzche at gmail.com
Wed Oct 27 15:47:03 PDT 2021


Hi Stephen,

Am 18.10.21 um 22:01 schrieb Stephen Boyd:
> Quoting Martin Blumenstingl (2021-10-16 03:50:21)
>> Commit 69a00fb3d69706 ("clk: divider: Implement and wire up
>> .determine_rate by default") switches clk_divider_ops to implement
>> .determine_rate by default. This breaks composite clocks with multiple
>> parents because clk-composite.c does not use the special handling for
>> mux + divider combinations anymore (that was restricted to rate clocks
>> which only implement .round_rate, but not .determine_rate).
>>
>> Alex reports:
>>   This breaks lot of clocks for Rockchip which intensively uses
>>   composites,  i.e. those clocks will always stay at the initial parent,
>>   which in some cases  is the XTAL clock and I strongly guess it is the
>>   same for other platforms,  which use composite clocks having more than
>>   one parent (e.g. mediatek, ti ...)
>>
>>   Example (RK3399)
>>   clk_sdio is set (initialized) with XTAL (24 MHz) as parent in u-boot.
>>   It will always stay at this parent, even if the mmc driver sets a rate
>>   of  200 MHz (fails, as the nature of things), which should switch it
>>   to   any of its possible parent PLLs defined in
>>   mux_pll_src_cpll_gpll_npll_ppll_upll_24m_p (see clk-rk3399.c)  - which
>>   never happens.
>>
>> Restore the original behavior by changing the priority of the conditions
>> inside clk-composite.c. Now the special rate + mux case (with rate_ops
>> having a .round_rate - which is still the case for the default
>> clk_divider_ops) is preferred over rate_ops which have .determine_rate
>> defined (and not further considering the mux).
>>
>> Fixes: 69a00fb3d69706 ("clk: divider: Implement and wire up .determine_rate by default")
>> Reported-by: Alex Bee <knaerzche at gmail.com>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl at googlemail.com>
>> ---
> 
> Applied to clk-fixes

any chance this can make it in 5.15?

Regards,
Alex
> 



More information about the linux-arm-kernel mailing list