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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E886CC433ED for ; Tue, 11 May 2021 14:31:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BD13161260 for ; Tue, 11 May 2021 14:31:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231793AbhEKOcr (ORCPT ); Tue, 11 May 2021 10:32:47 -0400 Received: from mga14.intel.com ([192.55.52.115]:32906 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231154AbhEKOcl (ORCPT ); Tue, 11 May 2021 10:32:41 -0400 IronPort-SDR: iH4gk33J4A9XjfMEBwy5vLkq3wBh5PEIp4n0qsDzK/7hAH3psz+8ADpMfnmnfFKkPzzAEj0t1f N6tShNC8+GCQ== X-IronPort-AV: E=McAfee;i="6200,9189,9981"; a="199136065" X-IronPort-AV: E=Sophos;i="5.82,290,1613462400"; d="scan'208";a="199136065" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 May 2021 07:31:34 -0700 IronPort-SDR: qCrlyJaXV9SkWdyIBZnuzQfHfOzwIA2iGRu3+gEIzlGkGc3Hzn1V4Z7U4hKBYsQ7qAhxmQvSay n9icrFIsSrtQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,290,1613462400"; d="scan'208";a="434471084" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.171]) by fmsmga008.fm.intel.com with SMTP; 11 May 2021 07:31:31 -0700 Received: by stinkbox (sSMTP sendmail emulation); Tue, 11 May 2021 17:31:30 +0300 Date: Tue, 11 May 2021 17:31:30 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Werner Sembach Cc: airlied@linux.ie, daniel@ffwll.ch, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v7 0/3] drm/i915/display: Try YCbCr420 color when RGB fails Message-ID: References: <20210510133349.14491-1-wse@tuxedocomputers.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210510133349.14491-1-wse@tuxedocomputers.com> X-Patchwork-Hint: comment Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 10, 2021 at 03:33:46PM +0200, Werner Sembach wrote: > When encoder validation of a display mode fails, retry with less bandwidth > heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups > to support 4k60Hz output, which previously failed silently. > > AMDGPU had nearly the exact same issue. This problem description is > therefore copied from my commit message of the AMDGPU patch. > > On some setups, while the monitor and the gpu support display modes with > pixel clocks of up to 600MHz, the link encoder might not. This prevents > YCbCr444 and RGB encoding for 4k60Hz, but YCbCr420 encoding might still be > possible. However, which color mode is used is decided before the link > encoder capabilities are checked. This patch fixes the problem by retrying > to find a display mode with YCbCr420 enforced and using it, if it is > valid. > > This patchset is revision 7. Fixed a rebase issue in 1/3 and moved message > from error output to debug output in 2/3. Looks good and CI seem shappy. Series pushed to drm-intel-next. Thanks. -- Ville Syrjälä Intel