dwc_otg: pay attention to qh->interval when rescheduling periodic queues

A regression introduced in #3887 meant that if the newly scheduled transfer immediately returned data, and the driver resubmitted a single URB after every transfer, then the effective polling interval would end up being approx 1ms. Use the larger of SCHEDULE_SLOP or the configured endpoint interval. Signed-off-by: Jonathan Bell <[email protected]>
raspberrypi · Nov 8, 2021 · e6ce680 · e6ce680
1 parent 8bf08cd
commit e6ce680
Showing 1 changed file with 1 addition and 1 deletion.
diff --git a/drivers/usb/host/dwc_otg/dwc_otg_hcd_queue.c b/drivers/usb/host/dwc_otg/dwc_otg_hcd_queue.c
@@ -691,7 +691,7 @@ int dwc_otg_hcd_qh_add(dwc_otg_hcd_t * hcd, dwc_otg_qh_t * qh)
 	} else {
 		/* If the QH wasn't in a schedule, then sched_frame is stale. */
 		qh->sched_frame = dwc_frame_num_inc(dwc_otg_hcd_get_frame_number(hcd),
-							SCHEDULE_SLOP);
+						    max_t(uint32_t, qh->interval, SCHEDULE_SLOP));
 		status = schedule_periodic(hcd, qh);
 		qh->start_split_frame = qh->sched_frame;
 		if ( !hcd->periodic_qh_count ) {