From patchwork Wed Jun 13 18:41:57 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Kumar, Abhay" X-Patchwork-Id: 10462835 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 48564603B4 for ; Wed, 13 Jun 2018 18:43:50 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3357D290A7 for ; Wed, 13 Jun 2018 18:43:50 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 31D60290C1; Wed, 13 Jun 2018 18:43:50 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id AD01028A20 for ; Wed, 13 Jun 2018 18:43:49 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E59B96E19F; Wed, 13 Jun 2018 18:43:44 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTPS id ED23289FA0 for ; Wed, 13 Jun 2018 18:43:42 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jun 2018 11:43:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,220,1526367600"; d="scan'208";a="47516785" Received: from abhaykum-lin.sc.intel.com ([10.3.62.173]) by fmsmga008.fm.intel.com with ESMTP; 13 Jun 2018 11:43:40 -0700 From: Abhay Kumar To: intel-gfx@lists.freedesktop.org, ville.syrjala@intel.com Date: Wed, 13 Jun 2018 11:41:57 -0700 Message-Id: <1528915317-14156-5-git-send-email-abhay.kumar@intel.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1528915317-14156-1-git-send-email-abhay.kumar@intel.com> References: <1528915317-14156-1-git-send-email-abhay.kumar@intel.com> MIME-Version: 1.0 Subject: [Intel-gfx] [PATCH v4 4/4] drm/i915: Shut off PW2 when changing cdclk on glk X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 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" X-Virus-Scanned: ClamAV using ClamSMTP From: Ville Syrjälä Apparently the audio hardware gets confused if it's powered up when change the cdclk frequency. Force PW2 (which is where audio lives) off when we do the cdclk reprogramming. This is a rather big hack. If something is using PW2 when we do this things wil break. I don't think there should be anything active on the display side since we've turned off all the pipes and we've locked out gmbus and aux, but I may be overlooking something. The problem is more on the audio side. If audio is active when we do this PW2 toggle I'm sure something "interesting" will happen. But presumably something would also happen if we just changed cdclk without the PW2 toggle. A better fix would involve somehow forcing everything to drop their PW2 references, which isn't trivial. And to make the audio driver participate in this scheme we'd definitely need some kind of pre/post cdclk change notify hooks in the audio component so that i915 can actually inform the audio driver that the cdclk is going to be changed. Either that or the audio driver would have to promise never to touch the hardware when the pipes are off (which is how the VLV/CHV LPE audio driver works IIRC). Even with this hacky scheme it would make more sense to me to have the pre/post cdclk change hooks so that the audio driver is actually informed when the cdclk change/pw2 toggle will occur. What the audio driver would do to prepare itself I don't actually know. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_cdclk.c | 14 ++++++++++++++ drivers/gpu/drm/i915/intel_drv.h | 5 +++++ drivers/gpu/drm/i915/intel_runtime_pm.c | 34 +++++++++++++++++++++++++++++++++ 3 files changed, 53 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c index ebfafef7bf88..206f573c89b1 100644 --- a/drivers/gpu/drm/i915/intel_cdclk.c +++ b/drivers/gpu/drm/i915/intel_cdclk.c @@ -1356,6 +1356,7 @@ static void bxt_set_cdclk(struct drm_i915_private *dev_priv, { int cdclk = cdclk_state->cdclk; int vco = cdclk_state->vco; + bool enable_pw2 = false; u32 val, divider; int ret; @@ -1381,6 +1382,14 @@ static void bxt_set_cdclk(struct drm_i915_private *dev_priv, } /* + * On GLK HDA apparently gets confused if + * cdclk is changed while PW2 is on + */ + if (IS_GEMINILAKE(dev_priv)) + enable_pw2 = intel_display_power_toggle_start(dev_priv, + SKL_DISP_PW_2); + + /* * Inform power controller of upcoming frequency change. BSpec * requires us to wait up to 150usec, but that leads to timeouts; * the 2ms used here is based on experiment. @@ -1437,6 +1446,11 @@ static void bxt_set_cdclk(struct drm_i915_private *dev_priv, } intel_update_cdclk(dev_priv); + + if (IS_GEMINILAKE(dev_priv)) + intel_display_power_toggle_end(dev_priv, + SKL_DISP_PW_2, + enable_pw2); } static void bxt_sanitize_cdclk(struct drm_i915_private *dev_priv) diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index c77942adda22..e92ea5eff46f 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -1964,6 +1964,11 @@ bool intel_display_power_get_if_enabled(struct drm_i915_private *dev_priv, enum intel_display_power_domain domain); void intel_display_power_put(struct drm_i915_private *dev_priv, enum intel_display_power_domain domain); +bool intel_display_power_toggle_start(struct drm_i915_private *dev_priv, + enum i915_power_well_id power_well_id); +void intel_display_power_toggle_end(struct drm_i915_private *dev_priv, + enum i915_power_well_id power_well_id, + bool enable); void icl_dbuf_slices_update(struct drm_i915_private *dev_priv, u8 req_slices); diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c index 53a6eaa9671a..86a4b788e224 100644 --- a/drivers/gpu/drm/i915/intel_runtime_pm.c +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c @@ -2809,6 +2809,40 @@ static void skl_display_core_uninit(struct drm_i915_private *dev_priv) usleep_range(10, 30); /* 10 us delay per Bspec */ } +bool intel_display_power_toggle_start(struct drm_i915_private *dev_priv, + enum i915_power_well_id power_well_id) +{ + struct i915_power_domains *power_domains = &dev_priv->power_domains; + struct i915_power_well *well = lookup_power_well(dev_priv, power_well_id); + bool was_enabled; + + mutex_lock(&power_domains->lock); + + was_enabled = well->hw_enabled; + + if (was_enabled) + intel_power_well_disable(dev_priv, well); + + return was_enabled; +} + +void intel_display_power_toggle_end(struct drm_i915_private *dev_priv, + enum i915_power_well_id power_well_id, + bool enable) +{ + struct i915_power_domains *power_domains = &dev_priv->power_domains; + struct i915_power_well *well = lookup_power_well(dev_priv, power_well_id); + + lockdep_assert_held(&power_domains->lock); + + if (enable) { + WARN_ON(well->hw_enabled); + intel_power_well_enable(dev_priv, well); + } + + mutex_unlock(&power_domains->lock); +} + void bxt_display_core_init(struct drm_i915_private *dev_priv, bool resume) {