https://bugzilla.kernel.org/show_bug.cgi?id=215742
--- Comment #28 from Daniel Drake (dr...@endlessm.com) ---
The PXP._OFF function calls DL23(), which is what writes L23E = One, which is
the condition I have not yet found a way of recovering from. Full method:
Method (DL23, 0, Serialized)
{
L23E = One
Sleep (0x10)
Local0 = Zero
While (L23E)
{
If ((Local0 > 0x04))
{
Break
}
Sleep (0x10)
Local0++
}
SCB0 = One
}
Here is the corresponding function called in the _ON path:
Method (L23D, 0, Serialized)
{
If ((SCB0 != One))
{
Return (Zero)
}
L23R = One
Local0 = Zero
While (L23R)
{
If ((Local0 > 0x04))
{
Break
}
Sleep (0x10)
Local0++
}
SCB0 = Zero
Local0 = Zero
While ((LASX == Zero))
{
If ((Local0 > 0x08))
{
Break
}
Sleep (0x10)
Local0++
}
}
I was able to find some more meaningful names for these registers, from
https://doxygen.coreboot.org/df/dc4/rtd3_8c_source.html which appears to
generate basically the same code.
#define ACPI_REG_PCI_LINK_ACTIVE "LASX" /* Link active status */
#define ACPI_REG_PCI_L23_RDY_ENTRY "L23E" /* L23_Rdy Entry Request */
#define ACPI_REG_PCI_L23_RDY_DETECT "L23R" /* L23_Rdy Detect Transition */
Also here:
https://www.mail-archive.com/devel@edk2.groups.io/msg27375.html
+ // DL23 method puts link to L2 or L3 state. Used for RTD3 flows, before
endpoint is powered down.
+ // This flow is implemented in ASL because rootport registers used for L2/L3
entry/exit
+ // are proprietary and OS drivers don't know about them.
+ //
So the intention of this code is to go into PCI power state L2/L3, which is not
something standardized, so the magic gets done in ACPI.
I experimented with this flow with setpci - nothing jumps out. When L23_Rdy
Entry Request gets written, it clears to 0 immediately after. When L23_Rdy
Detect Transition is written to 1, it also clears to 0 immediately. Link Active
Status (LASX) is also 1 at this point.
I think there's room to look at exactly what is the breakage at that point,
after going through _OFF and _ON. The PCI devices are enumerable at this point
and configuration space can be read, for both the bridge and child NVMe device.
I think nvme probe is failing at the NVME_REG_CSTS check in nvme_pci_enable().
I'll examine more closely another day.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
