Hello, 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. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
