diff options
author | Wayne Lin <Wayne.Lin@amd.com> | 2020-01-13 17:36:49 +0800 |
---|---|---|
committer | Lyude Paul <lyude@redhat.com> | 2020-01-15 17:01:21 -0500 |
commit | 5a64967a2f3bbc01cc708ee43c7b0893089c61c4 (patch) | |
tree | 67cab3ff97971a640fbfa2ffeb54f0afc5c63c32 /drivers/ide/ide-atapi.c | |
parent | 7617e9621bf2ca3bb58d5f216cc35c86b029105d (diff) | |
download | linux-5a64967a2f3bbc01cc708ee43c7b0893089c61c4.tar.bz2 |
drm/dp_mst: Have DP_Tx send one msg at a time
[Why]
Noticed this while testing MST with the 4 ports MST hub from
StarTech.com. Sometimes can't light up monitors normally and get the
error message as 'sideband msg build failed'.
Look into aux transactions, found out that source sometimes will send
out another down request before receiving the down reply of the
previous down request. On the other hand, in drm_dp_get_one_sb_msg(),
current code doesn't handle the interleaved replies case. Hence, source
can't build up message completely and can't light up monitors.
[How]
For good compatibility, enforce source to send out one down request at a
time. Add a flag, is_waiting_for_dwn_reply, to determine if the source
can send out a down request immediately or not.
- Check the flag before calling process_single_down_tx_qlock to send out
a msg
- Set the flag when successfully send out a down request
- Clear the flag when successfully build up a down reply
- Clear the flag when find erros during sending out a down request
- Clear the flag when find errors during building up a down reply
- Clear the flag when timeout occurs during waiting for a down reply
- Use drm_dp_mst_kick_tx() to try to send another down request in queue
at the end of drm_dp_mst_wait_tx_reply() (attempt to send out messages
in queue when errors occur)
Cc: Lyude Paul <lyude@redhat.com>
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200113093649.11755-1-Wayne.Lin@amd.com
Diffstat (limited to 'drivers/ide/ide-atapi.c')
0 files changed, 0 insertions, 0 deletions