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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 2DCADC10DCE for ; Fri, 13 Mar 2020 18:17:10 +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 DF8B120674 for ; Fri, 13 Mar 2020 18:17:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DF8B120674 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.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 854A06EC43; Fri, 13 Mar 2020 18:17:09 +0000 (UTC) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTPS id C77FE6EC43 for ; Fri, 13 Mar 2020 18:17:07 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Mar 2020 11:17:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,549,1574150400"; d="scan'208";a="237311628" Received: from eliteleevi.tm.intel.com ([10.237.54.20]) by orsmga008.jf.intel.com with ESMTP; 13 Mar 2020 11:17:05 -0700 Date: Fri, 13 Mar 2020 20:17:05 +0200 (EET) From: Kai Vehmanen X-X-Sender: kvehmane@eliteleevi.tm.intel.com To: =?ISO-8859-15?Q?Ville_Syrj=E4l=E4?= In-Reply-To: <20200313151443.GO13686@intel.com> Message-ID: References: <20200313144821.29592-1-kai.vehmanen@linux.intel.com> <20200313144821.29592-2-kai.vehmanen@linux.intel.com> <20200313151443.GO13686@intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7 02160 Espoo MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-318106570-1302833355-1584121445=:2957" Content-ID: Subject: Re: [Intel-gfx] [PATCH 2/2] drm/i915: move audio CDCLK constraint setup to bind/unbind 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: Takashi Iwai , intel-gfx@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---318106570-1302833355-1584121445=:2957 Content-Type: text/plain; CHARSET=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-ID: Hey, On Fri, 13 Mar 2020, Ville Syrjälä wrote: > On Fri, Mar 13, 2020 at 04:48:21PM +0200, Kai Vehmanen wrote: >> This patch moves modifying the min_cdclk at audio component bind >> phase and extends coverage to all gen9+ platforms. This effectively > > So this will now force BXT to never use the 144 MHz CDCLK too. Is that > actually required? I don't remember any reports of failures on BXT. yes it will force it higher. I can't really explain why it works. 144Mhz is well above BCLK, so most of the time it will work, but it is still out of spec. I do know that on more recent hardware (gen12), I will get failures if I don't strictly follow the requirement. GLK is a special case as it has the 79Mhz low cdclk. I've not been able to trigger the problem on other old hardware though. So where to draw the line? It's a fair point that if the old platforms have worked so far, we should not make the change unless there is at least one data point supporting it. So the constraint would then apply for gen12+ and glk. Now thinking of another possibility, is it possible to hook code to power-up of power domains? E.g. can I hook custom code which is executed in sync with power wells going up and down? If we could reprogram AUD_FREQ_CNTRL outside the get/put_power() flow (i.e. independently from audio driver), and guarantee that if the display side is powered on, the link params are always correct, it might be possible to get away without calling get_power() from audio controller reset. Worth a shot probably before we merge this. >> + if (INTEL_GEN(dev_priv) >= 9) >> + glk_force_audio_cdclk(dev_priv, true); > > Ah, so we still keep it on the i915 side. That seems fine. We can then > stop doing this once we get nicer hardware and put it back into to > get/put power. OTOH, if we restrict this to gen12+-and-glk, the glk_ prefix makes sense again. Br, Kai ---318106570-1302833355-1584121445=:2957 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ---318106570-1302833355-1584121445=:2957--