similar to: [PATCH v7 0/5] Fix legacy DPMS changes with MST

Next version of https://patchwork.freedesktop.org/series/49878/ . No changes, except that these patches are against master so hopefully intel's CI doesn't get confused this time. Lyude Paul (5): drm/atomic_helper: Disallow new modesets on unregistered connectors drm/nouveau: Fix nv50_mstc->best_encoder() drm/i915: Leave intel_conn->mst_port set, use mst_port_gone instead

Next version of https://patchwork.freedesktop.org/series/49877/ This fixes some rather silly bugs regarding DPMS On->Off changes failing for connectors which were just recently destroyed. Lyude Paul (5): drm/atomic_helper: Disallow new modesets on unregistered connectors drm/nouveau: Fix nv50_mstc->best_encoder() drm/i915: Leave intel_conn->mst_port set, use mst_port_gone instead

Latest version of https://patchwork.freedesktop.org/series/49878/ Lyude Paul (5): drm/atomic_helper: Disallow new modesets on unregistered connectors drm/nouveau: Fix nv50_mstc->best_encoder() drm/i915: Don't unset intel_connector->mst_port drm/i915: Skip vcpi allocation for MSTB ports that are gone drm/i915: Fix intel_dp_mst_best_encoder()

Next version of https://patchwork.freedesktop.org/series/49878/ No functional changes, just a typo fix Lyude Paul (5): drm/atomic_helper: Disallow new modesets on unregistered connectors drm/nouveau: Fix nv50_mstc->best_encoder() drm/i915: Don't unset intel_connector->mst_port drm/i915: Skip vcpi allocation for MSTB ports that are gone drm/i915: Fix

Currently we set intel_connector->mst_port to NULL to signify that the MST port has been removed from the system so that we can prevent further action on the port such as connector probes, mode probing, etc. However, we're going to need access to intel_connector->mst_port in order to fixup ->best_encoder() so that it can always return the correct encoder for an MST port to prevent

On Fri, 2018-09-21 at 11:27 +0200, Daniel Vetter wrote: > On Tue, Sep 18, 2018 at 07:06:19PM -0400, Lyude Paul wrote: > > Currently we set intel_connector->mst_port to NULL to signify that the > > MST port has been removed from the system so that we can prevent further > > action on the port such as connector probes, mode probing, etc. > > However, we're going to

Currently we set intel_connector->mst_port to NULL to signify that the MST port has been removed from the system so that we can prevent further action on the port such as connector probes, mode probing, etc. However, we're going to need access to intel_connector->mst_port in order to fixup ->best_encoder() so that it can always return the correct encoder for an MST port to prevent

This patchset does some cleaning up of the atomic VCPI helpers for MST, and converts nouveau over to using them. I would have included amdgpu in this patch as well, but at the moment moving them over to the atomic helpers is nontrivial. [sorry for still not adding your R-Bs! I ended up needing to make a lot of changes to make it so we do actually kref() each port in the atomic state] Cc: Daniel

This fixes the extra issues I discovered upstream after the introduction of my rework of the atomic VCPI helpers that occur during suspend/resume. This time around, we use a slightly different but much less complicated approach for fixing said issues. Cc: Daniel Vetter <daniel at ffwll.ch> Lyude Paul (4): drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a

From: Sean Paul <seanpaul at chromium.org> Everyone who implements connector_helper_funcs->atomic_check reaches into the connector state to get the atomic state. Instead of continuing this pattern, change the callback signature to just give atomic state and let the driver determine what it does and does not need from it. Eventually all atomic functions should do this, but that's

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a

This fixes the extra issues I discovered upstream after the introduction of my rework of the atomic VCPI helpers that occur during suspend/resume. This time around, we use a slightly different but much less complicated approach for fixing said issues. Cc: Daniel Vetter <daniel at ffwll.ch> Lyude Paul (4): drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()

On Sat, May 11, 2019 at 3:12 PM Laurent Pinchart <laurent.pinchart at ideasonboard.com> wrote: > > Hi Sean, > > Thank you for the patch. > Hey Laurent, Thanks for looking! > On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote: > > From: Sean Paul <seanpaul at chromium.org> > > > > Everyone who implements

This patchset does some cleaning up of the atomic VCPI helpers for MST, and converts nouveau over to using them. I would have included amdgpu in this patch as well, but at the moment moving them over to the atomic helpers is nontrivial. Cc: Daniel Vetter <daniel at ffwll.ch> Lyude Paul (5): drm/dp_mst: Add some atomic state iterator macros drm/dp_mst: Start tracking per-port VCPI

On Sat, May 11, 2019 at 10:12:02PM +0300, Laurent Pinchart wrote: > Hi Sean, > > Thank you for the patch. > > On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote: > > From: Sean Paul <seanpaul at chromium.org> > > > > Everyone who implements connector_helper_funcs->atomic_check reaches > > into the connector state to get the atomic state.

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a

So we don't ever have to worry about drivers touching drm_dp_mst_port structs without verifying them and crashing again. Lyude Paul (6): drm/dp_mst: Add drm_dp_get_payload_info() drm/nouveau: Use drm_dp_get_payload_info() for getting payload/vcpi drm/nouveau: Stop reading port->mgr in nv50_mstc_get_modes() drm/nouveau: Stop reading port->mgr in nv50_mstc_detect() drm/dp_mst:

[sorry about the resend-copy pasted the wrong header and I want to make sure this doesn't get missed!] This patchset does some cleaning up of the atomic VCPI helpers for MST, and converts nouveau over to using them. I would have included amdgpu in this patch as well, but at the moment moving them over to the atomic helpers is nontrivial. Cc: Daniel Vetter <daniel at ffwll.ch> Lyude