Hi Michael, On Thursday 26 July 2012 13:59:54 Michael Jones wrote: > Hello, > > I would like to (re)submit a couple of patches to support V4L2 behavior at > the V4L2 device nodes of the omap3-isp driver, but I'm guessing they require > some discussion first. Indeed. The main reason why the OMAP3 ISP driver implements G_FMT/S_FMT as it does today is to hack around a restriction in the V4L2 API. We needed a way to preallocate and possibly prequeue buffers for snapshot, which wasn't possible in a standard-compliant way back then. The situation has since changed, and we now have the VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF ioctls. My plan is to - port the OMAP3 ISP driver to videobuf2 - implement support for CREATE_BUFS and PREPARE_BUF - fix the G_FMT/S_FMT/ENUM_FMT behaviour The real problem will be to find time to implement this. > I've previously submitted one of them here [1] to support ENUM_FMT for the > omap3-isp. This sparked some discussion, the result of which was that my > patch probably made sense. Later [2], Laurent mentioned that there was some > discussion/decision about adding "profiles" to the V4L2 specification, and > the OMAP3 ISP would probably implement the "streaming" profile. That was 7 > months ago and I haven't seen any discussion of such profiles. Can somebody > bring me up to speed on this? > > The purpose of these two patches is for the V4L2 device nodes to support > mandatory V4L2 ioctls G_FMT and ENUM_FMT, such that a pure V4L2 application, > ignorant of the media controller, can still stream the images from the video > nodes. This presumes that the media controller would have been > pre-configured. This approach is often seen on the mailing list using > 'media-ctl' to configure the ISP, then 'yavta' to retrieve images. Currently > this works because yavta doesn't require ENUM_FMT (unlike Gstreamer), and > only as long as one sets the same format with yavta as had already been set > with media-ctl. I think yavta should be able to just do G_FMT to see what is > configured. > > To be clear (as discussed in [1]), ENUM_FMT does not behave according to its > original intent, because it cannot enumerate possible formats the ISP can > deliver. It will enumerate only one format: the one configured with the > media controller. In a sense this complies with the specification, because > S_FMT wouldn't be able to change the format to anything else. > > I have tested these patches on v3.4, but I have rebased them to v3.5 here. > I would remove the pr_debug() calls before submitting upstream, but they're > useful for testing. > > [1] http://www.mail-archive.com/linux-media@xxxxxxxxxxxxxxx/msg29640.html > [2] http://www.mail-archive.com/linux-media@xxxxxxxxxxxxxxx/msg40618.html > > Michael Jones (2): > [media] omap3isp: implement ENUM_FMT > [media] omap3isp: support G_FMT > > drivers/media/video/omap3isp/ispvideo.c | 50 ++++++++++++++++++++++++++++ > 1 files changed, 50 insertions(+), 0 deletions(-) -- Regards, Laurent Pinchart -- 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
