From patchwork Tue Aug 27 20:35:09 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Paul X-Patchwork-Id: 11117489 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id AC2C414F7 for ; Tue, 27 Aug 2019 20:35:22 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 96C6D2077B for ; Tue, 27 Aug 2019 20:35:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 96C6D2077B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=poorly.run Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id BD82489BF5; Tue, 27 Aug 2019 20:35:20 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-yw1-xc41.google.com (mail-yw1-xc41.google.com [IPv6:2607:f8b0:4864:20::c41]) by gabe.freedesktop.org (Postfix) with ESMTPS id 377D589BF5 for ; Tue, 27 Aug 2019 20:35:20 +0000 (UTC) Received: by mail-yw1-xc41.google.com with SMTP id i138so22769ywg.8 for ; Tue, 27 Aug 2019 13:35:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=e0xIUWcu2PtPYxUBaI6CyjPRq+fZktag3Dw+rT5KOO0=; b=OFODw+9ee6tqAVrst4RmxYwV91YT4/M0kEeiknRxQNRFubSea5OnbFeR821wm9wija uUvsn5/HX3qKJG16ziKq6FfSusm25CcgHyi8mguJV1vRiwrzjyh0mFw/j2IJM52LrJfi bmIOLHf+kAZffwjn3PFNa0jH9YwXrfYENe2w/iLBJfp0ocRgA+70qUCFHdw5WUkBtcIY rM4XLqs14Sm072B6OHCyHtrvPN3bC0TUCbyKYDR8Kk33dazrYfUIK+GGLjEHSBEobGFs R8MfG+ucCSMD3wUrMnELGJoS2NXsanFvSHqYdfDrpXsSiYHdD+w1BPC23MS3sStewFQE FE+w== X-Gm-Message-State: APjAAAWjw1ANqbH1AeffdWQ0deFDn06CJgTGJ/y4Ktcc88Ymey+8Y18t iNXrJtFu3gaK/OXScjuInLHlEj49OIk= X-Google-Smtp-Source: APXvYqwIOp4V7VC7CrfwPOERR9Hu7cKMw7UIL/hl0kp5Nylm/kxS/eIMlbNBYrBll2HZBJ9Rm7/qtA== X-Received: by 2002:a0d:c985:: with SMTP id l127mr628915ywd.332.1566938118926; Tue, 27 Aug 2019 13:35:18 -0700 (PDT) Received: from rosewood.cam.corp.google.com ([2620:0:1013:11:89c6:2139:5435:371d]) by smtp.gmail.com with ESMTPSA id 82sm117861ywr.52.2019.08.27.13.35.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Aug 2019 13:35:18 -0700 (PDT) From: Sean Paul To: dri-devel@lists.freedesktop.org Subject: [PATCH] drm: dp_mst_topology: Ensure the proposed pbn does not exceed available bandwidth Date: Tue, 27 Aug 2019 16:35:09 -0400 Message-Id: <20190827203517.228139-1-sean@poorly.run> X-Mailer: git-send-email 2.23.0.187.g17f5b7556c-goog MIME-Version: 1.0 X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=poorly.run; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=e0xIUWcu2PtPYxUBaI6CyjPRq+fZktag3Dw+rT5KOO0=; b=Q5vThO43K7Qy4nFGtoJnddbsUk3y4R1x1e+fKiafzZnOX6T1RBNZ5Fr7iFE2ozBxfX Gndn428uD73LUsMKG/1DUd53WD0lfN4+mQ5uNb4lqDDqNj2otf2Fah0XW0t4JJj7ue0W kIvLYb/iwSGzpp2ZExEtNyBQdx5CYNSBoAcDYKh6r3kkARZ9MhjnKAC8bBWCdb4KGrgI Vc0G7sY54o0k53D09kZLO/rTsym9Jh59j4KGHwMoURBZlCTC8e4485T5bDGvK8kldM3m lX5z/31DuxEr9X178Lnuheck19kLk4DbjiiQUOgV86qP1ltvJl+V6c2cfvs5QLyehuNE pwEQ== X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Maxime Ripard , David Airlie , Sean Paul , Sean Paul Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" From: Sean Paul The PBN is calculated by the DP helpers during atomic check using the adjusted mode. In some cases, the EDID may contain modes which are not possible given the available PBN. One such example of this is if you downgrade the DP version of a 4k display from 1.2 to 1.1. The EDID would still contain the 4k mode, but it is not possible without HBR2. Another case might be if the branch device and sink have to downgrade their link speed during training. This patch checks that the proposed pbn does not exceed a port's available pbn before allocating vcpi slots. Signed-off-by: Sean Paul --- This is my first dip into MST, so it's possible (probable?) that I'm doing something wrong. However this seems to fix the issue I'm experiencing, so at least we have a base to work with. I'm more than a bit confused when available_pbn is 0, and I've tried retrying enum_path_resources and even doing a phy powerup before epr, but it still insists available_pbn=0. I've been looking at the DP 1.3 spec and it isn't too clear on why this might be. If there are better resources, I'm interested :) drivers/gpu/drm/drm_dp_mst_topology.c | 31 ++++++++++++++++++++++++++- 1 file changed, 30 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 82add736e17d..16a88230091a 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -2182,7 +2182,26 @@ static int drm_dp_send_enum_path_resources(struct drm_dp_mst_topology_mgr *mgr, DRM_ERROR("got incorrect port in response\n"); DRM_DEBUG_KMS("enum path resources %d: %d %d\n", txmsg->reply.u.path_resources.port_number, txmsg->reply.u.path_resources.full_payload_bw_number, txmsg->reply.u.path_resources.avail_payload_bw_number); - port->available_pbn = txmsg->reply.u.path_resources.avail_payload_bw_number; + + /* + * Some monitors (Samsung U28D590 at least) return 0 for + * available pbn while in low power mode. + * + * If we were to trust this value, we'd end up failing + * all vcpi allocations, since the requested bandwidth + * will be compared to 0. So use the full pbn as + * available. Doing this will cap the vcpi allocations + * at the trained link rate and will at least prevent + * us from trying to allocate payloads larger than our + * full pbn. + * + * If there is actually no bandwidth left, we'll fail + * on ALLOCATE_PAYLOAD anyways. + */ + if (txmsg->reply.u.path_resources.avail_payload_bw_number) + port->available_pbn = txmsg->reply.u.path_resources.avail_payload_bw_number; + else + port->available_pbn = txmsg->reply.u.path_resources.full_payload_bw_number; } } @@ -3239,6 +3258,16 @@ int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state, struct drm_dp_vcpi_allocation *pos, *vcpi = NULL; int prev_slots, req_slots, ret; + /* + * Sanity check that the pbn proposed doesn't exceed the maximum + * available pbn for the port. This could happen if the EDID is + * advertising a mode which needs a faster link rate than has been + * trained between the sink and the branch device (easy to repro by + * using "compatibility" mode on a 4k display and downgrading to DP 1.1) + */ + if (pbn > port->available_pbn) + return -EINVAL; + topology_state = drm_atomic_get_mst_topology_state(state, mgr); if (IS_ERR(topology_state)) return PTR_ERR(topology_state);