Re: [PATCH v7 3/8] cpufreq: kirkwood: Remove use of the clk provider API

[Andrew Lunn]

> One final thought I have had is that it might be a good idea to have a
> mux clock which represents the clock signal that feeds into the cpu. It
> seems that a mux is exactly what is going on here with cpuclk rate and
> ddrclk rate.

I did think of this when i implemented the cpufreq driver. What makes
it hard is that this bit is mixed in the same 32 bit register as the
gate clocks. It would mean two clock providers sharing the same
register, sharing a spinlock, etc. And the gating provider is shared
with all mvebu platforms, dove, kirkword, orion5x, and four different
armada SoCs. So i'm pushing complexity into this shared code, which
none of the others need. Does the standard mux clock do what is
needed? Or would i have to write a new clock provider?

> I even wonder if it is even appropriate to model this transition with a
> clock enable operation? Maybe it is only a multiplex operation, or
> perhaps a combination of enabling the powersave clock and changing the
> parent input to the cpu?
> 
> My idea is instead of relying on a cpufreq driver to parse the state of
> your clocks and understand the multiplexing, you can use the clock
> framework for that. In fact that might help you get one step closer to
> using the cpufreq-cpu0.c/cpufreq-generic.c implementation.

So you want the whole disabling of interrupt delivery to the cpu,
flipping the mux, wait for interrupt and re-enabling of interrupt
delivery to the cpu inside the clock provider? That is way past a
simple mux clock.

       Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/