From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A062DC433EF for ; Tue, 26 Apr 2022 19:20:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353932AbiDZTYB (ORCPT ); Tue, 26 Apr 2022 15:24:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56516 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354122AbiDZTXz (ORCPT ); Tue, 26 Apr 2022 15:23:55 -0400 Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2DEBF2A700; Tue, 26 Apr 2022 12:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1651000846; x=1682536846; h=message-id:date:mime-version:subject:from:to:cc: references:in-reply-to:content-transfer-encoding; bh=Fmy89Zk4IfdhrvBHV8RGwaA3LuC4mMyB9cHa34B6ROM=; b=xAUQJyoNF7QOYvjCcytxPUKlvs86/Jo1KFsufERmUavaFRIz5AY+xrLt JyStpg5J/iCrYEWpIsIWvCnYGAJYdGWQ4jbQ9T7ckLp41gVAU3Qrq9DSS jD2wsh16JQXMaqUmZ7PqfqSMtcnYAIzlZVvtVZzSlqj5/tiM/GNIYcHac 8=; Received: from unknown (HELO ironmsg05-sd.qualcomm.com) ([10.53.140.145]) by alexa-out-sd-01.qualcomm.com with ESMTP; 26 Apr 2022 12:20:45 -0700 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg05-sd.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2022 12:20:45 -0700 Received: from nalasex01a.na.qualcomm.com (10.47.209.196) by nasanex01c.na.qualcomm.com (10.47.97.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Tue, 26 Apr 2022 12:20:45 -0700 Received: from [10.111.160.161] (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Tue, 26 Apr 2022 12:20:42 -0700 Message-ID: <517f71e4-785f-ef6f-d30e-fb18974eed57@quicinc.com> Date: Tue, 26 Apr 2022 12:20:40 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [PATCH 2/2] drm/probe-helper: For DP, add 640x480 if all other modes are bad Content-Language: en-US From: Abhinav Kumar To: Douglas Anderson , CC: , Thomas Zimmermann , David Airlie , , , , , , References: <20220426114627.1.I2dd93486c6952bd52f2020904de0133970d11b29@changeid> <20220426114627.2.I4ac7f55aa446699f8c200a23c10463256f6f439f@changeid> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01a.na.qualcomm.com (10.47.209.196) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Missed one more comment. On 4/26/2022 12:16 PM, Abhinav Kumar wrote: > Hi Doug > > One minor comment below. > > But otherwise, looking at this change this should work for us acc to me. > > We will test this out with our equipment and then provide R-b. > > Thanks > > Abhinav > On 4/26/2022 11:46 AM, Douglas Anderson wrote: >> As per Displayport spec section 5.2.1.2 ("Video Timing Format") says >> that all detachable sinks shall support 640x480 @60Hz as a fail safe >> mode. >> >> A DP compliance test expected us to utilize the above fact when all >> modes it presented to the DP source were not achievable. It presented >> only modes that would be achievable with more lanes and/or higher >> speeds than we had available and expected that when we couldn't do >> that then we'd fall back to 640x480 even though it didn't advertise >> this size. >> >> In order to pass the compliance test (and also support any users who >> might fall into a similar situation with their display), we need to >> add 640x480 into the list of modes. However, we don't want to add >> 640x480 all the time. Despite the fact that the DP spec says all sinks >> _shall support_ 640x480, they're not guaranteed to support it >> _well_. Continuing to read the spec you can see that the display is >> not required to really treat 640x480 equal to all the other modes. It >> doesn't need to scale or anything--just display the pixels somehow for >> failsafe purposes. It should also be noted that it's not hard to find >> a display hooked up via DisplayPort that _doesn't_ support 640x480 at >> all. The HP ZR30w screen I'm sitting in front of has a native DP port >> and doesn't work at 640x480. I also plugged in a tiny 800x480 HDMI >> display via a DP to HDMI adapter and that screen definitely doesn't >> support 640x480. >> >> As a compromise solution, let's only add the 640x480 mode if: >> * We're on DP. >> * All other modes have been pruned. >> >> This acknowledges that 640x480 might not be the best mode to use but, >> since sinks are _supposed_ to support it, we will at least fall back >> to it if there's nothing else. >> >> Note that we _don't_ add higher resolution modes like 1024x768 in this >> case. We only add those modes for a failed EDID read where we have no >> idea what's going on. In the case where we've pruned all modes then >> instead we only want 640x480 which is the only defined "Fail Safe" >> resolution. >> >> This patch originated in response to Kuogee Hsieh's patch [1]. >> >> [1] >> https://lore.kernel.org/r/1650671124-14030-1-git-send-email-quic_khsieh@quicinc.com >> >> >> Signed-off-by: Douglas Anderson >> --- >> >>   drivers/gpu/drm/drm_probe_helper.c | 26 +++++++++++++++++++++----- >>   1 file changed, 21 insertions(+), 5 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_probe_helper.c >> b/drivers/gpu/drm/drm_probe_helper.c >> index 819225629010..90cd46cbfec1 100644 >> --- a/drivers/gpu/drm/drm_probe_helper.c >> +++ b/drivers/gpu/drm/drm_probe_helper.c >> @@ -476,7 +476,6 @@ int drm_helper_probe_single_connector_modes(struct >> drm_connector *connector, >>       const struct drm_connector_helper_funcs *connector_funcs = >>           connector->helper_private; >>       int count = 0, ret; >> -    bool verbose_prune = true; >>       enum drm_connector_status old_status; >>       struct drm_modeset_acquire_ctx ctx; >> @@ -556,8 +555,8 @@ int drm_helper_probe_single_connector_modes(struct >> drm_connector *connector, >>           DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n", >>               connector->base.id, connector->name); >>           drm_connector_update_edid_property(connector, NULL); >> -        verbose_prune = false; >> -        goto prune; >> +        drm_mode_prune_invalid(dev, &connector->modes, false); >> +        goto exit; >>       } >>       count = (*connector_funcs->get_modes)(connector); >> @@ -580,9 +579,26 @@ int >> drm_helper_probe_single_connector_modes(struct drm_connector *connector, >>           } >>       } >> -prune: >> -    drm_mode_prune_invalid(dev, &connector->modes, verbose_prune); >> +    drm_mode_prune_invalid(dev, &connector->modes, true); >> +    /* >> +     * Displayport spec section 5.2.1.2 ("Video Timing Format") says >> that >> +     * all detachable sinks shall support 640x480 @60Hz as a fail safe >> +     * mode. If all modes were pruned, perhaps because they need more >> +     * lanes or a higher pixel clock than available, at least try to add >> +     * in 640x480. >> +     */ >> +    if (list_empty(&connector->modes) && >> +        connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) { >> +        count = drm_add_modes_noedid(connector, 640, 480); >> +        if (_drm_helper_update_and_validate(connector, maxX, maxY, >> &ctx)) { >> +            drm_modeset_backoff(&ctx); >> +            goto retry; > > Do we need another retry here? This will again repeat everything from > get_modes(). > The fact that we are hitting this code is because we have already tried > that and this is already a second-pass. So I think another retry isnt > needed? This will help cover the case of 4.2.2.6 but not fix 4.2.2.1. For 4.2.2.1, we will have 0 modes and so the original DRM fwk code of adding all modes <= 1024x768 will kick in. Now, in that list, we will still need to pick/mark 640x480 as the preferred mode. We still need IGT for that. So yes, this will cover one of the test but not the other. > >> +        } >> +        drm_mode_prune_invalid(dev, &connector->modes, true); >> +    } >> + >> +exit: >>       drm_modeset_drop_locks(&ctx); >>       drm_modeset_acquire_fini(&ctx);