[question] [Exynos850] ACPM firmware doesn't implement ->recalc_rate for acpm clocks

[Alexey Klimov]

Hi all,

I'm working on Exynos850 platform support and currently trying to deal with
ACPM firmware clocks. ACPM is firmware running on separate co-processor
(like SCPI/SCMI thingy for instance).

Unlike gs101, the ACPM firmware clocks protocol on Exynos850 does not
implement get_rate() ACPM IPC call. Set_rate works fine, but get_rate
returns 0. Downstream reads MMIO registers directly to obtain the rate for
these clocks.

The file is drivers/clk/samsung/clk-acpm.c
static const struct clk_ops acpm_clk_ops = {
	.recalc_rate = acpm_clk_recalc_rate, <-- not impl by firmware
	.determine_rate = acpm_clk_determine_rate,
	.set_rate = acpm_clk_set_rate,
};

Currently I made ACPM clocks childs of corresponding parent clocks, for
instance, for CPU clocks:
	clocks = <&cmu_cpucl0 CLK_FOUT_CPUCL0_PLL>,
		 <&cmu_cpucl1 CLK_FOUT_CPUCL1_PLL>;
	clock-names = "cpucl0", "cpucl1";
and just return parent_rate from ->recalc_rate().

The problem is that stale (cached) value is returned all the time despite
CLK_GET_RATE_NOCACHE. I tried different approaches but don't see smth
upstreameable because clock rates are changed behind Linux and I need
to trigger something like clk_get_rate(parent_clock) to let the new rate
propagate down the tree.

Which pattern is preferred for upstream acceptance here?

1. Return parent_rate as is and live with stale parent rate.
2. Cache the set value in ->set_rate() and return it in ->recalc_rate().
3. Utilise clock rate change notifiers somehow and upon POST_RATE_CHANGE
   do smth like clk_set_rate(parent, new_rate) but that probably breaks
   locking and mixes clk-provider with clk-consumer.
4. Maybe use/play with CLK_SET_RATE_PARENT?

Or something else?
Best regards,
Alexey