linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Mario Limonciello <mario.limonciello@amd.com>
Cc: Basavaraj Natikar <bnatikar@amd.com>,
	"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>
Subject: Re: [PATCH] PCI: Add quirk to clear MSI-X
Date: Fri, 10 Mar 2023 16:13:36 -0600	[thread overview]
Message-ID: <20230310221336.GA1282150@bhelgaas> (raw)
In-Reply-To: <0e1bd2cd-ea0e-7f2f-3d4a-62e9dea892b8@amd.com>

On Thu, Mar 09, 2023 at 06:57:38PM -0600, Mario Limonciello wrote:
> On 3/9/23 16:30, Bjorn Helgaas wrote:
> > On Thu, Mar 09, 2023 at 12:32:41PM -0600, Limonciello, Mario wrote:
> > > On 3/9/2023 12:25, Bjorn Helgaas wrote:
> > > ...
> > 
> > > > > > https://gitlab.freedesktop.org/agd5f/linux/-/commit/07494a25fc8881e122c242a46b5c53e0e4403139
> > > > 
> > > > That nbio_v7.2.c patch and this patch don't look anything alike.  It
> > > > looks like the nbio_v7.2.c patch might run once?  Could *this* be done
> > > > once at enumeration-time, too?
> > > 
> > > They don't look anything alike because they're attacking the problem from
> > > different angles.
> > 
> > Why do we need different angles?
> 
> The GPU driver approach only works if the GPU is enabled.  If the GPU could
> never be disabled then it alone would be sufficient.
> 
> > > The NBIO patch fixes the initialization value for the internal registers.
> > > This is what the BIOS "should" have done.  When the internal registers are
> > > configured properly then the behavior the kernel expects works as well.
> > > 
> > > The NBIO patch will run both at amdgpu startup as well as when resuming from
> > > suspend.
> > 
> > If initializing something as BIOS should have done makes the hardware
> > work correctly, isn't once enough?  Why does the NBIO patch need to
> > run at resume-time?
> 
> During suspend some internal registers are in a power domain that the state
> will be lost.  These are typically restored by the BIOS to the values
> defined in initialization tables before handing control back to the OS.

I don't quite get this.  I thought I read that if BIOS had initialized
the hardware correctly, a D0->D3hot->D0 transition would work without
any issues.  Linux can do this with PMCSR writes and BIOS isn't
involved at all.

Bjorn

  parent reply	other threads:[~2023-03-10 22:13 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 [this message]
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
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=20230310221336.GA1282150@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=Basavaraj.Natikar@amd.com \
    --cc=bhelgaas@google.com \
    --cc=bnatikar@amd.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --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).