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 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 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
>> 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-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-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-07-11 3:29 a.m., Pekka Paalanen wrote:
> Wait, one can write udev rules for connectors and stuff?
> How? What can they do?
I was using it to generate user-friendly device names for the mst aux
implementation:
https://patchwork.freedesktop.org/patch/315900/?series=63237=2
Leo
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-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-08-01 5:51 a.m., Pekka Paalanen wrote:
> On Tue, 16 Jul 2019 14:59:58 +
> "Li, Sun peng (Leo)" wrote:
>
>> On 2019-07-11 3:29 a.m., Pekka Paalanen wrote:
>>> Wait, one can write udev rules for connectors and stuff?
>>> How? What can they
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
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 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
26 matches
Mail list logo
