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
next prev parent 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