Displaying 6 results from an estimated 6 matches for "up_req".
2019 Sep 03
0
[PATCH v2 19/27] drm/dp_mst: Handle UP requests asynchronously
...eouts and causes the whole topology state to go
out of sync with reality, usually resulting in the user needing to
replug the entire topology in hopes that it actually fixes things.
The reason for this is because the way we currently handle UP requests
in MST is completely bogus. drm_dp_mst_handle_up_req() is called from
drm_dp_mst_hpd_irq(), which is usually called from the driver's hotplug
handler. Because we handle sending the hotplug event from this function,
we actually cause the driver's hotplug handler (and in turn, all
sideband transactions) to block on
drm_device->mode_config.co...
2019 Oct 22
0
[PATCH v5 04/14] drm/dp_mst: Handle UP requests asynchronously
...eouts and causes the whole topology state to go
out of sync with reality, usually resulting in the user needing to
replug the entire topology in hopes that it actually fixes things.
The reason for this is because the way we currently handle UP requests
in MST is completely bogus. drm_dp_mst_handle_up_req() is called from
drm_dp_mst_hpd_irq(), which is usually called from the driver's hotplug
handler. Because we handle sending the hotplug event from this function,
we actually cause the driver's hotplug handler (and in turn, all
sideband transactions) to block on
drm_device->mode_config.co...
2019 Oct 22
0
[PATCH v5 05/14] drm/dp_mst: Add probe_lock
...lly grabbed under random various modesetting locks, meaning that
there's no way we can just invert the &mgr->lock order and keep it
locked throughout the whole process of updating the topology.
Luckily there are only two workers which can modify the in-memory
topology layout: drm_dp_mst_up_req_work() and
drm_dp_mst_link_probe_work(), meaning as long as we prevent these two
workers from traveling the topology layout in parallel with the intent
of updating it we don't need to worry about grabbing &mgr->lock in these
workers for reads. We only need to grab &mgr->lock in th...
2019 Oct 22
17
[PATCH v5 00/14] DP MST Refactors + debugging tools + suspend/resume reprobing
This is the final portion of the large series for adding MST
suspend/resume reprobing that I've been working on for quite a while
now. In addition, I:
* Refactored and cleaned up any code I ended up digging through in the
process of understanding how some parts of these helpers worked.
* Added some debugging tools along the way that I ended up needing to
figure out some issues in my own
2019 Oct 22
0
[PATCH v5 06/14] drm/dp_mst: Protect drm_dp_mst_port members with locking
...gr->base.lock, the modesetting
lock which currently only protects &mgr->base.state. This works
perfectly because it allows us to avoid blocking connection_mutex
unnecessarily, and we can grab this in connector detection paths since
it's a ww mutex. We start by having drm_dp_mst_handle_up_req() hold this
when updating ports. For drm_dp_mst_handle_link_address_port() things
are a bit more complicated. As I've learned the hard way, we can grab
&mgr->lock.base for everything except for port->connector. See, our
normal driver probing paths end up generating this rather obvious...
2019 Sep 03
50
[PATCH v2 00/27] DP MST Refactors + debugging tools + suspend/resume reprobing
...mbine redundant cases in drm_dp_encode_sideband_req()
drm/dp_mst: Add sideband down request tracing + selftests
drm/dp_mst: Remove PDT teardown in drm_dp_destroy_port() and refactor
drm/dp_mst: Refactor drm_dp_send_enum_path_resources
drm/dp_mst: Remove huge conditional in drm_dp_mst_handle_up_req()
drm/dp_mst: Constify guid in drm_dp_get_mst_branch_by_guid()
drm/dp_mst: Refactor drm_dp_mst_handle_up_req()
drm/dp_mst: Refactor drm_dp_mst_handle_down_rep()
drm/dp_mst: Destroy topology_mgr mutexes
drm/dp_mst: Cleanup drm_dp_send_link_address() a bit
drm/dp_mst: Refactor pdt setup/t...