Locking in the clk API
From: Saravana Kannan <hidden>
Date: 2011-01-22 02:56:53
On 01/21/2011 06:24 PM, Colin Cross wrote:
On Fri, Jan 21, 2011 at 5:53 PM, Saravana Kannan[off-list ref] wrote:quoted
On 01/21/2011 01:32 AM, Russell King - ARM Linux wrote:quoted
On Thu, Jan 20, 2011 at 08:12:45PM -0800, Saravana Kannan wrote:quoted
In my opinion, the only major reason for needing atomic clk APIs was due to device_ops->suspend being atomic. Since that's not the case anymore, I really don't see a justification for atomic clocks. Sure, I might have missed some exceptions, but in that case we should make the atomic APIs an exception (add clk_enable_atomic) and not the norm.The suspend method has never been atomic. It has always been able to sleep. You're mistaken.I distinctly remember trying to do sleeping stuff inside a .suspend function and have it complain that it's atomic. So, I think you might be mistaken. But I will have to back up my claims. Let me trying to find that info. In the end, one of us will learn something new -- which is good and all that matters.platform_driver->suspend and dev_pm_ops->suspend can sleep, but dev_pm_ops->suspend_noirq is called after irqs are disabled and can't sleep. Maybe that's what you were using?
The stuff I did was before suspend_noirq was added. Well, at least the struct that I was filling up had no suspend_noirq. -Saravana -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.