Quoting Kuogee Hsieh (2021-04-21 16:37:37)
Maybe when the cable is disconnected the DP phy should be shutdown and some bit in the phy could effectively "cut off" the aux channel and then NAKs would start coming through here in the DP controller I/O register space. This patch have DP aux channel read/write to return NAK immediately if DP controller connection status is in unplugged state.
Changes in V4: -- split this patch as stand alone patch
Signed-off-by: Kuogee Hsieh khsieh@codeaurora.org
drivers/gpu/drm/msm/dp/dp_aux.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c index 7c22bfe..fae3806 100644 --- a/drivers/gpu/drm/msm/dp/dp_aux.c +++ b/drivers/gpu/drm/msm/dp/dp_aux.c @@ -343,6 +343,11 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
mutex_lock(&aux->mutex);
if (!dp_catalog_link_is_connected(aux->catalog)) {ret = -ETIMEDOUT;goto unlock_exit;}aux->native = msg->request & (DP_AUX_NATIVE_WRITE & DP_AUX_NATIVE_READ); /* Ignore address only message */
Can the code check for aux timeouts? So instead of blindly completing 'aux->comp' we would do the transfer, and then dp_aux_cmd_fifo_tx() would check to see if the completion was completed from the irq handler because of a timeout or a nack, etc. I think the code is probably racy, given that dp_aux_isr() is called from irq context, and aux_error_num is set from the irq context and tested in non-irq context. This code needs a spinlock and then to check the isr bits to figure out if it should tell the upper layers that the address was wrong, or there was a nack or a timeout, etc.
I don't think we need to check the link to see if it is connected, just look at the irq bits to see if the response was bad and letting higher layers know that should quickly cut off the transactions.