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=-8.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 9978AC433E0 for ; Wed, 1 Jul 2020 19:13:41 +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 7C1D120720 for ; Wed, 1 Jul 2020 19:13:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7C1D120720 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1C9B66E9D1; Wed, 1 Jul 2020 19:13:41 +0000 (UTC) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by gabe.freedesktop.org (Postfix) with ESMTPS id 378776E9CA for ; Wed, 1 Jul 2020 19:13:39 +0000 (UTC) IronPort-SDR: LvEPWT7/Kme3xwfNcv+e1QCbKBMFY1yUiw3hMQqemoorQNYzAOuriCFjiNjhxYgwF1F5YZV9Ms +60hmlp7j8tQ== X-IronPort-AV: E=McAfee;i="6000,8403,9669"; a="144201238" X-IronPort-AV: E=Sophos;i="5.75,301,1589266800"; d="scan'208";a="144201238" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2020 12:13:38 -0700 IronPort-SDR: 5sgNaXOiMozkLM/Tvxv/9q9opgx//nStoiiVgf/u+0pYhq5FPxVQSJHVcOTsJj6Agh7i0kw1h1 ijP3++JW1Imw== X-IronPort-AV: E=Sophos;i="5.75,301,1589266800"; d="scan'208";a="455215594" Received: from slisovsk-lenovo-ideapad-720s-13ikb.fi.intel.com (HELO intel.com) ([10.237.72.190]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2020 12:13:36 -0700 Date: Wed, 1 Jul 2020 22:13:32 +0300 From: "Lisovskiy, Stanislav" To: Manasi Navare Message-ID: <20200701191332.GB17127@intel.com> References: <20200630112609.9998-1-stanislav.lisovskiy@intel.com> <4d307447-fbf3-e39d-3627-e6b52e0e9e2e@linux.intel.com> <20200701184403.GA25635@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200701184403.GA25635@intel.com> User-Agent: Mutt/1.9.4 (2018-02-28) Subject: Re: [Intel-gfx] [PATCH v1] drm/i915: Clamp min_cdclk to max_cdclk_freq to unblock 8K X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx@lists.freedesktop.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Wed, Jul 01, 2020 at 11:44:04AM -0700, Manasi Navare wrote: > On Wed, Jul 01, 2020 at 02:20:28PM +0200, Maarten Lankhorst wrote: > > Op 30-06-2020 om 13:26 schreef Stanislav Lisovskiy: > > > We still need "Bump up CDCLK" workaround otherwise getting > > > underruns - however currently it blocks 8K as CDCLK = Pixel rate, > > > in 8K case would require CDCLK to be around 1 Ghz which is not > > > possible. > > > > > > Signed-off-by: Stanislav Lisovskiy > > > --- > > > drivers/gpu/drm/i915/display/intel_cdclk.c | 14 +++++++++++++- > > > 1 file changed, 13 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c > > > index 45f7f33d1144..01a5bc6b08c4 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c > > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c > > > @@ -2080,9 +2080,21 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state) > > > * Explicitly stating here that this seems to be currently > > > * rather a Hack, than final solution. > > > */ > > > - if (IS_TIGERLAKE(dev_priv)) > > > + if (IS_TIGERLAKE(dev_priv)) { > > > min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate); > > > > > > + /* > > > + * Clamp to max_cdclk_freq in order not to break an 8K, > > > + * but still leave W/A at place. > > > + */ > > > + min_cdclk = min(min_cdclk, (int)dev_priv->max_cdclk_freq); > > > + > > > + /* > > > + * max_cdclk_freq check obviously not needed - just return. > > > + */ > > > + return min_cdclk; > > > + } > > > + > > > if (min_cdclk > dev_priv->max_cdclk_freq) { > > > drm_dbg_kms(&dev_priv->drm, > > > "required cdclk (%d kHz) exceeds max (%d kHz)\n", > > > > Wouldn't you just have to halve pixel_rate if bigjoiner flag is set? > > We dont have big joiner patches pulled in yet, this is just for the 2p2p configuration > > Manasi Also it would make more sense if we wanted this to stay here, however I still want to believe that some day(R) we figure out proper solution. Otherwise yep, we would need some logic to check if the pixel rate should be divided and etc.. Stan > > > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx