status request of et8k8, ad5820 and their corresponding rx51 board code

status request of et8k8, ad5820 and their corresponding rx51 board code

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 239 bytes --]

Hi,

What's the plan for the rx51 camera drivers from [0]? Is there a
chance, that they get included in the mainline 3.2 or 3.3 kernel?

[0] http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-2.6.37-rx51

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: status request of et8k8, ad5820 and their corresponding rx51 board code

[Laurent Pinchart]

Hi Sebastian,

(CC'ing Sakari Ailus)

On Wednesday 31 August 2011 17:15:24 Sebastian Reichel wrote:
> Hi,
> 
> What's the plan for the rx51 camera drivers from [0]? Is there a
> chance, that they get included in the mainline 3.2 or 3.3 kernel?

The ad5820 driver will probably be the simplest one to upstream. It should be 
possible to push it to v3.3. Someone needs to look at the lens-related 
controls and how they can be standardized (if at all).

The et8ek8 driver is a different story. I don't think it should get mainlined 
in its current state. We need to get rid of the "camera firmware" support from 
the driver first, and if possible implement the V4L2 API correctly without 
relying on register lists.

-- 
Regards,

Laurent Pinchart

Re: status request of et8k8, ad5820 and their corresponding rx51 board code

[Sakari Ailus]

On Wed, Aug 31, 2011 at 05:33:16PM +0200, Laurent Pinchart wrote:
> Hi Sebastian,

Hi,

> (CC'ing Sakari Ailus)
> 
> On Wednesday 31 August 2011 17:15:24 Sebastian Reichel wrote:
> > Hi,
> > 
> > What's the plan for the rx51 camera drivers from [0]? Is there a
> > chance, that they get included in the mainline 3.2 or 3.3 kernel?
> 
> The ad5820 driver will probably be the simplest one to upstream. It should be 
> possible to push it to v3.3. Someone needs to look at the lens-related 
> controls and how they can be standardized (if at all).

I don't know enough of different lenses to give a definitive answer but so
far what I have seen is that the way to drive a lens varies wildly from chip
to another. It might not be possible to standarside them.

I agree the ad5820 would be relatively easy to upstream.

> The et8ek8 driver is a different story. I don't think it should get mainlined 
> in its current state. We need to get rid of the "camera firmware" support from 
> the driver first, and if possible implement the V4L2 API correctly without 
> relying on register lists.

I fully agree with this. One problem is that the documentation for this
sensor is poor and not many of its registers are known. It's possible to use
it with the existing register list (which should be part of the driver
itself).

-- 
Sakari Ailus
sakari.ailus@iki.fi