Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp1874252pxb; Mon, 12 Apr 2021 08:38:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyG0j1lh2FYGJ2ws40LKb/Up1POZOpx983iaDXERhTOzWPmm67SlD7Lnffuqq2a+fr2V1M9 X-Received: by 2002:aa7:c64b:: with SMTP id z11mr30610253edr.8.1618241887388; Mon, 12 Apr 2021 08:38:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618241887; cv=none; d=google.com; s=arc-20160816; b=gp3JvlkZLejwKgBOMRygB5Xvv7ynXbzv/L0g+RMbnSKlv+2R/lZsjx1R+6J4KIO651 d/RjT4CJHM8Bvbg9DeJScuazxhyHsO899XJCeViRwks/K6t2NyaBOY2OaJexiz5NXmZg MbVMemKbT1NcKFnHwbBmMq8+yKtISLXWW7KybVbAD3ApRQfaiRDidNTbROk1l+6G4juw nTYify4CUp3AyWF2nujpMArPVIXZB6Qa6txq2H4hVWz85lHJoZ8Dgj1APdHN/xKw4WN9 Z/A9k5Zz/dzGWfDr49U0RRTlkYbxZoEvhNOC2m4BwMdPW74akTlXTWEiEioiIRD9p2dY ccJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=swcMB0gksJnRCwp8lTk8P7vj2UScYbp8KCBYjOXd4Y0=; b=ZdGdMNSHDzKKNt38HIFJuCFgOpLKS9FZhlMYSwT1JnVSYUCFbBHQCMWWnHTU2/awSy m2sZ7siZbxCHTpF2ByXNTxATWRU9sa7bbS99BnaWABBuJ31ttO03CE0WuBDlRV8P2rWs o37+JUQvorexlWEa4W4YdjlmWfe3ZsV8NHV8bwz8qevPHwu9gRcCJI5imhazm7PEWWwQ aZ3joU1Mf5BDVH5GDgKGAmDaFGVjaQspUaWyz1pThLtkgVy7gjnCnqA8Fa8Cn34N7FwG qOjsmfNcwf64FAEVmKQWYJMlkMnN3+YBprn6pUXpAz4trAJS91Rxur5yOB3blrVzJ2t9 KmyQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bk25si7996159ejb.211.2021.04.12.08.37.44; Mon, 12 Apr 2021 08:38:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S242174AbhDLPdY (ORCPT + 99 others); Mon, 12 Apr 2021 11:33:24 -0400 Received: from foss.arm.com ([217.140.110.172]:53680 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238770AbhDLPdY (ORCPT ); Mon, 12 Apr 2021 11:33:24 -0400 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 DBFA111FB; Mon, 12 Apr 2021 08:33:05 -0700 (PDT) Received: from e113632-lin (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4EDB73F694; Mon, 12 Apr 2021 08:33:04 -0700 (PDT) From: Valentin Schneider To: Ruifeng Zhang Cc: linux@armlinux.org.uk, sudeep.holla@arm.com, Greg KH , "Rafael J. Wysocki" , a.p.zijlstra@chello.nl, dietmar.eggemann@arm.com, mingo@kernel.org, ruifeng.zhang1@unisoc.com, nianfu.bai@unisoc.com, linux-arm-kernel@lists.infradead.org, Linux Kernel Mailing List Subject: Re: [PATCH 1/1] arm: topology: parse the topology from the dt In-Reply-To: References: <20210412070819.23493-1-ruifeng.zhang0110@gmail.com> <87y2dnn3gw.mognet@arm.com> Date: Mon, 12 Apr 2021 16:32:57 +0100 Message-ID: <87tuobmsba.mognet@arm.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/04/21 20:20, Ruifeng Zhang wrote: > There is a armv8.3 cpu which should work normally both on aarch64 and aarch32. > The MPIDR has been written to the chip register in armv8.3 format. > For example, > core0: 0000000080000000 > core1: 0000000080000100 > core2: 0000000080000200 > ... > > Its cpu topology can be parsed normally on aarch64 mode (both > userspace and kernel work on arm64). > > The problem is when it working on aarch32 mode (both userspace and > kernel work on arm 32-bit), I didn't know using aarch32 elsewhere than EL0 was something actually being used. Do you deploy this somewhere, or do you use it for testing purposes? > the cpu topology > will parse error because of the format is different between armv7 and armv8.3. > The arm 32-bit driver, arch/arm/kernel/topology will parse the MPIDR > and store to the topology with armv7, > and the result is all cpu core_id is 0, the bit[1:0] of armv7 MPIDR format. > I'm not fluent at all in armv7 (or most aarch32 compat mode stuff), but I couldn't find anything about MPIDR format differences: DDI 0487G.a G8.2.113 """ AArch32 System register MPIDR bits [31:0] are architecturally mapped to AArch64 System register MPIDR_EL1[31:0]. """ Peeking at some armv7 doc and arm/kernel/topology.c the layout really looks just the same, i.e. for both of them, with your example of: core0: 0000000080000000 core1: 0000000080000100 core2: 0000000080000200 ... we'll get: | | aff2 | aff1 | aff0 | |-------+------+------+------| | Core0 | 0 | 0 | 0 | | Core1 | 0 | 1 | 0 | | Core2 | 0 | 2 | 0 | ... Now, arm64 doesn't fallback to MPIDR for topology information anymore since 3102bc0e6ac7 ("arm64: topology: Stop using MPIDR for topology information") so without DT we would get: | | package_id | core_id | |-------+------------+---------| | Core0 | 0 | 0 | | Core1 | 0 | 1 | | Core2 | 0 | 2 | Whereas with an arm kernel we'll end up parsing MPIDR as: | | package_id | core_id | |-------+------------+---------| | Core0 | 0 | 0 | | Core1 | 1 | 0 | | Core2 | 2 | 0 | Did I get this right? Is this what you're observing? > In addition, I think arm should also allow customers to configure cpu > topologies via DT.