On 2018-10-16 08:33 AM, Daniel Vetter wrote:
> On Mon, Oct 15, 2018 at 09:46:40AM -0400, sunpeng...@amd.com wrote:
>> From: Leo Li
>>
>> This fixes a general protection fault, caused by accessing the contents
>> of a flip_done completion object that has already been freed. It occurs
>> due to
+amdgfx, amdgpu specific patches should go here
On 2018-11-05 05:33 AM, Shaokun Zhang wrote:
> RETIMER_REDRIVER_INFO shows the buffer as a decimal value with a '0x'
> prefix, which is somewhat misleading.
>
> Fix it to print hexadecimal, as was intended.
>
> Fixes: 2f14bc89("drm/amd/display:
On 2018-11-12 10:01 AM, Maarten Lankhorst wrote:
> We already have __drm_atomic_helper_connector_reset() and
> __drm_atomic_helper_plane_reset(), extend this to crtc as well.
>
> Most drivers already have a gpu reset hook, correct it.
> Nouveau already implemented its own
On 2019-01-15 5:42 a.m., Paul Menzel wrote:
> Dear Hersen, dear Leo,
>
>
> Some nitpicks. Could you not put the problem statement in the commit
> message summary, but the solution? For example:
>
>> Fix eDP fast bootup for pre-raven asics
>
> On 01/14/19 23:36, sunpeng...@amd.com wrote:
>>
Reviewed-by: Leo Li
On 2018-12-07 1:14 p.m., Alex Deucher wrote:
> Acked-by: Alex Deucher
> On Fri, Dec 7, 2018 at 10:07 AM Nicholas Kazlauskas
> wrote:
>>
>> [Why]
>> These properties aren't being carried over when the atomic state.
>> This tricks atomic check and commit tail into performing
PM
> *To:* amd-gfx@lists.freedesktop.org
> *Cc:* Li, Sun peng (Leo); Wentland, Harry; Lakha, Bhawanpreet;
> Kazlauskas, Nicholas
> *Subject:* [PATCH] Revert "drm/amd/display: Set RMX_ASPECT as default"
> This reverts commit 91b66c47ba3468f7882ea4a84d5e0e0c186b638f.
>
>
On 2018-12-05 2:59 p.m., Nicholas Kazlauskas wrote:
> [Why]
> Legacy cursor plane updates from drm helpers go through the full
> atomic codepath. A high volume of cursor updates through this slow
> code path can cause subsequent page-flips to skip vblank intervals
> since each individual update
:28 AM
> *To:* amd-gfx@lists.freedesktop.org
> *Cc:* Li, Sun peng (Leo); Wentland, Harry; Kazlauskas, Nicholas
> *Subject:* [PATCH] drm/amd/display: Fix NULL ptr deref for
> commit_planes_to_stream
> [Why]
> With scaling, underscan and abm changes we can end up calling
>
On 2018-11-20 12:17 p.m., Colin King wrote:
> From: Colin Ian King
>
> Currently there are several instances of pointer fs_params being
> dereferenced before fs_params is being null checked. Fix this by
> only dereferencing fs_params after the null check.
>
> Detected by CoverityScan,
On 2018-11-16 2:59 p.m., Bhawanpreet Lakha wrote:
> Before:
> We use drm_match_cea_mode() to get the vic for any mode we
> want to set, most of the time vic will be different for the new mode.
>
> DC uses memcmp to check if timing changed, in this case DC will
> say timing changed and we endup
On 2018-11-22 12:34 p.m., Nicholas Kazlauskas wrote:
> [Why]
> Two non-blocking commits in succession can result in a sequence where
> the same dc->current_state is queried for both commits.
>
> 1. 1st commit -> check -> commit -> swaps atomic state -> queues work
> 2. 2nd commit -> check ->
On 2019-01-10 3:12 p.m., Nicholas Kazlauskas wrote:
> [Why]
> This fixes a stuttering issue that occurs when moving a hardware cursor
> when VRR is enabled.
>
> Previously when VRR is enabled atomic check will grab the connector
> state for every atomic update. This has to lock the connector in
On 2018-12-18 3:33 p.m., Grodzovsky, Andrey wrote:
>
>
> On 12/18/2018 12:09 PM, Kazlauskas, Nicholas wrote:
>> On 12/18/18 10:26 AM, sunpeng...@amd.com wrote:
>>> From: Leo Li
>>>
>>> drm_atomic_helper_check_planes() calls the crtc atomic check helpers. In
>>> an attempt to better align
On 2019-01-28 9:00 a.m., Nicholas Kazlauskas wrote:
> [Why]
> The flip and full structures were allocated but never freed.
>
> [How]
> Free them at the end of the function. There's a small behavioral
> change here with the function returning early if the allocation fails
> but we wouldn't
On 2019-02-20 12:24 a.m., Mathias Fröhlich wrote:
> Hi,
>
> ping?
> ... to the dc folks?
>
> best
> Mathias
Hi Mathias,
Sorry for the wait, change looks good to me.
Reviewed-by: Leo Li
...and merged.
Thanks for cleaning this up.
Leo
>
> On Wednesday, 13 February 2019 21:38:03 CET Alex
On 2019-03-05 9:14 a.m., Nicholas Kazlauskas wrote:
> [Why]
> New DRM versions manage locking for private objects for us, so this
> is no longer needed.
>
> This also prevents a WARN_ON from occurring when the private object is
> duplicated during the forced atomic commit that occurs from the
On 2019-03-11 9:38 a.m., Nicholas Kazlauskas wrote:
> [Why]
> For new DC planes the correct plane address fields are filled based
> on whether the plane had a graphics or video format.
>
> However, when we perform stream and plane updates using DC we only ever
> fill in the graphics format
On 2019-04-12 1:30 p.m., Ville Syrjälä wrote:
> On Fri, Apr 12, 2019 at 12:05:29PM -0400, sunpeng...@amd.com wrote:
>> From: Leo Li
>>
>> Hi all,
>>
>> This is a follup to this change made by Ville to add MST aux nodes:
>>
>> Hmm. My MST-foo is admittedly weak so I'm not sure. A quick trawl through
>> the spec didn't provide any solid explanations either :( However eg.
>> "Figure 2-83: Example Multi-function MST Branch-Sink Device Enumeration"
>> in the DP 1.4 spec does appear to show kind of virtual DPCD thing
On 2019-04-16 6:16 p.m., Lyude Paul wrote:
> Sorry for the slow response, I've been really busy ;_;
No worries :)
>
> On Fri, 2019-04-12 at 12:05 -0400, sunpeng...@amd.com wrote:
>> From: Leo Li
>>
>> In preparation for adding aux devices for DP MST:
>>
>> 1. A non-cyclic idr is used for
On 2019-05-16 3:54 p.m., Lyude Paul wrote:
> [CAUTION: External Email]
>
> Hi, could we (and for future versions of this series and others) get a respin
> of this that's actually rebased against drm-tip? That is the defacto standard
> branch to do development on, and otherwise anyone trying to
On 2019-06-04 3:21 p.m., Nicholas Kazlauskas wrote:
> [Why]
> Unlike our regular connectors, MST connectors don't start off with
> an initial connector state. This causes a NULL pointer dereference to
> occur when attaching the bpc property since it tries to modify the
> connector state.
>
> We
On 2019-06-03 3:28 p.m., Lyude Paul wrote:
>> I'm reproducing this just by reloading i915 on a machine with some MST
>> displays connected. I uploaded a copy of the script that I use to do this
>> here:
>>
>> https://people.freedesktop.org/~lyudess/archive/06-03-2019/unloadgpumod.sh
>
Hey, sorry for my late response!
On 2019-05-16 5:40 p.m., Lyude Paul wrote:
>>if (old_pdt != port->pdt && !port->input) {
>> @@ -1220,6 +1268,8 @@ static void drm_dp_add_port(struct drm_dp_mst_branch
>> *mstb,
>>drm_connector_set_tile_property(port->connector);
On 2019-07-04 3:33 p.m., Ville Syrjälä wrote:
> On Thu, Jul 04, 2019 at 03:05:12PM -0400, sunpeng...@amd.com wrote:
>> From: Leo Li
>>
>> This can be used to create more descriptive symlinks for MST aux
>> devices. Consider the following udev rule:
>>
>> SUBSYSTEM=="drm_dp_aux_dev",
Sorry for the late response! just jumping back on this now.
On 2019-05-16 5:40 p.m., Lyude Paul wrote:
> [CAUTION: External Email]
>
> So a couple of things:
>
> On Thu, 2019-05-16 at 11:17 -0400, sunpeng...@amd.com wrote:
>> From: Ville Syrjälä
>>
>> All available downstream ports - physical
On 2019-07-05 4:41 p.m., Alex Deucher wrote:
> Need to add appropriate ifdef.
>
Acked-by: Leo Li
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/nv.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c
On 2019-04-24 1:26 p.m., Lyude Paul wrote:
> Closer, but are we sure we want to use the MST prop path for this? Why not add
> a sysfs attribute with the corresponding DRM connector name instead since the
> connector itself will have a path property. That way we can associate aux
> devices for
On 2019-03-22 9:59 a.m., Nicholas Kazlauskas wrote:
> The brace initialization used here generates warnings on some
> compilers. For example, on GCC 4.9:
>
> [...] In function ‘dm_determine_update_type_for_commit’:
> [...] error: missing braces around initializer [-Werror=missing-braces]
>
On 2019-03-22 10:11 a.m., Nicholas Kazlauskas wrote:
> [Why]
> DC provides a few visual confirmation debug options that can be
> dynamically changed at runtime to help debug surface programming issues
> but we don't have any way to access it from userspace.
>
> [How]
> Add the
On 2019-03-25 3:27 p.m., Nicholas Kazlauskas wrote:
> The extra ; in the macro definition creates an empty statement
> preventing any variable declarations from occuring after
> any use of to_dm_plane_state(...).
>
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Leo Li
> ---
>
>>> - if (adev->smu.ppt_funcs->get_current_power_state)
>>> + if (adev->smu.ppt_funcs && adev->smu.ppt_funcs-
>>> get_current_power_state)
>>
>> For consistency, I think we probably want something like:
>> if (is_support_sw_smu(adev) && adev->smu.ppt_funcs-
>>> get_current_power_state)
Reviewed-by: Leo Li
Thanks!
On 2019-08-21 12:57 p.m., Nicholas Kazlauskas wrote:
> [Why]
> The only place where state->max_bpc is updated on the connector is
> at the start of atomic check during drm_atomic_connector_check. It
> isn't updated when adding the connectors to the atomic state after
On 2019-08-20 5:02 p.m., Lyude Paul wrote:
> [Added Leo Li here, since they did the auxdev work that introduced these
> functions]
>
> Since it seems we'll actually be doing remote DPCD read/writes in DRM drivers
> and not just from auxdev, maybe we should combine drm_dp_dpcd_read() with
>
On 2019-09-13 8:08 a.m., Christian König wrote:
> The placement is something TTM/BO internal and the RAS code should
> avoid touching that directly.
>
> Add a helper to create a BO at a fixed location and use that instead.
>
> Signed-off-by: Christian König
> ---
>
Looks like the subject is wrong for this and patch 20:
s/3.4/3.2/
Will modify before merge.
Leo
On 2019-09-10 9:54 a.m., sunpeng...@amd.com wrote:
> From: Aric Cyr
>
> Signed-off-by: Aric Cyr
> Acked-by: Leo Li
> ---
> drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
> 1 file changed, 1
On 2019-07-10 6:50 p.m., Lyude Paul wrote:
> gah. So, I was originally going to ask "why didn't we add the connector name
> into this?", but then I realized we're doing the right thing already and just
> doing card%d-%s % (card_number, path_prop). Which means we probably really
> don't
> want
On 2019-07-18 10:49 a.m., Michel Dänzer wrote:
> On 2019-07-15 11:19 p.m., sunpeng...@amd.com wrote:
>> From: Eric Yang
>>
>> [Why]
>> For better readability and reusability
>>
>> [How]
>> Move snippets of BW calculation code into helpers.
>>
>> Signed-off-by: Eric Yang
>> Reviewed-by: Fatemeh
On 2019-07-12 4:15 p.m., Ville Syrjälä wrote:
> On Fri, Jul 12, 2019 at 11:05:59PM +0300, Ville Syrjälä wrote:
>> On Fri, Jul 12, 2019 at 03:48:53PM -0400, Lyude Paul wrote:
>>> BTW, I just tried these patches on my T450s (using i915) and I'm seeing some
>>> kernel warnings with them when adding
On 2019-07-24 4:05 p.m., Kazlauskas, Nicholas wrote:
> 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:
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 conversion from enumeration type 'enum smu_clk_type'
>> to
On 2019-07-25 12:14 p.m., Kazlauskas, Nicholas wrote:
> 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 w
Hi Lyude, sorry - just realized I forgot to CC you on this series! Let
me know if I should resend them.
Adding some additional reviewers as well.
Thanks,
Leo
On 2019-07-04 3:05 p.m., sunpeng...@amd.com wrote:
> From: Leo Li
>
> Hi all,
>
> Here's the second revision of patches to enable mst
On 2019-11-05 2:01 p.m., sunpeng...@amd.com wrote:
> From: Leo Li
>
> [Why]
>
> On DCN hardware, the crtc_high_irq handler makes vupdate_high_irq
> handler redundant.
>
> All the vupdate handler does is handle vblank events, and update vrr
> for DCE hw (excluding VEGA, more on that later).
On 2019-11-05 11:15 a.m., Kazlauskas, Nicholas wrote:
> On 2019-11-05 10:34 a.m., sunpeng...@amd.com wrote:
>> From: Leo Li
>>
>> [Why]
>>
>> For DCN hardware, the crtc_high_irq handler is assigned to the vstartup
>> interrupt. This is different from DCE, which has it assigned to vblank
>>
On 2019-11-05 11:16 a.m., Kazlauskas, Nicholas wrote:
> On 2019-11-05 10:58 a.m., sunpeng...@amd.com wrote:
>> From: Leo Li
>>
>> [Why]
>>
>> On DCN hardware, the crtc_high_irq handler makes vupdate_high_irq
>> handler redundant.
>>
>> All the vupdate handler does is handle vblank events, and
Hi Zheng,
Harry's previous comment about the superfluous REG_READ()s is still unaddressed.
Once that's fixed, I can give my r-b.
Thanks,
Leo
On 2019-10-28 5:32 a.m., zhengbin (A) wrote:
> ping
>
> On 2019/10/9 14:25, zhengbin wrote:
>> zhengbin (3):
>> drm/amd/display: Remove set but not
On 2019-10-23 11:23 a.m., Michel Dänzer wrote:
> On 2019-10-17 9:13 p.m., sunpeng...@amd.com wrote:
>> From: Aidan Yang
>>
>> [why]
>> There's a use case for inverted gamma
>> and it's been confirmed that negative slopes are ok.
>>
>> [how]
>> Remove code for blocking non-monotonically
On 2019-10-23 10:19 a.m., Lukáš Krejčí wrote:
> On Mon, 2019-10-21 at 15:44 -0400, sunpeng...@amd.com wrote:
>> From: Leo Li
>>
>> [Why]
>>
>> Some LED panel drivers might not like fractional PWM. In such cases,
>> backlight flickering may be observed.
>>
>> [How]
>>
>> Add a DC feature mask to
This has already been fixed here:
https://patchwork.freedesktop.org/patch/336195/
Should be mirrored on Alex's tree soon.
Thanks,
Leo
On 2019-10-17 2:19 a.m., Chen Wandun wrote:
> From: Chenwandun
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:1913:48:
> error: struct
Thanks for the detailed notes! See reply inline.
On 2019-10-15 4:03 p.m., Lukáš Krejčí wrote:
> [Why]
> Having the rounding of the backlight value restored to the way it was
> seemingly gets rid of backlight flickering on certain Stoney Ridge
> laptops.
>
> [How]
> Rescale the backlight level
On 2019-10-11 12:26 p.m., Nicholas Kazlauskas wrote:
> [Why]
> We're leaking memory by not freeing the gamma used to calculate the
> transfer function for legacy gamma.
>
> [How]
> Release the gamma after we're done with it.
>
> Cc: Philip Yang
> Cc: Harry Wentland
> Cc: Bhawanpreet Lakha
>
52 matches
Mail list logo
