Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Cc: amd-gfx@lists.freedesktop.org,
	sathyanarayanan.kuppuswamy@linux.intel.com,
	linux-pci@vger.kernel.org, alexander.deucher@amd.com,
	nirmodas@amd.com, Dennis.Li@amd.com, christian.koenig@amd.com,
	luben.tuikov@amd.com, bhelgaas@google.com
Subject: Re: [PATCH v4 4/8] drm/amdgpu: Fix consecutive DPC recovery failures.
Date: Wed, 2 Sep 2020 17:23:59 -0500	[thread overview]
Message-ID: <20200902222359.GA272485@bjorn-Precision-5520> (raw)
In-Reply-To: <1599072130-10043-5-git-send-email-andrey.grodzovsky@amd.com>

On Wed, Sep 02, 2020 at 02:42:06PM -0400, Andrey Grodzovsky wrote:
> Cache the PCI state on boot and before each case where we might
> loose it.

s/loose/lose/

> v2: Add pci_restore_state while caching the PCI state to avoid
> breaking PCI core logic for stuff like suspend/resume.
> 
> v3: Extract pci_restore_state from amdgpu_device_cache_pci_state
> to avoid superflous restores during GPU resets and suspend/resumes.
> 
> v4: Style fixes.

Is the DRM convention to keep the v2/v3/v4 stuff in the commit log?  I
keep those below the "---" or manually remove them for PCI, but use
the local convention, of course.

> +	/* Have stored pci confspace at hand for restore in sudden PCI error */

I assume that at least from the perspective of this code, all PCI
errors are "sudden".  Or if they're not, I'm curious about which would
be sudden and which would not.

> +	if (amdgpu_device_cache_pci_state(adev->pdev))
> +		pci_restore_state(pdev);

> +bool amdgpu_device_cache_pci_state(struct pci_dev *pdev)
> +{
> +	struct drm_device *dev = pci_get_drvdata(pdev);
> +	struct amdgpu_device *adev = drm_to_adev(dev);
> +	int r;
> +
> +	r = pci_save_state(pdev);
> +	if (!r) {
> +		kfree(adev->pci_state);
> +
> +		adev->pci_state = pci_store_saved_state(pdev);
> +
> +		if (!adev->pci_state) {
> +			DRM_ERROR("Failed to store PCI saved state");
> +			return false;
> +		}
> +	} else {
> +		DRM_WARN("Failed to save PCI state, err:%d\n", r);
> +		return false;
> +	}
> +
> +	return true;
> +}
> +
> +bool amdgpu_device_load_pci_state(struct pci_dev *pdev)
> +{
> +	struct drm_device *dev = pci_get_drvdata(pdev);
> +	struct amdgpu_device *adev = drm_to_adev(dev);
> +	int r;
> +
> +	if (!adev->pci_state)
> +		return false;
> +
> +	r = pci_load_saved_state(pdev, adev->pci_state);

I'm a little bit hesitant to pci_load_saved_state() and
pci_store_saved_state() being used here, simply because they're
currently only used by VFIO, Xen, and nvme.  So I don't have a real
objection, but just pointing out that apparently you're doing
something really special that isn't commonly used and tested, so it's
more likely to be broken or incomplete.

There's lots of state that the PCI core *can't* save/restore, and
pci_load_saved_state() doesn't even handle all the architected PCI
state, i.e., we only call pci_add_cap_save_buffer() or
pci_add_ext_cap_save_buffer() for a few of the capabilities.

  reply	other threads:[~2020-09-02 22:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-02 18:42 [PATCH v4 0/8] Implement PCI Error Recovery on Navi12 Andrey Grodzovsky
2020-09-02 18:42 ` [PATCH v4 1/8] drm/amdgpu: Avoid accessing HW when suspending SW state Andrey Grodzovsky
2020-09-02 21:56   ` Bjorn Helgaas
2020-09-03  1:32   ` Li, Dennis
2020-09-02 18:42 ` [PATCH v4 2/8] drm/amdgpu: Block all job scheduling activity during DPC recovery Andrey Grodzovsky
2020-09-02 22:07   ` Bjorn Helgaas
2020-09-02 18:42 ` [PATCH v4 3/8] drm/amdgpu: Fix SMU error failure Andrey Grodzovsky
2020-09-02 22:05   ` Bjorn Helgaas
2020-09-03 15:29     ` Andrey Grodzovsky
2020-09-02 18:42 ` [PATCH v4 4/8] drm/amdgpu: Fix consecutive DPC recovery failures Andrey Grodzovsky
2020-09-02 22:23   ` Bjorn Helgaas [this message]
2020-09-03 15:45     ` Andrey Grodzovsky
2020-09-02 18:42 ` [PATCH v4 5/8] drm/amdgpu: Trim amdgpu_pci_slot_reset by reusing code Andrey Grodzovsky
2020-09-02 18:42 ` [PATCH v4 6/8] drm/amdgpu: Disable DPC for XGMI for now Andrey Grodzovsky
2020-09-02 18:42 ` [PATCH v4 7/8] drm/amdgpu: Minor checkpatch fix Andrey Grodzovsky
2020-09-02 18:42 ` [PATCH v4 8/8] Revert "PCI/ERR: Update error status after reset_link()" Andrey Grodzovsky
2020-09-02 19:00   ` Kuppuswamy, Sathyanarayanan
2020-09-02 19:54     ` Andrey Grodzovsky
2020-09-02 20:27       ` Kuppuswamy, Sathyanarayanan
2020-09-02 21:36 ` [PATCH v4 0/8] Implement PCI Error Recovery on Navi12 Bjorn Helgaas

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=20200902222359.GA272485@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=Dennis.Li@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=andrey.grodzovsky@amd.com \
    --cc=bhelgaas@google.com \
    --cc=christian.koenig@amd.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=luben.tuikov@amd.com \
    --cc=nirmodas@amd.com \
    --cc=sathyanarayanan.kuppuswamy@linux.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