From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from smtp5-g21.free.fr ([212.27.42.5]:54864 "EHLO smtp5-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751918AbZFKIBY (ORCPT ); Thu, 11 Jun 2009 04:01:24 -0400 Message-ID: <4A30B9CB.8030902@cynove.com> Date: Thu, 11 Jun 2009 10:01:15 +0200 From: =?ISO-8859-1?Q?Jean-Philippe_Fran=E7ois?= MIME-Version: 1.0 To: "Karicheri, Muralidharan" CC: Guennadi Liakhovetski , "davinci-linux-open-source@linux.davincidsp.com" , Muralidharan Karicheri , "linux-media@vger.kernel.org" Subject: Re: mt9t031 (was RE: [PATCH] adding support for setting bus parameters in sub device) References: <1244580891-24153-1-git-send-email-m-karicheri2@ti.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-media-owner@vger.kernel.org List-ID: 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. 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@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source >