Re: [PATCH 1/3] usb: rename bU2DevExitLat to wU2DevExitLat

[Hans Petter Selasky]

On 09/06/16 08:44, Felipe Balbi wrote:

Hi,

Felipe Balbi  writes:

> According to USB 3.1 Specification, that field is 2
> bytes wide and is named with a 'w' prefix, not 'b'.
>
> Just to make grepping in the spec easier, let's
> match the name.
>
> Signed-off-by: Felipe Balbi 

I'll wait for another week or so, if nobody has any objections to this
series, I plan on sending it to Greg on my pull request.


FYI: Affects Linux's libusb header files too. They have the same 
mis-spelling.


--HPS
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: xhci

[Hans Petter Selasky]

On 09/12/14 15:26, Mathias Nyman wrote:

Hi

On 09/11/2014 05:18 PM, Jay Larson wrote:

Mathias,

I was not able to locate an official method of inquiring about issues with xhci,
so I'm writing directly to you. If this is not the appropriate method please
accept my apologies and kindly direct me to the proper place.



Me, including the linux usb mailing list (added to cc), is the right 
combination to ask
questions regarding xhci.


We have had a failure for which I have been asked to provide an explanation. A
process that was accessing a USB 3.0 disk unexpectedly failed (Killed). We have
had other issues where users have had to reboot to restore USB connectivity
(possibly just reloading the module would have had the same effect). I can only
surmise that there is either a problem with the hardware, or xhci. I am in
particular curious if we could expect any significant benefits to using a more
recent kernel.



You should definitely use a more recent kernel, there are tons of changes since 
2.6.32,
and It's impossible for me to support old kernels.


[uname -a]
Linux kdmlinux3 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 12:19:21 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux

[lcpci -vv]
04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev




...


Hi,

I thought I'd drop you guys a message about the USB 3.0 NEC uPD720200 
hoping that some hardware guys are hanging around on this list.


After we added 64-bit support to the XHCI driver in FreeBSD we've had 
several identical reports, that the USB 3.0 NEC uPD720200 is refusing 
to work correctly. Timeout errors start happening exactly after the 
first data transfer to/from a DMA address above 4GBytes. Is this a known 
issue?


Until further we've added a quirk to mask away the 64-bit capability of 
the XHCI controller:

https://svnweb.freebsd.org/changeset/base/279563

We currently don't believe this is a XHCI driver problem in FreeBSD, 
hence other XHCI controllers work just fine.


--HPS

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/1] for HID core dot c

[Hans Petter Selasky]

Hi Greg,

Thank you for the pointer. Will try to remember that till next time.

Sorry about the noise!



Please use scripts/get_maintainer.pl to determine who and what mailing
lists to send a patch to so that the right maintainer(s) get the patch.



--HPS
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] for HID core dot c

[Hans Petter Selasky]

See attachment.

Thank you!

--HPS
commit 862e8673263b82652b5738ccda4f8367959fa234
Author: Hans Petter Selasky h...@selasky.org
Date:   Fri Sep 5 11:07:15 2014 +0200

Correct argument for Module parameter description.

Signed-off-by: Hans Petter Selasky h...@selasky.org

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 12b6e67..1956c72 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -52,7 +52,7 @@ EXPORT_SYMBOL_GPL(hid_debug);
 
 static int hid_ignore_special_drivers = 0;
 module_param_named(ignore_special_drivers, hid_ignore_special_drivers, int, 0600);
-MODULE_PARM_DESC(debug, Ignore any special drivers and handle all devices by generic driver);
+MODULE_PARM_DESC(ignore_special_drivers, Ignore any special drivers and handle all devices by generic driver);
 
 /*
  * Register a new report for a device.

[PATCH 0/1] for HID core dot c

[Hans Petter Selasky]

Hi,

Looks like the first argument for MODULE_PARAM_DESC() is incorrect.

--HPS

commit 862e8673263b82652b5738ccda4f8367959fa234
Author: Hans Petter Selasky h...@selasky.org
Date:   Fri Sep 5 11:07:15 2014 +0200

Correct argument for Module parameter description.

Signed-off-by: Hans Petter Selasky h...@selasky.org


diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 12b6e67..1956c72 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -52,7 +52,7 @@ EXPORT_SYMBOL_GPL(hid_debug);
 
 static int hid_ignore_special_drivers = 0;

 module_param_named(ignore_special_drivers, hid_ignore_special_drivers, int, 
0600);
-MODULE_PARM_DESC(debug, Ignore any special drivers and handle all devices by 
generic driver);
+MODULE_PARM_DESC(ignore_special_drivers, Ignore any special drivers and handle all 
devices by generic driver);
 
 /*

  * Register a new report for a device.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] for HID core dot c

[Hans Petter Selasky]

On 09/05/14 16:20, Frans Klaver wrote:

Hi,

On Fri, Sep 5, 2014 at 4:07 PM, Hans Petter Selasky h...@selasky.org wrote:

See attachment.


It's preferred that you send your patches in the body of the email.
Please read Documentation/SubmittingPatches.

Frans
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



Hi,

I'll re-send it.

Not sending patches that frequently.

Thank you!

--HPS
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Correct argument for Module parameter description.

[Hans Petter Selasky]

Signed-off-by: Hans Petter Selasky h...@selasky.org
---
 drivers/hid/hid-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 12b6e67..1956c72 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -52,7 +52,7 @@ EXPORT_SYMBOL_GPL(hid_debug);
 
 static int hid_ignore_special_drivers = 0;

 module_param_named(ignore_special_drivers, hid_ignore_special_drivers, int, 
0600);
-MODULE_PARM_DESC(debug, Ignore any special drivers and handle all devices by 
generic driver);
+MODULE_PARM_DESC(ignore_special_drivers, Ignore any special drivers and handle all 
devices by generic driver);
 
 /*

  * Register a new report for a device.
--
1.8.2.3




--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Slow boot due to USB errors

[Hans Petter Selasky]

Hi,


Hi,

echo hw.usb.no_boot_wait=0  /boot/loader.conf

--HPS



Maybe not directly related to this list, but in FreeBSD we have a 
tunable to not wait for synchronous device probing at boot.


--HPS

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: xhci and other woes

[Hans Petter Selasky]

On 02/04/14 20:10, Sarah Sharp wrote:

And there's code in the xHCI driver to ignore the second successful
event.  See ep-last_td_was_short.  Yes, this is a slight race
condition, and we should wait for the successful event.  However, we
have not seen any issues with this race condition.


Hi,

Some comments from the side-line:

I've observed some XHCI controllers sending special case events, like 
IO-errors for ISOCHRONOUS endpoints, out of order. In not sure if the 
XHCI specification is clear about this, or not, that when you have bunch 
of TD's on an endpoint, you should not receive the completion event for 
the next timeslot / TD, before receiving the IO-error for the previous 
failed TRB/TD. I'm not sure what tests HW guys are doing these days 
regarding XHCI. This has been observed during driver development of 
FreeBSD's XHCI driver a long time ago, and I though I'd mention it for 
you guys.


--HPS

FreeBSD's XHCI driver: 
http://svnweb.freebsd.org/base/head/sys/dev/usb/controller/xhci.c?view=markup


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb scheduler

[Hans Petter Selasky]

On Friday 27 July 2012 10:52:11 Alexey Filin wrote:
 USB is a good choice for some bus adapters, it is used widely, cheap,
 simple. For 2-byte read/write we could use either two bulk IN/OUT
 endpoints (131 * 8kHz ~ 1 MHz) or one control endpoint (table 5-3, 42
 * 8 kHz = 336 kHz). Ethernet is overkill for the task even if it could
 provide 1 us delay.

Hi,

If you submit one million URB's per second, you will have a significant system 
overhead? Right? Have you ever tried this application under FreeBSD 8+ ? There 
we allow so-called multi-frame transfers, that means you sort of bind 
toghether multiple jobs into a single URB submit.

For example you can submit 100 2-byte short-packet-jobs in a single submit, 
and have only one completion interrupt from the EHCI controller!

For the XHCI you can even double buffer such transfers.



This discussion gets me thinking of once i stress-tested some USB code, by 
hacking into the EHCI DMA schedule, repeating each control request 128 times 
or more. This allows for submitting more than 8000 control requests per second 
for the EHCI controller and can be useful to find timing related issues in the 
device side.


--HPS
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb scheduler

[Hans Petter Selasky]

On Friday 27 July 2012 17:12:51 Alan Stern wrote:
 On Fri, 27 Jul 2012, Hans Petter Selasky wrote:
  On Friday 27 July 2012 10:52:11 Alexey Filin wrote:
   USB is a good choice for some bus adapters, it is used widely, cheap,
   simple. For 2-byte read/write we could use either two bulk IN/OUT
   endpoints (131 * 8kHz ~ 1 MHz) or one control endpoint (table 5-3, 42
   * 8 kHz = 336 kHz). Ethernet is overkill for the task even if it could
   provide 1 us delay.
  
  Hi,
  
  If you submit one million URB's per second, you will have a significant
  system overhead? Right? Have you ever tried this application under
  FreeBSD 8+ ? There we allow so-called multi-frame transfers, that means
  you sort of bind toghether multiple jobs into a single URB submit.
  
  For example you can submit 100 2-byte short-packet-jobs in a single
  submit, and have only one completion interrupt from the EHCI controller!
  
  For the XHCI you can even double buffer such transfers.
 
 The problem is that Alexey needs to use the data returned by the
 previous transfer in order to compute the data for the next transfer.
 Therefore the transfers must be made sequentially; they cannot be done
 concurrently.

I see.

--HPS
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb scheduler

[Hans Petter Selasky]

On Thursday 26 July 2012 17:47:11 Alan Stern wrote:
* Is there a USB controller with scheduling in current microframe?
 
 They all do it.  But they won't generate completion IRQs any faster 
 than 8 KHz.

Hi,

Maybe a bit off-topic: I've noticed that if you STALL a USB transfer, this 
rule might not apply. Anyway, STALL is not considered a successful completion. 
Abusing STALL PID to get higher IRQ rates for the EHCI/XHCI is more or less a 
hack :-)

--HPS
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb scheduler

[Hans Petter Selasky]

On Thursday 26 July 2012 17:47:11 Alan Stern wrote:
 To get maximum throughput you should submit multiple URBs originally,
 and then submit a new URB whenever an URB completes.  I recommand using
 a pipeline depth of 10-20 ms.  For bulk transfers at high speed, that
 comes out to between 500 KB and 1 MB of concurrent URB data.

Some EHCI hardware will scan for new QH's and TD's when you set the EHCI 
doorbell bit. This bit is only supposed to be used when you remove QH's/TD's 
from the ASYNC schedule, but can also be abused when entering QH's/TD's into 
the schedule.

How this works for your EHCI controller, depends on the actual hardware 
implementation.

--HPS
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html