Web lists-archives.org

Re: [PATCH 2/6] V4L2 soc_camera driver for PXA27x processors

On Thu, 14 Feb 2008, eric miao wrote:

> readability, compare:
> 
>     DRCMR68 = dma_chan_y | DRCMR_MAPVLD;
> 
> and
> 
>     DRCMR(drcmr_y) = dma_chan_y | DRCMR_MAPVLD;
> 
> And another thing if you take a look into pxa-regs.h about those DRCMRx
> register definitions, it's currently a mess. People uses different ways to
> reference DRCMR
> 
> 1. DRCMRxx directly, like in your driver
> 2. DRCMRRXSSDR - named DRCMR register
> 3. DRCMR(xx)
> 
> among these three, I like DRCMR(x) best for the reason I have stated
> above. Now most drivers are moving toward that way, once we get
> all those reference to DRCMR fixed, we will only define one macro
> 
> DRCMR(xx) and remove all DRCMRxx and DRCMRXXXXX

Ah, sure, sorry, misunderstood you the first time. Will replace.

> > > 3. by using only Y dma channel, the driver is dropping the capability
> > > of the hardware to convert interleaved YCbCr data to planar format,
> > > what is your plan for that capability?
> >
> > This driver so far presents what I had to implement and what I could test.
> > I didn't have any YCbCr cameras, so, as long as someone gets a task of
> > supporting them and the necessary hardware, it'll have to be implemented
> > too. I guess, what I could do now at most, is look in the datasheet and
> > see if I can prepare the driver to facilitate those future extensions.
> >
> 
> I have boards with YCbCr sensors here, yet I don't know if I will have
> time to test this :-(. So yes, you may prepare for that, and let's see
> if we can extend that.

Well, as I do not have access to any of this hardware, I would prefer to 
first commit the driver without any support for these, and then review 
patches for them separately. How does this sound?

> > example in my case, the platform supported 8 and 10 bit modes, and a
> > method to dynamically switch between those. So, my .flags look like
> >
> > +       .flags  = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 | PXA_CAMERA_DATAWIDTH_10 |
> > +               PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
> >
> > (see the [PATCH 6/6]). And the switching is transparent - it is activated
> > upon setting of an 8- or 16-bit pixel format.
> >
> 
> Mmm... this is really cool. I didn't know any sensor that needs width
> change at run-time. Usually, it's fixed. Two common types of sensors:
> 
> 1. YCbCr sensors - usually comes with 8-bit interleaved pixel format
> and
> 2. raw sensors - usually comes with 10-bit RGGB output
> 
> There are some smart sensors with different output protocol, but
> most of them I know mimics the YCbCr output, except for JPEG,
> which is usually specially handled.
> 
> So I'm really curious what exact sensor you are using?

Ok, I'm not going to disclose any secrets, if I just point you to the 
patch-series:-) If you looked at it, you would see, that both cameras I 
submitted with it are normal raw 10-bit cameras. And they just use an 
external I2C GPIO extender to switch to 8 bits. And the discovery is again 
performed based upon the platform data.

> One sensor at any given time, Yes. The QCI can handle only _one_
> sensor, the others are just put to idle and disconnected. Usually, the
> switching is controlled by external analog switch, for example. And
> this is common requirement, say when one needs one sensor for
> high resolution and another one for low resolution, as commonly
> seen on high-end mobile devices.
> 
> The connections might or might not be same. So it would be nice
> if the sensor can provide output format information to the camera driver.
> 
> Switching of sensors is board specific, so the platform data should
> really provide some kind of switching callback functions if possible.

Yeah, this is going to be a mess... Currently to set a specific video 
format an ioctl is passed from the v4l2 layer to the video driver, which 
is in this case the soc_camera.c. This then calls back into the camera 
driver and into the interface driver (pxa_camera.c). Now we'll have to 
also call back into the platform code... Wow.

But, I think, we'll have to do it differently. The two cameras you mention 
are two separate video-devices with my framework. So, the application will 
have to go to /dev/video1 from /dev/video0. And, perhaps, the camera 
driver (not the interface driver, like pxa-camera) will have to call back 
into the platform layer to activate the respective controller. How does 
this sound?

Thanks
Guennadi
---
Guennadi Liakhovetski

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