Hi Guennadi,

On Mon, Oct 08, 2012 at 02:23:25PM +0200, Guennadi Liakhovetski wrote:
...
> If we do it from the bridge driver, we could install an I2C bus-notifier, 
> _before_ the subdevice driver is probed, i.e. upon the 
> BUS_NOTIFY_BIND_DRIVER event we could turn on the clock. If subdevice 
> probing was successful, we can then wait for the BUS_NOTIFY_BOUND_DRIVER 
> event to switch the clock back off. BUT - if the subdevice fails probing? 
> How do we find out about that and turn the clock back off? There is no 
> notification event for that... Possible solutions:
> 
> 1. timer - ugly and unreliable.
> 2. add a "probing failed" notifier event to the device core - would this 
>    be accepted?
> 3. let the subdevice turn the master clock on and off for the duration of 
>    probing.
> 
> My vote goes for (3). Ideally this should be done using the generic clock 
> framework. But can we really expect all drivers and platforms to switch to 
> it quickly enough? If not, we need a V4L2-specific callback from subdevice 
> drivers to bridge drivers to turn the clock on and off. That's what I've 
> done "temporarily" in this patch series for soc-camera.

I'd say the clock has to be controlled by the sub-device driver. Sensors
also have a power-up (and power-down) sequences that should be followed.
Usually they also involve switching the external clock on (and off) at a
given point of time.

Also the OMAP 3 provides that clock through ISP so it, too, requires the
generic clock framework to function with DT.

> Suppose we decide to do the same for V4L2 centrally - add call-backs. Then 

I'd prefer to use the generic clock framework, albeit I admit it may take
some time till all the relevant platforms support it. Nevertheless, if
there's going to be a temporary solution it should be removed once the
clock framework support is there.

Kind regards,

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi     XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to