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 seamless
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 th
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 on
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 c103f8583
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
[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
> ;
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 kerne
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 a
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, followi
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
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 scanout+d
*From:* amd-gfx 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
; Kazla
On 2021-01-04 4:08 p.m., Aurabindo Pillai wrote:
[Why&How]
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 valu
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 Shashank's
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 blob
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:
>
> SUBSYSTE
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
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 descriptive
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
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 i'm
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
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 wr
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 exactly
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 one
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
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
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
>> trans
On 1/30/19 6:02 AM, Daniel Vetter wrote:
> On Wed, Jan 30, 2019 at 11:42 AM Daniel Vetter wrote:
>>
>> On Thu, Nov 8, 2018 at 3:44 PM Nicholas Kazlauskas
>> wrote:
>>>
>>> This patch introduces the 'vrr_enabled' CRTC property to allow
>>> dynamic control over variable refresh rate support for a C
On 1/30/19 11:30 AM, Daniel Vetter wrote:
> Yes it's inconsitent with vrr_capable, but this is the actual uapi as
> exercise by igt.
>
> Fixes: ab7a664f7a2d ("drm: Document variable refresh properties")
> Cc: Nicholas Kazlauskas
> Cc: Harry Wentland
> Cc: Pekka Paalanen
> Cc: Alex Deucher
> Si
On 1/30/19 11:30 AM, Daniel Vetter wrote:
> .. next to all the other sink helpers. The rect library is more used
> for handling plane clipping, so belongs to those imo.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Nicholas Kazlauskas
Looks better than being sandwiched between the HDMI helpers
On 1/30/19 11:30 AM, Daniel Vetter wrote:
> It only talks about crtc, brings up intel as an exampel and I think is
nit: Should be "example".
> more misleading than useful really. Plus we have lots of discussion
> about how your standard kms driver should be initialized/cleaned up,
> so maybe bett
On 1/30/19 4:02 PM, Daniel Vetter wrote:
> On Wed, Jan 30, 2019 at 05:33:00PM +0000, Kazlauskas, Nicholas wrote:
>> On 1/30/19 11:30 AM, Daniel Vetter wrote:
>>> It only talks about crtc, brings up intel as an exampel and I think is
>>
>> nit: Should be "ex
On 2/9/19 1:52 AM, Mario Kleiner wrote:
> In VRR mode, keep track of the vblank count of the last
> completed pageflip in amdgpu_crtc->last_flip_vblank, as
> recorded in the pageflip completion handler after each
> completed flip.
>
> Use that count to prevent mmio programming a new pageflip
> wit
On 2/11/19 3:35 AM, Daniel Vetter wrote:
> On Mon, Feb 11, 2019 at 04:22:24AM +0100, Mario Kleiner wrote:
>> The pageflip completion timestamps transmitted to userspace
>> via pageflip completion events are supposed to describe the
>> time at which the first pixel of the new post-pageflip scanout
>
On 2/11/19 10:01 AM, Michel Dänzer wrote:
> On 2019-02-09 7:52 a.m., Mario Kleiner wrote:
>> In VRR mode, keep track of the vblank count of the last
>> completed pageflip in amdgpu_crtc->last_flip_vblank, as
>> recorded in the pageflip completion handler after each
>> completed flip.
>>
>> Use that
On 2/13/19 4:50 AM, Daniel Vetter wrote:
> On Tue, Feb 12, 2019 at 10:32:31PM +0100, Mario Kleiner wrote:
>> On Mon, Feb 11, 2019 at 6:04 PM Daniel Vetter wrote:
>>>
>>> On Mon, Feb 11, 2019 at 4:01 PM Kazlauskas, Nicholas
>>> wrote:
>>>>
>&g
On 2/13/19 10:14 AM, Daniel Vetter wrote:
> On Wed, Feb 13, 2019 at 3:33 PM Kazlauskas, Nicholas
> wrote:
>>
>> On 2/13/19 4:50 AM, Daniel Vetter wrote:
>>> On Tue, Feb 12, 2019 at 10:32:31PM +0100, Mario Kleiner wrote:
>>>> On Mon, Feb 11, 2019 at 6:04 PM D
On 2/13/19 1:10 PM, Mario Kleiner wrote:
> On Wed, Feb 13, 2019 at 5:03 PM Daniel Vetter wrote:
>>
>> On Wed, Feb 13, 2019 at 4:46 PM Kazlauskas, Nicholas
>> wrote:
>>>
>>> On 2/13/19 10:14 AM, Daniel Vetter wrote:
>>>> On Wed, Feb 1
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 Da
On 12/24/18 7:15 AM, Daniel Vetter wrote:
> On Fri, Dec 21, 2018 at 09:33:24AM -0500, Nicholas Kazlauskas wrote:
>> The behavior of drm_atomic_helper_cleanup_planes differs depending on
>> whether the commit was an asynchronous update or not.
>>
>> For a typical (non-async) atomic commit prepare_fb
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 fun
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 old_state.
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 b
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
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 n
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 Trøn
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
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:
>>> + if (crc->opened) {
>>> + spin_lock_irq(&crc->lock);
>>> + crc->opened = false;
>>> + spin_unlock_irq(&crc->lock);
>>> + }
>
> Either you don't need a lock to look at -&g
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 rec
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:
>
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 w
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 and
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() - a
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 delivery
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(),
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,
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 w
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
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 delivery
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 update_freesync_state_on_st
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 w
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
> Sign
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 co
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: Harr
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]
>
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 and
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) wit
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
&g
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|
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 plane")
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
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 pageflip
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 to
iled_block (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:
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 implementatio
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':
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c
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 Bergm
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 input
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 D
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 are
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 modese
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
>
> Signed-off-
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 to
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 a
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:*
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 enough
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 amdgpu_dm_atomic_commit_t
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 seq
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. Esse
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
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 path
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
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 [-Werror=m
madman.
Any help on where to start, 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., Kazlauska
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 3:12
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
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 no
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
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: Bhanuprakas
1 - 100 of 143 matches
Mail list logo
