s/drm_dp_get_validated_port_ref/drm_dp_mst_topology_get_port_validated/
s/drm_dp_put_port/drm_dp_mst_topology_put_port/
s/drm_dp_get_validated_mstb_ref/drm_dp_mst_topology_get_mstb_validated/
s/drm_dp_put_mst_branch_device/drm_dp_mst_topology_put_mstb/
This is a much more consistent naming
Going through the currently programmed payloads isn't safe without
holding mgr->payload_lock, so actually do that and warn if anyone tries
calling nv50_msto_payload() in the future without grabbing the right
locks.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc:
Now that we finally have a sane way to keep port allocations around, use
it to fix the potential unchecked ->port accesses that nouveau makes by
making sure we keep the mst port allocated for as long as it's
drm_connector is accessible.
Additionally, now that we've guaranteed that mstc->port is
While this isn't a complete fix, this will improve the reliability of
drm_dp_get_last_connected_port_and_mstb() pretty significantly during
hotplug events, since there's a chance that the in-memory topology tree
may not be fully updated when drm_dp_get_last_connected_port_and_mstb()
is called and
Changes since v6:
- Move EXPORT_SYMBOL() for drm_dp_mst_topology_state_funcs to this
commit
- Document __drm_dp_mst_state_iter_get() and note that it shouldn't be
called directly
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Up until now, freeing payloads on remote MST hubs that just had ports
removed has almost never worked because we've been relying on port
validation in order to stop us from accessing ports that have already
been freed from memory, but ports which need their payloads released due
to being removed
The current way of handling refcounting in the DP MST helpers is really
confusing and probably just plain wrong because it's been hacked up many
times over the years without anyone actually going over the code and
seeing if things could be simplified.
To the best of my understanding, the current
Trying to destroy the connector using mstc->connector.funcs->destroy()
if connector initialization fails is wrong: there is no possible
codepath in nv50_mstc_new where nv50_mstm_add_connector() would return
<0 and mstc would be non-NULL.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David
This has never actually worked, and isn't needed anyway: the driver's
always going to try to deallocate VCPI when it tears down the display
that the VCPI belongs to.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
So that the ports stay around until we've destroyed the connectors, in
order to ensure that we don't pass an invalid pointer to any MST helpers
once we introduce the new MST VCPI helpers.
Changes since v1:
* Move drm_dp_mst_get_port_malloc() to where we assign
intel_connector->port - danvet
Just like i915 and nouveau, it's a good idea for us to hold a malloc
reference to the port here so that we never pass a freed pointer to any
of the DP MST helper functions.
Also, we stop unsetting aconnector->port in
dm_dp_destroy_mst_connector(). There's literally no point to that
assignment
https://bugs.freedesktop.org/show_bug.cgi?id=102349
--- Comment #17 from Ilia Mirkin ---
(In reply to Christian Tosta from comment #16)
> Not fixed in Mesa 18.2.8 for Fedora 29. Plasmashell keeps segfaulting.
> Screen turns black with only the cursor. Konsole and other programs
> runs fine,
There is no need to look at the port's VCPI allocation before calling
drm_dp_mst_deallocate_vcpi(), as we already have msto->disabled to let
us avoid cleaning up an msto more then once. The DP MST core will never
call drm_dp_mst_deallocate_vcpi() on it's own, which is presumably what
these checks
Same as we did for i915, but for nouveau this time. Additionally, we
grab a malloc reference to the port that lasts for the entire lifetime
of nv50_mstc, which gives us the guarantee that mstc->port will always
point to valid memory for as long as the mstc stays around.
Signed-off-by: Lyude Paul
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
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
It occurred to me that we never actually check this! So let's start
doing that.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++-
1 file changed, 7 insertions(+), 1
https://bugs.freedesktop.org/show_bug.cgi?id=102349
Christian Tosta changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=109187
Dominik 'Rathann' Mierzejewski changed:
What|Removed |Added
Summary|[NVC1][optimus] nouveau |[NVC1][optimus]
19 matches
Mail list logo
