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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 6C655C433B4 for ; Mon, 12 Apr 2021 15:34:56 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 0535361206 for ; Mon, 12 Apr 2021 15:34:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0535361206 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=IliOUIzj6QjhiTri79wIMR6qtu0InAbseig16hgq/+I=; b=c+P/sdsiN8cUG/bLsX2y4bFpf UIC56oC/OS9QpQR/ZREUqimw4cyNkfjjzvdj7PepVBQdHiO8PcfMaBlwuBjLaT6qIyReEdmayMtyc nExpNgfjtFQu7qRClytmCglUJOpW59im0WDLOSH4Wz9kouF1AgUIDqvsAwDT5cP7gALV6U7ExL7Id VL/VvcO/GcQ3bPCfyNaOAI3ECOdBqoeaaBHy6jLEASsxfajrWM+8iol+e0Qu8DGJeyu1pxtCT8QfY 37A5aqCAcjhaLgB1tdzTurh3AwpDHTpt5zGjGRTDz5R3raFcowmrS1qZGn6HgaUZlzYl+2mZud2sv rC710ZpXg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lVyZF-0076R1-Am; Mon, 12 Apr 2021 15:33:38 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lVyYo-0076G2-EG for linux-arm-kernel@desiato.infradead.org; Mon, 12 Apr 2021 15:33:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:MIME-Version:Message-ID: Date:References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=swcMB0gksJnRCwp8lTk8P7vj2UScYbp8KCBYjOXd4Y0=; b=ptnwlIqaczMONmf8DoqMjRd3VR ixrO1QJgf+d3ZtWQcSfcIbF5hyb1Tqw4akfCBj3VoPQ7lFAZYer32+xAOc/gnuMkA49bDflsXZQbB erZj4YozyhQ8t+n9dQFOgXevBipXQMzIioXcsTo3gmNYf5j78lXkvW06DJWINCoXB2eVY5iAu1Oyj VxnF5U7oVKqsbJ2yBmHA6azVeX5ZXOOvbI+T3JF2QhZfhMA3BZd3H3NCjRSBnrqa+0B/w0VSQlk7m MINDO18M1Pkx1EOK6jcOcavRx7crCJupDseEdFGGSpPxOOF9x0D4Ylvy7LfqISX3EoTlLY4imftrM /57pzp3w==; Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lVyYl-006LZg-Je for linux-arm-kernel@lists.infradead.org; Mon, 12 Apr 2021 15:33:09 +0000 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210412_083307_715884_D9BBA42E X-CRM114-Status: GOOD ( 18.92 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel