Re: OmniVision OV9655 camera chip via soc-camera interface

[Guennadi Liakhovetski <g.liakhovetski@xxxxxx>]

On Tue, 15 Apr 2008, Stefan Herbrechtsmeier wrote:

> Guennadi Liakhovetski schrieb:
> > 
> > Look in pxa_camera.c, e.g., in pxa_camera_activate. There are function calls
> > like
> > 
> > pxa_camera_activate(struct pxa_camera_dev *pcdev)
> > {
> > 	struct pxacamera_platform_data *pdata = pcdev->pdata;
> > 
> > ...
> > 
> > 	pdata->power(pcdev->dev, 1);
> > 
> > ...
> > 
> > 	pdata->reset(pcdev->dev, 1);
> > 
> > in it, which should do exactly what you need. And they are supposed to be
> > implemented in the platform, so, you have all the required GPIO information
> > you need there. That is exactly the reason they are defined that way -
> > because they were thought to be platform-dependent. Let me know if there's
> > still anything missing. It is still a work in progress, so, we are flexible
> > and can add any (reasonable) APIs we find useful.
> >   
> Thanks, that exact what I search, but maybe this functions should be in the
> soc_camera_link. I think this functions belong to the camera chip and not to
> the capture interface. This allows more than one camera chip on one capture
> interface with separate enable and reset.

Well, in principle, yes, I think this is a good idea. But:

1. ATM these functions are called from the camera-host (pxa-camera) 
driver. And until now it knew nothing about soc_camera_link. Which is also 
good.

   a) If we want to keep calls to these functions in the camera-host 
driver, we'll either have to let it also handle soc_camera_link, or 
introduce some parameter to these functions to tell the platform which 
camera shall be resetted / powered on or off.

   b) Alternatively, we could call these functions from soc_camera_ops 
init() and release() methods. Actually, I think, this would be the best 
option.

2. Do you have a real-life example with several cameras on one interface? 
ATM pxa_camera is explicitely limited to handle only one camera on its 
quick capture interface. You would have to lift that restriction too.

So, I think, a patch implementing 1.b could be considered.

Thanks
Guennadi
---
Guennadi Liakhovetski

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list