[coreboot] USB EHCI power management

[Zoran Stojsavljevic]

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

Konstantin, there are out there UBS specs, but there are implementation
limiting factors. I did NOT ask you about BIOS randomly, since both root
EHCI and xHCI USB hubs are implemented in Lynx Point HW. And... With the
INTEL/AMI/Phoenix BIOSes HSW wise, it is obvious that ONLY one of a kind
(either EHCI, either xHCI) can work, home alone.

Mixture is NOT allowed. BIOS fixes/hides fatal USB HW bug in Lynx Point,
which has nothing to do with mentioned declarative specs.

Coreboot probably does NOT have this limitation imposed in the USB code.
Neither INTEL FSP, supporting SEC and PEI BIOS phase... My best guess! For
the record, SKL family (99.99% probability) has implemented ONLY xHCI root
hub, following xHCI USB specs (to get rid of this bug). Obvious downside,
legacy OSes requiring ONLY legacy EHCI are very hard to bring up. ;-)

Enjoy,
Zoran

On Thu, Dec 29, 2016 at 12:34 PM, Аладышев Константин <aladyshev at nicevt.ru>
wrote:

> 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/0737871c/attachment.html>