Re: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation

[Sylwester Nawrocki <s.nawrocki@samsung.com>]

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@vger.kernel.org/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.

--

Thanks,
Sylwester