From: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
To: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>,
<igt-dev@lists.freedesktop.org>
Cc: <intel-gfx@lists.freedesktop.org>,
<intel-xe@lists.freedesktop.org>,
"Kamil Konieczny" <kamil.konieczny@linux.intel.com>,
Andi Shyti <andi.shyti@linux.intel.com>,
Krzysztof Karas <krzysztof.karas@intel.com>,
Krzysztof Niemiec <krzysztof.niemiec@intel.com>,
Sebastian Brzezinka <sebastian.brzezinka@intel.com>
Subject: Re: [PATCH i-g-t 3/7] lib/igt_device_scan: Include PCIe bridge upstream port if available
Date: Fri, 23 Jan 2026 12:02:30 +0100 [thread overview]
Message-ID: <DFVX25OT5Y4I.1UO45LB0A5M5P@intel.com> (raw)
In-Reply-To: <20260121114656.1970684-12-janusz.krzysztofik@linux.intel.com>
Hi Janusz,
On Wed Jan 21, 2026 at 12:42 PM CET, Janusz Krzysztofik wrote:
> Users of Intel discrete graphics adapters are confused with fake
> information on PCIe link bandwidth (speed and size) of their GPU devices
> reported by sysfs and userspace tools, including our lsgpu utility. In
> order for the lsgpu to show correct link bandwidth information, we need to
> identify an upstream port of a PCIe bridge that sits on the GPU card and
> get that information from that port.
>
> Since the tool uses our udev based igt_device_scan library for identifying
> GPU devices and printing their properties and attributes, modifications
> that we need apply to that library.
>
> When scanning for DRM devices and their PCI parents, the lsgpu utility
> requests collection of all their attributes. When running in this mode,
> also try to collect information about upstream ports of PCIe bridges of
> discrete GPU devices. Once collected, the lsgpu utility will show that
> information automatically while listing the devices.
>
> While IGT tests are using pciaccess library for processing PCI devices,
> that library requires careful handling in order to avoid collisions among
> multiple processes or threads potentially using it. That protection is
> implemented in igt_device with help of IGT exit handlers. That requires
> linking with full igt_core library code, while the lsgpu tool now depends
> neither on igt_device nor on igt_core. To keep that independence,
> implement the new code around libpci. With that approach, refactoring of
> IGT use of pciaccess is avoided.
>
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10753
> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> ---
> lib/igt_device_scan.c | 73 +++++++++++++++++++++++++++++++++++++++++--
> lib/meson.build | 2 ++
> meson.build | 1 +
> 3 files changed, 74 insertions(+), 2 deletions(-)
>
> diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
> index d3a2ebe8d2..34c7a8131b 100644
> --- a/lib/igt_device_scan.c
> +++ b/lib/igt_device_scan.c
> @@ -36,6 +36,7 @@
> #ifdef __linux__
> #include <linux/limits.h>
> #endif
> +#include <pci/pci.h>
> #include <sys/stat.h>
> #include <sys/time.h>
> #include <sys/types.h>
> @@ -909,6 +910,27 @@ static struct igt_device *igt_device_from_syspath(const char *syspath)
> return NULL;
> }
>
> +static bool is_pcie_upstream_bridge(struct pci_dev *dev)
> +{
> + struct pci_cap *pcie;
> + uint8_t type, dir;
> +
> + type = pci_read_byte(dev, PCI_HEADER_TYPE) & 0x7f;
> + if (type != PCI_HEADER_TYPE_BRIDGE)
> + return false;
> +
> + pcie = pci_find_cap(dev, PCI_CAP_ID_EXP, PCI_CAP_NORMAL);
> + if (!pcie)
> + return false;
> +
> + /* GET_REG_MASK macro borrowed from pciutils' internal bitops.h */
> +#define GET_REG_MASK(reg, mask) (((reg) & (mask)) / ((mask) & ~((mask) << 1)))
> + dir = GET_REG_MASK(pci_read_word(dev, pcie->addr + PCI_EXP_FLAGS), PCI_EXP_FLAGS_TYPE);
> +#undef GET_REG_MASK
Instead of copying the macro, we could just use:
type = ( pci_read_word... & PCI_EXP_FLAGS_TYPE) >> 4. This seems cleaner.
> +
> + return dir == PCI_EXP_TYPE_UPSTREAM;
> +}
> +
> #define RETRIES_GET_PARENT 5
>
> static struct igt_device *find_or_add_igt_device(struct udev *udev,
> @@ -948,18 +970,55 @@ static struct igt_device *find_or_add_igt_device(struct udev *udev,
> return idev;
> }
>
> +static struct udev_device *get_pcie_upstream_bridge(struct udev *udev,
> + struct udev_device *dev)
> +{
> + struct pci_access *pacc;
> +
> + pacc = pci_alloc();
> + pci_init(pacc);
> +
I'm not entirely familiar with this pci library, but is it necessary to initialize it
for every device? It might be more efficient to do it once in scan_drm_devices.
--
Best regards,
Sebastian
next prev parent reply other threads:[~2026-01-23 11:02 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-21 11:42 [PATCH i-g-t 0/7] lsgpu: Report upstream port link bandwidth Janusz Krzysztofik
2026-01-21 11:42 ` [PATCH i-g-t 1/7] lib/igt_device_scan: Don't print fake link bandwidth attributes Janusz Krzysztofik
2026-01-23 11:01 ` Sebastian Brzezinka
2026-01-23 14:10 ` Janusz Krzysztofik
2026-01-23 14:20 ` Sebastian Brzezinka
2026-01-23 14:42 ` Janusz Krzysztofik
2026-01-23 14:59 ` Sebastian Brzezinka
2026-01-21 11:42 ` [PATCH i-g-t 2/7] lib/igt_device_scan: Split out reusable part of update_or_add_parent Janusz Krzysztofik
2026-01-23 11:02 ` Sebastian Brzezinka
2026-01-21 11:42 ` [PATCH i-g-t 3/7] lib/igt_device_scan: Include PCIe bridge upstream port if available Janusz Krzysztofik
2026-01-23 11:02 ` Sebastian Brzezinka [this message]
2026-01-23 14:22 ` Janusz Krzysztofik
2026-01-21 11:42 ` [PATCH i-g-t 4/7] lib/igt_device_scan: List PCIe bridge ports after their children Janusz Krzysztofik
2026-01-23 11:02 ` Sebastian Brzezinka
2026-01-21 11:42 ` [PATCH i-g-t 5/7] lib/igt_device_scan: Omit AER statistics data from attributes Janusz Krzysztofik
2026-01-21 11:42 ` [PATCH i-g-t 6/7] lib/igt_device_scan: Don't print bridge not applicable attributes Janusz Krzysztofik
2026-01-23 11:03 ` Sebastian Brzezinka
2026-01-23 14:29 ` Janusz Krzysztofik
2026-01-21 11:42 ` [PATCH i-g-t 7/7] lib/igt_device_scan: Print GPU upstream port parent/child relations Janusz Krzysztofik
2026-01-23 11:03 ` Sebastian Brzezinka
2026-01-23 14:34 ` Janusz Krzysztofik
2026-01-26 12:56 ` Janusz Krzysztofik
2026-01-23 12:36 ` ✓ Xe.CI.BAT: success for lsgpu: Report upstream port link bandwidth (rev4) Patchwork
2026-01-23 12:54 ` ✗ i915.CI.BAT: failure " Patchwork
2026-01-24 0:46 ` ✗ Xe.CI.Full: " Patchwork
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=DFVX25OT5Y4I.1UO45LB0A5M5P@intel.com \
--to=sebastian.brzezinka@intel.com \
--cc=andi.shyti@linux.intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=janusz.krzysztofik@linux.intel.com \
--cc=kamil.konieczny@linux.intel.com \
--cc=krzysztof.karas@intel.com \
--cc=krzysztof.niemiec@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.