* [PATCH 0/3] arm64: add new support Samsung GH7 SoC and SSDK board @ 2014-02-11 6:29 ` Kukjin Kim 0 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-11 6:29 UTC (permalink / raw) To: linux-arm-kernel, linux-samsung-soc; +Cc: Ilho Lee, Thomas Abraham This adds support for Samsung ARMv8 core based GH7 SoC and its evaluation SSDK board. [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family [PATCH 3/3] Documentation: DT: add new entry for Samsung GH7 SoC and SSDK board ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 0/3] arm64: add new support Samsung GH7 SoC and SSDK board @ 2014-02-11 6:29 ` Kukjin Kim 0 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-11 6:29 UTC (permalink / raw) To: linux-arm-kernel This adds support for Samsung ARMv8 core based GH7 SoC and its evaluation SSDK board. [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family [PATCH 3/3] Documentation: DT: add new entry for Samsung GH7 SoC and SSDK board ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board 2014-02-11 6:29 ` Kukjin Kim @ 2014-02-11 6:29 ` Kukjin Kim -1 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-11 6:29 UTC (permalink / raw) To: linux-arm-kernel, linux-samsung-soc Cc: Ilho Lee, Thomas Abraham, Kukjin Kim, Catalin Marinas Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Reviewed-by: Thomas Abraham <thomas.ab@samsung.com> Cc: Catalin Marinas <catalin.marinas@arm.com> --- arch/arm64/boot/dts/samsung-gh7.dtsi | 108 ++++++++++++++++++++++++++++++ arch/arm64/boot/dts/samsung-ssdk-gh7.dts | 26 +++++++ 2 files changed, 134 insertions(+) create mode 100644 arch/arm64/boot/dts/samsung-gh7.dtsi create mode 100644 arch/arm64/boot/dts/samsung-ssdk-gh7.dts diff --git a/arch/arm64/boot/dts/samsung-gh7.dtsi b/arch/arm64/boot/dts/samsung-gh7.dtsi new file mode 100644 index 0000000..5b8785c --- /dev/null +++ b/arch/arm64/boot/dts/samsung-gh7.dtsi @@ -0,0 +1,108 @@ +/* + * SAMSUNG GH7 SoC device tree source + * + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +/dts-v1/; + +/memreserve/ 0x80000000 0x0C400000; + +/ { + model = "SAMSUNG GH7"; + compatible = "samsung,gh7"; + interrupt-parent = <&gic>; + #address-cells = <2>; + #size-cells = <2>; + + cpus { + #address-cells = <2>; + #size-cells = <0>; + + cpu@000 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x0 0x000>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x8000fff8>; + }; + cpu@001 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x0 0x001>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x8000fff8>; + }; + cpu@002 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x0 0x002>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x8000fff8>; + }; + cpu@003 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x0 0x003>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x8000fff8>; + }; + }; + + gic: interrupt-controller@1C000000 { + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; + #interrupt-cells = <3>; + #address-cells = <0>; + interrupt-controller; + reg = <0x0 0x1C001000 0 0x1000>, /* GIC Dist */ + <0x0 0x1C002000 0 0x1000>, /* GIC CPU */ + <0x0 0x1C004000 0 0x2000>, /* GIC VCPU Control */ + <0x0 0x1C006000 0 0x2000>; /* GIC VCPU */ + interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <1 13 0xff01>, /* Secure Phys IRQ */ + <1 14 0xff01>, /* Non-secure Phys IRQ */ + <1 11 0xff01>, /* Virt IRQ */ + <1 10 0xff01>; /* Hyp IRQ */ + clock-frequency = <100000000>; + }; + + pmu { + compatible = "arm,armv8-pmuv3"; + interrupts = <0 294 8>, + <0 295 8>, + <0 296 8>, + <0 297 8>, + <0 298 8>, + <0 299 8>, + <0 300 8>, + <0 301 8>; + }; + + amba { + compatible = "arm,amba-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + serial@12c00000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x12c00000 0x10000>; + interrupts = <418>; + }; + + serial@12c20000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x12c20000 0x10000>; + interrupts = <420>; + }; + }; +}; diff --git a/arch/arm64/boot/dts/samsung-ssdk-gh7.dts b/arch/arm64/boot/dts/samsung-ssdk-gh7.dts new file mode 100644 index 0000000..47afbc4 --- /dev/null +++ b/arch/arm64/boot/dts/samsung-ssdk-gh7.dts @@ -0,0 +1,26 @@ +/* + * SAMSUNG SSDK-GH7 board device tree source + * + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +/dts-v1/; +#include "samsung-gh7.dtsi" + +/ { + model = "SAMSUNG SSDK-GH7 board based on GH7 SoC"; + compatible = "samsung,ssdk-gh7", "samsung,gh7"; + + chosen { + }; + + memory@80000000 { + device_type = "memory"; + reg = <0x00000000 0x80000000 0 0x80000000>; + }; +}; -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board @ 2014-02-11 6:29 ` Kukjin Kim 0 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-11 6:29 UTC (permalink / raw) To: linux-arm-kernel Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Reviewed-by: Thomas Abraham <thomas.ab@samsung.com> Cc: Catalin Marinas <catalin.marinas@arm.com> --- arch/arm64/boot/dts/samsung-gh7.dtsi | 108 ++++++++++++++++++++++++++++++ arch/arm64/boot/dts/samsung-ssdk-gh7.dts | 26 +++++++ 2 files changed, 134 insertions(+) create mode 100644 arch/arm64/boot/dts/samsung-gh7.dtsi create mode 100644 arch/arm64/boot/dts/samsung-ssdk-gh7.dts diff --git a/arch/arm64/boot/dts/samsung-gh7.dtsi b/arch/arm64/boot/dts/samsung-gh7.dtsi new file mode 100644 index 0000000..5b8785c --- /dev/null +++ b/arch/arm64/boot/dts/samsung-gh7.dtsi @@ -0,0 +1,108 @@ +/* + * SAMSUNG GH7 SoC device tree source + * + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +/dts-v1/; + +/memreserve/ 0x80000000 0x0C400000; + +/ { + model = "SAMSUNG GH7"; + compatible = "samsung,gh7"; + interrupt-parent = <&gic>; + #address-cells = <2>; + #size-cells = <2>; + + cpus { + #address-cells = <2>; + #size-cells = <0>; + + cpu at 000 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x0 0x000>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x8000fff8>; + }; + cpu at 001 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x0 0x001>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x8000fff8>; + }; + cpu at 002 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x0 0x002>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x8000fff8>; + }; + cpu at 003 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x0 0x003>; + enable-method = "spin-table"; + cpu-release-addr = <0x0 0x8000fff8>; + }; + }; + + gic: interrupt-controller at 1C000000 { + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; + #interrupt-cells = <3>; + #address-cells = <0>; + interrupt-controller; + reg = <0x0 0x1C001000 0 0x1000>, /* GIC Dist */ + <0x0 0x1C002000 0 0x1000>, /* GIC CPU */ + <0x0 0x1C004000 0 0x2000>, /* GIC VCPU Control */ + <0x0 0x1C006000 0 0x2000>; /* GIC VCPU */ + interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <1 13 0xff01>, /* Secure Phys IRQ */ + <1 14 0xff01>, /* Non-secure Phys IRQ */ + <1 11 0xff01>, /* Virt IRQ */ + <1 10 0xff01>; /* Hyp IRQ */ + clock-frequency = <100000000>; + }; + + pmu { + compatible = "arm,armv8-pmuv3"; + interrupts = <0 294 8>, + <0 295 8>, + <0 296 8>, + <0 297 8>, + <0 298 8>, + <0 299 8>, + <0 300 8>, + <0 301 8>; + }; + + amba { + compatible = "arm,amba-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + serial at 12c00000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x12c00000 0x10000>; + interrupts = <418>; + }; + + serial at 12c20000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x12c20000 0x10000>; + interrupts = <420>; + }; + }; +}; diff --git a/arch/arm64/boot/dts/samsung-ssdk-gh7.dts b/arch/arm64/boot/dts/samsung-ssdk-gh7.dts new file mode 100644 index 0000000..47afbc4 --- /dev/null +++ b/arch/arm64/boot/dts/samsung-ssdk-gh7.dts @@ -0,0 +1,26 @@ +/* + * SAMSUNG SSDK-GH7 board device tree source + * + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +/dts-v1/; +#include "samsung-gh7.dtsi" + +/ { + model = "SAMSUNG SSDK-GH7 board based on GH7 SoC"; + compatible = "samsung,ssdk-gh7", "samsung,gh7"; + + chosen { + }; + + memory at 80000000 { + device_type = "memory"; + reg = <0x00000000 0x80000000 0 0x80000000>; + }; +}; -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 82+ messages in thread
* Re: [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board 2014-02-11 6:29 ` Kukjin Kim @ 2014-02-11 18:15 ` Mark Rutland -1 siblings, 0 replies; 82+ messages in thread From: Mark Rutland @ 2014-02-11 18:15 UTC (permalink / raw) To: Kukjin Kim Cc: linux-arm-kernel, linux-samsung-soc, Thomas Abraham, Ilho Lee, Catalin Marinas On Tue, Feb 11, 2014 at 06:29:41AM +0000, Kukjin Kim wrote: > Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> > Reviewed-by: Thomas Abraham <thomas.ab@samsung.com> > Cc: Catalin Marinas <catalin.marinas@arm.com> > --- > arch/arm64/boot/dts/samsung-gh7.dtsi | 108 ++++++++++++++++++++++++++++++ > arch/arm64/boot/dts/samsung-ssdk-gh7.dts | 26 +++++++ > 2 files changed, 134 insertions(+) > create mode 100644 arch/arm64/boot/dts/samsung-gh7.dtsi > create mode 100644 arch/arm64/boot/dts/samsung-ssdk-gh7.dts > > diff --git a/arch/arm64/boot/dts/samsung-gh7.dtsi b/arch/arm64/boot/dts/samsung-gh7.dtsi > new file mode 100644 > index 0000000..5b8785c > --- /dev/null > +++ b/arch/arm64/boot/dts/samsung-gh7.dtsi > @@ -0,0 +1,108 @@ > +/* > + * SAMSUNG GH7 SoC device tree source > + * > + * Copyright (c) 2014 Samsung Electronics Co., Ltd. > + * http://www.samsung.com > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > +*/ > + > +/dts-v1/; > + > +/memreserve/ 0x80000000 0x0C400000; That looks _very_ large. What is this for? [...] > + timer { > + compatible = "arm,armv8-timer"; > + interrupts = <1 13 0xff01>, /* Secure Phys IRQ */ > + <1 14 0xff01>, /* Non-secure Phys IRQ */ > + <1 11 0xff01>, /* Virt IRQ */ > + <1 10 0xff01>; /* Hyp IRQ */ > + clock-frequency = <100000000>; Please, get your bootloader to set CNTFREQ. The clock frequency property for the timer node is a horrible hack for buggy firmware. [...] > + amba { > + compatible = "arm,amba-bus"; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + > + serial@12c00000 { > + compatible = "arm,pl011", "arm,primecell"; > + reg = <0x12c00000 0x10000>; > + interrupts = <418>; > + }; > + > + serial@12c20000 { > + compatible = "arm,pl011", "arm,primecell"; > + reg = <0x12c20000 0x10000>; > + interrupts = <420>; > + }; Don't these need clocks? [...] > + memory@80000000 { > + device_type = "memory"; > + reg = <0x00000000 0x80000000 0 0x80000000>; Minor nit, but it would be nice for the 0 values to be consistently padded. Thanks, Mark. ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board @ 2014-02-11 18:15 ` Mark Rutland 0 siblings, 0 replies; 82+ messages in thread From: Mark Rutland @ 2014-02-11 18:15 UTC (permalink / raw) To: linux-arm-kernel On Tue, Feb 11, 2014 at 06:29:41AM +0000, Kukjin Kim wrote: > Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> > Reviewed-by: Thomas Abraham <thomas.ab@samsung.com> > Cc: Catalin Marinas <catalin.marinas@arm.com> > --- > arch/arm64/boot/dts/samsung-gh7.dtsi | 108 ++++++++++++++++++++++++++++++ > arch/arm64/boot/dts/samsung-ssdk-gh7.dts | 26 +++++++ > 2 files changed, 134 insertions(+) > create mode 100644 arch/arm64/boot/dts/samsung-gh7.dtsi > create mode 100644 arch/arm64/boot/dts/samsung-ssdk-gh7.dts > > diff --git a/arch/arm64/boot/dts/samsung-gh7.dtsi b/arch/arm64/boot/dts/samsung-gh7.dtsi > new file mode 100644 > index 0000000..5b8785c > --- /dev/null > +++ b/arch/arm64/boot/dts/samsung-gh7.dtsi > @@ -0,0 +1,108 @@ > +/* > + * SAMSUNG GH7 SoC device tree source > + * > + * Copyright (c) 2014 Samsung Electronics Co., Ltd. > + * http://www.samsung.com > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > +*/ > + > +/dts-v1/; > + > +/memreserve/ 0x80000000 0x0C400000; That looks _very_ large. What is this for? [...] > + timer { > + compatible = "arm,armv8-timer"; > + interrupts = <1 13 0xff01>, /* Secure Phys IRQ */ > + <1 14 0xff01>, /* Non-secure Phys IRQ */ > + <1 11 0xff01>, /* Virt IRQ */ > + <1 10 0xff01>; /* Hyp IRQ */ > + clock-frequency = <100000000>; Please, get your bootloader to set CNTFREQ. The clock frequency property for the timer node is a horrible hack for buggy firmware. [...] > + amba { > + compatible = "arm,amba-bus"; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + > + serial at 12c00000 { > + compatible = "arm,pl011", "arm,primecell"; > + reg = <0x12c00000 0x10000>; > + interrupts = <418>; > + }; > + > + serial at 12c20000 { > + compatible = "arm,pl011", "arm,primecell"; > + reg = <0x12c20000 0x10000>; > + interrupts = <420>; > + }; Don't these need clocks? [...] > + memory at 80000000 { > + device_type = "memory"; > + reg = <0x00000000 0x80000000 0 0x80000000>; Minor nit, but it would be nice for the 0 values to be consistently padded. Thanks, Mark. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board 2014-02-11 18:15 ` Mark Rutland @ 2014-02-11 3:16 ` Kukjin Kim -1 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-11 3:16 UTC (permalink / raw) To: Mark Rutland Cc: Kukjin Kim, Ilho Lee, linux-samsung-soc, Thomas Abraham, linux-arm-kernel, Catalin Marinas On 02/12/14 03:15, Mark Rutland wrote: > On Tue, Feb 11, 2014 at 06:29:41AM +0000, Kukjin Kim wrote: >> Signed-off-by: Kukjin Kim<kgene.kim@samsung.com> >> Reviewed-by: Thomas Abraham<thomas.ab@samsung.com> >> Cc: Catalin Marinas<catalin.marinas@arm.com> >> --- >> arch/arm64/boot/dts/samsung-gh7.dtsi | 108 ++++++++++++++++++++++++++++++ >> arch/arm64/boot/dts/samsung-ssdk-gh7.dts | 26 +++++++ >> 2 files changed, 134 insertions(+) >> create mode 100644 arch/arm64/boot/dts/samsung-gh7.dtsi >> create mode 100644 arch/arm64/boot/dts/samsung-ssdk-gh7.dts >> >> diff --git a/arch/arm64/boot/dts/samsung-gh7.dtsi b/arch/arm64/boot/dts/samsung-gh7.dtsi >> new file mode 100644 >> index 0000000..5b8785c >> --- /dev/null >> +++ b/arch/arm64/boot/dts/samsung-gh7.dtsi >> @@ -0,0 +1,108 @@ >> +/* >> + * SAMSUNG GH7 SoC device tree source >> + * >> + * Copyright (c) 2014 Samsung Electronics Co., Ltd. >> + * http://www.samsung.com >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. >> +*/ >> + >> +/dts-v1/; >> + >> +/memreserve/ 0x80000000 0x0C400000; > > That looks _very_ large. What is this for? > Yes, I know but we need to reserve that for EL3 monitor, UEFI services, secure, hypervisor and scan chanin... > [...] > >> + timer { >> + compatible = "arm,armv8-timer"; >> + interrupts =<1 13 0xff01>, /* Secure Phys IRQ */ >> + <1 14 0xff01>, /* Non-secure Phys IRQ */ >> + <1 11 0xff01>, /* Virt IRQ */ >> + <1 10 0xff01>; /* Hyp IRQ */ >> + clock-frequency =<100000000>; > > Please, get your bootloader to set CNTFREQ. The clock frequency property > for the timer node is a horrible hack for buggy firmware. > You're right. OK. > [...] > >> + amba { >> + compatible = "arm,amba-bus"; >> + #address-cells =<1>; >> + #size-cells =<1>; >> + ranges; >> + >> + serial@12c00000 { >> + compatible = "arm,pl011", "arm,primecell"; >> + reg =<0x12c00000 0x10000>; >> + interrupts =<418>; >> + }; >> + >> + serial@12c20000 { >> + compatible = "arm,pl011", "arm,primecell"; >> + reg =<0x12c20000 0x10000>; >> + interrupts =<420>; >> + }; > > Don't these need clocks? > We don't need and the clocks will be handled by bootloader... > [...] > >> + memory@80000000 { >> + device_type = "memory"; >> + reg =<0x00000000 0x80000000 0 0x80000000>; > > Minor nit, but it would be nice for the 0 values to be consistently padded. > OK. Thanks, Kukjin ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board @ 2014-02-11 3:16 ` Kukjin Kim 0 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-11 3:16 UTC (permalink / raw) To: linux-arm-kernel On 02/12/14 03:15, Mark Rutland wrote: > On Tue, Feb 11, 2014 at 06:29:41AM +0000, Kukjin Kim wrote: >> Signed-off-by: Kukjin Kim<kgene.kim@samsung.com> >> Reviewed-by: Thomas Abraham<thomas.ab@samsung.com> >> Cc: Catalin Marinas<catalin.marinas@arm.com> >> --- >> arch/arm64/boot/dts/samsung-gh7.dtsi | 108 ++++++++++++++++++++++++++++++ >> arch/arm64/boot/dts/samsung-ssdk-gh7.dts | 26 +++++++ >> 2 files changed, 134 insertions(+) >> create mode 100644 arch/arm64/boot/dts/samsung-gh7.dtsi >> create mode 100644 arch/arm64/boot/dts/samsung-ssdk-gh7.dts >> >> diff --git a/arch/arm64/boot/dts/samsung-gh7.dtsi b/arch/arm64/boot/dts/samsung-gh7.dtsi >> new file mode 100644 >> index 0000000..5b8785c >> --- /dev/null >> +++ b/arch/arm64/boot/dts/samsung-gh7.dtsi >> @@ -0,0 +1,108 @@ >> +/* >> + * SAMSUNG GH7 SoC device tree source >> + * >> + * Copyright (c) 2014 Samsung Electronics Co., Ltd. >> + * http://www.samsung.com >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. >> +*/ >> + >> +/dts-v1/; >> + >> +/memreserve/ 0x80000000 0x0C400000; > > That looks _very_ large. What is this for? > Yes, I know but we need to reserve that for EL3 monitor, UEFI services, secure, hypervisor and scan chanin... > [...] > >> + timer { >> + compatible = "arm,armv8-timer"; >> + interrupts =<1 13 0xff01>, /* Secure Phys IRQ */ >> + <1 14 0xff01>, /* Non-secure Phys IRQ */ >> + <1 11 0xff01>, /* Virt IRQ */ >> + <1 10 0xff01>; /* Hyp IRQ */ >> + clock-frequency =<100000000>; > > Please, get your bootloader to set CNTFREQ. The clock frequency property > for the timer node is a horrible hack for buggy firmware. > You're right. OK. > [...] > >> + amba { >> + compatible = "arm,amba-bus"; >> + #address-cells =<1>; >> + #size-cells =<1>; >> + ranges; >> + >> + serial at 12c00000 { >> + compatible = "arm,pl011", "arm,primecell"; >> + reg =<0x12c00000 0x10000>; >> + interrupts =<418>; >> + }; >> + >> + serial at 12c20000 { >> + compatible = "arm,pl011", "arm,primecell"; >> + reg =<0x12c20000 0x10000>; >> + interrupts =<420>; >> + }; > > Don't these need clocks? > We don't need and the clocks will be handled by bootloader... > [...] > >> + memory at 80000000 { >> + device_type = "memory"; >> + reg =<0x00000000 0x80000000 0 0x80000000>; > > Minor nit, but it would be nice for the 0 values to be consistently padded. > OK. Thanks, Kukjin ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board 2014-02-11 3:16 ` Kukjin Kim @ 2014-02-18 10:30 ` Mark Rutland -1 siblings, 0 replies; 82+ messages in thread From: Mark Rutland @ 2014-02-18 10:30 UTC (permalink / raw) To: Kukjin Kim Cc: Ilho Lee, linux-samsung-soc, Thomas Abraham, linux-arm-kernel, Catalin Marinas On Tue, Feb 11, 2014 at 03:16:26AM +0000, Kukjin Kim wrote: > On 02/12/14 03:15, Mark Rutland wrote: > > On Tue, Feb 11, 2014 at 06:29:41AM +0000, Kukjin Kim wrote: > >> Signed-off-by: Kukjin Kim<kgene.kim@samsung.com> > >> Reviewed-by: Thomas Abraham<thomas.ab@samsung.com> > >> Cc: Catalin Marinas<catalin.marinas@arm.com> > >> --- > >> arch/arm64/boot/dts/samsung-gh7.dtsi | 108 ++++++++++++++++++++++++++++++ > >> arch/arm64/boot/dts/samsung-ssdk-gh7.dts | 26 +++++++ > >> 2 files changed, 134 insertions(+) > >> create mode 100644 arch/arm64/boot/dts/samsung-gh7.dtsi > >> create mode 100644 arch/arm64/boot/dts/samsung-ssdk-gh7.dts > >> > >> diff --git a/arch/arm64/boot/dts/samsung-gh7.dtsi b/arch/arm64/boot/dts/samsung-gh7.dtsi > >> new file mode 100644 > >> index 0000000..5b8785c > >> --- /dev/null > >> +++ b/arch/arm64/boot/dts/samsung-gh7.dtsi > >> @@ -0,0 +1,108 @@ > >> +/* > >> + * SAMSUNG GH7 SoC device tree source > >> + * > >> + * Copyright (c) 2014 Samsung Electronics Co., Ltd. > >> + * http://www.samsung.com > >> + * > >> + * This program is free software; you can redistribute it and/or modify > >> + * it under the terms of the GNU General Public License version 2 as > >> + * published by the Free Software Foundation. > >> +*/ > >> + > >> +/dts-v1/; > >> + > >> +/memreserve/ 0x80000000 0x0C400000; > > > > That looks _very_ large. What is this for? > > > Yes, I know but we need to reserve that for EL3 monitor, UEFI services, > secure, hypervisor and scan chanin... OK. How much of that memory does the kernel need to know about then? Surely the kernel shouldn't be able to map the EL3 monitor or hypervisor at all? What address is the kernel getting loaded at if everything up to 0x8C400000 isn't usable? [...] > > > [...] > > > >> + amba { > >> + compatible = "arm,amba-bus"; > >> + #address-cells =<1>; > >> + #size-cells =<1>; > >> + ranges; > >> + > >> + serial@12c00000 { > >> + compatible = "arm,pl011", "arm,primecell"; > >> + reg =<0x12c00000 0x10000>; > >> + interrupts =<418>; > >> + }; > >> + > >> + serial@12c20000 { > >> + compatible = "arm,pl011", "arm,primecell"; > >> + reg =<0x12c20000 0x10000>; > >> + interrupts =<420>; > >> + }; > > > > Don't these need clocks? > > > We don't need and the clocks will be handled by bootloader... While that might be sufficient for the device to function, Linux doesn't know that from this DT, and as far as I can see the device can't possibly probe, as no clocks are provided through platform data: of_platform_bus_create will call of_amba_device_create for anyting compatible with "arm,primecell". This in turn will call amba_device_add, which will call amba_get_enable_pclk. Then clk_get(&pcdev->dev, "apb_pclk") should fail, amba_device_add should fail, and of_platform_bus_create will stop trying to probe the node. of_platform_populate will carry on probing other nodes. Surely the pl011 nodes at least need "apb_pclk"? Cheers, Mark. ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board @ 2014-02-18 10:30 ` Mark Rutland 0 siblings, 0 replies; 82+ messages in thread From: Mark Rutland @ 2014-02-18 10:30 UTC (permalink / raw) To: linux-arm-kernel On Tue, Feb 11, 2014 at 03:16:26AM +0000, Kukjin Kim wrote: > On 02/12/14 03:15, Mark Rutland wrote: > > On Tue, Feb 11, 2014 at 06:29:41AM +0000, Kukjin Kim wrote: > >> Signed-off-by: Kukjin Kim<kgene.kim@samsung.com> > >> Reviewed-by: Thomas Abraham<thomas.ab@samsung.com> > >> Cc: Catalin Marinas<catalin.marinas@arm.com> > >> --- > >> arch/arm64/boot/dts/samsung-gh7.dtsi | 108 ++++++++++++++++++++++++++++++ > >> arch/arm64/boot/dts/samsung-ssdk-gh7.dts | 26 +++++++ > >> 2 files changed, 134 insertions(+) > >> create mode 100644 arch/arm64/boot/dts/samsung-gh7.dtsi > >> create mode 100644 arch/arm64/boot/dts/samsung-ssdk-gh7.dts > >> > >> diff --git a/arch/arm64/boot/dts/samsung-gh7.dtsi b/arch/arm64/boot/dts/samsung-gh7.dtsi > >> new file mode 100644 > >> index 0000000..5b8785c > >> --- /dev/null > >> +++ b/arch/arm64/boot/dts/samsung-gh7.dtsi > >> @@ -0,0 +1,108 @@ > >> +/* > >> + * SAMSUNG GH7 SoC device tree source > >> + * > >> + * Copyright (c) 2014 Samsung Electronics Co., Ltd. > >> + * http://www.samsung.com > >> + * > >> + * This program is free software; you can redistribute it and/or modify > >> + * it under the terms of the GNU General Public License version 2 as > >> + * published by the Free Software Foundation. > >> +*/ > >> + > >> +/dts-v1/; > >> + > >> +/memreserve/ 0x80000000 0x0C400000; > > > > That looks _very_ large. What is this for? > > > Yes, I know but we need to reserve that for EL3 monitor, UEFI services, > secure, hypervisor and scan chanin... OK. How much of that memory does the kernel need to know about then? Surely the kernel shouldn't be able to map the EL3 monitor or hypervisor at all? What address is the kernel getting loaded at if everything up to 0x8C400000 isn't usable? [...] > > > [...] > > > >> + amba { > >> + compatible = "arm,amba-bus"; > >> + #address-cells =<1>; > >> + #size-cells =<1>; > >> + ranges; > >> + > >> + serial at 12c00000 { > >> + compatible = "arm,pl011", "arm,primecell"; > >> + reg =<0x12c00000 0x10000>; > >> + interrupts =<418>; > >> + }; > >> + > >> + serial at 12c20000 { > >> + compatible = "arm,pl011", "arm,primecell"; > >> + reg =<0x12c20000 0x10000>; > >> + interrupts =<420>; > >> + }; > > > > Don't these need clocks? > > > We don't need and the clocks will be handled by bootloader... While that might be sufficient for the device to function, Linux doesn't know that from this DT, and as far as I can see the device can't possibly probe, as no clocks are provided through platform data: of_platform_bus_create will call of_amba_device_create for anyting compatible with "arm,primecell". This in turn will call amba_device_add, which will call amba_get_enable_pclk. Then clk_get(&pcdev->dev, "apb_pclk") should fail, amba_device_add should fail, and of_platform_bus_create will stop trying to probe the node. of_platform_populate will carry on probing other nodes. Surely the pl011 nodes at least need "apb_pclk"? Cheers, Mark. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board 2014-02-18 10:30 ` Mark Rutland @ 2014-02-24 23:56 ` Kukjin Kim -1 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-24 23:56 UTC (permalink / raw) To: Mark Rutland Cc: Kukjin Kim, linux-arm-kernel, Catalin Marinas, linux-samsung-soc, Thomas Abraham, Ilho Lee On 02/18/14 19:30, Mark Rutland wrote: > On Tue, Feb 11, 2014 at 03:16:26AM +0000, Kukjin Kim wrote: >> On 02/12/14 03:15, Mark Rutland wrote: >>> On Tue, Feb 11, 2014 at 06:29:41AM +0000, Kukjin Kim wrote: >>>> Signed-off-by: Kukjin Kim<kgene.kim@samsung.com> >>>> Reviewed-by: Thomas Abraham<thomas.ab@samsung.com> >>>> Cc: Catalin Marinas<catalin.marinas@arm.com> >>>> --- >>>> arch/arm64/boot/dts/samsung-gh7.dtsi | 108 ++++++++++++++++++++++++++++++ >>>> arch/arm64/boot/dts/samsung-ssdk-gh7.dts | 26 +++++++ >>>> 2 files changed, 134 insertions(+) >>>> create mode 100644 arch/arm64/boot/dts/samsung-gh7.dtsi >>>> create mode 100644 arch/arm64/boot/dts/samsung-ssdk-gh7.dts >>>> >>>> diff --git a/arch/arm64/boot/dts/samsung-gh7.dtsi b/arch/arm64/boot/dts/samsung-gh7.dtsi >>>> new file mode 100644 >>>> index 0000000..5b8785c >>>> --- /dev/null >>>> +++ b/arch/arm64/boot/dts/samsung-gh7.dtsi >>>> @@ -0,0 +1,108 @@ >>>> +/* >>>> + * SAMSUNG GH7 SoC device tree source >>>> + * >>>> + * Copyright (c) 2014 Samsung Electronics Co., Ltd. >>>> + * http://www.samsung.com >>>> + * >>>> + * This program is free software; you can redistribute it and/or modify >>>> + * it under the terms of the GNU General Public License version 2 as >>>> + * published by the Free Software Foundation. >>>> +*/ >>>> + >>>> +/dts-v1/; >>>> + >>>> +/memreserve/ 0x80000000 0x0C400000; >>> >>> That looks _very_ large. What is this for? >>> >> Yes, I know but we need to reserve that for EL3 monitor, UEFI services, >> secure, hypervisor and scan chanin... > > OK. How much of that memory does the kernel need to know about then? > > Surely the kernel shouldn't be able to map the EL3 monitor or hypervisor > at all? > > What address is the kernel getting loaded at if everything up to > 0x8C400000 isn't usable? > > [...] > >> >>> [...] >>> >>>> + amba { >>>> + compatible = "arm,amba-bus"; >>>> + #address-cells =<1>; >>>> + #size-cells =<1>; >>>> + ranges; >>>> + >>>> + serial@12c00000 { >>>> + compatible = "arm,pl011", "arm,primecell"; >>>> + reg =<0x12c00000 0x10000>; >>>> + interrupts =<418>; >>>> + }; >>>> + >>>> + serial@12c20000 { >>>> + compatible = "arm,pl011", "arm,primecell"; >>>> + reg =<0x12c20000 0x10000>; >>>> + interrupts =<420>; >>>> + }; >>> >>> Don't these need clocks? >>> >> We don't need and the clocks will be handled by bootloader... > > While that might be sufficient for the device to function, Linux doesn't > know that from this DT, and as far as I can see the device can't > possibly probe, as no clocks are provided through platform data: > > of_platform_bus_create will call of_amba_device_create for anyting > compatible with "arm,primecell". This in turn will call amba_device_add, > which will call amba_get_enable_pclk. Then clk_get(&pcdev->dev, > "apb_pclk") should fail, amba_device_add should fail, and > of_platform_bus_create will stop trying to probe the node. > of_platform_populate will carry on probing other nodes. > > Surely the pl011 nodes at least need "apb_pclk"? > You're right. We should make a dummy clock for pl011, proper clocks will be added in next version. Thanks, Kukjin ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board @ 2014-02-24 23:56 ` Kukjin Kim 0 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-24 23:56 UTC (permalink / raw) To: linux-arm-kernel On 02/18/14 19:30, Mark Rutland wrote: > On Tue, Feb 11, 2014 at 03:16:26AM +0000, Kukjin Kim wrote: >> On 02/12/14 03:15, Mark Rutland wrote: >>> On Tue, Feb 11, 2014 at 06:29:41AM +0000, Kukjin Kim wrote: >>>> Signed-off-by: Kukjin Kim<kgene.kim@samsung.com> >>>> Reviewed-by: Thomas Abraham<thomas.ab@samsung.com> >>>> Cc: Catalin Marinas<catalin.marinas@arm.com> >>>> --- >>>> arch/arm64/boot/dts/samsung-gh7.dtsi | 108 ++++++++++++++++++++++++++++++ >>>> arch/arm64/boot/dts/samsung-ssdk-gh7.dts | 26 +++++++ >>>> 2 files changed, 134 insertions(+) >>>> create mode 100644 arch/arm64/boot/dts/samsung-gh7.dtsi >>>> create mode 100644 arch/arm64/boot/dts/samsung-ssdk-gh7.dts >>>> >>>> diff --git a/arch/arm64/boot/dts/samsung-gh7.dtsi b/arch/arm64/boot/dts/samsung-gh7.dtsi >>>> new file mode 100644 >>>> index 0000000..5b8785c >>>> --- /dev/null >>>> +++ b/arch/arm64/boot/dts/samsung-gh7.dtsi >>>> @@ -0,0 +1,108 @@ >>>> +/* >>>> + * SAMSUNG GH7 SoC device tree source >>>> + * >>>> + * Copyright (c) 2014 Samsung Electronics Co., Ltd. >>>> + * http://www.samsung.com >>>> + * >>>> + * This program is free software; you can redistribute it and/or modify >>>> + * it under the terms of the GNU General Public License version 2 as >>>> + * published by the Free Software Foundation. >>>> +*/ >>>> + >>>> +/dts-v1/; >>>> + >>>> +/memreserve/ 0x80000000 0x0C400000; >>> >>> That looks _very_ large. What is this for? >>> >> Yes, I know but we need to reserve that for EL3 monitor, UEFI services, >> secure, hypervisor and scan chanin... > > OK. How much of that memory does the kernel need to know about then? > > Surely the kernel shouldn't be able to map the EL3 monitor or hypervisor > at all? > > What address is the kernel getting loaded at if everything up to > 0x8C400000 isn't usable? > > [...] > >> >>> [...] >>> >>>> + amba { >>>> + compatible = "arm,amba-bus"; >>>> + #address-cells =<1>; >>>> + #size-cells =<1>; >>>> + ranges; >>>> + >>>> + serial at 12c00000 { >>>> + compatible = "arm,pl011", "arm,primecell"; >>>> + reg =<0x12c00000 0x10000>; >>>> + interrupts =<418>; >>>> + }; >>>> + >>>> + serial at 12c20000 { >>>> + compatible = "arm,pl011", "arm,primecell"; >>>> + reg =<0x12c20000 0x10000>; >>>> + interrupts =<420>; >>>> + }; >>> >>> Don't these need clocks? >>> >> We don't need and the clocks will be handled by bootloader... > > While that might be sufficient for the device to function, Linux doesn't > know that from this DT, and as far as I can see the device can't > possibly probe, as no clocks are provided through platform data: > > of_platform_bus_create will call of_amba_device_create for anyting > compatible with "arm,primecell". This in turn will call amba_device_add, > which will call amba_get_enable_pclk. Then clk_get(&pcdev->dev, > "apb_pclk") should fail, amba_device_add should fail, and > of_platform_bus_create will stop trying to probe the node. > of_platform_populate will carry on probing other nodes. > > Surely the pl011 nodes at least need "apb_pclk"? > You're right. We should make a dummy clock for pl011, proper clocks will be added in next version. Thanks, Kukjin ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board 2014-02-11 6:29 ` Kukjin Kim @ 2014-02-11 23:36 ` Olof Johansson -1 siblings, 0 replies; 82+ messages in thread From: Olof Johansson @ 2014-02-11 23:36 UTC (permalink / raw) To: Kukjin Kim Cc: linux-arm-kernel, linux-samsung-soc, Ilho Lee, Thomas Abraham, Catalin Marinas, Marc Zyngier Hi, Besides what Mark Rutland already commented on: On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > +/ { > + model = "SAMSUNG GH7"; > + compatible = "samsung,gh7"; Model and compatible in the dtsi should probably always be overridden by a dts that includes it, so there's little use in having it here. > + interrupt-parent = <&gic>; > + #address-cells = <2>; > + #size-cells = <2>; > + > + cpus { > + #address-cells = <2>; > + #size-cells = <0>; > + > + cpu@000 { > + device_type = "cpu"; > + compatible = "arm,armv8"; > + reg = <0x0 0x000>; No need to zero-pad cpu numbers in unit address or reg. > + enable-method = "spin-table"; > + cpu-release-addr = <0x0 0x8000fff8>; > + }; > + cpu@001 { > + device_type = "cpu"; > + compatible = "arm,armv8"; > + reg = <0x0 0x001>; > + enable-method = "spin-table"; > + cpu-release-addr = <0x0 0x8000fff8>; > + }; > + cpu@002 { > + device_type = "cpu"; > + compatible = "arm,armv8"; > + reg = <0x0 0x002>; > + enable-method = "spin-table"; > + cpu-release-addr = <0x0 0x8000fff8>; > + }; > + cpu@003 { > + device_type = "cpu"; > + compatible = "arm,armv8"; > + reg = <0x0 0x003>; > + enable-method = "spin-table"; > + cpu-release-addr = <0x0 0x8000fff8>; > + }; > + }; > + > + gic: interrupt-controller@1C000000 { > + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; This looks incorrect -- you should at the very least have a more specific one than a15-gic? Marc? > + #interrupt-cells = <3>; > + #address-cells = <0>; > + interrupt-controller; > + reg = <0x0 0x1C001000 0 0x1000>, /* GIC Dist */ > + <0x0 0x1C002000 0 0x1000>, /* GIC CPU */ > + <0x0 0x1C004000 0 0x2000>, /* GIC VCPU Control */ > + <0x0 0x1C006000 0 0x2000>; /* GIC VCPU */ > + interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ > + }; > + > + timer { > + compatible = "arm,armv8-timer"; > + interrupts = <1 13 0xff01>, /* Secure Phys IRQ */ > + <1 14 0xff01>, /* Non-secure Phys IRQ */ > + <1 11 0xff01>, /* Virt IRQ */ > + <1 10 0xff01>; /* Hyp IRQ */ > + clock-frequency = <100000000>; > + }; > + > + pmu { > + compatible = "arm,armv8-pmuv3"; > + interrupts = <0 294 8>, > + <0 295 8>, > + <0 296 8>, > + <0 297 8>, > + <0 298 8>, > + <0 299 8>, > + <0 300 8>, > + <0 301 8>; > + }; > + > + amba { > + compatible = "arm,amba-bus"; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + > + serial@12c00000 { > + compatible = "arm,pl011", "arm,primecell"; > + reg = <0x12c00000 0x10000>; > + interrupts = <418>; > + }; > + > + serial@12c20000 { > + compatible = "arm,pl011", "arm,primecell"; > + reg = <0x12c20000 0x10000>; > + interrupts = <420>; > + }; > + }; > +}; > diff --git a/arch/arm64/boot/dts/samsung-ssdk-gh7.dts b/arch/arm64/boot/dts/samsung-ssdk-gh7.dts > new file mode 100644 > index 0000000..47afbc4 > --- /dev/null > +++ b/arch/arm64/boot/dts/samsung-ssdk-gh7.dts > @@ -0,0 +1,26 @@ > +/* > + * SAMSUNG SSDK-GH7 board device tree source > + * > + * Copyright (c) 2014 Samsung Electronics Co., Ltd. > + * http://www.samsung.com > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > +*/ > + > +/dts-v1/; > +#include "samsung-gh7.dtsi" > + > +/ { > + model = "SAMSUNG SSDK-GH7 board based on GH7 SoC"; > + compatible = "samsung,ssdk-gh7", "samsung,gh7"; > + > + chosen { > + }; > + > + memory@80000000 { > + device_type = "memory"; > + reg = <0x00000000 0x80000000 0 0x80000000>; > + }; > +}; > -- > 1.7.10.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board @ 2014-02-11 23:36 ` Olof Johansson 0 siblings, 0 replies; 82+ messages in thread From: Olof Johansson @ 2014-02-11 23:36 UTC (permalink / raw) To: linux-arm-kernel Hi, Besides what Mark Rutland already commented on: On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > +/ { > + model = "SAMSUNG GH7"; > + compatible = "samsung,gh7"; Model and compatible in the dtsi should probably always be overridden by a dts that includes it, so there's little use in having it here. > + interrupt-parent = <&gic>; > + #address-cells = <2>; > + #size-cells = <2>; > + > + cpus { > + #address-cells = <2>; > + #size-cells = <0>; > + > + cpu at 000 { > + device_type = "cpu"; > + compatible = "arm,armv8"; > + reg = <0x0 0x000>; No need to zero-pad cpu numbers in unit address or reg. > + enable-method = "spin-table"; > + cpu-release-addr = <0x0 0x8000fff8>; > + }; > + cpu at 001 { > + device_type = "cpu"; > + compatible = "arm,armv8"; > + reg = <0x0 0x001>; > + enable-method = "spin-table"; > + cpu-release-addr = <0x0 0x8000fff8>; > + }; > + cpu at 002 { > + device_type = "cpu"; > + compatible = "arm,armv8"; > + reg = <0x0 0x002>; > + enable-method = "spin-table"; > + cpu-release-addr = <0x0 0x8000fff8>; > + }; > + cpu at 003 { > + device_type = "cpu"; > + compatible = "arm,armv8"; > + reg = <0x0 0x003>; > + enable-method = "spin-table"; > + cpu-release-addr = <0x0 0x8000fff8>; > + }; > + }; > + > + gic: interrupt-controller at 1C000000 { > + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; This looks incorrect -- you should at the very least have a more specific one than a15-gic? Marc? > + #interrupt-cells = <3>; > + #address-cells = <0>; > + interrupt-controller; > + reg = <0x0 0x1C001000 0 0x1000>, /* GIC Dist */ > + <0x0 0x1C002000 0 0x1000>, /* GIC CPU */ > + <0x0 0x1C004000 0 0x2000>, /* GIC VCPU Control */ > + <0x0 0x1C006000 0 0x2000>; /* GIC VCPU */ > + interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ > + }; > + > + timer { > + compatible = "arm,armv8-timer"; > + interrupts = <1 13 0xff01>, /* Secure Phys IRQ */ > + <1 14 0xff01>, /* Non-secure Phys IRQ */ > + <1 11 0xff01>, /* Virt IRQ */ > + <1 10 0xff01>; /* Hyp IRQ */ > + clock-frequency = <100000000>; > + }; > + > + pmu { > + compatible = "arm,armv8-pmuv3"; > + interrupts = <0 294 8>, > + <0 295 8>, > + <0 296 8>, > + <0 297 8>, > + <0 298 8>, > + <0 299 8>, > + <0 300 8>, > + <0 301 8>; > + }; > + > + amba { > + compatible = "arm,amba-bus"; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + > + serial at 12c00000 { > + compatible = "arm,pl011", "arm,primecell"; > + reg = <0x12c00000 0x10000>; > + interrupts = <418>; > + }; > + > + serial at 12c20000 { > + compatible = "arm,pl011", "arm,primecell"; > + reg = <0x12c20000 0x10000>; > + interrupts = <420>; > + }; > + }; > +}; > diff --git a/arch/arm64/boot/dts/samsung-ssdk-gh7.dts b/arch/arm64/boot/dts/samsung-ssdk-gh7.dts > new file mode 100644 > index 0000000..47afbc4 > --- /dev/null > +++ b/arch/arm64/boot/dts/samsung-ssdk-gh7.dts > @@ -0,0 +1,26 @@ > +/* > + * SAMSUNG SSDK-GH7 board device tree source > + * > + * Copyright (c) 2014 Samsung Electronics Co., Ltd. > + * http://www.samsung.com > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > +*/ > + > +/dts-v1/; > +#include "samsung-gh7.dtsi" > + > +/ { > + model = "SAMSUNG SSDK-GH7 board based on GH7 SoC"; > + compatible = "samsung,ssdk-gh7", "samsung,gh7"; > + > + chosen { > + }; > + > + memory at 80000000 { > + device_type = "memory"; > + reg = <0x00000000 0x80000000 0 0x80000000>; > + }; > +}; > -- > 1.7.10.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board 2014-02-11 23:36 ` Olof Johansson @ 2014-02-11 3:25 ` Kukjin Kim -1 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-11 3:25 UTC (permalink / raw) To: Olof Johansson Cc: Kukjin Kim, linux-samsung-soc, Marc Zyngier, Catalin Marinas, Ilho Lee, Thomas Abraham, linux-arm-kernel On 02/12/14 08:36, Olof Johansson wrote: > Hi, > Hi Olof, > Besides what Mark Rutland already commented on: > OK, thanks :-) > On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim<kgene.kim@samsung.com> wrote: >> +/ { >> + model = "SAMSUNG GH7"; >> + compatible = "samsung,gh7"; > > Model and compatible in the dtsi should probably always be overridden > by a dts that includes it, so there's little use in having it here. > OK, makes sense. >> + interrupt-parent =<&gic>; >> + #address-cells =<2>; >> + #size-cells =<2>; >> + >> + cpus { >> + #address-cells =<2>; >> + #size-cells =<0>; >> + >> + cpu@000 { >> + device_type = "cpu"; >> + compatible = "arm,armv8"; >> + reg =<0x0 0x000>; > > No need to zero-pad cpu numbers in unit address or reg. > Yes it's correct without any consideration, but I'm going to add more cpus next time and they should be separated from this. So I used. >> + enable-method = "spin-table"; >> + cpu-release-addr =<0x0 0x8000fff8>; >> + }; >> + cpu@001 { >> + device_type = "cpu"; >> + compatible = "arm,armv8"; >> + reg =<0x0 0x001>; >> + enable-method = "spin-table"; >> + cpu-release-addr =<0x0 0x8000fff8>; >> + }; >> + cpu@002 { >> + device_type = "cpu"; >> + compatible = "arm,armv8"; >> + reg =<0x0 0x002>; >> + enable-method = "spin-table"; >> + cpu-release-addr =<0x0 0x8000fff8>; >> + }; >> + cpu@003 { >> + device_type = "cpu"; >> + compatible = "arm,armv8"; >> + reg =<0x0 0x003>; >> + enable-method = "spin-table"; >> + cpu-release-addr =<0x0 0x8000fff8>; >> + }; >> + }; >> + >> + gic: interrupt-controller@1C000000 { >> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; > > This looks incorrect -- you should at the very least have a more > specific one than a15-gic? Marc? > OK, you're right. And I replied on other e-mail. Thanks, Kukjin ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board @ 2014-02-11 3:25 ` Kukjin Kim 0 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-11 3:25 UTC (permalink / raw) To: linux-arm-kernel On 02/12/14 08:36, Olof Johansson wrote: > Hi, > Hi Olof, > Besides what Mark Rutland already commented on: > OK, thanks :-) > On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim<kgene.kim@samsung.com> wrote: >> +/ { >> + model = "SAMSUNG GH7"; >> + compatible = "samsung,gh7"; > > Model and compatible in the dtsi should probably always be overridden > by a dts that includes it, so there's little use in having it here. > OK, makes sense. >> + interrupt-parent =<&gic>; >> + #address-cells =<2>; >> + #size-cells =<2>; >> + >> + cpus { >> + #address-cells =<2>; >> + #size-cells =<0>; >> + >> + cpu at 000 { >> + device_type = "cpu"; >> + compatible = "arm,armv8"; >> + reg =<0x0 0x000>; > > No need to zero-pad cpu numbers in unit address or reg. > Yes it's correct without any consideration, but I'm going to add more cpus next time and they should be separated from this. So I used. >> + enable-method = "spin-table"; >> + cpu-release-addr =<0x0 0x8000fff8>; >> + }; >> + cpu at 001 { >> + device_type = "cpu"; >> + compatible = "arm,armv8"; >> + reg =<0x0 0x001>; >> + enable-method = "spin-table"; >> + cpu-release-addr =<0x0 0x8000fff8>; >> + }; >> + cpu at 002 { >> + device_type = "cpu"; >> + compatible = "arm,armv8"; >> + reg =<0x0 0x002>; >> + enable-method = "spin-table"; >> + cpu-release-addr =<0x0 0x8000fff8>; >> + }; >> + cpu at 003 { >> + device_type = "cpu"; >> + compatible = "arm,armv8"; >> + reg =<0x0 0x003>; >> + enable-method = "spin-table"; >> + cpu-release-addr =<0x0 0x8000fff8>; >> + }; >> + }; >> + >> + gic: interrupt-controller at 1C000000 { >> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; > > This looks incorrect -- you should at the very least have a more > specific one than a15-gic? Marc? > OK, you're right. And I replied on other e-mail. Thanks, Kukjin ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board 2014-02-11 23:36 ` Olof Johansson @ 2014-02-12 11:13 ` Marc Zyngier -1 siblings, 0 replies; 82+ messages in thread From: Marc Zyngier @ 2014-02-12 11:13 UTC (permalink / raw) To: Olof Johansson Cc: Kukjin Kim, linux-arm-kernel, linux-samsung-soc, Ilho Lee, Thomas Abraham, Catalin Marinas On 11/02/14 23:36, Olof Johansson wrote: > Hi, > > Besides what Mark Rutland already commented on: > > On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >> +/ { >> + model = "SAMSUNG GH7"; >> + compatible = "samsung,gh7"; > > Model and compatible in the dtsi should probably always be overridden > by a dts that includes it, so there's little use in having it here. > >> + interrupt-parent = <&gic>; >> + #address-cells = <2>; >> + #size-cells = <2>; >> + >> + cpus { >> + #address-cells = <2>; >> + #size-cells = <0>; >> + >> + cpu@000 { >> + device_type = "cpu"; >> + compatible = "arm,armv8"; >> + reg = <0x0 0x000>; > > No need to zero-pad cpu numbers in unit address or reg. > >> + enable-method = "spin-table"; >> + cpu-release-addr = <0x0 0x8000fff8>; >> + }; >> + cpu@001 { >> + device_type = "cpu"; >> + compatible = "arm,armv8"; >> + reg = <0x0 0x001>; >> + enable-method = "spin-table"; >> + cpu-release-addr = <0x0 0x8000fff8>; >> + }; >> + cpu@002 { >> + device_type = "cpu"; >> + compatible = "arm,armv8"; >> + reg = <0x0 0x002>; >> + enable-method = "spin-table"; >> + cpu-release-addr = <0x0 0x8000fff8>; >> + }; >> + cpu@003 { >> + device_type = "cpu"; >> + compatible = "arm,armv8"; >> + reg = <0x0 0x003>; >> + enable-method = "spin-table"; >> + cpu-release-addr = <0x0 0x8000fff8>; >> + }; >> + }; >> + >> + gic: interrupt-controller@1C000000 { >> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; > > This looks incorrect -- you should at the very least have a more > specific one than a15-gic? Marc? "arm,cortex-a9-gic" is definitely wrong (the A9 GIC doesn't have the virt extensions). This binding matches what the A15 GIC has, so "arm,cortex-a15-gic" is probably fine. Main issue here is that the GICv2 driver has no compatible string for anything else. Should we define something more generic (like "arm,gic-v2")? Or carry on adding more compatible strings? M. >> + #interrupt-cells = <3>; >> + #address-cells = <0>; >> + interrupt-controller; >> + reg = <0x0 0x1C001000 0 0x1000>, /* GIC Dist */ >> + <0x0 0x1C002000 0 0x1000>, /* GIC CPU */ >> + <0x0 0x1C004000 0 0x2000>, /* GIC VCPU Control */ >> + <0x0 0x1C006000 0 0x2000>; /* GIC VCPU */ >> + interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ >> + }; -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board @ 2014-02-12 11:13 ` Marc Zyngier 0 siblings, 0 replies; 82+ messages in thread From: Marc Zyngier @ 2014-02-12 11:13 UTC (permalink / raw) To: linux-arm-kernel On 11/02/14 23:36, Olof Johansson wrote: > Hi, > > Besides what Mark Rutland already commented on: > > On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >> +/ { >> + model = "SAMSUNG GH7"; >> + compatible = "samsung,gh7"; > > Model and compatible in the dtsi should probably always be overridden > by a dts that includes it, so there's little use in having it here. > >> + interrupt-parent = <&gic>; >> + #address-cells = <2>; >> + #size-cells = <2>; >> + >> + cpus { >> + #address-cells = <2>; >> + #size-cells = <0>; >> + >> + cpu at 000 { >> + device_type = "cpu"; >> + compatible = "arm,armv8"; >> + reg = <0x0 0x000>; > > No need to zero-pad cpu numbers in unit address or reg. > >> + enable-method = "spin-table"; >> + cpu-release-addr = <0x0 0x8000fff8>; >> + }; >> + cpu at 001 { >> + device_type = "cpu"; >> + compatible = "arm,armv8"; >> + reg = <0x0 0x001>; >> + enable-method = "spin-table"; >> + cpu-release-addr = <0x0 0x8000fff8>; >> + }; >> + cpu at 002 { >> + device_type = "cpu"; >> + compatible = "arm,armv8"; >> + reg = <0x0 0x002>; >> + enable-method = "spin-table"; >> + cpu-release-addr = <0x0 0x8000fff8>; >> + }; >> + cpu at 003 { >> + device_type = "cpu"; >> + compatible = "arm,armv8"; >> + reg = <0x0 0x003>; >> + enable-method = "spin-table"; >> + cpu-release-addr = <0x0 0x8000fff8>; >> + }; >> + }; >> + >> + gic: interrupt-controller at 1C000000 { >> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; > > This looks incorrect -- you should at the very least have a more > specific one than a15-gic? Marc? "arm,cortex-a9-gic" is definitely wrong (the A9 GIC doesn't have the virt extensions). This binding matches what the A15 GIC has, so "arm,cortex-a15-gic" is probably fine. Main issue here is that the GICv2 driver has no compatible string for anything else. Should we define something more generic (like "arm,gic-v2")? Or carry on adding more compatible strings? M. >> + #interrupt-cells = <3>; >> + #address-cells = <0>; >> + interrupt-controller; >> + reg = <0x0 0x1C001000 0 0x1000>, /* GIC Dist */ >> + <0x0 0x1C002000 0 0x1000>, /* GIC CPU */ >> + <0x0 0x1C004000 0 0x2000>, /* GIC VCPU Control */ >> + <0x0 0x1C006000 0 0x2000>; /* GIC VCPU */ >> + interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ >> + }; -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board 2014-02-12 11:13 ` Marc Zyngier @ 2014-02-12 11:29 ` Mark Rutland -1 siblings, 0 replies; 82+ messages in thread From: Mark Rutland @ 2014-02-12 11:29 UTC (permalink / raw) To: Marc Zyngier Cc: linux-samsung-soc, Catalin Marinas, Ilho Lee, Thomas Abraham, Olof Johansson, Kukjin Kim, linux-arm-kernel > >> + gic: interrupt-controller@1C000000 { > >> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; > > > > This looks incorrect -- you should at the very least have a more > > specific one than a15-gic? Marc? > > "arm,cortex-a9-gic" is definitely wrong (the A9 GIC doesn't have the > virt extensions). This binding matches what the A15 GIC has, so > "arm,cortex-a15-gic" is probably fine. Main issue here is that the GICv2 > driver has no compatible string for anything else. > > Should we define something more generic (like "arm,gic-v2")? Or carry on > adding more compatible strings? It's been proposed repeatedly, and it probably makes sense to add the generic versions to the driver, and allow for more specific ones in the binding which DTs can use. That way we don't get an explosion of strings in the driver, but if we need to handle any particular GIC specially in future we can do so. I guess for Linux we'd want to add "arm,gic-v1" and "arm,gic-v2" to the driver. We could just add "arm,gic-v1" and expect it later in the compatible list if v2 is a strict superset of v1; I think it is but I'm not a GIC expert. Thanks, Mark. ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board @ 2014-02-12 11:29 ` Mark Rutland 0 siblings, 0 replies; 82+ messages in thread From: Mark Rutland @ 2014-02-12 11:29 UTC (permalink / raw) To: linux-arm-kernel > >> + gic: interrupt-controller at 1C000000 { > >> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; > > > > This looks incorrect -- you should at the very least have a more > > specific one than a15-gic? Marc? > > "arm,cortex-a9-gic" is definitely wrong (the A9 GIC doesn't have the > virt extensions). This binding matches what the A15 GIC has, so > "arm,cortex-a15-gic" is probably fine. Main issue here is that the GICv2 > driver has no compatible string for anything else. > > Should we define something more generic (like "arm,gic-v2")? Or carry on > adding more compatible strings? It's been proposed repeatedly, and it probably makes sense to add the generic versions to the driver, and allow for more specific ones in the binding which DTs can use. That way we don't get an explosion of strings in the driver, but if we need to handle any particular GIC specially in future we can do so. I guess for Linux we'd want to add "arm,gic-v1" and "arm,gic-v2" to the driver. We could just add "arm,gic-v1" and expect it later in the compatible list if v2 is a strict superset of v1; I think it is but I'm not a GIC expert. Thanks, Mark. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board 2014-02-12 11:29 ` Mark Rutland @ 2014-02-12 11:40 ` Marc Zyngier -1 siblings, 0 replies; 82+ messages in thread From: Marc Zyngier @ 2014-02-12 11:40 UTC (permalink / raw) To: Mark Rutland Cc: Olof Johansson, linux-samsung-soc, Catalin Marinas, Ilho Lee, Thomas Abraham, Kukjin Kim, linux-arm-kernel On 12/02/14 11:29, Mark Rutland wrote: >>>> + gic: interrupt-controller@1C000000 { >>>> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; >>> >>> This looks incorrect -- you should at the very least have a more >>> specific one than a15-gic? Marc? >> >> "arm,cortex-a9-gic" is definitely wrong (the A9 GIC doesn't have the >> virt extensions). This binding matches what the A15 GIC has, so >> "arm,cortex-a15-gic" is probably fine. Main issue here is that the GICv2 >> driver has no compatible string for anything else. >> >> Should we define something more generic (like "arm,gic-v2")? Or carry on >> adding more compatible strings? > > It's been proposed repeatedly, and it probably makes sense to add the > generic versions to the driver, and allow for more specific ones in the > binding which DTs can use. That way we don't get an explosion of strings > in the driver, but if we need to handle any particular GIC specially in > future we can do so. > > I guess for Linux we'd want to add "arm,gic-v1" and "arm,gic-v2" to the > driver. We could just add "arm,gic-v1" and expect it later in the > compatible list if v2 is a strict superset of v1; I think it is but I'm > not a GIC expert. Sounds good to me. M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board @ 2014-02-12 11:40 ` Marc Zyngier 0 siblings, 0 replies; 82+ messages in thread From: Marc Zyngier @ 2014-02-12 11:40 UTC (permalink / raw) To: linux-arm-kernel On 12/02/14 11:29, Mark Rutland wrote: >>>> + gic: interrupt-controller at 1C000000 { >>>> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; >>> >>> This looks incorrect -- you should at the very least have a more >>> specific one than a15-gic? Marc? >> >> "arm,cortex-a9-gic" is definitely wrong (the A9 GIC doesn't have the >> virt extensions). This binding matches what the A15 GIC has, so >> "arm,cortex-a15-gic" is probably fine. Main issue here is that the GICv2 >> driver has no compatible string for anything else. >> >> Should we define something more generic (like "arm,gic-v2")? Or carry on >> adding more compatible strings? > > It's been proposed repeatedly, and it probably makes sense to add the > generic versions to the driver, and allow for more specific ones in the > binding which DTs can use. That way we don't get an explosion of strings > in the driver, but if we need to handle any particular GIC specially in > future we can do so. > > I guess for Linux we'd want to add "arm,gic-v1" and "arm,gic-v2" to the > driver. We could just add "arm,gic-v1" and expect it later in the > compatible list if v2 is a strict superset of v1; I think it is but I'm > not a GIC expert. Sounds good to me. M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board 2014-02-12 11:40 ` Marc Zyngier @ 2014-02-11 3:03 ` Kukjin Kim -1 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-11 3:03 UTC (permalink / raw) To: Marc Zyngier Cc: Mark Rutland, linux-samsung-soc, Catalin Marinas, Ilho Lee, Thomas Abraham, Olof Johansson, Kukjin Kim, linux-arm-kernel On 02/12/14 20:40, Marc Zyngier wrote: > On 12/02/14 11:29, Mark Rutland wrote: >>>>> + gic: interrupt-controller@1C000000 { >>>>> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; >>>> >>>> This looks incorrect -- you should at the very least have a more >>>> specific one than a15-gic? Marc? >>> >>> "arm,cortex-a9-gic" is definitely wrong (the A9 GIC doesn't have the >>> virt extensions). This binding matches what the A15 GIC has, so >>> "arm,cortex-a15-gic" is probably fine. Main issue here is that the GICv2 >>> driver has no compatible string for anything else. >>> >>> Should we define something more generic (like "arm,gic-v2")? Or carry on >>> adding more compatible strings? >> >> It's been proposed repeatedly, and it probably makes sense to add the >> generic versions to the driver, and allow for more specific ones in the >> binding which DTs can use. That way we don't get an explosion of strings >> in the driver, but if we need to handle any particular GIC specially in >> future we can do so. >> >> I guess for Linux we'd want to add "arm,gic-v1" and "arm,gic-v2" to the >> driver. We could just add "arm,gic-v1" and expect it later in the >> compatible list if v2 is a strict superset of v1; I think it is but I'm >> not a GIC expert. > > Sounds good to me. > OK, so did you guys agree to use version for gic? I'm fine to use gic-v2. And so who will take changing for others in mainline? ;-) - Kukjin ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board @ 2014-02-11 3:03 ` Kukjin Kim 0 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-11 3:03 UTC (permalink / raw) To: linux-arm-kernel On 02/12/14 20:40, Marc Zyngier wrote: > On 12/02/14 11:29, Mark Rutland wrote: >>>>> + gic: interrupt-controller at 1C000000 { >>>>> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; >>>> >>>> This looks incorrect -- you should at the very least have a more >>>> specific one than a15-gic? Marc? >>> >>> "arm,cortex-a9-gic" is definitely wrong (the A9 GIC doesn't have the >>> virt extensions). This binding matches what the A15 GIC has, so >>> "arm,cortex-a15-gic" is probably fine. Main issue here is that the GICv2 >>> driver has no compatible string for anything else. >>> >>> Should we define something more generic (like "arm,gic-v2")? Or carry on >>> adding more compatible strings? >> >> It's been proposed repeatedly, and it probably makes sense to add the >> generic versions to the driver, and allow for more specific ones in the >> binding which DTs can use. That way we don't get an explosion of strings >> in the driver, but if we need to handle any particular GIC specially in >> future we can do so. >> >> I guess for Linux we'd want to add "arm,gic-v1" and "arm,gic-v2" to the >> driver. We could just add "arm,gic-v1" and expect it later in the >> compatible list if v2 is a strict superset of v1; I think it is but I'm >> not a GIC expert. > > Sounds good to me. > OK, so did you guys agree to use version for gic? I'm fine to use gic-v2. And so who will take changing for others in mainline? ;-) - Kukjin ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-11 6:29 ` Kukjin Kim @ 2014-02-11 6:29 ` Kukjin Kim -1 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-11 6:29 UTC (permalink / raw) To: linux-arm-kernel, linux-samsung-soc Cc: Ilho Lee, Thomas Abraham, Kukjin Kim, Catalin Marinas This patch adds support for Samsung GH7 SoC in arm64/Kconfig. Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Cc: Catalin Marinas <catalin.marinas@arm.com> --- arch/arm64/Kconfig | 5 +++++ arch/arm64/boot/dts/Makefile | 1 + 2 files changed, 6 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index dd4327f..7d71823 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -111,6 +111,11 @@ source "kernel/Kconfig.freezer" menu "Platform selection" +config ARCH_GH7 + bool "Samsung ARMv8 GH7 SoC" + help + This enables support for Samsung GH7 SoC + config ARCH_VEXPRESS bool "ARMv8 software model (Versatile Express)" select ARCH_REQUIRE_GPIOLIB diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile index c52bdb0..54fb0cf 100644 --- a/arch/arm64/boot/dts/Makefile +++ b/arch/arm64/boot/dts/Makefile @@ -1,3 +1,4 @@ +dtb-$(CONFIG_ARCH_GH7) += samsung-ssdk-gh7.dtb dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-11 6:29 ` Kukjin Kim 0 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-11 6:29 UTC (permalink / raw) To: linux-arm-kernel This patch adds support for Samsung GH7 SoC in arm64/Kconfig. Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Cc: Catalin Marinas <catalin.marinas@arm.com> --- arch/arm64/Kconfig | 5 +++++ arch/arm64/boot/dts/Makefile | 1 + 2 files changed, 6 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index dd4327f..7d71823 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -111,6 +111,11 @@ source "kernel/Kconfig.freezer" menu "Platform selection" +config ARCH_GH7 + bool "Samsung ARMv8 GH7 SoC" + help + This enables support for Samsung GH7 SoC + config ARCH_VEXPRESS bool "ARMv8 software model (Versatile Express)" select ARCH_REQUIRE_GPIOLIB diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile index c52bdb0..54fb0cf 100644 --- a/arch/arm64/boot/dts/Makefile +++ b/arch/arm64/boot/dts/Makefile @@ -1,3 +1,4 @@ +dtb-$(CONFIG_ARCH_GH7) += samsung-ssdk-gh7.dtb dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-11 6:29 ` Kukjin Kim @ 2014-02-11 23:39 ` Olof Johansson -1 siblings, 0 replies; 82+ messages in thread From: Olof Johansson @ 2014-02-11 23:39 UTC (permalink / raw) To: Kukjin Kim Cc: linux-arm-kernel, linux-samsung-soc, Ilho Lee, Thomas Abraham, Catalin Marinas On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > This patch adds support for Samsung GH7 SoC in arm64/Kconfig. > > Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> > Cc: Catalin Marinas <catalin.marinas@arm.com> The overhead of building one more device tree isn't very large, and I don't see any other need to have a Kconfig entry per SoC at this time. It's of course up to Catalin, but you might just want to always compile all dts files instead. -Olof ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-11 23:39 ` Olof Johansson 0 siblings, 0 replies; 82+ messages in thread From: Olof Johansson @ 2014-02-11 23:39 UTC (permalink / raw) To: linux-arm-kernel On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > This patch adds support for Samsung GH7 SoC in arm64/Kconfig. > > Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> > Cc: Catalin Marinas <catalin.marinas@arm.com> The overhead of building one more device tree isn't very large, and I don't see any other need to have a Kconfig entry per SoC at this time. It's of course up to Catalin, but you might just want to always compile all dts files instead. -Olof ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-11 23:39 ` Olof Johansson @ 2014-02-12 10:38 ` Catalin Marinas -1 siblings, 0 replies; 82+ messages in thread From: Catalin Marinas @ 2014-02-12 10:38 UTC (permalink / raw) To: Olof Johansson Cc: Kukjin Kim, linux-arm-kernel, linux-samsung-soc, Ilho Lee, Thomas Abraham On Tue, Feb 11, 2014 at 11:39:27PM +0000, Olof Johansson wrote: > On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > > This patch adds support for Samsung GH7 SoC in arm64/Kconfig. > > > > Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> > > Cc: Catalin Marinas <catalin.marinas@arm.com> > > The overhead of building one more device tree isn't very large, and I > don't see any other need to have a Kconfig entry per SoC at this time. > It's of course up to Catalin, but you might just want to always > compile all dts files instead. For arm64, I thought of getting rid of ARCH_* Kconfig entries entirely, only that I haven't heard any strong opinion either way (in which case I'll do it, with a risk of single Image getting bigger and bigger and people needing smaller Image can trim their .config). -- Catalin ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-12 10:38 ` Catalin Marinas 0 siblings, 0 replies; 82+ messages in thread From: Catalin Marinas @ 2014-02-12 10:38 UTC (permalink / raw) To: linux-arm-kernel On Tue, Feb 11, 2014 at 11:39:27PM +0000, Olof Johansson wrote: > On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > > This patch adds support for Samsung GH7 SoC in arm64/Kconfig. > > > > Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> > > Cc: Catalin Marinas <catalin.marinas@arm.com> > > The overhead of building one more device tree isn't very large, and I > don't see any other need to have a Kconfig entry per SoC at this time. > It's of course up to Catalin, but you might just want to always > compile all dts files instead. For arm64, I thought of getting rid of ARCH_* Kconfig entries entirely, only that I haven't heard any strong opinion either way (in which case I'll do it, with a risk of single Image getting bigger and bigger and people needing smaller Image can trim their .config). -- Catalin ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-12 10:38 ` Catalin Marinas @ 2014-02-12 16:25 ` Kumar Gala -1 siblings, 0 replies; 82+ messages in thread From: Kumar Gala @ 2014-02-12 16:25 UTC (permalink / raw) To: Catalin Marinas Cc: Olof Johansson, Thomas Abraham, linux-samsung-soc, Kukjin Kim, Ilho Lee, linux-arm-kernel On Feb 12, 2014, at 4:38 AM, Catalin Marinas <catalin.marinas@arm.com> wrote: > On Tue, Feb 11, 2014 at 11:39:27PM +0000, Olof Johansson wrote: >> On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>> This patch adds support for Samsung GH7 SoC in arm64/Kconfig. >>> >>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> >>> Cc: Catalin Marinas <catalin.marinas@arm.com> >> >> The overhead of building one more device tree isn't very large, and I >> don't see any other need to have a Kconfig entry per SoC at this time. >> It's of course up to Catalin, but you might just want to always >> compile all dts files instead. > > For arm64, I thought of getting rid of ARCH_* Kconfig entries entirely, > only that I haven't heard any strong opinion either way (in which case > I'll do it, with a risk of single Image getting bigger and bigger and > people needing smaller Image can trim their .config). One reason to keep around ARCH_* is for drivers shared between arm and arm64 that depend on it. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-12 16:25 ` Kumar Gala 0 siblings, 0 replies; 82+ messages in thread From: Kumar Gala @ 2014-02-12 16:25 UTC (permalink / raw) To: linux-arm-kernel On Feb 12, 2014, at 4:38 AM, Catalin Marinas <catalin.marinas@arm.com> wrote: > On Tue, Feb 11, 2014 at 11:39:27PM +0000, Olof Johansson wrote: >> On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>> This patch adds support for Samsung GH7 SoC in arm64/Kconfig. >>> >>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> >>> Cc: Catalin Marinas <catalin.marinas@arm.com> >> >> The overhead of building one more device tree isn't very large, and I >> don't see any other need to have a Kconfig entry per SoC at this time. >> It's of course up to Catalin, but you might just want to always >> compile all dts files instead. > > For arm64, I thought of getting rid of ARCH_* Kconfig entries entirely, > only that I haven't heard any strong opinion either way (in which case > I'll do it, with a risk of single Image getting bigger and bigger and > people needing smaller Image can trim their .config). One reason to keep around ARCH_* is for drivers shared between arm and arm64 that depend on it. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-12 16:25 ` Kumar Gala @ 2014-02-12 18:12 ` Catalin Marinas -1 siblings, 0 replies; 82+ messages in thread From: Catalin Marinas @ 2014-02-12 18:12 UTC (permalink / raw) To: Kumar Gala Cc: Olof Johansson, Thomas Abraham, linux-samsung-soc, Kukjin Kim, Ilho Lee, linux-arm-kernel On 12 Feb 2014, at 16:25, Kumar Gala <galak@codeaurora.org> wrote: > On Feb 12, 2014, at 4:38 AM, Catalin Marinas <catalin.marinas@arm.com> wrote: > >> On Tue, Feb 11, 2014 at 11:39:27PM +0000, Olof Johansson wrote: >>> On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>>> This patch adds support for Samsung GH7 SoC in arm64/Kconfig. >>>> >>>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> >>>> Cc: Catalin Marinas <catalin.marinas@arm.com> >>> >>> The overhead of building one more device tree isn't very large, and I >>> don't see any other need to have a Kconfig entry per SoC at this time. >>> It's of course up to Catalin, but you might just want to always >>> compile all dts files instead. >> >> For arm64, I thought of getting rid of ARCH_* Kconfig entries entirely, >> only that I haven't heard any strong opinion either way (in which case >> I'll do it, with a risk of single Image getting bigger and bigger and >> people needing smaller Image can trim their .config). > > One reason to keep around ARCH_* is for drivers shared between arm and arm64 that depend on it. We already converted some of them (those depending on ARCH_VEXPRESS) to just depend on ARM64. Ideally, at some point I’d like to see them as defaulting to modules but I don’t think we are there yet (we had some discussions at the last KS, I’m not sure anyone started looking into this).-- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-12 18:12 ` Catalin Marinas 0 siblings, 0 replies; 82+ messages in thread From: Catalin Marinas @ 2014-02-12 18:12 UTC (permalink / raw) To: linux-arm-kernel On 12 Feb 2014, at 16:25, Kumar Gala <galak@codeaurora.org> wrote: > On Feb 12, 2014, at 4:38 AM, Catalin Marinas <catalin.marinas@arm.com> wrote: > >> On Tue, Feb 11, 2014 at 11:39:27PM +0000, Olof Johansson wrote: >>> On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>>> This patch adds support for Samsung GH7 SoC in arm64/Kconfig. >>>> >>>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> >>>> Cc: Catalin Marinas <catalin.marinas@arm.com> >>> >>> The overhead of building one more device tree isn't very large, and I >>> don't see any other need to have a Kconfig entry per SoC at this time. >>> It's of course up to Catalin, but you might just want to always >>> compile all dts files instead. >> >> For arm64, I thought of getting rid of ARCH_* Kconfig entries entirely, >> only that I haven't heard any strong opinion either way (in which case >> I'll do it, with a risk of single Image getting bigger and bigger and >> people needing smaller Image can trim their .config). > > One reason to keep around ARCH_* is for drivers shared between arm and arm64 that depend on it. We already converted some of them (those depending on ARCH_VEXPRESS) to just depend on ARM64. Ideally, at some point I?d like to see them as defaulting to modules but I don?t think we are there yet (we had some discussions at the last KS, I?m not sure anyone started looking into this). ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-12 18:12 ` Catalin Marinas @ 2014-02-12 19:04 ` Kumar Gala -1 siblings, 0 replies; 82+ messages in thread From: Kumar Gala @ 2014-02-12 19:04 UTC (permalink / raw) To: Catalin Marinas Cc: Olof Johansson, Thomas Abraham, linux-samsung-soc, Kukjin Kim, Ilho Lee, linux-arm-kernel On Feb 12, 2014, at 12:12 PM, Catalin Marinas <catalin.marinas@arm.com> wrote: > On 12 Feb 2014, at 16:25, Kumar Gala <galak@codeaurora.org> wrote: >> On Feb 12, 2014, at 4:38 AM, Catalin Marinas <catalin.marinas@arm.com> wrote: >> >>> On Tue, Feb 11, 2014 at 11:39:27PM +0000, Olof Johansson wrote: >>>> On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>>>> This patch adds support for Samsung GH7 SoC in arm64/Kconfig. >>>>> >>>>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> >>>>> Cc: Catalin Marinas <catalin.marinas@arm.com> >>>> >>>> The overhead of building one more device tree isn't very large, and I >>>> don't see any other need to have a Kconfig entry per SoC at this time. >>>> It's of course up to Catalin, but you might just want to always >>>> compile all dts files instead. >>> >>> For arm64, I thought of getting rid of ARCH_* Kconfig entries entirely, >>> only that I haven't heard any strong opinion either way (in which case >>> I'll do it, with a risk of single Image getting bigger and bigger and >>> people needing smaller Image can trim their .config). >> >> One reason to keep around ARCH_* is for drivers shared between arm and arm64 that depend on it. > > We already converted some of them (those depending on ARCH_VEXPRESS) to > just depend on ARM64. Ideally, at some point I’d like to see them as > defaulting to modules but I don’t think we are there yet (we had some > discussions at the last KS, I’m not sure anyone started looking into > this). I’m torn about this, I think for something like VEXPRESS it makes sense, however I think its reasonable to still have an config symbol for a full SoC family or something of that nature. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-12 19:04 ` Kumar Gala 0 siblings, 0 replies; 82+ messages in thread From: Kumar Gala @ 2014-02-12 19:04 UTC (permalink / raw) To: linux-arm-kernel On Feb 12, 2014, at 12:12 PM, Catalin Marinas <catalin.marinas@arm.com> wrote: > On 12 Feb 2014, at 16:25, Kumar Gala <galak@codeaurora.org> wrote: >> On Feb 12, 2014, at 4:38 AM, Catalin Marinas <catalin.marinas@arm.com> wrote: >> >>> On Tue, Feb 11, 2014 at 11:39:27PM +0000, Olof Johansson wrote: >>>> On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>>>> This patch adds support for Samsung GH7 SoC in arm64/Kconfig. >>>>> >>>>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> >>>>> Cc: Catalin Marinas <catalin.marinas@arm.com> >>>> >>>> The overhead of building one more device tree isn't very large, and I >>>> don't see any other need to have a Kconfig entry per SoC at this time. >>>> It's of course up to Catalin, but you might just want to always >>>> compile all dts files instead. >>> >>> For arm64, I thought of getting rid of ARCH_* Kconfig entries entirely, >>> only that I haven't heard any strong opinion either way (in which case >>> I'll do it, with a risk of single Image getting bigger and bigger and >>> people needing smaller Image can trim their .config). >> >> One reason to keep around ARCH_* is for drivers shared between arm and arm64 that depend on it. > > We already converted some of them (those depending on ARCH_VEXPRESS) to > just depend on ARM64. Ideally, at some point I?d like to see them as > defaulting to modules but I don?t think we are there yet (we had some > discussions at the last KS, I?m not sure anyone started looking into > this). I?m torn about this, I think for something like VEXPRESS it makes sense, however I think its reasonable to still have an config symbol for a full SoC family or something of that nature. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-12 19:04 ` Kumar Gala @ 2014-02-12 19:14 ` Arnd Bergmann -1 siblings, 0 replies; 82+ messages in thread From: Arnd Bergmann @ 2014-02-12 19:14 UTC (permalink / raw) To: linux-arm-kernel Cc: Kumar Gala, Catalin Marinas, linux-samsung-soc, Ilho Lee, Thomas Abraham, Olof Johansson, Kukjin Kim On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: > On Feb 12, 2014, at 12:12 PM, Catalin Marinas <catalin.marinas@arm.com> wrote: > > On 12 Feb 2014, at 16:25, Kumar Gala <galak@codeaurora.org> wrote: > >> One reason to keep around ARCH_* is for drivers shared between arm and arm64 that depend on it. > > > > We already converted some of them (those depending on ARCH_VEXPRESS) to > > just depend on ARM64. Ideally, at some point I’d like to see them as > > defaulting to modules but I don’t think we are there yet (we had some > > discussions at the last KS, I’m not sure anyone started looking into > > this). > > I’m torn about this, I think for something like VEXPRESS it makes sense, > however I think its reasonable to still have an config symbol for a full > SoC family or something of that nature. I think for SBSA compliant systems, we should be able to live with a generic ARCH_SBSA Kconfig symbol. For more irregular embedded platforms, we may need something more specific. Arnd ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-12 19:14 ` Arnd Bergmann 0 siblings, 0 replies; 82+ messages in thread From: Arnd Bergmann @ 2014-02-12 19:14 UTC (permalink / raw) To: linux-arm-kernel On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: > On Feb 12, 2014, at 12:12 PM, Catalin Marinas <catalin.marinas@arm.com> wrote: > > On 12 Feb 2014, at 16:25, Kumar Gala <galak@codeaurora.org> wrote: > >> One reason to keep around ARCH_* is for drivers shared between arm and arm64 that depend on it. > > > > We already converted some of them (those depending on ARCH_VEXPRESS) to > > just depend on ARM64. Ideally, at some point I?d like to see them as > > defaulting to modules but I don?t think we are there yet (we had some > > discussions at the last KS, I?m not sure anyone started looking into > > this). > > I?m torn about this, I think for something like VEXPRESS it makes sense, > however I think its reasonable to still have an config symbol for a full > SoC family or something of that nature. I think for SBSA compliant systems, we should be able to live with a generic ARCH_SBSA Kconfig symbol. For more irregular embedded platforms, we may need something more specific. Arnd ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-12 19:14 ` Arnd Bergmann @ 2014-02-11 2:52 ` Kukjin Kim -1 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-11 2:52 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-arm-kernel, linux-samsung-soc, Catalin Marinas, Ilho Lee, Thomas Abraham, Kumar Gala, Olof Johansson, Kukjin Kim On 02/13/14 04:14, Arnd Bergmann wrote: > On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: >> On Feb 12, 2014, at 12:12 PM, Catalin Marinas<catalin.marinas@arm.com> wrote: >>> On 12 Feb 2014, at 16:25, Kumar Gala<galak@codeaurora.org> wrote: >>>> One reason to keep around ARCH_* is for drivers shared between arm and arm64 that depend on it. >>> >>> We already converted some of them (those depending on ARCH_VEXPRESS) to >>> just depend on ARM64. Ideally, at some point I’d like to see them as >>> defaulting to modules but I don’t think we are there yet (we had some >>> discussions at the last KS, I’m not sure anyone started looking into >>> this). >> >> I’m torn about this, I think for something like VEXPRESS it makes sense, >> however I think its reasonable to still have an config symbol for a full >> SoC family or something of that nature. > > I think for SBSA compliant systems, we should be able to live with a > generic ARCH_SBSA Kconfig symbol. For more irregular embedded platforms, > we may need something more specific. > Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need to define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about compliant with SBSA Level1 and having some specific features? - Kukjin ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-11 2:52 ` Kukjin Kim 0 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-11 2:52 UTC (permalink / raw) To: linux-arm-kernel On 02/13/14 04:14, Arnd Bergmann wrote: > On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: >> On Feb 12, 2014, at 12:12 PM, Catalin Marinas<catalin.marinas@arm.com> wrote: >>> On 12 Feb 2014, at 16:25, Kumar Gala<galak@codeaurora.org> wrote: >>>> One reason to keep around ARCH_* is for drivers shared between arm and arm64 that depend on it. >>> >>> We already converted some of them (those depending on ARCH_VEXPRESS) to >>> just depend on ARM64. Ideally, at some point I?d like to see them as >>> defaulting to modules but I don?t think we are there yet (we had some >>> discussions at the last KS, I?m not sure anyone started looking into >>> this). >> >> I?m torn about this, I think for something like VEXPRESS it makes sense, >> however I think its reasonable to still have an config symbol for a full >> SoC family or something of that nature. > > I think for SBSA compliant systems, we should be able to live with a > generic ARCH_SBSA Kconfig symbol. For more irregular embedded platforms, > we may need something more specific. > Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need to define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about compliant with SBSA Level1 and having some specific features? - Kukjin ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-11 2:52 ` Kukjin Kim @ 2014-02-13 19:26 ` Olof Johansson -1 siblings, 0 replies; 82+ messages in thread From: Olof Johansson @ 2014-02-13 19:26 UTC (permalink / raw) To: Kukjin Kim Cc: Arnd Bergmann, linux-arm-kernel, linux-samsung-soc, Catalin Marinas, Ilho Lee, Thomas Abraham, Kumar Gala On Mon, Feb 10, 2014 at 6:52 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > On 02/13/14 04:14, Arnd Bergmann wrote: >> >> On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: >>> >>> On Feb 12, 2014, at 12:12 PM, Catalin Marinas<catalin.marinas@arm.com> >>> wrote: >>>> >>>> On 12 Feb 2014, at 16:25, Kumar Gala<galak@codeaurora.org> wrote: >>>>> >>>>> One reason to keep around ARCH_* is for drivers shared between arm and >>>>> arm64 that depend on it. >>>> >>>> >>>> We already converted some of them (those depending on ARCH_VEXPRESS) to >>>> just depend on ARM64. Ideally, at some point I'd like to see them as >>>> defaulting to modules but I don't think we are there yet (we had some >>>> discussions at the last KS, I'm not sure anyone started looking into >>>> this). >>> >>> >>> I'm torn about this, I think for something like VEXPRESS it makes sense, >>> however I think its reasonable to still have an config symbol for a full >>> SoC family or something of that nature. >> >> >> I think for SBSA compliant systems, we should be able to live with a >> generic ARCH_SBSA Kconfig symbol. For more irregular embedded platforms, >> we may need something more specific. >> > Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need to > define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about > compliant with SBSA Level1 and having some specific features? (It's a little hard to answer since nobody can download the doc and then talk about it.) What kind of features are you expecting though? More IP blocks/devices? Those are just kernel config options to enable, ideally as modules. x86 doesn't need config options for each generation of their platform, and neither should ARM64. Sure, there might be drivers that don't make sense to enable on some platforms, but that's what defconfigs (or distro configs), and modules are for -- the modules won't load unless the hardware is there. As long as we're not talking about massive amounts of code that is part of the base platform, separating out per version again doesn't make sense -- just enable for SBSA and it'll support Level 1 through whatever. If the kernel size becomes a concern we can revisit, but let's not start out that way. -Olof ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-13 19:26 ` Olof Johansson 0 siblings, 0 replies; 82+ messages in thread From: Olof Johansson @ 2014-02-13 19:26 UTC (permalink / raw) To: linux-arm-kernel On Mon, Feb 10, 2014 at 6:52 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > On 02/13/14 04:14, Arnd Bergmann wrote: >> >> On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: >>> >>> On Feb 12, 2014, at 12:12 PM, Catalin Marinas<catalin.marinas@arm.com> >>> wrote: >>>> >>>> On 12 Feb 2014, at 16:25, Kumar Gala<galak@codeaurora.org> wrote: >>>>> >>>>> One reason to keep around ARCH_* is for drivers shared between arm and >>>>> arm64 that depend on it. >>>> >>>> >>>> We already converted some of them (those depending on ARCH_VEXPRESS) to >>>> just depend on ARM64. Ideally, at some point I'd like to see them as >>>> defaulting to modules but I don't think we are there yet (we had some >>>> discussions at the last KS, I'm not sure anyone started looking into >>>> this). >>> >>> >>> I'm torn about this, I think for something like VEXPRESS it makes sense, >>> however I think its reasonable to still have an config symbol for a full >>> SoC family or something of that nature. >> >> >> I think for SBSA compliant systems, we should be able to live with a >> generic ARCH_SBSA Kconfig symbol. For more irregular embedded platforms, >> we may need something more specific. >> > Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need to > define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about > compliant with SBSA Level1 and having some specific features? (It's a little hard to answer since nobody can download the doc and then talk about it.) What kind of features are you expecting though? More IP blocks/devices? Those are just kernel config options to enable, ideally as modules. x86 doesn't need config options for each generation of their platform, and neither should ARM64. Sure, there might be drivers that don't make sense to enable on some platforms, but that's what defconfigs (or distro configs), and modules are for -- the modules won't load unless the hardware is there. As long as we're not talking about massive amounts of code that is part of the base platform, separating out per version again doesn't make sense -- just enable for SBSA and it'll support Level 1 through whatever. If the kernel size becomes a concern we can revisit, but let's not start out that way. -Olof ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-13 19:26 ` Olof Johansson @ 2014-02-14 17:06 ` Arnd Bergmann -1 siblings, 0 replies; 82+ messages in thread From: Arnd Bergmann @ 2014-02-14 17:06 UTC (permalink / raw) To: Olof Johansson Cc: Kukjin Kim, linux-arm-kernel, linux-samsung-soc, Catalin Marinas, Ilho Lee, Thomas Abraham, Kumar Gala On Thursday 13 February 2014, Olof Johansson wrote: > On Mon, Feb 10, 2014 at 6:52 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > > On 02/13/14 04:14, Arnd Bergmann wrote: > >> On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: > > Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need to > > define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about > > compliant with SBSA Level1 and having some specific features? My feeling is that we don't need to use the levels for Kconfig, although we might want to use them DT compatible strings, even if it ends up looking a little funny when you do compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; > What kind of features are you expecting though? More IP > blocks/devices? Those are just kernel config options to enable, > ideally as modules. Right, I think we can just put them into defconfig. No need to "select" them from Kconfig since the extra options wouldn't be required for booting or using the system. Arnd ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-14 17:06 ` Arnd Bergmann 0 siblings, 0 replies; 82+ messages in thread From: Arnd Bergmann @ 2014-02-14 17:06 UTC (permalink / raw) To: linux-arm-kernel On Thursday 13 February 2014, Olof Johansson wrote: > On Mon, Feb 10, 2014 at 6:52 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > > On 02/13/14 04:14, Arnd Bergmann wrote: > >> On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: > > Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need to > > define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about > > compliant with SBSA Level1 and having some specific features? My feeling is that we don't need to use the levels for Kconfig, although we might want to use them DT compatible strings, even if it ends up looking a little funny when you do compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; > What kind of features are you expecting though? More IP > blocks/devices? Those are just kernel config options to enable, > ideally as modules. Right, I think we can just put them into defconfig. No need to "select" them from Kconfig since the extra options wouldn't be required for booting or using the system. Arnd ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-14 17:06 ` Arnd Bergmann @ 2014-02-18 1:10 ` Kukjin Kim -1 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-18 1:10 UTC (permalink / raw) To: Arnd Bergmann Cc: Olof Johansson, linux-samsung-soc, Catalin Marinas, Ilho Lee, Thomas Abraham, Kumar Gala, Kukjin Kim, linux-arm-kernel On 02/15/14 02:06, Arnd Bergmann wrote: > On Thursday 13 February 2014, Olof Johansson wrote: >> On Mon, Feb 10, 2014 at 6:52 PM, Kukjin Kim<kgene.kim@samsung.com> wrote: >>> On 02/13/14 04:14, Arnd Bergmann wrote: >>>> On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: >>> Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need to >>> define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about >>> compliant with SBSA Level1 and having some specific features? > Well, how about ARMv8 mobile SoC? I think, it is not compatible with SBSA. For example, you know MCT can be used for ARMv8 cores instead of ARCH Timer. So I'm not sure ARCH_SBSA is really good choice... > My feeling is that we don't need to use the levels for Kconfig, although > we might want to use them DT compatible strings, even if it ends up looking > a little funny when you do > > compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; > >> What kind of features are you expecting though? More IP >> blocks/devices? Those are just kernel config options to enable, >> ideally as modules. > > Right, I think we can just put them into defconfig. No need to > "select" them from Kconfig since the extra options wouldn't be > required for booting or using the system. > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, it is not for used for GH7 though... - Kukjin ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-18 1:10 ` Kukjin Kim 0 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-18 1:10 UTC (permalink / raw) To: linux-arm-kernel On 02/15/14 02:06, Arnd Bergmann wrote: > On Thursday 13 February 2014, Olof Johansson wrote: >> On Mon, Feb 10, 2014 at 6:52 PM, Kukjin Kim<kgene.kim@samsung.com> wrote: >>> On 02/13/14 04:14, Arnd Bergmann wrote: >>>> On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: >>> Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need to >>> define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about >>> compliant with SBSA Level1 and having some specific features? > Well, how about ARMv8 mobile SoC? I think, it is not compatible with SBSA. For example, you know MCT can be used for ARMv8 cores instead of ARCH Timer. So I'm not sure ARCH_SBSA is really good choice... > My feeling is that we don't need to use the levels for Kconfig, although > we might want to use them DT compatible strings, even if it ends up looking > a little funny when you do > > compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; > >> What kind of features are you expecting though? More IP >> blocks/devices? Those are just kernel config options to enable, >> ideally as modules. > > Right, I think we can just put them into defconfig. No need to > "select" them from Kconfig since the extra options wouldn't be > required for booting or using the system. > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, it is not for used for GH7 though... - Kukjin ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-18 1:10 ` Kukjin Kim @ 2014-02-18 10:53 ` Arnd Bergmann -1 siblings, 0 replies; 82+ messages in thread From: Arnd Bergmann @ 2014-02-18 10:53 UTC (permalink / raw) To: Kukjin Kim Cc: Olof Johansson, linux-samsung-soc, Catalin Marinas, Ilho Lee, Thomas Abraham, Kumar Gala, linux-arm-kernel On Tuesday 18 February 2014 10:10:30 Kukjin Kim wrote: > On 02/15/14 02:06, Arnd Bergmann wrote: > > On Thursday 13 February 2014, Olof Johansson wrote: > >> On Mon, Feb 10, 2014 at 6:52 PM, Kukjin Kim<kgene.kim@samsung.com> wrote: > >>> On 02/13/14 04:14, Arnd Bergmann wrote: > >>>> On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: > >>> Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need to > >>> define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about > >>> compliant with SBSA Level1 and having some specific features? > > > Well, how about ARMv8 mobile SoC? I think, it is not compatible with > SBSA. For example, you know MCT can be used for ARMv8 cores instead of > ARCH Timer. So I'm not sure ARCH_SBSA is really good choice... Sure, if you are talking about an embedded SoC that is not SBSA compliant, we shouldn't try to make it work with ARCH_SBSA and instead give it its own Kconfig symbol. > > My feeling is that we don't need to use the levels for Kconfig, although > > we might want to use them DT compatible strings, even if it ends up looking > > a little funny when you do > > > > compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; > > > >> What kind of features are you expecting though? More IP > >> blocks/devices? Those are just kernel config options to enable, > >> ideally as modules. > > > > Right, I think we can just put them into defconfig. No need to > > "select" them from Kconfig since the extra options wouldn't be > > required for booting or using the system. > > > As I commented above, how about MCT? Samsung has a plan to use MCT on > ARMv8, it is not for used for GH7 though... If it's just one driver that is needed in addition to the usual stuff, we can also just make it a standalone option and turn it on in the generic defconfig. We won't need a per-platform option in that case. Arnd ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-18 10:53 ` Arnd Bergmann 0 siblings, 0 replies; 82+ messages in thread From: Arnd Bergmann @ 2014-02-18 10:53 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 18 February 2014 10:10:30 Kukjin Kim wrote: > On 02/15/14 02:06, Arnd Bergmann wrote: > > On Thursday 13 February 2014, Olof Johansson wrote: > >> On Mon, Feb 10, 2014 at 6:52 PM, Kukjin Kim<kgene.kim@samsung.com> wrote: > >>> On 02/13/14 04:14, Arnd Bergmann wrote: > >>>> On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: > >>> Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need to > >>> define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about > >>> compliant with SBSA Level1 and having some specific features? > > > Well, how about ARMv8 mobile SoC? I think, it is not compatible with > SBSA. For example, you know MCT can be used for ARMv8 cores instead of > ARCH Timer. So I'm not sure ARCH_SBSA is really good choice... Sure, if you are talking about an embedded SoC that is not SBSA compliant, we shouldn't try to make it work with ARCH_SBSA and instead give it its own Kconfig symbol. > > My feeling is that we don't need to use the levels for Kconfig, although > > we might want to use them DT compatible strings, even if it ends up looking > > a little funny when you do > > > > compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; > > > >> What kind of features are you expecting though? More IP > >> blocks/devices? Those are just kernel config options to enable, > >> ideally as modules. > > > > Right, I think we can just put them into defconfig. No need to > > "select" them from Kconfig since the extra options wouldn't be > > required for booting or using the system. > > > As I commented above, how about MCT? Samsung has a plan to use MCT on > ARMv8, it is not for used for GH7 though... If it's just one driver that is needed in addition to the usual stuff, we can also just make it a standalone option and turn it on in the generic defconfig. We won't need a per-platform option in that case. Arnd ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-18 1:10 ` Kukjin Kim @ 2014-02-18 16:16 ` Olof Johansson -1 siblings, 0 replies; 82+ messages in thread From: Olof Johansson @ 2014-02-18 16:16 UTC (permalink / raw) To: Kukjin Kim Cc: Arnd Bergmann, linux-samsung-soc, Catalin Marinas, Ilho Lee, Thomas Abraham, Kumar Gala, linux-arm-kernel, Daniel Lezcano, Thomas Gleixner On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > On 02/15/14 02:06, Arnd Bergmann wrote: >> >> On Thursday 13 February 2014, Olof Johansson wrote: >>> >>> On Mon, Feb 10, 2014 at 6:52 PM, Kukjin Kim<kgene.kim@samsung.com> >>> wrote: >>>> >>>> On 02/13/14 04:14, Arnd Bergmann wrote: >>>>> >>>>> On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: >>>> >>>> Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need >>>> to >>>> define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about >>>> compliant with SBSA Level1 and having some specific features? >> >> > Well, how about ARMv8 mobile SoC? I think, it is not compatible with SBSA. > For example, you know MCT can be used for ARMv8 cores instead of ARCH Timer. > So I'm not sure ARCH_SBSA is really good choice... > > >> My feeling is that we don't need to use the levels for Kconfig, although >> we might want to use them DT compatible strings, even if it ends up >> looking >> a little funny when you do >> >> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; >> >>> What kind of features are you expecting though? More IP >>> blocks/devices? Those are just kernel config options to enable, >>> ideally as modules. >> >> >> Right, I think we can just put them into defconfig. No need to >> "select" them from Kconfig since the extra options wouldn't be >> required for booting or using the system. >> > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, > it is not for used for GH7 though... It looks like the clocksource drivers are all based around being enabled based on platforms instead of individually selectable. That causes a problem here. I think we should change the clocksource Kconfig instead. Then it's just a matter of making sure your defconfig has the needed driver enabled. (Adding Daniel and Thomas in case they have objections to that approach) -Olof ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-18 16:16 ` Olof Johansson 0 siblings, 0 replies; 82+ messages in thread From: Olof Johansson @ 2014-02-18 16:16 UTC (permalink / raw) To: linux-arm-kernel On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > On 02/15/14 02:06, Arnd Bergmann wrote: >> >> On Thursday 13 February 2014, Olof Johansson wrote: >>> >>> On Mon, Feb 10, 2014 at 6:52 PM, Kukjin Kim<kgene.kim@samsung.com> >>> wrote: >>>> >>>> On 02/13/14 04:14, Arnd Bergmann wrote: >>>>> >>>>> On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: >>>> >>>> Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need >>>> to >>>> define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about >>>> compliant with SBSA Level1 and having some specific features? >> >> > Well, how about ARMv8 mobile SoC? I think, it is not compatible with SBSA. > For example, you know MCT can be used for ARMv8 cores instead of ARCH Timer. > So I'm not sure ARCH_SBSA is really good choice... > > >> My feeling is that we don't need to use the levels for Kconfig, although >> we might want to use them DT compatible strings, even if it ends up >> looking >> a little funny when you do >> >> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; >> >>> What kind of features are you expecting though? More IP >>> blocks/devices? Those are just kernel config options to enable, >>> ideally as modules. >> >> >> Right, I think we can just put them into defconfig. No need to >> "select" them from Kconfig since the extra options wouldn't be >> required for booting or using the system. >> > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, > it is not for used for GH7 though... It looks like the clocksource drivers are all based around being enabled based on platforms instead of individually selectable. That causes a problem here. I think we should change the clocksource Kconfig instead. Then it's just a matter of making sure your defconfig has the needed driver enabled. (Adding Daniel and Thomas in case they have objections to that approach) -Olof ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-18 16:16 ` Olof Johansson @ 2014-02-18 18:13 ` Arnd Bergmann -1 siblings, 0 replies; 82+ messages in thread From: Arnd Bergmann @ 2014-02-18 18:13 UTC (permalink / raw) To: Olof Johansson, John Stultz Cc: Kukjin Kim, linux-samsung-soc, Catalin Marinas, Ilho Lee, Thomas Abraham, Kumar Gala, linux-arm-kernel, Daniel Lezcano, Thomas Gleixner On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: > On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > > On 02/15/14 02:06, Arnd Bergmann wrote: > >> My feeling is that we don't need to use the levels for Kconfig, although > >> we might want to use them DT compatible strings, even if it ends up > >> looking > >> a little funny when you do > >> > >> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; > >> > >>> What kind of features are you expecting though? More IP > >>> blocks/devices? Those are just kernel config options to enable, > >>> ideally as modules. > >> > >> > >> Right, I think we can just put them into defconfig. No need to > >> "select" them from Kconfig since the extra options wouldn't be > >> required for booting or using the system. > >> > > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, > > it is not for used for GH7 though... > > It looks like the clocksource drivers are all based around being > enabled based on platforms instead of individually selectable. That > causes a problem here. I think we should change the clocksource > Kconfig instead. Then it's just a matter of making sure your defconfig > has the needed driver enabled. > > (Adding Daniel and Thomas in case they have objections to that approach) +John Stultz IIRC it was John who insisted on doing it the current way, although I can't remember his reasoning. Arnd ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-18 18:13 ` Arnd Bergmann 0 siblings, 0 replies; 82+ messages in thread From: Arnd Bergmann @ 2014-02-18 18:13 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: > On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > > On 02/15/14 02:06, Arnd Bergmann wrote: > >> My feeling is that we don't need to use the levels for Kconfig, although > >> we might want to use them DT compatible strings, even if it ends up > >> looking > >> a little funny when you do > >> > >> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; > >> > >>> What kind of features are you expecting though? More IP > >>> blocks/devices? Those are just kernel config options to enable, > >>> ideally as modules. > >> > >> > >> Right, I think we can just put them into defconfig. No need to > >> "select" them from Kconfig since the extra options wouldn't be > >> required for booting or using the system. > >> > > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, > > it is not for used for GH7 though... > > It looks like the clocksource drivers are all based around being > enabled based on platforms instead of individually selectable. That > causes a problem here. I think we should change the clocksource > Kconfig instead. Then it's just a matter of making sure your defconfig > has the needed driver enabled. > > (Adding Daniel and Thomas in case they have objections to that approach) +John Stultz IIRC it was John who insisted on doing it the current way, although I can't remember his reasoning. Arnd ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-18 18:13 ` Arnd Bergmann @ 2014-02-18 19:52 ` John Stultz -1 siblings, 0 replies; 82+ messages in thread From: John Stultz @ 2014-02-18 19:52 UTC (permalink / raw) To: Arnd Bergmann Cc: Olof Johansson, Kukjin Kim, linux-samsung-soc, Catalin Marinas, Ilho Lee, Thomas Abraham, Kumar Gala, linux-arm-kernel, Daniel Lezcano, Thomas Gleixner On Tue, Feb 18, 2014 at 10:13 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: >> On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >> > On 02/15/14 02:06, Arnd Bergmann wrote: >> >> My feeling is that we don't need to use the levels for Kconfig, although >> >> we might want to use them DT compatible strings, even if it ends up >> >> looking >> >> a little funny when you do >> >> >> >> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; >> >> >> >>> What kind of features are you expecting though? More IP >> >>> blocks/devices? Those are just kernel config options to enable, >> >>> ideally as modules. >> >> >> >> >> >> Right, I think we can just put them into defconfig. No need to >> >> "select" them from Kconfig since the extra options wouldn't be >> >> required for booting or using the system. >> >> >> > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, >> > it is not for used for GH7 though... >> >> It looks like the clocksource drivers are all based around being >> enabled based on platforms instead of individually selectable. That >> causes a problem here. I think we should change the clocksource >> Kconfig instead. Then it's just a matter of making sure your defconfig >> has the needed driver enabled. >> >> (Adding Daniel and Thomas in case they have objections to that approach) > > +John Stultz > > IIRC it was John who insisted on doing it the current way, although > I can't remember his reasoning. Are we really expecting there to be SoC specific clocksources here? I thought we were getting away from that sort of stuff with the architecture timer? I'm fine with clocksources being selected by other functionality options (ie: on x86 ACPI PM timer clocksource doesn't have a prompt, but depends on the ACPI option). I just don't want to force users to have to navigate through tons of deep menus to select clocksource options that logically duplicate other selections already made. But again, I handed this maintainership over to Daniel, so I can be considered just a crank yelling from the sidelines :) thanks -john ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-18 19:52 ` John Stultz 0 siblings, 0 replies; 82+ messages in thread From: John Stultz @ 2014-02-18 19:52 UTC (permalink / raw) To: linux-arm-kernel On Tue, Feb 18, 2014 at 10:13 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: >> On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >> > On 02/15/14 02:06, Arnd Bergmann wrote: >> >> My feeling is that we don't need to use the levels for Kconfig, although >> >> we might want to use them DT compatible strings, even if it ends up >> >> looking >> >> a little funny when you do >> >> >> >> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; >> >> >> >>> What kind of features are you expecting though? More IP >> >>> blocks/devices? Those are just kernel config options to enable, >> >>> ideally as modules. >> >> >> >> >> >> Right, I think we can just put them into defconfig. No need to >> >> "select" them from Kconfig since the extra options wouldn't be >> >> required for booting or using the system. >> >> >> > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, >> > it is not for used for GH7 though... >> >> It looks like the clocksource drivers are all based around being >> enabled based on platforms instead of individually selectable. That >> causes a problem here. I think we should change the clocksource >> Kconfig instead. Then it's just a matter of making sure your defconfig >> has the needed driver enabled. >> >> (Adding Daniel and Thomas in case they have objections to that approach) > > +John Stultz > > IIRC it was John who insisted on doing it the current way, although > I can't remember his reasoning. Are we really expecting there to be SoC specific clocksources here? I thought we were getting away from that sort of stuff with the architecture timer? I'm fine with clocksources being selected by other functionality options (ie: on x86 ACPI PM timer clocksource doesn't have a prompt, but depends on the ACPI option). I just don't want to force users to have to navigate through tons of deep menus to select clocksource options that logically duplicate other selections already made. But again, I handed this maintainership over to Daniel, so I can be considered just a crank yelling from the sidelines :) thanks -john ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-18 19:52 ` John Stultz @ 2014-02-18 20:00 ` Olof Johansson -1 siblings, 0 replies; 82+ messages in thread From: Olof Johansson @ 2014-02-18 20:00 UTC (permalink / raw) To: John Stultz Cc: Arnd Bergmann, Kukjin Kim, linux-samsung-soc, Catalin Marinas, Ilho Lee, Thomas Abraham, Kumar Gala, linux-arm-kernel, Daniel Lezcano, Thomas Gleixner On Tue, Feb 18, 2014 at 11:52 AM, John Stultz <john.stultz@linaro.org> wrote: > On Tue, Feb 18, 2014 at 10:13 AM, Arnd Bergmann <arnd@arndb.de> wrote: >> On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: >>> On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>> > On 02/15/14 02:06, Arnd Bergmann wrote: >>> >> My feeling is that we don't need to use the levels for Kconfig, although >>> >> we might want to use them DT compatible strings, even if it ends up >>> >> looking >>> >> a little funny when you do >>> >> >>> >> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; >>> >> >>> >>> What kind of features are you expecting though? More IP >>> >>> blocks/devices? Those are just kernel config options to enable, >>> >>> ideally as modules. >>> >> >>> >> >>> >> Right, I think we can just put them into defconfig. No need to >>> >> "select" them from Kconfig since the extra options wouldn't be >>> >> required for booting or using the system. >>> >> >>> > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, >>> > it is not for used for GH7 though... >>> >>> It looks like the clocksource drivers are all based around being >>> enabled based on platforms instead of individually selectable. That >>> causes a problem here. I think we should change the clocksource >>> Kconfig instead. Then it's just a matter of making sure your defconfig >>> has the needed driver enabled. >>> >>> (Adding Daniel and Thomas in case they have objections to that approach) >> >> +John Stultz >> >> IIRC it was John who insisted on doing it the current way, although >> I can't remember his reasoning. > > Are we really expecting there to be SoC specific clocksources here? I > thought we were getting away from that sort of stuff with the > architecture timer? Unfortunately vendors can do crazy stuff if they want to. But we also have an option to choose to enable it. Maybe the answer here is to say no to MCT on 64-bit, they get to use the arch timers like everybody else. Or at least motivate why they're not good enough. > I'm fine with clocksources being selected by other functionality > options (ie: on x86 ACPI PM timer clocksource doesn't have a prompt, > but depends on the ACPI option). I just don't want to force users to > have to navigate through tons of deep menus to select clocksource > options that logically duplicate other selections already made. > > But again, I handed this maintainership over to Daniel, so I can be > considered just a crank yelling from the sidelines :) I think you have a good point. Until we hear why MCT is needed this is mostly speculation, so let's see what Kukjin says about that. -Olof ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-18 20:00 ` Olof Johansson 0 siblings, 0 replies; 82+ messages in thread From: Olof Johansson @ 2014-02-18 20:00 UTC (permalink / raw) To: linux-arm-kernel On Tue, Feb 18, 2014 at 11:52 AM, John Stultz <john.stultz@linaro.org> wrote: > On Tue, Feb 18, 2014 at 10:13 AM, Arnd Bergmann <arnd@arndb.de> wrote: >> On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: >>> On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>> > On 02/15/14 02:06, Arnd Bergmann wrote: >>> >> My feeling is that we don't need to use the levels for Kconfig, although >>> >> we might want to use them DT compatible strings, even if it ends up >>> >> looking >>> >> a little funny when you do >>> >> >>> >> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; >>> >> >>> >>> What kind of features are you expecting though? More IP >>> >>> blocks/devices? Those are just kernel config options to enable, >>> >>> ideally as modules. >>> >> >>> >> >>> >> Right, I think we can just put them into defconfig. No need to >>> >> "select" them from Kconfig since the extra options wouldn't be >>> >> required for booting or using the system. >>> >> >>> > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, >>> > it is not for used for GH7 though... >>> >>> It looks like the clocksource drivers are all based around being >>> enabled based on platforms instead of individually selectable. That >>> causes a problem here. I think we should change the clocksource >>> Kconfig instead. Then it's just a matter of making sure your defconfig >>> has the needed driver enabled. >>> >>> (Adding Daniel and Thomas in case they have objections to that approach) >> >> +John Stultz >> >> IIRC it was John who insisted on doing it the current way, although >> I can't remember his reasoning. > > Are we really expecting there to be SoC specific clocksources here? I > thought we were getting away from that sort of stuff with the > architecture timer? Unfortunately vendors can do crazy stuff if they want to. But we also have an option to choose to enable it. Maybe the answer here is to say no to MCT on 64-bit, they get to use the arch timers like everybody else. Or at least motivate why they're not good enough. > I'm fine with clocksources being selected by other functionality > options (ie: on x86 ACPI PM timer clocksource doesn't have a prompt, > but depends on the ACPI option). I just don't want to force users to > have to navigate through tons of deep menus to select clocksource > options that logically duplicate other selections already made. > > But again, I handed this maintainership over to Daniel, so I can be > considered just a crank yelling from the sidelines :) I think you have a good point. Until we hear why MCT is needed this is mostly speculation, so let's see what Kukjin says about that. -Olof ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-18 20:00 ` Olof Johansson @ 2014-02-18 20:06 ` John Stultz -1 siblings, 0 replies; 82+ messages in thread From: John Stultz @ 2014-02-18 20:06 UTC (permalink / raw) To: Olof Johansson Cc: Arnd Bergmann, Kukjin Kim, linux-samsung-soc, Catalin Marinas, Ilho Lee, Thomas Abraham, Kumar Gala, linux-arm-kernel, Daniel Lezcano, Thomas Gleixner On Tue, Feb 18, 2014 at 12:00 PM, Olof Johansson <olof@lixom.net> wrote: > On Tue, Feb 18, 2014 at 11:52 AM, John Stultz <john.stultz@linaro.org> wrote: >> On Tue, Feb 18, 2014 at 10:13 AM, Arnd Bergmann <arnd@arndb.de> wrote: >>> On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: >>>> On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>>> > On 02/15/14 02:06, Arnd Bergmann wrote: >>>> >> My feeling is that we don't need to use the levels for Kconfig, although >>>> >> we might want to use them DT compatible strings, even if it ends up >>>> >> looking >>>> >> a little funny when you do >>>> >> >>>> >> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; >>>> >> >>>> >>> What kind of features are you expecting though? More IP >>>> >>> blocks/devices? Those are just kernel config options to enable, >>>> >>> ideally as modules. >>>> >> >>>> >> >>>> >> Right, I think we can just put them into defconfig. No need to >>>> >> "select" them from Kconfig since the extra options wouldn't be >>>> >> required for booting or using the system. >>>> >> >>>> > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, >>>> > it is not for used for GH7 though... >>>> >>>> It looks like the clocksource drivers are all based around being >>>> enabled based on platforms instead of individually selectable. That >>>> causes a problem here. I think we should change the clocksource >>>> Kconfig instead. Then it's just a matter of making sure your defconfig >>>> has the needed driver enabled. >>>> >>>> (Adding Daniel and Thomas in case they have objections to that approach) >>> >>> +John Stultz >>> >>> IIRC it was John who insisted on doing it the current way, although >>> I can't remember his reasoning. >> >> Are we really expecting there to be SoC specific clocksources here? I >> thought we were getting away from that sort of stuff with the >> architecture timer? > > Unfortunately vendors can do crazy stuff if they want to. But we also > have an option to choose to enable it. Maybe the answer here is to say > no to MCT on 64-bit, they get to use the arch timers like everybody > else. Or at least motivate why they're not good enough. > >> I'm fine with clocksources being selected by other functionality >> options (ie: on x86 ACPI PM timer clocksource doesn't have a prompt, >> but depends on the ACPI option). I just don't want to force users to >> have to navigate through tons of deep menus to select clocksource >> options that logically duplicate other selections already made. >> >> But again, I handed this maintainership over to Daniel, so I can be >> considered just a crank yelling from the sidelines :) > > I think you have a good point. Until we hear why MCT is needed this is > mostly speculation, so let's see what Kukjin says about that. Yea. And on x86 (well, i386 actually) there are system specific clocksources as well, such as the cyclone timer used by "summit" based x440 and similar NUMA systems, but those systems had more general config options that had to be enabled which the cyclone clocksource depended on. thanks -john ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-18 20:06 ` John Stultz 0 siblings, 0 replies; 82+ messages in thread From: John Stultz @ 2014-02-18 20:06 UTC (permalink / raw) To: linux-arm-kernel On Tue, Feb 18, 2014 at 12:00 PM, Olof Johansson <olof@lixom.net> wrote: > On Tue, Feb 18, 2014 at 11:52 AM, John Stultz <john.stultz@linaro.org> wrote: >> On Tue, Feb 18, 2014 at 10:13 AM, Arnd Bergmann <arnd@arndb.de> wrote: >>> On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: >>>> On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>>> > On 02/15/14 02:06, Arnd Bergmann wrote: >>>> >> My feeling is that we don't need to use the levels for Kconfig, although >>>> >> we might want to use them DT compatible strings, even if it ends up >>>> >> looking >>>> >> a little funny when you do >>>> >> >>>> >> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; >>>> >> >>>> >>> What kind of features are you expecting though? More IP >>>> >>> blocks/devices? Those are just kernel config options to enable, >>>> >>> ideally as modules. >>>> >> >>>> >> >>>> >> Right, I think we can just put them into defconfig. No need to >>>> >> "select" them from Kconfig since the extra options wouldn't be >>>> >> required for booting or using the system. >>>> >> >>>> > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, >>>> > it is not for used for GH7 though... >>>> >>>> It looks like the clocksource drivers are all based around being >>>> enabled based on platforms instead of individually selectable. That >>>> causes a problem here. I think we should change the clocksource >>>> Kconfig instead. Then it's just a matter of making sure your defconfig >>>> has the needed driver enabled. >>>> >>>> (Adding Daniel and Thomas in case they have objections to that approach) >>> >>> +John Stultz >>> >>> IIRC it was John who insisted on doing it the current way, although >>> I can't remember his reasoning. >> >> Are we really expecting there to be SoC specific clocksources here? I >> thought we were getting away from that sort of stuff with the >> architecture timer? > > Unfortunately vendors can do crazy stuff if they want to. But we also > have an option to choose to enable it. Maybe the answer here is to say > no to MCT on 64-bit, they get to use the arch timers like everybody > else. Or at least motivate why they're not good enough. > >> I'm fine with clocksources being selected by other functionality >> options (ie: on x86 ACPI PM timer clocksource doesn't have a prompt, >> but depends on the ACPI option). I just don't want to force users to >> have to navigate through tons of deep menus to select clocksource >> options that logically duplicate other selections already made. >> >> But again, I handed this maintainership over to Daniel, so I can be >> considered just a crank yelling from the sidelines :) > > I think you have a good point. Until we hear why MCT is needed this is > mostly speculation, so let's see what Kukjin says about that. Yea. And on x86 (well, i386 actually) there are system specific clocksources as well, such as the cyclone timer used by "summit" based x440 and similar NUMA systems, but those systems had more general config options that had to be enabled which the cyclone clocksource depended on. thanks -john ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-18 20:06 ` John Stultz @ 2014-02-20 9:03 ` Olof Johansson -1 siblings, 0 replies; 82+ messages in thread From: Olof Johansson @ 2014-02-20 9:03 UTC (permalink / raw) To: John Stultz Cc: Arnd Bergmann, Kukjin Kim, linux-samsung-soc, Catalin Marinas, Ilho Lee, Thomas Abraham, Kumar Gala, linux-arm-kernel, Daniel Lezcano, Thomas Gleixner On Tue, Feb 18, 2014 at 12:06 PM, John Stultz <john.stultz@linaro.org> wrote: > On Tue, Feb 18, 2014 at 12:00 PM, Olof Johansson <olof@lixom.net> wrote: >> On Tue, Feb 18, 2014 at 11:52 AM, John Stultz <john.stultz@linaro.org> wrote: >>> On Tue, Feb 18, 2014 at 10:13 AM, Arnd Bergmann <arnd@arndb.de> wrote: >>>> On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: >>>>> On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>>>> > On 02/15/14 02:06, Arnd Bergmann wrote: >>>>> >> My feeling is that we don't need to use the levels for Kconfig, although >>>>> >> we might want to use them DT compatible strings, even if it ends up >>>>> >> looking >>>>> >> a little funny when you do >>>>> >> >>>>> >> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; >>>>> >> >>>>> >>> What kind of features are you expecting though? More IP >>>>> >>> blocks/devices? Those are just kernel config options to enable, >>>>> >>> ideally as modules. >>>>> >> >>>>> >> >>>>> >> Right, I think we can just put them into defconfig. No need to >>>>> >> "select" them from Kconfig since the extra options wouldn't be >>>>> >> required for booting or using the system. >>>>> >> >>>>> > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, >>>>> > it is not for used for GH7 though... >>>>> >>>>> It looks like the clocksource drivers are all based around being >>>>> enabled based on platforms instead of individually selectable. That >>>>> causes a problem here. I think we should change the clocksource >>>>> Kconfig instead. Then it's just a matter of making sure your defconfig >>>>> has the needed driver enabled. >>>>> >>>>> (Adding Daniel and Thomas in case they have objections to that approach) >>>> >>>> +John Stultz >>>> >>>> IIRC it was John who insisted on doing it the current way, although >>>> I can't remember his reasoning. >>> >>> Are we really expecting there to be SoC specific clocksources here? I >>> thought we were getting away from that sort of stuff with the >>> architecture timer? >> >> Unfortunately vendors can do crazy stuff if they want to. But we also >> have an option to choose to enable it. Maybe the answer here is to say >> no to MCT on 64-bit, they get to use the arch timers like everybody >> else. Or at least motivate why they're not good enough. >> >>> I'm fine with clocksources being selected by other functionality >>> options (ie: on x86 ACPI PM timer clocksource doesn't have a prompt, >>> but depends on the ACPI option). I just don't want to force users to >>> have to navigate through tons of deep menus to select clocksource >>> options that logically duplicate other selections already made. >>> >>> But again, I handed this maintainership over to Daniel, so I can be >>> considered just a crank yelling from the sidelines :) >> >> I think you have a good point. Until we hear why MCT is needed this is >> mostly speculation, so let's see what Kukjin says about that. > > Yea. And on x86 (well, i386 actually) there are system specific > clocksources as well, such as the cyclone timer used by "summit" based > x440 and similar NUMA systems, but those systems had more general > config options that had to be enabled which the cyclone clocksource > depended on. So, after giving this some more thought (and getting my hands dirty in some of this code), I think I'm going to change my mind on this. For mobile platforms I think it might make sense to bring over the toplevel platform Kconfig from arch/arm, to simplify dependencies without tearing up the driver subtree with churn like this. This, of course, only holds true for v8 mobile platforms. Samsung isn't saying if GH7 is a server platform and not, and they don't have to tell us. But I think we should consider only enabling and bringing over the mobile ones (and ideally try to avoid even that, but it might make sense to do some of them at least initially -- it does provide some convenient ways to enable larger subsets of default drivers per platform/vendor family). I.e. I'd be OK with an ARCH_EXYNOS/ARCH_TEGRA/ARCH_IMX/ARCH_<whatever>, but I don't think we should add more finegrained options than that globally on ARM64, at least not until truly proven to be needed. We're trying to push back against new per-SoC Kconfig entries on 32-bit as well right now. -Olof ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-20 9:03 ` Olof Johansson 0 siblings, 0 replies; 82+ messages in thread From: Olof Johansson @ 2014-02-20 9:03 UTC (permalink / raw) To: linux-arm-kernel On Tue, Feb 18, 2014 at 12:06 PM, John Stultz <john.stultz@linaro.org> wrote: > On Tue, Feb 18, 2014 at 12:00 PM, Olof Johansson <olof@lixom.net> wrote: >> On Tue, Feb 18, 2014 at 11:52 AM, John Stultz <john.stultz@linaro.org> wrote: >>> On Tue, Feb 18, 2014 at 10:13 AM, Arnd Bergmann <arnd@arndb.de> wrote: >>>> On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: >>>>> On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>>>> > On 02/15/14 02:06, Arnd Bergmann wrote: >>>>> >> My feeling is that we don't need to use the levels for Kconfig, although >>>>> >> we might want to use them DT compatible strings, even if it ends up >>>>> >> looking >>>>> >> a little funny when you do >>>>> >> >>>>> >> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; >>>>> >> >>>>> >>> What kind of features are you expecting though? More IP >>>>> >>> blocks/devices? Those are just kernel config options to enable, >>>>> >>> ideally as modules. >>>>> >> >>>>> >> >>>>> >> Right, I think we can just put them into defconfig. No need to >>>>> >> "select" them from Kconfig since the extra options wouldn't be >>>>> >> required for booting or using the system. >>>>> >> >>>>> > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, >>>>> > it is not for used for GH7 though... >>>>> >>>>> It looks like the clocksource drivers are all based around being >>>>> enabled based on platforms instead of individually selectable. That >>>>> causes a problem here. I think we should change the clocksource >>>>> Kconfig instead. Then it's just a matter of making sure your defconfig >>>>> has the needed driver enabled. >>>>> >>>>> (Adding Daniel and Thomas in case they have objections to that approach) >>>> >>>> +John Stultz >>>> >>>> IIRC it was John who insisted on doing it the current way, although >>>> I can't remember his reasoning. >>> >>> Are we really expecting there to be SoC specific clocksources here? I >>> thought we were getting away from that sort of stuff with the >>> architecture timer? >> >> Unfortunately vendors can do crazy stuff if they want to. But we also >> have an option to choose to enable it. Maybe the answer here is to say >> no to MCT on 64-bit, they get to use the arch timers like everybody >> else. Or at least motivate why they're not good enough. >> >>> I'm fine with clocksources being selected by other functionality >>> options (ie: on x86 ACPI PM timer clocksource doesn't have a prompt, >>> but depends on the ACPI option). I just don't want to force users to >>> have to navigate through tons of deep menus to select clocksource >>> options that logically duplicate other selections already made. >>> >>> But again, I handed this maintainership over to Daniel, so I can be >>> considered just a crank yelling from the sidelines :) >> >> I think you have a good point. Until we hear why MCT is needed this is >> mostly speculation, so let's see what Kukjin says about that. > > Yea. And on x86 (well, i386 actually) there are system specific > clocksources as well, such as the cyclone timer used by "summit" based > x440 and similar NUMA systems, but those systems had more general > config options that had to be enabled which the cyclone clocksource > depended on. So, after giving this some more thought (and getting my hands dirty in some of this code), I think I'm going to change my mind on this. For mobile platforms I think it might make sense to bring over the toplevel platform Kconfig from arch/arm, to simplify dependencies without tearing up the driver subtree with churn like this. This, of course, only holds true for v8 mobile platforms. Samsung isn't saying if GH7 is a server platform and not, and they don't have to tell us. But I think we should consider only enabling and bringing over the mobile ones (and ideally try to avoid even that, but it might make sense to do some of them at least initially -- it does provide some convenient ways to enable larger subsets of default drivers per platform/vendor family). I.e. I'd be OK with an ARCH_EXYNOS/ARCH_TEGRA/ARCH_IMX/ARCH_<whatever>, but I don't think we should add more finegrained options than that globally on ARM64, at least not until truly proven to be needed. We're trying to push back against new per-SoC Kconfig entries on 32-bit as well right now. -Olof ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-20 9:03 ` Olof Johansson @ 2014-02-20 11:22 ` Catalin Marinas -1 siblings, 0 replies; 82+ messages in thread From: Catalin Marinas @ 2014-02-20 11:22 UTC (permalink / raw) To: Olof Johansson Cc: John Stultz, Arnd Bergmann, Kukjin Kim, linux-samsung-soc, Ilho Lee, Thomas Abraham, Kumar Gala, linux-arm-kernel, Daniel Lezcano, Thomas Gleixner On Thu, Feb 20, 2014 at 09:03:30AM +0000, Olof Johansson wrote: > So, after giving this some more thought (and getting my hands dirty in > some of this code), I think I'm going to change my mind on this. For > mobile platforms I think it might make sense to bring over the > toplevel platform Kconfig from arch/arm, to simplify dependencies > without tearing up the driver subtree with churn like this. > > This, of course, only holds true for v8 mobile platforms. Samsung > isn't saying if GH7 is a server platform and not, and they don't have > to tell us. But I think we should consider only enabling and bringing > over the mobile ones (and ideally try to avoid even that, but it might > make sense to do some of them at least initially -- it does provide > some convenient ways to enable larger subsets of default drivers per > platform/vendor family). > > I.e. I'd be OK with an > ARCH_EXYNOS/ARCH_TEGRA/ARCH_IMX/ARCH_<whatever>, but I don't think we > should add more finegrained options than that globally on ARM64, at > least not until truly proven to be needed. We're trying to push back > against new per-SoC Kconfig entries on 32-bit as well right now. I'm fine with this. Do we still need something for ARMv8 server platforms like ARCH_ARM_SBSA? The only advantage would be to make it easier for mobile targeted kernel builds to disable server features but I'm not sure there are so many such features, people can trim the .config manually. Two additional points: 1. Single arm64 defconfig file covering everything 2. Modules rather than built-in by default where possible (especially for server platforms) -- Catalin ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-20 11:22 ` Catalin Marinas 0 siblings, 0 replies; 82+ messages in thread From: Catalin Marinas @ 2014-02-20 11:22 UTC (permalink / raw) To: linux-arm-kernel On Thu, Feb 20, 2014 at 09:03:30AM +0000, Olof Johansson wrote: > So, after giving this some more thought (and getting my hands dirty in > some of this code), I think I'm going to change my mind on this. For > mobile platforms I think it might make sense to bring over the > toplevel platform Kconfig from arch/arm, to simplify dependencies > without tearing up the driver subtree with churn like this. > > This, of course, only holds true for v8 mobile platforms. Samsung > isn't saying if GH7 is a server platform and not, and they don't have > to tell us. But I think we should consider only enabling and bringing > over the mobile ones (and ideally try to avoid even that, but it might > make sense to do some of them at least initially -- it does provide > some convenient ways to enable larger subsets of default drivers per > platform/vendor family). > > I.e. I'd be OK with an > ARCH_EXYNOS/ARCH_TEGRA/ARCH_IMX/ARCH_<whatever>, but I don't think we > should add more finegrained options than that globally on ARM64, at > least not until truly proven to be needed. We're trying to push back > against new per-SoC Kconfig entries on 32-bit as well right now. I'm fine with this. Do we still need something for ARMv8 server platforms like ARCH_ARM_SBSA? The only advantage would be to make it easier for mobile targeted kernel builds to disable server features but I'm not sure there are so many such features, people can trim the .config manually. Two additional points: 1. Single arm64 defconfig file covering everything 2. Modules rather than built-in by default where possible (especially for server platforms) -- Catalin ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-20 11:22 ` Catalin Marinas @ 2014-02-20 12:07 ` Arnd Bergmann -1 siblings, 0 replies; 82+ messages in thread From: Arnd Bergmann @ 2014-02-20 12:07 UTC (permalink / raw) To: Catalin Marinas Cc: Olof Johansson, John Stultz, Kukjin Kim, linux-samsung-soc, Ilho Lee, Thomas Abraham, Kumar Gala, linux-arm-kernel, Daniel Lezcano, Thomas Gleixner On Thursday 20 February 2014 11:22:48 Catalin Marinas wrote: > > I'm fine with this. Do we still need something for ARMv8 server > platforms like ARCH_ARM_SBSA? The only advantage would be to make it > easier for mobile targeted kernel builds to disable server features but > I'm not sure there are so many such features, people can trim the > .config manually. I think in particular for SBSA compliant platforms we should not have per-platform options at all the way we do for embedded, as they will be much more homogenous. > Two additional points: > > 1. Single arm64 defconfig file covering everything > 2. Modules rather than built-in by default where possible (especially > for server platforms) +1 Arnd ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-20 12:07 ` Arnd Bergmann 0 siblings, 0 replies; 82+ messages in thread From: Arnd Bergmann @ 2014-02-20 12:07 UTC (permalink / raw) To: linux-arm-kernel On Thursday 20 February 2014 11:22:48 Catalin Marinas wrote: > > I'm fine with this. Do we still need something for ARMv8 server > platforms like ARCH_ARM_SBSA? The only advantage would be to make it > easier for mobile targeted kernel builds to disable server features but > I'm not sure there are so many such features, people can trim the > .config manually. I think in particular for SBSA compliant platforms we should not have per-platform options at all the way we do for embedded, as they will be much more homogenous. > Two additional points: > > 1. Single arm64 defconfig file covering everything > 2. Modules rather than built-in by default where possible (especially > for server platforms) +1 Arnd ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-20 11:22 ` Catalin Marinas @ 2014-02-20 17:09 ` Olof Johansson -1 siblings, 0 replies; 82+ messages in thread From: Olof Johansson @ 2014-02-20 17:09 UTC (permalink / raw) To: Catalin Marinas Cc: John Stultz, Arnd Bergmann, Kukjin Kim, linux-samsung-soc, Ilho Lee, Thomas Abraham, Kumar Gala, linux-arm-kernel, Daniel Lezcano, Thomas Gleixner On Thu, Feb 20, 2014 at 3:22 AM, Catalin Marinas <catalin.marinas@arm.com> wrote: > On Thu, Feb 20, 2014 at 09:03:30AM +0000, Olof Johansson wrote: >> So, after giving this some more thought (and getting my hands dirty in >> some of this code), I think I'm going to change my mind on this. For >> mobile platforms I think it might make sense to bring over the >> toplevel platform Kconfig from arch/arm, to simplify dependencies >> without tearing up the driver subtree with churn like this. >> >> This, of course, only holds true for v8 mobile platforms. Samsung >> isn't saying if GH7 is a server platform and not, and they don't have >> to tell us. But I think we should consider only enabling and bringing >> over the mobile ones (and ideally try to avoid even that, but it might >> make sense to do some of them at least initially -- it does provide >> some convenient ways to enable larger subsets of default drivers per >> platform/vendor family). >> >> I.e. I'd be OK with an >> ARCH_EXYNOS/ARCH_TEGRA/ARCH_IMX/ARCH_<whatever>, but I don't think we >> should add more finegrained options than that globally on ARM64, at >> least not until truly proven to be needed. We're trying to push back >> against new per-SoC Kconfig entries on 32-bit as well right now. > > I'm fine with this. Do we still need something for ARMv8 server > platforms like ARCH_ARM_SBSA? The only advantage would be to make it > easier for mobile targeted kernel builds to disable server features but > I'm not sure there are so many such features, people can trim the > .config manually. I don't think there's all that much that's unique to SBSA for a Kconfig entry. If anything it could be useful to describe dependencies (i.e. you very likely don't want to turn off the standardized UART driver, etc). But doing that through Kconfig is a bit clumsy, we might be better off doing it through example defconfigs. I'm not sure we want to do it through selects. > Two additional points: > > 1. Single arm64 defconfig file covering everything > 2. Modules rather than built-in by default where possible (especially > for server platforms) Sounds good to me. Are you also willing to pick up one defconfig per vendor (but not more)? I think it's been useful to have those on arm, even on multiplatform kernels. We used them on powerpc as well, where we had a two-layer approach (ppc64_defconfig and per-platform configs, pseries/iseries/pasemi/g5/cell). -Olof ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-20 17:09 ` Olof Johansson 0 siblings, 0 replies; 82+ messages in thread From: Olof Johansson @ 2014-02-20 17:09 UTC (permalink / raw) To: linux-arm-kernel On Thu, Feb 20, 2014 at 3:22 AM, Catalin Marinas <catalin.marinas@arm.com> wrote: > On Thu, Feb 20, 2014 at 09:03:30AM +0000, Olof Johansson wrote: >> So, after giving this some more thought (and getting my hands dirty in >> some of this code), I think I'm going to change my mind on this. For >> mobile platforms I think it might make sense to bring over the >> toplevel platform Kconfig from arch/arm, to simplify dependencies >> without tearing up the driver subtree with churn like this. >> >> This, of course, only holds true for v8 mobile platforms. Samsung >> isn't saying if GH7 is a server platform and not, and they don't have >> to tell us. But I think we should consider only enabling and bringing >> over the mobile ones (and ideally try to avoid even that, but it might >> make sense to do some of them at least initially -- it does provide >> some convenient ways to enable larger subsets of default drivers per >> platform/vendor family). >> >> I.e. I'd be OK with an >> ARCH_EXYNOS/ARCH_TEGRA/ARCH_IMX/ARCH_<whatever>, but I don't think we >> should add more finegrained options than that globally on ARM64, at >> least not until truly proven to be needed. We're trying to push back >> against new per-SoC Kconfig entries on 32-bit as well right now. > > I'm fine with this. Do we still need something for ARMv8 server > platforms like ARCH_ARM_SBSA? The only advantage would be to make it > easier for mobile targeted kernel builds to disable server features but > I'm not sure there are so many such features, people can trim the > .config manually. I don't think there's all that much that's unique to SBSA for a Kconfig entry. If anything it could be useful to describe dependencies (i.e. you very likely don't want to turn off the standardized UART driver, etc). But doing that through Kconfig is a bit clumsy, we might be better off doing it through example defconfigs. I'm not sure we want to do it through selects. > Two additional points: > > 1. Single arm64 defconfig file covering everything > 2. Modules rather than built-in by default where possible (especially > for server platforms) Sounds good to me. Are you also willing to pick up one defconfig per vendor (but not more)? I think it's been useful to have those on arm, even on multiplatform kernels. We used them on powerpc as well, where we had a two-layer approach (ppc64_defconfig and per-platform configs, pseries/iseries/pasemi/g5/cell). -Olof ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-20 17:09 ` Olof Johansson @ 2014-02-20 18:58 ` Catalin Marinas -1 siblings, 0 replies; 82+ messages in thread From: Catalin Marinas @ 2014-02-20 18:58 UTC (permalink / raw) To: Olof Johansson Cc: John Stultz, Arnd Bergmann, Kukjin Kim, linux-samsung-soc, Ilho Lee, Thomas Abraham, Kumar Gala, linux-arm-kernel, Daniel Lezcano, Thomas Gleixner On Thu, Feb 20, 2014 at 05:09:59PM +0000, Olof Johansson wrote: > On Thu, Feb 20, 2014 at 3:22 AM, Catalin Marinas > > Two additional points: > > > > 1. Single arm64 defconfig file covering everything > > 2. Modules rather than built-in by default where possible (especially > > for server platforms) > > Sounds good to me. Are you also willing to pick up one defconfig per > vendor (but not more)? I think it's been useful to have those on arm, > even on multiplatform kernels. We used them on powerpc as well, where > we had a two-layer approach (ppc64_defconfig and per-platform configs, > pseries/iseries/pasemi/g5/cell). Initially I would keep a single defconfig with everything just to get wider coverage of single Image. Later on, if just deselecting config entries doesn't work, we can revisit per-vendor defconfigs. -- Catalin ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-20 18:58 ` Catalin Marinas 0 siblings, 0 replies; 82+ messages in thread From: Catalin Marinas @ 2014-02-20 18:58 UTC (permalink / raw) To: linux-arm-kernel On Thu, Feb 20, 2014 at 05:09:59PM +0000, Olof Johansson wrote: > On Thu, Feb 20, 2014 at 3:22 AM, Catalin Marinas > > Two additional points: > > > > 1. Single arm64 defconfig file covering everything > > 2. Modules rather than built-in by default where possible (especially > > for server platforms) > > Sounds good to me. Are you also willing to pick up one defconfig per > vendor (but not more)? I think it's been useful to have those on arm, > even on multiplatform kernels. We used them on powerpc as well, where > we had a two-layer approach (ppc64_defconfig and per-platform configs, > pseries/iseries/pasemi/g5/cell). Initially I would keep a single defconfig with everything just to get wider coverage of single Image. Later on, if just deselecting config entries doesn't work, we can revisit per-vendor defconfigs. -- Catalin ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-20 18:58 ` Catalin Marinas @ 2014-02-25 0:19 ` Kukjin Kim -1 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-25 0:19 UTC (permalink / raw) To: Catalin Marinas Cc: Olof Johansson, John Stultz, Arnd Bergmann, Kukjin Kim, linux-samsung-soc, Ilho Lee, Thomas Abraham, Kumar Gala, linux-arm-kernel, Daniel Lezcano, Thomas Gleixner On 02/21/14 03:58, Catalin Marinas wrote: > On Thu, Feb 20, 2014 at 05:09:59PM +0000, Olof Johansson wrote: >> On Thu, Feb 20, 2014 at 3:22 AM, Catalin Marinas >>> Two additional points: >>> >>> 1. Single arm64 defconfig file covering everything >>> 2. Modules rather than built-in by default where possible (especially >>> for server platforms) >> >> Sounds good to me. Are you also willing to pick up one defconfig per >> vendor (but not more)? I think it's been useful to have those on arm, >> even on multiplatform kernels. We used them on powerpc as well, where >> we had a two-layer approach (ppc64_defconfig and per-platform configs, >> pseries/iseries/pasemi/g5/cell). > > Initially I would keep a single defconfig with everything just to get > wider coverage of single Image. Later on, if just deselecting config > entries doesn't work, we can revisit per-vendor defconfigs. > OK, agreed with single defconfig on ARMv8 for now. And as Olof said, it's expected that each vendor maybe needs to use per-vendor defconfig soon and agreed too :-) Thanks, Kukjin ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-25 0:19 ` Kukjin Kim 0 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-25 0:19 UTC (permalink / raw) To: linux-arm-kernel On 02/21/14 03:58, Catalin Marinas wrote: > On Thu, Feb 20, 2014 at 05:09:59PM +0000, Olof Johansson wrote: >> On Thu, Feb 20, 2014 at 3:22 AM, Catalin Marinas >>> Two additional points: >>> >>> 1. Single arm64 defconfig file covering everything >>> 2. Modules rather than built-in by default where possible (especially >>> for server platforms) >> >> Sounds good to me. Are you also willing to pick up one defconfig per >> vendor (but not more)? I think it's been useful to have those on arm, >> even on multiplatform kernels. We used them on powerpc as well, where >> we had a two-layer approach (ppc64_defconfig and per-platform configs, >> pseries/iseries/pasemi/g5/cell). > > Initially I would keep a single defconfig with everything just to get > wider coverage of single Image. Later on, if just deselecting config > entries doesn't work, we can revisit per-vendor defconfigs. > OK, agreed with single defconfig on ARMv8 for now. And as Olof said, it's expected that each vendor maybe needs to use per-vendor defconfig soon and agreed too :-) Thanks, Kukjin ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-20 9:03 ` Olof Johansson @ 2014-02-25 0:20 ` Kukjin Kim -1 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-25 0:20 UTC (permalink / raw) To: Olof Johansson Cc: John Stultz, linux-samsung-soc, Arnd Bergmann, Catalin Marinas, Daniel Lezcano, Ilho Lee, Thomas Abraham, Kumar Gala, Kukjin Kim, Thomas Gleixner, linux-arm-kernel On 02/20/14 18:03, Olof Johansson wrote: [...] > > I.e. I'd be OK with an > ARCH_EXYNOS/ARCH_TEGRA/ARCH_IMX/ARCH_<whatever>, but I don't think we > should add more finegrained options than that globally on ARM64, at > least not until truly proven to be needed. We're trying to push back > against new per-SoC Kconfig entries on 32-bit as well right now. > OK, agreed. - Kukjin ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-25 0:20 ` Kukjin Kim 0 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-25 0:20 UTC (permalink / raw) To: linux-arm-kernel On 02/20/14 18:03, Olof Johansson wrote: [...] > > I.e. I'd be OK with an > ARCH_EXYNOS/ARCH_TEGRA/ARCH_IMX/ARCH_<whatever>, but I don't think we > should add more finegrained options than that globally on ARM64, at > least not until truly proven to be needed. We're trying to push back > against new per-SoC Kconfig entries on 32-bit as well right now. > OK, agreed. - Kukjin ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-18 20:00 ` Olof Johansson @ 2014-02-25 0:10 ` Kukjin Kim -1 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-25 0:10 UTC (permalink / raw) To: Olof Johansson Cc: John Stultz, linux-samsung-soc, Arnd Bergmann, Catalin Marinas, Daniel Lezcano, Ilho Lee, Thomas Abraham, Kumar Gala, Kukjin Kim, Thomas Gleixner, linux-arm-kernel On 02/19/14 05:00, Olof Johansson wrote: > On Tue, Feb 18, 2014 at 11:52 AM, John Stultz<john.stultz@linaro.org> wrote: >> On Tue, Feb 18, 2014 at 10:13 AM, Arnd Bergmann<arnd@arndb.de> wrote: >>> On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: >>>> On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim<kgene.kim@samsung.com> wrote: >>>>> On 02/15/14 02:06, Arnd Bergmann wrote: >>>>>> My feeling is that we don't need to use the levels for Kconfig, although >>>>>> we might want to use them DT compatible strings, even if it ends up >>>>>> looking >>>>>> a little funny when you do >>>>>> >>>>>> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; >>>>>> >>>>>>> What kind of features are you expecting though? More IP >>>>>>> blocks/devices? Those are just kernel config options to enable, >>>>>>> ideally as modules. >>>>>> >>>>>> >>>>>> Right, I think we can just put them into defconfig. No need to >>>>>> "select" them from Kconfig since the extra options wouldn't be >>>>>> required for booting or using the system. >>>>>> >>>>> As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, >>>>> it is not for used for GH7 though... >>>> >>>> It looks like the clocksource drivers are all based around being >>>> enabled based on platforms instead of individually selectable. That >>>> causes a problem here. I think we should change the clocksource >>>> Kconfig instead. Then it's just a matter of making sure your defconfig >>>> has the needed driver enabled. >>>> >>>> (Adding Daniel and Thomas in case they have objections to that approach) >>> >>> +John Stultz >>> >>> IIRC it was John who insisted on doing it the current way, although >>> I can't remember his reasoning. >> >> Are we really expecting there to be SoC specific clocksources here? I >> thought we were getting away from that sort of stuff with the >> architecture timer? > > Unfortunately vendors can do crazy stuff if they want to. But we also > have an option to choose to enable it. Maybe the answer here is to say > no to MCT on 64-bit, they get to use the arch timers like everybody > else. Or at least motivate why they're not good enough. > >> I'm fine with clocksources being selected by other functionality >> options (ie: on x86 ACPI PM timer clocksource doesn't have a prompt, >> but depends on the ACPI option). I just don't want to force users to >> have to navigate through tons of deep menus to select clocksource >> options that logically duplicate other selections already made. >> >> But again, I handed this maintainership over to Daniel, so I can be >> considered just a crank yelling from the sidelines :) > > I think you have a good point. Until we hear why MCT is needed this is > mostly speculation, so let's see what Kukjin says about that. > Using MCT on ARMv8 is an example, it's true on some Samsung ARMv8 SoC though. I don't want to argue what's the benefit of MCT in this thread, but just possibility. As you know, generally ARM SoC vendor is open to use any IPs...So I'd like to say we need to consider the situation. Anyway, basically I agree with you guys suggestion to use common CONFIG on ARMv8 like multiplatform supporting on arm32. Thanks, Kukji ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-25 0:10 ` Kukjin Kim 0 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-25 0:10 UTC (permalink / raw) To: linux-arm-kernel On 02/19/14 05:00, Olof Johansson wrote: > On Tue, Feb 18, 2014 at 11:52 AM, John Stultz<john.stultz@linaro.org> wrote: >> On Tue, Feb 18, 2014 at 10:13 AM, Arnd Bergmann<arnd@arndb.de> wrote: >>> On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: >>>> On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim<kgene.kim@samsung.com> wrote: >>>>> On 02/15/14 02:06, Arnd Bergmann wrote: >>>>>> My feeling is that we don't need to use the levels for Kconfig, although >>>>>> we might want to use them DT compatible strings, even if it ends up >>>>>> looking >>>>>> a little funny when you do >>>>>> >>>>>> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; >>>>>> >>>>>>> What kind of features are you expecting though? More IP >>>>>>> blocks/devices? Those are just kernel config options to enable, >>>>>>> ideally as modules. >>>>>> >>>>>> >>>>>> Right, I think we can just put them into defconfig. No need to >>>>>> "select" them from Kconfig since the extra options wouldn't be >>>>>> required for booting or using the system. >>>>>> >>>>> As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, >>>>> it is not for used for GH7 though... >>>> >>>> It looks like the clocksource drivers are all based around being >>>> enabled based on platforms instead of individually selectable. That >>>> causes a problem here. I think we should change the clocksource >>>> Kconfig instead. Then it's just a matter of making sure your defconfig >>>> has the needed driver enabled. >>>> >>>> (Adding Daniel and Thomas in case they have objections to that approach) >>> >>> +John Stultz >>> >>> IIRC it was John who insisted on doing it the current way, although >>> I can't remember his reasoning. >> >> Are we really expecting there to be SoC specific clocksources here? I >> thought we were getting away from that sort of stuff with the >> architecture timer? > > Unfortunately vendors can do crazy stuff if they want to. But we also > have an option to choose to enable it. Maybe the answer here is to say > no to MCT on 64-bit, they get to use the arch timers like everybody > else. Or at least motivate why they're not good enough. > >> I'm fine with clocksources being selected by other functionality >> options (ie: on x86 ACPI PM timer clocksource doesn't have a prompt, >> but depends on the ACPI option). I just don't want to force users to >> have to navigate through tons of deep menus to select clocksource >> options that logically duplicate other selections already made. >> >> But again, I handed this maintainership over to Daniel, so I can be >> considered just a crank yelling from the sidelines :) > > I think you have a good point. Until we hear why MCT is needed this is > mostly speculation, so let's see what Kukjin says about that. > Using MCT on ARMv8 is an example, it's true on some Samsung ARMv8 SoC though. I don't want to argue what's the benefit of MCT in this thread, but just possibility. As you know, generally ARM SoC vendor is open to use any IPs...So I'd like to say we need to consider the situation. Anyway, basically I agree with you guys suggestion to use common CONFIG on ARMv8 like multiplatform supporting on arm32. Thanks, Kukji ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-18 1:10 ` Kukjin Kim @ 2014-02-18 16:40 ` Catalin Marinas -1 siblings, 0 replies; 82+ messages in thread From: Catalin Marinas @ 2014-02-18 16:40 UTC (permalink / raw) To: Kukjin Kim Cc: Arnd Bergmann, Olof Johansson, linux-samsung-soc, Ilho Lee, Thomas Abraham, Kumar Gala, linux-arm-kernel On Tue, Feb 18, 2014 at 01:10:30AM +0000, Kukjin Kim wrote: > As I commented above, how about MCT? Samsung has a plan to use MCT on > ARMv8, it is not for used for GH7 though... Any reason for not using the generic timer? -- Catalin ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-18 16:40 ` Catalin Marinas 0 siblings, 0 replies; 82+ messages in thread From: Catalin Marinas @ 2014-02-18 16:40 UTC (permalink / raw) To: linux-arm-kernel On Tue, Feb 18, 2014 at 01:10:30AM +0000, Kukjin Kim wrote: > As I commented above, how about MCT? Samsung has a plan to use MCT on > ARMv8, it is not for used for GH7 though... Any reason for not using the generic timer? -- Catalin ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-11 23:39 ` Olof Johansson @ 2014-02-13 20:08 ` Rob Herring -1 siblings, 0 replies; 82+ messages in thread From: Rob Herring @ 2014-02-13 20:08 UTC (permalink / raw) To: Olof Johansson Cc: Kukjin Kim, Thomas Abraham, Catalin Marinas, linux-samsung-soc, Ilho Lee, linux-arm-kernel On Tue, Feb 11, 2014 at 5:39 PM, Olof Johansson <olof@lixom.net> wrote: > On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >> This patch adds support for Samsung GH7 SoC in arm64/Kconfig. >> >> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> >> Cc: Catalin Marinas <catalin.marinas@arm.com> > > The overhead of building one more device tree isn't very large, and I > don't see any other need to have a Kconfig entry per SoC at this time. > It's of course up to Catalin, but you might just want to always > compile all dts files instead. I think having "make dtbs" build all regardless of the config would be better. Perhaps a "all_dtbs" target could be added and everyone can get what they want. If/when we add checking into dtc, this we certainly become more desirable. Rob ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-13 20:08 ` Rob Herring 0 siblings, 0 replies; 82+ messages in thread From: Rob Herring @ 2014-02-13 20:08 UTC (permalink / raw) To: linux-arm-kernel On Tue, Feb 11, 2014 at 5:39 PM, Olof Johansson <olof@lixom.net> wrote: > On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >> This patch adds support for Samsung GH7 SoC in arm64/Kconfig. >> >> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> >> Cc: Catalin Marinas <catalin.marinas@arm.com> > > The overhead of building one more device tree isn't very large, and I > don't see any other need to have a Kconfig entry per SoC at this time. > It's of course up to Catalin, but you might just want to always > compile all dts files instead. I think having "make dtbs" build all regardless of the config would be better. Perhaps a "all_dtbs" target could be added and everyone can get what they want. If/when we add checking into dtc, this we certainly become more desirable. Rob ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family 2014-02-13 20:08 ` Rob Herring @ 2014-02-13 20:19 ` Olof Johansson -1 siblings, 0 replies; 82+ messages in thread From: Olof Johansson @ 2014-02-13 20:19 UTC (permalink / raw) To: Rob Herring Cc: Kukjin Kim, Catalin Marinas, Ilho Lee, linux-samsung-soc, Thomas Abraham, linux-arm-kernel On Thu, Feb 13, 2014 at 12:08 PM, Rob Herring <robherring2@gmail.com> wrote: > On Tue, Feb 11, 2014 at 5:39 PM, Olof Johansson <olof@lixom.net> wrote: >> On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>> This patch adds support for Samsung GH7 SoC in arm64/Kconfig. >>> >>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> >>> Cc: Catalin Marinas <catalin.marinas@arm.com> >> >> The overhead of building one more device tree isn't very large, and I >> don't see any other need to have a Kconfig entry per SoC at this time. >> It's of course up to Catalin, but you might just want to always >> compile all dts files instead. > > I think having "make dtbs" build all regardless of the config would be > better. We can do that too, but that doesn't mean it's useful to have this kconfig entry. > Perhaps a "all_dtbs" target could be added and everyone can > get what they want. If/when we add checking into dtc, this we > certainly become more desirable. -Olof ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family @ 2014-02-13 20:19 ` Olof Johansson 0 siblings, 0 replies; 82+ messages in thread From: Olof Johansson @ 2014-02-13 20:19 UTC (permalink / raw) To: linux-arm-kernel On Thu, Feb 13, 2014 at 12:08 PM, Rob Herring <robherring2@gmail.com> wrote: > On Tue, Feb 11, 2014 at 5:39 PM, Olof Johansson <olof@lixom.net> wrote: >> On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>> This patch adds support for Samsung GH7 SoC in arm64/Kconfig. >>> >>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> >>> Cc: Catalin Marinas <catalin.marinas@arm.com> >> >> The overhead of building one more device tree isn't very large, and I >> don't see any other need to have a Kconfig entry per SoC at this time. >> It's of course up to Catalin, but you might just want to always >> compile all dts files instead. > > I think having "make dtbs" build all regardless of the config would be > better. We can do that too, but that doesn't mean it's useful to have this kconfig entry. > Perhaps a "all_dtbs" target could be added and everyone can > get what they want. If/when we add checking into dtc, this we > certainly become more desirable. -Olof ^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH 3/3] Documentation: DT: add new entry for Samsung GH7 SoC and SSDK board 2014-02-11 6:29 ` Kukjin Kim @ 2014-02-11 6:29 ` Kukjin Kim -1 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-11 6:29 UTC (permalink / raw) To: linux-arm-kernel, linux-samsung-soc Cc: Ilho Lee, Thomas Abraham, Kukjin Kim, Catalin Marinas Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Reviewed-by: Thomas Abraham <thomas.ab@samsung.com> Cc: Catalin Marinas <catalin.marinas@arm.com> --- Documentation/devicetree/bindings/arm/samsung-boards.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung-boards.txt index 2168ed3..9284db3 100644 --- a/Documentation/devicetree/bindings/arm/samsung-boards.txt +++ b/Documentation/devicetree/bindings/arm/samsung-boards.txt @@ -16,3 +16,13 @@ Optional: compatible = "samsung,secure-firmware"; reg = <0x0203F000 0x1000>; }; + +* Samsung's GH7 based SSDK-GH7 evaluation board + +SSDK-GH7 evaluation board is based on Samsung's GH7 SoC which has ARMv8 cores. + +Required root node properties: + - compatible = should be one or more of the following. + (a) "samsung,ssdk-gh7" - for Samsung's SSDK-GH7 eval board. + (b) "samsung,gh7" - for boards based on GH7 SoC. + -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH 3/3] Documentation: DT: add new entry for Samsung GH7 SoC and SSDK board @ 2014-02-11 6:29 ` Kukjin Kim 0 siblings, 0 replies; 82+ messages in thread From: Kukjin Kim @ 2014-02-11 6:29 UTC (permalink / raw) To: linux-arm-kernel Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Reviewed-by: Thomas Abraham <thomas.ab@samsung.com> Cc: Catalin Marinas <catalin.marinas@arm.com> --- Documentation/devicetree/bindings/arm/samsung-boards.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung-boards.txt index 2168ed3..9284db3 100644 --- a/Documentation/devicetree/bindings/arm/samsung-boards.txt +++ b/Documentation/devicetree/bindings/arm/samsung-boards.txt @@ -16,3 +16,13 @@ Optional: compatible = "samsung,secure-firmware"; reg = <0x0203F000 0x1000>; }; + +* Samsung's GH7 based SSDK-GH7 evaluation board + +SSDK-GH7 evaluation board is based on Samsung's GH7 SoC which has ARMv8 cores. + +Required root node properties: + - compatible = should be one or more of the following. + (a) "samsung,ssdk-gh7" - for Samsung's SSDK-GH7 eval board. + (b) "samsung,gh7" - for boards based on GH7 SoC. + -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 82+ messages in thread
end of thread, other threads:[~2014-02-25 0:21 UTC | newest] Thread overview: 82+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-02-11 6:29 [PATCH 0/3] arm64: add new support Samsung GH7 SoC and SSDK board Kukjin Kim 2014-02-11 6:29 ` Kukjin Kim 2014-02-11 6:29 ` [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board Kukjin Kim 2014-02-11 6:29 ` Kukjin Kim 2014-02-11 18:15 ` Mark Rutland 2014-02-11 18:15 ` Mark Rutland 2014-02-11 3:16 ` Kukjin Kim 2014-02-11 3:16 ` Kukjin Kim 2014-02-18 10:30 ` Mark Rutland 2014-02-18 10:30 ` Mark Rutland 2014-02-24 23:56 ` Kukjin Kim 2014-02-24 23:56 ` Kukjin Kim 2014-02-11 23:36 ` Olof Johansson 2014-02-11 23:36 ` Olof Johansson 2014-02-11 3:25 ` Kukjin Kim 2014-02-11 3:25 ` Kukjin Kim 2014-02-12 11:13 ` Marc Zyngier 2014-02-12 11:13 ` Marc Zyngier 2014-02-12 11:29 ` Mark Rutland 2014-02-12 11:29 ` Mark Rutland 2014-02-12 11:40 ` Marc Zyngier 2014-02-12 11:40 ` Marc Zyngier 2014-02-11 3:03 ` Kukjin Kim 2014-02-11 3:03 ` Kukjin Kim 2014-02-11 6:29 ` [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family Kukjin Kim 2014-02-11 6:29 ` Kukjin Kim 2014-02-11 23:39 ` Olof Johansson 2014-02-11 23:39 ` Olof Johansson 2014-02-12 10:38 ` Catalin Marinas 2014-02-12 10:38 ` Catalin Marinas 2014-02-12 16:25 ` Kumar Gala 2014-02-12 16:25 ` Kumar Gala 2014-02-12 18:12 ` Catalin Marinas 2014-02-12 18:12 ` Catalin Marinas 2014-02-12 19:04 ` Kumar Gala 2014-02-12 19:04 ` Kumar Gala 2014-02-12 19:14 ` Arnd Bergmann 2014-02-12 19:14 ` Arnd Bergmann 2014-02-11 2:52 ` Kukjin Kim 2014-02-11 2:52 ` Kukjin Kim 2014-02-13 19:26 ` Olof Johansson 2014-02-13 19:26 ` Olof Johansson 2014-02-14 17:06 ` Arnd Bergmann 2014-02-14 17:06 ` Arnd Bergmann 2014-02-18 1:10 ` Kukjin Kim 2014-02-18 1:10 ` Kukjin Kim 2014-02-18 10:53 ` Arnd Bergmann 2014-02-18 10:53 ` Arnd Bergmann 2014-02-18 16:16 ` Olof Johansson 2014-02-18 16:16 ` Olof Johansson 2014-02-18 18:13 ` Arnd Bergmann 2014-02-18 18:13 ` Arnd Bergmann 2014-02-18 19:52 ` John Stultz 2014-02-18 19:52 ` John Stultz 2014-02-18 20:00 ` Olof Johansson 2014-02-18 20:00 ` Olof Johansson 2014-02-18 20:06 ` John Stultz 2014-02-18 20:06 ` John Stultz 2014-02-20 9:03 ` Olof Johansson 2014-02-20 9:03 ` Olof Johansson 2014-02-20 11:22 ` Catalin Marinas 2014-02-20 11:22 ` Catalin Marinas 2014-02-20 12:07 ` Arnd Bergmann 2014-02-20 12:07 ` Arnd Bergmann 2014-02-20 17:09 ` Olof Johansson 2014-02-20 17:09 ` Olof Johansson 2014-02-20 18:58 ` Catalin Marinas 2014-02-20 18:58 ` Catalin Marinas 2014-02-25 0:19 ` Kukjin Kim 2014-02-25 0:19 ` Kukjin Kim 2014-02-25 0:20 ` Kukjin Kim 2014-02-25 0:20 ` Kukjin Kim 2014-02-25 0:10 ` Kukjin Kim 2014-02-25 0:10 ` Kukjin Kim 2014-02-18 16:40 ` Catalin Marinas 2014-02-18 16:40 ` Catalin Marinas 2014-02-13 20:08 ` Rob Herring 2014-02-13 20:08 ` Rob Herring 2014-02-13 20:19 ` Olof Johansson 2014-02-13 20:19 ` Olof Johansson 2014-02-11 6:29 ` [PATCH 3/3] Documentation: DT: add new entry for Samsung GH7 SoC and SSDK board Kukjin Kim 2014-02-11 6:29 ` Kukjin Kim
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.