Albert, The version of the sensor driver in upstream kernel is using v4l2 sub device API and is different from the version used in MV Kernel.
JFYI.... Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: [email protected] ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Albert Burbea Sent: Friday, March 26, 2010 12:34 PM To: Raffaele Recalcati Cc: [email protected] Subject: Re: Seeking volunteers to porting video drivers to upstream on DMxxx devices Hi everybody just to add my cent... the mtpt9031 has a sort of frame rate control - because of its PLL. So, If you start using a certain clock, you can modify the PLL coefficients and get a variable pixel rate and variable frame rate, This may even be done on the fly, maybe a frame will get lost but no more harm than this. Also, it would be interesting (I guess) to use the VIDIOC_S_CROP, because this sensor (and many more) offer an ROI feature. Another issue I am thinking about: Is it possible to stack drivers in linux? And if so, at what performance price? I think the approach taken in MVISTA davinci_vpfe.c is interesting, (e.g. using a special callback to manage the raw data sensor) but it is VERY limiting. I think there should be a generic API for vpfe (at the end of the day, you want to set up ccdc and handle a queue of frames and not want to deal with every annoying detail of every sensor in the world) and a "registering" API that allows other drivers to be called back by the vpfe for every event in the driver (init, release, ioctl, new frame...). Probably those "minidrivers" should be able to allocate the frame memories (only the sensor knows its reolution !) and handle the sensor control (one sensor is I2C, the other is SPI, the other has an FPGA in the middle doing frame processing.. add at wish), leaving the vpfe (or IPIPE) driver alone. What do you think? Cheers! Albert 2010/3/26 Raffaele Recalcati <[email protected]<mailto:[email protected]>> I'm trying to use adv7180 and dm365. By now vpfe_poll start, but no video incoming. I have to investigate configuration of vpfe in respect of adv7180 video format. adv7180 sees the video (status 1 register 0x4f). I'll send more info in future. 2010/3/26 Jean-Philippe François <[email protected]<mailto:[email protected]>> Karicheri, Muralidharan a écrit : Jean-Philippe, 4) Develop and integrate mt9p031 sensor driver and integrate it with vpfe_capture. Regarding point 4, how is the cmos capture part supposed to work with the HD video standards ? Currently, to set the cmos capture resolution we have to : set a video HD standards. use TRY_FMT, S_FMT to set a windows that fits into the standard. Currently, the highest resolution avilables are in the V4L2_STD_1080* standard. mt9t* chips have resolution up to 2048x1536 2Mpixels sensor comes with resolution like 1600x1200 not to mention the mt9p031 sensor. What is the right way to handle this ? add a V4L2_STD_IMAGER_STD with a 4096x4096 or higher resolution ? I know this is an issue and was discussed in the v4l mailing list as part HD timing API RFC discussion. The conclusion then was to use S_FMT to set the frame size as done in mt9t031 driver. However currently mt9t031 doesn't allow setting frame rate. I think we need to discuss this in v4l list as part of this development activity. Another issue with the current implementation of mt9t031 is that how to make use of the Resizer at the VPFE to scale up or down the image output from the mt9t031. There is an effort to add device node to sub devices (Hans has indicated that to me last week). In that case, application may be able to use S_FMT at the sub device node and then call S_FMT at the video node (capture) and capture will be able to calculate proper scaling factor and apply the same at the Resizer. I suggest to discuss this as well in the v4l mailing list as part of this development activity. Another issue is how do we handle the i2c switch that is present in the sensor header? There are patches being reviewed in the i2c mailing list to handle these devices in the i2c driver. IMO, this piece is required as well. So do you want to work on this? I am sorry, I currently have no hardware with the corresponding cmos chips at my disposal. But we are in the process of designing a new hardware, and maybe one of this sensor will be used. -Murali 5) one shot mode Preview and Resize drivers on DM355/DM365 using memory to memory API (RFC recently submitted by Samsung) 6) vpfe capture enhancements using Previewer and Resizer in continuous mode. 7) vpif display enhancements for HD video. 8) Adding AEW/AF/Histogram support in vpfe capture driver. Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: [email protected]<mailto:[email protected]> _______________________________________________ Davinci-linux-open-source mailing list [email protected]<mailto:[email protected]> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source _______________________________________________ Davinci-linux-open-source mailing list [email protected]<mailto:[email protected]> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- www.opensurf.it<http://www.opensurf.it/> _______________________________________________ Davinci-linux-open-source mailing list [email protected]<mailto:[email protected]> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- Albert Burbea Harishonim 8 Ramat Gan 52502, Israel Tel/Fax + 972-3-7526016 Mobile: +972-52-3541842
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
