Re: [PATCH] USB issues - kbdlayouts branch

[Aleš Nesrsta]

Hi,

there is little bit modified patch, it should work better...
For details see description in original e-mail included below.

Regards
Ales

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

usb_patch_USB_issues_100913_0
Description: Text Data