From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752044AbaGaPWl (ORCPT ); Thu, 31 Jul 2014 11:22:41 -0400 Received: from mail-vc0-f177.google.com ([209.85.220.177]:51057 "EHLO mail-vc0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751770AbaGaPWk (ORCPT ); Thu, 31 Jul 2014 11:22:40 -0400 MIME-Version: 1.0 In-Reply-To: <20140731123443.GS4703@rric.localhost> References: <1406732794-20920-1-git-send-email-rric@kernel.org> <1406732794-20920-3-git-send-email-rric@kernel.org> <20140730154626.GD20162@leverpostej> <20140731123443.GS4703@rric.localhost> From: Rob Herring Date: Thu, 31 Jul 2014 10:22:19 -0500 Message-ID: Subject: Re: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC To: Robert Richter Cc: Mark Rutland , Catalin Marinas , Will Deacon , Rob Herring , Arnd Bergmann , Pawel Moll , Ian Campbell , Kumar Gala , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Radha Mohan Chintakuntla , Robert Richter , "devicetree@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 31, 2014 at 7:34 AM, Robert Richter wrote: > On 30.07.14 11:37:38, Rob Herring wrote: >> On Wed, Jul 30, 2014 at 10:46 AM, Mark Rutland wrote: >> > On Wed, Jul 30, 2014 at 04:06:31PM +0100, Robert Richter wrote: >> >> From: Radha Mohan Chintakuntla > >> >> +/ { >> >> + model = "Cavium ThunderX CN88XX Family"; >> >> + compatible = "cavium,thunder-88xx"; >> > >> > Please don't use wildcards in compatible strings. Give this an absolute >> > name, and override as necessary. > > The naming 88xx refers to the processor family and arn't actually > wildcards. In the future we might need another dts file for 87xx, but > so far all SoCs of 88xx family should use the same dts files. In this > sense the naming is very specific. Yes, but each implementation can have its own errata. You might not need to distinguish them now, but you could in the future. However, if the family is really all the same die and different parts are just marketing, then the name is fine. Or if you can easily probe the exact part and revision it's probably fine. > > >> >> + cpus { >> >> + #address-cells = <2>; >> >> + #size-cells = <0>; >> >> + >> >> + cpu@000 { >> >> + device_type = "cpu"; >> >> + compatible = "cavium,thunder", "arm,armv8"; >> >> + reg = <0x0 0x000>; >> >> + enable-method = "psci"; >> >> + }; >> > >> > Just to check: both the SoC and CPU are called thunder? > > The soc is called thunder-88xx, the cpu thunder. E.g. an 87xx soc will > have the same core in which is thunder. And the next version of the core would be called something else? thunder-v2? lightning? As long as they are distinguishable they should be fine. Rob > > >> >> + memory@00000000 { >> >> + device_type = "memory"; >> >> + reg = <0x0 0x00000000 0x0 0x80000000>; >> >> + }; >> >> + >> >> + gic0: interrupt-controller@801000000000 { >> > >> > To make this easier to read, please place a comma between 32-bit >> > portions of the unit address (e.g. here have 8010,00000000). > > Changed this. > >> >> Mark, perhaps a dtc or checkpatch.pl check for this? >> >> This should also be under a bus node. > > Will do. > >> >> >> + compatible = "arm,gic-v3"; >> >> + #interrupt-cells = <3>; >> >> + #address-cells = <2>; >> >> + #size-cells = <2>; >> >> + ranges; >> > >> > This has no children, so why have ranges, #address-cells, and >> > #size-cells? > > Right, this is a leftover from a change in a follow on patch that > introduces a child for its. Will remove #address-cells, #size-cells > and ranges in this patch and move the change to the later patch. > >> > >> >> + interrupt-controller; >> >> + reg = <0x8010 0x00000000 0x0 0x010000>, /* GICD */ >> >> + <0x8010 0x80000000 0x0 0x200000>; /* GICR */ >> >> + interrupts = <1 9 0xf04>; >> >> + }; > >> >> + clocks { >> >> + #address-cells = <2>; >> >> + #size-cells = <2>; >> >> + ranges; >> >> + >> >> + refclk50mhz: refclk50mhz { >> >> + compatible = "fixed-clock"; >> >> + #clock-cells = <0>; >> >> + clock-frequency = <50000000>; >> >> + clock-output-names = "refclk50mhz"; >> >> + }; >> >> + }; >> > >> > Please get rid of the clocks node and just put the clocks here. > > Will do. > >> > >> >> + >> >> + uaa0: serial@87e024000000 { >> >> + compatible = "arm,pl011", "arm,primecell"; >> >> + reg = <0x87e0 0x24000000 0x0 0x1000>; >> >> + interrupts = <1 21 4>; >> >> + clocks = <&refclk50mhz>; >> >> + clock-names = "apb_pclk"; >> > >> > Is this actually the apb_pclk, or is the the uartclk? I assume it's the >> > latter. >> >> Shouldn't new bindings have both clocks here? A single clock was a >> mistake I think (mine in fact). > > Do you mean > clock-names = "uartclk", "apb_pclk"; > here? Yes, but Mark said this change never happened so maybe it is fine. In any case, follow the pl011 binding documentation. Rob From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Subject: Re: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC Date: Thu, 31 Jul 2014 10:22:19 -0500 Message-ID: References: <1406732794-20920-1-git-send-email-rric@kernel.org> <1406732794-20920-3-git-send-email-rric@kernel.org> <20140730154626.GD20162@leverpostej> <20140731123443.GS4703@rric.localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <20140731123443.GS4703-vWBEXY7mpu73kLQC+b9v0A@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Robert Richter Cc: Mark Rutland , Catalin Marinas , Will Deacon , Rob Herring , Arnd Bergmann , Pawel Moll , Ian Campbell , Kumar Gala , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Radha Mohan Chintakuntla , Robert Richter , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: devicetree@vger.kernel.org On Thu, Jul 31, 2014 at 7:34 AM, Robert Richter wrote: > On 30.07.14 11:37:38, Rob Herring wrote: >> On Wed, Jul 30, 2014 at 10:46 AM, Mark Rutland wrote: >> > On Wed, Jul 30, 2014 at 04:06:31PM +0100, Robert Richter wrote: >> >> From: Radha Mohan Chintakuntla > >> >> +/ { >> >> + model = "Cavium ThunderX CN88XX Family"; >> >> + compatible = "cavium,thunder-88xx"; >> > >> > Please don't use wildcards in compatible strings. Give this an absolute >> > name, and override as necessary. > > The naming 88xx refers to the processor family and arn't actually > wildcards. In the future we might need another dts file for 87xx, but > so far all SoCs of 88xx family should use the same dts files. In this > sense the naming is very specific. Yes, but each implementation can have its own errata. You might not need to distinguish them now, but you could in the future. However, if the family is really all the same die and different parts are just marketing, then the name is fine. Or if you can easily probe the exact part and revision it's probably fine. > > >> >> + cpus { >> >> + #address-cells = <2>; >> >> + #size-cells = <0>; >> >> + >> >> + cpu@000 { >> >> + device_type = "cpu"; >> >> + compatible = "cavium,thunder", "arm,armv8"; >> >> + reg = <0x0 0x000>; >> >> + enable-method = "psci"; >> >> + }; >> > >> > Just to check: both the SoC and CPU are called thunder? > > The soc is called thunder-88xx, the cpu thunder. E.g. an 87xx soc will > have the same core in which is thunder. And the next version of the core would be called something else? thunder-v2? lightning? As long as they are distinguishable they should be fine. Rob > > >> >> + memory@00000000 { >> >> + device_type = "memory"; >> >> + reg = <0x0 0x00000000 0x0 0x80000000>; >> >> + }; >> >> + >> >> + gic0: interrupt-controller@801000000000 { >> > >> > To make this easier to read, please place a comma between 32-bit >> > portions of the unit address (e.g. here have 8010,00000000). > > Changed this. > >> >> Mark, perhaps a dtc or checkpatch.pl check for this? >> >> This should also be under a bus node. > > Will do. > >> >> >> + compatible = "arm,gic-v3"; >> >> + #interrupt-cells = <3>; >> >> + #address-cells = <2>; >> >> + #size-cells = <2>; >> >> + ranges; >> > >> > This has no children, so why have ranges, #address-cells, and >> > #size-cells? > > Right, this is a leftover from a change in a follow on patch that > introduces a child for its. Will remove #address-cells, #size-cells > and ranges in this patch and move the change to the later patch. > >> > >> >> + interrupt-controller; >> >> + reg = <0x8010 0x00000000 0x0 0x010000>, /* GICD */ >> >> + <0x8010 0x80000000 0x0 0x200000>; /* GICR */ >> >> + interrupts = <1 9 0xf04>; >> >> + }; > >> >> + clocks { >> >> + #address-cells = <2>; >> >> + #size-cells = <2>; >> >> + ranges; >> >> + >> >> + refclk50mhz: refclk50mhz { >> >> + compatible = "fixed-clock"; >> >> + #clock-cells = <0>; >> >> + clock-frequency = <50000000>; >> >> + clock-output-names = "refclk50mhz"; >> >> + }; >> >> + }; >> > >> > Please get rid of the clocks node and just put the clocks here. > > Will do. > >> > >> >> + >> >> + uaa0: serial@87e024000000 { >> >> + compatible = "arm,pl011", "arm,primecell"; >> >> + reg = <0x87e0 0x24000000 0x0 0x1000>; >> >> + interrupts = <1 21 4>; >> >> + clocks = <&refclk50mhz>; >> >> + clock-names = "apb_pclk"; >> > >> > Is this actually the apb_pclk, or is the the uartclk? I assume it's the >> > latter. >> >> Shouldn't new bindings have both clocks here? A single clock was a >> mistake I think (mine in fact). > > Do you mean > clock-names = "uartclk", "apb_pclk"; > here? Yes, but Mark said this change never happened so maybe it is fine. In any case, follow the pl011 binding documentation. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: robherring2@gmail.com (Rob Herring) Date: Thu, 31 Jul 2014 10:22:19 -0500 Subject: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC In-Reply-To: <20140731123443.GS4703@rric.localhost> References: <1406732794-20920-1-git-send-email-rric@kernel.org> <1406732794-20920-3-git-send-email-rric@kernel.org> <20140730154626.GD20162@leverpostej> <20140731123443.GS4703@rric.localhost> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Jul 31, 2014 at 7:34 AM, Robert Richter wrote: > On 30.07.14 11:37:38, Rob Herring wrote: >> On Wed, Jul 30, 2014 at 10:46 AM, Mark Rutland wrote: >> > On Wed, Jul 30, 2014 at 04:06:31PM +0100, Robert Richter wrote: >> >> From: Radha Mohan Chintakuntla > >> >> +/ { >> >> + model = "Cavium ThunderX CN88XX Family"; >> >> + compatible = "cavium,thunder-88xx"; >> > >> > Please don't use wildcards in compatible strings. Give this an absolute >> > name, and override as necessary. > > The naming 88xx refers to the processor family and arn't actually > wildcards. In the future we might need another dts file for 87xx, but > so far all SoCs of 88xx family should use the same dts files. In this > sense the naming is very specific. Yes, but each implementation can have its own errata. You might not need to distinguish them now, but you could in the future. However, if the family is really all the same die and different parts are just marketing, then the name is fine. Or if you can easily probe the exact part and revision it's probably fine. > > >> >> + cpus { >> >> + #address-cells = <2>; >> >> + #size-cells = <0>; >> >> + >> >> + cpu at 000 { >> >> + device_type = "cpu"; >> >> + compatible = "cavium,thunder", "arm,armv8"; >> >> + reg = <0x0 0x000>; >> >> + enable-method = "psci"; >> >> + }; >> > >> > Just to check: both the SoC and CPU are called thunder? > > The soc is called thunder-88xx, the cpu thunder. E.g. an 87xx soc will > have the same core in which is thunder. And the next version of the core would be called something else? thunder-v2? lightning? As long as they are distinguishable they should be fine. Rob > > >> >> + memory at 00000000 { >> >> + device_type = "memory"; >> >> + reg = <0x0 0x00000000 0x0 0x80000000>; >> >> + }; >> >> + >> >> + gic0: interrupt-controller at 801000000000 { >> > >> > To make this easier to read, please place a comma between 32-bit >> > portions of the unit address (e.g. here have 8010,00000000). > > Changed this. > >> >> Mark, perhaps a dtc or checkpatch.pl check for this? >> >> This should also be under a bus node. > > Will do. > >> >> >> + compatible = "arm,gic-v3"; >> >> + #interrupt-cells = <3>; >> >> + #address-cells = <2>; >> >> + #size-cells = <2>; >> >> + ranges; >> > >> > This has no children, so why have ranges, #address-cells, and >> > #size-cells? > > Right, this is a leftover from a change in a follow on patch that > introduces a child for its. Will remove #address-cells, #size-cells > and ranges in this patch and move the change to the later patch. > >> > >> >> + interrupt-controller; >> >> + reg = <0x8010 0x00000000 0x0 0x010000>, /* GICD */ >> >> + <0x8010 0x80000000 0x0 0x200000>; /* GICR */ >> >> + interrupts = <1 9 0xf04>; >> >> + }; > >> >> + clocks { >> >> + #address-cells = <2>; >> >> + #size-cells = <2>; >> >> + ranges; >> >> + >> >> + refclk50mhz: refclk50mhz { >> >> + compatible = "fixed-clock"; >> >> + #clock-cells = <0>; >> >> + clock-frequency = <50000000>; >> >> + clock-output-names = "refclk50mhz"; >> >> + }; >> >> + }; >> > >> > Please get rid of the clocks node and just put the clocks here. > > Will do. > >> > >> >> + >> >> + uaa0: serial at 87e024000000 { >> >> + compatible = "arm,pl011", "arm,primecell"; >> >> + reg = <0x87e0 0x24000000 0x0 0x1000>; >> >> + interrupts = <1 21 4>; >> >> + clocks = <&refclk50mhz>; >> >> + clock-names = "apb_pclk"; >> > >> > Is this actually the apb_pclk, or is the the uartclk? I assume it's the >> > latter. >> >> Shouldn't new bindings have both clocks here? A single clock was a >> mistake I think (mine in fact). > > Do you mean > clock-names = "uartclk", "apb_pclk"; > here? Yes, but Mark said this change never happened so maybe it is fine. In any case, follow the pl011 binding documentation. Rob