From: Kieran Bingham <kieran.bingham@ideasonboard.com>
To: Tomasz Figa <tfiga@google.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
g.liakhovetski@gmx.de, olivier.braun@stereolabs.com,
troy.kisky@boundarydevices.com,
Randy Dunlap <rdunlap@infradead.org>,
philipp.zabel@gmail.com,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 6/6] media: uvcvideo: Move decode processing to process context
Date: Tue, 6 Nov 2018 15:13:55 +0000 [thread overview]
Message-ID: <4fa1b96d-912c-ec07-f08e-d8de164a0186@ideasonboard.com> (raw)
In-Reply-To: <CAAFQd5CQEhmuLbs0dmGfu66x1Xq1V_kOT0bV_DoPitkkOX5Q4A@mail.gmail.com>
Hi Tomasz,
On 07/08/2018 10:54, Tomasz Figa wrote:
> Hi Kieran,
>
> On Wed, Mar 28, 2018 at 1:47 AM Kieran Bingham
> <kieran.bingham@ideasonboard.com> wrote:
> [snip]
>> @@ -1544,25 +1594,29 @@ static int uvc_alloc_urb_buffers(struct uvc_streaming *stream,
>> */
>> static void uvc_uninit_video(struct uvc_streaming *stream, int free_buffers)
>> {
>> - struct urb *urb;
>> - unsigned int i;
>> + struct uvc_urb *uvc_urb;
>>
>> uvc_video_stats_stop(stream);
>>
>> - for (i = 0; i < UVC_URBS; ++i) {
>> - struct uvc_urb *uvc_urb = &stream->uvc_urb[i];
>> + /*
>> + * We must poison the URBs rather than kill them to ensure that even
>> + * after the completion handler returns, any asynchronous workqueues
>> + * will be prevented from resubmitting the URBs
>> + */
>> + for_each_uvc_urb(uvc_urb, stream)
>> + usb_poison_urb(uvc_urb->urb);
>>
>> - urb = uvc_urb->urb;
>> - if (urb == NULL)
>> - continue;
>> + flush_workqueue(stream->async_wq);
>>
>> - usb_kill_urb(urb);
>> - usb_free_urb(urb);
>> + for_each_uvc_urb(uvc_urb, stream) {
>> + usb_free_urb(uvc_urb->urb);
>> uvc_urb->urb = NULL;
>> }
>>
>> if (free_buffers)
>> uvc_free_urb_buffers(stream);
>> +
>> + destroy_workqueue(stream->async_wq);
>
> In our testing, this function ends up being called twice, if before
> suspend the camera is streaming and if the camera disconnects between
> suspend and resume. This is because uvc_video_suspend() calls this
> function (with free_buffers = 0), but uvc_video_resume() wouldn't call
> uvc_init_video() due to an earlier failure and uvc_v4l2_release()
> would end up calling this function again, while the workqueue is
> already destroyed.
>
> The following diff seems to take care of it:
Thank you for this. After discussing with Laurent, I have gone with the
approach of keeping the workqueue for the lifetime of the stream, rather
than the lifetime of the streamon.
>
> 8<~~~
> diff --git a/drivers/media/usb/uvc/uvc_video.c
> b/drivers/media/usb/uvc/uvc_video.c
> index c5e0ab564b1a..6fb890c8ba67 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -1493,10 +1493,11 @@ static void uvc_uninit_video(struct
> uvc_streaming *stream, int free_buffers)
> uvc_urb->urb = NULL;
> }
>
> - if (free_buffers)
> + if (free_buffers) {
> uvc_free_urb_buffers(stream);
> -
> - destroy_workqueue(stream->async_wq);
> + destroy_workqueue(stream->async_wq);
> + stream->async_wq = NULL;
> + }
> }
>
> /*
> @@ -1648,10 +1649,12 @@ static int uvc_init_video(struct uvc_streaming
> *stream, gfp_t gfp_flags)
>
> uvc_video_stats_start(stream);
>
> - stream->async_wq = alloc_workqueue("uvcvideo", WQ_UNBOUND | WQ_HIGHPRI,
> - 0);
> - if (!stream->async_wq)
> - return -ENOMEM;
> + if (!stream->async_wq) {
> + stream->async_wq = alloc_workqueue("uvcvideo",
> + WQ_UNBOUND | WQ_HIGHPRI, 0);
> + if (!stream->async_wq)
> + return -ENOMEM;
> + }
>
> if (intf->num_altsetting > 1) {
> struct usb_host_endpoint *best_ep = NULL;
> ~~~>8
>
> Best regards,
> Tomasz
>
--
Regards
--
Kieran
next prev parent reply other threads:[~2018-11-06 15:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.3cb9065dabdf5d455da508fb4109201e626d5ee7.1522168131.git-series.kieran.bingham@ideasonboard.com>
2018-03-27 16:45 ` [PATCH v4 1/6] media: uvcvideo: Refactor URB descriptors Kieran Bingham
2018-03-27 16:45 ` [PATCH v4 2/6] media: uvcvideo: Convert decode functions to use new context structure Kieran Bingham
2018-03-27 16:46 ` [PATCH v4 3/6] media: uvcvideo: Protect queue internals with helper Kieran Bingham
2018-03-27 16:46 ` [PATCH v4 4/6] media: uvcvideo: queue: Simplify spin-lock usage Kieran Bingham
2018-07-30 19:57 ` Laurent Pinchart
2018-11-06 15:10 ` Kieran Bingham
2018-03-27 16:46 ` [PATCH v4 5/6] media: uvcvideo: queue: Support asynchronous buffer handling Kieran Bingham
2018-03-27 16:46 ` [PATCH v4 6/6] media: uvcvideo: Move decode processing to process context Kieran Bingham
2018-06-04 12:09 ` Guennadi Liakhovetski
2018-06-04 12:34 ` Kieran Bingham
2018-07-30 22:11 ` Laurent Pinchart
2018-08-07 9:54 ` Tomasz Figa
2018-08-07 23:06 ` Laurent Pinchart
2018-08-07 23:13 ` Laurent Pinchart
2018-08-08 3:50 ` Tomasz Figa
2018-08-08 13:49 ` Kieran Bingham
2018-11-06 15:13 ` Kieran Bingham [this message]
2018-11-07 4:38 ` Tomasz Figa
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=4fa1b96d-912c-ec07-f08e-d8de164a0186@ideasonboard.com \
--to=kieran.bingham@ideasonboard.com \
--cc=g.liakhovetski@gmx.de \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=olivier.braun@stereolabs.com \
--cc=philipp.zabel@gmail.com \
--cc=rdunlap@infradead.org \
--cc=tfiga@google.com \
--cc=troy.kisky@boundarydevices.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;
as well as URLs for NNTP newsgroup(s).