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

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

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 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.

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

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

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

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

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

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 (4): drm/dp_mst: Add some atomic state iterator macros drm/dp_mst: Start tracking per-port VCPI

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

[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

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

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

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 Wed, 2018-11-28 at 09:17 +0100, Daniel Vetter wrote: > 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: > > > > We could do this the other way around so it looks like this maybe > > > > struct kref; /* manages kfree() */ > > struct topology_kref; /* corresonds to lifetime in topology

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: > > > > > > /* We cannot rely on port->vcpi.num_slots to update > >

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 > * branch device was unplugged. This should be fixed by tracking > * per-port slot allocation

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 07:50:05PM -0500, Lyude Paul wrote: > > > > > There has been a TODO waiting