On 27/09/2019 02:14, Stephen Boyd wrote: > Quoting Neil Armstrong (2019-09-19 03:25:17) >> This introduces the clk_invalidate_rate() call used to recalculate the >> rate and parent tree of a particular clock if it's known that the >> underlying registers set has been altered by the firmware, like from >> a suspend/resume handler running in trusted cpu mode. >> >> The call refreshes the actual parent and when changed, instructs CCF >> the parent has changed. Finally the call will recalculate the rate of >> each part of the tree to make sure the CCF cached tree is in sync with >> the hardware. >> >> Signed-off-by: Neil Armstrong <[email protected]> >> --- > > The knee-jerk reaction to these patches is that it shouldn't be a > consumer API (i.e. taking a struct clk) but a provider API (i.e. taking > a struct clk_hw). I haven't looked in any more detail but just know that > it's a non-starter to be a consumer based API because we don't want > random consumers out there to be telling the CCF or provider drivers > that some clk has lost state and needs to be "refreshed". >
Totally agree, I hesitated and obviously did the wrong choice, but this is a nit, the main algorithm is not tied to the API level. Should I resend it with clk_hw ? the difference will be small and the main subject is the resync algorithm. Neil
