From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Valentin Schneider <valentin.schneider@arm.com>,
Ruifeng Zhang <ruifeng.zhang0110@gmail.com>,
linux@armlinux.org.uk, sudeep.holla@arm.com,
gregkh@linuxfoundation.org, rafael@kernel.org,
a.p.zijlstra@chello.nl, 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
Date: Thu, 15 Apr 2021 22:10:47 +0200 [thread overview]
Message-ID: <b7a76995-f6c3-67c5-b14e-d40587495d7e@arm.com> (raw)
In-Reply-To: <8735vrmnc7.mognet@arm.com>
On 15/04/2021 20:09, Valentin Schneider wrote:
> On 14/04/21 20:23, Ruifeng Zhang wrote:
>> From: Ruifeng Zhang <ruifeng.zhang1@unisoc.com>
>>
>> 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).
... and this would be in sync with
https://developer.arm.com/documentation/100442/0200/register-descriptions/aarch32-system-registers/mpidr--multiprocessor-affinity-register
MT, [24]
0b1 ...
There is no 0b0 for MT.
WARNING: multiple messages have this Message-ID (diff)
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Valentin Schneider <valentin.schneider@arm.com>,
Ruifeng Zhang <ruifeng.zhang0110@gmail.com>,
linux@armlinux.org.uk, sudeep.holla@arm.com,
gregkh@linuxfoundation.org, rafael@kernel.org,
a.p.zijlstra@chello.nl, 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
Date: Thu, 15 Apr 2021 22:10:47 +0200 [thread overview]
Message-ID: <b7a76995-f6c3-67c5-b14e-d40587495d7e@arm.com> (raw)
In-Reply-To: <8735vrmnc7.mognet@arm.com>
On 15/04/2021 20:09, Valentin Schneider wrote:
> On 14/04/21 20:23, Ruifeng Zhang wrote:
>> From: Ruifeng Zhang <ruifeng.zhang1@unisoc.com>
>>
>> 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).
... and this would be in sync with
https://developer.arm.com/documentation/100442/0200/register-descriptions/aarch32-system-registers/mpidr--multiprocessor-affinity-register
MT, [24]
0b1 ...
There is no 0b0 for MT.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-04-15 20:10 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-14 12:23 [PATCH v2 0/1] arm: topology: parse the topology from the dt Ruifeng Zhang
2021-04-14 12:23 ` Ruifeng Zhang
2021-04-14 12:23 ` [PATCH v2 1/1] " Ruifeng Zhang
2021-04-14 12:23 ` Ruifeng Zhang
2021-04-14 12:38 ` Ruifeng Zhang
2021-04-14 12:38 ` Ruifeng Zhang
2021-04-15 18:09 ` Valentin Schneider
2021-04-15 18:09 ` Valentin Schneider
2021-04-15 18:09 ` [PATCH v2 0/1] " Valentin Schneider
2021-04-15 18:09 ` Valentin Schneider
2021-04-15 20:10 ` Dietmar Eggemann [this message]
2021-04-15 20:10 ` Dietmar Eggemann
2021-04-16 7:47 ` Ruifeng Zhang
2021-04-16 7:47 ` Ruifeng Zhang
2021-04-16 9:32 ` Valentin Schneider
2021-04-16 9:32 ` Valentin Schneider
2021-04-16 10:39 ` Dietmar Eggemann
2021-04-16 10:39 ` Dietmar Eggemann
2021-04-16 10:47 ` Valentin Schneider
2021-04-16 10:47 ` Valentin Schneider
2021-04-16 11:04 ` Ruifeng Zhang
2021-04-16 11:04 ` Ruifeng Zhang
2021-04-16 17:00 ` Dietmar Eggemann
2021-04-16 17:00 ` Dietmar Eggemann
2021-04-19 2:55 ` Ruifeng Zhang
2021-04-19 2:55 ` Ruifeng Zhang
2021-04-19 21:27 ` Dietmar Eggemann
2021-04-19 21:27 ` Dietmar Eggemann
2021-04-23 6:25 ` Ruifeng Zhang
2021-04-23 6:25 ` Ruifeng Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b7a76995-f6c3-67c5-b14e-d40587495d7e@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mingo@kernel.org \
--cc=nianfu.bai@unisoc.com \
--cc=rafael@kernel.org \
--cc=ruifeng.zhang0110@gmail.com \
--cc=ruifeng.zhang1@unisoc.com \
--cc=sudeep.holla@arm.com \
--cc=valentin.schneider@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.