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

[Aleš Nesrsta]

Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Problem is that if firmware didn't set this register correctly we'll
> have problems with it. Additionaly the advantage of always using the
> same values is to avoid having different behaviour on different chipsets
> which is a plus from debugging perspective.
> ...
> But I doubt it's a case for OHCI expansion card if BIOS fails to execute
> option ROM.
I agree, it will be better if FSMPS value will be set by GRUB itself because
on some platforms or add-on cards etc. it is high possibility that FSMPS 
will be
bad / not set.

> > Additionally, specification says that bit 31 (FIT) should be set to one
> > if any change of FRAME_INTERVAL occurs - but I think it is necessary
> > only if OHCI is in operational state - which is not in our case.
> It can be done. Thanks.
As I wrote, it is most probably not our case, (GRUB is setting controller
in STOP state and nobody takes care about immediate impact of such setting,
there are delays between set of FRAME_INTERVAL register and real
start of first communication transaction) so don't hurry with such 
change...:-)
(Because if you set FIT bit, you should also wait for FRT bit in register
FRAME_REMAINING to be set by OHCI controller as the reaction.
But it should happen in next start of frame, i.e. max. after 1ms.)

> > I tested your patch usb.diff from previous e-mail - it works fine.
> Thanks. When legal part will be done I'll apply it to trunk.
Mr. Donald R. Robertson wrote:
> Hello,
>
> I'm not sure what that error is. I received your request and am mailing
> your assignment form. If you are employed to do programming, then please
> have your employer fill out that disclaimer form found in the previous
> message I just sent.
So, I am awaiting the mail... Till now it is not there (after approx. one 
week.).
I expect it can be normal post delay (as it is little bit far from USA to 
us...
And, additionally, there was the problem with Eyjafjallajökull volcano...).

>   ...
> I think the real problem are channels. I have suspicion that only first
> channel of UHCI works. Another possible problem are the legacy support
> bits in EHCI controller.
It looks like good idea. I also told myself that I have to first discover 
how are
GRUB modules usb and usbms working with USB ports of USB controller,
how are they looking for connected USB mass storage device.
So I try first to more study actual related source code.

Another source of problem could be not only legacy support itself but
EHCI set up made by BIOS. If I good understood leading part of EHCI
specification, if EHCI is enabled - working, all USB 2.0 capable devices
are not "seen" on UHCI/OHCI but on EHCI only. So, if BIOS enables EHCI
to be working, none USB mass storage device will be reported on UHCI
or OHCI ports. And all USB mass storage that I have are USB 2.0
capable...
If it is in this way, I don't see any simple way how to avoid it (maybe 
except
disabling USB 2.0 support in BIOS if it is possible).
But maybe it is my misunderstanding only.

(If you will be find something sooner than me, inform me, please,
thanks in advance.)

Best regards
Ales