Hi Kevin,
On Tue, 20 May 2008, Kevin Hilman wrote:
The locking in the get_rate() hook is unnecessary, and causes problems
when used with the -rt patch, since it may be called recursively.
Signed-off-by: Kevin Hilman [EMAIL PROTECTED]
Acked-by: Paul Walmsley [EMAIL PROTECTED]
BTW, looks
Paul Walmsley wrote:
Hi Kevin,
On Tue, 20 May 2008, Kevin Hilman wrote:
The locking in the get_rate() hook is unnecessary, and causes problems
when used with the -rt patch, since it may be called recursively.
Signed-off-by: Kevin Hilman [EMAIL PROTECTED]
Acked-by: Paul Walmsley
* Kevin Hilman [EMAIL PROTECTED] [080604 09:37]:
Paul Walmsley wrote:
Hi Kevin,
On Tue, 20 May 2008, Kevin Hilman wrote:
The locking in the get_rate() hook is unnecessary, and causes problems
when used with the -rt patch, since it may be called recursively.
Signed-off-by: Kevin
Tony Lindgren wrote:
* Kevin Hilman [EMAIL PROTECTED] [080604 09:37]:
Paul Walmsley wrote:
Hi Kevin,
On Tue, 20 May 2008, Kevin Hilman wrote:
The locking in the get_rate() hook is unnecessary, and causes problems
when used with the -rt patch, since it may be called recursively.
Hi,
On Wed, 2008-06-04 at 17:11 -0700, ext Kevin Hilman wrote:
The same can happen even with the locking. If someone asks for the
rate, and then another thread changes the rate right after, the thread
who asked for the rate has an out-of-date value.
I don't understand how this would
Hello,
On Thu, 5 Jun 2008, Igor Stoppa wrote:
- if a dvfs change is responsible of changing the rate supplied to a
driver which asked it with clk_get_rate(), the dvfs transition has no
reason to happen in case it would violate the constraints set by clock
users.
There aren't any such