Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp994188pxb; Thu, 15 Apr 2021 11:10:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxVBbS5Umw/xgkNg06XdqERdWGXZajO1Gbr73ynEegzR7McbTZ/WRce6aQAJs2YB+vWfi5l X-Received: by 2002:a17:902:e289:b029:eb:29e7:beda with SMTP id o9-20020a170902e289b02900eb29e7bedamr5083012plc.78.1618510245581; Thu, 15 Apr 2021 11:10:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618510245; cv=none; d=google.com; s=arc-20160816; b=D8S3ekIkju0mBipRR7n0u7V3J719Yo1kWcF2pbTtsyRHhgZlup8Tuil0ysCNsJpyu0 qPdDkyMpx/pJibmng+8BxMfgkTz+2GfUwDO+g2n01pI0Cm47ZWiObLT6zx5BkMfpQDdj wjSjY/bALFL+4hI7sei9/SWoa5PUmV8VzsxlFwUdptR7jNfS9VdTkcdfZE9Rpl09u9gx VBcHJ0iGQy00SImqRhaqpkzJvSc/2BPgTUw5Zaq8rXQImZMZSJ5H/3xIAX/gGhzY94+8 +LKsYHBtdNXFZTazikBBgZyPOq2H11cMqBvVAvOdNEfvmuH3ArFHgNsWqKKLqGBLA4sm K6OQ== 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=70YFyHg+GwyqtmeMWQHXkH0NEKZffV5NgGEDGzeZebM=; b=P8R87JdaQgj/fGAiTn4N2dcsqqutynPdkwj3c5AaMOz/zazTpfG3Ds79QHqneyIaTT ny0z64Bv0xXw7bK/LgnCSbR3y6HjbcDFCbpQm60tQIPXnrMOxymgaOcveZJ3R1+Z63Gt QcbyiNIgYL+Jc9ODcoWId36Z8nI5gTcNChnLVetLuXQjWQQYRK2uM7N7lARYqrrrtWNb i0Qla42i2rklQ2YQ2YuYceQ3yQ6s5kLIFNnCg7CmouOS/KEQwaDnS5VYuvZr5U07VdH8 Np5zcr46Iur7UKPYoIm5v+bTTNH6mbBbdJZYTvJ00NRtNRMdTn+10yPn/icj4wMtkDsC mCKQ== 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 h9si3589818pgf.519.2021.04.15.11.10.32; Thu, 15 Apr 2021 11:10:45 -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 S234482AbhDOSKC (ORCPT + 99 others); Thu, 15 Apr 2021 14:10:02 -0400 Received: from foss.arm.com ([217.140.110.172]:51992 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233916AbhDOSJ6 (ORCPT ); Thu, 15 Apr 2021 14:09:58 -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 3E7F6106F; Thu, 15 Apr 2021 11:09:35 -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 AA3313FA45; Thu, 15 Apr 2021 11:09:33 -0700 (PDT) From: Valentin Schneider To: Ruifeng Zhang , linux@armlinux.org.uk, sudeep.holla@arm.com, gregkh@linuxfoundation.org, rafael@kernel.org, a.p.zijlstra@chello.nl, dietmar.eggemann@arm.com, mingo@kernel.org, ruifeng.zhang1@unisoc.com, nianfu.bai@unisoc.com Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/1] arm: topology: parse the topology from the dt In-Reply-To: <20210414122326.5255-1-ruifeng.zhang0110@gmail.com> References: <20210414122326.5255-1-ruifeng.zhang0110@gmail.com> Date: Thu, 15 Apr 2021 19:09:28 +0100 Message-ID: <8735vrmnc7.mognet@arm.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14/04/21 20:23, Ruifeng Zhang wrote: > From: Ruifeng Zhang > > In Unisoc, the sc9863a SoC which using cortex-a55, it has two software > version, one of them is the kernel running on EL1 using aarch32. > user(EL0) kernel(EL1) > sc9863a_go aarch32 aarch32 > sc9863a aarch64 aarch64 > > When kernel runs on EL1 using aarch32, the topology will parse wrong. > For example, > The MPIDR has been written to the chip register in armv8.2 format. > For example, > core0: 0000000080000000 > core1: 0000000080000100 > core2: 0000000080000200 > ... > > It will parse to: > | | aff2 | packageid | coreid | > |-------+------+-----------+--------| > | Core0 | 0 | 0 | 0 | > | Core1 | 0 | 1 | 0 | > | Core2 | 0 | 2 | 0 | > | ... | | | | > > The wrong topology is that all of the coreid are 0 and unexpected > packageid. > > The reason is the MPIDR format is different between armv7 and armv8.2. > armv7 (A7) mpidr is: > [11:8] [7:2] [1:0] > cluster reserved cpu > The cortex-a7 spec DDI0464F 4.3.5 > https://developer.arm.com/documentation/ddi0464/f/?lang=en > > armv8.2 (A55) mpidr is: > [23:16] [15:8] [7:0] > cluster cpu thread > What I had understood from our conversation was that there *isn't* a format difference (at least for the bottom 32 bits) - arm64/kernel/topopology.c would parse it the same, except that MPIDR parsing has been deprecated for arm64. The problem is that those MPIDR values don't match the actual topology. If they had the MT bit set, i.e. core0: 0000000081000000 core1: 0000000081000100 core2: 0000000081000200 then it would be parsed as: | | package_id | core_id | thread_id | |-------+------------+---------+-----------| | Core0 | 0 | 0 | 0 | | Core1 | 0 | 1 | 0 | | Core2 | 0 | 2 | 0 | which would make more sense (wrt the actual, physical topology).