From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: "Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"Gupta, Anshuman" <anshuman.gupta@intel.com>,
"Dugast, Francois" <francois.dugast@intel.com>
Subject: Re: [PATCH 2/2] drm/xe: Ensure d3cold is only allowed in DGFX
Date: Tue, 4 Jun 2024 11:03:16 -0400 [thread overview]
Message-ID: <Zl8stGEaHUGBUVxh@intel.com> (raw)
In-Reply-To: <4305f424b0eb58a885c803a57b0303d3109178ce.camel@intel.com>
On Mon, Jun 03, 2024 at 06:15:46PM -0400, Zanoni, Paulo R wrote:
> On Mon, 2024-06-03 at 17:52 -0400, Rodrigo Vivi wrote:
> > For our integrated parts, the GPU is part of the CPU package,
> > hence removing the power at the root port is likely not possible.
> >
> > Let's add this extra layer of protection to ensure that we are
> > really not seeing d3cold atempts into integrated devices.
>
> I don't think this is the case.
>
> It's been a while since I dealt with this, but as far as I remember you
> can put integrated cards in D3 cold by writing 0x3 to PCI register
> 0xd4.
That is D3. Please notice that there's no difference on D3hot vs D3cold
on that register.
Bits 0-1: Power State (PS)
00: D0
01: D1
10: D2
11: D3
D3Cold is a special sub-case of D3hot, where the main Vcc power is off.
That doesn't happen at the device level, but only at the root port level,
after all the PCI devices under the same root port are in D3hot.
Although technically possible, I doubt that we have any integrated out
there with true D3Cold support. In general, on igfx, we are the device
0000:00:02.0 that is under the root port pci0000:00 with many other devices
directly bound to CPU. I honestly doubt that the power there can be cut.
Also, I recently noticed that even on most of our integrated parts, not
even D3hot is advertised as supported. The gain of the runtime pm on
the integrated comes more from the package-C state, then from the PCI
device power delivery channels actually.
Well, anyway, the rest of our code on d3cold_allowed are more prepared
to deal with discrete by checking local memory and other things. I don't
want to take the risk of unexpected behavior of something we were not
taking into account.
We can re-evaluate this on a next step if we see parts coming out with
this support in place, so we prepare the flow properly.
>
> https://cdrdv2.intel.com/v1/dl/getcontent/703047 page 990 (printed as
> 960). On BSpec this is page 49664.
yeap, I believe it just shows the possibility, but that would depend
of other agents and hardware changes that are outside of the graphics
domain.
>
> >
> > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > Cc: Anshuman Gupta <anshuman.gupta@intel.com>
> > Cc: Francois Dugast <francois.dugast@intel.com>
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > ---
> > drivers/gpu/drm/xe/xe_pm.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c
> > index de3b5df65e48..1facb7dd8b66 100644
> > --- a/drivers/gpu/drm/xe/xe_pm.c
> > +++ b/drivers/gpu/drm/xe/xe_pm.c
> > @@ -172,6 +172,9 @@ static bool xe_pm_pci_d3cold_capable(struct xe_device *xe)
> > struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
> > struct pci_dev *root_pdev;
> >
> > + if (!IS_DGFX(xe))
> > + return false;
> > +
> > root_pdev = pcie_find_root_port(pdev);
> > if (!root_pdev)
> > return false;
>
next prev parent reply other threads:[~2024-06-04 15:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-03 21:52 [PATCH 1/2] drm/xe: Avoid fbdev suspend at runtime pm suspend Rodrigo Vivi
2024-06-03 21:52 ` [PATCH 2/2] drm/xe: Ensure d3cold is only allowed in DGFX Rodrigo Vivi
2024-06-03 22:15 ` Zanoni, Paulo R
2024-06-04 15:03 ` Rodrigo Vivi [this message]
2024-06-04 22:46 ` ✓ CI.Patch_applied: success for series starting with [1/2] drm/xe: Avoid fbdev suspend at runtime pm suspend Patchwork
2024-06-04 22:47 ` ✓ CI.checkpatch: " Patchwork
2024-06-04 22:48 ` ✓ CI.KUnit: " Patchwork
2024-06-04 22:59 ` ✓ CI.Build: " Patchwork
2024-06-04 22:59 ` ✗ CI.Hooks: failure " Patchwork
2024-06-04 23:01 ` ✓ CI.checksparse: success " Patchwork
2024-06-04 23:29 ` ✓ CI.BAT: " Patchwork
2024-06-05 6:49 ` ✗ CI.FULL: failure " Patchwork
2024-06-07 8:59 ` [PATCH 1/2] " Francois Dugast
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=Zl8stGEaHUGBUVxh@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=anshuman.gupta@intel.com \
--cc=francois.dugast@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=paulo.r.zanoni@intel.com \
/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