On Tue, May 20, 2014 at 09:57:14AM -0700, Kevin Hilman wrote:

> For most devices, input clocks are modeled by the clock framework (or
> managed by the SoC's runtime PM core), and therefore, a pm_runtime_get()
> (or possibly an explict clk_enable()) is used to ensure the input clock
> is running.  In this external device example, it sounds to me like the
> sensor driver has no knowledge of its input clock so it has to rely on
> some other layer to resume things in the right order for correct
> functionality.

> Maybe I'm wrong here (likely, since I haven't looked at the code, and am
> admittedly very ignorant of the camera and display subsystems) but it
> sounds to me like what's missing is the sensor driver having knowledge
> of it's input clock and/or a way for it to request it's input clock to
> be enabled (e.g. clk_get/clk_enable.)

> Alternatively, what would proably be even better would be that the
> sensor driver has a reference to the actual device that provides its
> input clock (possibly via a DT phandle?) so that the sensor driver can
> simply do a pm_runtime_get() on the device providing the clock.

We have this problem on ASoC too and for DT converted devices we've been
doing exactly as you suggest and just teaching the device it has a clock
and letting it work out what to do with it.  Ideally we'd be able to
rely on having a clock API (better yet, the common clock API
implementation) and just put the entire clock tree in there.  It's not
been causing us any problems thus far but it's not that widely rolled
out yet either.