Locking in the clk API
From: Grant Likely <hidden>
Date: 2011-01-16 07:00:14
Also in:
linux-sh, lkml
2011/1/15 Russell King - ARM Linux [off-list ref]:
On Sat, Jan 15, 2011 at 04:03:31PM +0100, Uwe Kleine-K?nig wrote:quoted
Hi Russell, On Sat, Jan 15, 2011 at 02:53:58PM +0000, Russell King - ARM Linux wrote:quoted
We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable() vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc. There's been a lot of talk on this issue for ages with no real progress that I'm just going to repeat: let's unify those implementations which use a spinlock for their clks into one consolidated solution, and a separate consolidated solution for those which use a mutex. This will at least allow us to have _some_ consolidation of the existing implementations - and it doesn't add anything to the problem at hand. It might actually help identify what can be done at code level to resolve this issue.Great, so how should we do it? ?Take Jeremy's patch and make the differenciation between sleeping and atomic implementation a Kconfig variable?No - I've been suggesting for about a week now about doing two entirely separate consolidations. I think it would be insane to do the consolidation of the two different implementations in one patch or even one patch set. ?There needs to be a consolidation of spinlock-based clks as one patch set, which is entirely separate and independent from the consolidation of mutex-based clks.
+1
What if one of the consolidations turns out to be a problem? ?Do we want to throw both out, or do we want to keep as much as we possibly can? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo at vger.kernel.org More majordomo info at ?http://vger.kernel.org/majordomo-info.html Please read the FAQ at ?http://www.tux.org/lkml/
-- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.