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=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS autolearn=ham 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 8E54FC43218 for ; Fri, 26 Apr 2019 17:02:57 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 598E9206E0 for ; Fri, 26 Apr 2019 17:02:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="GDZxKRSw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 598E9206E0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=TV8JP21A/Dcdtb5qdh2gRsPlirUVXsm2cTRWkr8EiQ0=; b=GDZxKRSwLIJSFmy3TKbZjt5Hx I/OncsQr+a669esu28wrkkbhKo+dV50YUBkKe4R8SB5SVrRNYmcFfiCjxnCmiGHWAMfZ1Eqjk+eLX 6pMtBOqSmUCuc1l54ZNEaweJscR1vhfQHIzAfDi77XJ7udTCcvoiJbHdgxMdefTtoENUI6jYq1DqD +NSJOxEEZLDzPMw+lyacgZijsULgAXc0gu8vRAx7J8zEGYHRh6aD5B/vj6PKjT7Okim4R2/RlUQMq BZM7Cx2Av9bMQs1P4KElUXi+jvM+O9gsRA4CM5eT6lXu/FvxiBBB0fsggXU8qm2cY34oGReV7I6jQ IBAsSmKqw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hK4FU-00030v-Bx; Fri, 26 Apr 2019 17:02:56 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hK4FR-00030a-GX for linux-arm-kernel@lists.infradead.org; Fri, 26 Apr 2019 17:02:54 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C35ABA78; Fri, 26 Apr 2019 10:02:52 -0700 (PDT) Received: from [192.168.100.241] (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3CA613F557; Fri, 26 Apr 2019 10:02:52 -0700 (PDT) Subject: Re: [PATCH 1/2] ACPI/PPTT: Add variable to record max cache line size To: Shaokun Zhang , linux-arm-kernel@lists.infradead.org References: <1556242821-5080-1-git-send-email-zhangshaokun@hisilicon.com> From: Jeremy Linton Message-ID: Date: Fri, 26 Apr 2019 12:02:45 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <1556242821-5080-1-git-send-email-zhangshaokun@hisilicon.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190426_100253_562124_D6563E81 X-CRM114-Status: GOOD ( 22.39 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Catalin Marinas , john.garry@huawei.com, "Rafael J. Wysocki" , qiuzhenfa@hisilicon.com, guohanjun@huawei.com, Len Brown Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On 4/25/19 8:40 PM, Shaokun Zhang wrote: > Add coherency_max_size variable to record the maximum cache line size > detected from PPTT information for different cache levels. We will > synchronize it with CTR_EL0.CWG reporting in cache_line_size() for arm64. Is the expectation that the largest cache line size will differ from the LLC line size? Also, will it remain consistent across all PE's? I believe this is required, Yes? > > Cc: "Rafael J. Wysocki" > Cc: Len Brown > Cc: Jeremy Linton > Cc: Catalin Marinas > To: linux-acpi@vger.kernel.org > Signed-off-by: Shaokun Zhang > --- > drivers/acpi/pptt.c | 7 ++++++- > include/linux/acpi.h | 1 + > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c > index 065c4fc245d1..3998621e00ce 100644 > --- a/drivers/acpi/pptt.c > +++ b/drivers/acpi/pptt.c > @@ -341,6 +341,8 @@ static struct acpi_pptt_cache *acpi_find_cache_node(struct acpi_table_header *ta > return found; > } > > +unsigned int coherency_max_size; > + > /** > * update_cache_properties() - Update cacheinfo for the given processor > * @this_leaf: Kernel cache info structure being updated > @@ -360,8 +362,11 @@ static void update_cache_properties(struct cacheinfo *this_leaf, > this_leaf->fw_token = cpu_node; > if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) > this_leaf->size = found_cache->size; > - if (found_cache->flags & ACPI_PPTT_LINE_SIZE_VALID) > + if (found_cache->flags & ACPI_PPTT_LINE_SIZE_VALID) { > this_leaf->coherency_line_size = found_cache->line_size; > + coherency_max_size = this_leaf->coherency_line_size > coherency_max_size ? > + this_leaf->coherency_line_size : coherency_max_size; > + } > if (found_cache->flags & ACPI_PPTT_NUMBER_OF_SETS_VALID) > this_leaf->number_of_sets = found_cache->number_of_sets; > if (found_cache->flags & ACPI_PPTT_ASSOCIATIVITY_VALID) > diff --git a/include/linux/acpi.h b/include/linux/acpi.h > index d5dcebd7aad3..199cde875d5b 100644 > --- a/include/linux/acpi.h > +++ b/include/linux/acpi.h > @@ -315,6 +315,7 @@ static inline bool acpi_sci_irq_valid(void) > > extern int sbf_port; > extern unsigned long acpi_realmode_flags; > +extern unsigned int coherency_max_size; Assuming that the LLC doesn't reflect the max cache line size, and it can't be pulled directly from the cpu_cacheinfo, I don't think this is the ideal place for this code. Given that DT has a cache line property as well, I suspect cache_shared_cpu_map_setup() may be a better place. Although, that isn't ideal either, as both these pieces of code have the pretense of being architecture neutral. Maybe a new call into arch/arm64/cacheinfo.c? > > int acpi_register_gsi (struct device *dev, u32 gsi, int triggering, int polarity); > int acpi_gsi_to_irq (u32 gsi, unsigned int *irq); > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel