Reviewed-by: Lyude Paul lyude@redhat.com
Will push to drm-misc-next in a bit
On Thu, 2022-04-28 at 20:49 +0800, Wayne Lin wrote:
[Why] It's reasonable that we receive NAK while doing DP_REMOTE_DPCD_READ. Downstream device might reply NAK with the reason and source should react accordingly.
e.g.
- When downstream device can't handle corresponding message in time,
it then replies NAK as reason been set as DEFER. 2. When multi-function branch-sink device doesn't enumerate virtual DP peer devices for those multi-function down facing ports. Without virtual DPCD, branch device might reply NAK with reason as BAD_PARAM indicating this port can't do aux DPCD read.
It's expected result. Not an error.
[How] Use drm_dbg_kms() to replace drm_err() when receive NAK.
Changes since v1:
- drm_dp_mst_topology.c file path changed. Folder was rename from
'dp' to 'display'
Signed-off-by: Wayne Lin Wayne.Lin@amd.com Reviewed-by: Harry Wentland harry.wentland@amd.com
drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c b/drivers/gpu/drm/display/drm_dp_mst_topology.c index 8526aae75c6d..f27aa0b95bea 100644 --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c @@ -3557,9 +3557,8 @@ static int drm_dp_send_dpcd_read(struct drm_dp_mst_topology_mgr *mgr, if (ret < 0) goto fail_free; - /* DPCD read should never be NACKed */ if (txmsg->reply.reply_type == 1) { - drm_err(mgr->dev, "mstb %p port %d: DPCD read on addr 0x%x for %d bytes NAKed\n", + drm_dbg_kms(mgr->dev, "mstb %p port %d: DPCD read on addr 0x%x for %d bytes NAKed\n", mstb, port->port_num, offset, size); ret = -EIO; goto fail_free;