Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp4247825pxk; Tue, 22 Sep 2020 14:25:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwGUHNf3zCCK11LqeSg6PldPmhaLkRTGkdnxGCU0PLHUDghxLw2r3T5qkpO/nY0NivfJzYs X-Received: by 2002:a17:906:3494:: with SMTP id g20mr7006829ejb.486.1600809908003; Tue, 22 Sep 2020 14:25:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600809907; cv=none; d=google.com; s=arc-20160816; b=WUpnxR42Pnp5gldWSaZqFvPMW+Rm+IOmUJ5gFQgNQtkKfYbnUmESpOBBOsFUFDVPpu ghEWVg6xq047wCa8iWLkiOQRAYk1U0K/5tlFH5/vsNXh4YUglSYKH9eLN8bY3RvBcEbc DSjjaJllS6Ffs3JdXNRVvLXshSAEsoVlThfIIvFBStv/bInKynjA9/xxWMY3vIDQrxGS DHTGApXkq87ONcvAf7UqmoruBm+X3OaOvNCMkIcr386VIoAZm52aC7mJFWZEeVun97EE hU8edfsKixa6qlkljTPx8XdxGxaDliF+ASmO3JLbCTTy3io/zcJmobPs5GkuwmrbsoPQ P9Lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=QNfsE0e5j0sjDrSbMU06dsnlI5tq+95f3KQ29B+CI20=; b=Ga1yFjDZNjlFCC3JhZh+VDwLtIY62aFo5XdZa4nORcHVagY18RAxLVZMsYg3Xm2y4X 8bnzGYi374etQjA6zBUiY2fTD//iP5BrpTLLDVZOa0a3lWlhhX9Q0JSpeP2Zql1e8GQf 1U529urgpmmJkRFDv0nLnG09/3rMftwTwsiLVHQ6ySFz6c1RpfqYTzl8zrXtOOp06sAQ i5+V96C2nXSWuxgD1vRt9/0tlh5OZrq6Q3LHe6X6Kd26NXXWcs1UWfPnkMFyhQjqmUrJ zuAtC0qWc9ZOcnUyBd3ZSYUtdfCPTS10o9Pkv538/sKFntKXeW+5SlSrEVNh0GWkf4IH kIZw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id nr20si11554894ejb.483.2020.09.22.14.24.43; Tue, 22 Sep 2020 14:25:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726620AbgIVVWf (ORCPT + 99 others); Tue, 22 Sep 2020 17:22:35 -0400 Received: from mail-vs1-f66.google.com ([209.85.217.66]:39838 "EHLO mail-vs1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726179AbgIVVWf (ORCPT ); Tue, 22 Sep 2020 17:22:35 -0400 Received: by mail-vs1-f66.google.com with SMTP id 7so11176545vsp.6 for ; Tue, 22 Sep 2020 14:22:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QNfsE0e5j0sjDrSbMU06dsnlI5tq+95f3KQ29B+CI20=; b=BqOwgo+2yTe5WmvoceJmxnno9DA9xCYr9jnSqK9yDlvM1ofqt0mi22pQUmZsHOeC8G HctoXzyZJhxRmN5/GEp0Vo/pldJlYxCmywgrfRrJuhWlFrAMjWGsqmqrHCZqV7RoBy/V /EGopSpkIcK8K0zCkqADjyX6Jyh513Wq5k4Bv6rfj/T4IURKKq1xwvad2WstsHcovtMY uA4vMdWqRmuqEnL/EMlCvbp+1AstGe9opWYLtXtxt3rEvpOztQgnLA3cr1XEWK/1jdYs EXsS23yJIwA/b/9Bm1XWzJkPzoP/8kic+1r8RK6bjcpTsBybTtcTvZQ3qQlSrHXzSxsj RIow== X-Gm-Message-State: AOAM533YN3RAC7jtwHDXBTWpWgUigWoLf8nwVGKPIKsRw7BLJyRswCB0 AvNqhWZ+Li8gaqrS5D8IWohX5ut/Z+ZXS7s8OzkyDnHppZw= X-Received: by 2002:a67:6954:: with SMTP id e81mr5330189vsc.0.1600809754259; Tue, 22 Sep 2020 14:22:34 -0700 (PDT) MIME-Version: 1.0 References: <20200922210510.156220-1-lyude@redhat.com> <7b10668ee337e531b14705ebecb1f6c1004728d6.camel@redhat.com> In-Reply-To: <7b10668ee337e531b14705ebecb1f6c1004728d6.camel@redhat.com> From: Ilia Mirkin Date: Tue, 22 Sep 2020 17:22:23 -0400 Message-ID: Subject: Re: [PATCH] drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid() To: Lyude Paul Cc: nouveau , David Airlie , open list , "open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS" , Ben Skeggs Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul wrote: > > On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote: > > Can we use 6bpc on arbitrary DP monitors, or is there a capability for > > it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8? > > I don't think that display_info.bpc actually implies a minimum bpc, only a > maximum bpc iirc (Ville would know the answer to this one). The other thing to > note here is that we want to assume the lowest possible bpc here since we're > only concerned if the mode passed to ->mode_valid can be set under -any- > conditions (including those that require lowering the bpc beyond it's maximum > value), so we definitely do want to always use 6bpc here even once we get > support for optimizing the bpc based on the available display bandwidth. Yeah, display_info is the max bpc. But would an average monitor support 6bpc? And if it does, does the current link training code even try that when display_info.bpc != 6? -ilia