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

[Aleš Nesrsta]

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 have little bit another suggestion:

According to PERIODIC_START:
OHCI specification says "The value is calculated roughly as 10% off from
HcFrameInterval. A typical value will be 3E67h."
I think "typical value 3E67h" is some mistake - because it is greater
than default frame interval value (11999=2EDFh) ! - and it should be
probably 2A2Fh=2EDF*9/10.
So I suggest calculation of PERIODIC_START like this: ((frame_interval &
0x3fff) * 9) / 10.

According to FSMPS part of FRAME_INTERVAL (high part of register):
OHCI specification says this: "...FMPS is calculated by subtracting from
FrameInterval the maximum number of bit times needed for EOF processing,
then multiplying the result by 6/7..."
In example in specification is "maximum number of bit times needed for
EOF processing" set to 210 - I don't know why, probably it is related to
USB1.1 specification.
So, the FSMPS default value should be (11999-210) *6 / 7 = 10104 =2778h,
ie. it is the value in your patch - but only in case if low part of
frame interval register really contains default value 11999=2EDFh. I
think better will be to calculate it because frame interval can have
another default value.

There is also question, why actually to change FSMPS ?
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).

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.

Finally it can look like this (not optimal code :-), not tested yet):
>    grub_dprintf ("ohci", "OHCI reset\n");
>  
>    /* Restore the frame interval register.  */
> +  frame_interval = (frame_interval & 0x3fff) | (((((frame_interval & 0x3fff) 
> - 210) * 6) / 7) << 16);
>    grub_ohci_writereg32 (o, GRUB_OHCI_REG_FRAME_INTERVAL, frame_interval);
>  
> +  /* Set periodic start reg. - it is necessary only after HW reset, but it 
> is probably our case */
> +  grub_ohci_writereg32 (o, GRUB_OHCI_REG_PERIODIC_START, ((frame_interval & 
> 0x3fff) * 9) / 10);
> +
>    /* Setup the HCCA.  */
> -  grub_ohci_writereg32 (o, GRUB_OHCI_REG_HCCA, (grub_uint32_t) o->hcca);
> +  grub_ohci_writereg32 (o, GRUB_OHCI_REG_HCCA, (grub_uint32_t) o->hcca);
>    grub_dprintf ("ohci", "OHCI HCCA\n");
>  
>    /* Enable the OHCI.  */


3.
I tested your patch usb.diff from previous e-mail - it works fine.


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


Best regards
Ales