Received: by 10.223.164.202 with SMTP id h10csp502025wrb; Fri, 17 Nov 2017 04:14:53 -0800 (PST) X-Google-Smtp-Source: AGs4zMbhhsS5Nk8cvEfTarGpaRECaG/bO14kPQcIqF3bQljZOVcpGOW0o0peXBBdWi/zWWQdPuQd X-Received: by 10.99.43.71 with SMTP id r68mr5042875pgr.348.1510920893706; Fri, 17 Nov 2017 04:14:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510920893; cv=none; d=google.com; s=arc-20160816; b=FoaK26j7Gs+6eLjVXcDYz87hDyYap3dzX1HZyvqI84U5dTcJXr7Bax7Z51iEpMvmaG He34OX5+O8Bs66klb1axxFVED+67VqFwrWiHzNGKIYnTSgMGehOe/qCF2yQJ0fcdcrAq ZMwffbYKD5UfdTUbKwFKXp2n2jqpp+RkhD6B2cdBf80BPyng9cu9NXbyaCkQ2B/MxNAI CRcvhnRaezgthNaiQSH6jNmpX2+PORpfRNKlRA3KaCy6N3q/GRYSSVA8BV9v5fZdQLqY kR6slLbNnOdV7f40BQH5LuoJcViTNriXeCBf+MkEHU+cYtwfFotR6r+R7+0yTppu2E7d Xc2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:arc-authentication-results; bh=J3PpkwmsmyLShWbtPFQ/sa/9+T1q8ri7LMrTS0V2Zuw=; b=SISg8+86gHZaENJIRPEtTkGae2aH8x/iirxxfsp4VWiQbyWchEYisHjvmncYBOEPej s8OpNM1HsDGRCkEp0phTqDKdU1IW6XhXzgaVaqlIC+5AGiSS41btoVcbq6rfVObTzwJV YVgfO0RYXm9AnTh1vIKOtlnZ1LaYmYpPlXKmukQeADs+PtOOFz8dE5sBBcjDGrelnpnJ eqPEMbzUyW56C1moriMrcNfqZjqHX4VDycTWtelYONX1e1YPuWOXHA/W1y4Km4JaFrWV IWBvFq9GrSQvyC1xQqbJoKYB07pt34HdgsYirAqqJwZugMKFnaLtg3A60mpkIIXNHn6f op8g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h126si2604805pgc.289.2017.11.17.04.14.40; Fri, 17 Nov 2017 04:14:53 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932079AbdKQCO7 (ORCPT + 91 others); Thu, 16 Nov 2017 21:14:59 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:10997 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754930AbdKQCOv (ORCPT ); Thu, 16 Nov 2017 21:14:51 -0500 Received: from 172.30.72.58 (EHLO DGGEMS408-HUB.china.huawei.com) ([172.30.72.58]) by dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id DLC60770; Fri, 17 Nov 2017 10:14:42 +0800 (CST) Received: from [127.0.0.1] (10.177.21.79) by DGGEMS408-HUB.china.huawei.com (10.3.19.208) with Microsoft SMTP Server id 14.3.361.1; Fri, 17 Nov 2017 10:13:52 +0800 Subject: Re: [PATCH] drivers: base: cacheinfo: support DT overrides for cache type To: Sudeep Holla References: <1510837089-5951-1-git-send-email-tanxiaojun@huawei.com> CC: , From: Tan Xiaojun Message-ID: <5A0E45D3.1090803@huawei.com> Date: Fri, 17 Nov 2017 10:13:39 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.21.79] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5A0E4612.00AE,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: cb483f80661b039cd96c9c13f0d72bab Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017/11/16 23:23, Sudeep Holla wrote: > > > On 16/11/17 12:58, Tan Xiaojun wrote: >> Since commit dfea747d2aba ("drivers: base: cacheinfo: support DT >> overrides for cache properties"), we can set the correct cacheinfo >> via DT. But the cache type can't be set in the same way. >> >> I found this may be a problem in recent tests. I tested L3 cache >> node setting in DT in Hisilicon D03/D05 board. And I got cacheinfo >> via sysfs below: > > I assume L3 is outer non-architected system cache. > Yes. >> >> $ cat /sys/devices/system/cpu/cpu*/cache/index3/ >> allocation_policy level power/ >> shared_cpu_map uevent write_policy >> coherency_line_size number_of_sets shared_cpu_list >> size ways_of_associativity >> >> This is incomplete, no type file to display type info. Because L3 >> cache is uncore, we can't get correct type info from system >> register, and will get a default type "CACHE_TYPE_NOCACHE". Then >> use "lscpu" will print an error like below: >> >> $ lscpu >> lscpu: cannot open /sys/devices/system/cpu/cpu0/cache/index3/type: >> No such file or directory >> >> So I think maybe we can set correct cache type via DT too. >> >> Signed-off-by: Tan Xiaojun >> --- >> drivers/base/cacheinfo.c | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c >> index eb3af27..3e650dc 100644 >> --- a/drivers/base/cacheinfo.c >> +++ b/drivers/base/cacheinfo.c >> @@ -122,6 +122,15 @@ static inline int get_cacheinfo_idx(enum cache_type type) >> return type; >> } >> >> +static void cache_type(struct cacheinfo *this_leaf) >> +{ >> + const __be32 *cache_type; >> + >> + cache_type = of_get_property(this_leaf->of_node, "type", NULL); > > NACK for this: > > 1. We don't have any DT binding for the "type" > 2. Even if we had, we will never have such a binding that magical > returns the enum used in Linux implementation. That's not how DT > bindings are designed. > > Please refer ePAPR or Devicetree Specification Release 0.1 from > devicetree.org, we have cache-unified boolean for type. > > Let me know if the below patch works for you, I will submit it > preferably with your tested-by. > > Regards, > Sudeep > OK. That's fine. I will test this. By the way, Arm64 tend to use acpi way to boot now. Is there some suitable solution for acpi? Thanks. Xiaojun. > -->8 > > diff --git i/drivers/base/cacheinfo.c w/drivers/base/cacheinfo.c > index eb3af2739537..07532d83be0b 100644 > --- i/drivers/base/cacheinfo.c > +++ w/drivers/base/cacheinfo.c > @@ -186,6 +186,11 @@ static void cache_associativity(struct cacheinfo > *this_leaf) > this_leaf->ways_of_associativity = (size / nr_sets) / > line_size; > } > > +static bool cache_node_is_unified(struct cacheinfo *this_leaf) > +{ > + return of_property_read_bool(this_leaf->of_node, "cache-unified"); > +} > + > static void cache_of_override_properties(unsigned int cpu) > { > int index; > @@ -194,6 +199,14 @@ static void cache_of_override_properties(unsigned > int cpu) > > for (index = 0; index < cache_leaves(cpu); index++) { > this_leaf = this_cpu_ci->info_list + index; > + /* > + * init_cache_level must setup the cache level correctly > + * overriding the architecturally specified levels, so > + * if type is NONE at this stage, it should be unified > + */ > + if (this_leaf->type == CACHE_TYPE_NOCACHE && > + cache_node_is_unified(this_leaf)) > + this_leaf->type = CACHE_TYPE_UNIFIED; > cache_size(this_leaf); > cache_get_line_size(this_leaf); > cache_nr_sets(this_leaf); > > > . > From 1584242973727435612@xxx Thu Nov 16 17:03:54 +0000 2017 X-GM-THRID: 1584226221830067445 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread