[PATCH 1/3] clk: ti: add 'ti,round-rate' flag

[mturquette@linaro.org (Mike Turquette)]

Quoting Paul Walmsley (2014-06-13 12:53:06)
> Furthermore, as a general interface principle, allowing clk_set_rate() to 
> silently round rates could lead to unexpected behavior, since the set of 
> rates that clk_set_rate() can round to may change between the call to 
> clk_round_rate() and the call to clk_set_rate().

Rounding the rate will always happen in a call to clk_set_rate. We need
to know what rate that clock node can actually support. The real
question is what do we do with that rounded rate. There are two options:

1) abort and return an error code if the rounded rate does not exactly
match the requested rate

2) use the rounded rate even if it does not match the requested rate

#2 has some variations worth considering:

a) allow a rounded rate within a specified tolerance (e.g. 10% of the
requested rate)
b) allow a rounded rate so long as it is rounded down from the requested
rate
c) same as #b, but rounded up, etc.

> 
> So again I think that the right way to deal with this is to:
> 
> 1. avoid silently rounding rates in clk_set_rate() and to return an error 
> if calling clk_set_rate() would result in a rate other than the one 
> desired; and to

Let's get consensus on my above question before we solidify the API.
It's worth noting that the current behavior of rounding the rate within
clk_set_rate is actually what Russell had in mind back in 2010. See this
thread[1] for details.

Also note that this opens up a can of worms regarding *intended rates*.
For example, if you always abort clk_set_rate if the rounded rate does
not match the requested rate, then what does that mean for a child clock
that will be changed by some parent clock higher up the tree? If that
child gets put to a rate that would never be returned by clk_round_rate
then is the framework responsible for walking down the tree, checking
every child and aborting when the first one is off by a few hertz?
That's going to be messy.

> 
> 2. modify clk_round_rate() such that it returns the closest 
> lowest-or-equal rate match to the target rate requested.

I agree that the behavior of clk_round_rate needs to be defined once and
for all. I also think that clk_round_ceil, clk_round_floor and
clk_round_exact aren't terrible ideas either.

I'll kick off a thread on this topic shortly, and we can hopefully gain
some consensus.

Regards,
Mike

[1] https://lkml.org/lkml/2010/7/14/330

> 
> 
> - Paul