[PATCH v4 2/5] media: ov2640: add async probe function

[g.liakhovetski@gmx.de (Guennadi Liakhovetski)]

On Tue, 30 Dec 2014, Josh Wu wrote:

[snip]

> > And until omap1 is in the mainline we cannot drop v4l2_clk.

s/until/as lonh as/

> So I think the better way right now for ov2640 driver is still request both
> the v4l2_clock: mclk, and the clock: xvclk in probe().
> In that way,  we can take our time to introduce other patches to merged these
> two clocks.
> Does it make sense?

How about this sequence, that we cat still try to get in on time for the 
next merge window:

1. stop using the clock name in v4l2_clk
2. add support for CCF to v4l2_clk, falling back to current behaviour if 
no clock is found
3. switch ov2640 to using "xvclk"

Otherwise I would propose to add asynchronous probing support to ov2640 
_without_ changing the clock name. Whether or not we changee clock's name 
isn't related directly to async support, since the driver already is using 
v4l2_clk with the standarf "wrong" name. So, I would consider these two 
changes separately - one is a new feature, another is a fix. The only 
question is in which order to apply them. In general fix-first is 
preferred, but since in this case the fix requires framework changes, we 
could go with feature-first. This also makes sense since features need to 
catch a merge window, whereas a fix can go in later too. So, if we don't 
manage the above 3-step plan, I would priposw the most primitive patch ro 
ov2640 just adding async support in line wuth other drivers and without 
changing the clock name at first.

Thanks
Guennadi