Thread (22 messages) 22 messages, 8 authors, 2013-06-13

[PATCH v4 5/5] clk: clk-mux: implement remuxing on set_rate

From: dianders@chromium.org (Doug Anderson)
Date: 2013-06-12 17:55:39
Also in: lkml

Mike,

On Wed, Jun 12, 2013 at 10:45 AM, Mike Turquette [off-list ref] wrote:
quoted
* It seems like we can't make muxing decisions on the SoC level.
* Your automatic muxing patches don't hurt me and could be useful for
_some_ of the muxing options, just not the top PLL ones.
For the time being you won't be affected by this until you start using
.determine_rate.  Even then we have the flag which disables this
behavior.
Yup, exactly!  :)  So I have no objections to the auto remuxing, it
just doesn't solve all of my problems.

quoted
...but the only place that leaves me for my muxing needs is the device
tree.  ...and as Mike pointed out on IRC the device tree should
describe hardware, not policy.  Ick.
This sounds like another vote for configtree ;-)
Yes.  It sounds like for now we're just going to carry some patches to
setup our clocks, but a configtree seems like it would solve this type
of problem.

One question to raise: if we're going to need to come up with a
solution for defining parents for things like PLLs, does it decrease
the need for the auto-remuxing patches?  AKA: if we use some type of
mechanism like configtree to specify muxing, would that be enough?  I
don't know the answer, but just thought I'd raise the question...

-Doug
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help