Hi Sylwester, On Tuesday 31 July 2012 15:28:52 Sylwester Nawrocki wrote: > On 07/31/2012 02:59 PM, Guennadi Liakhovetski wrote: > > On Tue, 31 Jul 2012, Sylwester Nawrocki wrote: > >> On 07/31/2012 02:26 PM, Guennadi Liakhovetski wrote: > >>>>>> But should we allow host probe() to succeed if the sensor isn't > >>>>>> present ? > >>>>> > >>>>> I think we should, yes. The host hardware is there and functional - > >>>>> whether or not all or some of the clients are failing. Theoretically > >>>>> clients can also be hot-plugged. Whether and how many video device > >>>>> nodes > >>>>> we create, that's a different question. > >>>> > >>>> I think I can agree with you on this (although I could change my mind > >>>> if this architecture turns out to result in unsolvable technical > >>>> issues). That will involve a lot of work though. > >>> > >>> There's however at least one more gotcha that occurs to me with this > >>> approach: if clients fail to probe, how do we find out about that and > >>> turn > >>> clocks back off? One improvement to turning clocks on immediately in > >> > >> Hmm, wouldn't it be the client that turns a clock on/off when needed ? > >> I'd like to preserve this functionality, so client drivers can have > >> full control on the power up/down sequences. While we are trying to > >> improve the current situation... > > > > Eventually, when the clock API is available - yes, the client would just > > call clk_enable() / clk_disable(). But for now isn't it host's job to do > > that? Or you want to add new API for that? > > Indeed, looking at existing drivers, the clocks' handling is now mostly > done in the host drivers. Only the omap3isp appears to do the right thing, > i.e. delegating control over the clock to client drivers, but it does it > with platform_data callbacks. > > We've already discussed adding a new API for that, > http://www.mail-archive.com/linux-media@xxxxxxxxxxxxxxx/msg35359.html > > However using common clock API and binding a clock to client device > (either DT based or not) sounds like a best approach to me. > > Waiting for the common clock API to be generally available maybe we > could add some clock ops at the v4l2_device ? Just a humble suggestion, > I'm not sure whether it is really good and needed or not. I'm fine with that (or something similar) as an interim solution. -- Regards, Laurent Pinchart -- 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
