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=-8.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham 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 2A0C8C6783B for ; Wed, 12 Dec 2018 02:31:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CD94820839 for ; Wed, 12 Dec 2018 02:31:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1544581887; bh=QYO5U6h0/FA3b59fEwGr/mAZ3N748YL6Mr2oTvnwTk4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=KI1cDavJPXAY3VNCw9eIPYm8lkA4ykUpKnT4wDpv1A1C+yqrqOw/IVibSg5G/ZlN7 nj/EnEQgd+atAH1+tA62uaqJMTE1w//zzbg+lesLbnWZuYsw8VU+TSq+S+mk22mS/o 2ljaZKt94m1gMZanf5FJRBOvW+SIVJAtI/XVBZ9U= DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CD94820839 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726309AbeLLCb0 (ORCPT ); Tue, 11 Dec 2018 21:31:26 -0500 Received: from mail-oi1-f196.google.com ([209.85.167.196]:40960 "EHLO mail-oi1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726211AbeLLCbZ (ORCPT ); Tue, 11 Dec 2018 21:31:25 -0500 Received: by mail-oi1-f196.google.com with SMTP id j21so13813382oii.8; Tue, 11 Dec 2018 18:31:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=JSdQZJweWPk6BAdWHHcAkj2ssa0zPN7sDYIXlGWtClU=; b=LJdINTzosiLAaGvERb/b5KYzM0IFEEDhQ7rb+FznvlIsfVSMV66l03akrelPsnWG38 yuwPKxy6hixfArsQhbAgtn6ayB47SVU9qr9kqz4D+LzHdjI4zR2KIVN8Eq7/vnXBGBSh E2fxmWw7pb5fo8aXPhZJFdrrgNR5M7eiwmSl+oT1ZIl6EmP2tqKXWzistrIEONI96jmu 32GxvN7xNY3b6HnJiDgFedQSCo3XB2Y8LGdfotijIzzAqQFKZvKSj8eW+5QM+CaXm1+Y LhKoSswCd51qR7QHobzi7/Sli0MWD7wgT0h0ou7Bq/Bg4BpU/UR5zse8sMokROPqs/KW 6SLA== X-Gm-Message-State: AA+aEWbZ1ofjTRDIbSGd3htM0Xy6c229320AaOdzA0/YTwsEB9OA9nmm EPQ4yeWd4SAZs1n82+Bm7A== X-Google-Smtp-Source: AFSGD/WUL+gr1+ZUmzzI/idm/8r5/q6w5+BAYiwGlY05OjIWeXzXSE+UTITJGjVxF5ZsAaRfqSn3vw== X-Received: by 2002:aca:e3d3:: with SMTP id a202mr2551031oih.79.1544581883988; Tue, 11 Dec 2018 18:31:23 -0800 (PST) Received: from localhost (24-155-109-49.dyn.grandenetworks.net. [24.155.109.49]) by smtp.gmail.com with ESMTPSA id f127sm9431995oia.19.2018.12.11.18.31.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 11 Dec 2018 18:31:23 -0800 (PST) Date: Tue, 11 Dec 2018 20:31:22 -0600 From: Rob Herring To: Atish Patra Cc: linux-kernel@vger.kernel.org, Albert Ou , Anup Patel , Ard Biesheuvel , Catalin Marinas , devicetree@vger.kernel.org, Dmitriy Cherkasov , Greg Kroah-Hartman , Ingo Molnar , Jeremy Linton , Juri Lelli , "moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)" , linux-riscv@lists.infradead.org, Mark Rutland , Morten Rasmussen , Palmer Dabbelt , "Peter Zijlstra (Intel)" , "Rafael J. Wysocki" , Sudeep Holla , Thomas Gleixner , Will Deacon Subject: Re: [RFT PATCH v1 2/4] dt-binding: cpu-topology: Move cpu-map to a common binding. Message-ID: <20181212023122.GB14213@bogus> References: <1543534100-3654-1-git-send-email-atish.patra@wdc.com> <1543534100-3654-3-git-send-email-atish.patra@wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1543534100-3654-3-git-send-email-atish.patra@wdc.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 29, 2018 at 03:28:18PM -0800, Atish Patra wrote: > cpu-map binding can be used to described cpu topology for both > RISC-V & ARM. It makes more sense to move the binding to document > to a common place. > > The relevant discussion can be found here. > https://lkml.org/lkml/2018/11/6/19 > > Signed-off-by: Atish Patra > --- > .../{arm/topology.txt => cpu/cpu-topology.txt} | 81 ++++++++++++++++++---- > 1 file changed, 67 insertions(+), 14 deletions(-) > rename Documentation/devicetree/bindings/{arm/topology.txt => cpu/cpu-topology.txt} (86%) > > diff --git a/Documentation/devicetree/bindings/arm/topology.txt b/Documentation/devicetree/bindings/cpu/cpu-topology.txt > similarity index 86% > rename from Documentation/devicetree/bindings/arm/topology.txt > rename to Documentation/devicetree/bindings/cpu/cpu-topology.txt > index 66848355..1de6fbce 100644 > --- a/Documentation/devicetree/bindings/arm/topology.txt > +++ b/Documentation/devicetree/bindings/cpu/cpu-topology.txt > @@ -1,12 +1,12 @@ > =========================================== > -ARM topology binding description > +CPU topology binding description > =========================================== > > =========================================== > 1 - Introduction > =========================================== > > -In an ARM system, the hierarchy of CPUs is defined through three entities that > +In a SMP system, the hierarchy of CPUs is defined through three entities that > are used to describe the layout of physical CPUs in the system: > > - socket > @@ -14,9 +14,6 @@ are used to describe the layout of physical CPUs in the system: > - core > - thread > > -The cpu nodes (bindings defined in [1]) represent the devices that > -correspond to physical CPUs and are to be mapped to the hierarchy levels. > - > The bottom hierarchy level sits at core or thread level depending on whether > symmetric multi-threading (SMT) is supported or not. > > @@ -25,33 +22,37 @@ threads existing in the system and map to the hierarchy level "thread" above. > In systems where SMT is not supported "cpu" nodes represent all cores present > in the system and map to the hierarchy level "core" above. > > -ARM topology bindings allow one to associate cpu nodes with hierarchical groups > +CPU topology bindings allow one to associate cpu nodes with hierarchical groups > corresponding to the system hierarchy; syntactically they are defined as device > tree nodes. > > -The remainder of this document provides the topology bindings for ARM, based > -on the Devicetree Specification, available from: > +Currently, only ARM/RISC-V intend to use this cpu topology binding but it may be > +used for any other architecture as well. > > -https://www.devicetree.org/specifications/ > +The remainder of this document provides the topology bindings for ARM/RISC-V, based You already said who are current users, why restrict it to ARM and RISC-V here? > +on the Devicetree Specification, available at [4]. > + > +The cpu nodes (bindings defined in [1] for ARM or [2] for RISC-V) represent the devices that > +correspond to physical CPUs and are to be mapped to the hierarchy levels. The cpu topology isn't dependent on anything beyond what the DT spec says for cpu nodes so I think this can be simplified to just refer to the spec. Plus, shouldn't [2] (numa) be [3] here. > 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]. > +documented in [1] or [3] for respective ISA. > A topology description containing phandles to cpu nodes that are not compliant > -with bindings standardized in [1] is therefore considered invalid. > +with bindings standardized in [1] or [3] is therefore considered invalid. > > =========================================== > 2 - cpu-map node > =========================================== > > -The ARM CPU topology is defined within the cpu-map node, which is a direct > +The ARM/RISC-V CPU topology is defined within the cpu-map node, which is a direct > child of the cpus node and provides a container where the actual topology > nodes are listed. > > - cpu-map node > > - Usage: Optional - On ARM SMP systems provide CPUs topology to the OS. > - ARM uniprocessor systems do not require a topology > + Usage: Optional - On SMP systems provide CPUs topology to the OS. > + Uniprocessor systems do not require a topology > description and therefore should not define a > cpu-map node. > > @@ -494,8 +495,60 @@ cpus { > }; > }; > > +Example 3: HiFive Unleashed (RISC-V 64 bit, 4 core system) > + > +cpus { > + #address-cells = <2>; > + #size-cells = <2>; > + compatible = "sifive,fu540g", "sifive,fu500"; > + model = "sifive,hifive-unleashed-a00"; This is wrong. Looks like the root node, but called 'cpus'. > + > + ... > + > + cpu-map { > + cluster0 { > + core0 { > + cpu = <&L12>; > + }; Mixed space and tabs. > + core1 { > + cpu = <&L15>; > + }; > + core2 { > + cpu0 = <&L18>; > + }; > + core3 { > + cpu0 = <&L21>; > + }; > + }; > + }; Mixed space and tab. > + > + L12: cpu@1 { > + device_type = "cpu"; > + compatible = "sifive,rocket0", "riscv"; > + reg = <0x1>; > + } > + > + L15: cpu@2 { > + device_type = "cpu"; > + compatible = "sifive,rocket0", "riscv"; > + reg = <0x2>; > + } > + L18: cpu@3 { > + device_type = "cpu"; > + compatible = "sifive,rocket0", "riscv"; > + reg = <0x3>; > + } > + L21: cpu@4 { > + device_type = "cpu"; > + compatible = "sifive,rocket0", "riscv"; > + reg = <0x4>; > + } > +}; > =============================================================================== > [1] ARM Linux kernel documentation > Documentation/devicetree/bindings/arm/cpus.txt > [2] Devicetree NUMA binding description > Documentation/devicetree/bindings/numa.txt > +[3] RISC-V Linux kernel documentation > + Documentation/devicetree/bindings/riscv/cpus.txt > +[4] https://www.devicetree.org/specifications/ > -- > 2.7.4 > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Subject: Re: [RFT PATCH v1 2/4] dt-binding: cpu-topology: Move cpu-map to a common binding. Date: Tue, 11 Dec 2018 20:31:22 -0600 Message-ID: <20181212023122.GB14213@bogus> References: <1543534100-3654-1-git-send-email-atish.patra@wdc.com> <1543534100-3654-3-git-send-email-atish.patra@wdc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1543534100-3654-3-git-send-email-atish.patra@wdc.com> Sender: linux-kernel-owner@vger.kernel.org To: Atish Patra Cc: linux-kernel@vger.kernel.org, Albert Ou , Anup Patel , Ard Biesheuvel , Catalin Marinas , devicetree@vger.kernel.org, Dmitriy Cherkasov , Greg Kroah-Hartman , Ingo Molnar , Jeremy Linton , Juri Lelli , "moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)" , linux-riscv@lists.infradead.org, Mark Rutland , Morten Rasmussen , Palmer Dabbelt , "Peter Zijlstra (Intel)" , "Rafael J. Wysocki" , Sudeep List-Id: devicetree@vger.kernel.org On Thu, Nov 29, 2018 at 03:28:18PM -0800, Atish Patra wrote: > cpu-map binding can be used to described cpu topology for both > RISC-V & ARM. It makes more sense to move the binding to document > to a common place. > > The relevant discussion can be found here. > https://lkml.org/lkml/2018/11/6/19 > > Signed-off-by: Atish Patra > --- > .../{arm/topology.txt => cpu/cpu-topology.txt} | 81 ++++++++++++++++++---- > 1 file changed, 67 insertions(+), 14 deletions(-) > rename Documentation/devicetree/bindings/{arm/topology.txt => cpu/cpu-topology.txt} (86%) > > diff --git a/Documentation/devicetree/bindings/arm/topology.txt b/Documentation/devicetree/bindings/cpu/cpu-topology.txt > similarity index 86% > rename from Documentation/devicetree/bindings/arm/topology.txt > rename to Documentation/devicetree/bindings/cpu/cpu-topology.txt > index 66848355..1de6fbce 100644 > --- a/Documentation/devicetree/bindings/arm/topology.txt > +++ b/Documentation/devicetree/bindings/cpu/cpu-topology.txt > @@ -1,12 +1,12 @@ > =========================================== > -ARM topology binding description > +CPU topology binding description > =========================================== > > =========================================== > 1 - Introduction > =========================================== > > -In an ARM system, the hierarchy of CPUs is defined through three entities that > +In a SMP system, the hierarchy of CPUs is defined through three entities that > are used to describe the layout of physical CPUs in the system: > > - socket > @@ -14,9 +14,6 @@ are used to describe the layout of physical CPUs in the system: > - core > - thread > > -The cpu nodes (bindings defined in [1]) represent the devices that > -correspond to physical CPUs and are to be mapped to the hierarchy levels. > - > The bottom hierarchy level sits at core or thread level depending on whether > symmetric multi-threading (SMT) is supported or not. > > @@ -25,33 +22,37 @@ threads existing in the system and map to the hierarchy level "thread" above. > In systems where SMT is not supported "cpu" nodes represent all cores present > in the system and map to the hierarchy level "core" above. > > -ARM topology bindings allow one to associate cpu nodes with hierarchical groups > +CPU topology bindings allow one to associate cpu nodes with hierarchical groups > corresponding to the system hierarchy; syntactically they are defined as device > tree nodes. > > -The remainder of this document provides the topology bindings for ARM, based > -on the Devicetree Specification, available from: > +Currently, only ARM/RISC-V intend to use this cpu topology binding but it may be > +used for any other architecture as well. > > -https://www.devicetree.org/specifications/ > +The remainder of this document provides the topology bindings for ARM/RISC-V, based You already said who are current users, why restrict it to ARM and RISC-V here? > +on the Devicetree Specification, available at [4]. > + > +The cpu nodes (bindings defined in [1] for ARM or [2] for RISC-V) represent the devices that > +correspond to physical CPUs and are to be mapped to the hierarchy levels. The cpu topology isn't dependent on anything beyond what the DT spec says for cpu nodes so I think this can be simplified to just refer to the spec. Plus, shouldn't [2] (numa) be [3] here. > 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]. > +documented in [1] or [3] for respective ISA. > A topology description containing phandles to cpu nodes that are not compliant > -with bindings standardized in [1] is therefore considered invalid. > +with bindings standardized in [1] or [3] is therefore considered invalid. > > =========================================== > 2 - cpu-map node > =========================================== > > -The ARM CPU topology is defined within the cpu-map node, which is a direct > +The ARM/RISC-V CPU topology is defined within the cpu-map node, which is a direct > child of the cpus node and provides a container where the actual topology > nodes are listed. > > - cpu-map node > > - Usage: Optional - On ARM SMP systems provide CPUs topology to the OS. > - ARM uniprocessor systems do not require a topology > + Usage: Optional - On SMP systems provide CPUs topology to the OS. > + Uniprocessor systems do not require a topology > description and therefore should not define a > cpu-map node. > > @@ -494,8 +495,60 @@ cpus { > }; > }; > > +Example 3: HiFive Unleashed (RISC-V 64 bit, 4 core system) > + > +cpus { > + #address-cells = <2>; > + #size-cells = <2>; > + compatible = "sifive,fu540g", "sifive,fu500"; > + model = "sifive,hifive-unleashed-a00"; This is wrong. Looks like the root node, but called 'cpus'. > + > + ... > + > + cpu-map { > + cluster0 { > + core0 { > + cpu = <&L12>; > + }; Mixed space and tabs. > + core1 { > + cpu = <&L15>; > + }; > + core2 { > + cpu0 = <&L18>; > + }; > + core3 { > + cpu0 = <&L21>; > + }; > + }; > + }; Mixed space and tab. > + > + L12: cpu@1 { > + device_type = "cpu"; > + compatible = "sifive,rocket0", "riscv"; > + reg = <0x1>; > + } > + > + L15: cpu@2 { > + device_type = "cpu"; > + compatible = "sifive,rocket0", "riscv"; > + reg = <0x2>; > + } > + L18: cpu@3 { > + device_type = "cpu"; > + compatible = "sifive,rocket0", "riscv"; > + reg = <0x3>; > + } > + L21: cpu@4 { > + device_type = "cpu"; > + compatible = "sifive,rocket0", "riscv"; > + reg = <0x4>; > + } > +}; > =============================================================================== > [1] ARM Linux kernel documentation > Documentation/devicetree/bindings/arm/cpus.txt > [2] Devicetree NUMA binding description > Documentation/devicetree/bindings/numa.txt > +[3] RISC-V Linux kernel documentation > + Documentation/devicetree/bindings/riscv/cpus.txt > +[4] https://www.devicetree.org/specifications/ > -- > 2.7.4 > 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=-8.7 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT autolearn=unavailable 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 43DD7C67839 for ; Wed, 12 Dec 2018 02:31:50 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 084CD20839 for ; Wed, 12 Dec 2018 02:31:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="nAKbAOX9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 084CD20839 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=xWpKOEyMwp+jKvzPwkhMYvqG85C6C6sbxwOXaZDpLTw=; b=nAKbAOX9Bk9+5/ KCE8jA2DnQzH0p+5Eld2uQHRonpILA3KCh54mWsesswk1QrQ3weT0DqeG7WIivU9WDxf6RV7aNhKj WtGz7oglfanryccsfXgBZl0lhdkFe44mtNJEpjuRHNo1upvZHeULheuq5IgYiXn/8C0VGaEOSnPg1 JS8DTl2dZUT4sq0R2vZ1copMdSRYn0LdEzMh/Q6WWHnJryoPUmMjfwDgbjtDEFeYi0a5wBz+UC8EM 8X6BE40XEdFk2/mqKCFcUHU/OLLnVwa7PZ9vmwqIi3iVOwvUTHERnqOH7AA9H61tEWUpnat7GYkA5 SH16hapjcfJ3262KBZ1A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gWuJQ-0004Qa-5J; Wed, 12 Dec 2018 02:31:48 +0000 Received: from mail-oi1-f196.google.com ([209.85.167.196]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gWuJE-0004IP-SA; Wed, 12 Dec 2018 02:31:38 +0000 Received: by mail-oi1-f196.google.com with SMTP id i6so13828595oia.6; Tue, 11 Dec 2018 18:31:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=JSdQZJweWPk6BAdWHHcAkj2ssa0zPN7sDYIXlGWtClU=; b=lWav1Z4zBogHoFoRgwspGrdL+d4ByB+PA7FrmiNCWYF0bKUOrPcyNqHaQTqvfMJX/X 1Y11CUjcgw77+JS7noIE2t5aFvZudHrGDbi0UTtHDexTJgFQ8pZJav/VxsM3dxfCYgma a2TR/Yj0Na8twziZLapECD9ciITxcIWEjD6fzZv89YJofo15tuv+Az5XnQ066EnfQN1g sSvrGgruchZLIeNRJ6zfC3vThgMJ91S6FStAClUIO1nil+t7sZJocHYeQa2imS4cNe4z 9vCHDIf3v5hmSKYCyXVS1YsWYVDElsbOIj+AuapEJL2MTLEdYTOa6ejF06JEr6SXzB5s NaWg== X-Gm-Message-State: AA+aEWYOX9A7+eYaK3dq3iputEKpo2z9v1PtyvAWKZ36lE1F896/foYx yjmo8jO08BW3ngECBusFyg== X-Google-Smtp-Source: AFSGD/WUL+gr1+ZUmzzI/idm/8r5/q6w5+BAYiwGlY05OjIWeXzXSE+UTITJGjVxF5ZsAaRfqSn3vw== X-Received: by 2002:aca:e3d3:: with SMTP id a202mr2551031oih.79.1544581883988; Tue, 11 Dec 2018 18:31:23 -0800 (PST) Received: from localhost (24-155-109-49.dyn.grandenetworks.net. [24.155.109.49]) by smtp.gmail.com with ESMTPSA id f127sm9431995oia.19.2018.12.11.18.31.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 11 Dec 2018 18:31:23 -0800 (PST) Date: Tue, 11 Dec 2018 20:31:22 -0600 From: Rob Herring To: Atish Patra Subject: Re: [RFT PATCH v1 2/4] dt-binding: cpu-topology: Move cpu-map to a common binding. Message-ID: <20181212023122.GB14213@bogus> References: <1543534100-3654-1-git-send-email-atish.patra@wdc.com> <1543534100-3654-3-git-send-email-atish.patra@wdc.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1543534100-3654-3-git-send-email-atish.patra@wdc.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20181211_183136_953161_FC9A15DA X-CRM114-Status: GOOD ( 25.84 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , devicetree@vger.kernel.org, Albert Ou , Thomas Gleixner , Juri Lelli , Ard Biesheuvel , Dmitriy Cherkasov , Anup Patel , Palmer Dabbelt , Will Deacon , linux-kernel@vger.kernel.org, Jeremy Linton , Morten Rasmussen , "Peter Zijlstra \(Intel\)" , Greg Kroah-Hartman , Sudeep Holla , Catalin Marinas , "Rafael J. Wysocki" , linux-riscv@lists.infradead.org, Ingo Molnar , "moderated list:ARM64 PORT \(AARCH64 ARCHITECTURE\)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org On Thu, Nov 29, 2018 at 03:28:18PM -0800, Atish Patra wrote: > cpu-map binding can be used to described cpu topology for both > RISC-V & ARM. It makes more sense to move the binding to document > to a common place. > > The relevant discussion can be found here. > https://lkml.org/lkml/2018/11/6/19 > > Signed-off-by: Atish Patra > --- > .../{arm/topology.txt => cpu/cpu-topology.txt} | 81 ++++++++++++++++++---- > 1 file changed, 67 insertions(+), 14 deletions(-) > rename Documentation/devicetree/bindings/{arm/topology.txt => cpu/cpu-topology.txt} (86%) > > diff --git a/Documentation/devicetree/bindings/arm/topology.txt b/Documentation/devicetree/bindings/cpu/cpu-topology.txt > similarity index 86% > rename from Documentation/devicetree/bindings/arm/topology.txt > rename to Documentation/devicetree/bindings/cpu/cpu-topology.txt > index 66848355..1de6fbce 100644 > --- a/Documentation/devicetree/bindings/arm/topology.txt > +++ b/Documentation/devicetree/bindings/cpu/cpu-topology.txt > @@ -1,12 +1,12 @@ > =========================================== > -ARM topology binding description > +CPU topology binding description > =========================================== > > =========================================== > 1 - Introduction > =========================================== > > -In an ARM system, the hierarchy of CPUs is defined through three entities that > +In a SMP system, the hierarchy of CPUs is defined through three entities that > are used to describe the layout of physical CPUs in the system: > > - socket > @@ -14,9 +14,6 @@ are used to describe the layout of physical CPUs in the system: > - core > - thread > > -The cpu nodes (bindings defined in [1]) represent the devices that > -correspond to physical CPUs and are to be mapped to the hierarchy levels. > - > The bottom hierarchy level sits at core or thread level depending on whether > symmetric multi-threading (SMT) is supported or not. > > @@ -25,33 +22,37 @@ threads existing in the system and map to the hierarchy level "thread" above. > In systems where SMT is not supported "cpu" nodes represent all cores present > in the system and map to the hierarchy level "core" above. > > -ARM topology bindings allow one to associate cpu nodes with hierarchical groups > +CPU topology bindings allow one to associate cpu nodes with hierarchical groups > corresponding to the system hierarchy; syntactically they are defined as device > tree nodes. > > -The remainder of this document provides the topology bindings for ARM, based > -on the Devicetree Specification, available from: > +Currently, only ARM/RISC-V intend to use this cpu topology binding but it may be > +used for any other architecture as well. > > -https://www.devicetree.org/specifications/ > +The remainder of this document provides the topology bindings for ARM/RISC-V, based You already said who are current users, why restrict it to ARM and RISC-V here? > +on the Devicetree Specification, available at [4]. > + > +The cpu nodes (bindings defined in [1] for ARM or [2] for RISC-V) represent the devices that > +correspond to physical CPUs and are to be mapped to the hierarchy levels. The cpu topology isn't dependent on anything beyond what the DT spec says for cpu nodes so I think this can be simplified to just refer to the spec. Plus, shouldn't [2] (numa) be [3] here. > 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]. > +documented in [1] or [3] for respective ISA. > A topology description containing phandles to cpu nodes that are not compliant > -with bindings standardized in [1] is therefore considered invalid. > +with bindings standardized in [1] or [3] is therefore considered invalid. > > =========================================== > 2 - cpu-map node > =========================================== > > -The ARM CPU topology is defined within the cpu-map node, which is a direct > +The ARM/RISC-V CPU topology is defined within the cpu-map node, which is a direct > child of the cpus node and provides a container where the actual topology > nodes are listed. > > - cpu-map node > > - Usage: Optional - On ARM SMP systems provide CPUs topology to the OS. > - ARM uniprocessor systems do not require a topology > + Usage: Optional - On SMP systems provide CPUs topology to the OS. > + Uniprocessor systems do not require a topology > description and therefore should not define a > cpu-map node. > > @@ -494,8 +495,60 @@ cpus { > }; > }; > > +Example 3: HiFive Unleashed (RISC-V 64 bit, 4 core system) > + > +cpus { > + #address-cells = <2>; > + #size-cells = <2>; > + compatible = "sifive,fu540g", "sifive,fu500"; > + model = "sifive,hifive-unleashed-a00"; This is wrong. Looks like the root node, but called 'cpus'. > + > + ... > + > + cpu-map { > + cluster0 { > + core0 { > + cpu = <&L12>; > + }; Mixed space and tabs. > + core1 { > + cpu = <&L15>; > + }; > + core2 { > + cpu0 = <&L18>; > + }; > + core3 { > + cpu0 = <&L21>; > + }; > + }; > + }; Mixed space and tab. > + > + L12: cpu@1 { > + device_type = "cpu"; > + compatible = "sifive,rocket0", "riscv"; > + reg = <0x1>; > + } > + > + L15: cpu@2 { > + device_type = "cpu"; > + compatible = "sifive,rocket0", "riscv"; > + reg = <0x2>; > + } > + L18: cpu@3 { > + device_type = "cpu"; > + compatible = "sifive,rocket0", "riscv"; > + reg = <0x3>; > + } > + L21: cpu@4 { > + device_type = "cpu"; > + compatible = "sifive,rocket0", "riscv"; > + reg = <0x4>; > + } > +}; > =============================================================================== > [1] ARM Linux kernel documentation > Documentation/devicetree/bindings/arm/cpus.txt > [2] Devicetree NUMA binding description > Documentation/devicetree/bindings/numa.txt > +[3] RISC-V Linux kernel documentation > + Documentation/devicetree/bindings/riscv/cpus.txt > +[4] https://www.devicetree.org/specifications/ > -- > 2.7.4 > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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=-8.7 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT autolearn=unavailable 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 BDBEAC6783B for ; Wed, 12 Dec 2018 02:31:42 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 8F7AA20839 for ; Wed, 12 Dec 2018 02:31:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="UNBhfa5s" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8F7AA20839 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=cuajt0Ok1DJi7iZJ9wiVjxF48PLLmwBqdxDcdPCzeN4=; b=UNBhfa5s02pbFl 4LP2EHJb/MY+ug4gh11KwYy/89JBqlYvmWPfM9GY+xcbvLGfVjk/lYSfku2cwQ4c5zlMaAGkBLjOn lPaKCO/R8wTBrANNCiaAZZdwQbHMEnoFWx8pBESvKm3BqjF1qN1CnjYoEbIQ6Q9TaDi2W1rbeXfD4 CX5Kctqb2dmWiswIaI4jh6MWvcuzS/ai5g2rRtXELsLg/3yiO/1XI5Z5MBjAXu/xUGfWeZj5tkJTR Yb3NrfTsZw+QWqn+DsIk0XtFcbgczMoDHAU3vP/ap8oPS1kb689IwutC9nQG18G2sIAuAq7L3RK6t FzoWkAeqoFhkpYuCOHrg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gWuJI-0004J9-Qh; Wed, 12 Dec 2018 02:31:40 +0000 Received: from mail-oi1-f196.google.com ([209.85.167.196]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gWuJE-0004IP-SA; Wed, 12 Dec 2018 02:31:38 +0000 Received: by mail-oi1-f196.google.com with SMTP id i6so13828595oia.6; Tue, 11 Dec 2018 18:31:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=JSdQZJweWPk6BAdWHHcAkj2ssa0zPN7sDYIXlGWtClU=; b=lWav1Z4zBogHoFoRgwspGrdL+d4ByB+PA7FrmiNCWYF0bKUOrPcyNqHaQTqvfMJX/X 1Y11CUjcgw77+JS7noIE2t5aFvZudHrGDbi0UTtHDexTJgFQ8pZJav/VxsM3dxfCYgma a2TR/Yj0Na8twziZLapECD9ciITxcIWEjD6fzZv89YJofo15tuv+Az5XnQ066EnfQN1g sSvrGgruchZLIeNRJ6zfC3vThgMJ91S6FStAClUIO1nil+t7sZJocHYeQa2imS4cNe4z 9vCHDIf3v5hmSKYCyXVS1YsWYVDElsbOIj+AuapEJL2MTLEdYTOa6ejF06JEr6SXzB5s NaWg== X-Gm-Message-State: AA+aEWYOX9A7+eYaK3dq3iputEKpo2z9v1PtyvAWKZ36lE1F896/foYx yjmo8jO08BW3ngECBusFyg== X-Google-Smtp-Source: AFSGD/WUL+gr1+ZUmzzI/idm/8r5/q6w5+BAYiwGlY05OjIWeXzXSE+UTITJGjVxF5ZsAaRfqSn3vw== X-Received: by 2002:aca:e3d3:: with SMTP id a202mr2551031oih.79.1544581883988; Tue, 11 Dec 2018 18:31:23 -0800 (PST) Received: from localhost (24-155-109-49.dyn.grandenetworks.net. [24.155.109.49]) by smtp.gmail.com with ESMTPSA id f127sm9431995oia.19.2018.12.11.18.31.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 11 Dec 2018 18:31:23 -0800 (PST) Date: Tue, 11 Dec 2018 20:31:22 -0600 From: Rob Herring To: Atish Patra Subject: Re: [RFT PATCH v1 2/4] dt-binding: cpu-topology: Move cpu-map to a common binding. Message-ID: <20181212023122.GB14213@bogus> References: <1543534100-3654-1-git-send-email-atish.patra@wdc.com> <1543534100-3654-3-git-send-email-atish.patra@wdc.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1543534100-3654-3-git-send-email-atish.patra@wdc.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20181211_183136_953161_FC9A15DA X-CRM114-Status: GOOD ( 25.84 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , devicetree@vger.kernel.org, Albert Ou , Thomas Gleixner , Juri Lelli , Ard Biesheuvel , Dmitriy Cherkasov , Anup Patel , Palmer Dabbelt , Will Deacon , linux-kernel@vger.kernel.org, Jeremy Linton , Morten Rasmussen , "Peter Zijlstra \(Intel\)" , Greg Kroah-Hartman , Sudeep Holla , Catalin Marinas , "Rafael J. Wysocki" , linux-riscv@lists.infradead.org, Ingo Molnar , "moderated list:ARM64 PORT \(AARCH64 ARCHITECTURE\)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Nov 29, 2018 at 03:28:18PM -0800, Atish Patra wrote: > cpu-map binding can be used to described cpu topology for both > RISC-V & ARM. It makes more sense to move the binding to document > to a common place. > > The relevant discussion can be found here. > https://lkml.org/lkml/2018/11/6/19 > > Signed-off-by: Atish Patra > --- > .../{arm/topology.txt => cpu/cpu-topology.txt} | 81 ++++++++++++++++++---- > 1 file changed, 67 insertions(+), 14 deletions(-) > rename Documentation/devicetree/bindings/{arm/topology.txt => cpu/cpu-topology.txt} (86%) > > diff --git a/Documentation/devicetree/bindings/arm/topology.txt b/Documentation/devicetree/bindings/cpu/cpu-topology.txt > similarity index 86% > rename from Documentation/devicetree/bindings/arm/topology.txt > rename to Documentation/devicetree/bindings/cpu/cpu-topology.txt > index 66848355..1de6fbce 100644 > --- a/Documentation/devicetree/bindings/arm/topology.txt > +++ b/Documentation/devicetree/bindings/cpu/cpu-topology.txt > @@ -1,12 +1,12 @@ > =========================================== > -ARM topology binding description > +CPU topology binding description > =========================================== > > =========================================== > 1 - Introduction > =========================================== > > -In an ARM system, the hierarchy of CPUs is defined through three entities that > +In a SMP system, the hierarchy of CPUs is defined through three entities that > are used to describe the layout of physical CPUs in the system: > > - socket > @@ -14,9 +14,6 @@ are used to describe the layout of physical CPUs in the system: > - core > - thread > > -The cpu nodes (bindings defined in [1]) represent the devices that > -correspond to physical CPUs and are to be mapped to the hierarchy levels. > - > The bottom hierarchy level sits at core or thread level depending on whether > symmetric multi-threading (SMT) is supported or not. > > @@ -25,33 +22,37 @@ threads existing in the system and map to the hierarchy level "thread" above. > In systems where SMT is not supported "cpu" nodes represent all cores present > in the system and map to the hierarchy level "core" above. > > -ARM topology bindings allow one to associate cpu nodes with hierarchical groups > +CPU topology bindings allow one to associate cpu nodes with hierarchical groups > corresponding to the system hierarchy; syntactically they are defined as device > tree nodes. > > -The remainder of this document provides the topology bindings for ARM, based > -on the Devicetree Specification, available from: > +Currently, only ARM/RISC-V intend to use this cpu topology binding but it may be > +used for any other architecture as well. > > -https://www.devicetree.org/specifications/ > +The remainder of this document provides the topology bindings for ARM/RISC-V, based You already said who are current users, why restrict it to ARM and RISC-V here? > +on the Devicetree Specification, available at [4]. > + > +The cpu nodes (bindings defined in [1] for ARM or [2] for RISC-V) represent the devices that > +correspond to physical CPUs and are to be mapped to the hierarchy levels. The cpu topology isn't dependent on anything beyond what the DT spec says for cpu nodes so I think this can be simplified to just refer to the spec. Plus, shouldn't [2] (numa) be [3] here. > 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]. > +documented in [1] or [3] for respective ISA. > A topology description containing phandles to cpu nodes that are not compliant > -with bindings standardized in [1] is therefore considered invalid. > +with bindings standardized in [1] or [3] is therefore considered invalid. > > =========================================== > 2 - cpu-map node > =========================================== > > -The ARM CPU topology is defined within the cpu-map node, which is a direct > +The ARM/RISC-V CPU topology is defined within the cpu-map node, which is a direct > child of the cpus node and provides a container where the actual topology > nodes are listed. > > - cpu-map node > > - Usage: Optional - On ARM SMP systems provide CPUs topology to the OS. > - ARM uniprocessor systems do not require a topology > + Usage: Optional - On SMP systems provide CPUs topology to the OS. > + Uniprocessor systems do not require a topology > description and therefore should not define a > cpu-map node. > > @@ -494,8 +495,60 @@ cpus { > }; > }; > > +Example 3: HiFive Unleashed (RISC-V 64 bit, 4 core system) > + > +cpus { > + #address-cells = <2>; > + #size-cells = <2>; > + compatible = "sifive,fu540g", "sifive,fu500"; > + model = "sifive,hifive-unleashed-a00"; This is wrong. Looks like the root node, but called 'cpus'. > + > + ... > + > + cpu-map { > + cluster0 { > + core0 { > + cpu = <&L12>; > + }; Mixed space and tabs. > + core1 { > + cpu = <&L15>; > + }; > + core2 { > + cpu0 = <&L18>; > + }; > + core3 { > + cpu0 = <&L21>; > + }; > + }; > + }; Mixed space and tab. > + > + L12: cpu@1 { > + device_type = "cpu"; > + compatible = "sifive,rocket0", "riscv"; > + reg = <0x1>; > + } > + > + L15: cpu@2 { > + device_type = "cpu"; > + compatible = "sifive,rocket0", "riscv"; > + reg = <0x2>; > + } > + L18: cpu@3 { > + device_type = "cpu"; > + compatible = "sifive,rocket0", "riscv"; > + reg = <0x3>; > + } > + L21: cpu@4 { > + device_type = "cpu"; > + compatible = "sifive,rocket0", "riscv"; > + reg = <0x4>; > + } > +}; > =============================================================================== > [1] ARM Linux kernel documentation > Documentation/devicetree/bindings/arm/cpus.txt > [2] Devicetree NUMA binding description > Documentation/devicetree/bindings/numa.txt > +[3] RISC-V Linux kernel documentation > + Documentation/devicetree/bindings/riscv/cpus.txt > +[4] https://www.devicetree.org/specifications/ > -- > 2.7.4 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel