Thread (53 messages) 53 messages, 5 authors, 2012-08-19

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

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2012-07-31 21:46:46
Also in: linux-media, linux-samsung-soc

Hi Sylwester,

On Tuesday 31 July 2012 15:28:52 Sylwester Nawrocki wrote:
On 07/31/2012 02:59 PM, Guennadi Liakhovetski wrote:
quoted
On Tue, 31 Jul 2012, Sylwester Nawrocki wrote:
quoted
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?
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.
I'm fine with that (or something similar) as an interim solution.

-- 
Regards,

Laurent Pinchart
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help