On 10/05/2018 12:56 PM, Michel Dänzer wrote:
On 2018-10-05 6:21 p.m., Kazlauskas, Nicholas wrote:
On 10/05/2018 04:10 AM, Pekka Paalanen wrote:
2. User preference
A toggle on the desktop environment's display settings
application to allow or disallow VRR. After all, video mode
On 10/05/2018 04:10 AM, Pekka Paalanen wrote:
Hi,
I have a somewhat of my own view on what would be involved with VRR,
and I'd like to hear what you think of it. Comments inline.
On Tue, 25 Sep 2018 09:51:37 -0400
"Kazlauskas, Nicholas" wrote:
On 09/24/2018 04:26 PM, Ville Syr
On 10/11/2018 04:39 PM, Harry Wentland wrote:
On 2018-10-11 12:39 PM, Nicholas Kazlauskas wrote:
Support for AMDGPU specific FreeSync properties and ioctls are dropped
from amdgpu_dm in favor of supporting drm variable refresh rate
properties.
The drm vrr_capable property is now attached to
On 10/15/2018 09:57 AM, Pekka Paalanen wrote:
On Fri, 12 Oct 2018 08:58:23 -0400
"Kazlauskas, Nicholas" wrote:
On 10/12/2018 07:20 AM, Koenig, Christian wrote:
Am 12.10.2018 um 11:21 schrieb Pekka Paalanen:
On Fri, 12 Oct 2018 07:35:57 +
"Koenig, Christian" wrote:
On 10/12/2018 07:20 AM, Koenig, Christian wrote:
Am 12.10.2018 um 11:21 schrieb Pekka Paalanen:
On Fri, 12 Oct 2018 07:35:57 +
"Koenig, Christian" wrote:
Am 12.10.2018 um 09:23 schrieb Pekka Paalanen:
On Wed, 10 Oct 2018 09:35:50 -0400
"Kazlauskas, Nicholas" wro
On 10/26/18 7:37 AM, Pekka Paalanen wrote:
> On Thu, 11 Oct 2018 12:39:41 -0400
> Nicholas Kazlauskas wrote:
>
>> These include the drm_connector 'vrr_capable' and the drm_crtc
>> 'vrr_enabled' properties.
>>
>> Signed-off-by: Nicholas Kazlauskas
>> ---
>> Documentation/gpu/drm-kms.rst | 7
On 10/29/18 2:03 PM, Ville Syrjälä wrote:
> On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote:
>> On 2018-10-26 7:59 p.m., Ville Syrjälä wrote:
>>> On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nicholas wrote:
>>>> On 10/26/18 10:53 AM, Ville Syrjä
On 11/1/18 6:58 AM, Michel Dänzer wrote:
> On 2018-10-31 6:54 p.m., Kazlauskas, Nicholas wrote:
>> On 10/31/18 12:20 PM, Michel Dänzer wrote:
>>> On 2018-10-31 3:41 p.m., Kazlauskas, Nicholas wrote:
>>>> On 10/31/18 10:12 AM, Michel Dänzer wrote:
>>>>>
On 10/30/18 11:34 AM, Kazlauskas, Nicholas wrote:
> On 10/30/18 5:29 AM, Michel Dänzer wrote:
>> On 2018-10-29 7:03 p.m., Ville Syrjälä wrote:
>>> On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote:
>>>> On 2018-10-26 7:59 p.m., Ville Syrjälä wrote:
>&
On 10/31/18 10:12 AM, Michel Dänzer wrote:
> On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote:
>> On 10/30/18 11:34 AM, Kazlauskas, Nicholas wrote:
>>> On 10/30/18 5:29 AM, Michel Dänzer wrote:
>>>> On 2018-10-29 7:03 p.m., Ville Syrjälä wrote:
>>>>
On 10/31/18 12:20 PM, Michel Dänzer wrote:
> On 2018-10-31 3:41 p.m., Kazlauskas, Nicholas wrote:
>> On 10/31/18 10:12 AM, Michel Dänzer wrote:
>>> On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote:
>>>> On 10/30/18 11:34 AM, Kazlauskas, Nicholas wrote:
>>>
On 10/26/18 10:53 AM, Ville Syrjälä wrote:
> On Fri, Oct 26, 2018 at 02:49:31PM +0000, Kazlauskas, Nicholas wrote:
>> On 10/26/18 7:37 AM, Pekka Paalanen wrote:
>>> On Thu, 11 Oct 2018 12:39:41 -0400
>>> Nicholas Kazlauskas wrote:
>>>
>>>&
On 10/30/18 5:29 AM, Michel Dänzer wrote:
> On 2018-10-29 7:03 p.m., Ville Syrjälä wrote:
>> On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote:
>>> On 2018-10-26 7:59 p.m., Ville Syrjälä wrote:
>>>> On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nic
On 10/26/18 3:13 PM, Manasi Navare wrote:
> On Fri, Oct 26, 2018 at 05:34:15PM +0000, Kazlauskas, Nicholas wrote:
>> On 10/26/18 10:53 AM, Ville Syrjälä wrote:
>>> On Fri, Oct 26, 2018 at 02:49:31PM +, Kazlauskas, Nicholas wrote:
>>>> On 10/26/18 7:37 AM, Pekka Pa
On 11/1/18 1:05 PM, Michel Dänzer wrote:
> On 2018-11-01 3:58 p.m., Kazlauskas, Nicholas wrote:
>> On 11/1/18 6:58 AM, Michel Dänzer wrote:
>>> On 2018-10-31 6:54 p.m., Kazlauskas, Nicholas wrote:
>>>> On 10/31/18 12:20 PM, Michel Dänzer wrote:
>>>>>
On 10/29/18 4:36 AM, Pekka Paalanen wrote:
> On Fri, 26 Oct 2018 17:34:15 +
> "Kazlauskas, Nicholas" wrote:
>
>> On 10/26/18 10:53 AM, Ville Syrjälä wrote:
>>> On Fri, Oct 26, 2018 at 02:49:31PM +, Kazlauskas, Nicholas wrote:
>>>> On 10/26
On 11/7/18 1:10 PM, Rodrigo Vivi wrote:
> On Wed, Nov 07, 2018 at 04:56:00PM +0000, Kazlauskas, Nicholas wrote:
>> On 10/24/18 6:49 PM, Rodrigo Vivi wrote:
>>> On Fri, Oct 12, 2018 at 11:42:32AM -0700, Radhakrishna Sripada wrote:
>>>> At times 12bpc HDMI cannot
On 11/7/18 9:57 AM, Wentland, Harry wrote:
>
>
> On 2018-11-06 3:24 p.m., Nicholas Kazlauskas wrote:
>> These include the drm_connector 'vrr_capable' and the drm_crtc
>> 'vrr_enabled' properties.
>>
>> Signed-off-by: Nicholas Kazlauskas
>> Cc: Harry Wentland
>> Cc: Manasi Navare
>> Cc: Pekka
On 10/24/18 6:49 PM, Rodrigo Vivi wrote:
> On Fri, Oct 12, 2018 at 11:42:32AM -0700, Radhakrishna Sripada wrote:
>> At times 12bpc HDMI cannot be driven due to faulty cables, dongles
>> level shifters etc. To workaround them we may need to drive the output
>> at a lower bpc. Currently the user
On 11/12/18 11:12 AM, Wentland, Harry wrote:
> On 2018-11-08 9:43 a.m., Nicholas Kazlauskas wrote:
>> These include the drm_connector 'vrr_capable' and the drm_crtc
>> 'vrr_enabled' properties.
>>
>> Signed-off-by: Nicholas Kazlauskas
>> Cc: Harry Wentland
>> Cc: Manasi Navare
>> Cc: Pekka
On 10/05/2018 06:10 PM, Manasi Navare wrote:
On Fri, Oct 05, 2018 at 04:39:46PM -0400, Nicholas Kazlauskas wrote:
Modern display hardware is capable of supporting variable refresh rates.
This patch introduces the "vrr_capable" property on the connector to
allow userspace to query support for
On 10/10/2018 03:14 AM, Pekka Paalanen wrote:
On Fri, 5 Oct 2018 12:21:20 -0400
"Kazlauskas, Nicholas" wrote:
On 10/05/2018 04:10 AM, Pekka Paalanen wrote:
Hi,
I have a somewhat of my own view on what would be involved with VRR,
and I'd like to hear what you think of it. Comme
On 09/24/2018 04:26 PM, Ville Syrjälä wrote:
On Mon, Sep 24, 2018 at 03:06:02PM -0400, Kazlauskas, Nicholas wrote:
On 09/24/2018 02:38 PM, Ville Syrjälä wrote:
On Mon, Sep 24, 2018 at 02:15:36PM -0400, Nicholas Kazlauskas wrote:
Variable refresh rate algorithms have typically been enabled
On 09/24/2018 02:38 PM, Ville Syrjälä wrote:
On Mon, Sep 24, 2018 at 02:15:36PM -0400, Nicholas Kazlauskas wrote:
Variable refresh rate algorithms have typically been enabled only
when the display is covered by a single source of content.
This patch introduces a new default CRTC property that
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
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
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
On 09/11/2018 12:31 PM, Ville Syrjälä wrote:
On Tue, Sep 11, 2018 at 07:22:43PM +0300, Ville Syrjälä wrote:
On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote:
Modern monitor hardware is capable of supporting variable refresh rates
and adaptive sync technologies. The
On 09/11/2018 01:56 PM, Ville Syrjälä wrote:
On Tue, Sep 11, 2018 at 01:36:01PM -0400, Kazlauskas, Nicholas wrote:
On 09/11/2018 12:31 PM, Ville Syrjälä wrote:
On Tue, Sep 11, 2018 at 07:22:43PM +0300, Ville Syrjälä wrote:
On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote
On 09/11/2018 01:51 PM, Christian König wrote:
Am 11.09.2018 um 18:13 schrieb Nicholas Kazlauskas:
From: Harry Wentland
Add the ioctl to enable/disable freesync.
Why do we still need this now that we have the DRM CRTC properties?
These patches were already merged into amd-staging-drm-next
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
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
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
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
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
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/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/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
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 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
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
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
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
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() -
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/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
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 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:
>>>&
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 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/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
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
>
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
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
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
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
>
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 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
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/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 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:
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
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:
>
>
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
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
>>
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
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
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/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
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 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
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
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
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
>
>
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
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
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
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
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
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
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
>
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
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:
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
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
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)
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
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-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':
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
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-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
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
(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
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
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
1 - 100 of 143 matches
Mail list logo
