[lkml]   [2013]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectCommon clock framework: mutex recursion when calling clk_prepare from prepare handler

I ran into a mutex recursion issue while trying to port the OMAP3 ISP driver
(drivers/media/platform/omap3isp) over to the common clock framework.

The OMAP3 ISP generates two programmable clocks named xclka and xclkb that are
routed out of the SoC. My goal is to expose them as common clock instances
through the common clock framework.

The xclk[ab] clocks are children of the cam_mclk clock. They are controlled
through ISP registers that sit in the cam_fclk clock domain. The cam_mclk and
cam_fclk clocks sit in separate power domains.

To program the xclk clocks I need to enable the cam_fclk clock. As xclk[ab]
are not descendants of the cam_fclk clock, this operation needs to be
performed manually. I thus call clk_prepare_enable on the cam_fclk clock in
the xclk[ab] prepare handler. This is where things break, as the common clock
framework takes the prepare_lock mutex in clk_prepare, which results in a
mutex recursion deadlock as the prepare_lock mutex isn't recursive.

What's the best way to solve this ? __clk_prepare (the unlocked version of
clk_prepare) isn't exported to drivers, and I'm not convinced it should be.
Turning prepare_lock into a recursive mutex might also work, but I'm not sure
what drawbacks this would have. Advices would be appreciated.


Laurent Pinchart

 \ /
  Last update: 2013-01-07 02:21    [W:0.016 / U:4.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site