public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "David E. Box" <david.e.box@linux.intel.com>
To: Daniel Drake <drake@endlessos.org>, Bjorn Helgaas <helgaas@kernel.org>
Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	 dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
	 linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	bhelgaas@google.com,  mario.limonciello@amd.com,
	rafael@kernel.org, lenb@kernel.org,  linux-acpi@vger.kernel.org,
	linux@endlessos.org
Subject: Re: [PATCH v2 1/2] PCI: Disable D3cold on Asus B1400 PCI-NVMe bridge
Date: Thu, 08 Feb 2024 08:57:12 -0800	[thread overview]
Message-ID: <9654146ac849bb00faf2fe963d3da94ad65003b8.camel@linux.intel.com> (raw)
In-Reply-To: <CAD8Lp44-8WhPyOrd2dCWyG3rRuCqzJ-aZCH6b1r0kyhfcXJ8xg@mail.gmail.com>

On Thu, 2024-02-08 at 10:52 +0100, Daniel Drake wrote:
> On Thu, Feb 8, 2024 at 9:37 AM Daniel Drake <drake@endlessos.org> wrote:
> > > What would be the downside of skipping the DMI table and calling
> > > pci_d3cold_disable() always?  If this truly is a Root Port defect, it
> > > should affect all platforms with this device, and what's the benefit
> > > of relying on BIOS to use StorageD3Enable to avoid the defect?
> > 
> > I had more assumed that it was a platform-specific DSDT bug, in that
> > PEG0.PXP._OFF is doing something that PEG0.PXP._ON is unable to
> > recover from, and that other platforms might handle the suspend/resume
> > of this root port more correctly. Not sure if it is reasonable to
> > assume that all other platforms on the same chipset have the same bug
> > (if that's what this is).

This does look like a firmware bug. We've had reports of D3cold support missing
when running in non-VMD mode on systems that were designed with VMD for Windows.
These issues have been caught and addressed by OEMs during enabling of Linux
systems. Does D3cold work in VMD mode?

David

> 
> Just realised my main workstation (Dell XPS) has the same chipset.
> 
> The Dell ACPI table has the exact same suspect-buggy function, which
> the affected Asus system calls from PEG0.PXP._OFF:
> 
>         Method (DL23, 0, Serialized)
>         {
>             L23E = One
>             Sleep (0x10)
>             Local0 = Zero
>             While (L23E)
>             {
>                 If ((Local0 > 0x04))
>                 {
>                     Break
>                 }
> 
>                 Sleep (0x10)
>                 Local0++
>             }
> 
>             SCB0 = One
>         }
> 
> (the "L23E = One" line is the one that writes a value to config offset
> 0xe2, if you comment out this line then everything works)
> 
> However, on the Dell XPS system, nothing calls DL23() i.e. it is dead code.
> 
> Comparing side by side:
> Asus root port (PC00.PEG0) has the PXP power resource which gets
> powered down during D3cold transition as it becomes unused. Dell root
> port has no power resources (no _PR0).
> Asus NVM device sitting under that root port (PC00.PEG0.PEGP) has
> no-op _PS3 method, but Dell does not have _PS3. This means that Dell
> doesn't attempt D3cold on NVMe nor the parent root port during suspend
> (both go to D3hot only).
> 
> Let me know if you have any ideas for other useful comparative experiments.
> Daniel


  reply	other threads:[~2024-02-08 16:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-07  8:44 [PATCH v2 1/2] PCI: Disable D3cold on Asus B1400 PCI-NVMe bridge Daniel Drake
2024-02-07  8:44 ` [PATCH v2 2/2] Revert "ACPI: PM: Block ASUS B1400CEAE from suspend to idle by default" Daniel Drake
2024-02-07  9:08   ` Jian-Hong Pan
2024-02-07 10:29     ` Rafael J. Wysocki
2024-02-07 11:42       ` Jian-Hong Pan
2024-02-07  9:06 ` [PATCH v2 1/2] PCI: Disable D3cold on Asus B1400 PCI-NVMe bridge Jian-Hong Pan
2024-02-07 11:43   ` Jian-Hong Pan
2024-02-07 20:05 ` Bjorn Helgaas
2024-02-08  8:37   ` Daniel Drake
2024-02-08  9:52     ` Daniel Drake
2024-02-08 16:57       ` David E. Box [this message]
2024-02-09  8:36         ` Daniel Drake
2024-02-09 17:19           ` David E. Box
2024-02-19 11:35           ` Daniel Drake
2024-02-19 12:45             ` Mario Limonciello
2024-02-20 23:25             ` David E. Box
2024-02-19  9:52       ` Daniel Drake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9654146ac849bb00faf2fe963d3da94ad65003b8.camel@linux.intel.com \
    --to=david.e.box@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=drake@endlessos.org \
    --cc=helgaas@kernel.org \
    --cc=hpa@zytor.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@endlessos.org \
    --cc=mario.limonciello@amd.com \
    --cc=mingo@redhat.com \
    --cc=rafael@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox