Re: [PATCH 05/14] media: add a V4L2 OF parser

[Sylwester Nawrocki <sylvester.nawrocki@gmail.com>]

On 10/10/2012 10:32 PM, Guennadi Liakhovetski wrote:
>>> We might actually not need that, it might be easier to handle the circular
>>> dependency problem from the other end. We could add a way (ioctl, sysfs, ...)
>>> to force a V4L2 bridge driver to release its subdevs. Once done, the subdev
>>> driver could be unloaded and/or the subdev device unregistered, which would
>>> release the resources used by the subdev, such as clocks. The bridge driver
>>> could then be unregistered.
>>
>> That sounds like an option. Perhaps it could be done by v4l2-core, e.g. a sysfs
>> entry could be registered for a media or video device if driver requests it.
>> I'm not sure if we should allow subdevs in "released" state, perhaps it's better
>> to just unregister subdevs entirely right away ?
> 
> What speaks against holding a clock reference only during streaming, or at
> least between open and close? Wouldn't that solve the problem naturally?
> Yes, after giving up your reference to a clock at close() and re-acquiring
> it at open() you will have to make sure the frequency hasn't change, resp.
> adjust it, but I don't see it as a huge problem, I don't think many users
> on embedded systems will compete for your camera master clock. And if they
> do, you have a different problem, IMHO;-)

I agree, normally nobody should touch these clocks except the subdev (or as of 
now the host) drivers. It depends on a sensor, video encoder, etc. how much it 
tolerates switching the clock on/off. I suppose it's best to acquire/release it
in .s_power callback, since only then the proper voltage supply, GPIO, clock 
enable/disable sequences could be ensured. I know those things are currently 
mostly ignored, but some sensors might be picky WRT their initialization/shutdown
sequences and it would be good to ensure these sequences are fully controllable 
by the sensor driver itsels, where the host's architecture allows that.

To summarize, I can't see how holding a clock only when a device is active
could cause any problems, in case of camera sensors. I'm not sure about other
devices, like e.g. tuners.

--

Regards,
Sylwester