Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM

The Gallium HUD doesn't consume strings. It only consumes values that are exposed as counters from the driver. In this case, we need the driver to expose evicted stats as counters. Each counter can set whether the value is absolute (e.g. memory usage) or monotonic (e.g. perf counter). Parsing

Re: [PATCH 1/2] drm/amd/display: Hook up 'content type' property for HDMI

On 1/19/23 17:20, Joshua Ashton wrote: > > > On 1/19/23 18:14, Melissa Wen wrote: >> On 01/17, Joshua Ashton wrote: >>> Implements the 'content type' property for HDMI connectors. >>> Verified by checking the avi infoframe on a connected TV. >>> >>> This also simplifies a lot of the code in

Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM

How are the counters which the HUD consumes declared? See what I want to avoid is a) to nail down the interface with the kernel on specific values and b) make it possible to easily expose new values. In other words what we could do with fdinfo is to have something like this:

Re: Minimal kernel version for 7900XT

On 1/23/23 12:28, Ernst Sjöstrand wrote:> 6.0 should be enough: > https://www.phoronix.com/review/rx7900xt-rx7900xtx-linux > > > The firmware files is maybe the most complicated part right now... > > //Ernst I found that article, too, but

Re: Minimal kernel version for 7900XT

Ah you were looking at the packaged driver installer (usually called "Proprietary" even though most of it is not). It will install extra modules so it works with "any" kernel. For the upstream Torvalds support I guess you end up in the CHIP_IP_DISCOVERY clause, it's a new method for new cards.

New? amdgpu drm_modeset_drop_locks oops/warning with 6.2-rc#

Hi, Since I'm dogfooding 6.2-rc# I'm regularly (not always directly after boot) seeing the following warning / oops in my logs. This is on an AMD Ryzen 7 5700G on a B550M PRO-VDH WIFI with 2 1920x1080 monitors connected (one over DVI and over HDMI IIRC). [4.896028] [drm] amdgpu kernel

Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM

Let's do this as valid in fdinfo. This way we can easily extend whatever the kernel wants to display as statistics in the userspace HUD. Regards, Christian. Am 21.01.23 um 01:45 schrieb Marek Olšák: We badly need a way to query evicted memory usage. It's essential for investigating

[PATCH 08/10] drm/fbdev-generic: Minimize client unregistering

For uninitialized framebuffers, only release the DRM client and free the fbdev memory. Do not attempt to clean up the framebuffer. DRM fbdev clients have a two-step initialization: first create the DRM client; then create the framebuffer device on the first successful hotplug event. In cases

Re: Minimal kernel version for 7900XT

On 1/23/23 15:09, Alex Deucher wrote: On Mon, Jan 23, 2023 at 5:11 AM Goran Mekić wrote: Hello, I'm trying to figure out what's the minimal kernel version that supports the 7900XT. I found that the driver supports SLES 15:

Re: Minimal kernel version for 7900XT

6.0 should be enough: https://www.phoronix.com/review/rx7900xt-rx7900xtx-linux The firmware files is maybe the most complicated part right now... //Ernst Den mån 23 jan. 2023 kl 11:11 skrev Goran Mekić : > Hello, > > I'm trying to figure out what's the minimal kernel version that supports >

Re: Minimal kernel version for 7900XT

On 1/23/23 13:34, Ernst Sjöstrand wrote: Ah you were looking at the packaged driver installer (usually called "Proprietary" even though most of it is not). It will install extra modules so it works with "any" kernel. For the upstream Torvalds support I guess you end up in the

Re: Minimal kernel version for 7900XT

On Mon, Jan 23, 2023 at 5:11 AM Goran Mekić wrote: > > Hello, > > I'm trying to figure out what's the minimal kernel version that supports > the 7900XT. I found that the driver supports SLES 15: >

Re: [PATCH v2 00/14] Remove clang's -Qunused-arguments from KBUILD_CPPFLAGS

Hi Nathan, On Thu, 12 Jan 2023 at 08:35, Nathan Chancellor wrote: > > Hi all, > > Clang can emit a few different warnings when it encounters a flag that it > recognizes but does not support internally. These warnings are elevated to > errors within {as,cc}-option via -Werror to catch unsupported

Minimal kernel version for 7900XT

Hello, I'm trying to figure out what's the minimal kernel version that supports the 7900XT. I found that the driver supports SLES 15: https://www.amd.com/en/support/graphics/amd-radeon-rx-7000-series/amd-radeon-rx-7900-series/amd-radeon-rx-7900xt I also found that SLES 15 SP 4 runs on 5.14:

[PATCH 04/10] drm/fbdev-generic: Initialize fb-helper structure in generic setup

Initialize the fb-helper structure immediately after its allocation in drm_fbdev_generic_setup(). That will make it easier to fill it with driver-specific values, such as the preferred BPP. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_fbdev_generic.c | 13 + 1 file

Re: [PATCH 0/7] Fix MST on amdgpu

For the whole series, as rebased on v6.1.7. Tested on this Thinkpad X13 AMD Gen2: Tested-By: Didier Raboud Le vendredi, 20 janvier 2023, 00.51:53 h CET Harry Wentland a écrit : > MST has been broken on amdgpu after a refactor in drm_dp_mst > code that was aligning drm_dp_mst more closely with

[PATCH 00/10] drm/fb-helper: Various cleanups

Add various cleanups and changes to DRM's fbdev helpers and the generic fbdev emulation. There's no clear theme here, just lots of small things that need to be updated. In the end, the code will better reflect which parts are in the DRM client, which is fbdev emulation, and which are shared

[PATCH 07/10] drm/fbdev-generic: Minimize hotplug error handling

Call drm_fb_helper_init() in the generic-fbdev hotplug helper to revert the effects of drm_fb_helper_init(). No full cleanup is required. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_fbdev_generic.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git

[PATCH 09/10] drm/fbdev-generic: Inline clean-up helpers into drm_fbdev_fb_destroy()

The fbdev framebuffer cleanup in drm_fbdev_fb_destroy() calls drm_fbdev_release() and drm_fbdev_cleanup(). Inline both into the caller. No functional changes. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_fbdev_generic.c | 17 ++--- 1 file changed, 2 insertions(+), 15

[PATCH 02/10] drm/client: Add hotplug_failed flag

Signal failed hotplugging with a flag in struct drm_client_dev. If set, the client helpers will not further try to set up the fbdev display. This used to be signalled with a combination of cleared pointers in struct drm_fb_helper, which prevents us from initializing these pointers early after

[PATCH 03/10] drm/fb-helper: Introduce drm_fb_helper_unprepare()

Move the fb-helper clean-up code into drm_fb_helper_unprepare(). No functional changes. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_fb_helper.c | 14 +- include/drm/drm_fb_helper.h | 4 2 files changed, 17 insertions(+), 1 deletion(-) diff --git

[PATCH 01/10] drm/client: Test for connectors before sending hotplug event

Test for connectors in the client code and remove a similar test from the generic fbdev emulation. Do nothing if the test fails. Not having connectors indicates a driver bug. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_client.c| 5 + drivers/gpu/drm/drm_fbdev_generic.c

[PATCH 05/10] drm/fb-helper: Remove preferred_bpp parameter from fbdev internals

Store the console's preferred BPP value in struct drm_fb_helper and remove the respective function parameters from the internal fbdev code. The BPP value is only required as a fallback and will now always be available in the fb-helper instance. No functional changes. Signed-off-by: Thomas

[PATCH 10/10] drm/fbdev-generic: Rename struct fb_info 'fbi' to 'info'

The generic fbdev emulation names variables of type struct fb_info both 'fbi' and 'info'. The latter seems to be more common in fbdev code, so name fbi accordingly. Also replace the duplicate variable in drm_fbdev_fb_destroy(). Signed-off-by: Thomas Zimmermann ---

[PATCH 06/10] drm/fb-helper: Initialize fb-helper's preferred BPP in prepare function

Initialize the fb-helper's preferred_bpp field early from within drm_fb_helper_prepare(); instead of the later client hot-plugging callback. This simplifies the generic fbdev setup function. No real changes, but all drivers' fbdev code has to be adapted. Signed-off-by: Thomas Zimmermann ---

RE: [PATCH IP-REVIEW 00/26] DC Patches Jan. 16, 2023

[Public] Hi all, This week this patchset was tested on the following systems: Lenovo Thinkpad T14s Gen2, with AMD Ryzen 5 5650U Lenovo Thinkpad T13s Gen4 with AMD Ryzen 5 6600U Reference AMD RX6800 These systems were tested on the following display types: eDP, (1080p 60hz [4500U, 5650U])

Re: [PATCH v2 00/14] Remove clang's -Qunused-arguments from KBUILD_CPPFLAGS

Hi Naresh, On Mon, Jan 23, 2023 at 07:28:10PM +0530, Naresh Kamboju wrote: > FYI, > [ please provide comments, feedback and improvements on build/ ltp smoke > tests ] > > LKFT test farm have fetched your patch series [1] > [PATCH v2 00/14] Remove clang's -Qunused-arguments from KBUILD_CPPFLAGS

[linux-next:master] BUILD REGRESSION 691781f561e9868a94c3ed7daf4adad7f8af5d16

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 691781f561e9868a94c3ed7daf4adad7f8af5d16 Add linux-next specific files for 20230123 Error/Warning: (recently discovered and may have been fixed) ERROR: modpost: "devm_platform_ioremap_res

Re: [PATCH 0/7] Fix MST on amdgpu

On 1/20/23 18:15, Lyude Paul wrote: > For the whole series: > > Reviewed-by: Lyude Paul Thanks, series is merged to amd-staging-drm-next. Harry > > So glad to have this fixed finally ♥ > > On Thu, 2023-01-19 at 18:51 -0500, Harry Wentland wrote: >> MST has been broken on amdgpu after a

Re: [PATCH 0/7] Fix MST on amdgpu

On 1/22/23 14:12, Didier 'OdyX' Raboud wrote: > For the whole series, as rebased on v6.1.7. Tested on this Thinkpad X13 AMD > Gen2: > > Tested-By: Didier Raboud Thanks. Harry > > Le vendredi, 20 janvier 2023, 00.51:53 h CET Harry Wentland a écrit : >> MST has been broken on amdgpu after

[RFC PATCH] drm: Create documentation about device resets

Create a document that specifies how to deal with DRM device resets for kernel and userspace drivers. Signed-off-by: André Almeida --- Documentation/gpu/drm-reset.rst | 51 + Documentation/gpu/index.rst | 1 + 2 files changed, 52 insertions(+) create mode

[RFC PATCH 0/1] drm: Add doc about GPU reset

Due to the complexity of its stack and the apps that we run on it, GPU resets are for granted. What's left for driver developers is how to make resets a smooth experience as possible. While some OS's can recover or show an error message in such cases, Linux is more a hit-and-miss due to its lack

Re: [PATCH v2 18/21] drm/amd/display: Fallback to 2020_YCBCR if the pixel encoding is not RGB

A new property to control YCC and subsampling would be the more complete path here. If we actually want to fix this in the short-term though, we should handle the YCC and RGB Colorspace values as equivalent, everywhere. Technically we're breaking the user space API here so it should be documented

Re: [RFC PATCH] drm: Create documentation about device resets

Am 23.01.23 um 21:26 schrieb André Almeida: Create a document that specifies how to deal with DRM device resets for kernel and userspace drivers. Signed-off-by: André Almeida --- Documentation/gpu/drm-reset.rst | 51 + Documentation/gpu/index.rst | 1 +

Re: [PATCH 10/10] drm/fbdev-generic: Rename struct fb_info 'fbi' to 'info'

Hi Thomas, a quick drive-by comment. On Mon, Jan 23, 2023 at 11:05:59AM +0100, Thomas Zimmermann wrote: > The generic fbdev emulation names variables of type struct fb_info > both 'fbi' and 'info'. The latter seems to be more common in fbdev > code, so name fbi accordingly. > > Also replace the

Fix for UMR on newer C++

[AMD Official Use Only - General] I noticed this today; it's required to explicitly include "" in newer GCC's, which I think has to do with newer C++ standards. None the less, see the attached patch. From c6863e7687404c628521d2a96d0055ec982f6df3 Mon Sep 17 00:00:00 2001 From: Jeremy Newton

Re: Fix for UMR on newer C++

Thanks I'll apply it upon the morrow From: Newton, Jeremy Sent: Monday, January 23, 2023 18:04 To: amd-gfx@lists.freedesktop.org Cc: StDenis, Tom Subject: Fix for UMR on newer C++ [AMD Official Use Only - General] I noticed this today; it's required to