Hello.
On 12/04/2014 08:15 PM, Sebastian Andrzej Siewior wrote:
The TX-interrupt fires (sometimes) too early and therefore we have the
early_tx timer to check periodically if the transfer is done. Initially
I started I started with a 150us delay which seemed to work well.
You started twice? :-)
This value was reduced further, because depending on the usecase a
smaller poll interval was desired.
Instead of tunning the number further I hereby try to get rid of the
s/tunning/tuning/.
timer and instead use the TX-FIFO-empty interrupt. I've been playing
with it for a while and tried various things. Here is a small summary:
- Enable TX-empty interrupt "late"
The TX-empty interrupt would be enabled after "DMA IRQ" if the FIFO is
still full. This seems to work in generall but after removing the
s/generall/general/.
debug code the TX-empty interrupt isn't generated.
- Use one of the two interrups
In general, the TX-empty interrupt comes after the DMA-interrupt. But
I've also seen it the other way around. So it not an option.
- Use both interrupts.
This patch.
I remember using this mode and specifically adding the code to musb_host.c
to handle it; ISTR I was also testing this with my own CPPI 4.1 DMA driver.
See commit c7bbc056a. I wonder why were you not using it...
For every TX-transfer we receive two interrupts: one from the DMA side
another from USB (FIFO empty). Once we seen both interrupts we consider
the USB-transfer as completed. The "downside" is that we have two
interrupts per TX-transfer. On the other hand we don't have the timer
anymore which may lead may to multiple timer-interrupts especially on
s/lead may/lead/.
slow USB-disk media (where the device sends plenty of NAKs).
On the testing side:
- mass storage seems to play fine. The write perfomance is unchanged.
s/perfomance/performance/.
- g_zero test 12 gives sometimes "did not went well"
Testing is very welcome.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
---
drivers/usb/musb/musb_cppi41.c | 147 +++++++++++++++++------------------------
drivers/usb/musb/musb_dsps.c | 90 ++++---------------------
drivers/usb/musb/musb_dsps.h | 83 +++++++++++++++++++++++
3 files changed, 158 insertions(+), 162 deletions(-)
create mode 100644 drivers/usb/musb/musb_dsps.h
diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index f64fd964dc6d..08846d05e671 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -6,6 +6,7 @@
#include <linux/of.h>
#include "musb_core.h"
+#include "musb_dsps.h"
#define RNDIS_REG(x) (0x80 + ((x - 1) * 4))
@@ -32,6 +33,7 @@ struct cppi41_dma_channel {
u8 is_tx;
u8 is_allocated;
u8 usb_toggle;
+ unsigned done_irqs;
dma_addr_t buf_addr;
u32 total_len;
@@ -49,8 +51,6 @@ struct cppi41_dma_controller {
struct cppi41_dma_channel rx_channel[MUSB_DMA_NUM_CHANNELS];
struct cppi41_dma_channel tx_channel[MUSB_DMA_NUM_CHANNELS];
struct musb *musb;
- struct hrtimer early_tx;
- struct list_head early_tx_list;
u32 rx_mode;
u32 tx_mode;
u32 auto_req;
@@ -184,40 +184,40 @@ static void cppi41_trans_done(struct cppi41_dma_channel *cppi41_channel)
}
}
-static enum hrtimer_restart cppi41_recheck_tx_req(struct hrtimer *timer)
+static void glue_tx_fifo_empty_irq(struct musb *musb, u8 epnum, bool enable)
Aren't you enabling all EPn interrupts here? The function name looks a bit
strange.
[...]
@@ -248,60 +248,17 @@ static void cppi41_dma_callback(void *private_data)
transferred < cppi41_channel->packet_sz)
cppi41_channel->prog_len = 0;
+ if (cppi41_channel->is_tx) {
+ cppi41_channel->done_irqs--;
+ if (cppi41_channel->done_irqs)
+ goto out;
+ }
+
empty = musb_is_tx_fifo_empty(hw_ep);
if (empty) {
cppi41_trans_done(cppi41_channel);
} else {
- struct cppi41_dma_controller *controller;
- int is_hs = 0;
- /*
- * On AM335x it has been observed that the TX interrupt fires
- * too early that means the TXFIFO is not yet empty but the DMA
- * engine says that it is done with the transfer. We don't
I'd say this is a general problem with DMA mode 1...
[...]
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
