Johan,
Some of our customers are experiencing communication issues on RS485
that could be solved quite nicely by turning on termios.PARMRK. I'd
be happy to go into details, but I don't think they're necessary for
the discussion below.
The problem we encountered is that the error flagging produce
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 oh
On Tue, Aug 22, 2017 at 3:40 PM, Greg KH 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 might
>> > help you ou
On Tue, Aug 22, 2017 at 3:40 PM, Greg KH 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 wrote:
>>
>> > USB has always been a big problem with this, the IRQ patch is v
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? If so, that might
> help you
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 count
From: David Mosberger
Restructure usb_sg_cancel() so we don't have to disable interrupts
while cancelling the URBs.
Suggested-by: Alan Stern
Signed-off-by: David Mosberger
---
drivers/usb/core/message.c | 37 +
1 file changed, 17 insertions(+
From: David Mosberger
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 problem by releasing the io
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.
[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
Mo
From: David Mosberger
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 problem by releasing the io
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
us
Acked-by: David Mosberger
On Mon, Dec 15, 2014 at 8:22 AM, Asaf Vertz 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
> ---
> drivers/usb/host/ma
-off-by: Alexey Khoroshilov
Acked-by: David Mosberger
> ---
> 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
> --- a/dr
From: David Mosberger-Tang
Signed-off-by: David Mosberger
---
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/host/max3421-hcd.c
+++ b/drivers
From: David Mosberger-Tang
Bit fields are not MP-safe.
Signed-off-by: David Mosberger
---
drivers/usb/host/max3421-hcd.c | 45 ++--
1 file changed, 20 insertions(+), 25 deletions(-)
diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421
From: David Mosberger-Tang
Bit fields are not MP-safe.
Signed-off-by: Davidm Mosberger
---
drivers/usb/host/max3421-hcd.c | 45 ++--
1 file changed, 20 insertions(+), 25 deletions(-)
diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421
From: David Mosberger-Tang
Signed-off-by: Davidm Mosberger
---
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/host/max3421-hcd.c
+++ b/drivers
From: David Mosberger-Tang
Signed-off-by: Davidm Mosberger
---
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 b/drivers/usb/host/max3421-hcd.c
On Thu, May 29, 2014 at 5:51 AM, Sachin Kamat wrote:
> module_spi_driver simplifies the code by eliminating
> boilerplate code.
Nice!
Acked-by: David Mosberger
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/usb/host/max3421-hcd.c | 15 +--
> 1 file change
From: David Mosberger-Tang
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 to them are guara
From: David Mosberger-Tang
Reported-by: Dan Carpenter
Signed-off-by: David Mosberger
---
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/usb/host/max3421-hcd.c
index 28abda1..714f99f 100644
From: David Mosberger-Tang
Reported-by: Dan Carpenter
Signed-off-by: David Mosberger
---
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/usb/host/max3421-hcd.c
index dfc74d6..28abda1 100644
--- a
Signed-off-by: David Mosberger
---
drivers/usb/Makefile |1 +
drivers/usb/host/Kconfig | 11 +
drivers/usb/host/Makefile |1 +
drivers/usb/host/max3421-hcd.c| 1937 +
include/linux
lways 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/Kc
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 wrote:
> On Fri, Apr 11, 2014 at 11:55:51PM -0600, David Mosberger wrote:
>> This is v4 of the patch
,
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
---
drivers/usb/Makefile |1 +
drivers/usb/host/Kconfig | 11
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
---
drivers/usb/Makefile |1 +
drivers
mtd.c that I forgot about previously.
Signed-off-by: David Mosberger
---
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 --git a/dr
On Mon, Mar 24, 2014 at 1:35 PM, Felipe Balbi 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 irq, void *de
Felipe,
On Mon, Mar 24, 2014 at 7:31 AM, Felipe Balbi 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 spinlocks or with
i
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 |
Felipe,
Thanks for your feedback, I'll take that into consideration.
On Fri, Mar 21, 2014 at 9:44 PM, Felipe Balbi wrote:
>> + max3421_hcd->spi_thread = kthread_run(max3421_spi_thread, hcd,
>> + "max3421_spi_thread");
>
> why do you need this kthrea
host/max3421.c
@@ -0,0 +1,1990 @@
+/*
+ * MAX3421 Host Controller driver for USB.
+ *
+ * Maintainer: David Mosberger-Tang
+ *
+ * (C) Copyright 2014 David Mosberger-Tang
+ *
+ * MAX3421 is a chip implementing a USB 2.0 Full-/Low-Speed host
+ * controller on a SPI bus.
+ *
+ * Based on
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
th
ue a dummy 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 wrote:
> OK, I fina
Alan,
On Fri, Mar 14, 2014 at 9:34 AM, Alan Stern 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
> accept the packet (ACK,
Alan,
On Fri, Mar 14, 2014 at 8:02 AM, Alan Stern 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 periphe
but it wasn't to me... ;-).
--david
On Fri, Mar 7, 2014 at 6:16 PM, David Mosberger 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 solici
Alan,
On Thu, Mar 13, 2014 at 11:12 AM, Alan Stern 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 something
> like that).
Pe
's 55MiB in size, so I can't attach it to email.
--david
On Thu, Mar 13, 2014 at 8:55 AM, David Mosberger 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 bett
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 unsubsc
On Wed, Mar 12, 2014 at 2:53 PM, Alan Stern 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 co
e OUT 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 wrote:
> I couldn't figure out how to force UHCI onto an EHCI chip but I did
> fin
On Wed, Mar 12, 2014 at 6:21 AM, Peter Stuge 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
ch
MB) copied, 15.1192 s, 339 kB/s
No infinite NAK issue.
Still scratching my head...
--david
On Tue, Mar 11, 2014 at 1:00 PM, Alan Stern wrote:
> On Tue, 11 Mar 2014, David Mosberger wrote:
>
>> > It looks like the host controller is behaving correctly, which means
>> >
On Tue, Mar 11, 2014 at 12:43 PM, Alan Stern 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 t
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?
>>
>>
times, but eventually go through fine. So I think OUT re-transmissions
are fine. That drive still fails eventually with infinite NAKs, but this
one on a bulk-IN transaction.
I agree, it's time to get a bus analyzer.
--david
On Sun, Mar 9, 2014 at 9:11 AM, Alan Stern wrote:
> On Fri,
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
On Mon, Mar 3, 2014 at 2:40 PM, Daniel Mack wrote:
> 1. Your patch has a large number of style issues, which
> scripts/checkpatch.pl will tell you more about.
Sure, I"m not really at a point of worrying about style, but that's
easy enough to change.
> 2. Is there any good reason for not using t
On Sun, Mar 2, 2014 at 10:04 AM, Peter Stuge 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
>
ote:
> Hi,
>
> On Thu, Jan 30, 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 C
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, wrote:
>> We have a need to graft a USB Host controller onto a SPI bus (never
Peter,
On Thu, Jan 30, 2014 at 6:09 PM, Peter Stuge 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
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 Maxim
56 matches
Mail list logo
