[coreboot] USB EHCI power management

[Аладышев Константин]

Salut, Zoran!

 

The question isn’t specific to LynxPoint PCH. It is related to EHCI specification. Every southbridge with EHCI controller should support these registers in a right way.

 

Anyway, after months of investigation I solved this issue couple of days after I posted this letter.

 

The solution was very simple, I just needed to explicitly disable XHCI through RCBA registers:

 

                /* Disable unused devices (board specific) */

                RCBA_RMW_REG_32(FD, ~0, PCH_DISABLE_ALWAYS | PCH_DISABLE_XHCI),

 

It seems like “device pci 14.0 off end # USB3 XHCI” record in devicetree.cb is not enough. I spend so much time on this, cause USB worked perfectly without this RCBA register until S3 suspend/resume sequence.

 

For complete answer, I’ll post solutions to my questions:

1)      D3hot

2)      Yes

3)      Yes, and in resume BIOS sequence they still be suspended. But besides suspend bit all other bits in this F0-Fx register should be preserved (like current connection status)! If it isn’t so, something is wrong

4)      It should be enabled automatically already in resume BIOS sequence

 

 

 

From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic at gmail.com] 
Sent: Tuesday, December 27, 2016 7:35 PM
To: Аладышев Константин
Cc: coreboot
Subject: Re: [coreboot] USB EHCI power management

 

Privet Konstantin,

 

Ja mogu i po Russkomu (russkij keyboard ne imeet dlja menja nikakogo smisla perekljucat6, tak cto ja po Russkomu naucilsja davnim, prezde cem (paru let prezde) ZX81 i Spektrum pojavilis6, no budu ja pisat6 po Anglijskij, tak cto ljudi Coreboot-a mogut ponjat6 ob cem mi zdes6 tolkujem/hozjataistvujem. :-)

_______

 

I do not think that people here, Coreboot people, have appropriate detailed documentation for Lynx Point (Series 8 PCH), which primarily serves to HSW (CORE 4) Family. It also served (as experimental PCH) to some SKL (Core 6) families. Before Sunrise Point (Series 10, I believe) PCH came to existence. About 14+ months ago.

 

For the bigger picture, I'll suggest to you the following test scenario:

[1] You should do all of this what you have asked here with HSW (CORE 4) true BIOS, and then installing on the top of it any Linux distro (I use Fedora, I mastered it, but you can use any Linux distro of your free choice):

   [A] After bringing BIOS up, and GRUB2, then Linux... You should exercise exactly the same scenario as you described with Coreboot BSP. Then, you should take any and every possible detailed log which you can (to compare with the same scenario using Coreboot).

   [B] You should see if you have the same behavior as you describe it in your original email.

[2] You say/write heading: USB EHCI power management. What about: USB xHCI power management (there is duality there, in Lynx Point PCH, don't you know?)?

 

I hope this email helps somehow. :-)

 

Zoran

 

On Tue, Dec 27, 2016 at 10:24 AM, Аладышев Константин <aladyshev at nicevt.ru> wrote:

I have a problem with USB EHCI on board with Lynxpoint-LP southbridge.

First of all system doesn't wakeup from USB devices from S3. EHCI controller
is listed in "/proc/acpi/wakeup" as "enabled" and GPE number is seemed to be
configured correctly to PME_B0, but it doesn't work.

More troubling issue that USB stops working after wakeup (for example from
power button).

In attempt to solve this issue I started to  investigate how exactly EHCI
works in S3 suspend/resume sequence.

And I have some questions:

1) PCI_config: PWR_CNTL_STS register (54-55h)

What power state should enter EHCI controller when system enters S3?   D0
state or D3hot ?

2) MEM_BASE: USB2.0_CMD (20-23h)

Is it correct, that system disables "Run/Stop (RS)" bit when system enters
S3?

3) MEM_BASE: RMHPORTSTSN (F0h)

Is it correct, that all ports became suspended when system enters S3?

4) Who is responsible to set "Run/Stop (RS)" and bring USB ports from
suspended state? BIOS or OS?

5) Is there any board in coreboot that has USB EHCI working correctly with
S3 suspend/resume?



--
coreboot mailing list: coreboot at coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20161229/41232bfc/attachment.html>