Re: OmniVision OV9655 camera chip via soc-camera interface

[Stefan Herbrechtsmeier <hbmeier@xxxxxxxxxxxxxxxxxxxx>]

Sorry for the late answers, but first I want to get my ov9655 driver 
work prober.

Guennadi Liakhovetski schrieb:
> 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.
>   
This means moving the init() and reset() functions into the 
soc_camera_link. Is this right?
> 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.
>   
Not at the moment.

I have some addition suggestion for the soc_camera interface:

1. Renaming SOCAM_HSYNC_* to SOCAM_HREF_*
I think the current used Signal is HREF and not HSYNC.
- HREF is active during valid pixels
- HSYNC is a impulse at the start of each line before valid pixels and 
need some pixel skipping.

2. Add a new SOCAM_HSYNC_* to the soc_camera interface

3. Add x_skip_left to soc_camera_device
The pxa_camera has to skip some pixel at the begin of each line if a 
HSYNC signal is used.
(y_skip_top and x_skip_left can change with each format adjustment!)

4. Remove camera_init() call before camera_probe()
I think the driver should first detect the hardware before it do 
something with it.
The first hardware initialization should be done in the probe function.

Regards,
  Stefan

--
Dipl.-Ing. Stefan Herbrechtsmeier

Heinz Nixdorf Institute
University of Paderborn 
System and Circuit Technology 
Fürstenallee 11
D-33102 Paderborn (Germany)

office : F0.415
phone  : + 49 5251 - 60 6342
fax    : + 49 5251 - 60 6351

mailto : hbmeier@xxxxxxxxxx

www    : http://wwwhni.upb.de/sct/mitarbeiter/hbmeier


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