Messages in this thread | | | Date | Tue, 01 Feb 2011 12:21:45 -0800 | From | Saravana Kannan <> | Subject | Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare |
| |
On 02/01/2011 11:56 AM, Russell King - ARM Linux wrote: > On Tue, Feb 01, 2011 at 08:32:01PM +0100, Uwe Kleine-König wrote: >> On Tue, Feb 01, 2011 at 05:06:37PM +0000, Russell King - ARM Linux wrote: >>> So? You're not _supposed_ to call it from any atomic context ever. >> >> My motivation for a more complicated clk_prepare was to make clk_prepare >> atomic when that's possible (i.e. when the clk is already prepared) and >> call it before the enable callback in clk_enable. Then everything >> behaves nicely even if clk_enable is called from atomic context provided >> that the clock was prepared before (or doesn't need to). > > You really don't get the point of clk_prepare() do you. I'm not > going to bother trying to educate you anymore. > > Hopefully someone with more patience can give you the necessary > teaching to make you understand.
Uwe,
If the driver is calling clk_prepare() right next to clk_enable() knowing it's been already prepared and will hence be "atomic" (this is actually not true), then by your description, it's pointless to call clk_prepare().
If you want the driver to call clk_prepare() in atomic context because it will be atomic in most cases -- well, that's wrong. It's either atomic or is NOT atomic. There is no in between. If a call is NOT atomic, it can't be called in atomic context. Long story short, if you expect clk_prepare() to be atomic under any circumstance, it beats the point of introducing clk_prepare().
Hope I helped.
-Saravana
-- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |