Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3465849yba; Tue, 16 Apr 2019 11:55:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqwPYRm9FmIHsCHxDq4KQ79o01edE/U4fvSVYxxDiL1aEoxm71/CM/4ld25q63Xrwp63eWrB X-Received: by 2002:a62:474a:: with SMTP id u71mr84090023pfa.87.1555440944848; Tue, 16 Apr 2019 11:55:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555440944; cv=none; d=google.com; s=arc-20160816; b=lfi569IoG3RTxPPlGFu5NXoM+t+A7ybEOEhVgHFGu/F/fx6hrqgPVfvTGYMp4q9gRb raiKVofL/2kdbMfVbG8Qd89SYaiJC3tGYn7AzJc7HLvvz0/vyI1tHPy8hyLTcasxMoeh BP4uk0uH4WJQtB2YaBaMDsiDnr7xFAEZh2XkbCnM88kWxDhp06VORci/6wd0c6AHtB9V 8Uw4llqKkzjecbH2L5paYs5UUPyPIZkSoO+NOX1Mnt+RSRTDJGg+v51WZuFCE8cRkt01 5TqQ74hHhvdMfaVegp1oFG5btNAxfZiMmppvci2Z1HjlJeLtw5BYlLIngMZGEmcNbYXh XJPA== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:ironport-sdr:ironport-sdr :dkim-signature; bh=RqN8WwSgbvpAlTyKRNhXZCchFqFm+y9LTCFL/2ZqfxM=; b=GtKRH1nL87PnQxgwkAnbp6z4fuMW9RqzYewbzvb3n2JQe0V1OgJRfuELFlnoyALAgd yP8ndN78/7atEA9KSPeTbdnbBfi2rBQYsgx2PwSVOHvkz9SZ24T9aMd5yhxFsNbEpfOP o06DSKfxwJKRZpXM5OeTAEK3IDLAW4ryN8qotGHIY+jZ3gTnK1fdKpTF/NtWa0Ii4gSI 2S+bkJNhtRBWCxzKUGuAZox2BsnaRbXyaQN++smiA+VSfWWBBo5uiH+GnQqNlkitdz8X 6pqM2S2j6A6vZ26kSu9GOQphHY1AN0amRHI8XsWhNdYcMRoN7/2Yc6r83mTSsCU7DeRp ir5w== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@wdc.com header.s=dkim.wdc.com header.b="n7c/ixN7"; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=wdc.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r15si48617940pgi.27.2019.04.16.11.55.28; Tue, 16 Apr 2019 11:55:44 -0700 (PDT) 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; dkim=fail header.i=@wdc.com header.s=dkim.wdc.com header.b="n7c/ixN7"; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=wdc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730249AbfDPSyv (ORCPT + 99 others); Tue, 16 Apr 2019 14:54:51 -0400 Received: from esa1.hgst.iphmx.com ([68.232.141.245]:2610 "EHLO esa1.hgst.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726860AbfDPSyv (ORCPT ); Tue, 16 Apr 2019 14:54:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com; t=1555440890; x=1586976890; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ZT0B97dSH1Ijy8Uz6tkERdBIjfHUkvFmhigXZV6/kCM=; b=n7c/ixN7PQk+hAc7y2Bx38M56mVqxTUUwDHhDgxVtzz7+YzqzTl2BeBQ ce7grs/swLMGUEGWnKBpFZ9BkYVv55QsVnZgGqGABX6MHlsLyeXDo2j4r HtSQrghNXSYez8vKlKxJ2qL22clOoG+/VusX9BVh0LYdlYzTuMtLSLd4E hpRWKVsFqERuTtSqdg1CGtRWYjxBIKA53k8wmMhCDhem1Er01Rd+e2ORM 5Z5zvICYGfAE2uTvNlJZXqrgIivLB2XVSPOgXFsx2Qbgr9GSdJexzB9Ib GNtIojM3gOj9cbe27rs55hBVbSxWggVjOwezL49zNSMpZmQLyWtbtgiTH A==; X-IronPort-AV: E=Sophos;i="5.60,358,1549900800"; d="scan'208";a="211868828" Received: from uls-op-cesaip02.wdc.com (HELO uls-op-cesaep02.wdc.com) ([199.255.45.15]) by ob1.hgst.iphmx.com with ESMTP; 17 Apr 2019 02:54:50 +0800 IronPort-SDR: b/rkYS4O/bz9eFZYrnOpNimtaoNBbZrFb/4ZnDQWAFzPkqJB59XMhcOoomHq15PBOMnW+1uw0v G/tY+Fm2gL30YzqdBqR1zThmGGnan9dWjQ5VxRpiM6H/UlGhIEtf5EJv3QVyiZ7uc1i1kU0iFW IdfzzvTlQ6YpnTzAwzlBlL5iioE/Wy3tlS2viWy4kQozF1OmjOP0hxuF6QqXNzNgATWA4pWOjU +3GR3p7k2JsXo2LzFPYE9yceIir5KN+Nl7NJFUafPxjzCA+JmFgZJW3eHWUAU99oNKTvPmD7Ec H90YtWtGLFs5yuI7amRS6d+L Received: from uls-op-cesaip02.wdc.com ([10.248.3.37]) by uls-op-cesaep02.wdc.com with ESMTP; 16 Apr 2019 11:33:43 -0700 IronPort-SDR: lp/jOdP+DmZq8I6+T6uki2xICfwqvEelUfHXocVeqDgAp7Jutc6jpm3A3kdRfNpBMZQcL153Ng jSzTEyR35BoZwlMzAWuCm+7N4Ovs5k1pa199lkoQFLypTJUhotRW/rSOu84pQQSAYlz7XVQWSV oaBFQJQz9+GyPCmmFCWXw48jXcGz5GWGS8z62Bm2zZEUlO/VtZyyMLdvQQ8GnNDxiy3kQxVIf/ pF2xCkK/STyOzjLCY2DwXC+ipD1EPZmggngSUTXd9MbmuenvxS84uPaoS3tpfjqrSdNqpI3cPi ZsE= Received: from c02v91rdhtd5.sdcorp.global.sandisk.com (HELO [10.111.66.167]) ([10.111.66.167]) by uls-op-cesaip02.wdc.com with ESMTP; 16 Apr 2019 11:54:49 -0700 Subject: Re: [RFT/RFC PATCH v3 3/5] cpu-topology: Move cpu topology code to common code. To: Sudeep Holla Cc: "linux-kernel@vger.kernel.org" , Jeffrey Hugo , Albert Ou , Anup Patel , Ard Biesheuvel , Catalin Marinas , "devicetree@vger.kernel.org" , Dmitriy Cherkasov , Greg Kroah-Hartman , Ingo Molnar , Jeremy Linton , Johan Hovold , "linux-riscv@lists.infradead.org" , Mark Rutland , Morten Rasmussen , Otto Sabart , Palmer Dabbelt , Paul Walmsley , "Peter Zijlstra (Intel)" , "Rafael J. Wysocki" , Rob Herring , Will Deacon References: <20190320234806.19748-1-atish.patra@wdc.com> <20190320234806.19748-4-atish.patra@wdc.com> <20190415152741.GA28623@e107155-lin> <5c5b720f-414a-706c-3415-642c27baef1f@wdc.com> <20190416132324.GB24669@e107155-lin> From: Atish Patra Message-ID: Date: Tue, 16 Apr 2019 11:54:49 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190416132324.GB24669@e107155-lin> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/16/19 6:23 AM, Sudeep Holla wrote: > On Mon, Apr 15, 2019 at 03:08:45PM -0700, Atish Patra wrote: >> On 4/15/19 8:27 AM, Sudeep Holla wrote: >>> Hi Atish, >>> >>> Thanks again for doing this. Overall changes look good except a couple >>> of minor nit, see below. >>> >>> On Wed, Mar 20, 2019 at 04:48:04PM -0700, Atish Patra wrote: >>>> Both RISC-V & ARM64 are using cpu-map device tree to describe >>>> their cpu topology. It's better to move the relevant code to >>>> a common place instead of duplicate code. >>>> >>>> Signed-off-by: Atish Patra >>>> Tested-by: Jeffrey Hugo >>>> --- >>>> arch/arm64/include/asm/topology.h | 23 --- >>>> arch/arm64/kernel/topology.c | 303 +----------------------------- >>>> drivers/base/arch_topology.c | 298 ++++++++++++++++++++++++++++- >>>> drivers/base/topology.c | 1 + >>>> include/linux/arch_topology.h | 28 +++ >>>> 5 files changed, 330 insertions(+), 323 deletions(-) >>>> >>> >>> [...] >>> >>>> diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c >>>> index edfcf8d9..6cc6a860 100644 >>>> --- a/drivers/base/arch_topology.c >>>> +++ b/drivers/base/arch_topology.c >>>> @@ -6,8 +6,8 @@ >>>> * Written by: Juri Lelli, ARM Ltd. >>>> */ >>>> -#include >>>> #include >>>> +#include >>>> #include >>>> #include >>>> #include >>>> @@ -16,6 +16,11 @@ >>>> #include >>>> #include >>>> #include >>>> +#include >>>> +#include >>>> +#include >>>> +#include >>>> +#include >>>> DEFINE_PER_CPU(unsigned long, freq_scale) = SCHED_CAPACITY_SCALE; >>>> @@ -278,3 +283,294 @@ static void parsing_done_workfn(struct work_struct *work) >>>> #else >>>> core_initcall(free_raw_capacity); >>>> #endif >>>> + >>>> +#if defined(CONFIG_ARM64) || defined(CONFIG_RISCV) >>> >>> Why can't the above one be just GENERIC_ARCH_TOPOLOGY ? >>> I may be missing to find it myself, but would like to know. >>> >> GENERIC_ARCH_TOPOLOGY is now used for both RISCV, ARM & ARM64. >> The below functions under this #ifdef have different implementation for ARM >> and ARM64. >> >> parse_dt_topology >> cpu_coregroup_mask >> update_siblings_masks >> >> While we can combine the later two functions and move them to common code as >> well, parse_dt_topology is significantly different. >> > > Sure, had a quick glance and indeed they may look different, but won't > it defeat the purpose of this binding consolidation ? > I didn't want change too much at first go. >> That's why we need some kind of #ifdef or renaming of parse_dt_topology for >> ARM32 code. >> > > I am fine if we want to take this up later to keep the impact minimum. > But cpu_coregroup_mask and update_siblings_masks can and must be unified. Sure. I will just leave parse_dt_topology as it is for now and unify other two functions. I think we should unify parse_dt_topology in separate series. Regards, Atish > In fact the existing generic version must work on ARM32 too. > >> Thanks for the review!! >> > > You are welcome. > > -- > Regards, > Sudeep >