On Tue, 31 Jul 2012, Sylwester Nawrocki wrote:

On 07/31/2012 02:26 PM, Guennadi Liakhovetski wrote:

quoted

quoted

quoted

quoted

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

quoted

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/