> -----Original Message----- > From: Mauro Carvalho Chehab [mailto:mchehab@xxxxxxxxxxxxx] > Sent: Thursday, April 29, 2010 9:31 AM > To: Muralidharan Karicheri > Cc: linux-media@xxxxxxxxxxxxxxx; Hiremath, Vaibhav; Hans Verkuil; Karicheri, > Muralidharan > Subject: Re: [GIT PATCHES FOR 2.6.35] - Adding OMAP2/3 V4l2 display driver > > Muralidharan Karicheri wrote: > > Hi Mauro, > > > > Please pull from:- > > > > The following changes since commit > 184b7c85f31583632ad00c062a295b622759eef3: > > Mauro Carvalho Chehab (1): > > ir-core: Fix the delete logic > > > > are available in the git repository at: > > > > git://linuxtv.org/mkaricheri/vpfe-vpbe-video.git for_upstream_04_11 > > > > Vaibhav Hiremath (2): > > V4L2: Add support for OMAP2/3 V4L2 display driver on top of DSS2 > > omap_vout:V4L2 Display: Changed enum return type to int > > > > drivers/media/video/Kconfig | 2 + > > drivers/media/video/Makefile | 2 + > > drivers/media/video/omap/Kconfig | 11 + > > drivers/media/video/omap/Makefile | 7 + > > drivers/media/video/omap/omap_vout.c | 2643 > +++++++++++++++++++++++++++++++ > > drivers/media/video/omap/omap_voutdef.h | 147 ++ > > drivers/media/video/omap/omap_voutlib.c | 293 ++++ > > drivers/media/video/omap/omap_voutlib.h | 34 + > > 8 files changed, 3139 insertions(+), 0 deletions(-) > > create mode 100644 drivers/media/video/omap/Kconfig > > create mode 100644 drivers/media/video/omap/Makefile > > create mode 100644 drivers/media/video/omap/omap_vout.c > > create mode 100644 drivers/media/video/omap/omap_voutdef.h > > create mode 100644 drivers/media/video/omap/omap_voutlib.c > > create mode 100644 drivers/media/video/omap/omap_voutlib.h > > > > Applied. Yet, I didn't like to see all those memory allocations for userprt > inside > the driver. IMO, it would be better placed inside the videobuf code. > [Hiremath, Vaibhav] Mauro, The OMAP is a really different device in terms of how the features are supported; let's take an example of rotation here, Rotation is supported by another separate hardware module called VRFB (Virtual rotation FB) and there are some constraints on how you can use it, for example, the line length (pitch) must be 2048. Also VRFB has 12 contexts only and shared all over system (V4L2 display and Fbdev driver) so we should be using it efficiently. Now as an application user I wouldn't want to consider this constraint and allocate this much huge buffer although we are not using it. Also most of the cases buffers come from other modules like, codes, DSP side application. So the approach we took here is, we are limiting user application to use 4 buffers only in case of rotation enabled. And differentiating user and VRFB buffers, so that user doesn't have to care about all VRFB related constraints here. Internally system DMA copies user buffer to VRFB buffers. That's where we required buffer allocation which can not be generic. Thanks, Vaibhav > -- > > Cheers, > Mauro -- 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
