All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: u-boot@lists.denx.de
Subject: [PATCH 2/4] usb: musb: Fix receiving of bigger buffers
Date: Sat, 26 Dec 2020 19:28:49 +0100	[thread overview]
Message-ID: <20201226182851.18493-3-pali@kernel.org> (raw)
In-Reply-To: <20201226182851.18493-1-pali@kernel.org>

If musb_peri_rx_ep() was called to processed received HW buffer but U-Boot
cannot read it yet (e.g. because U-Boot SW buffer is full) then interrupt
was marked as processed but HW buffer stayed unprocessed.

U-Boot tried to process this buffer again when it receive interrupt again,
but it can receive it only when sender (host) send a new data. As sender
(host) is not going to send a new data until U-Boot process current data
this issue caused a deadlock in case sender (host) is emitting data faster
than U-Boot can process it.

Reading musb intrrx register automatically clears this register and mark
interrupt as processed. So to prevent marking interrupt in U-Boot as
processed and a new variable pending_intrrx which would contain unprocessed
bits of intrrx register.

And as a second step, every time when musb_peri_rx_ep() is called and there
are waiting data to be processed (signaled by MUSB_RXCSR_RXPKTRDY) either
acknowledge sender (via musb_peri_rx_ack()) that whole HW buffer was
processed or set corresponding bit in pending_intrrx that HW buffer was not
fully processed yet and next iteration is required after U-Boot allocate
space for reading HW buffer.

This patch fixes receiving large usb buffers, e.g. file transfer via Kermit
protocol implemented by 'loadb' U-Boot command over usbtty serial console.

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 drivers/usb/musb/musb_udc.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_udc.c b/drivers/usb/musb/musb_udc.c
index 28719cc3f6..7c74422623 100644
--- a/drivers/usb/musb/musb_udc.c
+++ b/drivers/usb/musb/musb_udc.c
@@ -104,6 +104,8 @@ struct usb_endpoint_instance *ep0_endpoint;
 static struct usb_device_instance *udc_device;
 static int enabled;
 
+u16 pending_intrrx;
+
 #ifdef MUSB_DEBUG
 static void musb_db_regs(void)
 {
@@ -664,7 +666,10 @@ static void musb_peri_rx_ep(unsigned int ep)
 				/* The common musb fifo reader */
 				read_fifo(ep, length, data);
 
-				musb_peri_rx_ack(ep);
+				if (length == peri_rxcount)
+					musb_peri_rx_ack(ep);
+				else
+					pending_intrrx |= (1 << ep);
 
 				/*
 				 * urb's actual_length is updated in
@@ -677,18 +682,24 @@ static void musb_peri_rx_ep(unsigned int ep)
 					serial_printf("ERROR : %s %d no space "
 						      "in rcv buffer\n",
 						      __PRETTY_FUNCTION__, ep);
+
+				pending_intrrx |= (1 << ep);
 			}
 		} else {
 			if (debug_level > 0)
 				serial_printf("ERROR : %s %d problem with "
 					      "endpoint\n",
 					      __PRETTY_FUNCTION__, ep);
+
+			pending_intrrx |= (1 << ep);
 		}
 
 	} else {
 		if (debug_level > 0)
 			serial_printf("ERROR : %s %d with nothing to do\n",
 				      __PRETTY_FUNCTION__, ep);
+
+		musb_peri_rx_ack(ep);
 	}
 }
 
@@ -770,6 +781,9 @@ void udc_irq(void)
 			intrrx = readw(&musbr->intrrx);
 			intrtx = readw(&musbr->intrtx);
 
+			intrrx |= pending_intrrx;
+			pending_intrrx = 0;
+
 			if (intrrx)
 				musb_peri_rx(intrrx);
 
-- 
2.20.1

  parent reply	other threads:[~2020-12-26 18:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-26 18:28 [PATCH 0/4] usbtty/musb: Fix file transfers Pali Rohár
2020-12-26 18:28 ` [PATCH 1/4] serial: usbtty: Send urb data in correct order Pali Rohár
2020-12-26 18:28 ` Pali Rohár [this message]
2020-12-26 18:28 ` [PATCH 3/4] usb: musb: Fix handling interrupts for EP0 and SET ADDRESS commmand Pali Rohár
2021-01-23 15:16   ` Lukasz Majewski
2021-01-23 15:23     ` Pali Rohár
2021-01-23 21:23       ` Lukasz Majewski
2021-01-23 21:28         ` Pali Rohár
2020-12-26 18:28 ` [PATCH 4/4] usb: musb: Ensure that we set musb dynamic FIFO buffer for every endpoint Pali Rohár

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=20201226182851.18493-3-pali@kernel.org \
    --to=pali@kernel.org \
    --cc=u-boot@lists.denx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.