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? Thanks Guennadi > > host's probe() is to only do it in a BUS_NOTIFY_BIND_DRIVER notifier. But > > how do we find out, that probing failed? No notifier is called in this > > case. We could use a time-out, but that's ugly. I think, we could ever > > request a new notifier for this case. We could also require client drivers > > to call a V4L2 function in this case, but that's not very pretty either. --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
