[PATCH 3/3] drm/amdgpu/gfx: assign the actual me0 queues per pipe

2025-03-29 Thread Alex Deucher
Set the actual number of queues per pipe for ME0 (gfx). This way we will dump all of the queues properly in dev core dumps. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 4 ++-- drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 4 ++-- drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c | 2

Re: [PATCH 1/2] drm/amd/display: Protect dml2_create()/dml2_copy()/dml2_create_copy()

2025-03-29 Thread Huacai Chen
Hi, Aurabindo, On Sat, Mar 29, 2025 at 2:27 AM Aurabindo Pillai wrote: > > > > On 2025-03-26 21:40, Huacai Chen wrote: > > Hi, Alex, > > > > On Thu, Mar 27, 2025 at 8:10 AM Alex Hung wrote: > >> > >> The following error messages showed up on an APU and a dGPU during testing. > >> > >> <3> [100.2

Re: [PATCH] drm/amd/display: replace use of msleep(<20) with usleep_range for better accuracy

2025-03-29 Thread James
On Fri, Mar 28, 2025, at 3:46 PM, Shuah Khan wrote: > On 3/26/25 01:00, James Flowers wrote: >> msleep < 20ms will often sleep for ~20ms (according to >> Documentation/timers/timers-howto.rst). > > Can you elaborate and explain why this change is necessary? scripts/checkpatch.pl highlighted it as

Re: [PATCH V8 28/43] drm/colorop: Add PQ 125 EOTF and its inverse

2025-03-29 Thread Simon Ser
Reviewed-by: Simon Ser

Re: [PATCH V8 40/43] drm/colorop: Add 3D LUT support to color pipeline

2025-03-29 Thread Simon Ser
Reviewed-by: Simon Ser

Re: [PATCH V8 03/43] drm/doc/rfc: Describe why prescriptive color pipeline is needed

2025-03-29 Thread Simon Ser
Thanks a lot for these docs, very well written. I especially like the "Driver Implementer's Guide" section. A few minor comments below, regardless: Reviewed-by: Simon Ser > +What problem are we solving? > + > + > +We would like to support pre-, and post-blending comp

Re: [PATCH V8 10/43] drm/plane: Add COLOR PIPELINE property

2025-03-29 Thread Simon Ser
Two nits below, regardless: Reviewed-by: Simon Ser > + } else if (property == plane->color_pipeline_property) { > + /* find DRM colorop object */ > + struct drm_colorop *colorop = NULL; > + > + colorop = drm_colorop_find(dev, file_priv, val); > + > +

Re: [PATCH V8 11/43] drm/colorop: Introduce DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE

2025-03-29 Thread Simon Ser
Reviewed-by: Simon Ser

Re: [PATCH V8 12/43] Documentation/gpu: document drm_colorop

2025-03-29 Thread Simon Ser
Reviewed-by: Simon Ser

Re: [PATCH V8 32/43] drm/colorop: Add 1D Curve Custom LUT type

2025-03-29 Thread Simon Ser
Reviewed-by: Simon Ser

Re: [PATCH V8 20/43] drm/colorop: pass plane_color_pipeline client cap to atomic check

2025-03-29 Thread Simon Ser
Reviewed-by: Simon Ser

Re: [PATCH V8 39/43] drm/colorop: allow non-bypass colorops

2025-03-29 Thread Simon Ser
I'm personally not a fan of such boolean function arguments, especially when caller and callee are far apart. From the caller side, the meaning of the boolean argument is not immediately clear. I would prefer a "flags" argument, which can take a e.g. DRM_COLOROP_FLAG_ALLOW_BYPASS value. But I'm n

Re: [PATCH V8 43/43] drm/colorop: Add destroy functions for color pipeline

2025-03-29 Thread Simon Ser
I would prefer these functions to be introduced together with the patches adding functions to create objects and adding the new fields. That way it's easier to check the symmetry and at no point in the series there are memory leaks. Additionally, I would avoid using the name "cleanup", which seems

Re: [PATCH V8 30/43] drm/colorop: add BT2020/BT709 OETF and Inverse OETF

2025-03-29 Thread Simon Ser
Note, this patch adds new values in the middle of the enum. This is in general a breaking uAPI change: all enum values afterwards will get re-numbered. Maybe this patch should come before the PQ 125 one. In this series it shouldn't matter either way because we're also introducing the enum, but (1)