similar to: [PATCH v4 04/11] drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state

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. Instead of continuing > this pattern, change the callback signature to just give atomic state > and let the

Hi Sean, On Mon, May 13, 2019 at 10:38:58AM -0400, Sean Paul wrote: > On Sat, May 11, 2019 at 3:12 PM Laurent Pinchart wrote: > > 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

Hi Daniel, On Mon, May 13, 2019 at 04:47:47PM +0200, Daniel Vetter wrote: > On Sat, May 11, 2019 at 10:12:02PM +0300, Laurent Pinchart wrote: > > 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

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

On Thu, May 16, 2019 at 2:02 PM Laurent Pinchart <laurent.pinchart at ideasonboard.com> wrote: > > Hi Daniel, > > On Mon, May 13, 2019 at 04:47:47PM +0200, Daniel Vetter wrote: > > On Sat, May 11, 2019 at 10:12:02PM +0300, Laurent Pinchart wrote: > > > On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote: > > >> From: Sean Paul <seanpaul at

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

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.

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

Currently, nouveau uses the yolo method of setting up MST displays: it uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the display configuration. These helpers don't take care to make sure they take a reference to the mstb port that they're checking, and additionally don't actually check whether or not the topology still has enough bandwidth to provide the VCPI

Currently, nouveau uses the yolo method of setting up MST displays: it uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the display configuration. These helpers don't take care to make sure they take a reference to the mstb port that they're checking, and additionally don't actually check whether or not the topology still has enough bandwidth to provide the VCPI

Currently, i915 appears to rely on blocking modesets on no-longer-present MSTB ports by simply returning NULL for ->best_encoder(), which in turn causes any new atomic commits that don't disable the CRTC to fail. This is wrong however, since we still want to allow userspace to disable CRTCs on no-longer-present MSTB ports by changing the DPMS state to off and this still requires that we

Currently, i915 appears to rely on blocking modesets on no-longer-present MSTB ports by simply returning NULL for ->best_encoder(), which in turn causes any new atomic commits that don't disable the CRTC to fail. This is wrong however, since we still want to allow userspace to disable CRTCs on no-longer-present MSTB ports by changing the DPMS state to off and this still requires that we

There has been a TODO waiting for quite a long time in drm_dp_mst_topology.c: /* We cannot rely on port->vcpi.num_slots to update * topology_state->avail_slots as the port may not exist if the parent * branch device was unplugged. This should be fixed by tracking * per-port slot allocation in drm_dp_mst_topology_state instead of * depending on the caller to tell us how many slots

There has been a TODO waiting for quite a long time in drm_dp_mst_topology.c: /* We cannot rely on port->vcpi.num_slots to update * topology_state->avail_slots as the port may not exist if the parent * branch device was unplugged. This should be fixed by tracking * per-port slot allocation in drm_dp_mst_topology_state instead of * depending on the caller to tell us how many slots

There has been a TODO waiting for quite a long time in drm_dp_mst_topology.c: /* We cannot rely on port->vcpi.num_slots to update * topology_state->avail_slots as the port may not exist if the parent * branch device was unplugged. This should be fixed by tracking * per-port slot allocation in drm_dp_mst_topology_state instead of * depending on the caller to tell us how many slots

On Mon, 2018-11-26 at 22:04 +0100, Daniel Vetter wrote: > On Thu, Nov 15, 2018 at 07:50:05PM -0500, Lyude Paul wrote: > > There has been a TODO waiting for quite a long time in > > drm_dp_mst_topology.c: > > > > /* We cannot rely on port->vcpi.num_slots to update > > * topology_state->avail_slots as the port may not exist if the parent > > *

On Mon, Nov 26, 2018 at 10:04:21PM +0100, Daniel Vetter wrote: > On Thu, Nov 15, 2018 at 07:50:05PM -0500, Lyude Paul wrote: > > There has been a TODO waiting for quite a long time in > > drm_dp_mst_topology.c: > > > > /* We cannot rely on port->vcpi.num_slots to update > > * topology_state->avail_slots as the port may not exist if the parent > >

On Tue, Nov 27, 2018 at 12:48:59PM -0500, Lyude Paul wrote: > On Mon, 2018-11-26 at 22:22 +0100, Daniel Vetter wrote: > > On Mon, Nov 26, 2018 at 10:04:21PM +0100, Daniel Vetter wrote: > > > On Thu, Nov 15, 2018 at 07:50:05PM -0500, Lyude Paul wrote: > > > > There has been a TODO waiting for quite a long time in > > > > drm_dp_mst_topology.c: > >

On Tue, Nov 27, 2018 at 08:44:14PM -0500, Lyude Paul wrote: > On Tue, 2018-11-27 at 20:44 +0100, Daniel Vetter wrote: > > On Tue, Nov 27, 2018 at 12:48:59PM -0500, Lyude Paul wrote: > > > On Mon, 2018-11-26 at 22:22 +0100, Daniel Vetter wrote: > > > > On Mon, Nov 26, 2018 at 10:04:21PM +0100, Daniel Vetter wrote: > > > > > On Thu, Nov 15, 2018 at

Currently; private objects are mostly used just for driver-specific atomic state, but not entirely. MST also uses private objects for holding it's atomic state, but in order to make our MST helpers safer for atomic we need to be able to check that state after the driver has performed it's own checks on the atomic state. So, add an optional ->atomic_check() callback into