dri-devel March 2022

dri-devel@lists.freedesktop.org

370 participants
780 discussions

[PATCH v4 0/3] drm/msm/dp: replace DRM_DEBUG_DP with drm_dbg_dp
by Kuogee Hsieh 01 Apr '22

01 Apr '22

Since DRM_DEBUG_DP is deprecated in favor of drm_dbg_dp(NULL, ...), replace all DRM_DEBUG_DP with drm_dbg_dp(). Kuogee Hsieh (3): drm/msm/dp: add connector type to enhance debug messages drm/msm/dp: enhance debug info related to dp phy drm/msm/dp: replace DRM_DEBUG_DP marco with drm_dbg_dp drivers/gpu/drm/msm/dp/dp_audio.c | 50 ++++++++++----- drivers/gpu/drm/msm/dp/dp_catalog.c | 35 +++++----- drivers/gpu/drm/msm/dp/dp_ctrl.c | 124 +++++++++++++++++++----------------- drivers/gpu/drm/msm/dp/dp_display.c | 103 +++++++++++++++++++++--------- drivers/gpu/drm/msm/dp/dp_drm.c | 4 +- drivers/gpu/drm/msm/dp/dp_link.c | 103 ++++++++++++++++++------------ drivers/gpu/drm/msm/dp/dp_panel.c | 47 ++++++++------ drivers/gpu/drm/msm/dp/dp_parser.c | 2 - drivers/gpu/drm/msm/dp/dp_power.c | 25 ++++++-- 9 files changed, 302 insertions(+), 191 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

3 11

[PATCH v12 0/4] drm/msm/dpu: enable widebus feature base on chip hardware revision
by Kuogee Hsieh 01 Apr '22

01 Apr '22

revise widebus timing engine programming and enable widebus feature base on chip Kuogee Hsieh (4): drm/msm/dpu: adjust display_v_end for eDP and DP drm/msm/dpu: replace BIT(x) with correspond marco define string drm/msm/dpu: revise timing engine programming to support widebus feature drm/msm/dp: enable widebus feature for display port drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 14 ++++- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 2 + .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 14 +++++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 62 ++++++++++++++++------ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 2 + drivers/gpu/drm/msm/dp/dp_catalog.c | 34 +++++++++++- drivers/gpu/drm/msm/dp/dp_catalog.h | 2 + drivers/gpu/drm/msm/dp/dp_ctrl.c | 7 ++- drivers/gpu/drm/msm/dp/dp_ctrl.h | 1 + drivers/gpu/drm/msm/dp/dp_display.c | 21 +++++++- drivers/gpu/drm/msm/dp/dp_display.h | 2 + drivers/gpu/drm/msm/msm_drv.h | 6 +++ 12 files changed, 146 insertions(+), 21 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

3 8

[PATCH] linux/fb.h: Spelling s/palette/palette/
by Geert Uytterhoeven 01 Apr '22

01 Apr '22

Fix a misspelling of "palette" in a comment. Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org> --- include/uapi/linux/fb.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/uapi/linux/fb.h b/include/uapi/linux/fb.h index 4c14e8be7267761b..3a49913d006c9bf6 100644 --- a/include/uapi/linux/fb.h +++ b/include/uapi/linux/fb.h @@ -182,7 +182,7 @@ struct fb_fix_screeninfo { * * For pseudocolor: offset and length should be the same for all color * components. Offset specifies the position of the least significant bit - * of the pallette index in a pixel value. Length indicates the number + * of the palette index in a pixel value. Length indicates the number * of available palette entries (i.e. # of entries = 1 << length). */ struct fb_bitfield { -- 2.25.1

3 2

Re: [PATCH v2 1/5] dt-bindings: reserved-memory: Document memory region specifier
by Thierry Reding 01 Apr '22

01 Apr '22

On Fri, Jul 02, 2021 at 05:16:25PM +0300, Dmitry Osipenko wrote: > 01.07.2021 21:14, Thierry Reding пишет: > > On Tue, Jun 08, 2021 at 06:51:40PM +0200, Thierry Reding wrote: > >> On Fri, May 28, 2021 at 06:54:55PM +0200, Thierry Reding wrote: > >>> On Thu, May 20, 2021 at 05:03:06PM -0500, Rob Herring wrote: > >>>> On Fri, Apr 23, 2021 at 06:32:30PM +0200, Thierry Reding wrote: > >>>>> From: Thierry Reding <treding(a)nvidia.com> > >>>>> > >>>>> Reserved memory region phandle references can be accompanied by a > >>>>> specifier that provides additional information about how that specific > >>>>> reference should be treated. > >>>>> > >>>>> One use-case is to mark a memory region as needing an identity mapping > >>>>> in the system's IOMMU for the device that references the region. This is > >>>>> needed for example when the bootloader has set up hardware (such as a > >>>>> display controller) to actively access a memory region (e.g. a boot > >>>>> splash screen framebuffer) during boot. The operating system can use the > >>>>> identity mapping flag from the specifier to make sure an IOMMU identity > >>>>> mapping is set up for the framebuffer before IOMMU translations are > >>>>> enabled for the display controller. > >>>>> > >>>>> Signed-off-by: Thierry Reding <treding(a)nvidia.com> > >>>>> --- > >>>>> .../reserved-memory/reserved-memory.txt | 21 +++++++++++++++++++ > >>>>> include/dt-bindings/reserved-memory.h | 8 +++++++ > >>>>> 2 files changed, 29 insertions(+) > >>>>> create mode 100644 include/dt-bindings/reserved-memory.h > >>>> > >>>> Sorry for being slow on this. I have 2 concerns. > >>>> > >>>> First, this creates an ABI issue. A DT with cells in 'memory-region' > >>>> will not be understood by an existing OS. I'm less concerned about this > >>>> if we address that with a stable fix. (Though I'm pretty sure we've > >>>> naively added #?-cells in the past ignoring this issue.) > >>> > >>> A while ago I had proposed adding memory-region*s* as an alternative > >>> name for memory-region to make the naming more consistent with other > >>> types of properties (think clocks, resets, gpios, ...). If we added > >>> that, we could easily differentiate between the "legacy" cases where > >>> no #memory-region-cells was allowed and the new cases where it was. > >>> > >>>> Second, it could be the bootloader setting up the reserved region. If a > >>>> node already has 'memory-region', then adding more regions is more > >>>> complicated compared to adding new properties. And defining what each > >>>> memory-region entry is or how many in schemas is impossible. > >>> > >>> It's true that updating the property gets a bit complicated, but it's > >>> not exactly rocket science. We really just need to splice the array. I > >>> have a working implemention for this in U-Boot. > >>> > >>> For what it's worth, we could run into the same issue with any new > >>> property that we add. Even if we renamed this to iommu-memory-region, > >>> it's still possible that a bootloader may have to update this property > >>> if it already exists (it could be hard-coded in DT, or it could have > >>> been added by some earlier bootloader or firmware). > >>> > >>>> Both could be addressed with a new property. Perhaps something like > >>>> 'iommu-memory-region = <&phandle>;'. I think the 'iommu' prefix is > >>>> appropriate given this is entirely because of the IOMMU being in the > >>>> mix. I might feel differently if we had other uses for cells, but I > >>>> don't really see it in this case. > >>> > >>> I'm afraid that down the road we'll end up with other cases and then we > >>> might proliferate a number of *-memory-region properties with varying > >>> prefixes. > >>> > >>> I am aware of one other case where we might need something like this: on > >>> some Tegra SoCs we have audio processors that will access memory buffers > >>> using a DMA engine. These processors are booted from early firmware > >>> using firmware from system memory. In order to avoid trashing the > >>> firmware, we need to reserve memory. We can do this using reserved > >>> memory nodes. However, the audio DMA engine also uses the SMMU, so we > >>> need to make sure that the firmware memory is marked as reserved within > >>> the SMMU. This is similar to the identity mapping case, but not exactly > >>> the same. Instead of creating a 1:1 mapping, we just want that IOVA > >>> region to be reserved (i.e. IOMMU_RESV_RESERVED instead of > >>> IOMMU_RESV_DIRECT{,_RELAXABLE}). > >>> > >>> That would also fall into the IOMMU domain, but we can't reuse the > >>> iommu-memory-region property for that because then we don't have enough > >>> information to decide which type of reservation we need. > >>> > >>> We could obviously make iommu-memory-region take a specifier, but we > >>> could just as well use memory-regions in that case since we have > >>> something more generic anyway. > >>> > >>> With the #memory-region-cells proposal, we can easily extend the cell in > >>> the specifier with an additional MEMORY_REGION_IOMMU_RESERVE flag to > >>> take that other use case into account. If we than also change to the new > >>> memory-regions property name, we avoid the ABI issue (and we gain a bit > >>> of consistency while at it). > >> > >> Ping? Rob, do you want me to add this second use-case to the patch > >> series to make it more obvious that this isn't just a one-off thing? Or > >> how do we proceed? > > > > Rob, given that additional use-case, do you want me to run with this > > proposal and send out an updated series? > > > What about variant with a "descriptor" properties that will describe > each region: > > fb_desc: display-framebuffer-memory-descriptor { > needs-identity-mapping; > } > > display@52400000 { > memory-region = <&fb ...>; > memory-region-descriptor = <&fb_desc ...>; > }; > > It could be a more flexible/extendible variant. This problem recently came up on #dri-devel again. Adding Alyssa and Sven who are facing a similar challenge on their work on Apple M1 (if I understood correctly). Also adding dri-devel for visibility since this is a very common problem for display in particular. On M1 the situation is slightly more complicated: the firmware will allocate a couple of buffers (including the framebuffer) in high memory (> 4 GiB) and use the IOMMU to map that into an IOVA region below 4 GiB so that the display hardware can access it. This makes it impossible to bypass the IOMMU like we do on other chips (in particular to work around the fault-by-default policy of the ARM SMMU driver). It also means that in addition to the simple reserved regions I mentioned we need for audio use-cases and identity mapping use-cases we need for display on Tegra, we now also need to be able to convey physical to IOVA mappings. Fitting the latter into the original proposal sounds difficult. A quick fix would've been to generate a mapping table in memory and pass that to the kernel using a reserved-memory node (similar to what's done for example on Tegra for the EMC frequency table on Tegra210) and mark it as such using a special flag. But that then involves two layers of parsing, which seems a bit suboptimal. Another way to shoehorn that into the original proposal would've been to add flags for physical and virtual address regions and use pairs to pass them using special flags. Again, this is a bit wonky because it needs these to be carefully parsed and matched up. Another downside is that we now have a situation where some of these regions are no longer "reserved-memory regions" in the traditional sense. This would require an additional flag in the reserved-memory region nodes to prevent the IOVA regions from being reserved. By the way, this is something that would also be needed for the audio use-case I mentioned before, because the physical memory at that address can still be used by an operating system. A more general solution would be to draw a bit from Dmitry's proposal and introduce a new top-level "iov-reserved-memory" node. This could be modelled on the existing reserved-memory node, except that the physical memory pages for regions represented by child nodes would not be marked as reserved. Only the IOVA range described by the region would be reserved subsequently by the IOMMU framework and/or IOMMU driver. The simplest case where we just want to reserve some IOVA region could then be done like this: iov-reserved-memory { /* * Probably safest to default to <2>, <2> here given * that most IOMMUs support either > 32 bits of IAS * or OAS. */ #address-cells = <2>; #size-cells = <2>; firmware: firmware@80000000 { reg = <0 0x80000000 0 0x01000000>; }; }; audio@30000000 { ... iov-memory-regions = <&firmware>; ... }; Mappings could be represented by an IOV reserved region taking a reference to the reserved-region that they map: reserved-memory { #address-cells = <2>; #size-cells = <2>; /* 16 MiB of framebuffer at top-of-memory */ framebuffer: framebuffer@1,ff000000 { reg = <0x1 0xff000000 0 0x01000000>; no-map; }; }; iov-reserved-memory { /* IOMMU supports only 32-bit output address space */ #address-cells = <1>; #size-cells = <1>; /* 16 MiB of framebuffer mapped to top of IOVA */ fb: fb@ff000000 { reg = <0 0xff000000 0 0x01000000>; memory-region = <&framebuffer>; }; }; display@40000000 { ... /* optional? */ memory-region = <&framebuffer>; iov-memory-regions = <&fb>; ... }; It's interesting how identity mapped regions now become a trivial special case of mappings. All that is needed is to make the reg property of the IOV reserved region correspond to the reg property of the normal reserved region. Alternatively, as a small optimization for lazy people like me, we could just allow these cases to omit the reg property and instead inherit it from the referenced reserved region. As the second example shows it might be convenient if memory-region could be derived from iov-memory-regions. This could be useful for cases where the driver wants to do something with the physical pages of the reserved region (such as mapping them and copying out the framebuffer data to another buffer so that the reserved memory can be recycled). If we have the IOV reserved region, we could provide an API to extract the physical reserved region (if it exists). That way we could avoid referencing it twice in DT. Then again, there's something elegant about the explicit second reference to. It indicates the intent that we may want to use the region for something other than just the IOV mapping. Anyway, this has been long enough. Let me know what you think. Alyssa, Sven, it'd be interesting to hear if you think this could work as a solution to the problem on M1. Rob, I think you might like this alternative because it basically gets rid of all the points in the original proposal that you were concerned about. Let me know what you think. Thierry

3 12

[PATCH v2 00/12] drm/edid: cleanup and refactoring around validity checks
by Jani Nikula 01 Apr '22

01 Apr '22

v2 of https://patchwork.freedesktop.org/series/101931/ Rebased, review comments addressed. BR, Jani. Jani Nikula (12): drm/edid: use struct edid * in drm_do_get_edid() drm/edid: clean up EDID block checksum functions drm/edid: add edid_block_tag() helper to get the EDID extension tag drm/edid: make drm_edid_header_is_valid() accept void pointer drm/edid: clean up edid_is_zero() drm/edid: split out edid_header_fix() drm/edid: split drm_edid_block_valid() to check and act parts drm/edid: use a better variable name for EDID block read retries drm/edid: simplify block check when filtering invalid blocks drm/edid: split out invalid block filtering to a separate function drm/edid: track invalid blocks in drm_do_get_edid() drm/edid: reduce magic when updating the EDID block checksum drivers/gpu/drm/drm_edid.c | 295 +++++++++++++++++++++---------------- include/drm/drm_edid.h | 2 +- 2 files changed, 173 insertions(+), 124 deletions(-) -- 2.30.2

2 15

[PATCH 0/1] add PSR-SU DPCD bitfield definitions as per eDP 1.5
by David Zhang 01 Apr '22

01 Apr '22

*** BLURB HERE *** David Zhang (1): drm: add PSR2 support and capability definition as per eDP 1.5 include/drm/drm_dp_helper.h | 2 ++ 1 file changed, 2 insertions(+) -- 2.25.1

4 4

[PATCH] drm/amdgpu/vcn: remove Unneeded semicolon
by Haowen Bai 01 Apr '22

01 Apr '22

report by coccicheck: drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:1951:2-3: Unneeded semicolon fixed c543dcb ("drm/amdgpu/vcn: Add VCN ras error query support") Signed-off-by: Haowen Bai <baihaowen(a)meizu.com> --- drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c index 3e1de8c..17d44be 100644 --- a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c @@ -1948,7 +1948,7 @@ static uint32_t vcn_v2_6_query_poison_by_instance(struct amdgpu_device *adev, break; default: break; - }; + } if (poison_stat) dev_info(adev->dev, "Poison detected in VCN%d, sub_block%d\n", -- 2.7.4

4 5

[PATCH v2] drm/amd/display: Fix unused-but-set-variable warning
by Aashish Sharma 01 Apr '22

01 Apr '22

Fix the kernel test robot warning below: drivers/gpu/drm/amd/amdgpu/../display/dmub/inc/dmub_cmd.h:2893:12: warning: variable 'temp' set but not used [-Wunused-but-set-variable] Replaced the assignment to the unused temp variable with READ_ONCE() macro to flush the writes. READ_ONCE() helps avoid the use of volatile and makes it obvious from the code that the read here is intentional. Also verified on x86 that the generated code is exactly the same as before. Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Aashish Sharma <shraash(a)google.com> --- v2: Removed unnecessary volatile qualifier in the typecast and an unnecessary comment. Also reworded the commit message. --- drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h index 873ecd04e01d..a58f460f431d 100644 --- a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h +++ b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h @@ -2913,13 +2913,11 @@ static inline void dmub_rb_flush_pending(const struct dmub_rb *rb) uint32_t wptr = rb->wrpt; while (rptr != wptr) { - uint64_t volatile *data = (uint64_t volatile *)((uint8_t *)(rb->base_address) + rptr); - //uint64_t volatile *p = (uint64_t volatile *)data; - uint64_t temp; + uint64_t *data = (uint64_t *)((uint8_t *)(rb->base_address) + rptr); uint8_t i; for (i = 0; i < DMUB_RB_CMD_SIZE / sizeof(uint64_t); i++) - temp = *data++; + (void)READ_ONCE(*data++); rptr += DMUB_RB_CMD_SIZE; if (rptr >= rb->capacity) -- 2.35.1.894.gb6a874cedc-goog

2 1

[PATCH 1/2] drm/panel: lvds: Simplify mode parsing
by Marek Vasut 01 Apr '22

01 Apr '22

The mode parsing is currently implemented in three steps: of_get_display_timing() - DT panel-timing to struct display_timing videomode_from_timing() - struct display_timing to struct videomode drm_display_mode_from_videomode() - struct videomode to struct drm_display_mode Replace all that with simple of_get_drm_panel_display_mode() call, which already populates struct drm_display_mode and then duplicate that mode in panel_lvds_get_modes() each time, since the mode does not change. Nice bonus is the bus_flags parsed by of_get_drm_panel_display_mode() out of panel-timing DT node, which is used in subsequent patch to fix handling of 'de-active' DT property. Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Christoph Niedermaier <cniedermaier(a)dh-electronics.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Dmitry Osipenko <digetx(a)gmail.com> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: Robert Foss <robert.foss(a)linaro.org> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> To: dri-devel(a)lists.freedesktop.org --- drivers/gpu/drm/panel/panel-lvds.c | 28 ++++++---------------------- 1 file changed, 6 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-lvds.c b/drivers/gpu/drm/panel/panel-lvds.c index 27a1c9923b09..65c6a6e9e223 100644 --- a/drivers/gpu/drm/panel/panel-lvds.c +++ b/drivers/gpu/drm/panel/panel-lvds.c @@ -30,7 +30,8 @@ struct panel_lvds { const char *label; unsigned int width; unsigned int height; - struct videomode video_mode; + struct drm_display_mode dmode; + u32 bus_flags; unsigned int bus_format; bool data_mirror; @@ -87,16 +88,15 @@ static int panel_lvds_get_modes(struct drm_panel *panel, struct panel_lvds *lvds = to_panel_lvds(panel); struct drm_display_mode *mode; - mode = drm_mode_create(connector->dev); + mode = drm_mode_duplicate(connector->dev, &lvds->dmode); if (!mode) return 0; - drm_display_mode_from_videomode(&lvds->video_mode, mode); mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED; drm_mode_probed_add(connector, mode); - connector->display_info.width_mm = lvds->width; - connector->display_info.height_mm = lvds->height; + connector->display_info.width_mm = lvds->dmode.width_mm; + connector->display_info.height_mm = lvds->dmode.height_mm; drm_display_info_set_bus_formats(&connector->display_info, &lvds->bus_format, 1); connector->display_info.bus_flags = lvds->data_mirror @@ -116,7 +116,6 @@ static const struct drm_panel_funcs panel_lvds_funcs = { static int panel_lvds_parse_dt(struct panel_lvds *lvds) { struct device_node *np = lvds->dev->of_node; - struct display_timing timing; int ret; ret = of_drm_get_panel_orientation(np, &lvds->orientation); @@ -125,28 +124,13 @@ static int panel_lvds_parse_dt(struct panel_lvds *lvds) return ret; } - ret = of_get_display_timing(np, "panel-timing", &timing); + ret = of_get_drm_panel_display_mode(np, &lvds->dmode, &lvds->bus_flags); if (ret < 0) { dev_err(lvds->dev, "%pOF: problems parsing panel-timing (%d)\n", np, ret); return ret; } - videomode_from_timing(&timing, &lvds->video_mode); - - ret = of_property_read_u32(np, "width-mm", &lvds->width); - if (ret < 0) { - dev_err(lvds->dev, "%pOF: invalid or missing %s DT property\n", - np, "width-mm"); - return -ENODEV; - } - ret = of_property_read_u32(np, "height-mm", &lvds->height); - if (ret < 0) { - dev_err(lvds->dev, "%pOF: invalid or missing %s DT property\n", - np, "height-mm"); - return -ENODEV; - } - of_property_read_string(np, "label", &lvds->label); ret = drm_of_lvds_get_data_mapping(np); -- 2.35.1

3 8

[PATCH i-g-t 00/11] Per client GPU utilisation
by Tvrtko Ursulin 01 Apr '22

01 Apr '22

From: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> This series contains four main components: 1. Per client support for intel_gpu_top. 2. IGT test for per client data exposed via fdinfo from i915. 3. Extracting intel_gpu_top code into shared IGT libraries - which makes possible to write: 4. Vendor agnostic rudimentary gputop tool. Since I had the intel_gpu_top code for years, this flow of the series is what I ended up with. But it also makes sense since we can have a cut point after intel_gpu_top, in case the common drm fdinfo specification does not end up getting enough traction. Example of the intel_gpu_top output: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ intel-gpu-top: Intel Tigerlake (Gen12) @ /dev/dri/card0 - 220/ 221 MHz 70% RC6; 0.62/ 7.08 W; 760 irqs/s ENGINES BUSY MI_SEMA MI_WAIT Render/3D 23.06% |██████▊ | 0% 0% Blitter 0.00% | | 0% 0% Video 5.40% |█▋ | 0% 0% VideoEnhance 20.67% |██████ | 0% 0% PID NAME Render/3D Blitter Video VideoEnhance 3082 mpv | || ||▌ ||██ | 3117 neverball |█▉ || || || | 1 systemd |▍ || || || | 2338 gnome-shell | || || || | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Example of the gputop output: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ DRM minor 0 PID NAME render copy video 3816 kwin_x11 |███▎ || || || | 3523 Xorg |▊ || || || | 1120449 mpv | || ||▋ || | 1120529 glxgears |▋ || || || | 1120449 mpv |▍ || || || | 3860 plasmashell |▏ || || || | 4764 krunner | || || || | 575206 chrome | || || || | 833481 firefox | || || || | 892924 thunderbird | || || || | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tvrtko Ursulin (11): lib: Helper library for parsing i915 fdinfo output tests/i915/drm_fdinfo: Basic and functional tests for GPU busyness exported via fdinfo intel-gpu-top: Add support for per client stats lib: Extract igt_drm_clients from intel_gpu_top libdrmfdinfo: Allow specifying custom engine map libdrmclients: Record client drm minor libdrmclient: Support multiple DRM cards libdrmfdinfo: Track largest engine index libdrmclient/intel_gpu_top: Decouple hardcoded engine assumptions libdrmclient: Enforce client status sort order in the library gputop: Basic vendor agnostic GPU top tool lib/igt_drm_clients.c | 443 +++++++++++++++++++++++++++++++ lib/igt_drm_clients.h | 104 ++++++++ lib/igt_drm_fdinfo.c | 200 ++++++++++++++ lib/igt_drm_fdinfo.h | 52 ++++ lib/meson.build | 15 ++ man/intel_gpu_top.rst | 4 + tests/i915/drm_fdinfo.c | 565 ++++++++++++++++++++++++++++++++++++++++ tests/meson.build | 8 + tools/gputop.c | 276 ++++++++++++++++++++ tools/intel_gpu_top.c | 497 ++++++++++++++++++++++++++++++++++- tools/meson.build | 7 +- 11 files changed, 2159 insertions(+), 12 deletions(-) create mode 100644 lib/igt_drm_clients.c create mode 100644 lib/igt_drm_clients.h create mode 100644 lib/igt_drm_fdinfo.c create mode 100644 lib/igt_drm_fdinfo.h create mode 100644 tests/i915/drm_fdinfo.c create mode 100644 tools/gputop.c -- 2.32.0

2 17

← Newer
1
...
12
13
14
15
16
17
18
...
78
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2022