* [PATCH v2 1/3] usb: gadget: uvc: make interrupt skip logic configurable
2022-10-11 18:34 [PATCH v2 0/3] uvc gadget performance issues Dan Vacura
@ 2022-10-11 18:34 ` Dan Vacura
2022-10-12 20:44 ` Dan Vacura
2022-10-11 18:34 ` [PATCH v2 2/3] usb: gadget: uvc: fix sg handling in error case Dan Vacura
` (2 subsequent siblings)
3 siblings, 1 reply; 8+ messages in thread
From: Dan Vacura @ 2022-10-11 18:34 UTC (permalink / raw)
To: linux-usb
Cc: Daniel Scally, Thinh Nguyen, Dan Vacura, stable,
Greg Kroah-Hartman, Jonathan Corbet, Laurent Pinchart,
Felipe Balbi, Paul Elder, Michael Grzeschik, linux-kernel,
linux-doc
Some UDC hw may not support skipping interrupts, but still support the
request. Allow the interrupt frequency to be configurable to the user.
Default to not skip interrupts, a value of 0. This fixes a smmu panic
that is occurring on dwc3 hw.
Fixes: fc78941d8169 ("usb: gadget: uvc: decrease the interrupt load to a quarter")
Cc: <stable@vger.kernel.org>
Signed-off-by: Dan Vacura <w36195@motorola.com>
---
V1 -> V2:
- no change, new patch in series
Documentation/ABI/testing/configfs-usb-gadget-uvc | 1 +
Documentation/usb/gadget-testing.rst | 2 ++
drivers/usb/gadget/function/f_uvc.c | 3 +++
drivers/usb/gadget/function/u_uvc.h | 1 +
drivers/usb/gadget/function/uvc.h | 1 +
drivers/usb/gadget/function/uvc_configfs.c | 2 ++
drivers/usb/gadget/function/uvc_queue.c | 6 ++++++
drivers/usb/gadget/function/uvc_video.c | 3 ++-
8 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc b/Documentation/ABI/testing/configfs-usb-gadget-uvc
index 611b23e6488d..5dfaa3f7f6a4 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-uvc
+++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc
@@ -8,6 +8,7 @@ Description: UVC function directory
streaming_maxpacket 1..1023 (fs), 1..3072 (hs/ss)
streaming_interval 1..16
function_name string [32]
+ req_int_skip_div unsigned int
=================== =============================
What: /config/usb-gadget/gadget/functions/uvc.name/control
diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst
index 2278c9ffb74a..f9b5a09be1f4 100644
--- a/Documentation/usb/gadget-testing.rst
+++ b/Documentation/usb/gadget-testing.rst
@@ -794,6 +794,8 @@ The uvc function provides these attributes in its function directory:
sending or receiving when this configuration is
selected
function_name name of the interface
+ req_int_skip_div divisor of total requests to aid in calculating
+ interrupt frequency, 0 indicates all interrupt
=================== ================================================
There are also "control" and "streaming" subdirectories, each of which contain
diff --git a/drivers/usb/gadget/function/f_uvc.c b/drivers/usb/gadget/function/f_uvc.c
index 6e196e06181e..75f524c83996 100644
--- a/drivers/usb/gadget/function/f_uvc.c
+++ b/drivers/usb/gadget/function/f_uvc.c
@@ -655,6 +655,8 @@ uvc_function_bind(struct usb_configuration *c, struct usb_function *f)
cpu_to_le16(max_packet_size * max_packet_mult *
(opts->streaming_maxburst + 1));
+ uvc->video.req_int_skip_div = opts->req_int_skip_div;
+
/* Allocate endpoints. */
ep = usb_ep_autoconfig(cdev->gadget, &uvc_control_ep);
if (!ep) {
@@ -872,6 +874,7 @@ static struct usb_function_instance *uvc_alloc_inst(void)
opts->streaming_interval = 1;
opts->streaming_maxpacket = 1024;
+ opts->req_int_skip_div = 0;
snprintf(opts->function_name, sizeof(opts->function_name), "UVC Camera");
ret = uvcg_attach_configfs(opts);
diff --git a/drivers/usb/gadget/function/u_uvc.h b/drivers/usb/gadget/function/u_uvc.h
index 24b8681b0d6f..6f73bd5638ed 100644
--- a/drivers/usb/gadget/function/u_uvc.h
+++ b/drivers/usb/gadget/function/u_uvc.h
@@ -24,6 +24,7 @@ struct f_uvc_opts {
unsigned int streaming_interval;
unsigned int streaming_maxpacket;
unsigned int streaming_maxburst;
+ unsigned int req_int_skip_div;
unsigned int control_interface;
unsigned int streaming_interface;
diff --git a/drivers/usb/gadget/function/uvc.h b/drivers/usb/gadget/function/uvc.h
index 40226b1f7e14..53175cd564e5 100644
--- a/drivers/usb/gadget/function/uvc.h
+++ b/drivers/usb/gadget/function/uvc.h
@@ -107,6 +107,7 @@ struct uvc_video {
spinlock_t req_lock;
unsigned int req_int_count;
+ unsigned int req_int_skip_div;
void (*encode) (struct usb_request *req, struct uvc_video *video,
struct uvc_buffer *buf);
diff --git a/drivers/usb/gadget/function/uvc_configfs.c b/drivers/usb/gadget/function/uvc_configfs.c
index 4303a3283ba0..419e926ab57e 100644
--- a/drivers/usb/gadget/function/uvc_configfs.c
+++ b/drivers/usb/gadget/function/uvc_configfs.c
@@ -2350,6 +2350,7 @@ UVC_ATTR(f_uvc_opts_, cname, cname)
UVCG_OPTS_ATTR(streaming_interval, streaming_interval, 16);
UVCG_OPTS_ATTR(streaming_maxpacket, streaming_maxpacket, 3072);
UVCG_OPTS_ATTR(streaming_maxburst, streaming_maxburst, 15);
+UVCG_OPTS_ATTR(req_int_skip_div, req_int_skip_div, UINT_MAX);
#undef UVCG_OPTS_ATTR
@@ -2399,6 +2400,7 @@ static struct configfs_attribute *uvc_attrs[] = {
&f_uvc_opts_attr_streaming_interval,
&f_uvc_opts_attr_streaming_maxpacket,
&f_uvc_opts_attr_streaming_maxburst,
+ &f_uvc_opts_attr_req_int_skip_div,
&f_uvc_opts_string_attr_function_name,
NULL,
};
diff --git a/drivers/usb/gadget/function/uvc_queue.c b/drivers/usb/gadget/function/uvc_queue.c
index ec500ee499ee..872d545838ee 100644
--- a/drivers/usb/gadget/function/uvc_queue.c
+++ b/drivers/usb/gadget/function/uvc_queue.c
@@ -63,6 +63,12 @@ static int uvc_queue_setup(struct vb2_queue *vq,
*/
nreq = DIV_ROUND_UP(DIV_ROUND_UP(sizes[0], 2), req_size);
nreq = clamp(nreq, 4U, 64U);
+ if (0 == video->req_int_skip_div) {
+ video->req_int_skip_div = nreq;
+ } else {
+ video->req_int_skip_div =
+ min_t(unsigned int, nreq, video->req_int_skip_div);
+ }
video->uvc_num_requests = nreq;
return 0;
diff --git a/drivers/usb/gadget/function/uvc_video.c b/drivers/usb/gadget/function/uvc_video.c
index bb037fcc90e6..241df42ce0ae 100644
--- a/drivers/usb/gadget/function/uvc_video.c
+++ b/drivers/usb/gadget/function/uvc_video.c
@@ -413,7 +413,8 @@ static void uvcg_video_pump(struct work_struct *work)
if (list_empty(&video->req_free) ||
buf->state == UVC_BUF_STATE_DONE ||
!(video->req_int_count %
- DIV_ROUND_UP(video->uvc_num_requests, 4))) {
+ DIV_ROUND_UP(video->uvc_num_requests,
+ video->req_int_skip_div))) {
video->req_int_count = 0;
req->no_interrupt = 0;
} else {
--
2.34.1
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [PATCH v2 1/3] usb: gadget: uvc: make interrupt skip logic configurable
2022-10-11 18:34 ` [PATCH v2 1/3] usb: gadget: uvc: make interrupt skip logic configurable Dan Vacura
@ 2022-10-12 20:44 ` Dan Vacura
0 siblings, 0 replies; 8+ messages in thread
From: Dan Vacura @ 2022-10-12 20:44 UTC (permalink / raw)
To: linux-usb
Cc: Daniel Scally, Thinh Nguyen, stable, Greg Kroah-Hartman,
Jonathan Corbet, Laurent Pinchart, Felipe Balbi, Paul Elder,
Michael Grzeschik, linux-kernel, linux-doc
It looks like configurability of interrupt throttling is not in favor,
but if we do proceed with this patch, I'll need to fix some logic. I
found a bug where req_int_skip_div will have a stale value used with
repeated resolution switches.
This fixes the bug:
diff --git a/drivers/usb/gadget/function/f_uvc.c b/drivers/usb/gadget/function/f_uvc.c
index 003c2d610e61..b7a5681d5f85 100644
--- a/drivers/usb/gadget/function/f_uvc.c
+++ b/drivers/usb/gadget/function/f_uvc.c
@@ -649,7 +649,7 @@ uvc_function_bind(struct usb_configuration *c, struct usb_function *f)
cpu_to_le16(max_packet_size * max_packet_mult *
(opts->streaming_maxburst + 1));
- uvc->video.req_int_skip_div = opts->req_int_skip_div;
+ uvc->config_skip_int_div = opts->req_int_skip_div;
uvc->video.queue.use_sg = opts->sg_supported;
/* Allocate endpoints. */
diff --git a/drivers/usb/gadget/function/uvc.h b/drivers/usb/gadget/function/uvc.h
index ddca23680c35..e7033cce0a43 100644
--- a/drivers/usb/gadget/function/uvc.h
+++ b/drivers/usb/gadget/function/uvc.h
@@ -153,6 +153,7 @@ struct uvc_device {
/* Events */
unsigned int event_length;
unsigned int event_setup_out : 1;
+ unsigned int config_skip_int_div;
};
static inline struct uvc_device *to_uvc(struct usb_function *f)
diff --git a/drivers/usb/gadget/function/uvc_queue.c b/drivers/usb/gadget/function/uvc_queue.c
index c7b76ac36194..b6fada4eab12 100644
--- a/drivers/usb/gadget/function/uvc_queue.c
+++ b/drivers/usb/gadget/function/uvc_queue.c
@@ -63,11 +63,11 @@ static int uvc_queue_setup(struct vb2_queue *vq,
*/
nreq = DIV_ROUND_UP(DIV_ROUND_UP(sizes[0], 2), req_size);
nreq = clamp(nreq, 4U, 64U);
- if (0 == video->req_int_skip_div) {
+ if (0 == video->uvc->config_skip_int_div) {
video->req_int_skip_div = nreq;
} else {
- video->req_int_skip_div =
- min_t(unsigned int, nreq, video->req_int_skip_div);
+ video->req_int_skip_div = min_t(unsigned int, nreq,
+ video->uvc->config_skip_int_div);
}
video->uvc_num_requests = nreq;
On Tue, Oct 11, 2022 at 01:34:33PM -0500, Dan Vacura wrote:
> Some UDC hw may not support skipping interrupts, but still support the
> request. Allow the interrupt frequency to be configurable to the user.
> Default to not skip interrupts, a value of 0. This fixes a smmu panic
> that is occurring on dwc3 hw.
>
> Fixes: fc78941d8169 ("usb: gadget: uvc: decrease the interrupt load to a quarter")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Dan Vacura <w36195@motorola.com>
> ---
> V1 -> V2:
> - no change, new patch in series
>
> Documentation/ABI/testing/configfs-usb-gadget-uvc | 1 +
> Documentation/usb/gadget-testing.rst | 2 ++
> drivers/usb/gadget/function/f_uvc.c | 3 +++
> drivers/usb/gadget/function/u_uvc.h | 1 +
> drivers/usb/gadget/function/uvc.h | 1 +
> drivers/usb/gadget/function/uvc_configfs.c | 2 ++
> drivers/usb/gadget/function/uvc_queue.c | 6 ++++++
> drivers/usb/gadget/function/uvc_video.c | 3 ++-
> 8 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc b/Documentation/ABI/testing/configfs-usb-gadget-uvc
> index 611b23e6488d..5dfaa3f7f6a4 100644
> --- a/Documentation/ABI/testing/configfs-usb-gadget-uvc
> +++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc
> @@ -8,6 +8,7 @@ Description: UVC function directory
> streaming_maxpacket 1..1023 (fs), 1..3072 (hs/ss)
> streaming_interval 1..16
> function_name string [32]
> + req_int_skip_div unsigned int
> =================== =============================
>
> What: /config/usb-gadget/gadget/functions/uvc.name/control
> diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst
> index 2278c9ffb74a..f9b5a09be1f4 100644
> --- a/Documentation/usb/gadget-testing.rst
> +++ b/Documentation/usb/gadget-testing.rst
> @@ -794,6 +794,8 @@ The uvc function provides these attributes in its function directory:
> sending or receiving when this configuration is
> selected
> function_name name of the interface
> + req_int_skip_div divisor of total requests to aid in calculating
> + interrupt frequency, 0 indicates all interrupt
> =================== ================================================
>
> There are also "control" and "streaming" subdirectories, each of which contain
> diff --git a/drivers/usb/gadget/function/f_uvc.c b/drivers/usb/gadget/function/f_uvc.c
> index 6e196e06181e..75f524c83996 100644
> --- a/drivers/usb/gadget/function/f_uvc.c
> +++ b/drivers/usb/gadget/function/f_uvc.c
> @@ -655,6 +655,8 @@ uvc_function_bind(struct usb_configuration *c, struct usb_function *f)
> cpu_to_le16(max_packet_size * max_packet_mult *
> (opts->streaming_maxburst + 1));
>
> + uvc->video.req_int_skip_div = opts->req_int_skip_div;
> +
> /* Allocate endpoints. */
> ep = usb_ep_autoconfig(cdev->gadget, &uvc_control_ep);
> if (!ep) {
> @@ -872,6 +874,7 @@ static struct usb_function_instance *uvc_alloc_inst(void)
>
> opts->streaming_interval = 1;
> opts->streaming_maxpacket = 1024;
> + opts->req_int_skip_div = 0;
> snprintf(opts->function_name, sizeof(opts->function_name), "UVC Camera");
>
> ret = uvcg_attach_configfs(opts);
> diff --git a/drivers/usb/gadget/function/u_uvc.h b/drivers/usb/gadget/function/u_uvc.h
> index 24b8681b0d6f..6f73bd5638ed 100644
> --- a/drivers/usb/gadget/function/u_uvc.h
> +++ b/drivers/usb/gadget/function/u_uvc.h
> @@ -24,6 +24,7 @@ struct f_uvc_opts {
> unsigned int streaming_interval;
> unsigned int streaming_maxpacket;
> unsigned int streaming_maxburst;
> + unsigned int req_int_skip_div;
>
> unsigned int control_interface;
> unsigned int streaming_interface;
> diff --git a/drivers/usb/gadget/function/uvc.h b/drivers/usb/gadget/function/uvc.h
> index 40226b1f7e14..53175cd564e5 100644
> --- a/drivers/usb/gadget/function/uvc.h
> +++ b/drivers/usb/gadget/function/uvc.h
> @@ -107,6 +107,7 @@ struct uvc_video {
> spinlock_t req_lock;
>
> unsigned int req_int_count;
> + unsigned int req_int_skip_div;
>
> void (*encode) (struct usb_request *req, struct uvc_video *video,
> struct uvc_buffer *buf);
> diff --git a/drivers/usb/gadget/function/uvc_configfs.c b/drivers/usb/gadget/function/uvc_configfs.c
> index 4303a3283ba0..419e926ab57e 100644
> --- a/drivers/usb/gadget/function/uvc_configfs.c
> +++ b/drivers/usb/gadget/function/uvc_configfs.c
> @@ -2350,6 +2350,7 @@ UVC_ATTR(f_uvc_opts_, cname, cname)
> UVCG_OPTS_ATTR(streaming_interval, streaming_interval, 16);
> UVCG_OPTS_ATTR(streaming_maxpacket, streaming_maxpacket, 3072);
> UVCG_OPTS_ATTR(streaming_maxburst, streaming_maxburst, 15);
> +UVCG_OPTS_ATTR(req_int_skip_div, req_int_skip_div, UINT_MAX);
>
> #undef UVCG_OPTS_ATTR
>
> @@ -2399,6 +2400,7 @@ static struct configfs_attribute *uvc_attrs[] = {
> &f_uvc_opts_attr_streaming_interval,
> &f_uvc_opts_attr_streaming_maxpacket,
> &f_uvc_opts_attr_streaming_maxburst,
> + &f_uvc_opts_attr_req_int_skip_div,
> &f_uvc_opts_string_attr_function_name,
> NULL,
> };
> diff --git a/drivers/usb/gadget/function/uvc_queue.c b/drivers/usb/gadget/function/uvc_queue.c
> index ec500ee499ee..872d545838ee 100644
> --- a/drivers/usb/gadget/function/uvc_queue.c
> +++ b/drivers/usb/gadget/function/uvc_queue.c
> @@ -63,6 +63,12 @@ static int uvc_queue_setup(struct vb2_queue *vq,
> */
> nreq = DIV_ROUND_UP(DIV_ROUND_UP(sizes[0], 2), req_size);
> nreq = clamp(nreq, 4U, 64U);
> + if (0 == video->req_int_skip_div) {
> + video->req_int_skip_div = nreq;
> + } else {
> + video->req_int_skip_div =
> + min_t(unsigned int, nreq, video->req_int_skip_div);
> + }
> video->uvc_num_requests = nreq;
>
> return 0;
> diff --git a/drivers/usb/gadget/function/uvc_video.c b/drivers/usb/gadget/function/uvc_video.c
> index bb037fcc90e6..241df42ce0ae 100644
> --- a/drivers/usb/gadget/function/uvc_video.c
> +++ b/drivers/usb/gadget/function/uvc_video.c
> @@ -413,7 +413,8 @@ static void uvcg_video_pump(struct work_struct *work)
> if (list_empty(&video->req_free) ||
> buf->state == UVC_BUF_STATE_DONE ||
> !(video->req_int_count %
> - DIV_ROUND_UP(video->uvc_num_requests, 4))) {
> + DIV_ROUND_UP(video->uvc_num_requests,
> + video->req_int_skip_div))) {
> video->req_int_count = 0;
> req->no_interrupt = 0;
> } else {
> --
> 2.34.1
>
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH v2 2/3] usb: gadget: uvc: fix sg handling in error case
2022-10-11 18:34 [PATCH v2 0/3] uvc gadget performance issues Dan Vacura
2022-10-11 18:34 ` [PATCH v2 1/3] usb: gadget: uvc: make interrupt skip logic configurable Dan Vacura
@ 2022-10-11 18:34 ` Dan Vacura
2022-10-11 18:34 ` [PATCH v2 3/3] usb: gadget: uvc: add configfs option for sg support Dan Vacura
2022-10-11 19:48 ` [PATCH v2 0/3] uvc gadget performance issues Michael Grzeschik
3 siblings, 0 replies; 8+ messages in thread
From: Dan Vacura @ 2022-10-11 18:34 UTC (permalink / raw)
To: linux-usb
Cc: Daniel Scally, Thinh Nguyen, Dan Vacura, stable,
Greg Kroah-Hartman, Jonathan Corbet, Laurent Pinchart,
Felipe Balbi, Paul Elder, Michael Grzeschik, linux-kernel,
linux-doc
If there is a transmission error the buffer will be returned too early,
causing a memory fault as subsequent requests for that buffer are still
queued up to be sent. Refactor the error handling to wait for the final
request to come in before reporting back the buffer to userspace for all
transfer types (bulk/isoc/isoc_sg). This ensures userspace knows if the
frame was successfully sent.
Fixes: e81e7f9a0eb9 ("usb: gadget: uvc: add scatter gather support")
Cc: <stable@vger.kernel.org> # 859c675d84d4: usb: gadget: uvc: consistently use define for headerlen
Cc: <stable@vger.kernel.org> # f262ce66d40c: usb: gadget: uvc: use on returned header len in video_encode_isoc_sg
Cc: <stable@vger.kernel.org> # 61aa709ca58a: usb: gadget: uvc: rework uvcg_queue_next_buffer to uvcg_complete_buffer
Cc: <stable@vger.kernel.org> # 9b969f93bcef: usb: gadget: uvc: giveback vb2 buffer on req complete
Cc: <stable@vger.kernel.org> # aef11279888c: usb: gadget: uvc: improve sg exit condition
Cc: <stable@vger.kernel.org>
Signed-off-by: Dan Vacura <w36195@motorola.com>
---
V1 -> V2:
- undo error rename
- change uvcg_info to uvcg_dbg
drivers/usb/gadget/function/uvc_queue.c | 8 +++++---
drivers/usb/gadget/function/uvc_video.c | 18 ++++++++++++++----
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/gadget/function/uvc_queue.c b/drivers/usb/gadget/function/uvc_queue.c
index 872d545838ee..fc65f8e73732 100644
--- a/drivers/usb/gadget/function/uvc_queue.c
+++ b/drivers/usb/gadget/function/uvc_queue.c
@@ -310,6 +310,7 @@ int uvcg_queue_enable(struct uvc_video_queue *queue, int enable)
queue->sequence = 0;
queue->buf_used = 0;
+ queue->flags &= ~UVC_QUEUE_DROP_INCOMPLETE;
} else {
ret = vb2_streamoff(&queue->queue, queue->queue.type);
if (ret < 0)
@@ -335,10 +336,11 @@ int uvcg_queue_enable(struct uvc_video_queue *queue, int enable)
void uvcg_complete_buffer(struct uvc_video_queue *queue,
struct uvc_buffer *buf)
{
- if ((queue->flags & UVC_QUEUE_DROP_INCOMPLETE) &&
- buf->length != buf->bytesused) {
- buf->state = UVC_BUF_STATE_QUEUED;
+ if (queue->flags & UVC_QUEUE_DROP_INCOMPLETE) {
+ queue->flags &= ~UVC_QUEUE_DROP_INCOMPLETE;
+ buf->state = UVC_BUF_STATE_ERROR;
vb2_set_plane_payload(&buf->buf.vb2_buf, 0, 0);
+ vb2_buffer_done(&buf->buf.vb2_buf, VB2_BUF_STATE_ERROR);
return;
}
diff --git a/drivers/usb/gadget/function/uvc_video.c b/drivers/usb/gadget/function/uvc_video.c
index 241df42ce0ae..9d76101c699d 100644
--- a/drivers/usb/gadget/function/uvc_video.c
+++ b/drivers/usb/gadget/function/uvc_video.c
@@ -88,6 +88,7 @@ uvc_video_encode_bulk(struct usb_request *req, struct uvc_video *video,
struct uvc_buffer *buf)
{
void *mem = req->buf;
+ struct uvc_request *ureq = req->context;
int len = video->req_size;
int ret;
@@ -113,13 +114,14 @@ uvc_video_encode_bulk(struct usb_request *req, struct uvc_video *video,
video->queue.buf_used = 0;
buf->state = UVC_BUF_STATE_DONE;
list_del(&buf->queue);
- uvcg_complete_buffer(&video->queue, buf);
video->fid ^= UVC_STREAM_FID;
+ ureq->last_buf = buf;
video->payload_size = 0;
}
if (video->payload_size == video->max_payload_size ||
+ video->queue.flags & UVC_QUEUE_DROP_INCOMPLETE ||
buf->bytesused == video->queue.buf_used)
video->payload_size = 0;
}
@@ -180,7 +182,8 @@ uvc_video_encode_isoc_sg(struct usb_request *req, struct uvc_video *video,
req->length -= len;
video->queue.buf_used += req->length - header_len;
- if (buf->bytesused == video->queue.buf_used || !buf->sg) {
+ if (buf->bytesused == video->queue.buf_used || !buf->sg ||
+ video->queue.flags & UVC_QUEUE_DROP_INCOMPLETE) {
video->queue.buf_used = 0;
buf->state = UVC_BUF_STATE_DONE;
buf->offset = 0;
@@ -195,6 +198,7 @@ uvc_video_encode_isoc(struct usb_request *req, struct uvc_video *video,
struct uvc_buffer *buf)
{
void *mem = req->buf;
+ struct uvc_request *ureq = req->context;
int len = video->req_size;
int ret;
@@ -209,12 +213,13 @@ uvc_video_encode_isoc(struct usb_request *req, struct uvc_video *video,
req->length = video->req_size - len;
- if (buf->bytesused == video->queue.buf_used) {
+ if (buf->bytesused == video->queue.buf_used ||
+ video->queue.flags & UVC_QUEUE_DROP_INCOMPLETE) {
video->queue.buf_used = 0;
buf->state = UVC_BUF_STATE_DONE;
list_del(&buf->queue);
- uvcg_complete_buffer(&video->queue, buf);
video->fid ^= UVC_STREAM_FID;
+ ureq->last_buf = buf;
}
}
@@ -255,6 +260,11 @@ uvc_video_complete(struct usb_ep *ep, struct usb_request *req)
case 0:
break;
+ case -EXDEV:
+ uvcg_dbg(&video->uvc->func, "VS request missed xfer.\n");
+ queue->flags |= UVC_QUEUE_DROP_INCOMPLETE;
+ break;
+
case -ESHUTDOWN: /* disconnect from host. */
uvcg_dbg(&video->uvc->func, "VS request cancelled.\n");
uvcg_queue_cancel(queue, 1);
--
2.34.1
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH v2 3/3] usb: gadget: uvc: add configfs option for sg support
2022-10-11 18:34 [PATCH v2 0/3] uvc gadget performance issues Dan Vacura
2022-10-11 18:34 ` [PATCH v2 1/3] usb: gadget: uvc: make interrupt skip logic configurable Dan Vacura
2022-10-11 18:34 ` [PATCH v2 2/3] usb: gadget: uvc: fix sg handling in error case Dan Vacura
@ 2022-10-11 18:34 ` Dan Vacura
2022-10-11 19:48 ` [PATCH v2 0/3] uvc gadget performance issues Michael Grzeschik
3 siblings, 0 replies; 8+ messages in thread
From: Dan Vacura @ 2022-10-11 18:34 UTC (permalink / raw)
To: linux-usb
Cc: Daniel Scally, Thinh Nguyen, Dan Vacura, stable,
Greg Kroah-Hartman, Jonathan Corbet, Laurent Pinchart,
Felipe Balbi, Paul Elder, Michael Grzeschik, linux-kernel,
linux-doc
The scatter gather support doesn't appear to work well with some UDC hw.
Add the ability to turn on the feature depending on the controller in
use. Default the feature off since there are transmission problems with
at least one controller, dwc3.
Fixes: e81e7f9a0eb9 ("usb: gadget: uvc: add scatter gather support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Dan Vacura <w36195@motorola.com>
---
V1 -> V2:
- no change, new patch in series
Documentation/ABI/testing/configfs-usb-gadget-uvc | 1 +
Documentation/usb/gadget-testing.rst | 2 ++
drivers/usb/gadget/function/f_uvc.c | 2 ++
drivers/usb/gadget/function/u_uvc.h | 1 +
drivers/usb/gadget/function/uvc_configfs.c | 2 ++
drivers/usb/gadget/function/uvc_queue.c | 4 ++--
6 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc b/Documentation/ABI/testing/configfs-usb-gadget-uvc
index 5dfaa3f7f6a4..839a75fc28ee 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-uvc
+++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc
@@ -9,6 +9,7 @@ Description: UVC function directory
streaming_interval 1..16
function_name string [32]
req_int_skip_div unsigned int
+ sg_supported 0..1
=================== =============================
What: /config/usb-gadget/gadget/functions/uvc.name/control
diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst
index f9b5a09be1f4..8e3072d6a590 100644
--- a/Documentation/usb/gadget-testing.rst
+++ b/Documentation/usb/gadget-testing.rst
@@ -796,6 +796,8 @@ The uvc function provides these attributes in its function directory:
function_name name of the interface
req_int_skip_div divisor of total requests to aid in calculating
interrupt frequency, 0 indicates all interrupt
+ sg_supported allow for scatter gather to be used if the UDC
+ hw supports it
=================== ================================================
There are also "control" and "streaming" subdirectories, each of which contain
diff --git a/drivers/usb/gadget/function/f_uvc.c b/drivers/usb/gadget/function/f_uvc.c
index 75f524c83996..965cf5b48094 100644
--- a/drivers/usb/gadget/function/f_uvc.c
+++ b/drivers/usb/gadget/function/f_uvc.c
@@ -656,6 +656,7 @@ uvc_function_bind(struct usb_configuration *c, struct usb_function *f)
(opts->streaming_maxburst + 1));
uvc->video.req_int_skip_div = opts->req_int_skip_div;
+ uvc->video.queue.use_sg = opts->sg_supported;
/* Allocate endpoints. */
ep = usb_ep_autoconfig(cdev->gadget, &uvc_control_ep);
@@ -875,6 +876,7 @@ static struct usb_function_instance *uvc_alloc_inst(void)
opts->streaming_interval = 1;
opts->streaming_maxpacket = 1024;
opts->req_int_skip_div = 0;
+ opts->sg_supported = 0;
snprintf(opts->function_name, sizeof(opts->function_name), "UVC Camera");
ret = uvcg_attach_configfs(opts);
diff --git a/drivers/usb/gadget/function/u_uvc.h b/drivers/usb/gadget/function/u_uvc.h
index 6f73bd5638ed..5ccced629925 100644
--- a/drivers/usb/gadget/function/u_uvc.h
+++ b/drivers/usb/gadget/function/u_uvc.h
@@ -25,6 +25,7 @@ struct f_uvc_opts {
unsigned int streaming_maxpacket;
unsigned int streaming_maxburst;
unsigned int req_int_skip_div;
+ unsigned int sg_supported;
unsigned int control_interface;
unsigned int streaming_interface;
diff --git a/drivers/usb/gadget/function/uvc_configfs.c b/drivers/usb/gadget/function/uvc_configfs.c
index 419e926ab57e..3784c0e02d01 100644
--- a/drivers/usb/gadget/function/uvc_configfs.c
+++ b/drivers/usb/gadget/function/uvc_configfs.c
@@ -2351,6 +2351,7 @@ UVCG_OPTS_ATTR(streaming_interval, streaming_interval, 16);
UVCG_OPTS_ATTR(streaming_maxpacket, streaming_maxpacket, 3072);
UVCG_OPTS_ATTR(streaming_maxburst, streaming_maxburst, 15);
UVCG_OPTS_ATTR(req_int_skip_div, req_int_skip_div, UINT_MAX);
+UVCG_OPTS_ATTR(sg_supported, sg_supported, 1);
#undef UVCG_OPTS_ATTR
@@ -2401,6 +2402,7 @@ static struct configfs_attribute *uvc_attrs[] = {
&f_uvc_opts_attr_streaming_maxpacket,
&f_uvc_opts_attr_streaming_maxburst,
&f_uvc_opts_attr_req_int_skip_div,
+ &f_uvc_opts_attr_sg_supported,
&f_uvc_opts_string_attr_function_name,
NULL,
};
diff --git a/drivers/usb/gadget/function/uvc_queue.c b/drivers/usb/gadget/function/uvc_queue.c
index fc65f8e73732..b11b1e4cfed6 100644
--- a/drivers/usb/gadget/function/uvc_queue.c
+++ b/drivers/usb/gadget/function/uvc_queue.c
@@ -149,11 +149,11 @@ int uvcg_queue_init(struct uvc_video_queue *queue, struct device *dev, enum v4l2
queue->queue.buf_struct_size = sizeof(struct uvc_buffer);
queue->queue.ops = &uvc_queue_qops;
queue->queue.lock = lock;
- if (cdev->gadget->sg_supported) {
+ if (queue->use_sg && cdev->gadget->sg_supported) {
queue->queue.mem_ops = &vb2_dma_sg_memops;
- queue->use_sg = 1;
} else {
queue->queue.mem_ops = &vb2_vmalloc_memops;
+ queue->use_sg = false;
}
queue->queue.timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY
--
2.34.1
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [PATCH v2 0/3] uvc gadget performance issues
2022-10-11 18:34 [PATCH v2 0/3] uvc gadget performance issues Dan Vacura
` (2 preceding siblings ...)
2022-10-11 18:34 ` [PATCH v2 3/3] usb: gadget: uvc: add configfs option for sg support Dan Vacura
@ 2022-10-11 19:48 ` Michael Grzeschik
2022-10-11 19:53 ` Greg Kroah-Hartman
2022-10-11 20:16 ` Dan Vacura
3 siblings, 2 replies; 8+ messages in thread
From: Michael Grzeschik @ 2022-10-11 19:48 UTC (permalink / raw)
To: Dan Vacura
Cc: linux-usb, Daniel Scally, Thinh Nguyen, Greg Kroah-Hartman,
Jonathan Corbet, Laurent Pinchart, Felipe Balbi, Paul Elder,
linux-kernel, linux-doc
[-- Attachment #1: Type: text/plain, Size: 4976 bytes --]
Hi Dan!
Thanks for the patches.
On Tue, Oct 11, 2022 at 01:34:32PM -0500, Dan Vacura wrote:
>Hello uvc gadget developers,
>
>Please find my V2 series with added patches to disable these performance
>features at the userspace level for devices that don't work well with
>the UDC hw, i.e. dwc3 in this case. Also included are updates to
>comments for the v1 patch.
>
>Original note:
>
>I'm working on a 5.15.41 based kernel on a qcom chipset with the dwc3
>controller and I'm encountering two problems related to the recent performance
>improvement changes:
>
>https://patchwork.kernel.org/project/linux-usb/patch/20210628155311.16762-5-m.grzeschik@pengutronix.de/ and
>https://patchwork.kernel.org/project/linux-usb/patch/20210628155311.16762-6-m.grzeschik@pengutronix.de/
>
>If I revert these two changes, then I have much improved stability and a
>transmission problem I'm seeing is gone. Has there been any success from
>others on 5.15 with this uvc improvement and any recommendations for my
>current problems? Those being:
>
>1) a smmu panic, snippet here:
>
> <3>[ 718.314900][ T803] arm-smmu 15000000.apps-smmu: Unhandled arm-smmu context fault from a600000.dwc3!
> <3>[ 718.314994][ T803] arm-smmu 15000000.apps-smmu: FAR = 0x00000000efe60800
> <3>[ 718.315023][ T803] arm-smmu 15000000.apps-smmu: PAR = 0x0000000000000000
> <3>[ 718.315048][ T803] arm-smmu 15000000.apps-smmu: FSR = 0x40000402 [TF R SS ]
> <3>[ 718.315074][ T803] arm-smmu 15000000.apps-smmu: FSYNR0 = 0x5f0003
> <3>[ 718.315096][ T803] arm-smmu 15000000.apps-smmu: FSYNR1 = 0xaa02
> <3>[ 718.315117][ T803] arm-smmu 15000000.apps-smmu: context bank# = 0x1b
> <3>[ 718.315141][ T803] arm-smmu 15000000.apps-smmu: TTBR0 = 0x001b0000c2a92000
> <3>[ 718.315165][ T803] arm-smmu 15000000.apps-smmu: TTBR1 = 0x001b000000000000
> <3>[ 718.315192][ T803] arm-smmu 15000000.apps-smmu: SCTLR = 0x0a5f00e7 ACTLR = 0x00000003
> <3>[ 718.315245][ T803] arm-smmu 15000000.apps-smmu: CBAR = 0x0001f300
> <3>[ 718.315274][ T803] arm-smmu 15000000.apps-smmu: MAIR0 = 0xf404ff44 MAIR1 = 0x0000efe4
> <3>[ 718.315297][ T803] arm-smmu 15000000.apps-smmu: SID = 0x40
> <3>[ 718.315318][ T803] arm-smmu 15000000.apps-smmu: Client info: BID=0x5, PID=0xa, MID=0x2
> <3>[ 718.315377][ T803] arm-smmu 15000000.apps-smmu: soft iova-to-phys=0x0000000000000000
>
> I can reduce this panic with the proposed patch, but it still happens until I
> disable the "req->no_interrupt = 1" logic.
This actually smells very much like an race between hardware and
software, that is probably working on the same memory. I would guess
that the hardware in the non interrupt case is currently processing
queued memory, while at the same time the software stack will update
that same memory with new data.
In my opinion this should be fixed, rather then making the interrupt
load optional. Also we could discuss if an option to adjust the load
adds some extra value, but out of this issue scope you describe here.
Also, is this issue also being more likely to happen when streaming YUYV?
>2) The frame is not fully transmitted in dwc3 with sg support enabled.
>
> There seems to be a mapping limit I'm seeing where only the roughly first
> 70% of the total frame is sent. Interestingly, if I allocate a larger
> size for the buffer upfront, in uvc_queue_setup(), like sizes[0] =
> video->imagesize * 3. Then the issue rarely happens. For example, when I
> do YUYV I see green, uninitialized data, at the bottom part of the
> frame. If I do MJPG with smaller filled sizes, the transmission is fine.
>
> +-------------------------+
> | |
> | |
> | |
> | Good data |
> | |
> | |
> | |
> +-------------------------+
> |xxxxxxxxxxxxxxxxxxxxxxxxx|
> |xxxx Bad data xxxxxxxxx|
> |xxxxxxxxxxxxxxxxxxxxxxxxx|
> +-------------------------+
>
I did not stream with YUYV for some time. I will do that and try to
reproduce the issues you describe.
I also have an patch in the queue that will limit the sg support for
devices with speed > HIGH_SPEED. Because of the overhead of the limited
transfer payload of 1024*3 Bytes, it is possible that a simple memcpy
will actually be fast enough. But for that patch I still have to make
proper measurements. Btw. which USB speed are you transferring with?
Regards,
Michael
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH v2 0/3] uvc gadget performance issues
2022-10-11 19:48 ` [PATCH v2 0/3] uvc gadget performance issues Michael Grzeschik
@ 2022-10-11 19:53 ` Greg Kroah-Hartman
2022-10-11 20:16 ` Dan Vacura
1 sibling, 0 replies; 8+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-11 19:53 UTC (permalink / raw)
To: Michael Grzeschik
Cc: Dan Vacura, linux-usb, Daniel Scally, Thinh Nguyen,
Jonathan Corbet, Laurent Pinchart, Felipe Balbi, Paul Elder,
linux-kernel, linux-doc
On Tue, Oct 11, 2022 at 09:48:08PM +0200, Michael Grzeschik wrote:
> I also have an patch in the queue that will limit the sg support for
> devices with speed > HIGH_SPEED. Because of the overhead of the limited
> transfer payload of 1024*3 Bytes, it is possible that a simple memcpy
> will actually be fast enough. But for that patch I still have to make
> proper measurements. Btw. which USB speed are you transferring with?
For a payload that small, yes a memcpy is almost always faster. I think
it's only much larger sizes that actually start to help with sg.
Can you submit this change now? Odds are it will help out a lot of
systems.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2 0/3] uvc gadget performance issues
2022-10-11 19:48 ` [PATCH v2 0/3] uvc gadget performance issues Michael Grzeschik
2022-10-11 19:53 ` Greg Kroah-Hartman
@ 2022-10-11 20:16 ` Dan Vacura
1 sibling, 0 replies; 8+ messages in thread
From: Dan Vacura @ 2022-10-11 20:16 UTC (permalink / raw)
To: Michael Grzeschik
Cc: linux-usb, Daniel Scally, Thinh Nguyen, Greg Kroah-Hartman,
Jonathan Corbet, Laurent Pinchart, Felipe Balbi, Paul Elder,
linux-kernel, linux-doc
Hi Michael,
Appreciate the support!
On Tue, Oct 11, 2022 at 09:48:08PM +0200, Michael Grzeschik wrote:
> Hi Dan!
>
> Thanks for the patches.
>
> On Tue, Oct 11, 2022 at 01:34:32PM -0500, Dan Vacura wrote:
> > Hello uvc gadget developers,
> >
> > Please find my V2 series with added patches to disable these performance
> > features at the userspace level for devices that don't work well with
> > the UDC hw, i.e. dwc3 in this case. Also included are updates to
> > comments for the v1 patch.
> >
> > Original note:
> >
> > I'm working on a 5.15.41 based kernel on a qcom chipset with the dwc3
> > controller and I'm encountering two problems related to the recent performance
> > improvement changes:
> >
> > https://patchwork.kernel.org/project/linux-usb/patch/20210628155311.16762-5-m.grzeschik@pengutronix.de/ and
> > https://patchwork.kernel.org/project/linux-usb/patch/20210628155311.16762-6-m.grzeschik@pengutronix.de/
> >
> > If I revert these two changes, then I have much improved stability and a
> > transmission problem I'm seeing is gone. Has there been any success from
> > others on 5.15 with this uvc improvement and any recommendations for my
> > current problems? Those being:
> >
> > 1) a smmu panic, snippet here:
> >
> > <3>[ 718.314900][ T803] arm-smmu 15000000.apps-smmu: Unhandled arm-smmu context fault from a600000.dwc3!
> > <3>[ 718.314994][ T803] arm-smmu 15000000.apps-smmu: FAR = 0x00000000efe60800
> > <3>[ 718.315023][ T803] arm-smmu 15000000.apps-smmu: PAR = 0x0000000000000000
> > <3>[ 718.315048][ T803] arm-smmu 15000000.apps-smmu: FSR = 0x40000402 [TF R SS ]
> > <3>[ 718.315074][ T803] arm-smmu 15000000.apps-smmu: FSYNR0 = 0x5f0003
> > <3>[ 718.315096][ T803] arm-smmu 15000000.apps-smmu: FSYNR1 = 0xaa02
> > <3>[ 718.315117][ T803] arm-smmu 15000000.apps-smmu: context bank# = 0x1b
> > <3>[ 718.315141][ T803] arm-smmu 15000000.apps-smmu: TTBR0 = 0x001b0000c2a92000
> > <3>[ 718.315165][ T803] arm-smmu 15000000.apps-smmu: TTBR1 = 0x001b000000000000
> > <3>[ 718.315192][ T803] arm-smmu 15000000.apps-smmu: SCTLR = 0x0a5f00e7 ACTLR = 0x00000003
> > <3>[ 718.315245][ T803] arm-smmu 15000000.apps-smmu: CBAR = 0x0001f300
> > <3>[ 718.315274][ T803] arm-smmu 15000000.apps-smmu: MAIR0 = 0xf404ff44 MAIR1 = 0x0000efe4
> > <3>[ 718.315297][ T803] arm-smmu 15000000.apps-smmu: SID = 0x40
> > <3>[ 718.315318][ T803] arm-smmu 15000000.apps-smmu: Client info: BID=0x5, PID=0xa, MID=0x2
> > <3>[ 718.315377][ T803] arm-smmu 15000000.apps-smmu: soft iova-to-phys=0x0000000000000000
> >
> > I can reduce this panic with the proposed patch, but it still happens until I
> > disable the "req->no_interrupt = 1" logic.
>
> This actually smells very much like an race between hardware and
> software, that is probably working on the same memory. I would guess
> that the hardware in the non interrupt case is currently processing
> queued memory, while at the same time the software stack will update
> that same memory with new data.
>
> In my opinion this should be fixed, rather then making the interrupt
> load optional. Also we could discuss if an option to adjust the load
> adds some extra value, but out of this issue scope you describe here.
Yes, I agree this should be fixed and it could just be an issue with the
dwc3 driver. I'd need help on this as an understanding of what the hw is
doing is needed to timely rootcause the issue.
As for giving the option to reduce the load to userspace, I thought it'd
be helpful for others since it seems this is the only gadget driver that
uses this option and the amount that is hardcoded may be desired to be
adjusted, like in my case to always interrupt. Although, if the bug
didn't exist, I'd be fine with the existing hardcode.
As for reproducing, did you try this with the sg functionality disabled?
The crash seems to occur sooner in that setup.
>
> Also, is this issue also being more likely to happen when streaming YUYV?
>
> > 2) The frame is not fully transmitted in dwc3 with sg support enabled.
> >
> > There seems to be a mapping limit I'm seeing where only the roughly first
> > 70% of the total frame is sent. Interestingly, if I allocate a larger
> > size for the buffer upfront, in uvc_queue_setup(), like sizes[0] =
> > video->imagesize * 3. Then the issue rarely happens. For example, when I
> > do YUYV I see green, uninitialized data, at the bottom part of the
> > frame. If I do MJPG with smaller filled sizes, the transmission is fine.
> >
> > +-------------------------+
> > | |
> > | |
> > | |
> > | Good data |
> > | |
> > | |
> > | |
> > +-------------------------+
> > |xxxxxxxxxxxxxxxxxxxxxxxxx|
> > |xxxx Bad data xxxxxxxxx|
> > |xxxxxxxxxxxxxxxxxxxxxxxxx|
> > +-------------------------+
> >
>
> I did not stream with YUYV for some time. I will do that and try to
> reproduce the issues you describe.
>
> I also have an patch in the queue that will limit the sg support for
> devices with speed > HIGH_SPEED. Because of the overhead of the limited
> transfer payload of 1024*3 Bytes, it is possible that a simple memcpy
> will actually be fast enough. But for that patch I still have to make
> proper measurements. Btw. which USB speed are you transferring with?
This happens with both super speed and high speed setups. Another
developer also mentioned problems with sg support and had to disable it
https://lore.kernel.org/linux-usb/0de496bf-fbc6-a2a1-a967-9a0580a7b1eb@ideasonboard.com/T/#mf06aa48ec53ed4c174601f03f397bd296f09efe5
but didn't have problems with dwc2.
>
> Regards,
> Michael
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 8+ messages in thread