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