linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Vidya Sagar <vidyas@nvidia.com>
Cc: "Kenneth R. Crudup" <kenny@panix.com>,
	bhelgaas@google.com, lorenzo.pieralisi@arm.com,
	hkallweit1@gmail.com, wangxiongfeng2@huawei.com,
	mika.westerberg@linux.intel.com, kai.heng.feng@canonical.com,
	chris.packham@alliedtelesis.co.nz, yangyicong@hisilicon.com,
	treding@nvidia.com, jonathanh@nvidia.com, abhsahu@nvidia.com,
	sagupta@nvidia.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, kthota@nvidia.com,
	mmaddireddy@nvidia.com, sagar.tv@gmail.com,
	Ricky Wu <ricky_wu@realtek.com>, Rajat Jain <rajatja@google.com>,
	Prasad Malisetty <quic_pmaliset@quicinc.com>,
	Victor Ding <victording@google.com>
Subject: Re: [PATCH V1] PCI/ASPM: Save/restore L1SS Capability for suspend/resume
Date: Wed, 13 Apr 2022 08:26:44 -0500	[thread overview]
Message-ID: <20220413132644.GA673431@bhelgaas> (raw)
In-Reply-To: <20220412225047.GA627910@bhelgaas>

On Tue, Apr 12, 2022 at 05:50:47PM -0500, Bjorn Helgaas wrote:
> ...
> I think we should try this patch again with some changes and maybe
> some debug logging:
> 
>   - I wonder if we should integrate the LTR, L1 SS, and Link Control
>     ASPM restore instead of having them spread around through
>     pci_restore_ltr_state(), pci_restore_aspm_l1ss_state(), and
>     pci_restore_pcie_state().  Maybe a new pci_restore_aspm() that
>     would be called from pci_restore_pcie_state()?

Sorry, this was a dumb idea, please ignore it.  Maybe it would be
useful in the future sometime, but right now when we're trying to
understand the issue, the code churn would just confuse things.  I
think we need minimal changes right now (like 4257f7e008ea).

>   - For L1 PM Substates configuration, sec 5.5.4 says that both ports
>     must be configured while ASPM L1 is disabled, but I don't think we
>     currently guarantee this: we restore all the upstream component
>     state first, and we don't know the ASPM state of the downstream
>     one.  Maybe we need to:
> 
>       * When restoring upstream component,
>           + disable its ASPM
> 
>       * When restoring downstream component,
>           + disable its ASPM
> 	  + restore upstream component's LTR, L1SS
> 	  + restore downstream component's LTR, L1SS
> 	  + restore upstream component's ASPM
> 	  + restore downstream component's ASPM
> 
>       This seems pretty messy, but seems like what the spec requires.

Actually, I think it's unlikely that a downstream device would have
ASPM enabled while we're restoring state of the upstream device, since 
we're probably restoring state after a reset or coming back from
D3cold.  But we may still need to wait to enable the upstream device
ASPM until after configuring it in the downstream device.

Logging of the previous & new state of these registers might help
untangle things.

>     - Add some pci_dbg() logging of all these save/restore values to
>       help debug any issues.

  parent reply	other threads:[~2022-04-13 13:26 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-01 12:35 [PATCH V1] PCI/ASPM: Save/restore L1SS Capability for suspend/resume Vidya Sagar
2022-02-01 13:54 ` Kenneth R. Crudup
     [not found] ` <8aa96f79-402-4897-424f-64a2c6893de8@panix.com>
2022-02-01 19:03   ` Kenneth R. Crudup
2022-02-01 19:05   ` Kenneth R. Crudup
2022-02-01 19:10   ` Kenneth R. Crudup
2022-02-01 19:24   ` Vidya Sagar
2022-02-01 22:25     ` Kenneth R. Crudup
2022-02-02  4:17       ` Vidya Sagar
2022-02-04  1:18         ` Kenneth R. Crudup
2022-02-04  5:37           ` Vidya Sagar
2022-02-04 23:02         ` Bjorn Helgaas
2022-02-04 23:17           ` Kenneth R. Crudup
2022-02-05 16:44             ` Vidya Sagar
     [not found]               ` <12fe557f-7336-1970-d8f0-5a93529cf8c1@panix.com>
2022-02-05 17:32                 ` Kenneth R. Crudup
2022-02-05 17:33                 ` Kenneth R. Crudup
2022-02-07 16:33                 ` Bjorn Helgaas
2022-02-07 18:20                   ` Kenneth R. Crudup
2022-02-15 13:10                     ` Kenneth R. Crudup
2022-02-16  4:40                       ` Vidya Sagar
2022-02-16  6:00                         ` Kenneth R. Crudup
2022-02-16 13:11                           ` Vidya Sagar
2022-04-12 22:50                             ` Bjorn Helgaas
2022-04-13  0:19                               ` Kai-Heng Feng
2022-04-14 16:41                                 ` Bjorn Helgaas
2022-04-15 14:26                                   ` Kai-Heng Feng
2022-04-15 21:25                                     ` Bjorn Helgaas
2022-04-21  6:16                                       ` Kai-Heng Feng
2022-04-21 20:36                                         ` Bjorn Helgaas
2022-04-21 20:40                                         ` Kenneth R. Crudup
2022-04-21 21:11                                           ` Bjorn Helgaas
2022-04-21 21:21                                             ` Kenneth R. Crudup
2022-04-13 13:26                               ` Bjorn Helgaas [this message]
2022-11-23 21:44                               ` Matthias Kaehlcke
2022-11-23 22:01                                 ` Kenneth R. Crudup
2022-11-24  0:07                                   ` Matthias Kaehlcke
2022-02-15 13:12                     ` Kenneth R. Crudup
2022-02-04 11:23 ` Abhishek Sahu

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=20220413132644.GA673431@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=abhsahu@nvidia.com \
    --cc=bhelgaas@google.com \
    --cc=chris.packham@alliedtelesis.co.nz \
    --cc=hkallweit1@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=kai.heng.feng@canonical.com \
    --cc=kenny@panix.com \
    --cc=kthota@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=mmaddireddy@nvidia.com \
    --cc=quic_pmaliset@quicinc.com \
    --cc=rajatja@google.com \
    --cc=ricky_wu@realtek.com \
    --cc=sagar.tv@gmail.com \
    --cc=sagupta@nvidia.com \
    --cc=treding@nvidia.com \
    --cc=victording@google.com \
    --cc=vidyas@nvidia.com \
    --cc=wangxiongfeng2@huawei.com \
    --cc=yangyicong@hisilicon.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;
as well as URLs for NNTP newsgroup(s).