> 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 :-)
Regards,
Hans
>
> JP François
>
>
>> Thanks
>>
>> Murali
>>
>>> Thanks
>>> Guennadi
>>> ---
>>> Guennadi Liakhovetski, Ph.D.
>>> Freelance Open-Source Software Developer
>>> http://www.open-technology.de/
>>
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source@xxxxxxxxxxxxxxxxxxxx
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>>
>
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@xxxxxxxxxxxxxxxxxxxx
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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
