Re: [PATCH] USB issues - kbdlayouts branch

[Aleš Nesrsta]

Hi,

today I discovered some small problem related to my last patch described
in e-mail below, point 7. The problem is:

The first (and only first) connection of USB device to root hub port is
not properly recognized or handled, any other subsequent connection is
OK.
It looks like it is the same on OHCI and UHCI, so maybe it is related to
common part (usbhub.c) or device initialization.
I am now investigating what is wrong...

Regards
Ales

Aleš Nesrsta wrote:
> 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
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel