linux-riscv.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Palmer Dabbelt <palmer@sifive.com>
To: robh+dt@kernel.org
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
	Damien.LeMoal@wdc.com, alankao@andestech.com, zong@andestech.com,
	anup@brainfault.org, linux-kernel@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	atish.patra@wdc.com, linux-riscv@lists.infradead.org,
	tglx@linutronix.de
Subject: Re: [RFC 1/2] dt-bindings: topology: Add RISC-V cpu topology.
Date: Mon, 05 Nov 2018 11:38:40 -0800 (PST)	[thread overview]
Message-ID: <mhng-799bd6f4-e4af-481e-90d8-bdc0e30f2530@palmer-si-x1c4> (raw)
Message-ID: <20181105193840.oZ5ZZpFojzQibhi1tJR9oXOZud-d3rLkvBX1goQg9l4@z> (raw)
In-Reply-To: <CAL_Jsq+wProNynprMjQnrz1jmbZT9TmmA-_=vPUxCEED_8xONg@mail.gmail.com>

On Fri, 02 Nov 2018 06:09:39 PDT (-0700), robh+dt@kernel.org wrote:
> On Thu, Nov 1, 2018 at 6:04 PM Atish Patra <atish.patra@wdc.com> wrote:
>>
>> Define a RISC-V cpu topology. This is based on cpu-map in ARM world.
>> But it doesn't need a separate thread node for defining SMT systems.
>> Multiple cpu phandle properties can be parsed to identify the sibling
>> hardware threads. Moreover, we do not have cluster concept in RISC-V.
>> So package is a better word choice than cluster for RISC-V.
>
> There was a proposal to add package info for ARM recently. Not sure
> what happened to that, but we don't need 2 different ways.
>
> There's never going to be clusters for RISC-V? What prevents that?
> Seems shortsighted to me.
>
>>
>> Signed-off-by: Atish Patra <atish.patra@wdc.com>
>> ---
>>  .../devicetree/bindings/riscv/topology.txt         | 154 +++++++++++++++++++++
>>  1 file changed, 154 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/riscv/topology.txt
>>
>> diff --git a/Documentation/devicetree/bindings/riscv/topology.txt b/Documentation/devicetree/bindings/riscv/topology.txt
>> new file mode 100644
>> index 00000000..96039ed3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/riscv/topology.txt
>> @@ -0,0 +1,154 @@
>> +===========================================
>> +RISC-V cpu topology binding description
>> +===========================================
>> +
>> +===========================================
>> +1 - Introduction
>> +===========================================
>> +
>> +In a RISC-V system, the hierarchy of CPUs can be defined through following nodes that
>> +are used to describe the layout of physical CPUs in the system:
>> +
>> +- packages
>> +- core
>> +
>> +The cpu nodes (bindings defined in [1]) represent the devices that
>> +correspond to physical CPUs and are to be mapped to the hierarchy levels.
>> +Simultaneous multi-threading (SMT) systems can also represent their topology
>> +by defining multiple cpu phandles inside core node. The details are explained
>> +in paragraph 3.
>
> I don't see a reason to do this differently than ARM. That said, I
> don't think the thread part is in use on ARM, so it could possibly be
> changed.
>
>> +
>> +The remainder of this document provides the topology bindings for ARM, based
>
> for ARM?
>
>> +on the Devicetree Specification, available from:
>> +
>> +https://www.devicetree.org/specifications/
>> +
>> +If not stated otherwise, whenever a reference to a cpu node phandle is made its
>> +value must point to a cpu node compliant with the cpu node bindings as
>> +documented in [1].
>> +A topology description containing phandles to cpu nodes that are not compliant
>> +with bindings standardized in [1] is therefore considered invalid.
>> +
>> +This cpu topology binding description is mostly based on the topology defined
>> +in ARM [2].
>> +===========================================
>> +2 - cpu-topology node
>
> cpu-map. Why change this?
>
> What I would like to see is the ARM topology binding reworked to be
> common or some good reasons why it doesn't work for RISC-V as-is.

I think it would be great if CPU topologies were not a RISC-V specific thing.  
We don't really do anything different than anyone else, so it'd be great if we 
could all share the same spec and code.  Looking quickly at the ARM cpu-map 
bindings, I don't see any reason why we can't just use the same thing on RISC-V 
-- it's not quite how I'd do it, but I don't think the differences are worth 
having another implementation.  Mechanically I'm not sure how to do this: 
should there just be a "Documentation/devicetree/bindings/cpu-map.txt"?

If everyone is OK with that then I vote we just go ahead and genericise the ARM 
"cpu-map" stuff for CPU topology.  Sharing the implementation looks fairly 
straight-forward as well.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  parent reply	other threads:[~2018-11-05 20:19 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-01 23:04 [RFC 0/2] Add RISC-V cpu topology Atish Patra
2018-11-01 23:04 ` Atish Patra
2018-11-01 23:04 ` [RFC 1/2] dt-bindings: topology: " Atish Patra
2018-11-01 23:04   ` Atish Patra
2018-11-02 13:09   ` Rob Herring
2018-11-02 13:09     ` Rob Herring
2018-11-02 13:31     ` Sudeep Holla
2018-11-02 13:31       ` Sudeep Holla
2018-11-02 15:11       ` Rob Herring
2018-11-02 15:11         ` Rob Herring
2018-11-02 15:50         ` Sudeep Holla
2018-11-02 15:50           ` Sudeep Holla
2018-11-02 20:53           ` Atish Patra
2018-11-02 20:53             ` Atish Patra
2018-11-02 21:08             ` Rob Herring
2018-11-02 21:08               ` Rob Herring
2018-11-02 20:34     ` Atish Patra
2018-11-02 20:34       ` Atish Patra
2018-11-05 19:38     ` Palmer Dabbelt [this message]
2018-11-05 19:38       ` Palmer Dabbelt
2018-11-05 20:10       ` Rob Herring
2018-11-05 20:10         ` Rob Herring
2018-11-06  0:12         ` Atish Patra
2018-11-06  0:12           ` Atish Patra
2018-11-06 10:03       ` Nick Kossifidis
2018-11-06 10:03         ` Nick Kossifidis
2018-11-06 11:37         ` Mark Rutland
2018-11-06 11:37           ` Mark Rutland
2018-11-01 23:04 ` [RFC 2/2] RISC-V: Introduce " Atish Patra
2018-11-01 23:04   ` Atish Patra
2018-11-02 18:58 ` [RFC 0/2] Add RISC-V " Nick Kossifidis
2018-11-02 18:58   ` Nick Kossifidis
2018-11-02 21:14   ` Atish Patra
2018-11-02 21:14     ` Atish Patra
2018-11-02 22:18     ` Nick Kossifidis
2018-11-02 22:18       ` Nick Kossifidis
2018-11-06 14:13   ` Sudeep Holla
2018-11-06 14:13     ` Sudeep Holla
2018-11-06 15:26     ` Nick Kossifidis
2018-11-06 15:26       ` Nick Kossifidis
2018-11-06 15:50       ` Sudeep Holla
2018-11-06 15:50         ` Sudeep Holla
2018-11-06 16:20       ` Mark Rutland
2018-11-06 16:20         ` Mark Rutland
2018-11-07  2:31         ` Nick Kossifidis
2018-11-07  2:31           ` Nick Kossifidis
2018-11-07 12:06           ` Mark Rutland
2018-11-07 12:06             ` Mark Rutland
2018-11-08 13:45             ` Nick Kossifidis
2018-11-08 13:45               ` Nick Kossifidis
2018-11-08 15:54               ` Mark Rutland
2018-11-08 15:54                 ` Mark Rutland
2018-11-09  3:55                 ` Nick Kossifidis
2018-11-09  3:55                   ` Nick Kossifidis
2018-11-07 12:28           ` Sudeep Holla
2018-11-07 12:28             ` Sudeep Holla
2018-11-08 14:52             ` Nick Kossifidis
2018-11-08 14:52               ` Nick Kossifidis
2018-11-08 16:48               ` Sudeep Holla
2018-11-08 16:48                 ` Sudeep Holla
2018-11-09  2:36                 ` Nick Kossifidis
2018-11-09  2:36                   ` Nick Kossifidis
2018-11-09 12:33                   ` Sudeep Holla
2018-11-09 12:33                     ` Sudeep Holla

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=mhng-799bd6f4-e4af-481e-90d8-bdc0e30f2530@palmer-si-x1c4 \
    --to=palmer@sifive.com \
    --cc=Damien.LeMoal@wdc.com \
    --cc=alankao@andestech.com \
    --cc=anup@brainfault.org \
    --cc=atish.patra@wdc.com \
    --cc=devicetree@vger.kernel.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=zong@andestech.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).