Hi Vaibhav, On Wednesday 06 October 2010 11:19:25 Hiremath, Vaibhav wrote: > On Tuesday, October 05, 2010 7:55 PM Laurent Pinchart wrote: > > > > Add the following media bus format code definitions: > > > > - V4L2_MBUS_FMT_SGRBG10_1X10 for 10-bit GRBG Bayer > > - V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 for 10-bit DPCM compressed GRBG Bayer > > - V4L2_MBUS_FMT_YUYV16_1X16 for 8-bit YUYV on 16-bit bus > > - V4L2_MBUS_FMT_UYVY16_1X16 for 8-bit UYVY on 16-bit bus > > - V4L2_MBUS_FMT_YVYU16_1X16 for 8-bit YVYU on 16-bit bus > > - V4L2_MBUS_FMT_VYUY16_1X16 for 8-bit VYUY on 16-bit bus
The commit message should list V4L2_MBUS_FMT_*8_1X16 instead of V4L2_MBUS_FMT_*16_1X16, my bad. > > Laurent I may be wrong here, but I think above definition is confusing - > > For me the above definition actually means, 16bits are coming on the bus > for every cycle. That's correct. > If you are referring to OMAP3 interface here then 8->16 bit conversion > happens inside ISP-bridge, the interface from sensor-to-CCDC is still 8 > bit (Technically it is 10, but we are using lane shifter to get 8 bits) > and I believe sensor is also sending one component for every cycle (either > UYVY or YUYV). That's correct as well. > And I believe the bridge driver is not exported to user application so we > should be using MBUS_FMT_UYVY8_2x8 and family. The V4L2_MBUS_FMT_*8_1X16 formats are used for the preview -> resizer link, not the sensor -> CCDC link. For the later the V4L2_MBUS_FMT_*8_2X8 are used instead. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
