Displaying 8 results from an estimated 8 matches for "dp_connection_status_notifi".
Did you mean:
dp_connection_status_notify
2019 Sep 03
0
[PATCH v2 19/27] drm/dp_mst: Handle UP requests asynchronously
Once upon a time, hotplugging devices on MST branches actually worked in
DRM. Now, it only works in amdgpu (likely because of how it's hotplug
handlers are implemented). On both i915 and nouveau, hotplug
notifications from MST branches are noticed - but trying to respond to
them causes messaging timeouts and causes the whole topology state to go
out of sync with reality, usually resulting in
2019 Oct 22
0
[PATCH v5 04/14] drm/dp_mst: Handle UP requests asynchronously
Once upon a time, hotplugging devices on MST branches actually worked in
DRM. Now, it only works in amdgpu (likely because of how it's hotplug
handlers are implemented). On both i915 and nouveau, hotplug
notifications from MST branches are noticed - but trying to respond to
them causes messaging timeouts and causes the whole topology state to go
out of sync with reality, usually resulting in
2019 Sep 03
0
[PATCH v2 12/27] drm/dp_mst: Refactor drm_dp_mst_handle_up_req()
There's a couple of changes here, so to summarize:
* Remove the big ugly mgr->up_req_recv.have_eomt conditional to save on
indenting
* Store &mgr->up_req_recv.initial_hdr in a variable so we don't keep
going over 80 character long lines
* De-duplicate code for calling drm_dp_send_up_ack_reply() and getting
the MSTB via it's GUID
* Remove all of the duplicate calls to
2019 Sep 03
0
[PATCH v2 10/27] drm/dp_mst: Remove huge conditional in drm_dp_mst_handle_up_req()
Which reduces indentation and makes this function more legible.
Cc: Juston Li <juston.li at intel.com>
Cc: Imre Deak <imre.deak at intel.com>
Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
Cc: Harry Wentland <hwentlan at amd.com>
Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
Signed-off-by: Lyude Paul <lyude at redhat.com>
---
2019 Sep 03
0
[PATCH v2 17/27] drm/dp_mst: Rename drm_dp_add_port and drm_dp_update_port
The names for these functions are rather confusing. drm_dp_add_port()
sounds like a function that would simply create a port and add it to a
topology, and do nothing more. Similarly, drm_dp_update_port() would be
assumed to be the function that should be used to update port
information after initial creation.
While those assumptions are currently correct in how these functions are
used, a quick
2019 Sep 03
50
[PATCH v2 00/27] DP MST Refactors + debugging tools + suspend/resume reprobing
This is 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 code
Note that
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
This is a complicated one. Essentially, there's currently a problem in the MST
core that hasn't really caused any issues that we're aware of (emphasis on "that
we're aware of"): locking.
When we go through and probe the link addresses and path resources in a
topology, we hold no locks when updating ports with said information. The
members I'm referring to in