Vaibhav, A minor correction.... Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-karicheri2@xxxxxx >-----Original Message----- >From: linux-media-owner@xxxxxxxxxxxxxxx [mailto:linux-media- >owner@xxxxxxxxxxxxxxx] On Behalf Of Hiremath, Vaibhav >Sent: Monday, August 31, 2009 2:26 PM >To: linux-media@xxxxxxxxxxxxxxx >Subject: Behavior of ENUM_STD/G_STD ioctl > >Hi, > >I am working on OMAP3517 which has CCDC module which is almost similar to >Davinci (DM6446). I have ported davinci capture driver (Submitted by >Murali) to OMAP3517, and I am almost done with it, except some hardware >related issues (which requires some follow-ups with HW team). > >During this I came across one observation, in vpfe_camera.c file which is should be read as vpfe_capture.c >bridge driver assumes the default standard without looking/referring to >underneath sub-device (It choose index 0 in the v4l2_std array maintained >by bridge driver). If I understand correctly as per V4L2 Spec, the driver >does not need to implement enum_std/g_std callback functions, since V4L2 >layer handles this and returns these fields respectively. > >Now the question I have here is, how enum_std/g_std, to be more specific >tvnorm/current_norm should be handled by driver? > >1) During probe (or open) bridge driver should get the current standard >which is being active from the underneath sub-device and update the fields >tvnorm/current_norm accordingly. After that whenever application call >enum_std/g_std the V4L2 layer can handle it and for s_std anyway bridge >driver passing it to sub device. > >2) Application must call s_std and that's where all the path will get >synchronized (what sub-device has with what V4L2 layer has against bridge >driver) > >I believe driver should follow option 1, especially in our case (TVP5146 >video decoder) where it has a capability to lock the signal and return the >status of detected standard. > >Can anybody conform how this should be handled? > >Thanks, >Vaibhav >-- >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 -- 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
