[PATCH] USB issues - kbdlayouts branch

[Aleš Nesrsta]

Hi Vladimir (and, of course, possibly others...),

there is patch which (perhaps) solves some bugs I found in kbdlayouts
branch.

It includes:
0. Previously sent patch for UHCI low speed problem.
1. UHCI transfer error evaluation
2. OHCI cdata de-allocation
3. OHCI proper previous TD unchaining
4. OHCI EDs quantity
5. "Simplified" OHCI driver
6. Non-root hub "multiple reset"
7. OHCI/UHCI port reset handling

Patch is done against kbdlayouts branch version 2424.
I did not commit changes into branch repository.

Please test it on Yeelong and possible other machines, it contains
significant changes (mainly points 5,6,7).


Details about points:

ad 0.
Unfortunately, I still don't have progress with low-speed keyboard -
interrupt (bulk) transfer is not working on UHCI nor OHCI. This patch
solves control transfer only and I still don't know why.

ad 1.
More than one bit can be set in register at the end of transfer and old
evaluation of error code was wrong. Now it is better but probably still
not totally exact - but GRUB does not have so much different USB error
codes currently, so it probably makes not sense.

ad 2.
I did not find de-allocation of cdata in OHCI, so I added it into
finish_transfer.

ad 3.
I found some small mistake in OHCI TD unchaining of last (not processed)
TD which sometimes resulted in bad toggle value.

ad 4.
Increased possible number of connected devices or unplug/plug cycles for
OHCI driver - I wrote approx. two/three months ago about such expected
simple change.

ad 5.
I removed interrupt-like processing of transfers from OHCI driver. I
decided it is unnecessarily complex to implement proper handling of
donehead when "non-single thread execution" of transfer is used
(different cdata).
Only "bad OHCI" code is now in driver (in fact it is your old original
idea/algorithm with some hazards removed and little bit improved).
It should work - I tested it on my OHCI machine and it works well.

ad 6.
There was one big trouble - if I connected into PC hub with two or more
devices connected, usually none was working.
It was caused by "multiple reset" - all devices connected on hub were
reset in the same time, i.e. all devices become into default state with
address 0 - USB specification does not allow such situation, only one
device on one controller can have address 0 at the same time.
I made some relative simple workaround via special flag in controller
structure - it looks working.

ad 7.
I had problems with some devices to be evaluated - hotplugging changed
timing of device detection and evaluation process, so I tried to change
it into more proper way, according USB1.x/2.0, OHCI and UHCI
specifications.
There are three main things which are important:
a. Wait for stable power and insertion procedure completion before issue
reset - at least 100ms, I found more safe it is 250ms
b. Port reset and enable procedure and its timing (50ms reset signal and
after very small delay enable request)
c. Reset recovery delay 10ms

Point a. is little bit complicated by possible not stable "connected"
signal - this problem I detected on my older computer with worse
contacts and also on some very small (usually cheap) devices.

Point b. is relative easy on OHCI and non-root hubs, because OHCI or hub
handles reset procedure timing by itself and port is automatically
enabled after reset. But control of such procedure was not good on OHCI,
I changed it to respect automatic functions of OHCI.
On UHCI reset procedure is handled only via SW and we did not it
properly - it was reason, why some my devices were working on non-root
hub port and not on UHCI root port. I changed more things there, I was
inspired by USB specification and uhci-hub.c from Linux (but code is
different, I did not copy it). I am not sure what was more important -
if timing or bit masking... But result is - now are working all my
devices also on UHCI root port! Of course, I am not sure if it is fully
compatible...

Point c. is easy and it was included in portstatus before.

The last thing is - I deleted disabling of port before resetting and
enabling it - USB specification does not say it is necessary. But if
there is really some reason to use it, why not - but in this case maybe
some delay should be inserted between disable and enable, I not tested
it yet.

Regards
Ales

usb_patch_USB_issues_100912_0
Description: Text Data