Re: high irqs-off latency caused by USB serial driver

Actually, I just found this commit: 94dfd7edf USB: HCD: support giveback of URB in tasklet context It won't fix the problem entirely, but I think it should cut the worst-case irqs-disabled latency about in half, which would be a good improvement. Does anybody know why HCD_BH is not enabled in

Re: high irqs-off latency caused by USB serial driver

On Tue, Aug 22, 2017 at 3:40 PM, Greg KH <gre...@linuxfoundation.org> wrote: > On Tue, Aug 22, 2017 at 02:44:20PM -0600, David Mosberger wrote: >> > There was an option a while ago to turn USB irqs >> > into threaded irqs, do those work on your platform? If so, that m

Re: high irqs-off latency caused by USB serial driver

On Tue, Aug 22, 2017 at 3:40 PM, Greg KH <gre...@linuxfoundation.org> wrote: > On Tue, Aug 22, 2017 at 02:44:20PM -0600, David Mosberger wrote: >> Greg, >> >> On Tue, Aug 22, 2017 at 2:25 PM, Greg KH <gre...@linuxfoundation.org> wrote: >> >> > USB

Re: high irqs-off latency caused by USB serial driver

Greg, On Tue, Aug 22, 2017 at 2:25 PM, Greg KH wrote: > USB has always been a big problem with this, the IRQ patch is very long, > and messy and complex. Yeah. > There was an option a while ago to turn USB irqs > into threaded irqs, do those work on your platform?

high irqs-off latency caused by USB serial driver

Has anyone here looked into reducing the amount of time the USB serial driver disables interrupts? On an ARM system, I'm seeing about 746 us of latency for handling a USB interrupt, which seems rather excessive. I attached a trace captured with the irqsoff tracer. Note: the 500MHz ARM cycle

[PATCH 2/2] drivers: usb: core: Minimize irq disabling in usb_sg_cancel()

From: David Mosberger <dav...@egauge.net> Restructure usb_sg_cancel() so we don't have to disable interrupts while cancelling the URBs. Suggested-by: Alan Stern <st...@rowland.harvard.edu> Signed-off-by: David Mosberger <dav...@egauge.net> --- drivers/usb/c

[PATCH 1/2] drivers: usb: core: Don't disable irqs in usb_sg_wait() during URB submit.

From: David Mosberger <dav...@egauge.net> usb_submit_urb() may take quite long to execute. For example, a single sg list may have 30 or more entries, possibly leading to that many calls to DMA-map pages. This can cause interrupt latency of several hundred micro-seconds. Avoid the p

Re: [PATCH] drivers: usb: core: Don't disable irqs in usb_sg_wait() during URB submit.

Alan, Thanks for your feedback! > This should now be GFP_NOIO. OK, I updated the patch to fix that. Good catch. > Strictly speaking, this loop should run backward. Then the > spin_unlock() could be replaced with spin_unlock_irqrestore(). Good idea. A separate patch for this is included.

high interrupt latency due to usb_sg_wait()

[Second transmission; hopefully this one will go through...] Alan, How about the attached patch? Works for me but definitely needs more review and testing. --david -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org

[PATCH] drivers: usb: core: Don't disable irqs in usb_sg_wait() during URB submit.

From: David Mosberger <dav...@egauge.net> usb_submit_urb() may take quite long to execute. For example, a single sg list may have 30 or more entries, possibly leading to that many calls to DMA-map pages. This can cause interrupt latency of several hundred micro-seconds. Avoid the p

high interrupt latency due to usb_sg_wait()

We are seeing relatively high interrupt latencies due to usb_sg_wait() calling usb_submit_urb() with interrupts disabled (as a result of its spin_lock_irq() call). As far as I can see, io->lock protects io->status and it's not really necessary to hold the lock (or disable interrupts) during the

Re: [PATCH] usb: host: max3421-hcd: use time_after()

Acked-by: David Mosberger dav...@egauge.net On Mon, Dec 15, 2014 at 8:22 AM, Asaf Vertz asaf.ve...@tandemg.com wrote: To be future-proof and for better readability the time comparisons are modified to use time_after() instead of plain, error-prone math. Signed-off-by: Asaf Vertz asaf.ve

[PATCH] usb: host: max3421-hcd: Use atomic bitops in lieu of bit fields

From: David Mosberger-Tang dav...@egauge.net Bit fields are not MP-safe. Signed-off-by: David Mosberger dav...@egauge.net --- drivers/usb/host/max3421-hcd.c | 45 ++-- 1 file changed, 20 insertions(+), 25 deletions(-) diff --git a/drivers/usb/host/max3421

[PATCH] usb: host: max3421-hcd: Fix max3421_reset_port() to set USB_PORT_STAT_RESET

From: David Mosberger-Tang dav...@egauge.net Signed-off-by: David Mosberger dav...@egauge.net --- drivers/usb/host/max3421-hcd.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c index f8ecd7d..6dbf1e9 100644 --- a/drivers/usb

Re: [PATCH] usb: host: max3421-hcd: unconditionally use GFP_ATOMIC in max3421_urb_enqueue()

-by: Alexey Khoroshilov khoroshi...@ispras.ru Acked-by: David Mosberger dav...@egauge.net --- drivers/usb/host/max3421-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c index 858efcfda50b..ed22424dbec7 100644

[PATCH] usb: host: max3421-hcd: Fix max3421_reset_port() to set USB_PORT_STAT_RESET

From: David Mosberger-Tang dav...@egauge.net Signed-off-by: Davidm Mosberger dav...@egauge.net --- drivers/usb/host/max3421-hcd.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c index f8ecd7d..6dbf1e9 100644 --- a/drivers/usb

[PATCH] usb: host: max3421-hcd: Use atomic bitops in lieu of bit fields

From: David Mosberger-Tang dav...@egauge.net Bit fields are not MP-safe. Signed-off-by: Davidm Mosberger dav...@egauge.net --- drivers/usb/host/max3421-hcd.c | 45 ++-- 1 file changed, 20 insertions(+), 25 deletions(-) diff --git a/drivers/usb/host/max3421

Re: [PATCH 1/1] usb: host: max3421-hcd: Use module_spi_driver

On Thu, May 29, 2014 at 5:51 AM, Sachin Kamat sachin.ka...@linaro.org wrote: module_spi_driver simplifies the code by eliminating boilerplate code. Nice! Acked-by: David Mosberger dav...@egauge.net Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/usb/host/max3421-hcd.c

[PATCH] usb: host: max3421-hcd: Allow platform-data to specify Vbus polarity

From: David Mosberger-Tang dav...@egauge.net Signed-off-by: Davidm Mosberger dav...@egauge.net --- drivers/usb/host/max3421-hcd.c| 6 -- include/linux/platform_data/max3421-hcd.h | 1 + 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/max3421-hcd.c

[PATCH] usb: host: max3421-hcd: Fix potential NULL urb dereference

From: David Mosberger-Tang dav...@egauge.net Reported-by: Dan Carpenter dan.carpen...@oracle.com Signed-off-by: David Mosberger dav...@egauge.net --- drivers/usb/host/max3421-hcd.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/max3421-hcd.c b/drivers

[PATCH] usb: host: max3421-hcd: Fix missing unlock in max3421_urb_enqueue()

From: David Mosberger-Tang dav...@egauge.net Reported-by: Dan Carpenter dan.carpen...@oracle.com Signed-off-by: David Mosberger dav...@egauge.net --- drivers/usb/host/max3421-hcd.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/max3421-hcd.c b/drivers

[PATCH] usb: host: max3421-hcd: fix spi_rd8 uses dynamic stack allocation warning

From: David Mosberger-Tang dav...@egauge.net kmalloc the SPI rx and tx data buffers. This appears to be the only portable way to guarantee that the buffers are DMA-safe (e.g., in separate DMA cache-lines). This patch makes the spi_rdX()/spi_wrX() non-reentrant, but that's OK because calls

[PATCH v5 0/1] Add support for using a MAX3421E chip as a host driver.

correctly identify the transfer-direction for control pipes, where the direction is determined based on the contents of the control-packet. David Mosberger (1): Add support for using a MAX3421E chip as a host driver. drivers/usb/Makefile |1 + drivers/usb/host/Kconfig

[PATCH v5 1/1] Add support for using a MAX3421E chip as a host driver.

Signed-off-by: David Mosberger dav...@egauge.net --- drivers/usb/Makefile |1 + drivers/usb/host/Kconfig | 11 + drivers/usb/host/Makefile |1 + drivers/usb/host/max3421-hcd.c| 1937 + include

Re: [PATCH v4] Add support for using a MAX3421E chip as a host driver.

Greg, Thanks for taking a look. Yes, I'll definitely fix those oversights and send a new patch next week. Have a good weekend, --david On Thu, Apr 24, 2014 at 2:09 PM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Apr 11, 2014 at 11:55:51PM -0600, David Mosberger wrote: This is v4

[PATCH v4] Add support for using a MAX3421E chip as a host driver.

, respectively, since that more accurately reflects their function (whether or not a FIFO is being written depends on the register number). Signed-off-by: David Mosberger dav...@egauge.net --- drivers/usb/Makefile |1 + drivers/usb/host/Kconfig

[PATCH v3] usb: host: Add HCD for MAX3421E chip.

Final version of the driver. This includes support for low-speed devices connected via full-speed hubs. I believe this patch incorporates all the concrete suggestions that have been made on the mailing list. Signed-off-by: David Mosberger dav...@egauge.net --- drivers/usb/Makefile

[RFC] mtd: nand: Preparatory patch for adding on-die ECC controller support. This patch adds NAND_ECC_HW_ON_DIE and all other changes to generic code.

that I forgot about previously. Signed-off-by: David Mosberger dav...@egauge.net --- drivers/mtd/nand/nand_base.c | 36 +--- drivers/of/of_mtd.c |1 + include/linux/mtd/nand.h |7 +++ 3 files changed, 41 insertions(+), 3 deletions(-) diff

Re: [PATCH] usb: host: Add MAX3421E HCD support.

Felipe, On Mon, Mar 24, 2014 at 7:31 AM, Felipe Balbi ba...@ti.com wrote: Why do you need to run your IRQ handler when an URQ gets enqueued ? That doesn't make much sense :-s Please see the comments at the start of the file: spi_sync() is blocking and must not be called while holding

Re: [PATCH] usb: host: Add MAX3421E HCD support.

On Mon, Mar 24, 2014 at 1:35 PM, Felipe Balbi ba...@ti.com wrote: looking at the driver, there's still quite a bit of duplication between his kthread implementation and what threaded IRQs would give for free... Well, let's count: hard irq handler: static irqreturn_t max3421_irq_handler(int

[PATCH] usb: host: Add MAX3421E HCD support.

@@ +/* + * MAX3421 Host Controller driver for USB. + * + * Maintainer: David Mosberger-Tang dav...@egauge.net + * + * (C) Copyright 2014 David Mosberger-Tang dav...@egauge.net + * + * MAX3421 is a chip implementing a USB 2.0 Full-/Low-Speed host + * controller on a SPI bus. + * + * Based on: + * o

Re: [PATCH] usb: host: Add MAX3421E HCD support.

Felipe, Thanks for your feedback, I'll take that into consideration. On Fri, Mar 21, 2014 at 9:44 PM, Felipe Balbi ba...@ti.com wrote: + max3421_hcd-spi_thread = kthread_run(max3421_spi_thread, hcd, + max3421_spi_thread); why do you need this

[PATCH] usb: host: Add HCD for MAX3421E chip. (rev2)

This revision incorporates virtually all of Felipe's feedback. David Mosberger (1): usb: host: Add HCD for MAX3421E chip. drivers/usb/Makefile |1 + drivers/usb/host/Kconfig | 11 + drivers/usb/host/Makefile |1 + drivers/usb/host/max3421-hcd.c | 1857

Re: MAX3421E: device giving NAKs forever?

Alan, On Fri, Mar 14, 2014 at 8:02 AM, Alan Stern st...@rowland.harvard.edu wrote: On Thu, 13 Mar 2014, David Mosberger wrote: To answer my own question: it appears that USB peripherals return NAKs not only when the peripheral is not ready to accept the data, but also when the peripheral

Re: MAX3421E: device giving NAKs forever?

Alan, On Fri, Mar 14, 2014 at 9:34 AM, Alan Stern st...@rowland.harvard.edu wrote: Now, I'm not saying what the device did was correct. According to section 6.6.1 of the Bulk-Only Transport Mass Storage spec, when the device expects a CBW packet but gets something else, it is supposed to

Re: MAX3421E: device giving NAKs forever?

write to the SNDBC register to switch back to the original FIFO. I know I tried that at one point and it didn't fix the issue, but I should try this again as it seems the most plausible explanation. --david On Thu, Mar 13, 2014 at 10:46 AM, David Mosberger dav...@egauge.net wrote: OK, I finally

Re: MAX3421E: device giving NAKs forever?

OK, I was able to confirm this: switching the FIFO back through a dummy write after a NAK/error-response fixes the problem I was seeing, so it truly was a driver-bug, not a chip bug. My apologies to Maxim! ;-) --david -- To unsubscribe from this list: send the line unsubscribe linux-usb in the

Re: MAX3421E: device giving NAKs forever?

Yeah, sorry, the READ_10s were a total red herring. They're there because I forgot to specify bs=1024. ;-( I'll try to capture better traces today and if they look interesting, make them available. --david -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.976 -- To

Re: MAX3421E: device giving NAKs forever?

it to email. --david On Thu, Mar 13, 2014 at 8:55 AM, David Mosberger dav...@egauge.net wrote: Yeah, sorry, the READ_10s were a total red herring. They're there because I forgot to specify bs=1024. ;-( I'll try to capture better traces today and if they look interesting, make them available

Re: MAX3421E: device giving NAKs forever?

Alan, On Thu, Mar 13, 2014 at 11:12 AM, Alan Stern st...@rowland.harvard.edu wrote: Okay. Maybe this would have been easier to see if you had been writing actual data instead of just a lot of zeros; the errors would have shown up when you checked the received data (incorrect checksum or

Re: MAX3421E: device giving NAKs forever?

... ;-). --david On Fri, Mar 7, 2014 at 6:16 PM, David Mosberger dav...@egauge.net wrote: So the MAX3421E driver is working quite well but one problem I'm seeing is that after running devices for a while, they seem to get into a mode where a bulk out transfer gets stuck soliciting and endless stream

Re: MAX3421E: device giving NAKs forever?

On Wed, Mar 12, 2014 at 6:21 AM, Peter Stuge pe...@stuge.se wrote: David Mosberger wrote: I couldn't figure out how to force UHCI onto an EHCI chip I suggested removing the ehci_hcd driver. Did that work? Nope. UHCI was loaded but it didn't recognize any UHCI-compatible chips so I was left

Re: MAX3421E: device giving NAKs forever?

transactions that get NAK'd? I'll obviously investigate some more, but that's the first obvious difference I have noticed. --david On Tue, Mar 11, 2014 at 7:10 PM, David Mosberger dav...@egauge.net wrote: I couldn't figure out how to force UHCI onto an EHCI chip but I did find I had some old

Re: MAX3421E: device giving NAKs forever?

On Wed, Mar 12, 2014 at 2:53 PM, Alan Stern st...@rowland.harvard.edu wrote: On Wed, 12 Mar 2014, David Mosberger wrote: I see the same WRITE_10 commands of 122,880 bytes (240 sectors), but the glaring difference is that each such WRITE_10 command seems to be followed by ~ 27 READ_10 commands

Re: MAX3421E: device giving NAKs forever?

...@aculab.com wrote: From: Felipe Balbi On Mon, Mar 10, 2014 at 02:15:36PM -0600, David Mosberger wrote: I was thinking of the Salea Logic http://www.saleae.com/logic ($150). Are you aware of any limitations for this one that would get in the way? for full-speed USB it should work, I guess

Re: MAX3421E: device giving NAKs forever?

On Tue, Mar 11, 2014 at 12:43 PM, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 11 Mar 2014, David Mosberger wrote: So I hooked up a Seleae Logic and I still can't find anything obvious that's wrong. I attached the decoded USB trace for the last WRITE10 request that's ends up

Re: MAX3421E: device giving NAKs forever?

, 339 kB/s No infinite NAK issue. Still scratching my head... --david On Tue, Mar 11, 2014 at 1:00 PM, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 11 Mar 2014, David Mosberger wrote: It looks like the host controller is behaving correctly, which means the fault is in the device

Re: MAX3421E: device giving NAKs forever?

: On Fri, 7 Mar 2014, David Mosberger wrote: Felipe, Thanks for the tip about usbmon --- that looks interesting. Of course, as luck would have it, turning on usbmon changes behavior: dd'ing to a mass-storage device (/dev/sda1) used to fail after ~500KiB. With usbmon, it fails only after about 2MiB

MAX3421E: device giving NAKs forever?

So the MAX3421E driver is working quite well but one problem I'm seeing is that after running devices for a while, they seem to get into a mode where a bulk out transfer gets stuck soliciting and endless stream of NAKs. The MAX3421E retries NAK'd transfers in the next frame again, only to get the

Re: MAX3421E Linux driver?

On Mon, Mar 3, 2014 at 2:40 PM, Daniel Mack dan...@zonque.org wrote: 1. Your patch has a large number of style issues, which scripts/checkpatch.pl will tell you more about. Sure, Im not really at a point of worrying about style, but that's easy enough to change. 2. Is there any good reason

Re: MAX3421E Linux driver?

On Sun, Mar 2, 2014 at 10:04 AM, Peter Stuge pe...@stuge.se wrote: David Mosberger wrote: +++ b/drivers/usb/host/Kconfig @@ -4,6 +4,16 @@ comment USB Host Controller Drivers depends on USB +config USB_MAX3421_HCD + tristate MAX3421 HCD (USB-over-SPI) support

Re: MAX3421E Linux driver?

, 2014 at 05:34:59PM -0700, David Mosberger wrote: We have a need to graft a USB Host controller onto a SPI bus (never mind the wisdom of doing that, we have little choice in this particular instance). The Cypress CY7C67300 would fit the bill and has a Linux driver, but is probably too complex

MAX3421E Linux driver?

We have a need to graft a USB Host controller onto a SPI bus (never mind the wisdom of doing that, we have little choice in this particular instance). The Cypress CY7C67300 would fit the bill and has a Linux driver, but is probably too complex and definitely too expensive for our needs. The

Re: MAX3421E Linux driver?

Peter, On Thu, Jan 30, 2014 at 6:09 PM, Peter Stuge pe...@stuge.se wrote: David Mosberger wrote: The Maxim MAX3421E is the other option, but it has no Linux driver. You could look at http://arduino.cc/en/Main/ArduinoBoardADK for a reference that might even work. We are aware of Arduino

Re: MAX3421E Linux driver?

Great find, I'm impressed! Yeah, probably not much hope of contacting the author (it's from 2008), but it sounds like the basics were pretty straight-forward. Good to know. --david On Thu, Jan 30, 2014 at 6:54 PM, si...@mungewell.org wrote: We have a need to graft a USB Host controller