[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Patch] [bug #26237] multiple problems with usb devices

From: Aleš Nesrsta
Subject: Re: [Patch] [bug #26237] multiple problems with usb devices
Date: Mon, 31 May 2010 23:54:12 +0200

Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > Hello, Aleš. I've seen that your assignment was completed. I added you
> > to grub contributors. Feel free to create a branch in branches/usb.
> > Right now I'm busy but next week I should be able to assist. Perhaps
> > even this week. Right now I send uncommitted changes sitting in my
> > yeeloongfw branch. It's largely your rebased changes + few other things
> > like shutting the controller down before booting OS to avoid memory used
> > by OS to be clobbered by e.g. HCCA.

Yes, thanks, I was also sometimes thinking what happens when ohci module
is unloaded or OS booting started, but I never had time to check it, I
have little bit another priorities...

> > Branch usb should contain pci improvements + your usb changes. If you
> > have trouble with bzr or are short on time me (or perhaps someone else)
> > can give a hand.
> > This branch can go into mainline. Since mainline usb is in deplorable
> > state there is no need to pass this changes through experimental at all.
> > Merging into mainline doesn't mean that no further developpement should
> > be done on usb, just that this part is already a huge improvement.
> >
> >   
> I've created a branch "usb" where I put all the yeeloong work and
> previous version of your patch. Could you merge your latest patch into
> it and test the whole on your systems?

Ufff, I will try to do it but I am also busy probably whole this week
and maybe I will need a help with bzr, I will see... So don't expect it

> >> 2.
> >> Some devices (at least my APACER cardreader "ID 058f:6366 Alcor Micro
> >> Corp. Multi Flash Reader") are not working on UHCI. Such device does not
> >> accept any control message and UHCI returns status 0x450007 - it means
> >> STALL during sending SETUP packet.
> >> It looks to be the same problem as described by Vladimir: "I have
> >> somewhat similar issue with Geode OHCI controller right now: devices and
> >> speeds are correctly seen but trying to send a message results in a halt
> >> in first TD and error code 5.".
> >>   
> >>     
> > The problem was that the port was plainly off due to Geode reaction on
> > incorrect writes differring from that of other controllers.
> >   
> >> But I have problem on UHCI, not on OHCI - on computer with OHCI is this
> >> device working well (it is normal USB Mass Storage Bulk-Only device with
> >> SCSI subclass)! Maybe it depends on "combined controllers" UHCI-EHCI,
> >> OHCI-EHCI (?) - device is working on computer with OHCI only computer
> >> and it is not working on computer with UHCI-EHCI controller. But any
> >> other device is working well on both computers... I don't understand, I
> >> currently have no idea what can be wrong. Does anybody know...?
> >>
> >>   
> >>     
> > Does this device work under OS on this computer? Some ports are plainly
> > underpowered.

This device works fine under Linux and Windows in the same UHCI port.
But the underpower can be good idea - OSes are using EHCI, not UHCI and
there could be some difference in power handling. On UHCI I cannot find
any power handling...
And You remember to me that we are not handling overcurrent on OHCI -
but I have no idea what to do in this case.

> >   
> >> 3.
> >> There is not working USB hub support, GRUB does not see device connected
> >> via USB hub - does anybody know some details or have some specification
> >> of USB Hub class ? I cannot find it on USB site (maybe I have not
> >> sufficient patience...).
> >>
> >>
> >> I will probably focus in OHCI speed-up now, i.e. I try to do some other
> >> handling of ED to prevent changes in OHCI registers which are slowing
> >> down OHCI performance (OHCI is approx. 3 times slower than UHCI now from
> >> this reason).
> >>   
> >>     
> > How useful would the interrupts be for this matter? If the answer is
> > "very useful" I can implement them. Also we need some restructuring of
> > code of both ohci and grub in general to decrease the wait time. I think
> > specifically all the waits in init sequence. If system has 2 OHCI
> > controllers currently you need to wait twice as long as with 1
> > controllers while it's possible to init them in parallel and not wait
> > longer than in the case of one controller.

I think interrupt is not important in this case, don't hurry. Why:
Wait in initialization phase is not so critical from my point of view -
it happens only once when ohci module is loaded - for example compare it
with the time consumed by some BIOS starts...
But nothing against such improving, it can be done when interrupts will
be available.

The main problem is changing of Control or Bulk Head registers on begin
and end of each transfer because for each transfer we have another
allocated memory for ED and after transfer we de-allocate it. It was one
of thing which little bit surprised me when I first read OHCI
specification and then I saw GRUB source code - it is different than
ED/TD handling suggested in OHCI specification.
Registry change and ED de-allocation have to be done on really disabled
and inactive ED - and such situation is only after SOF (when related
list is disabled before, of course).
Such waiting can be avoided if EDs memory will not change - we can
allocate necessary EDs only once when device is detected and
enumerated / configured and do all necessary work only with TDs - in
this case, if we will not change ED addresses, it is not necessary to do
changes in OHCI registers on each transfer (with exception of "list
filled" bit setting but it can be done asynchronously without waiting
for SOF in this case) and all should be more faster, I hope as on UHCI.
Also TDs have to be handled in little bit different way in this case
because each ED must point to one valid memory address of TD structure
even if there is no transfer and queue is empty - and this empty TD have
to be used as "starting" (first) TD of next transfer - in fact we should
do it in the similar way as it is described in OHCI specification in HCD

Seth Goldberg wrote:
> USB devices are notoriously difficult to get right.  During development of 
> USB device support (mainly mass-storage devices), we discovered numerous 
> devices, usually super-cheap devices, that were not spec compliant or that 
> didn't implement this-or-that command, etc.  It's truly amazing that they 
> work 
> at all (they clearly only test on Windows, and that's all they care about). 
> So prepare yourself for a LOT of working trying to figure this stuff out (or 
> at least try to use Linux's implementation as a technical guide to avoid 
> rediscovering all of this horribleness.

Yes, I agree, it is never ending story... I am sometimes looking into
Linux (for example, issuing the Request Sense after each SCSI command is
idea taken from Linux source). Maybe I need to look there more often...
But Linux has little bit different "working environment" for USB device
driver than GRUB2.
Sometimes I am also looking into some USB development forums /
development mail lists - but there is lot of unsorted information and it
is not easy to find the right case and related solution there... - it is
often wasting of time.

But, from my point of view, current status is not so bad - I have 10
fairly different USB mass storage devices and all devices are working
well on OHCI and 9 of them are working well on UHCI.
GRUB2, when it is installed on HD or booting CD, is now able to boot
Linux from USB flash on my older computer without BIOS USB booting
support. That is what I needed some months ago, i.e. I am satisfied...

After all, GRUB2 is bootloader only, so probably nobody can expect full
USB functionality as in Linux/Windows... :-)

Best regards

reply via email to

[Prev in Thread] Current Thread [Next in Thread]