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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
