From patchwork Fri Aug 18 16:41:41 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stanislav Lisovskiy X-Patchwork-Id: 13358009 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id D9293C71159 for ; Fri, 18 Aug 2023 16:41:52 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5BD0110E0BF; Fri, 18 Aug 2023 16:41:52 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTPS id 5838C10E0CF for ; Fri, 18 Aug 2023 16:41:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1692376908; x=1723912908; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=eos6xE67/MTat/Rx8TmaEG3EoGj/Yb37tOj3Wsu4jHA=; b=cAOH+HlHZe5R7UZUSX7ZwlHHVkNYExGTVYTD+v/kBt6wD+D4Spdkyckj 9Ho1LC1y/AdsVAzbWaDSZGbLcMvcn8et2q/9J6BIcblwS1CYvMwkjmA29 Pao75Yz+1n3+4r5bsHUEnX5NJYl+1JDzcYErceiKv7XKE0a0hsuWVbdbm Ska1Q7Tffef1pzjLRPO1hj6ogKBUYFnOKu2s6wFI8nzTHJ3nG/E8u8Ac/ UjPz8Nxrv2HysZu9Aer5BPUfDBMhyFR9wCeGs0Vv5JVs5+vO7imqoEgHi se/MWiQx6LKMO2HgK43uLim6IyiZ87TXPK7Pi+tO7Hg8cO4KxrVcN4HZG g==; X-IronPort-AV: E=McAfee;i="6600,9927,10806"; a="370600415" X-IronPort-AV: E=Sophos;i="6.01,183,1684825200"; d="scan'208";a="370600415" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Aug 2023 09:41:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10806"; a="728653621" X-IronPort-AV: E=Sophos;i="6.01,183,1684825200"; d="scan'208";a="728653621" Received: from unknown (HELO slisovsk-Lenovo-ideapad-720S-13IKB.fi.intel.com) ([10.237.72.65]) by orsmga007.jf.intel.com with ESMTP; 18 Aug 2023 09:41:46 -0700 From: Stanislav Lisovskiy To: intel-gfx@lists.freedesktop.org Date: Fri, 18 Aug 2023 19:41:41 +0300 Message-Id: <20230818164142.27045-2-stanislav.lisovskiy@intel.com> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20230818164142.27045-1-stanislav.lisovskiy@intel.com> References: <20230818164142.27045-1-stanislav.lisovskiy@intel.com> MIME-Version: 1.0 Subject: [Intel-gfx] [PATCH 1/2] drm/i915: Update mbus in intel_dbuf_mbus_update and do it properly 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: jani.nikula@intel.com Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" According to BSpec we need to do correspondent MBUS updates before or after DBUF reallocation, depending on whether we are reducing or increasing amount of pipes(typical scenario is swithing between multiple and single displays). As of BSpec 49213 if we are swithing from multiple to single display MBUS registers should be updated with correspondent values _before_ Dbuf reallocation happens, however if we are switching from single display to multiple then it should happen _after_ DDB reallocation(i.e plane programming). Signed-off-by: Stanislav Lisovskiy --- drivers/gpu/drm/i915/display/skl_watermark.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c b/drivers/gpu/drm/i915/display/skl_watermark.c index 063929a42a42f..af99f2abd8446 100644 --- a/drivers/gpu/drm/i915/display/skl_watermark.c +++ b/drivers/gpu/drm/i915/display/skl_watermark.c @@ -3474,7 +3474,7 @@ int intel_dbuf_init(struct drm_i915_private *i915) * Configure MBUS_CTL and all DBUF_CTL_S of each slice to join_mbus state before * update the request state of all DBUS slices. */ -static void update_mbus_pre_enable(struct intel_atomic_state *state) +static void intel_dbuf_mbus_update(struct intel_atomic_state *state) { struct drm_i915_private *i915 = to_i915(state->base.dev); u32 mbus_ctl, dbuf_min_tracker_val; @@ -3524,7 +3524,9 @@ void intel_dbuf_pre_plane_update(struct intel_atomic_state *state) WARN_ON(!new_dbuf_state->base.changed); - update_mbus_pre_enable(state); + if (hweight8(new_dbuf_state->active_pipes) <= hweight8(old_dbuf_state->active_pipes)) + intel_dbuf_mbus_update(state); + gen9_dbuf_slices_update(i915, old_dbuf_state->enabled_slices | new_dbuf_state->enabled_slices); @@ -3545,6 +3547,9 @@ void intel_dbuf_post_plane_update(struct intel_atomic_state *state) WARN_ON(!new_dbuf_state->base.changed); + if (hweight8(new_dbuf_state->active_pipes) > hweight8(old_dbuf_state->active_pipes)) + intel_dbuf_mbus_update(state); + gen9_dbuf_slices_update(i915, new_dbuf_state->enabled_slices); } From patchwork Fri Aug 18 16:41:42 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stanislav Lisovskiy X-Patchwork-Id: 13358010 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 9C9D2C7EE2C for ; Fri, 18 Aug 2023 16:41:54 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2C17310E0CF; Fri, 18 Aug 2023 16:41:53 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7323910E0BF for ; Fri, 18 Aug 2023 16:41:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1692376910; x=1723912910; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=EUhH1rYBou5l1L1uw1FrI4aLuOu3tE1sa5d51D/TfYU=; b=g/m06K9S97JLd8iqInlelz7EmAaw9IiZSRUIy/EdAd1IiPuRq74GlFLf nTGEpfdr/3LmsQiGbWQ23yBoQzkVZ75ebhEVyv0EyjvGmuQBlaUW/KZhu dQojcYI9ca9qMBa/Nfx0k4sNmJw+naZd0v3g5rf7xeuJIzE4/PIRdCetA qLJPu0ItHGCABAm4Sccn/83TaEY6O/p3/A+fb3odr4WbfdKkwdtj8tcSH Klh3KSOkPTVxmIAOoB/KezgKxvBYFwoNgUfCDTKdSURTFMpKKbi1OjP+4 NG3uJMfxtSUeq3/vcKkyqlfbCyAvTGec97SYFVLbMmUzU3ZdZO91b8P0w Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10806"; a="370600418" X-IronPort-AV: E=Sophos;i="6.01,183,1684825200"; d="scan'208";a="370600418" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Aug 2023 09:41:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10806"; a="728653642" X-IronPort-AV: E=Sophos;i="6.01,183,1684825200"; d="scan'208";a="728653642" Received: from unknown (HELO slisovsk-Lenovo-ideapad-720S-13IKB.fi.intel.com) ([10.237.72.65]) by orsmga007.jf.intel.com with ESMTP; 18 Aug 2023 09:41:48 -0700 From: Stanislav Lisovskiy To: intel-gfx@lists.freedesktop.org Date: Fri, 18 Aug 2023 19:41:42 +0300 Message-Id: <20230818164142.27045-3-stanislav.lisovskiy@intel.com> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20230818164142.27045-1-stanislav.lisovskiy@intel.com> References: <20230818164142.27045-1-stanislav.lisovskiy@intel.com> MIME-Version: 1.0 Subject: [Intel-gfx] [PATCH 2/2] drm/i915: Implement vblank synchronized MBUS join changes 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: jani.nikula@intel.com Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Currently we can't change MBUS join status without doing a modeset, because we are lacking mechanism to synchronize those with vblank. However then this means that we can't do a fastset, if there is a need to change MBUS join state. Fix that by implementing such change. We already call correspondent check and update at pre_plane dbuf update, so the only thing left is to have a non-modeset version of that. If active pipes stay the same then fastset is possible and only MBUS join state/ddb allocation updates would be committed. v2: Implement additional changes according to BSpec. Vblank wait is needed after MBus/Dbuf programming in case if no modeset is done and we are switching from single to multiple displays, i.e mbus join state switches from "joined" to "non-joined" state. Otherwise vblank wait is not needed according to spec. v3: Split mbus and dbox programming into to pre/post plane update parts, how it should be done according to BSpec. Signed-off-by: Stanislav Lisovskiy Tested-by: Khaled Almahallawy --- drivers/gpu/drm/i915/display/intel_display.c | 2 -- drivers/gpu/drm/i915/display/skl_watermark.c | 36 +++++++++++++++----- 2 files changed, 27 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 8c81206ce90d7..249ba955cce2a 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -7041,9 +7041,7 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state) } intel_encoders_update_prepare(state); - intel_dbuf_pre_plane_update(state); - intel_mbus_dbox_update(state); for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) { if (new_crtc_state->do_async_flip) diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c b/drivers/gpu/drm/i915/display/skl_watermark.c index af99f2abd8446..b5c5fa9ecf43c 100644 --- a/drivers/gpu/drm/i915/display/skl_watermark.c +++ b/drivers/gpu/drm/i915/display/skl_watermark.c @@ -2614,13 +2614,6 @@ skl_compute_ddb(struct intel_atomic_state *state) if (ret) return ret; - if (old_dbuf_state->joined_mbus != new_dbuf_state->joined_mbus) { - /* TODO: Implement vblank synchronized MBUS joining changes */ - ret = intel_modeset_all_pipes(state, "MBUS joining change"); - if (ret) - return ret; - } - drm_dbg_kms(&i915->drm, "Enabled dbuf slices 0x%x -> 0x%x (total dbuf slices 0x%x), mbus joined? %s->%s\n", old_dbuf_state->enabled_slices, @@ -3524,8 +3517,15 @@ void intel_dbuf_pre_plane_update(struct intel_atomic_state *state) WARN_ON(!new_dbuf_state->base.changed); - if (hweight8(new_dbuf_state->active_pipes) <= hweight8(old_dbuf_state->active_pipes)) + /* + * Switching from multiple to single display scenario. + * Also we put here "<=" instead of "<" for suboptimal cases, when + * we switch from single => single display, enabling mbus join. + */ + if (hweight8(new_dbuf_state->active_pipes) <= hweight8(old_dbuf_state->active_pipes)) { intel_dbuf_mbus_update(state); + intel_mbus_dbox_update(state); + } gen9_dbuf_slices_update(i915, old_dbuf_state->enabled_slices | @@ -3547,8 +3547,26 @@ void intel_dbuf_post_plane_update(struct intel_atomic_state *state) WARN_ON(!new_dbuf_state->base.changed); - if (hweight8(new_dbuf_state->active_pipes) > hweight8(old_dbuf_state->active_pipes)) + /* + * Switching from single to multiple display scenario + */ + if (hweight8(new_dbuf_state->active_pipes) > hweight8(old_dbuf_state->active_pipes)) { + struct intel_crtc *crtc; + struct intel_crtc_state *old_crtc_state; + int i; intel_dbuf_mbus_update(state); + intel_mbus_dbox_update(state); + + for_each_old_intel_crtc_in_state(state, crtc, old_crtc_state, i) { + /* + * According to BSpec we should wait vblank on previously single display + */ + if (!old_crtc_state->hw.active) + continue; + + intel_crtc_wait_for_next_vblank(crtc); + } + } gen9_dbuf_slices_update(i915, new_dbuf_state->enabled_slices);