perly after throttling (see
perf_adjust_freq_unthr_events()).
> Otherwise, perhaps this suggests it deserves to be named a little more
> specifically for clarity, maybe PERF_CAP_SAMPLING_EVENTS?
Seems to me, the naming is not critical. If without setting the
PERF_PMU_CAP_SAMPLING flag, AUX events might lose chance to be
re-enabled after throttling.
Thanks,
Leo
oresight_is_percpu_sink(sink))
+ event->pmu.capabilities = PERF_PMU_CAP_SAMPLING;
+ else
+ event->pmu.capabilities &= ~PERF_PMU_CAP_SAMPLING;
+
Thanks,
Leo
linux/v6.15-rc1/source/drivers/gpu/drm/drm_atomic_uapi.c#L1081)
But IIUC, the desired behavior is actually:
* For PRIMARY planes
* Allow modifying of properties fb_id, in_fence_fd, and fb_damage_clips
* Allow setting same value for all other properties
* For OVERLAY and CURSOR pl
On 2025-07-22 07:21, Thadeu Lima de Souza Cascardo wrote:
> On Fri, Jul 18, 2025 at 07:00:39PM -0400, Alex Deucher wrote:
>> On Fri, Jul 18, 2025 at 6:01 PM Leo Li wrote:
>>>
>>>
>>>
>>> On 2025-07-18 17:33, Alex Deucher wrote:
>&
On 2025-07-18 17:33, Alex Deucher wrote:
> On Fri, Jul 18, 2025 at 5:02 PM Leo Li wrote:
>>
>>
>>
>> On 2025-07-18 16:07, Alex Deucher wrote:
>>> On Fri, Jul 18, 2025 at 1:57 PM Brian Geffon wrote:
>>>>
>>>> On Thu, Jul 17, 2025 at
isplay buffers need to be
>>>>>>> in GTT or VRAM, but not both). Raven and newer don't have this
>>>>>>> limitation and we tested raven pretty extensively at the time.
>>>>>>
>>>>>> Thanks for taking the time t
Hi Jani,
On Thu, Mar 13, 2025 at 6:48 PM Jani Nikula wrote:
>
> On Thu, 13 Mar 2025, "Yo-Jung (Leo) Lin" wrote:
> > The header self-contained tests in drm may leave .hdrtest files in
> > include/drm/ and drivers/gpu/drm/. Omit them by adding .gitignore
>
> T
cmd if
should_use_dmub_lock returns true.
This has been the case since dmub support has been added for PSR1.
This bug has landed on stable trees. Any chance for a review here?
Thanks.
Cascardo.
Thanks for the ping and fix!
Reviewed-by: Leo Li
Fix this by checking for dmub_srv
The header self-contained tests in drm may leave .hdrtest files in
include/drm/ and drivers/gpu/drm/. Omit them by adding .gitignore
Signed-off-by: Yo-Jung (Leo) Lin
---
drivers/gpu/drm/.gitignore | 1 +
include/drm/.gitignore | 1 +
2 files changed, 2 insertions(+)
create mode 100644
drm_dbg(dev, "3D LUT is not supported by hardware\n");
+ return 0;
Should an error be returned instead?
-Leo
+ }
+
+ drm_dbg(dev, "3D LUT colorop with ID: %d\n", colorop->base.id);
+
RVE_SRGB_EOTF)
Should it be || instead of &&? It sounds to me that this should error if either
condition is the case.
It's not critical, since they look to be dropped as more subtypes are introduced
in later patches. Just curious if the && was intentional.
>input_csc_color_matrix.enable_adjustment = false;
+ } else
+ drm_warn(dev, "blob->length (%lu) isn't equal to
drm_color_ctm_3x4 (%zu)\n",
+ blob->length, sizeof(struct
drm_color_ctm_
tf->tf = default_tf;
Not sure if IIUC --the shaper in HW can either be a custom 1D LUT, or a
predefined 1D CURVE, but cannot be both enabled at the same time, right?
If so, what would be the expected outcome if both LUT and CURVE colorops are not
in bypass? It looks from
_CURVE_BT2020_INV_OETF);
Should the PQ_125 bit + the changes for __set_colorop_1d_curve_blend_tf_lut() be
moved to patch 30/45 "Enable support for PQ 125 EOTF and Inverse"?
- Leo
#define MAX_COLOR_PIPELINE_OPS 10
if we simply replace
MAX_SURFACE_NUM with MAX_SURFACES = 3, will we still need these explicit fails?
FWICT, `dc_state_add_plane` should fail for us.
Thanks,
Leo
ret = drm_atomic_add_affected_planes(state, crtc);
if (ret)
goto fail;
@@ -11769,8 +11
On 2024-10-23 09:53, Melissa Wen wrote:
There are two events to trace the beginning and the end of
amdgpu_dm_atomic_commit_tail, but only the one ate the beginning was
placed. Place amdgpu_dm_atomic_commit_tail_finish tracepoint at the end
than.
Signed-off-by: Melissa Wen
Reviewed-by: Leo
Hi Mikhail,
Can you give this patch a try to see if it helps?
https://gist.github.com/leeonadoh/3271e90ec95d768424c572c970ada743
Thanks,
Leo
On 2024-09-10 11:47, Leo Li wrote:
On 2024-09-08 19:30, Mikhail Gavrilov wrote:
I have done additional tests:
1. The computer does not hang with
update state. However, a KMS cursor
update will only include the cursor plane. It's likely that amdgpu_dm only adds
the dedicated cursor plane to DC's update state, leaving the game's plane out.
The fix isn't exactly trivial. If I don't get anywhere before the fixes window,
I'll send out a revert.
Cheers,
Leo
anes being used on my setup.
Third, in case these two issues are related, can you give the attached patch on
this issue thread a try as well?
https://gitlab.freedesktop.org/drm/amd/-/issues/3569#note_2558359
Thanks,
Leo
On 2024-09-05 02:06, Mikhail Gavrilov wrote:
On Thu, Sep 5, 2024 at 4:06
On 2024-09-04 18:21, Mikhail Gavrilov wrote:
On Wed, Sep 4, 2024 at 4:15 AM Leo Li wrote:
Hi Mike,
Super sorry for the ridiculous wait. Your first two emails slipped by my inbox,
which is really silly, given I'm first in the to field...
Thanks for bisecting and finding a free ga
le-0002-revert-drm-amd-display-introduce-overlay-cursor-mode-patch
Thanks,
Leo
, and I wonder
if it's really necessary. I'll go and find out.
Thanks,
Leo
Signed-off-by: Sebastian Wick
For anyone who hasn't seen it, there has been a bunch of discussions that have
transpired on this topic and what to do about it on [1] as well as some other
linked places o
o bit mask
"Require low latency" PSR should be disabled.
When the property is restored to an empty bit mask ABM and PSR
can be enabled again.
Signed-off-by: Mario Limonciello
Reviewed-by: Leo Li
Thanks!
---
v3->v4:
* Fix enabling again after disable (Xaver)
---
dri
o bit mask
"Require low latency" PSR should be disabled.
When the property is restored to an empty bit mask the previous
value of ABM and pSR will be restored.
Signed-off-by: Mario Limonciello
Reviewed-by: Leo Li
Thanks!
---
v2->v3:
* Use `disallow_edp_enter_psr` i
psr_state = igt_amd_read_psr_state(data->fd, output->name);
igt_assert_f(psr_state == PSR_STATE3,
"Panel not in PSR after clearing power saving policy\n");
Thanks,
Leo
+
+ igt_remove_fb(data->fd, &ref_fb);
+ igt_remove_fb(data->fd, &
ose it should fail given that we've set REQUIRE_COLOR_ACCURACY. Though I'm
not sure why we can't keep target = 3.
Thanks,
Leo
+ r = set_abm_level(data, output, target);
+ igt_assert_eq(r, -1);
+
+ r = clear_power_saving_policy(dat
experience intended by the compositor.
Signed-off-by: Mario Limonciello
Acked-by: Leo Li
Thanks!
---
drivers/gpu/drm/drm_connector.c | 46 +
include/drm/drm_connector.h | 2 ++
include/drm/drm_mode_config.h | 5
include/uapi/drm/drm_mode.h
c_state->stream);
+ else if (!dm_old_conn_state->psr_forbidden &&
dm_new_conn_state->psr_forbidden)
+ amdgpu_dm_psr_enable(dm_new_crtc_state->stream);
+
dm_update_crtc_state() can be called as part of atomic check, so we should not
do any hw programmi
On 2024-05-21 13:32, Mario Limonciello wrote:
On 5/21/2024 12:27, Leo Li wrote:
On 2024-05-21 12:21, Mario Limonciello wrote:
On 5/21/2024 11:14, Xaver Hugl wrote:
Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello
:
On 5/21/2024 08:43, Simon Ser wrote:
This makes sense to
ration in addition to accuracy is latency.
I suppose a compositor may want to disable features such as PSR for use-cases
requiring low latency. Touch and stylus input are some examples.
I wonder if flags would work better than enums? A compositor can set something
like `REQUIRE_ACCURACY & REQUIRE_LOW_LATENCY`, for example.
- Leo
Would be nice to add documentation for the property in the "standard
connector properties" section.
Ack.
On 2024-04-16 10:10, Harry Wentland wrote:
On 2024-04-16 04:01, Pekka Paalanen wrote:
On Mon, 15 Apr 2024 18:33:39 -0400
Leo Li wrote:
On 2024-04-15 04:19, Pekka Paalanen wrote:
On Fri, 12 Apr 2024 16:14:28 -0400
Leo Li wrote:
On 2024-04-12 11:31, Alex Deucher wrote:
On Fri
On 2024-04-15 04:19, Pekka Paalanen wrote:
On Fri, 12 Apr 2024 16:14:28 -0400
Leo Li wrote:
On 2024-04-12 11:31, Alex Deucher wrote:
On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen
wrote:
On Fri, 12 Apr 2024 10:28:52 -0400
Leo Li wrote:
On 2024-04-12 04:03, Pekka Paalanen wrote
On 2024-04-12 11:31, Alex Deucher wrote:
On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen
wrote:
On Fri, 12 Apr 2024 10:28:52 -0400
Leo Li wrote:
On 2024-04-12 04:03, Pekka Paalanen wrote:
On Thu, 11 Apr 2024 16:33:57 -0400
Leo Li wrote:
...
That begs the question of what can be
On 2024-04-12 04:03, Pekka Paalanen wrote:
On Thu, 11 Apr 2024 16:33:57 -0400
Leo Li wrote:
On 2024-04-04 10:22, Marius Vlad wrote:
On Thu, Apr 04, 2024 at 09:59:03AM -0400, Harry Wentland wrote:
Hi all,
On 2024-04-04 06:24, Pekka Paalanen wrote:
On Wed, 3 Apr 2024 17:32:46 -0400
On 2024-04-04 10:22, Marius Vlad wrote:
On Thu, Apr 04, 2024 at 09:59:03AM -0400, Harry Wentland wrote:
Hi all,
On 2024-04-04 06:24, Pekka Paalanen wrote:
On Wed, 3 Apr 2024 17:32:46 -0400
Leo Li wrote:
On 2024-03-28 10:33, Pekka Paalanen wrote:
On Fri, 15 Mar 2024 13:09:56 -0400
On 2024-03-28 10:33, Pekka Paalanen wrote:
On Fri, 15 Mar 2024 13:09:56 -0400
wrote:
From: Leo Li
These patches aim to make the amdgpgu KMS driver play nicer with compositors
when building multi-plane scanout configurations. They do so by:
1. Making cursor behavior more sensible.
2
On 2024-03-28 11:52, Harry Wentland wrote:
On 2024-03-28 11:48, Robert Mader wrote:
Hi,
On 15.03.24 18:09, sunpeng...@amd.com wrote:
From: Leo Li
[Why]
DCN is the display hardware for amdgpu. DRM planes are backed by DCN
hardware pipes, which carry pixel data from one end (memory), to
Reviewed-by: Leo Liu
On 2023-07-17 23:20, sguttula wrote:
This patch will enable VCN FW workaround using
DRM KEY INJECT WORKAROUND method,
which is helping in fixing the secure playback.
Signed-off-by: sguttula
---
Changes in v2:
-updated commit message as per veera's feedback
Chang
Reviewed-by: Leo Liu
On 2023-07-17 13:27, sguttula wrote:
This patch will enable secure decode playback on VCN4_0_2
Signed-off-by: sguttula
---
Changes in v2:
-updated commit message only enabling for VCN402
-updated the logic as per Leo's feedback
---
drivers/gpu/drm/amd/amdgpu/vcn
/7414
- Leo
On 2/9/23 04:27, Mikhail Gavrilov wrote:
Harry, please don't ignore me.
This issue still happens in 6.1 and 6.2
Leo you are the author of the problematic commit please don't stand aside.
Really nobody is interested in clean logs without warnings and errors?
I am 100% sure that
: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Reviewed-by: Leo Li
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff
...@amd.com
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Reviewed-by: Leo Li
---
.../drm/amd/display/dc/core/dc_hw_sequencer.c | 38 -
drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h | 54 +++
2 files changed, 56 insertions
Secure part requires PSP load VCN boot sequence which is with indirect sram
mode.
Regards,
Leo
From: Alex Deucher
Sent: January 16, 2023 4:50 PM
To: Guilherme G. Piccoli
Cc: amd-...@lists.freedesktop.org ; Jiang, Sonny
; ker...@gpiccoli.net ; Pan, Xinhui
of the condition?
if (!(link->connector_signal & SIGNAL_TYPE_EDP))
return true;
Thanks,
Leo
+ return true;
+
+ pic_height = stream->timing.v_addressable +
+ stream->timing.v_border_top + stream->timing.v_border_bottom;
+ slice_height = pic_height / st
ts in fill_dc_dirty_rects().
Signed-off-by: Hamza Mahfooz
Thanks for the patch, it LGTM.
Reviewed-by: Leo Li
It would be good to add an IGT case to cover combinations of MPO &
damage clip commits. Perhaps something that covers the usecase of moving
a MPO video, while desktop UI updates. We'd
to
dc_dirty_rects. Otherwise, fallback to old FFU logic.
With MPO, the damage clips are more interesting, since the entire
plane's bounding box can be moved. I wonder if that is reflected in
DRM's damage clips. Do you know if a plane bb change will be reflected
in drm_pla
t are only useful for debugging PSR
(and confusing otherwise). So, we can instead limit the filling of dirty
rectangles to only when PSR is enabled.
Signed-off-by: Hamza Mahfooz
Reviewed-by: Leo Li
Thanks
---
v2: give a more concrete reason.
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.
gets data into the cache not also the DRAM?
Otherwise a read back would get the updated data too.
- Leo
> dma_unmap_single() invalidates the cache, and boom, the data is gone and
> you read back the previous content of the buffer that was cleaned out to
> DRAM beforehand.
>
> Robin.
>
> > --Sean
> -Original Message-
> From: Sean Anderson
> Sent: Tuesday, September 20, 2022 11:21 AM
> To: Robin Murphy ; Oleksij Rempel
> ; Pengutronix Kernel Team
> ; linux-...@vger.kernel.org; linux-arm-kernel
> ; Vinod Koul ;
> dmaeng...@vger.kernel.org; Leo Li ; Lauren
> ; Linux Kernel Mailing List ker...@vger.kernel.org>; linux-me...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; linaro-mm-...@lists.linaro.org; Joy Zou
> ; Peng Ma ; Robin Gong
> ; Shawn Guo ; Leo Li
>
> Subject: [BUG] ls1046a: eDMA does not transfer data from I2C
&
t;drm/amd/display: Get VCO frequency from registers")
> Signed-off-by: Nathan Chancellor
Just hit this myself, thanks for the fix!
Reviewed-by: Leo Li
> ---
> drivers/gpu/drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-
sonable to me. The suspend sends the destroy message if
there is still incomplete job, so it should be before the fini which
stops the hardware.
The series are:
Reviewed-by: Leo Liu
Signed-off-by: Qiang Ma
---
drivers/gpu/drm/radeon/cik.c | 2 +-
drivers/gpu/drm/radeon/evergreen.
Acked-by: Leo Liu
On 2021-04-16 8:54 a.m., Christian König wrote:
Ping?
Am 15.04.21 um 10:47 schrieb Christian König:
Releasing pinned BOs is illegal now.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers
meson: Also search for rst2man.py
James Zhu (1):
tests/amdgpu: add vcn test support for dimgrey_cavefish
Jinzhou Su (1):
test/amdgpu: remove static varible in Syncobj test
Lang Yu (2):
drm/tests/amdgpu: fix Metadata test failed issue
tests/amdgpu: fix bo eviction test
The series are:
Reviewed-and-Tested-by: Leo Liu
On 2021-02-04 9:44 a.m., Christian König wrote:
The VCN3 instances can do both decode as well as encode.
Share the scheduler load balancing score and remove fixing encode to
only the second instance.
Signed-off-by: Christian König
Sorry for the delay, change LGTM.
Reviewed-by: Leo Li
, and applied.
Thanks!
Leo
On 2020-01-24 5:18 a.m., Dor Askayo wrote:
> On Fri, Jan 17, 2020 at 12:59 PM Dor Askayo wrote:
>>
>> On Sat, Jan 4, 2020 at 2:23 PM Dor Askayo wrote:
>>>
>>> This allocation
gt; + return dc_link_bandwidth_kbps(link,
> + dc_link_get_link_cap(link)) / (8 * 1000 * 54);
Had to take a look at the DP spec to understand this conversion here, section
2.6.4.1.
LGTM,
Reviewed-by: Leo Li
> +}
> diff --git a/drivers/gpu/drm/amd/display/amdgpu
list_for_each_entry(vcpi, &mst_state->vcpis, next) {
> + if (!vcpi->pbn)
> + continue;
> +
> + if (drm_dp_mst_port_downstream_of_branch(vcpi->port, branch))
> + pbn_used += vcpi->pbn;
> + }
It's not
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/
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.
>
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:
&
ight pwm.
I attached a hack to the bugzilla ticket that disables it, please give that
patch a shot
first. I'd rather not change this calculation for all panels if the flickering
issue is
only a quirk for some.
Thanks,
Leo
>
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17
On 2019-10-01 5:57 p.m., Gustavo A. R. Silva wrote:
>
> On 10/1/19 16:46, Liu, Leo wrote:
>
>>>>> + ring->sched.ready = true;
>>>> This is redundant. all the sched->ready is initialized as true, please
>>>> refer to drm_sch
On 2019-10-01 5:43 p.m., Gustavo A. R. Silva wrote:
> Hi,
>
> On 10/1/19 16:29, Liu, Leo wrote:
>> On 2019-10-01 1:16 p.m., Gustavo A. R. Silva wrote:
>>> Notice that there is a *continue* statement in the middle of the
>>> for loop and that prevents the c
66,8 +267,7 @@ static int vcn_v2_5_hw_init(void *handle)
>
> for (i = 0; i < adev->vcn.num_enc_rings; ++i) {
> ring = &adev->vcn.inst[j].ring_enc[i];
> - ring->sched.ready = false;
> - contin
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
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-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
return false;
>> } else if (adev->smu.ppt_funcs &&
>> adev->smu.ppt_funcs->get_clock_by_type_with_latency) {
>> if (smu_get_clock_by_type_with_latency(&adev->smu,
>> -
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 t
op because blah */
> + connector->max_bpc_property =
> + intel_dp->attached_connector->base.max_bpc_property;
> drm_connector_attach_max_bpc_property(connector, 6, 12);
I'd prefer to address this separately, if that's alright.
It isn't related to this series, and no new
s patch entirely for now. We
> should
> be fine without it, even though the dp_aux_dev paths will be kind of ugly for
> a
> little while. I'd rather the rest of this series get upstream first, and try
> to
> do the path prop stuff separately.>
Sounds fair, going to
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&
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 p
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:
>>
>>
read requests on a disconnected
>> physical port, whereas the MST displays will NAK.
>>
>> In light of these discrepancies, it's simpler to expose all downstream
>> ports - both physical and logical - and let the user decide what to use.
>>
>> Cc: Lyude Paul
&
tion handling part in DRM still, but pass the responsibility of
creating and removing remote (fake) aux devices to the driver.
I have a WIP patch here for you to take a look. It should apply on top
of the existing patchset:
https://pastebin.com/1YJZhL4C
I'd like to hear yo
ort->connector-
>> kdev; assignment that you do in patch 3/7 (and of course, you can remove the
> connector registration status check there now).
Hmm, I don't think that will quite work for the purpose of the series.
If I register the aux device before the connector'
ise anyone trying to test these patches
> has to resolve merge conflicts (along with maintainers). The branch this
> appears to be based off of doesn't even have the new kref scheme for branch
> devices and ports.
>
Sorry, this was laziness on my part :)
Rebasing this now.
Leo
o the connector? FWICT
all drivers using drm_aux_register() should be able to provide the
associated connector when calling it.
Leo
>
> On Mon, 2019-04-22 at 19:56 -0400, sunpeng...@amd.com wrote:
>> From: Leo Li
>>
>> To give identifiable attributes to MST DP aux devic
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:
>&
; *NAK*
# auxrw.py read /dev/drm_dp_aux6_mst\:0-1 0x30-0x3f -> ACK
So it seems there's some device dependent behavior here. I'm not sure if
there's a better way of handling this besides exposing all the
downstream ports: If it works, great. If not, just don't
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:
>> h
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 Febr
Just make them properly i.e. put 0 to the Nop reg
Signed-off-by: Leo Liu
---
tests/amdgpu/vcn_tests.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/tests/amdgpu/vcn_tests.c b/tests/amdgpu/vcn_tests.c
index d9f05af8..859ec496 100644
--- a/tests/amdgpu
by CoverityScan, CID#1475565 ("Dereference before null check")
>
> Fixes: e1e8a020c6b8 ("drm/amd/display: Add support for Freesync 2 HDR and
> Content to Display Mapping")
> Signed-off-by: Colin Ian King
Reviewed-by: Leo Li
Thanks!
> ---
&
emented its own __drm_atomic_helper_crtc_reset(),
> convert it to the common one.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
> Cc: David Airlie
> Cc: Liviu D
s: 2f14bc89("drm/amd/display: add retimer log for HWQ tuning use.")
> Cc: Charlene Liu
> Cc: Dmytro Laktyushkin
> Cc: Leo Li
> Signed-off-by: Shaokun Zhang
Reviewed-by: Leo Li
Thanks!
Leo
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4 ++--
> 1 file
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
On 2018-10-12 03:34 AM, Daniel Vetter wrote:
On Thu, Oct 11, 2018 at 08:27:43PM -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 the preemption
481 ("drm/amd/display: Use DRM helper for
best_encoder").
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Andrey Grodzovsky
Cc: Tony Cheng
Cc: "Leo (Sunpeng) Li"
Cc: Shirish S
Acked-by: Harry Wentland
Thx for rebasing :)
Review
the hook, so we don't
have two conflicting patches in flight.
Leo
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Andrey Grodzovsky
Cc: Tony Cheng
Cc: "Leo (Sunpeng) Li"
Cc: Shirish S
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23 --
fails to build on architectures
that do not support any floating-point functions, or would require making
that code x86 specific as well. I also looked at what it would take to
Hi Arnd,
Is there a reason why we can't make __sanitizer_cov_trace_cmpd and
__sanitizer_cov_trace_cmpf X86 dep
On 2018-07-31 02:24 PM, Dan Carpenter wrote:
[ Potential security issue, if I'm reading the code correctly. I don't
really know the code and I haven't looked at the larger context. -dan ]
Hello Leo (Sunpeng) Li,
The patch edf6ffe4f47e: "drm/amd/display: Read AUX
we
already gets as part of verify_crc_source.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 3 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 4
On 2018-07-03 06:19 AM, Maarten Lankhorst wrote:
Op 02-07-18 om 13:07 schreef Mahesh Kumar:
This patch implements "verify_crc_source" callback function for
AMD drm driver.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
Acked-
Updated IGT results seem sane:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7698/shards.html
Would someone be able to apply this patch?
Thanks,
Leo
On 2018-01-17 03:18 PM, Sean Paul wrote:
On Wed, Jan 17, 2018 at 10:39 AM, Maarten Lankhorst
wrote:
Op 17-01-18 om 19:29 schreef Sean
On 2017-12-13 02:24 PM, Leo Li wrote:
On 2017-12-13 12:23 PM, Maarten Lankhorst wrote:
Op 13-12-17 om 17:19 schreef Leo Li:
Hi Daniel, Maarten,
Just digging an old thread out of the grave:
https://lists.freedesktop.org/archives/dri-devel/2017-August/150495.html
It's suppose to
;re starting to bump into this issue again. Regarding Daniel's
suggestion for an IGT test, has there been any work done on it? I'd be
interested in taking a look otherwise. As a side note, I can also
reproduce this on i915.
Thanks,
Leo
___
dr
On 2017-12-13 12:23 PM, Maarten Lankhorst wrote:
Op 13-12-17 om 17:19 schreef Leo Li:
Hi Daniel, Maarten,
Just digging an old thread out of the grave:
https://lists.freedesktop.org/archives/dri-devel/2017-August/150495.html
It's suppose to fix a memory leak on the drm_commit object d
1 - 100 of 118 matches
Mail list logo
