From nobody Fri Dec 26 21:41:11 2025 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5AEBA171CC; Wed, 3 Jan 2024 04:13:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Y1jHi2nH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1704255205; x=1735791205; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=GodFJtwqMnS+/ioQmjffko5s7Jn4rmDVSRk74S/bLAc=; b=Y1jHi2nHzUMGGsTLtMQv3hwdADe2KKpOOWT9ZQR/DADI6mVo9zNCvJFA J37akexFnknXQG+KeI9FxnZRFc0Oocb1CRK17Y0vBAcC0OYG0whc3GnVV TJtZdPQ6J4TvhSvlZC4mByMJzk6OKxwNCQ7tpfd/64J/0yx9g1x+uNbB0 dFJvGO1UoCvCVpilmA5pN7IWW1pBEht+iCzQpopZ+73E+fQbzy541qTXA 9UgoWeoKa/9w0Y5CqhSOqNMl9xWJcmokNx8wKAq+RqNEHreNLi8oJ8y/x nGLRc/JDn3niSUMtf8P7rqmuqWlffFB2pnp18fiRtIZ1UHj1jIGszpBWc w==; X-IronPort-AV: E=McAfee;i="6600,9927,10941"; a="463357398" X-IronPort-AV: E=Sophos;i="6.04,326,1695711600"; d="scan'208";a="463357398" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jan 2024 20:13:21 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10941"; a="1026957011" X-IronPort-AV: E=Sophos;i="6.04,326,1695711600"; d="scan'208";a="1026957011" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by fmsmga006.fm.intel.com with ESMTP; 02 Jan 2024 20:13:21 -0800 From: Ricardo Neri To: "Rafael J. Wysocki" Cc: Chen Yu , Len Brown , Srinivas Pandruvada , Stanislaw Gruszka , Zhang Rui , Zhao Liu , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 3/4] thermal: intel: hfi: Disable an HFI instance when all its CPUs go offline Date: Tue, 2 Jan 2024 20:14:58 -0800 Message-Id: <20240103041459.11113-4-ricardo.neri-calderon@linux.intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20240103041459.11113-1-ricardo.neri-calderon@linux.intel.com> References: <20240103041459.11113-1-ricardo.neri-calderon@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" In preparation to support hibernation, add functionality to disable an HFI instance during CPU offline. The last CPU of an instance that goes offline will disable such instance. The Intel Software Development Manual states that the operating system must wait for the hardware to set MSR_IA32_PACKAGE_THERM_STATUS[26] after disabling an HFI instance to ensure that it will no longer write on the HFI memory. Some processors, however, do not ever set such bit. Wait a minimum of 2ms to give time hardware to complete any pending memory writes. Cc: Chen Yu Cc: Len Brown Cc: Srinivas Pandruvada Cc: Stanislaw Gruszka Cc: Zhang Rui Cc: Zhao Liu Cc: linux-pm@vger.kernel.org Cc: stable@vger.kernel.org # 6.1 Signed-off-by: Ricardo Neri --- Changes since v1: * Relocated here comment about not freeing the HFI pages. (Rafael) --- drivers/thermal/intel/intel_hfi.c | 35 +++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/drivers/thermal/intel/intel_hfi.c b/drivers/thermal/intel/inte= l_hfi.c index 713da8befd40..22445403b520 100644 --- a/drivers/thermal/intel/intel_hfi.c +++ b/drivers/thermal/intel/intel_hfi.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include #include @@ -367,6 +368,32 @@ static void hfi_set_hw_table(struct hfi_instance *hfi_= instance) wrmsrl(MSR_IA32_HW_FEEDBACK_PTR, msr_val); } =20 +/* Caller must hold hfi_instance_lock. */ +static void hfi_disable(void) +{ + u64 msr_val; + int i; + + rdmsrl(MSR_IA32_HW_FEEDBACK_CONFIG, msr_val); + msr_val &=3D ~HW_FEEDBACK_CONFIG_HFI_ENABLE_BIT; + wrmsrl(MSR_IA32_HW_FEEDBACK_CONFIG, msr_val); + + /* + * Wait for hardware to acknowledge the disabling of HFI. Some + * processors may not do it. Wait for ~2ms. This is a reasonable + * time for hardware to complete any pending actions on the HFI + * memory. + */ + for (i =3D 0; i < 2000; i++) { + rdmsrl(MSR_IA32_PACKAGE_THERM_STATUS, msr_val); + if (msr_val & PACKAGE_THERM_STATUS_HFI_UPDATED) + break; + + udelay(1); + cpu_relax(); + } +} + /** * intel_hfi_online() - Enable HFI on @cpu * @cpu: CPU in which the HFI will be enabled @@ -420,6 +447,10 @@ void intel_hfi_online(unsigned int cpu) /* * Hardware is programmed with the physical address of the first page * frame of the table. Hence, the allocated memory must be page-aligned. + * + * Some processors do not forget the initial address of the HFI table + * even after having been reprogrammed. Keep using the same pages. Do + * not free them. */ hfi_instance->hw_table =3D alloc_pages_exact(hfi_features.nr_table_pages, GFP_KERNEL | __GFP_ZERO); @@ -488,6 +519,10 @@ void intel_hfi_offline(unsigned int cpu) =20 mutex_lock(&hfi_instance_lock); cpumask_clear_cpu(cpu, hfi_instance->cpus); + + if (!cpumask_weight(hfi_instance->cpus)) + hfi_disable(); + mutex_unlock(&hfi_instance_lock); } =20 --=20 2.25.1