public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
	LMML <linux-media@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] media: omap3isp: ispvideo: drop driver specific isp_video_fh
Date: Tue, 24 Feb 2015 11:07:53 +0200	[thread overview]
Message-ID: <1975486.DZ2Ir2MLZP@avalon> (raw)
In-Reply-To: <CA+V-a8urdZhD97m4mQu_aYLWW9Kf0PSx=ddhbvteb-HRz2hEEA@mail.gmail.com>

Hi Prabhakar,

On Tuesday 24 February 2015 08:04:40 Lad, Prabhakar wrote:
> On Tue, Feb 24, 2015 at 12:35 AM, Laurent Pinchart wrote:
> > On Monday 23 February 2015 20:19:32 Lad Prabhakar wrote:
> >> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
> >> 
> >> this patch drops driver specific isp_video_fh, as this
> >> can be handled by core.
> > 
> > I'm afraid it's not that simple.
> > 
> > The omap3isp driver stores video queues per file handle for a reason. This
> > was design to permit creating a high-resolution still image capture queue
> > and prepare buffers ahead of time, to avoid the large delay due to cache
> > management as prepare time when taking the snapshot.
> 
> Ah I see the reason.
> 
> > Now this use case has been partially solved by VIDIOC_CREATE_BUFS, but
> > we're still missing a VIDIOC_DESTROY_BUFS to make it work completely.
> > That needs to be solved first.
> 
> I haven't used the VIDIOC_CREATE_BUFS ioctl so far in any of the apps
> so cant comment much on this.
> But isn't that obvious we need VIDIOC_DESTROY_BUFS or is there any backdoor
> to destroy them that I am missing ?

You can destroy buffers allocated with CREATE_BUFS using REQBUFS(0), but you 
can't destroy them individually without a new ioctl.

> >> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> >> ---
> >> 
> >>  drivers/media/platform/omap3isp/ispvideo.c | 128 +++++++++--------------
> >>  drivers/media/platform/omap3isp/ispvideo.h |  13 +--
> >>  2 files changed, 49 http://vger.kernel.org/majordomo-info.html

-- 
Regards,

Laurent Pinchart


  reply	other threads:[~2015-02-24  9:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-23 20:19 [PATCH 0/3] omap3isp trivial enhancements Lad Prabhakar
2015-02-23 20:19 ` [PATCH 1/3] media: omap3isp: ispvideo: drop setting of vb2 buffer state to VB2_BUF_STATE_ACTIVE Lad Prabhakar
2015-02-24  0:12   ` Laurent Pinchart
2015-02-23 20:19 ` [PATCH 2/3] media: omap3isp: ispvideo: drop driver specific isp_video_fh Lad Prabhakar
2015-02-24  0:35   ` Laurent Pinchart
2015-02-24  8:04     ` Lad, Prabhakar
2015-02-24  9:07       ` Laurent Pinchart [this message]
2015-02-23 20:19 ` [PATCH 3/3] media: omap3isp: ispvideo: use vb2_fop_mmap/poll Lad Prabhakar
2015-02-24  0:23   ` Laurent Pinchart
2015-02-24  7:54     ` Lad, Prabhakar
2015-03-08 20:19     ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1975486.DZ2Ir2MLZP@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=prabhakar.csengg@gmail.com \
    --cc=sakari.ailus@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox