[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: Wed, 28 Apr 2010 10:20:19 +0200

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:

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
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

reply via email to

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