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
On Tue, Jul 01, 2014 at 02:40:17PM -0700, Mike Turquette wrote:
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
On 13/06/14 22:53, Paul Walmsley wrote:
Whatever we do to the (common, not DSS-specific) clock code to fix this
issue, it has to make sense independently of your specific DSS needs.
I agree. I think the fix (v1) makes sense for all users of the pll.
Correct me if I'm wrong, but the current
On Wed, 4 Jun 2014, Tomi Valkeinen wrote:
On 03/06/14 22:35, Paul Walmsley wrote:
What's really needed is better control over rounding in the clock code.
Well, if you ask me, what's really needed _now_ is to fix the bug that
makes am3xxx (and am4xxx when it's merged) display not to
On 03/06/14 22:35, Paul Walmsley wrote:
What's really needed is better control over rounding in the clock code.
Well, if you ask me, what's really needed _now_ is to fix the bug that
makes am3xxx (and am4xxx when it's merged) display not to work. I don't
need a fix that solves all the clock
On Fri, 30 May 2014, Mike Turquette wrote:
Quoting Tomi Valkeinen (2014-05-15 05:25:37)
On 15/05/14 09:08, Mike Turquette wrote:
Quoting Tomi Valkeinen (2014-05-12 05:13:51)
On 12/05/14 15:02, Tero Kristo wrote:
On 05/08/2014 12:06 PM, Tomi Valkeinen wrote:
The current DPLL code
Quoting Tomi Valkeinen (2014-05-15 05:25:37)
On 15/05/14 09:08, Mike Turquette wrote:
Quoting Tomi Valkeinen (2014-05-12 05:13:51)
On 12/05/14 15:02, Tero Kristo wrote:
On 05/08/2014 12:06 PM, Tomi Valkeinen wrote:
The current DPLL code does not try to round the clock rate, and instead
Quoting Tomi Valkeinen (2014-05-12 05:13:51)
On 12/05/14 15:02, Tero Kristo wrote:
On 05/08/2014 12:06 PM, Tomi Valkeinen wrote:
The current DPLL code does not try to round the clock rate, and instead
returns an error if the requested clock rate cannot be produced exactly
by the DPLL.
On Thu, May 15, 2014 at 1:08 AM, Mike Turquette mturque...@linaro.org wrote:
Quoting Tomi Valkeinen (2014-05-12 05:13:51)
On 12/05/14 15:02, Tero Kristo wrote:
On 05/08/2014 12:06 PM, Tomi Valkeinen wrote:
The current DPLL code does not try to round the clock rate, and instead
returns an
On 15/05/14 09:08, Mike Turquette wrote:
Quoting Tomi Valkeinen (2014-05-12 05:13:51)
On 12/05/14 15:02, Tero Kristo wrote:
On 05/08/2014 12:06 PM, Tomi Valkeinen wrote:
The current DPLL code does not try to round the clock rate, and instead
returns an error if the requested clock rate cannot
On 05/08/2014 12:06 PM, Tomi Valkeinen wrote:
The current DPLL code does not try to round the clock rate, and instead
returns an error if the requested clock rate cannot be produced exactly
by the DPLL.
It could be argued that this is a bug, but as the current drivers may
depend on that
On 12/05/14 15:02, Tero Kristo wrote:
On 05/08/2014 12:06 PM, Tomi Valkeinen wrote:
The current DPLL code does not try to round the clock rate, and instead
returns an error if the requested clock rate cannot be produced exactly
by the DPLL.
It could be argued that this is a bug, but as the
The current DPLL code does not try to round the clock rate, and instead
returns an error if the requested clock rate cannot be produced exactly
by the DPLL.
It could be argued that this is a bug, but as the current drivers may
depend on that behavior, a new flag 'ti,round-rate' is added which
13 matches
Mail list logo
