From: Bjorn Helgaas <helgaas@kernel.org>
To: Mario Limonciello <mario.limonciello@amd.com>
Cc: "Natikar, Basavaraj" <Basavaraj.Natikar@amd.com>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"thomas@glanzmann.de" <thomas@glanzmann.de>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: [PATCH] PCI: Add quirk to clear MSI-X
Date: Tue, 21 Mar 2023 06:07:47 -0500 [thread overview]
Message-ID: <20230321110747.GA2368837@bhelgaas> (raw)
In-Reply-To: <7bb0b977-be26-bf28-7bf1-b4e1b83f33c7@amd.com>
On Mon, Mar 20, 2023 at 05:52:58PM -0500, Mario Limonciello wrote:
> > If Linux *could* do this one-time initialization, and subsequent
> > D0/D3hot transitions worked per spec, that would be awesome
> > because we wouldn't have to worry about making sure we run the
> > quirk at every possible transition.
>
> It can be changed again at runtime.
>
> That's exactly what we did in amdgpu for the case that the user
> didn't disable integrated GPU.
>
> We did the init for the IP block during amdgpu's HW init phase.
>
> I see 3 ways to address this:
>
> 1) As submitted or similar (on every D state transition work around
> the issue).
>
> 2) Mimic the Windows behavior in Linux by disabling MSI-X during D3
> entry and re-enabling on D0.
>
> 3) Look for a way to get to and program that register outside of
> amdgpu.
>
> There are merits to all those approaches, what do you think?
Without knowing anything about the difficulty of 3), that seems the
most attractive to me because we never have to worry about catching
every D state transition.
Bjorn
next prev parent reply other threads:[~2023-03-21 11:07 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-06 7:23 [PATCH] PCI: Add quirk to clear MSI-X Basavaraj Natikar
2023-03-06 8:14 ` Thomas Glanzmann
2023-03-08 22:44 ` Bjorn Helgaas
2023-03-08 23:04 ` Limonciello, Mario
2023-03-09 7:34 ` Basavaraj Natikar
2023-03-09 18:25 ` Bjorn Helgaas
2023-03-09 18:32 ` Limonciello, Mario
2023-03-09 22:30 ` Bjorn Helgaas
2023-03-10 0:57 ` Mario Limonciello
2023-03-10 7:41 ` Basavaraj Natikar
2023-03-10 22:13 ` Bjorn Helgaas
2023-03-20 1:32 ` Limonciello, Mario
2023-03-20 17:14 ` Bjorn Helgaas
2023-03-20 17:20 ` Limonciello, Mario
2023-03-20 19:36 ` Bjorn Helgaas
2023-03-20 19:47 ` Limonciello, Mario
2023-03-20 21:30 ` Bjorn Helgaas
2023-03-20 21:37 ` Limonciello, Mario
2023-03-20 22:08 ` Bjorn Helgaas
2023-03-20 22:52 ` Mario Limonciello
2023-03-21 11:07 ` Bjorn Helgaas [this message]
2023-03-28 13:15 ` Basavaraj Natikar
2023-03-28 13:25 ` Limonciello, Mario
2023-03-28 17:42 ` Bjorn Helgaas
2023-03-10 7:22 ` Basavaraj Natikar
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=20230321110747.GA2368837@bhelgaas \
--to=helgaas@kernel.org \
--cc=Basavaraj.Natikar@amd.com \
--cc=bhelgaas@google.com \
--cc=linux-pci@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=rjw@rjwysocki.net \
--cc=thomas@glanzmann.de \
/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).