Reviewed-by: Lyude Paul
I assume you can push this to drm-misc-next yourself?
On Mon, 2024-09-09 at 13:31 +0200, Thomas Zimmermann wrote:
> Call drm_client_setup() to run the kernel's default client setup
> for DRM. Set fbdev_probe in struct drm_driver, so that the client
> setup
Pushed to drm-misc-next, thanks!
On Sat, 2024-08-31 at 09:28 +0800, Li Zetao wrote:
> When it needs to get a value within a certain interval, using clamp()
> makes the code easier to understand than min(max()).
>
> Reviewed-by: Lyude Paul
> Signed-off-by: Li Zetao
> ---
>
As long as you make sure to fix the patch name from drm/amdgpu to drm/nouveau
like Alex mentioned:
Reviewed-by: Lyude Paul
On Fri, 2024-08-30 at 09:22 +0800, Li Zetao wrote:
> When it needs to get a value within a certain interval, using clamp()
> makes the code easier to understand th
@@ -926,8 +926,7 @@ static void vga_switcheroo_debugfs_init(struct
> > vgasr_priv *priv)
> > /**
> > * vga_switcheroo_process_delayed_switch() - helper for delayed switching
> > *
> > - * Process a delayed switch if one is pending. DRM drivers should call
> &
Ah yep! I thought you had push rights for some reason
Also, just so patchwork picks up on it before I push:
Reviewed-by: Lyude Paul
On Wed, 2024-07-03 at 08:13 +, Lin, Wayne wrote:
> [Public]
>
> > -Original Message-
> > From: Lyude Paul
> > Sent: Saturda
perfect solution :), sounds good to me
>
> > > } else if (up_req->msg.req_type ==
> > > DP_RESOURCE_STATUS_NOTIFY) {
> > > const struct drm_dp_resource_status_notify *res_stat
> > > =
> > > &up_req->msg.u.r
Thanks!
Reviewed-by: Lyude Paul
On Wed, 2024-06-26 at 16:48 +0800, Wayne Lin wrote:
> [Why]
> After supend/resume, with topology unchanged, observe that
> link_address_sent of all mstb are marked as false even the topology
> probing
> is done without any error.
>
> It is c
dd checking condition in drm_dp_mst_handle_up_req() to skip handling
> CSN
> if the topology is yet to be probed.
>
> Cc: Lyude Paul
> Cc: Harry Wentland
> Cc: Jani Nikula
> Cc: Imre Deak
> Cc: Daniel Vetter
> Cc: sta...@vger.kernel.org
> Signed-off-by: Wayne Lin
>
Reviewed-by: Lyude Paul
On Fri, 2024-05-10 at 18:08 +0300, Jani Nikula wrote:
> Prefer the parsed results for is_hdmi and has_audio in display info
> over
> calling drm_detect_hdmi_monitor() and drm_detect_monitor_audio(),
> respectively.
>
> Conveniently, this also remov
For the nouveau bits:
Reviewed-by: Lyude Paul
On Mon, 2024-04-22 at 15:10 +0300, Jani Nikula wrote:
> Surprisingly many places depend on debugfs.h to be included via
> drm_print.h. Fix them.
>
> v3: Also fix armada, ite-it6505, imagination, msm, sti, vc4, and xe
>
> v2:
n support of this as well! As long as we make sure it gets
renamed everywhere :)
>
> Thanks,
> Easwar
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Reviewed-by: Lyude Paul
Thanks!
On Fri, 2023-09-22 at 10:32 -0700, Kees Cook wrote:
> Prepare for the coming implementation by GCC and Clang of the __counted_by
> attribute. Flexible array members annotated with __counted_by can have
> their accesses bounds-checked at run-time che
On Thu, 2023-08-24 at 04:12 +, Lin, Wayne wrote:
> [Public]
>
> Hi Lyude,
>
> I'm afraid that I don't have the permissions to push and would like to have
> your help. Thanks!
Whoops, sorry I only just noticed this message. I set a reminder on my phone
to bug me t
Sure - you're also welcome to push the first two patches after fixing the
indentation if you'd like
On Wed, 2023-08-23 at 03:19 +, Lin, Wayne wrote:
> [Public]
>
> Thanks, Lyude!
> Should I push another version to fix the indention?
>
> > -Original Me
v, "Step 2 of creating MST payload for %p
> failed: %d\n",
> payload->port, ret);
> - }
> + else
> + payload->payload_allocation_status =
> DRM_DP_MST_PAYLOAD_ALLOCATION_REMOTE;
>
> return ret;
&g
(pos, &mst_state->payloads, next) {
> > > > - if (pos != new_payload && pos->vc_start_slot > new_payload-
> > > > vc_start_slot)
> > > > - pos->vc_start_slot -= old_payload->time_slots;
> > > > + if (pos != payload && pos->vc_start_slot > payload-
> > > > vc_start_slot)
> > > > + pos->vc_start_slot -= time_slots_to_remove;
> > > > }
> > > > - new_payload->vc_start_slot = -1;
> > > > + payload->vc_start_slot = -1;
> > > >
> > > > mgr->payload_count--;
> > > > - mgr->next_start_slot -= old_payload->time_slots;
> > > > + mgr->next_start_slot -= time_slots_to_remove;
> > > >
> > > > - if (new_payload->delete)
> > > > - drm_dp_mst_put_port_malloc(new_payload->port);
> > > > + if (payload->delete)
> > > > + drm_dp_mst_put_port_malloc(payload->port);
> > > >
> > > > - new_payload->payload_allocation_status =
> > > DRM_DP_MST_PAYLOAD_ALLOCATION_NONE;
> > > > + payload->payload_allocation_status =
> > > > +DRM_DP_MST_PAYLOAD_ALLOCATION_NONE;
> > > > }
> >
> > --
> > Regards,
> > Wayne
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
> msto->head->base.index, 0, 0, 0, 0);
> } else {
> diff --git a/include/drm/display/drm_dp_mst_helper.h
> b/include/drm/display/drm_dp_mst_helper.h
> index ed5c9660563c..4429d3b1745b 100644
> --- a/include/drm/display/drm_dp_mst_helper.h
> +++ b/include/drm/display/drm_dp_mst_helper.h
> @@ -46,6 +46,13 @@ struct drm_dp_mst_topology_ref_history {
> };
> #endif /* IS_ENABLED(CONFIG_DRM_DEBUG_DP_MST_TOPOLOGY_REFS) */
>
> +enum drm_dp_mst_payload_allocation {
> + DRM_DP_MST_PAYLOAD_ALLOCATION_NONE,
> + DRM_DP_MST_PAYLOAD_ALLOCATION_LOCAL,
> + DRM_DP_MST_PAYLOAD_ALLOCATION_DFP,
> + DRM_DP_MST_PAYLOAD_ALLOCATION_REMOTE,
> +};
> +
> struct drm_dp_mst_branch;
>
> /**
> @@ -537,7 +544,7 @@ struct drm_dp_mst_atomic_payload {
>* drm_dp_mst_atomic_wait_for_dependencies() has been called, which
> will ensure the
>* previous MST states payload start slots have been copied over to
> the new state. Note
>* that a new start slot won't be assigned/removed from this payload
> until
> - * drm_dp_add_payload_part1()/drm_dp_remove_payload() have been
> called.
> + * drm_dp_add_payload_part1()/drm_dp_remove_payload_part2() have been
> called.
>* * Acquire the MST modesetting lock, and then wait for any pending
> MST-related commits to
>* get committed to hardware by calling drm_crtc_commit_wait() on
> each of the
>* &drm_crtc_commit structs in &drm_dp_mst_topology_state.commit_deps.
> @@ -564,6 +571,9 @@ struct drm_dp_mst_atomic_payload {
> /** @dsc_enabled: Whether or not this payload has DSC enabled */
> bool dsc_enabled : 1;
>
> + /** @payload_allocation_status: The allocation status of this payload */
> + enum drm_dp_mst_payload_allocation payload_allocation_status;
> +
> /** @next: The list node for this payload */
> struct list_head next;
> };
> @@ -842,10 +852,13 @@ int drm_dp_add_payload_part1(struct
> drm_dp_mst_topology_mgr *mgr,
> int drm_dp_add_payload_part2(struct drm_dp_mst_topology_mgr *mgr,
>struct drm_atomic_state *state,
>struct drm_dp_mst_atomic_payload *payload);
> -void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr *mgr,
> -struct drm_dp_mst_topology_state *mst_state,
> -const struct drm_dp_mst_atomic_payload *old_payload,
> -struct drm_dp_mst_atomic_payload *new_payload);
> +void drm_dp_remove_payload_part1(struct drm_dp_mst_topology_mgr *mgr,
> + struct drm_dp_mst_topology_state *mst_state,
> + struct drm_dp_mst_atomic_payload *payload);
> +void drm_dp_remove_payload_part2(struct drm_dp_mst_topology_mgr *mgr,
> + struct drm_dp_mst_topology_state *mst_state,
> + const struct drm_dp_mst_atomic_payload
> *old_payload,
> + struct drm_dp_mst_atomic_payload *new_payload);
>
> int drm_dp_check_act_status(struct drm_dp_mst_topology_mgr *mgr);
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
For the nouveau bits:
Reviewed-by: Lyude Paul
On Tue, 2023-06-13 at 03:25 +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> The vga_is_firmware_default() function is arch-dependent, it's probably
> wrong if we simply remove the arch guard. As the VRAM BAR which co
Alright, managed to figure out my MST woes! Just tested with nouveau and I see
no regressions :)
Reviewed-by: Lyude Paul
On Fri, 2023-06-09 at 18:49 +0800, Wayne Lin wrote:
> [Why]
> The sequence for collecting down_reply from source perspective should
> be:
>
> Request_n->r
ew_request(&mstm->mgr);
> }
>
> if (!ret)
> diff --git a/include/drm/display/drm_dp_mst_helper.h
> b/include/drm/display/drm_dp_mst_helper.h
> index 32c764fb9cb5..40e855c8407c 100644
> --- a/include/drm/display/drm_dp_mst_helper.h
> +++ b/include/drm/display/drm_dp_mst_helper.h
> @@ -815,8 +815,11 @@ void drm_dp_mst_topology_mgr_destroy(struct
> drm_dp_mst_topology_mgr *mgr);
> bool drm_dp_read_mst_cap(struct drm_dp_aux *aux, const u8
> dpcd[DP_RECEIVER_CAP_SIZE]);
> int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr,
> bool mst_state);
>
> -int drm_dp_mst_hpd_irq(struct drm_dp_mst_topology_mgr *mgr, u8 *esi, bool
> *handled);
> -
> +int drm_dp_mst_hpd_irq_handle_event(struct drm_dp_mst_topology_mgr *mgr,
> + const u8 *esi,
> + u8 *ack,
> + bool *handled);
> +void drm_dp_mst_hpd_irq_send_new_request(struct drm_dp_mst_topology_mgr
> *mgr);
>
> int
> drm_dp_mst_detect_port(struct drm_connector *connector,
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
> break;
> }
> +
> + drm_dp_mst_hpd_irq_send_new_request(&mstm->mgr);
> }
>
> if (!ret)
> diff --git a/include/drm/display/drm_dp_mst_helper.h
> b/include/drm/display/drm_dp_mst_helper.h
> index 32c764fb9cb5..40e855c8407c 100644
> --- a/include/drm/display/drm_dp_mst_helper.h
> +++ b/include/drm/display/drm_dp_mst_helper.h
> @@ -815,8 +815,11 @@ void drm_dp_mst_topology_mgr_destroy(struct
> drm_dp_mst_topology_mgr *mgr);
> bool drm_dp_read_mst_cap(struct drm_dp_aux *aux, const u8
> dpcd[DP_RECEIVER_CAP_SIZE]);
> int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr,
> bool mst_state);
>
> -int drm_dp_mst_hpd_irq(struct drm_dp_mst_topology_mgr *mgr, u8 *esi, bool
> *handled);
> -
> +int drm_dp_mst_hpd_irq_handle_event(struct drm_dp_mst_topology_mgr *mgr,
> + const u8 *esi,
> + u8 *ack,
> + bool *handled);
> +void drm_dp_mst_hpd_irq_send_new_request(struct drm_dp_mst_topology_mgr
> *mgr);
>
> int
> drm_dp_mst_detect_port(struct drm_connector *connector,
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Whoops, sorry about that!
Reviewed-by: Lyude Paul
On Thu, 2023-05-18 at 12:48 -0400, Alex Deucher wrote:
> Put back the radeon_dp_work_func logic. It seems that
> handling DP RX interrupts is necessary to make some
> panels work. This was removed with the MST support,
> but it re
Acked-by: Lyude Paul
On Thu, 2023-01-12 at 21:11 +0100, Thomas Zimmermann wrote:
> Several lastclose helpers call vga_switcheroo_process_delayed_switch().
> It's better to call the helper from drm_lastclose() after the kernel
> client's screen has been restored. This way, all
For the whole series:
Reviewed-by: Lyude Paul
So glad to have this fixed finally ♥
On Thu, 2023-01-19 at 18:51 -0500, Harry Wentland wrote:
> MST has been broken on amdgpu after a refactor in drm_dp_mst
> code that was aligning drm_dp_mst more closely with the atomic
> model.
>
oad table. But previous change tries to go through all the
> > > payloads in mst_state and update amdpug hw maintained table in once
> > > everytime
> > > driver only tries to add/remove a specific payload stream only. The newly
> > > design idea conflicts wi
Acked-by: Lyude Paul
On Thu, 2023-01-12 at 16:50 +0800, Wayne Lin wrote:
> This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f.
>
> [Why]
> Changes cause regression on amdgpu mst.
> E.g.
> In fill_dc_mst_payload_table_from_drm(), amdgpu expects to add/remove payloa
On Fri, 2022-11-18 at 13:54 -0600, Limonciello, Mario wrote:
> On 11/18/2022 13:25, Lyude Paul wrote:
> > It appears that amdgpu makes the mistake of completely ignoring the return
> > values from the DP MST helpers, and instead just returns a simple
> > true/false. In this c
Coverity noticed this one, so let's fix it.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/di
JFYI - I'm not sure of the correct commit ID to add for the Fixes: tag since
it's in your branch, so I'll omit that and let you add it into the patch
On Fri, 2022-11-18 at 14:47 -0500, Lyude Paul wrote:
> of course, will do in just a moment
>
> On Fri, 2022-11-18 at 1
of course, will do in just a moment
On Fri, 2022-11-18 at 14:46 -0500, Alex Deucher wrote:
> I've already picked this up. Can you send a follow up patch with just
> the coverity fix?
>
> Alex
>
> On Fri, Nov 18, 2022 at 2:17 PM Lyude Paul wrote:
> >
> >
_for_state()
Signed-off-by: Lyude Paul
Fixes: 8c20a1ed9b4f ("drm/amd/display: MST DSC compute fair share")
Reviewed-by: Wayne Lin
Cc: Harry Wentland
Cc: # v5.6+
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 18 +-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 235 ++-
4:39 +, Lin, Wayne wrote:
> [Public]
>
> All the patch set looks good to me. Feel free to add:
> Reviewed-by: Wayne Lin
>
> Again, thank you Lyude for helping on this!!!
>
> Regards,
> Wayne
> > -Original Message-
> > From: Lyude Paul
> > S
On Wed, 2022-11-16 at 04:39 +, Lin, Wayne wrote:
> [Public]
>
> All the patch set looks good to me. Feel free to add:
> Reviewed-by: Wayne Lin
>
> Again, thank you Lyude for helping on this!!!
No problem! I was the one who introduced the bug anyway :P, I'm just g
AN warning finally.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
Sending this one separately from the rest of my fixes since:
* It's definitely completely unrelated to the Gitlab 2171 issue
* I'm not sure if this is the correct fix since it's in DC
drivers/gpu/
al
to cause a deadlock.
Signed-off-by: Lyude Paul
Reviewed-by: Wayne Lin
Fixes: 8ec046716ca8 ("drm/dp_mst: Add helper to trigger modeset on affected DSC
MST CRTCs")
Cc: # v5.6+
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
ock. The one exception
is the mutex_lock() in dm_dp_mst_is_port_support_mode(), however we grab no
locks beneath &mgr->lock there so that should be fine to leave be.
Signed-off-by: Lyude Paul
Gitlab issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
Fixes: 8c20a1ed9b4f ("drm/am
paths to look at
the right pointer and skip things that aren't actual MST connectors from a
topology.
Signed-off-by: Lyude Paul
Gitlab issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
Fixes: 8c20a1ed9b4f ("drm/amd/display: MST DSC compute fair share")
Cc: # v5.6+
---
.
(), amdgpu had no way of telling when a
deadlock happened from these helpers. This could definitely result in some
kernel splats.
V2:
* Address Wayne's comments (fix another bunch of spots where we weren't
passing down return codes)
Signed-off-by: Lyude Paul
Fixes: 8c20a1ed9b4f ("drm/a
t on this
issue:
https://gitlab.freedesktop.org/drm/amd/-/issues/2171
Note I've omitted one KASAN fix, but that's because it was just getting
in the way of turning on KASAN and was definitely unrelated to this bug.
Will submit that one on it's own shortly.
Lyude Paul (4):
drm/amdgpu/
without doing
compression, and on ret == -ENOSPC it should just continue the function from
there
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
On Wed, 2022-11-09 at 09:48 +, Lin, Wayne wrote:
> [Public]
>
> Thanks, Lyude!
> Comments inline.
>
> > -Original Message-
> > From: Lyude Paul
> > Sent: Saturday, November 5, 2022 7:59 AM
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Wen
al
to cause a deadlock.
Signed-off-by: Lyude Paul
Fixes: 8ec046716ca8 ("drm/dp_mst: Add helper to trigger modeset on affected DSC
MST CRTCs")
Cc: # v5.6+
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/
(), amdgpu had no way of telling when a
deadlock happened from these helpers. This could definitely result in some
kernel splats.
Signed-off-by: Lyude Paul
Fixes: 8c20a1ed9b4f ("drm/amd/display: MST DSC compute fair share")
Cc: Harry Wentland
Cc: # v5.6+
---
.../gpu/drm/amd/display/amdgpu_dm/a
Some deadlock related fixes for amdgpu and DRM, spurred by:
https://gitlab.freedesktop.org/drm/amd/-/issues/2171
Unfortunately these don't fully fix the problem yet, but I'm getting
there!
Lyude Paul (2):
drm/amdgpu/mst: Stop ignoring error codes and deadlocking
drm/display/d
Gotcha, I'll take another look at this tomorrow
On Mon, 2022-10-17 at 03:09 +, Lin, Wayne wrote:
> [Public]
>
>
>
> > -Original Message-
> > From: Lyude Paul
> > Sent: Thursday, October 6, 2022 3:37 AM
> > To: Siqueira, Rodrigo ; dri-
On Tue, 2022-10-04 at 16:46 -0400, Rodrigo Siqueira Jordao wrote:
>
> On 2022-10-04 16:24, Lyude Paul wrote:
> > Yikes, it appears somehow I totally made a mistake here. We're currently
> > checking to see if drm_dp_add_payload_part2() returns a non-zero value to
>
t.
Signed-off-by: Lyude Paul
Issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
Fixes: 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into the atomic
state")
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
1 file changed, 1 insertion(+), 1 delet
Re comments about infinite retry: gotcha, makes sense to me.
On Tue, 2022-09-27 at 09:45 +1000, Alistair Popple wrote:
> John Hubbard writes:
>
> > On 9/26/22 14:35, Lyude Paul wrote:
> > > > + for (i = 0; i < npages; i++) {
> > > > +
Reviewed-by: Lyude Paul
On Wed, 2022-09-28 at 22:01 +1000, Alistair Popple wrote:
> When the module is unloaded or a GPU is unbound from the module it is
> possible for device private pages to still be mapped in currently
> running processes. This can lead to a hangs and RCU stall warn
On Tue, 2022-09-27 at 11:39 +1000, Alistair Popple wrote:
> Felix Kuehling writes:
>
> > On 2022-09-26 17:35, Lyude Paul wrote:
> > > On Mon, 2022-09-26 at 16:03 +1000, Alistair Popple wrote:
> > > > When the module is unloaded or a GPU is unbound from the
mem_fini(struct nouveau_drm *drm)
> mutex_lock(&drm->dmem->mutex);
>
> list_for_each_entry_safe(chunk, tmp, &drm->dmem->chunks, list) {
> + nouveau_dmem_evict_chunk(chunk);
> nouveau_bo_unpin(chunk->bo);
> nouveau_bo_ref(NULL, &chunk->bo);
> + WARN_ON(chunk->callocated);
> list_del(&chunk->list);
> memunmap_pages(&chunk->pagemap);
> release_mem_region(chunk->pagemap.range.start,
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
AGE_SIZE, DMA_BIDIRECTIONAL);
> + return -EIO;
> + }
Feel free to just align this with the starting (, as long as it doesn't go
above 100 characters it doesn't really matter imho and would look nicer that
way.
Otherwise:
Reviewed-by: Lyude Paul
Will look at the other patc
Reviewed-by: Lyude Paul
On Wed, 2022-08-31 at 18:13 -0400, Fangzhi Zuo wrote:
> The attempt to read DPCD_REV before any native aux read breaks
> majority of DP2 compliance.
>
> The spec. requires DP_SINK_STATUS to be polled for the reset status
> DP_INTRA_HOP_AUX_REPLY_INDICA
Reviewed-by: Lyude Paul
On Wed, 2022-08-24 at 14:15 +0200, Hans de Goede wrote:
> Add an entry summarizing the discussion about dealing with brightness
> control on devices with more then 1 internal panel.
>
> The original discussion can be found here:
> https://lore.kerne
Reviewed-by: Lyude Paul
On Wed, 2022-08-24 at 14:15 +0200, Hans de Goede wrote:
> Typically the acpi_video driver will initialize before nouveau, which
> used to cause /sys/class/backlight/acpi_video0 to get registered and then
> nouveau would register its own nv_backlight device lat
or digits + 1 for '\0'
> @@ -405,6 +406,11 @@ nouveau_backlight_init(struct drm_connector *connector)
> goto fail_alloc;
> }
>
> + if (!nouveau_acpi_video_backlight_use_native()) {
> + NV_INFO(drm, "Skipping nv_backlight registration\n");
>
->delete, which we set whenever we're planning on deleting a payload
during the current atomic commit.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/dr
Actually, talked with airlied and they suggested at this point I should just
go ahead and push. So, pushed! Have fun getting nice DSC support everyone :)
On Tue, 2022-08-23 at 13:26 -0400, Lyude Paul wrote:
> Would anyone have any issues if I merged this today? The whole series is
> acke
Would anyone have any issues if I merged this today? The whole series is
acked, but I'm not sure if we would like to wait for R-b's?
On Wed, 2022-08-17 at 15:38 -0400, Lyude Paul wrote:
> For quite a while we've been carrying around a lot of legacy modesetting
> code in the
ier is better since there generally will be a
bit of Q&A with organizers.
And if you just have some questions about what organizing XDC entails,
please feel free to chat with previous organizers, or someone from the
board.
Best regards,
Lyude Paul
On behalf of X.org
--
Cheers,
L
got
myself confused by DC and we don't actually need this.
Changes since v2:
* Get rid of fix for not sending payload deallocations if ddps=0 and just
go back to wayne's fix
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Dea
n just drop this code and forget
about it. I've already run this idea by Harry Wentland and Alex Deucher a
few times as well.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Alex Deucher
Acked
e only queue
link address probing work at the end of handling all CSNs - allowing us to
make sure we drop as many topology references as we can beforehand.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Pa
e simple helpers
for doing that and hook them up in various drivers.
v2:
* Use intel_dp_mst_source_support() to check for MST support in i915, fixes
CI failures
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc:
ive change
being rejected by the atomic check.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 11 ---
1 file changed,
Since we're going to be relying on atomic locking for payloads now (and the
MST mgr needs to track CRTCs), pull in the topology state for all modesets
in nv50_msto_atomic_check().
Signed-off-by: Lyude Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
1 file ch
vers
using the helpers. Also, it needs to be fixed anyway so we don't break
things when going atomic-only with MST.
So, let's just move this code into drm_dp_atomic_release_time_slots() and
stop open coding it.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
o avoid looking it
up each time. This isn't safe for NV50 since PIORs then come into play,
however there's no code pre-NV50 that would need to look this up anyhow -
so it's not really an issue.
Signed-off-by: Lyude Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/nouveau/nouveau_c
Since we're about to start adding some stuff here, we may as well fill in
any missing documentation that we forgot to write.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani N
s we release or allocate timeslots
on. As well, add some helpers for:
* Setting up the drm_crtc_commit structs in the ->commit_setup hook
* Waiting for any CRTC dependencies from the previous topology state
v2:
* Use drm_dp_mst_atomic_setup_commit() directly - Jani
Signed-off-by: Lyude Paul
We already open-code this quite often, and will be iterating through
payloads even more once we've moved all of the payload tracking into the
atomic state. So, let's add a helper for doing this.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani
d
allocations.
So, let's get rid of that comment.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 +--
1 file changed,
the most part, which is fine since we'll be removing it soon
anyhow. There should be no functional changes in this series.
v2:
* Add note that Wayne Lin from AMD suggested regarding slots being between
the source DP Tx and the immediate downstream DP Rx
Signed-off-by: Lyude Paul
Cc: Wayn
ming it to
drm_dp_mst_atomic_payload. Also, rename various variables throughout the
code that use atomic payloads.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/d
Just to make this more clear to outside contributors that these are
DC-specific structs, as this also threw me into a loop a number of times
before I figured out the purpose of this.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Fangzhi Zuo
Acked-by: Jani Nikula
---
.../gpu/drm/amd/display
x that Wayne pointed out isn't needed
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Lyude Paul (17):
drm/amdgpu/dc/mst: Rename dp_mst_stream_allocation(_table)
drm/amdgpu/dm/mst: Rename get_payload_table()
drm/display/dp_m
hrew me into a
loop a few times.
So, let's rename this to make it's purpose more obvious regardless of where
in the code you are.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Fangzhi Zuo
Acked-by: Jani Nikula
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 7 ---
On Wed, 2022-08-10 at 03:28 +, Lin, Wayne wrote:
> Hi Lyude,
> Thanks for your time and sorry for late response!
>
> It's described in 5.6.1.3 of DP spec 2.0:
> "MST branch device, in addition to waiting for the ACK from its immediate
> Upstream device
On Wed, 2022-08-10 at 09:23 -0400, Hamza Mahfooz wrote:
> On 2022-08-09 18:01, Lyude Paul wrote:
> > Ah yes of course! Probably should have asked when I gave the r-b :). Also,
> > just so patchwork actually catches it I will say the magic incantation:
> >
> > Reviewed-
e simple helpers
for doing that and hook them up in various drivers.
v2:
* Use intel_dp_mst_source_support() to check for MST support in i915, fixes
CI failures
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc:
Ah yes of course! Probably should have asked when I gave the r-b :). Also,
just so patchwork actually catches it I will say the magic incantation:
Reviewed-by: Lyude Paul
Do we want to merge just this patch to drm-misc-next, or do you want to merge
the whole series through there? If you&#
r.lock - Wayne Lin
* Remove mentions of allowing multiple ACT updates per payload change,
mention that this is a result of vendors not consistently supporting this
part of the spec and requiring a unique ACT for each payload change.
* Get rid of reference to drm_dp_mst_port in DC - turns out I just
n just drop this code and forget
about it. I've already run this idea by Harry Wentland and Alex Deucher a
few times as well.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Alex Deucher
Acked
->delete, which we set whenever we're planning on deleting a payload
during the current atomic commit.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/dr
omatically if that port is also marked as disconnected.
However, if there's another parent in the chain after that which is
connected - payloads must be released there with an ALLOCATE_PAYLOAD
message.
So, let's do that!
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc:
e only queue
link address probing work at the end of handling all CSNs - allowing us to
make sure we drop as many topology references as we can beforehand.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Pa
e simple helpers
for doing that and hook them up in various drivers.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
dri
Since we're going to be relying on atomic locking for payloads now (and the
MST mgr needs to track CRTCs), pull in the topology state for all modesets
in nv50_msto_atomic_check().
Signed-off-by: Lyude Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
1 file ch
vers
using the helpers. Also, it needs to be fixed anyway so we don't break
things when going atomic-only with MST.
So, let's just move this code into drm_dp_atomic_release_time_slots() and
stop open coding it.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
ive change
being rejected by the atomic check.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 11 ---
1 file changed,
o avoid looking it
up each time. This isn't safe for NV50 since PIORs then come into play,
however there's no code pre-NV50 that would need to look this up anyhow -
so it's not really an issue.
Signed-off-by: Lyude Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/nouveau/nouveau_c
s we release or allocate timeslots
on. As well, add some helpers for:
* Setting up the drm_crtc_commit structs in the ->commit_setup hook
* Waiting for any CRTC dependencies from the previous topology state
v2:
* Use drm_dp_mst_atomic_setup_commit() directly - Jani
Signed-off-by: Lyude Paul
Since we're about to start adding some stuff here, we may as well fill in
any missing documentation that we forgot to write.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani N
d
allocations.
So, let's get rid of that comment.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 +--
1 file changed,
We already open-code this quite often, and will be iterating through
payloads even more once we've moved all of the payload tracking into the
atomic state. So, let's add a helper for doing this.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani
the most part, which is fine since we'll be removing it soon
anyhow. There should be no functional changes in this series.
v2:
* Add note that Wayne Lin from AMD suggested regarding slots being between
the source DP Tx and the immediate downstream DP Rx
Signed-off-by: Lyude Paul
Cc: Wayn
Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Lyude Paul (18):
drm/amdgpu/dc/mst: Rename dp_mst_stream_allocation(_table)
drm/amdgpu/dm/mst: Rename get_payload_table()
drm/display/dp_mst: Rename drm_dp_mst_vcpi_allocation
drm/display/dp_mst: Ca
ming it to
drm_dp_mst_atomic_payload. Also, rename various variables throughout the
code that use atomic payloads.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/d
Just to make this more clear to outside contributors that these are
DC-specific structs, as this also threw me into a loop a number of times
before I figured out the purpose of this.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Fangzhi Zuo
Acked-by: Jani Nikula
---
.../gpu/drm/amd/display
hrew me into a
loop a few times.
So, let's rename this to make it's purpose more obvious regardless of where
in the code you are.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Fangzhi Zuo
Acked-by: Jani Nikula
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 7 ---
1 - 100 of 693 matches
Mail list logo
