From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kumar Gala Subject: Re: [PATCH v3 2/4] arm64: dts: Add Qualcomm MSM8916 SoC and evaluation board dts Date: Thu, 12 Mar 2015 14:54:15 -0500 Message-ID: References: <1426107080-29079-1-git-send-email-galak@codeaurora.org> <1426107080-29079-2-git-send-email-galak@codeaurora.org> <20150312170541.GE30145@leverpostej> <20150312182508.GF30145@leverpostej> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from smtp.codeaurora.org ([198.145.29.96]:58798 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754831AbbCLTyU convert rfc822-to-8bit (ORCPT ); Thu, 12 Mar 2015 15:54:20 -0400 In-Reply-To: <20150312182508.GF30145@leverpostej> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Mark Rutland Cc: "linux-arm-msm@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "arm@kernel.org" , "devicetree@vger.kernel.org" , "heiko@sntech.de" On Mar 12, 2015, at 1:25 PM, Mark Rutland wrote: >>>> + cpus { >>>> + #address-cells =3D <1>; >>>> + #size-cells =3D <0>; >>>> + >>>> + CPU0: cpu@0 { >>>> + device_type =3D "cpu"; >>>> + compatible =3D "arm,cortex-a53", "arm,armv8"; >>>> + reg =3D <0x0>; >>>> + }; >>>> + >>>> + CPU1: cpu@1 { >>>> + device_type =3D "cpu"; >>>> + compatible =3D "arm,cortex-a53", "arm,armv8"; >>>> + reg =3D <0x1>; >>>> + }; >>>> + >>>> + CPU2: cpu@2 { >>>> + device_type =3D "cpu"; >>>> + compatible =3D "arm,cortex-a53", "arm,armv8"; >>>> + reg =3D <0x2>; >>>> + }; >>>> + >>>> + CPU3: cpu@3 { >>>> + device_type =3D "cpu"; >>>> + compatible =3D "arm,cortex-a53", "arm,armv8"; >>>> + reg =3D <0x3>; >>>> + }; >>>> + }; >>>=20 >>> The secondary CPUs need an enable-method. Are you using PSCI or >>> spin-table? >>=20 >> This is on purpose. We aren=92t using either PSCI or spin-table. R= ight >> now the dts is for booting on a single core. I can drop CPU1..CPU3 = if >> that helps. >=20 > We won't poke the CPUs without an enable-method, so personally I'm no= t > too worried either way about having the CPUs listed. That was my thinking, so left them in. > Which of spin-table/psci are you planning on using for SMP support, a= nd > when would that be likely to appear? We have a qcom specific SMP enablement method for this device. This wa= s one of our first devices so it utilized as much from arm 32-bit as po= ssible. > Which exception level do CPUs enter the kernel? Even without a > virt-capable GIC booting at EL2 is less work for the FW and gives the > kernel a better chance of fixing things up (e.g. CNTVOFF). I think the enter in EL1. - k --=20 Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora For= um, a Linux Foundation Collaborative Project From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755817AbbCLTyW (ORCPT ); Thu, 12 Mar 2015 15:54:22 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:58798 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754831AbbCLTyU convert rfc822-to-8bit (ORCPT ); Thu, 12 Mar 2015 15:54:20 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [PATCH v3 2/4] arm64: dts: Add Qualcomm MSM8916 SoC and evaluation board dts From: Kumar Gala In-Reply-To: <20150312182508.GF30145@leverpostej> Date: Thu, 12 Mar 2015 14:54:15 -0500 Cc: "linux-arm-msm@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "arm@kernel.org" , "devicetree@vger.kernel.org" , "heiko@sntech.de" Content-Transfer-Encoding: 8BIT Message-Id: References: <1426107080-29079-1-git-send-email-galak@codeaurora.org> <1426107080-29079-2-git-send-email-galak@codeaurora.org> <20150312170541.GE30145@leverpostej> <20150312182508.GF30145@leverpostej> To: Mark Rutland X-Mailer: Apple Mail (2.1878.6) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mar 12, 2015, at 1:25 PM, Mark Rutland wrote: >>>> + cpus { >>>> + #address-cells = <1>; >>>> + #size-cells = <0>; >>>> + >>>> + CPU0: cpu@0 { >>>> + device_type = "cpu"; >>>> + compatible = "arm,cortex-a53", "arm,armv8"; >>>> + reg = <0x0>; >>>> + }; >>>> + >>>> + CPU1: cpu@1 { >>>> + device_type = "cpu"; >>>> + compatible = "arm,cortex-a53", "arm,armv8"; >>>> + reg = <0x1>; >>>> + }; >>>> + >>>> + CPU2: cpu@2 { >>>> + device_type = "cpu"; >>>> + compatible = "arm,cortex-a53", "arm,armv8"; >>>> + reg = <0x2>; >>>> + }; >>>> + >>>> + CPU3: cpu@3 { >>>> + device_type = "cpu"; >>>> + compatible = "arm,cortex-a53", "arm,armv8"; >>>> + reg = <0x3>; >>>> + }; >>>> + }; >>> >>> The secondary CPUs need an enable-method. Are you using PSCI or >>> spin-table? >> >> This is on purpose. We aren’t using either PSCI or spin-table. Right >> now the dts is for booting on a single core. I can drop CPU1..CPU3 if >> that helps. > > We won't poke the CPUs without an enable-method, so personally I'm not > too worried either way about having the CPUs listed. That was my thinking, so left them in. > Which of spin-table/psci are you planning on using for SMP support, and > when would that be likely to appear? We have a qcom specific SMP enablement method for this device. This was one of our first devices so it utilized as much from arm 32-bit as possible. > Which exception level do CPUs enter the kernel? Even without a > virt-capable GIC booting at EL2 is less work for the FW and gives the > kernel a better chance of fixing things up (e.g. CNTVOFF). I think the enter in EL1. - k -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project From mboxrd@z Thu Jan 1 00:00:00 1970 From: galak@codeaurora.org (Kumar Gala) Date: Thu, 12 Mar 2015 14:54:15 -0500 Subject: [PATCH v3 2/4] arm64: dts: Add Qualcomm MSM8916 SoC and evaluation board dts In-Reply-To: <20150312182508.GF30145@leverpostej> References: <1426107080-29079-1-git-send-email-galak@codeaurora.org> <1426107080-29079-2-git-send-email-galak@codeaurora.org> <20150312170541.GE30145@leverpostej> <20150312182508.GF30145@leverpostej> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mar 12, 2015, at 1:25 PM, Mark Rutland wrote: >>>> + cpus { >>>> + #address-cells = <1>; >>>> + #size-cells = <0>; >>>> + >>>> + CPU0: cpu at 0 { >>>> + device_type = "cpu"; >>>> + compatible = "arm,cortex-a53", "arm,armv8"; >>>> + reg = <0x0>; >>>> + }; >>>> + >>>> + CPU1: cpu at 1 { >>>> + device_type = "cpu"; >>>> + compatible = "arm,cortex-a53", "arm,armv8"; >>>> + reg = <0x1>; >>>> + }; >>>> + >>>> + CPU2: cpu at 2 { >>>> + device_type = "cpu"; >>>> + compatible = "arm,cortex-a53", "arm,armv8"; >>>> + reg = <0x2>; >>>> + }; >>>> + >>>> + CPU3: cpu at 3 { >>>> + device_type = "cpu"; >>>> + compatible = "arm,cortex-a53", "arm,armv8"; >>>> + reg = <0x3>; >>>> + }; >>>> + }; >>> >>> The secondary CPUs need an enable-method. Are you using PSCI or >>> spin-table? >> >> This is on purpose. We aren?t using either PSCI or spin-table. Right >> now the dts is for booting on a single core. I can drop CPU1..CPU3 if >> that helps. > > We won't poke the CPUs without an enable-method, so personally I'm not > too worried either way about having the CPUs listed. That was my thinking, so left them in. > Which of spin-table/psci are you planning on using for SMP support, and > when would that be likely to appear? We have a qcom specific SMP enablement method for this device. This was one of our first devices so it utilized as much from arm 32-bit as possible. > Which exception level do CPUs enter the kernel? Even without a > virt-capable GIC booting at EL2 is less work for the FW and gives the > kernel a better chance of fixing things up (e.g. CNTVOFF). I think the enter in EL1. - k -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project