From: Bjorn Helgaas <bhelgaas@google.com>
To: "Patel, Mayurkumar" <mayurkumar.patel@intel.com>
Cc: Sinan Kaya <okaya@codeaurora.org>,
Bjorn Helgaas <helgaas@kernel.org>,
Rajat Jain <rajatja@google.com>,
Rajat Jain <rajatxjain@gmail.com>,
David Daney <david.daney@cavium.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Timur Tabi <timur@codeaurora.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Julia Lawall <Julia.Lawall@lip6.fr>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Yinghai Lu <yinghai@kernel.org>,
Shawn Lin <shawn.lin@rock-chips.com>,
linux-arm <linux-arm-kernel@lists.infradead.org>,
Myron Stowe <myron.stowe@redhat.com>
Subject: Re: [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init
Date: Tue, 25 Apr 2017 13:45:13 -0500 [thread overview]
Message-ID: <CAErSpo7TO1rfG6MDYuohyXL4WbaGCJdV8y3Ke-uL6VjGRb1hvw@mail.gmail.com> (raw)
In-Reply-To: <92EBB4272BF81E4089A7126EC1E7B2846676C7EF@IRSMSX101.ger.corp.intel.com>
On Fri, Apr 21, 2017 at 2:46 AM, Patel, Mayurkumar
<mayurkumar.patel@intel.com> wrote:
> Hi Bjorn/Kaya,
>
>
>>
>>On 4/17/2017 12:38 PM, Bjorn Helgaas wrote:
>>>> Like you said, what do we do by default is the question. Should we opt
>>>> for safe like we are doing, or try to save some power.
>>> I think safety is paramount. Every user should be able to boot safely
>>> without any kernel parameters. We don't want users to have a problem
>>> booting and then have to search for a workaround like booting with
>>> "pcie_aspm=off". Most users will never do that.
>>>
>>
>>OK, no problem with leaving the behavior as it is.
>>
>>My initial approach was #2. We knew this way that user had full control
>>over the ASPM policy by changing the BIOS option. Then, Mayurkumar
>>complained that ASPM is not enabled following a hotplug insertion to an
>>empty slot. That's when I switched to #3 as it sounded like a good thing
>>to have for us.
>>
>>> Here's a long-term strawman proposal, see what you think:
>>>
>>> - Deprecate CONFIG_PCIEASPM_DEFAULT, CONFIG_PCIEASPM_POWERSAVE, etc.
>>> - Default aspm_policy is POLICY_DEFAULT always.
>>> - POLICY_DEFAULT means Linux doesn't touch anything: if BIOS enabled
>>> ASPM, we leave it that way; we leave ASPM disabled on hot-added
>>> devices.
>>
> I am also ok with leaving the same behavior as now.
> But still following is something open I feel besides, Which may be there in your comments redundantly.
> The current problem is, pcie_aspm_exit_link_state() disables the ASPM configuration even
> if POLICY_DEFAULT was set.
We call pcie_aspm_exit_link_state() when removing an endpoint. When
we remove an endpoint, I think disabling ASPM is the right thing to
do. The spec (PCIe r3.1, sec 5.4.1.3) says "Software must not enable
L0s in either direction on a given Link unless components on both
sides of the Link each support L0s; otherwise, the result is
undefined."
> I am seeing already following problem(or may be influence) with it. The Endpoint I have does not have
> does not have "Presence detect change" mechanism. Hot plug is working with Link status events.
> When link is in L1 or L1SS and if EP is powered off, no Link status change event are triggered (It might be
> the expected behavior in L1 or L1SS). When next time EP is powered on there are link down and
> link up events coming one after other. BIOS enables ASPM on Root port and Endpoint, but while
> processing link status down, pcie_aspm_exit_link_state() clears the ASPM already which were enabled by BIOS.
> If we want to follow above approach then shall we consider having something similar as following?
The proposal was to leave ASPM disabled on hot-added devices. If the
endpoint was powered off and powered back on again, I think that
device looks like a hot-added device, doesn't it?
Bjorn
next prev parent reply other threads:[~2017-04-25 18:45 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1491627351-1111-1-git-send-email-okaya@codeaurora.org>
2017-04-08 4:55 ` [PATCH V8 1/5] PCI/ASPM: introduce pci_aspm_init() and add to pci_init_capabilities() Sinan Kaya
2017-04-13 20:51 ` Bjorn Helgaas
2017-04-14 19:10 ` Sinan Kaya
2017-04-08 4:55 ` [PATCH V8 2/5] PCI/ASPM: split pci_aspm_init() into two Sinan Kaya
2017-04-12 19:16 ` Rajat Jain
2017-04-13 18:25 ` Bjorn Helgaas
2017-04-14 19:10 ` Sinan Kaya
2017-04-08 4:55 ` [PATCH V8 3/5] PCI/ASPM: add init hook to device_add Sinan Kaya
2017-04-13 20:48 ` Bjorn Helgaas
2017-04-13 21:02 ` Bjorn Helgaas
2017-04-14 1:19 ` Sinan Kaya
2017-04-14 1:30 ` Bjorn Helgaas
2017-04-08 4:55 ` [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init Sinan Kaya
2017-04-12 19:19 ` Rajat Jain
2017-04-14 19:12 ` Sinan Kaya
2017-04-14 21:44 ` Bjorn Helgaas
2017-04-14 22:17 ` Sinan Kaya
2017-04-17 16:38 ` Bjorn Helgaas
2017-04-17 17:50 ` Sinan Kaya
2017-04-21 7:46 ` Patel, Mayurkumar
2017-04-21 13:50 ` Sinan Kaya
2017-04-21 14:13 ` Patel, Mayurkumar
2017-04-25 18:45 ` Bjorn Helgaas [this message]
2017-05-02 12:02 ` Patel, Mayurkumar
2017-05-03 21:10 ` Bjorn Helgaas
2017-05-15 9:10 ` Patel, Mayurkumar
2017-04-08 4:55 ` [PATCH V8 5/5] PCI/ASPM: move link_state cleanup to bridge remove Sinan Kaya
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=CAErSpo7TO1rfG6MDYuohyXL4WbaGCJdV8y3Ke-uL6VjGRb1hvw@mail.gmail.com \
--to=bhelgaas@google.com \
--cc=Julia.Lawall@lip6.fr \
--cc=david.daney@cavium.com \
--cc=helgaas@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mayurkumar.patel@intel.com \
--cc=myron.stowe@redhat.com \
--cc=okaya@codeaurora.org \
--cc=rajatja@google.com \
--cc=rajatxjain@gmail.com \
--cc=shawn.lin@rock-chips.com \
--cc=timur@codeaurora.org \
--cc=yinghai@kernel.org \
/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
all inboxes | Powered by JetHome®