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@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@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@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot