On 06/11/2009 10:35 AM, Hans Verkuil wrote:
Karicheri, Muralidharan a écrit :
We need
streaming capability in the driver. This is how our driver works
with mt9t031 sensor
raw-bus (10 bit)
vpfe-capture ----------------- mt9t031 driver
| |
V V
VPFE MT9T031
VPFE hardware has internal timing and DMA controller to
copy data frame by frame from the sensor output to SDRAM.
The PCLK form the sensor is used to generate the internal
timing.
So, what is missing in the driver apart from the ability to specify
a frame-rate?
[MK] Does the mt9t031 output one frame (snapshot) like in a camera or
can it output frame continuously along with PCLK, Hsync and Vsync
signals like in a video streaming device. VPFE capture can accept frames
continuously from the sensor synchronized to PCLK, HSYNC and VSYNC and
output frames to application using QBUF/DQBUF. In our implementation, we
have timing parameters for the sensor to do streaming at various
resolutions and fps. So application calls S_STD to set these timings. I
am not sure if this is an acceptable way of implementing it. Any
comments?
PCLK, HSYNC, VSYNC are generated by the CMOS sensor. I don't think you
can set the timings. Depending on sensor settings, pixel clock speed etc
.., the frame rate will vary.
You could perhaps play with the CMOS sensor registers so that when
settings a standard, the driver somehow set the various exposition
parameter and pll settings to get a specified framerate.
This will vary with each sensor and each platform (because of
pixelclock). More over, chances are that it will be conflicting with
other control.
For example if you set a fixed gain and autoexpo, some sensor will see
a drop in fps under low light conditions. I think this kind of
arbitration should be left to userspace.
Unless the sensor supports a specific standard, I don't think the driver
should try to make behind the scene modification to camera sensor
register in response to a S_STD ioctl.
The S_STD call is hopelessly inadequate to deal with these types of
devices. What is needed is a new call that allows you to set the exact
timings you want: frame width/height, back/front porch, h/vsync width,
pixelclock. It is my opinion that the use of S_STD should be limited to
standard definition type inputs, and not used for other devices like
sensors or HD video.
Proposals for such a new ioctl are welcome :-)
Hmm,
Why would we want the *application* to set things like this *at all* ?
with sensors hsync and vsync and other timing are something between
the bridge and the sensor, actaully in my experience the correct
hsync / vsync timings to program the sensor to are very much bridge
specific. So IMHO this should not be exposed to userspace at all.
All userspace should be able to control is the resolution and the
framerate. Although controlling the framerate in many cases also
means controlling the maximum exposure time. So in many cases
one cannot even control the framerate. (Asking for 30 fps in an
artificially illuminated room will get you a very dark, useless
picture, with most sensors). Yes this means that with cams with
use autoexposure (which is something which we really want where ever
possible), the framerate can and will change while streaming.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
