From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sylwester Nawrocki Subject: Re: [PATCH 05/14] media: add a V4L2 OF parser Date: Wed, 10 Oct 2012 23:12:55 +0200 Message-ID: <5075E4D7.4010706@gmail.com> References: <1348754853-28619-1-git-send-email-g.liakhovetski@gmx.de> <5073FDC8.8090909@samsung.com> <201210091300.24124.hverkuil@xs4all.nl> <1398413.j3yGqyN4Du@avalon> <5075D947.3080903@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-sh-owner@vger.kernel.org To: Guennadi Liakhovetski Cc: Laurent Pinchart , Hans Verkuil , Sylwester Nawrocki , linux-media@vger.kernel.org, devicetree-discuss@lists.ozlabs.org, Magnus Damm , linux-sh@vger.kernel.org, Mark Brown , Stephen Warren , Arnd Bergmann , Grant Likely , Thomas Abraham , Tomasz Figa List-Id: devicetree@vger.kernel.org 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