From 345bf435405d58243c39d64a19a130a4a51c7fac Mon Sep 17 00:00:00 2001 From: Eric Anholt Date: Mon, 5 Feb 2018 18:53:18 +0000 Subject: [PATCH] drm/vc4: Don't wait for vblank on fkms cursor updates. We don't use the same async update path between fkms and normal kms, and the normal kms workaround ended up making us wait. This became a larger problem in rpi-4.14.y, as the USB HID update rate throttling got (accidentally?) dropped. Signed-off-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_kms.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/vc4/vc4_kms.c +++ b/drivers/gpu/drm/vc4/vc4_kms.c @@ -240,7 +240,8 @@ static int vc4_atomic_commit(struct drm_ * drm_atomic_helper_setup_commit() from auto-completing * commit->flip_done. */ - state->legacy_cursor_update = false; + if (!vc4->firmware_kms) + state->legacy_cursor_update = false; ret = drm_atomic_helper_setup_commit(state, nonblock); if (ret) return ret; 62724022e63425dd41bb2cde8'/> upstream openwrtJames
aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/bcm27xx/patches-5.4/950-0354-dwc_otg-checking-the-urb-transfer_buffer-too-early-3.patch
blob: 3bc9abde27b75906ea8baa1e4a85162f86204dde (plain) 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

From 271a9dfee2eb426ca9ec1ef51c6205de8496b803 Mon Sep 17 00:00:00 2001
From: Hui Wang <hui.wang@canonical.com>
Date: Sun, 17 Nov 2019 10:31:46 +0800
Subject: [PATCH] dwc_otg: checking the urb->transfer_buffer too early
 (#3332)

After enable the HIGHMEM and VMSPLIT_3G, the dwc_otg driver doesn't
work well on Pi2/3 boards with 1G physical ram. Users experience
the failure when copying a file of 600M size to the USB stick. And
at the same time, the dmesg shows:
usb 1-1.1.2: reset high-speed USB device number 8 using dwc_otg
sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
blk_update_request: I/O error, dev sda, sector 3024048 op 0x1:(WRITE) flags 0x4000 phys_seg 15 prio class 0

When this happens, the sg_buf sent to the driver is located in the
highmem region, the usb_sg_init() in the core/message.c will leave
transfer_buffer to NULL if the sg_buf is in highmem, but in the
dwc_otg driver, it returns -EINVAL unconditionally if transfer_buffer
is NULL.

The driver can handle the situation of buffer to be NULL, if it is in
DMA mode, it will convert an address from transfer_dma.

But if the conversion fails or it is in the PIO mode, we should check
buffer and return -EINVAL if it is NULL.

BugLink: https://bugs.launchpad.net/bugs/1852510
Signed-off-by: Hui Wang <hui.wang@canonical.com>
---
 drivers/usb/host/dwc_otg/dwc_otg_hcd_linux.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

--- a/drivers/usb/host/dwc_otg/dwc_otg_hcd_linux.c
+++ b/drivers/usb/host/dwc_otg/dwc_otg_hcd_linux.c
@@ -782,10 +782,6 @@ static int dwc_otg_urb_enqueue(struct us
 		dump_urb_info(urb, "dwc_otg_urb_enqueue");
 	}
 #endif
-
-	if (!urb->transfer_buffer && urb->transfer_buffer_length)
-		return -EINVAL;
-
 	if ((usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS)
 	    || (usb_pipetype(urb->pipe) == PIPE_INTERRUPT)) {
 		if (!dwc_otg_hcd_is_bandwidth_allocated
@@ -842,6 +838,13 @@ static int dwc_otg_urb_enqueue(struct us
 			      &urb->transfer_dma, buf);
 	}
 
+	if (!buf && urb->transfer_buffer_length) {
+		DWC_FREE(dwc_otg_urb);
+		DWC_ERROR("transfer_buffer is NULL in PIO mode or both "
+			   "transfer_buffer and transfer_dma are NULL in DMA mode\n");
+		return -EINVAL;
+	}
+
 	if (!(urb->transfer_flags & URB_NO_INTERRUPT))
 		flags |= URB_GIVEBACK_ASAP;
 	if (urb->transfer_flags & URB_ZERO_PACKET)
generated by cgit v1.2.3 (git 2.25.1) at