RE: [RFC PATCH] drm/amd/display: dont ignore alpha property

[AMD Official Use Only] > -Original Message- > From: Melissa Wen > Sent: Friday, March 25, 2022 4:45 PM > To: amd-...@lists.freedesktop.org; Wentland, Harry > ; Deucher, Alexander > ; Siqueira, Rodrigo > ; Kazlauskas, Nicholas > ; Gutierrez, Agustin > ;

Re: [PATCH 1/2] drm/atomic: document and enforce rules around "spurious" EBUSY

On 2021-11-08 10:07 a.m., Daniel Vetter wrote: On Fri, Nov 05, 2021 at 04:47:29PM -0400, Kazlauskas, Nicholas wrote: Hi Daniel, Just got bitten by this warning when trying to do some refactoring in amdgpu for trying to get rid of the DRM private object we use for our DC state. From

Re: [PATCH 1/2] drm/atomic: document and enforce rules around "spurious" EBUSY

Hi Daniel, Just got bitten by this warning when trying to do some refactoring in amdgpu for trying to get rid of the DRM private object we use for our DC state. From a userspace perspective I understand that we want to avoid judder, -EBUSY and other issues affecting the compositor from

Re: [PATCH v6 3/3] drm/amd/display: Skip modeset for front porch change

On 2021-02-12 8:08 p.m., Aurabindo Pillai wrote: [Why] A seamless transition between modes can be performed if the new incoming mode has the same timing parameters as the optimized mode on a display with a variable vtotal min/max. Smooth video playback usecases can be enabled with this seamless

Re: [PATCH] drm/amdgpu: stream's id should reduced after stream destruct

On 2021-02-20 1:30 a.m., ZhiJie.Zhang wrote: Signed-off-by: ZhiJie.Zhang --- drivers/gpu/drm/amd/display/dc/core/dc_stream.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c index

Re: [PATCH 3/3] drm/amd/display: Skip modeset for front porch change

On 2021-01-24 11:00 p.m., Aurabindo Pillai wrote: On 2021-01-21 2:05 p.m., Kazlauskas, Nicholas wrote: On 2021-01-19 10:50 a.m., Aurabindo Pillai wrote: [Why] A seamless transition between modes can be performed if the new incoming mode has the same timing parameters as the optimized mode

Re: [PATCH 2/2] drm/amd/display: Fix HDMI deep color output for DCE 6-11.

On 2021-01-25 12:57 p.m., Alex Deucher wrote: On Thu, Jan 21, 2021 at 1:17 AM Mario Kleiner wrote: This fixes corrupted display output in HDMI deep color 10/12 bpc mode at least as observed on AMD Mullins, DCE-8.3. It will hopefully also provide fixes for other DCE's up to DCE-11, assuming

Re: [PATCH 3/3] drm/amd/display: Skip modeset for front porch change

On 2021-01-19 10:50 a.m., Aurabindo Pillai wrote: [Why] A seamless transition between modes can be performed if the new incoming mode has the same timing parameters as the optimized mode on a display with a variable vtotal min/max. Smooth video playback usecases can be enabled with this

Re: [PATCH v3 3/3] drm/amd/display: Skip modeset for front porch change

On 2021-01-04 4:08 p.m., Aurabindo Pillai wrote: [Why] Inorder to enable freesync video mode, driver adds extra modes based on preferred modes for common freesync frame rates. When commiting these mode changes, a full modeset is not needed. If the change in only in the front porch timing value,

Re: [PATCH AUTOSEL 5.4 006/130] drm/amd/display: Do not silently accept DCC for multiplane formats.

on behalf of Sasha Levin *Sent:* Tuesday, December 22, 2020 9:16 PM *To:* linux-ker...@vger.kernel.org ; sta...@vger.kernel.org *Cc:* Sasha Levin ; dri-devel@lists.freedesktop.org ; amd-...@lists.freedesktop.org ; Bas Nieuwenhuizen ; Deucher, Alexander ; Kazlauskas, Nicholas *Subjec

Re: [PATCH 2/2] drm/amd/display: Enable fp16 also on DCE-8/10/11.

On 2020-12-28 1:50 p.m., Mario Kleiner wrote: The hw supports fp16, this is not only useful for HDR, but also for standard dynamic range displays, because it allows to get more precise color reproduction with about 11 - 12 bpc linear precision in the unorm range 0.0 - 1.0. Working fp16

Re: [PATCH 1/2] drm/amd/display: Check plane scaling against format specific hw plane caps.

On 2020-12-28 1:50 p.m., Mario Kleiner wrote: This takes hw constraints specific to pixel formats into account, e.g., the inability of older hw to scale fp16 format framebuffers. It should now allow safely to enable fp16 formats also on DCE-8, DCE-10, DCE-11.0 Signed-off-by: Mario Kleiner

Re: [PATCH] drm/amdgpu: Do not change amdgpu framebuffer format during page flip

On 2020-12-21 10:18 p.m., Zhan Liu wrote: [Why] Driver cannot change amdgpu framebuffer (afb) format while doing page flip. Force system doing so will cause ioctl error, and result in breaking several functionalities including FreeSync. If afb format is forced to change during page flip,

Re: [PATCH 0/3] drm/amd/display: Fix kernel panic by breakpoint

Reviewed-by: Nicholas Kazlauskas Looks fine to me. Feel free to apply. Regards, Nicholas Kazlauskas On 2020-10-26 3:34 p.m., Alex Deucher wrote: Yes, looks good to me as well. Series is: Acked-by: Alex Deucher I'll give the display guys a few more days to look this over, but if there are

Re: [PATCH 1/3] drm/atomic-helpers: remove legacy_cursor_update hacks

On 2020-10-21 12:32 p.m., Daniel Vetter wrote: The stuff never really worked, and leads to lots of fun because it out-of-order frees atomic states. Which upsets KASAN, among other things. For async updates we now have a more solid solution with the ->atomic_async_check and ->atomic_async_commit

Re: [PATCH v2 0/4] Enlarge tracepoints in the display component

On 2020-09-16 5:12 a.m., Daniel Vetter wrote: On Fri, Sep 11, 2020 at 10:59:23AM -0400, Rodrigo Siqueira wrote: Debug issues related to display can be a challenge due to the complexity around this topic and different source of information might help in this process. We already have support for

Re: [PATCH v2] drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is

On 2020-09-14 11:22 a.m., Michel Dänzer wrote: On 2020-09-14 4:37 p.m., Kazlauskas, Nicholas wrote: On 2020-09-14 3:52 a.m., Michel Dänzer wrote: On 2020-09-07 9:57 a.m., Daniel Vetter wrote: On Fri, Sep 04, 2020 at 12:43:04PM +0200, Michel Dänzer wrote: From: Michel Dänzer Don't check

Re: [PATCH v2] drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is

On 2020-09-14 3:52 a.m., Michel Dänzer wrote: On 2020-09-07 9:57 a.m., Daniel Vetter wrote: On Fri, Sep 04, 2020 at 12:43:04PM +0200, Michel Dänzer wrote: From: Michel Dänzer Don't check drm_crtc_state::active for this either, per its documentation in include/drm/drm_crtc.h:   * Hence

Re: [PATCH v2 1/4] drm/amd/display: Rework registers tracepoint

On 2020-09-11 10:59 a.m., Rodrigo Siqueira wrote: amdgpu_dc_rreg and amdgpu_dc_wreg are very similar, for this reason, this commits abstract these two events by using DECLARE_EVENT_CLASS and create an instance of it for each one of these events. Signed-off-by: Rodrigo Siqueira This looks

Re: [PATCH v2 3/4] drm/amd/display: Add pipe_state tracepoint

On 2020-09-11 10:59 a.m., Rodrigo Siqueira wrote: This commit introduces a trace mechanism for struct pipe_ctx by adding a middle layer struct in the amdgpu_dm_trace.h for capturing the most important data from struct pipe_ctx and showing its data via tracepoint. This tracepoint was added to

Re: [PATCH] drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is

On 2020-08-22 5:59 a.m., Michel Dänzer wrote: On 2020-08-21 8:07 p.m., Kazlauskas, Nicholas wrote: On 2020-08-21 12:57 p.m., Michel Dänzer wrote: From: Michel Dänzer Don't check drm_crtc_state::active for this either, per its documentation in include/drm/drm_crtc.h:   * Hence drivers must

Re: [PATCH] drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is

On 2020-08-21 12:57 p.m., Michel Dänzer wrote: From: Michel Dänzer Don't check drm_crtc_state::active for this either, per its documentation in include/drm/drm_crtc.h: * Hence drivers must not consult @active in their various * _mode_config_funcs.atomic_check callback to reject an atomic

Re: [PATCH 7/7] drm/amd/display: Replace DRM private objects with subclassed DRM atomic state

On 2020-08-07 4:52 a.m., dan...@ffwll.ch wrote: On Thu, Jul 30, 2020 at 04:36:42PM -0400, Nicholas Kazlauskas wrote: @@ -440,7 +431,7 @@ struct dm_crtc_state { #define to_dm_crtc_state(x) container_of(x, struct dm_crtc_state, base) struct dm_atomic_state { - struct

Re: [PATCH 3/7] drm/amd/display: Avoid using unvalidated tiling_flags and tmz_surface in prepare_planes

On 2020-08-07 4:30 a.m., dan...@ffwll.ch wrote: On Thu, Jul 30, 2020 at 04:36:38PM -0400, Nicholas Kazlauskas wrote: [Why] We're racing with userspace as the flags could potentially change from when we acquired and validated them in commit_check. Uh ... I didn't know these could change. I

Re: [PATCH 5/7] drm/amd/display: Reset plane for anything that's not a FAST update

On 2020-08-07 4:34 a.m., dan...@ffwll.ch wrote: On Thu, Jul 30, 2020 at 04:36:40PM -0400, Nicholas Kazlauskas wrote: [Why] MEDIUM or FULL updates can require global validation or affect bandwidth. By treating these all simply as surface updates we aren't actually passing this through DC global

Re: [PATCH 5/7] drm/amd/display: Reset plane for anything that's not a FAST update

On 2020-08-05 4:45 p.m., Rodrigo Siqueira wrote: On 07/30, Nicholas Kazlauskas wrote: [Why] MEDIUM or FULL updates can require global validation or affect bandwidth. By treating these all simply as surface updates we aren't actually passing this through DC global validation. [How] There's

Re: [PATCH 2/7] drm/amd/display: Reset plane when tiling flags change

On 2020-08-05 5:11 p.m., Rodrigo Siqueira wrote: On 07/30, Nicholas Kazlauskas wrote: [Why] Enabling or disable DCC or switching between tiled and linear formats can require bandwidth updates. They're currently skipping all DC validation by being treated as purely surface updates. [How] Treat

Re: [PATCH 7/7] drm/amd/display: Replace DRM private objects with subclassed DRM atomic state

On 2020-08-05 4:37 p.m., Rodrigo Siqueira wrote: Hi, I have some minor inline comments, but everything looks fine when I tested it on Raven; feel free to add Tested-by: Rodrigo Siqueira in the whole series. Thanks for the reviews! I can clean up the nitpicks for this patch and make a v2.

Re: [PATCH] drm/amd/display: Clear dm_state for fast updates

On 2020-07-28 5:08 a.m., dan...@ffwll.ch wrote: On Mon, Jul 27, 2020 at 10:49:48PM -0400, Kazlauskas, Nicholas wrote: On 2020-07-27 5:32 p.m., Daniel Vetter wrote: On Mon, Jul 27, 2020 at 11:11 PM Mazin Rezk wrote: On Monday, July 27, 2020 4:29 PM, Daniel Vetter wrote: On Mon, Jul 27

Re: [PATCH] amdgpu_dm: fix nonblocking atomic commit use-after-free

On 2020-07-28 5:22 a.m., Paul Menzel wrote: Dear Linux folks, Am 25.07.20 um 07:20 schrieb Mazin Rezk: On Saturday, July 25, 2020 12:59 AM, Duncan wrote: On Sat, 25 Jul 2020 03:03:52 + Mazin Rezk wrote: Am 24.07.20 um 19:33 schrieb Kees Cook: There was a fix to disable the async

Re: [PATCH] drm/amd/display: Clear dm_state for fast updates

On 2020-07-27 5:32 p.m., Daniel Vetter wrote: On Mon, Jul 27, 2020 at 11:11 PM Mazin Rezk wrote: On Monday, July 27, 2020 4:29 PM, Daniel Vetter wrote: On Mon, Jul 27, 2020 at 9:28 PM Christian König wrote: Am 27.07.20 um 16:05 schrieb Kazlauskas, Nicholas: On 2020-07-27 9:39 a.m

Re: [PATCH] drm/amd/display: Clear dm_state for fast updates

On 2020-07-27 9:39 a.m., Christian König wrote: Am 27.07.20 um 07:40 schrieb Mazin Rezk: This patch fixes a race condition that causes a use-after-free during amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking commits are requested and the second one finishes before the first.

Re: [PATCH] drm/amd/display: Clear dm_state for fast updates

On 2020-07-27 1:40 a.m., Mazin Rezk wrote: This patch fixes a race condition that causes a use-after-free during amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking commits are requested and the second one finishes before the first. Essentially, this bug occurs when the following

Re: [PATCH] amdgpu_dm: fix nonblocking atomic commit use-after-free

On 2020-07-23 5:10 p.m., Mazin Rezk wrote: When amdgpu_dm_atomic_commit_tail is running in the workqueue, drm_atomic_state_put will get called while amdgpu_dm_atomic_commit_tail is running, causing a race condition where state (and then dm_state) is sometimes freed while

Re: [PATCH] drm/amdgpu/dc: Simplify drm_crtc_state::active checks

On 2020-07-22 8:51 a.m., Daniel Vetter wrote: On Wed, Jul 22, 2020 at 2:38 PM Michel Dänzer wrote: From: Michel Dänzer drm_atomic_crtc_check enforces that ::active can only be true if ::enable is as well. Signed-off-by: Michel Dänzer Looks fine to me. The check is sufficiently old

Re: [PATCH] drm/amd/display: add dmcub check on RENOIR

Looks good to me. Reviewed-by: Nicholas Kazlauskas Regards, Nicholas Kazlauskas On 2020-07-08 10:15 a.m., Deucher, Alexander wrote: [AMD Public Use] [AMD Public Use] Acked-by: Alex Deucher *From:* Aaron Ma *Sent:*

Re: [v1 3/3] Revert "drm/amd/display: Expose connector VRR range via debugfs"

On 2020-06-22 10:25 a.m., Bhanuprakash Modem wrote: As both VRR min and max are already part of drm_display_info, drm can expose this VRR range for each connector. Hence this logic should move to core DRM. This reverts commit 727962f030c23422a01e8b22d0f463815fb15ec4. Signed-off-by:

Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: Add enable/disable flip done and flip done handler

On 2020-06-17 5:58 a.m., Daniel Vetter wrote: On Wed, Jun 10, 2020 at 03:33:06PM -0700, Paulo Zanoni wrote: Em qui, 2020-05-28 às 11:09 +0530, Karthik B S escreveu: Add enable/disable flip done functions and the flip done handler function which handles the flip done interrupt. Enable the flip

Re: [PATCH 2/2] drm/amd/display: Enable fp16 also on DCE-11.0 - DCE-12.

On 2020-05-20 2:44 p.m., Mario Kleiner wrote: On Wed, May 20, 2020 at 8:25 PM Alex Deucher > wrote: On Wed, May 20, 2020 at 12:39 PM Harry Wentland mailto:hwent...@amd.com>> wrote: > > On 2020-05-15 1:19 a.m., Mario Kleiner wrote: > > Testing on

Re: [PATCH 2/2] drm/amd/display: Enable fp16 also on DCE-11.0 - DCE-12.

On 2020-05-15 1:19 a.m., Mario Kleiner wrote: Testing on a Polaris11 gpu with DCE-11.2 suggests that it seems to work fine there, so optimistically enable it for DCE-11 and later. Signed-off-by: Mario Kleiner Series is: Reviewed-by: Nicholas Kazlauskas Thanks! ---

Re: [RFC 16/17] drm/amdgpu: gpu recovery does full modesets

On 2020-05-12 12:12 p.m., Daniel Vetter wrote: On Tue, May 12, 2020 at 4:24 PM Alex Deucher wrote: On Tue, May 12, 2020 at 9:45 AM Daniel Vetter wrote: On Tue, May 12, 2020 at 3:29 PM Alex Deucher wrote: On Tue, May 12, 2020 at 9:17 AM Daniel Vetter wrote: On Tue, May 12, 2020 at

Re: [PATCH] drm/amd/display: Fix pageflip event race condition for DCN. (v2)

ideas on how to fix it (other than just revert this commit, which I've done in the interim), or alternative patches would be appreciated. Thanks in advance for the work/help, Matt On 3/13/20 8:42 AM, Michel Dänzer wrote: On 2020-03-13 1:35 p.m., Kazlauskas, Nicholas wrote: On 2020-03-12 10:32 a.m.,

Re: [PATCH] [v2] amdgpu: fix gcc-4.8 build warnings

On 2020-04-29 5:20 a.m., Arnd Bergmann wrote: Older compilers warn about initializers with incorrect curly braces: drivers/gpu/drm/drm_dp_mst_topology.c: In function 'drm_dp_mst_dsc_aux_for_port': drivers/gpu/drm/drm_dp_mst_topology.c:5497:9: error: missing braces around initializer

Re: [PATCH 2/2] drm/amd/dc: Kill dc_conn_log_hex_linux()

On 2020-03-31 5:22 p.m., Lyude Paul wrote: DRM already supports tracing DPCD transactions, there's no reason for the existence of this function. Also, it prints one byte per-line which is way too loud. So, just remove it. Signed-off-by: Lyude Paul Thanks for helping clean this up! Series

Re: [PATCH] drm/amd/display: Fix pageflip event race condition for DCN. (v2)

On 2020-03-12 10:32 a.m., Alex Deucher wrote: On Thu, Mar 5, 2020 at 4:21 PM Mario Kleiner wrote: Commit '16f17eda8bad ("drm/amd/display: Send vblank and user events at vsartup for DCN")' introduces a new way of pageflip completion handling for DCN, and some trouble. The current

Re: [PATCH v4 2/2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits

(Ville) * Make the drm_get_adaptive_sync_range function static (Harry, Jani) v2: * Change vmin and vmax to use u8 (Ville) * Dont store pixel clock since that is just a max dotclock and not related to VRR mode (Manasi) Cc: Ville Syrjälä Cc: Harry Wentland Cc: Clinton A Taylor Cc: Kazlauskas

Re: [PATCH v2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits

On 2020-02-28 9:38 p.m., Manasi Navare wrote: On Fri, Feb 28, 2020 at 01:18:45PM -0800, Manasi Navare wrote: On Thu, Jan 09, 2020 at 03:08:52PM +0200, Ville Syrjälä wrote: On Tue, Jan 07, 2020 at 04:32:08PM -0800, Manasi Navare wrote: Adaptive Sync is a VESA feature so add a DRM core helper

Re: [PATCH] drm/amd/display: Fix pageflip event race condition for DCN.

On 2020-03-02 1:17 a.m., Mario Kleiner wrote: Commit '16f17eda8bad ("drm/amd/display: Send vblank and user events at vsartup for DCN")' introduces a new way of pageflip completion handling for DCN, and some trouble. The current implementation introduces a race condition, which can cause

Re: [PATCH] drm/amd/display: fix undefined struct member reference

On 2019-12-10 3:54 p.m., Liu, Zhan wrote: -Original Message- From: Arnd Bergmann Sent: 2019/December/10, Tuesday 3:31 PM To: Wentland, Harry ; Li, Sun peng (Leo) ; Deucher, Alexander ; Koenig, Christian ; Zhou, David(ChunMing) ; David Airlie ; Daniel Vetter ; Liu, Zhan Cc: Arnd

Re: [PATCH] drm/amd/display: include linux/slab.h where needed

On 2019-12-10 2:59 p.m., Arnd Bergmann wrote: Calling kzalloc() and related functions requires the linux/slab.h header to be included: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c: In function 'dcn21_ipp_create':

Re: [PATCH][next] drm/amd/display: fix spelling mistake "exeuction" -> "execution"

On 2019-11-09 2:49 p.m., Colin King wrote: From: Colin Ian King There are spelling mistakes in a DC_ERROR message and a comment. Fix these. Signed-off-by: Colin Ian King Reviewed-by: Nicholas Kazlauskas Thanks! Nicholas Kazlauskas --- drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c

Re: [PATCH] drm/amd/display: remove duplicated comparison expression

On 2019-11-09 10:49 a.m., Colin King wrote: From: Colin Ian King There is comparison expression that is duplicated and hence one of the expressions can be removed. Remove it. Addresses-Coverity: ("Same on both sides") Fixes: 12e2b2d4c65f ("drm/amd/display: add dcc programming for dual

Re: [PATCH 01/12] drm: Inline drm_color_lut_extract()

On 2019-11-07 10:43 a.m., Ville Syrjälä wrote: > On Thu, Nov 07, 2019 at 03:31:28PM +0000, Kazlauskas, Nicholas wrote: >> On 2019-11-07 10:17 a.m., Ville Syrjala wrote: >>> From: Ville Syrjälä >>> >>> This thing can get called several thousand times per LUT

Re: [PATCH 01/12] drm: Inline drm_color_lut_extract()

On 2019-11-07 10:17 a.m., Ville Syrjala wrote: > From: Ville Syrjälä > > This thing can get called several thousand times per LUT > so seems like we want to inline it to: > - avoid the function call overhead > - allow constant folding > > A quick synthetic test (w/o any hardware interaction)

Re: [PATCH 01/13] drm/amd/display: Add MST atomic routines

On 2019-10-30 3:24 p.m., mikita.lip...@amd.com wrote: > From: Mikita Lipski > > - Adding encoder atomic check to find vcpi slots for a connector > - Using DRM helper functions to calculate PBN > - Adding connector atomic check to release vcpi slots if connector > loses CRTC > - Calculate PBN

Re: [PATCH -next] drm/amd/display: Add a conversion function for transmitter and phy_id enums

On 2019-10-30 2:04 a.m., Nathan Chancellor wrote: > Clang warns: > > ../drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2520:42: > error: implicit conversion from enumeration type 'enum transmitter' to > different enumeration type 'enum physical_phy_id' > [-Werror,-Wenum-conversion] >

Re: [PATCH 1/3] drm/amd/display: Use swap() where appropriate

On 2019-10-10 9:11 a.m., Ville Syrjala wrote: > From: Ville Syrjälä > > Mostly a cocci-job, but it flat out refused to remove the > declaration in drivers/gpu/drm/amd/display/dc/core/dc.c so > had to do that part manually. > > @swap@ > identifier TEMP; > expression A,B; > @@ > - TEMP = A; > - A

Re: [PATCH 3/3] drm/atomic: Rename crtc_state->pageflip_flags to async_flip

On 2019-09-03 3:06 p.m., Daniel Vetter wrote: > It's the only flag anyone actually cares about. Plus if we're unlucky, > the atomic ioctl might need a different flag for async flips. So > better to abstract this away from the uapi a bit. > > Cc: Maarten Lankhorst > Cc: Michel Dänzer > Cc: Alex

Re: [PATCH v2 11/14] drm/amd/display: Validate DSC caps on MST endpoints

On 8/20/19 3:12 PM, David Francis wrote: > The first step in MST DSC is checking MST endpoints > to see how DSC can be enabled > > Case 1: DP-to-DP peer device > if the branch immediately upstream has > - PDT = DP_PEER_DEVICE_DP_MST_BRANCHING (2) > - DPCD rev. >= DP 1.4 > - Exactly one

Re: [PATCH v2 06/14] drm/dp-mst: Use dc and drm helpers to compute timeslots

On 8/20/19 4:43 PM, Lyude Paul wrote: > Some nitpicks below > > On Tue, 2019-08-20 at 15:11 -0400, David Francis wrote: >> We were using drm helpers to convert a timing into its >> bandwidth, its bandwidth into pbn, and its pbn into timeslots >> >> These helpers >> -Did not take DSC timings into

Re: [PATCH v2 14/14] drm/amd/display: Trigger modesets on MST DSC connectors

On 8/20/19 5:09 PM, Lyude Paul wrote: > This should definitely be implemented as an atomic helper in > drm_dp_mst_topology.c as well. This is probably reasonable, most drivers would probably want this. The issues with this in general are still: (1) Knowing if you have a DSC in the MST network

Re: [PATCH 07/14] drm/amd/display: Initialize DSC PPS variables to 0

On 8/19/19 11:50 AM, David Francis wrote: > For DSC MST, sometimes monitors would break out > in full-screen static. The issue traced back to the > PPS generation code, where these variables were being used > uninitialized and were picking up garbage. > > memset to 0 to avoid this > >

Re: [PATCH 14/14] drm/amd/display: Trigger modesets on MST DSC connectors

On 8/19/19 11:50 AM, David Francis wrote: > Whenever a connector on an MST network is attached, detached, or > undergoes a modeset, the DSC configs for each stream on that > topology will be recalculated. This can change their required > bandwidth, requiring a full reprogramming, as though a

Re: [PATCH 06/14] drm/amd/display: Use dc helpers to compute timeslot distribution

On 8/19/19 11:50 AM, David Francis wrote: > We were using drm helpers to convert a timing into its > bandwidth, its bandwidth into pbn, and its pbn into timeslots > > These helpers > -Did not take DSC timings into account > -Used the link rate and lane count of the link's aux device, > which

Re: [PATCH v2] drm: Set crc->opened to false before setting crc source to NULL.

On 7/26/19 12:02 PM, David (Dingchen) Zhang wrote: > From: Dingchen Zhang > > to terminate the while-loop in drm_dp_aux_crc_work when > drm_dp_start/stop_crc are called in the hook to set crc source. > > v2: Move spin_lock around entire crc->opened use (Daniel) > > Cc: Daniel Vetter > Cc:

Re: [PATCH 5/7] drm/amd/display: Use proper enum conversion functions

On 7/25/19 12:00 PM, Li, Sun peng (Leo) wrote: > > > On 2019-07-18 11:16 p.m., Nathan Chancellor wrote: >> On Wed, Jul 03, 2019 at 10:52:16PM -0700, Nathan Chancellor wrote: >>> clang warns: >>> >>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:336:8: >>> warning: implicit

Re: [PATCH 9/9] drm/amd/display: Implement MST Aux device registration

On 7/23/19 7:28 PM, sunpeng...@amd.com wrote: > From: Leo Li > > Implement late_register and early_unregister hooks for MST connectors. > Call drm helpers for MST connector registration, which registers the > AUX devices. > > Cc: Jerry Zuo > Cc: Nicholas Kazlauskas > Cc: Harry Wentland >

Re: [PATCH] drm/amd/display: avoid 64-bit division

On 7/8/19 9:52 AM, Arnd Bergmann wrote: > On 32-bit architectures, dividing a 64-bit integer in the kernel > leads to a link error: > > ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! > ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! > > Change the two

Re: [PATCH 2/2] drm: Set crc->opened = false before setting crc source to NULL.

pened) { >>> + spin_lock_irq(>lock); >>> + crc->opened = false; >>> + spin_unlock_irq(>lock); >>> + } > > Either you don't need a lock to look at ->opened, or you need it. Not > both. Too lazy check which way thi

Re: [PATCH] amdgpu_dm: no need to check return value of debugfs_create functions

On 6/13/19 9:20 AM, Greg Kroah-Hartman wrote: > When calling debugfs functions, there is no need to ever check the > return value. The function can work or not, but the code logic should > never do something different based on this. > > Cc: Harry Wentland > Cc: Leo Li > Cc: Alex Deucher > Cc:

Re: [PATCH 5/7] drm/amd/display: Use connector kdev as aux device parent

On 5/16/19 11:18 AM, sunpeng...@amd.com wrote: > > From: Leo Li > > Set the connector's kernel device as the parent for the aux kernel > device. This allows udev rules to access connector attributes when > creating symlinks to aux devices. > > For example, the following udev rule: > >

Re: [v9 04/13] drm: Enable HDR infoframe support

On 5/8/19 2:38 PM, Uma Shankar wrote: > [CAUTION: External Email] > > Enable Dynamic Range and Mastering Infoframe for HDR > content, which is defined in CEA 861.3 spec. > > The metadata will be computed based on blending > policy in userspace compositors and passed as a connector > property

Re: [v8 02/10] drm: Parse HDR metadata info from EDID

On 4/9/19 12:44 PM, Uma Shankar wrote: > HDR metadata block is introduced in CEA-861.3 spec. > Parsing the same to get the panel's HDR metadata. > > v2: Rebase and added Ville's POC changes to the patch. > > v3: No Change > > v4: Addressed Shashank's review comments > > v5: Addressed

Re: [PATCH] drm/amd/display: Allow faking displays as VRR capable.

On 4/30/19 3:44 AM, Michel Dänzer wrote: > [CAUTION: External Email] > > On 2019-04-30 9:37 a.m., Mario Kleiner wrote: >> Allow to detect any connected display to be marked as >> VRR capable. This is useful for testing the basics of >> VRR mode, e.g., scheduling and timestamping, BTR, and >>

Re: [PATCH 3/3] drm/amd/display: Compensate for pre-DCE12 BTR-VRR hw limitations. (v3)

On 4/26/19 5:40 PM, Mario Kleiner wrote: > Pre-DCE12 needs special treatment for BTR / low framerate > compensation for more stable behaviour: > > According to comments in the code and some testing on DCE-8 > and DCE-11, DCE-11 and earlier only apply VTOTAL_MIN/MAX > programming with a lag of one

Re: [PATCH 3/3] drm/amd/display: Compensate for pre-DCE12 BTR-VRR hw limitations. (v2)

On 4/26/19 6:50 AM, Mario Kleiner wrote: > Pre-DCE12 needs special treatment for BTR / low framerate > compensation for more stable behaviour: > > According to comments in the code and some testing on DCE-8 > and DCE-11, DCE-11 and earlier only apply VTOTAL_MIN/MAX > programming with a lag of one

Re: [PATCH 4/4] drm/amd/display: Compensate for pre-DCE12 BTR-VRR hw limitations.

On 4/17/19 11:51 PM, Mario Kleiner wrote: > Pre-DCE12 needs special treatment for BTR / low framerate > compensation for more stable behaviour: > > According to comments in the code and some testing on DCE-8 > and DCE-11, DCE-11 and earlier only apply VTOTAL_MIN/MAX > programming with a lag of

Re: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already signaled.

Feel free to merge 1+2 since they don't really depend on any other work in the series and they were previously reviewed. Nicholas Kazlauskas On 4/23/19 8:32 AM, Koenig, Christian wrote: > Well you at least have to give me time till after the holidays to get > going again :) > > Not sure

Re: [PATCH 2/4] drm/amd/display: Fix and simplify apply_below_the_range()

On 4/17/19 11:51 PM, Mario Kleiner wrote: > The comparison of inserted_frame_duration_in_us against a > duration calculated from max_refresh_in_uhz is both wrong > in its math and not needed, as the min_duration_in_us value > is already cached in in_out_vrr for reuse. No need to > recalculate it

Re: [PATCH 1/4] drm/amd/display: Add some debug output for VRR BTR.

On 4/17/19 11:51 PM, Mario Kleiner wrote: > Helps with debugging issues with low framerate compensation. > > Signed-off-by: Mario Kleiner > --- This looks like it'd generate a ton of debug output (the flip stuff is already a bit too spammy). But more importantly the DC and module code doesn't

Re: Improvements to VRR below-the-range/low framerate compensation.

On 4/18/19 10:24 AM, Michel Dänzer wrote: > On 2019-04-18 5:51 a.m., Mario Kleiner wrote: >> >> My desired application of VRR for neuroscience/vision research >> is to control the timing of when frames show up onscreen, e.g., >> to show animations at different "unconventional" framerates, >> so

Re: [PATCH] drm: Fix timestamp docs for variable refresh properties.

On 4/18/19 2:01 AM, Mario Kleiner wrote: > As discussed with Nicholas and Daniel Vetter (patchwork > link to discussion below), the VRR timestamping behaviour > produced utterly useless and bogus vblank/pageflip > timestamps. We have found a way to fix this and provide > sane behaviour. > > As of

Re: [PATCH v3 5/5] Patch '5edb0c9b Fix deadlock with display during hanged ring recovery' was accidentaly removed during one of DALs code merges.

On 4/15/19 3:43 PM, Andrey Grodzovsky wrote: > Signed-off-by: Andrey Grodzovsky > Reviewed-by: Nicholas Kazlauskas Nitpicks: Put the current commit message (with the spelling mistake in accidentally fixed) in the body of the commit and give the commit title something a little more

Re: [PATCH 4/4] drm/amd/display: Restore deleted patch to resolve reset deadlock.

On 4/11/19 12:03 PM, Andrey Grodzovsky wrote: > Patch '5edb0c9b Fix deadlock with display during hanged ring recovery' > was accidentaly removed during one of DALs code merges. > > Signed-off-by: Andrey Grodzovsky Reviewed-by: Nicholas Kazlauskas Probably got lost in a refactor. Also, didn't

Re: [PATCH 2/5] drm/amd/display: Prevent vblank irq disable while VRR is active. (v3)

On 3/29/19 8:00 AM, Mario Kleiner wrote: > During VRR mode we can not allow vblank irq dis-/enable > transitions, as an enable after a disable can happen at > an arbitrary time during the video refresh cycle, e.g., > with a high likelyhood inside vblank front-porch. An > enable during front-porch

Re: [PATCH 1/5] drm/amd/display: Update VRR state earlier in atomic_commit_tail.

On 3/29/19 8:00 AM, Mario Kleiner wrote: > We need the VRR active/inactive state info earlier in > the commit sequence, so VRR related setup functions like > amdgpu_dm_handle_vrr_transition() know the final VRR state > when they need to do their hw setup work. > > Split

Re: [PATCH 3/4] drm/amd/display: In VRR mode, do DRM core vblank handling at end of vblank. (v2)

On 3/22/19 4:04 PM, Mario Kleiner wrote: > In VRR mode, proper vblank/pageflip timestamps can only be computed > after the display scanout position has left front-porch. Therefore > delay calls to drm_crtc_handle_vblank(), and thereby calls to > drm_update_vblank_count() and pageflip event

Re: [PATCH 3/4] drm/amd/display: In VRR mode, do DRM core vblank handling at end of vblank.

On 3/21/19 11:38 AM, Wentland, Harry wrote: > > > On 2019-03-21 5:39 a.m., Mario Kleiner wrote: >> On Wed, Mar 20, 2019 at 1:53 PM Kazlauskas, Nicholas >> wrote: >>> >>> On 3/20/19 3:51 AM, Mario Kleiner wrote: >>>> Ok, fixed all the style

Re: [PATCH 1/4] drm/amd/display: Prevent vblank irq disable while VRR is active. (v2)

On 3/20/19 4:12 AM, Mario Kleiner wrote: > During VRR mode we can not allow vblank irq dis-/enable > transitions, as an enable after a disable can happen at > an arbitrary time during the video refresh cycle, e.g., > with a high likelyhood inside vblank front-porch. An > enable during front-porch

Re: [PATCH 3/4] drm/amd/display: In VRR mode, do DRM core vblank handling at end of vblank.

On 3/20/19 3:51 AM, Mario Kleiner wrote: > Ok, fixed all the style issues and ran checkpatch over the patches. Thanks. > > On Tue, Mar 19, 2019 at 2:32 PM Kazlauskas, Nicholas > wrote: >> >> On 3/19/19 9:23 AM, Kazlauskas, Nicholas wrote: >>> On 3/18/19 1:19 PM,

Re: [PATCH 3/4] drm/amd/display: In VRR mode, do DRM core vblank handling at end of vblank.

On 3/19/19 9:23 AM, Kazlauskas, Nicholas wrote: > On 3/18/19 1:19 PM, Mario Kleiner wrote: >> In VRR mode, proper vblank/pageflip timestamps can only be computed >> after the display scanout position has left front-porch. Therefore >> delay calls to drm_crtc_handle_vblank

Re: [PATCH 3/4] drm/amd/display: In VRR mode, do DRM core vblank handling at end of vblank.

On 3/18/19 1:19 PM, Mario Kleiner wrote: > In VRR mode, proper vblank/pageflip timestamps can only be computed > after the display scanout position has left front-porch. Therefore > delay calls to drm_crtc_handle_vblank(), and thereby calls to > drm_update_vblank_count() and pageflip event

Re: [PATCH 4/4] drm/amd/display: Make pageflip event delivery compatible with VRR.

On 3/18/19 1:19 PM, Mario Kleiner wrote: > We want vblank counts and timestamps of flip completion as sent > in pageflip completion events to be consistent with the vblank > count and timestamp of the vblank of flip completion, like in non > VRR mode. > > In VRR mode, drm_update_vblank_count() -

Re: [PATCH 2/4] drm/amd/display: Rework vrr flip throttling for late vblank irq.

On 3/18/19 1:19 PM, Mario Kleiner wrote: > For throttling to work correctly, we always need a baseline vblank > count last_flip_vblank that increments at start of front-porch. > > This is the case for drm_crtc_vblank_count() in non-VRR mode, where > the vblank irq fires at start of front-porch

Re: [PATCH 1/4] drm/amd/display: Prevent vblank irq disable while VRR is active.

On 3/18/19 1:19 PM, Mario Kleiner wrote: > During VRR mode we can not allow vblank irq dis-/enable > transitions, as an enable after a disable can happen at > an arbitrary time during the video refresh cycle, e.g., > with a high likelyhood inside vblank front-porch. An > enable during front-porch

Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output

On 3/14/19 5:50 AM, Daniel Vetter wrote: > On Wed, Mar 13, 2019 at 05:41:52PM +0000, Kazlauskas, Nicholas wrote: >> On 3/13/19 1:33 PM, Michel Dänzer wrote: >>> On 2019-03-13 5:16 p.m., Kazlauskas, Nicholas wrote: >>>> On 3/13/19 11:54 AM, Christian König wrote: >

Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output

On 3/13/19 1:33 PM, Michel Dänzer wrote: > On 2019-03-13 5:16 p.m., Kazlauskas, Nicholas wrote: >> On 3/13/19 11:54 AM, Christian König wrote: >>> Am 13.03.19 um 16:38 schrieb Michel Dänzer: >>>> On 2019-03-13 2:37 p.m., Christian König wrote: >>>>&g

Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output

On 3/13/19 11:54 AM, Christian König wrote: > Am 13.03.19 um 16:38 schrieb Michel Dänzer: >> On 2019-03-13 2:37 p.m., Christian König wrote: >>> Am 13.03.19 um 14:31 schrieb Ville Syrjälä: On Wed, Mar 13, 2019 at 10:35:08AM +0100, Michel Dänzer wrote: > On 2019-03-12 6:15 p.m., Noralf

Re: [PATCH v2 5/5] drm: don't block fb changes for async plane updates

On 3/12/19 2:44 AM, Boris Brezillon wrote: > On Mon, 11 Mar 2019 23:22:03 -0300 > Helen Koike wrote: > >> In the case of a normal sync update, the preparation of framebuffers (be >> it calling drm_atomic_helper_prepare_planes() or doing setups with >> drm_framebuffer_get()) are performed in the

Re: [PATCH 1/5] drm: don't block fb changes for async plane updates

On 3/11/19 6:06 AM, Boris Brezillon wrote: > Hello Nicholas, > > On Mon, 4 Mar 2019 15:46:49 + > "Kazlauskas, Nicholas" wrote: > >> On 3/4/19 9:49 AM, Helen Koike wrote: >>> In the case of a normal sync update, the prepar

  1   2   >