From: Dan Williams <dan.j.williams@intel.com>
To: "Brown, Len" <len.brown@intel.com>
Cc: "linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Pavel Machek <pavel@ucw.cz>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH v2] PM: CXL: Disable suspend
Date: Tue, 5 Apr 2022 13:22:42 -0700 [thread overview]
Message-ID: <CAPcyv4h=A4UKzjzQ5DAQFD66KnAU4F9MZRu6kGAgi6U3nX1hfQ@mail.gmail.com> (raw)
In-Reply-To: <SJ0PR11MB48956875FB15F900B5CF130BE0E49@SJ0PR11MB4895.namprd11.prod.outlook.com>
On Tue, Apr 5, 2022 at 1:05 PM Brown, Len <len.brown@intel.com> wrote:
>
> Is it possible for ACPI to be aware that CXL on that system doesn't support S3, and for ACPI to thus simply not export S3?
The ACPI domain has a chance to be aware of CXL devices attached at
boot and were configured into the System Memory Map.
However, there may be caveats that limit device visibility like
platform firmware only scans CXL devices directly attached to root
ports, not behind switches.
It would be welcome if there was an ACPI data structure to indicate
"device-X is in scope for S3" which would mean that it has aux power
and all HDM decoders (the registers that enable access to CXL memory)
are restored by the BIOS before OS resume begins.
Absent that the OS can only assume that the BIOS has no knowledge of
any HDM configurations that were defined at run time by the OS, like
after hotplug, or configurations that the OS rewrote by triggering a
secondary bus reset to unlock what the BIOS had locked and put into
the EFI memory map.
next prev parent reply other threads:[~2022-04-05 21:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-03 0:58 [PATCH] cxl/mem: Disable suspend Dan Williams
2022-04-04 15:59 ` Rafael J. Wysocki
2022-04-04 18:16 ` Dan Williams
2022-04-04 18:24 ` Rafael J. Wysocki
2022-04-05 20:00 ` [PATCH v2] PM: CXL: " Dan Williams
2022-04-05 20:05 ` Brown, Len
2022-04-05 20:22 ` Dan Williams [this message]
2022-04-12 16:59 ` Rafael J. Wysocki
2022-04-12 23:27 ` Dan Williams
2022-04-13 2:22 ` [PATCH v3] " Dan Williams
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='CAPcyv4h=A4UKzjzQ5DAQFD66KnAU4F9MZRu6kGAgi6U3nX1hfQ@mail.gmail.com' \
--to=dan.j.williams@intel.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rafael@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;
as well as URLs for NNTP newsgroup(s).