From: Lukas Wunner <lukas@wunner.de>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: linux-pci@vger.kernel.org, Bjorn Helgaas <helgaas@kernel.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Wilczy??ski <kw@linux.com>,
Alexandru Gagniuc <mr.nuke.me@gmail.com>,
Krishna chaitanya chundru <quic_krichai@quicinc.com>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
"Rafael J . Wysocki" <rafael@kernel.org>,
linux-pm@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
linux-kernel@vger.kernel.org,
Alex Deucher <alexdeucher@gmail.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Amit Kucheria <amitk@kernel.org>, Zhang Rui <rui.zhang@intel.com>
Subject: Re: [PATCH v3 05/10] PCI: Store all PCIe Supported Link Speeds
Date: Sat, 30 Dec 2023 20:30:00 +0100 [thread overview]
Message-ID: <20231230193000.GA11331@wunner.de> (raw)
In-Reply-To: <20231230114549.GB12257@wunner.de>
On Sat, Dec 30, 2023 at 12:45:49PM +0100, Lukas Wunner wrote:
> On Fri, Sep 29, 2023 at 02:57:18PM +0300, Ilpo Järvinen wrote:
> > struct pci_bus stores max_bus_speed. Implementation Note in PCIe r6.0.1
> > sec 7.5.3.18, however, recommends determining supported Link Speeds
> > using the Supported Link Speeds Vector in the Link Capabilities 2
> > Register (when available).
> >
> > Add pcie_bus_speeds into struct pci_bus which caches the Supported Link
> > Speeds. The value is taken directly from the Supported Link Speeds
> > Vector or synthetized from the Max Link Speed in the Link Capabilities
> > Register when the Link Capabilities 2 Register is not available.
>
> Remind me, what's the reason again to cache this and why is
> max_bus_speed not sufficient? Is the point that there may be
> "gaps" in the supported link speeds, i.e. not every bit below
> the maximum supported speed may be set? And you need to skip
> over those gaps when throttling to a lower speed?
FWIW I went and re-read the internal review I provided on May 18.
Turns out I already mentioned back then that gaps aren't permitted:
"Per PCIe r6.0.1 sec 8.2.1, the bitfield in the Link Capabilities 2
register is not permitted to contain gaps between maximum supported
speed and lowest possible speed (2.5 GT/s Gen1)."
> Also, I note that pci_set_bus_speed() doesn't use LNKCAP2.
About that, I wrote in May:
"Actually, scratch that. pci_set_bus_speed() is fine. Since it's only
interested in the *maximum* link speed, reading just LnkCap is correct.
LnkCap2 only needs to be read to determine if a certain speed is
*supported*. E.g., even though 32 GT/s are supported, perhaps 16 GT/s
are not.
It's rather pcie_get_speed_cap() which should be changed. There's
no need for it to read LnkCap2. The commit which introduced this,
6cf57be0f78e, was misguided and had to be fixed up with f1f90e254e46.
It could be simplified to just read LnkCap and return
pcie_link_speed[linkcap & PCI_EXP_LNKCAP_SLS]. If the device is a
Root Port or Downstream Port, it doesn't even have to do that but
could return the cached value in subordinate->max_bus_speed.
If you add another attribute to struct pci_bus for the downstream
device's maximum speed, the maximum speed for Endpoints and Upstream
Ports could be returned directly as well from that attribute."
Thanks,
Lukas
next prev parent reply other threads:[~2023-12-30 19:30 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-29 11:57 [PATCH v3 00/10] Add PCIe Bandwidth Controller Ilpo Järvinen
2023-09-29 11:57 ` [PATCH v3 01/10] PCI: Protect Link Control 2 Register with RMW locking Ilpo Järvinen
2023-12-30 10:33 ` Lukas Wunner
2023-09-29 11:57 ` [PATCH v3 02/10] drm/radeon: Use RMW accessors for changing LNKCTL2 Ilpo Järvinen
2023-09-29 11:57 ` [PATCH v3 03/10] drm/amdgpu: " Ilpo Järvinen
2023-09-29 11:57 ` [PATCH v3 04/10] RDMA/hfi1: " Ilpo Järvinen
2023-09-29 13:03 ` Dean Luick
2023-09-29 11:57 ` [PATCH v3 05/10] PCI: Store all PCIe Supported Link Speeds Ilpo Järvinen
2023-12-30 11:45 ` Lukas Wunner
2023-12-30 19:30 ` Lukas Wunner [this message]
2024-01-01 16:26 ` Ilpo Järvinen
2024-01-01 16:40 ` Lukas Wunner
2024-01-01 16:53 ` Ilpo Järvinen
2023-09-29 11:57 ` [PATCH v3 06/10] PCI: Cache PCIe device's Supported Speed Vector Ilpo Järvinen
2023-12-30 15:19 ` Lukas Wunner
2024-01-01 18:31 ` Ilpo Järvinen
2024-01-03 16:51 ` Lukas Wunner
2023-09-29 11:57 ` [PATCH v3 07/10] PCI/LINK: Re-add BW notification portdrv as PCIe BW controller Ilpo Järvinen
2023-12-30 15:58 ` Lukas Wunner
2024-01-01 17:37 ` Ilpo Järvinen
2024-01-01 18:11 ` Lukas Wunner
2023-09-29 11:57 ` [PATCH v3 08/10] PCI/bwctrl: Add "controller" part into PCIe bwctrl Ilpo Järvinen
2023-12-30 18:49 ` Lukas Wunner
2024-01-01 18:12 ` Ilpo Järvinen
2024-01-03 16:40 ` Lukas Wunner
2023-09-29 11:57 ` [PATCH v3 09/10] thermal: Add PCIe cooling driver Ilpo Järvinen
2023-12-30 19:08 ` Lukas Wunner
2024-01-01 16:39 ` Ilpo Järvinen
2023-09-29 11:57 ` [PATCH v3 10/10] selftests/pcie_bwctrl: Create selftests Ilpo Järvinen
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=20231230193000.GA11331@wunner.de \
--to=lukas@wunner.de \
--cc=alexdeucher@gmail.com \
--cc=amitk@kernel.org \
--cc=bhelgaas@google.com \
--cc=daniel.lezcano@linaro.org \
--cc=helgaas@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mr.nuke.me@gmail.com \
--cc=quic_krichai@quicinc.com \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=rui.zhang@intel.com \
--cc=srinivas.pandruvada@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;
as well as URLs for NNTP newsgroup(s).