[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On 05/23/2012 02:16 AM, Peter De Schrijver wrote:
On Tue, May 22, 2012 at 08:06:45PM +0200, Turquette, Mike wrote:On Tue, May 22, 2012 at 6:58 AM, Peter De Schrijver <pdeschrijver@xxxxxxxxxx> wrote:On Tue, May 15, 2012 at 08:20:44PM +0200, Saravana Kannan wrote:On 05/11/2012 09:59 PM, Saravana Kannan wrote:Without this patch, the following race conditions are possible. Race condition 1: * clk-A has two parents - clk-X and clk-Y. * All three are disabled and clk-X is current parent. * Thread A: clk_set_parent(clk-A, clk-Y). * Thread A:<snip execution flow> * Thread A: Grabs enable lock. * Thread A: Sees enable count of clk-A is 0, so doesn't enable clk-Y. * Thread A: Releases enable lock. * Thread B: Calls clk_enable(clk-A), which in turn enables clk-X. * Thread A: Switches clk-A's parent to clk-Y in hardware. clk-A is now enabled in software, but not clocking in hardware. Race condition 2: * clk-A has two parents - clk-X and clk-Y. * All three are disabled and clk-X is current parent. * Thread A: clk_set_parent(clk-A, clk-Y). * Thread A:<snip execution flow> * Thread A: Switches parent in hardware to clk-Y. * Thread A: Grabs enable lock. * Thread A: Sees enable count of clk-A is 0, so doesn't disable clk-X. * Thread A: Releases enable lock. * Thread B: Calls clk_enable(clk-A) * Thread B: Software state still says parent is clk-X. * Thread B: So, enables clk-X and then itself. * Thread A: Updates parent in software state to clk-Y.This looks correct to me. Is there any usecase where enabling/disabling a clock would require sleeping but changing the parent would not?clk_enable& clk_disable must never sleep. clk_prepare and clk_unprepare may sleep.In that case the clock is actually enabled in clk_prepare and disabled in clk_unprepare I guess (and clk_enable/clk_disable are dummy functions)? What I'm trying to say is that I don't think there are clocks which can be enabled/disabled using non blocking operations, but where a parent change would require a blocking operation. Cheers, Peter.
Mark, Shawn, Russell,Can you guys please respond? I'm surprised that no one seem to care about fixing race conditions between clk_set_parent/clk_set_rate() and clk_enable() that will result in incorrect enable count propagation and have the SW get out of sync with HW.
If we absolutely need to support clocks that where the ops->set_parent() is not atomic and can't go with the CLK_SET_PARENT_GATE option, then maybe we can add a "I promise the consumers of this clock won't call clk_set_parent() and clk_enable() in a racy way" clock flag (CLK_IGNORE_PARENT_ENABLE_RACE). Yes, it would be a hack for such clocks, but that's still better than leaving a gaping hole for all the clocks.
-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-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html