Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp294763iob; Fri, 13 May 2022 01:45:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwKPTlsGR7bnzkwUCpmmySZSzdXSOsIEERBnuTJoFO1KaeeQOFss5Rqr10DZQtJ7Uwq0Z6O X-Received: by 2002:a17:907:720f:b0:6f8:5e72:d8d8 with SMTP id dr15-20020a170907720f00b006f85e72d8d8mr3100649ejc.541.1652431512596; Fri, 13 May 2022 01:45:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652431512; cv=none; d=google.com; s=arc-20160816; b=FCf8VRO0CQrpCrhArXFlSkO3glRu6JC064L7IEwgOu6L6KaJuHTYVBjOhnSgCNtwGu 9OMxTllHjR/ChVDabMgSgkn8WeLzIJ05TD0knBDnPXdI9dYqXIQe6av0L85ssFTHvrKF eQQ6QeXGUb/PketyxaTzK8G9nqEPMWd/fjGZWWe7vPJWUAsJ0UT/JpHM0WjyZwIvSHHM +wH2VKtw21RgvRkI4QMplca+9/Ey02hY6tglM8o9MzOgD+n0Lez5b/ydmEvEpyuKdxpD AHKN8+cVKfsSwNWq3nOC790PGJ2Y4koxwRwbzudGVKJ9Z6rYcxKxqWDUbj7bp6ebRVC7 9Rag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=PUbGzjRwg3Vfw0+O+Q0rDdmtRpaRCU9+id2dlOzdEdE=; b=umWDxfplH0ZbnBHSPUEmD3v//SYXAcXAOCoz1NwOdKNjPPgOFML/aG2EZm3HEBI4Hu IpnmXGgJFBviUZEfQa0O4mUzwiokQOgi6kxEolqpec+oC7nuFhVTkgF/V4oFlLFycX0X jd/c9STbNNjC3u4DnBd12bdB4STf0X+JfFDZ0tXKqt+HcSHKkHArntJOrz55CcaLsoBK 2aR8TY+DzTA0K00KsImQFfkLNe8nu7GtX7SDvX2N0SQz65YGKkyxWfseDMKKbY5lFAgd ZS1W0Bbkq3KXYptVfxy1Fjdd4JRgnAr1Q933leRAg45/pm5qTHWFVtUulqhDsd/GCWUF t96Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cr19-20020a170906d55300b006e8c745f302si1541522ejc.314.2022.05.13.01.44.47; Fri, 13 May 2022 01:45:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243676AbiEKNqp (ORCPT + 99 others); Wed, 11 May 2022 09:46:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244058AbiEKNqb (ORCPT ); Wed, 11 May 2022 09:46:31 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A517D1D30A; Wed, 11 May 2022 06:46:30 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 758241042; Wed, 11 May 2022 06:46:30 -0700 (PDT) Received: from pierre123.arm.com (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id AFAA23F66F; Wed, 11 May 2022 06:46:27 -0700 (PDT) From: Pierre Gondois To: linux-kernel@vger.kernel.org Cc: Ionela.Voinescu@arm.com, Dietmar.Eggemann@arm.com, Pierre Gondois , Pierre Gondois , "Rafael J. Wysocki" , Len Brown , Viresh Kumar , Robert Moore , linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, devel@acpica.org Subject: [PATCH v1 3/5] ACPI: CPPC: Assume no transition latency if no PCCT Date: Wed, 11 May 2022 15:45:57 +0200 Message-Id: <20220511134559.1466925-3-pierre.gondois@arm.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220511134559.1466925-1-pierre.gondois@arm.com> References: <20220511134559.1466925-1-pierre.gondois@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Pierre Gondois The transition_delay_us (struct cpufreq_policy) is currently defined as: Preferred average time interval between consecutive invocations of the driver to set the frequency for this policy. To be set by the scaling driver (0, which is the default, means no preference). The transition_latency represents the amount of time necessary for a CPU to change its frequency. A PCCT table advertises mutliple values: - pcc_nominal: Expected latency to process a command, in microseconds - pcc_mpar: The maximum number of periodic requests that the subspace channel can support, reported in commands per minute. 0 indicates no limitation. - pcc_mrtt: The minimum amount of time that OSPM must wait after the completion of a command before issuing the next command, in microseconds. cppc_get_transition_latency() allows to get the max of them. commit d4f3388afd48 ("cpufreq / CPPC: Set platform specific transition_delay_us") allows to select transition_delay_us based on the platform, and fallbacks to cppc_get_transition_latency() otherwise. If _CPC objects are not using PCC channels (no PPCT table), the transition_delay_us is set to CPUFREQ_ETERNAL, leading to really long periods between frequency updates (~4s). If the desired_reg, where performance requests are written, is in SystemMemory or SystemIo ACPI address space, there is no delay in requests. So return 0 instead of CPUFREQ_ETERNAL, leading to transition_delay_us being set to LATENCY_MULTIPLIER us (1000 us). This patch also adds two macros to check the address spaces. Signed-off-by: Pierre Gondois --- drivers/acpi/cppc_acpi.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index 6f09fe011544..cc932ec1b613 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -100,6 +100,16 @@ static DEFINE_PER_CPU(struct cpc_desc *, cpc_desc_ptr); (cpc)->cpc_entry.reg.space_id == \ ACPI_ADR_SPACE_PLATFORM_COMM) +/* Check if a CPC register is in SystemMemory */ +#define CPC_IN_SM(cpc) ((cpc)->type == ACPI_TYPE_BUFFER && \ + (cpc)->cpc_entry.reg.space_id == \ + ACPI_ADR_SPACE_SYSTEM_MEMORY) + +/* Check if a CPC register is in SystemIo */ +#define CPC_IN_SIO(cpc) ((cpc)->type == ACPI_TYPE_BUFFER && \ + (cpc)->cpc_entry.reg.space_id == \ + ACPI_ADR_SPACE_SYSTEM_IO) + /* Evaluates to True if reg is a NULL register descriptor */ #define IS_NULL_REG(reg) ((reg)->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY && \ (reg)->address == 0 && \ @@ -1456,6 +1466,9 @@ EXPORT_SYMBOL_GPL(cppc_set_perf); * transition latency for performance change requests. The closest we have * is the timing information from the PCCT tables which provides the info * on the number and frequency of PCC commands the platform can handle. + * + * If desired_reg is in the SystemMemory or SystemIo ACPI address space, + * then assume there is no latency. */ unsigned int cppc_get_transition_latency(int cpu_num) { @@ -1481,7 +1494,9 @@ unsigned int cppc_get_transition_latency(int cpu_num) return CPUFREQ_ETERNAL; desired_reg = &cpc_desc->cpc_regs[DESIRED_PERF]; - if (!CPC_IN_PCC(desired_reg)) + if (CPC_IN_SM(desired_reg) || CPC_IN_SIO(desired_reg)) + return 0; + else if (!CPC_IN_PCC(desired_reg)) return CPUFREQ_ETERNAL; if (pcc_ss_id < 0) -- 2.25.1