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

2021-02-22 Thread Kazlauskas, Nicholas
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 AUTOSEL 5.4 006/130] drm/amd/display: Do not silently accept DCC for multiplane formats.

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

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

2020-10-26 Thread Kazlauskas, Nicholas
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 v2 0/4] Enlarge tracepoints in the display component

2020-09-16 Thread Kazlauskas, Nicholas
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 1/4] drm/amd/display: Rework registers tracepoint

2020-09-11 Thread Kazlauskas, Nicholas
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

2020-09-11 Thread Kazlauskas, Nicholas
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 v2] drm/amd/display: use correct scale for actual_brightness

2020-08-18 Thread Kazlauskas, Nicholas
No objections from my side - and thanks for addressing my feedback. Regards, Nicholas Kazlauskas On 2020-08-18 12:15 p.m., Alex Deucher wrote: Applied. Thanks! Alex On Mon, Aug 17, 2020 at 1:59 PM Alex Deucher wrote: On Mon, Aug 17, 2020 at 3:09 AM Alexander Monakov wrote: Ping.

Re: [PATCH] drm/amd/display: use correct scale for actual_brightness

2020-08-04 Thread Kazlauskas, Nicholas
On 2020-08-04 12:28 p.m., Alexander Monakov wrote: On Tue, 4 Aug 2020, Kazlauskas, Nicholas wrote: This is a cleaner change the other proposed patch since it doesn't need to Can you give a URL to the other patch please? Sorry, replied to the wrong email by accident here. The other

Re: [PATCH] drm/amd/display: use correct scale for actual_brightness

2020-08-04 Thread Kazlauskas, Nicholas
On 2020-08-03 4:02 p.m., Alexander Monakov wrote: Documentation for sysfs backlight level interface requires that values in both 'brightness' and 'actual_brightness' files are interpreted to be in range from 0 to the value given in the 'max_brightness' file. With amdgpu, max_brightness gives

Re: [PATCH] drm/amd/display: use correct scale for actual_brightness

2020-08-04 Thread Kazlauskas, Nicholas
This is a cleaner change the other proposed patch since it doesn't need to modify the exist conversion functions but I'd be worried about broken userspace relying on 0-255 as the only acceptable range. Not an expert on existing implementations to point out a specific one though. Regards,

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

2020-07-29 Thread Kazlauskas, Nicholas
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

2020-07-28 Thread Kazlauskas, Nicholas
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

2020-07-27 Thread Kazlauskas, Nicholas
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

2020-07-27 Thread Kazlauskas, Nicholas
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

2020-07-27 Thread Kazlauskas, Nicholas
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

2020-07-23 Thread Kazlauskas, Nicholas
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/amd/display: add dmcub check on RENOIR

2020-07-08 Thread Kazlauskas, Nicholas
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: [RFC 16/17] drm/amdgpu: gpu recovery does full modesets

2020-05-12 Thread Kazlauskas, Nicholas
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] [v2] amdgpu: fix gcc-4.8 build warnings

2020-04-29 Thread Kazlauskas, Nicholas
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 3/5] drm/amd: fix fb references in async update

2019-03-04 Thread Kazlauskas, Nicholas
On 3/4/19 9:49 AM, Helen Koike wrote: > Async update callbacks are expected to set the old_fb in the new_state > so prepare/cleanup framebuffers are balanced. > > Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new > fb and put the old fb) is not required, as it's taken care

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

2019-03-04 Thread Kazlauskas, Nicholas
On 3/4/19 9:49 AM, 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 new_state and the respective > cleanups are performed in the

Re: linux-next: build failure after merge of the drm-misc tree

2019-01-08 Thread Kazlauskas, Nicholas
On 1/8/19 3:37 AM, Daniel Vetter wrote: > On Tue, Jan 08, 2019 at 11:12:41AM +1100, Stephen Rothwell wrote: >> Hi all, >> >> After merging the drm-misc tree, today's linux-next build (x86_64 >> allmodconfig) failed like this: >> >> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In

Re: [PATCH] drm: add capability DRM_CAP_ASYNC_UPDATE

2018-12-20 Thread Kazlauskas, Nicholas
On 12/20/18 12:09 PM, Daniel Vetter wrote: > On Thu, Dec 20, 2018 at 6:03 PM Alex Deucher wrote: >> >> + Harry >> >> On Thu, Dec 20, 2018 at 11:54 AM Daniel Vetter wrote: >>> >>> On Thu, Dec 20, 2018 at 5:40 PM Alex Deucher wrote: + Nicholas On Thu, Dec 20, 2018 at 5:47 AM