[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: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: [Patch] [bug #26237] multiple problems with usb devices
Date: Sat, 24 Apr 2010 21:50:14 +0200
User-agent: Mozilla-Thunderbird (X11/20091109)

Aleš Nesrsta wrote:
> Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> ...
>> I discovered something. It looks like on Yeeloong the problem is caused
>> by the skipped step of initialising of timings and power management.
>> Quick and dirty fix:
> ...
> Hello,
> first of all sorry about delay - I am little bit busy now.
> 1.
> I fully agree with power enable fix (via register ...RHUBA) - it is
> simple and probably sufficiently universal.
> 2.
> The second fix, related to FRAME_INTERVAL (FSMPS part) and
> PERIODIC_START - where you get the fixed values?
I've just dumped them from a working controller.
> There is also question, why actually to change FSMPS ?
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.
> I think, if we take into frame_interval previous valid value from
> FRAME_INTERVAL register, this part should be correct.
> Maybe it is not always true - specification says that this value should
> be calculated by driver. So, if Yeeloong has no BIOS, probably nobody
> calculate and set this field and it is not set by OHCI HW itself. On
> another machines it is probably set by BIOS - at least on my machine
> with OHCI only :-) - but maybe it is done only in case if "Legacy USB
> support" is selected in BIOS (or similar USB setting).
But I doubt it's a case for OHCI expansion card if BIOS fails to execute
option ROM.
> 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.
> 3.
> 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.
> 4.
> I cannot test OHCI on my second machine as I promised - the second
> machine has no OHCI-EHCI, but UHCI-EHCI, I was wrong...
> But I tried to test UHCI on this second machine - and it was not
> working.
> I had no time to debug why it is not working - I suspect BIOS (which
> supports booting from USB) is doing something bad in background, maybe.
> I will check the BIOS settings and I will try test it once again. But
> first I have to add disk drive with Linux to this machine to be able
> make some debugging experiments with GRUB (I have only WinXP there
> currently).
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.
> Best regards
> Ales
> _______________________________________________
> Grub-devel mailing list
> address@hidden

Vladimir 'φ-coder/phcoder' Serbinenko

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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