[PATCH 0/3] arm64: add new support Samsung GH7 SoC and SSDK board

[PATCH 0/3] arm64: add new support Samsung GH7 SoC and SSDK board

[Kukjin Kim]

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

[PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board

[Kukjin Kim]

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

[PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board

[Mark Rutland]

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.

[PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board

[Kukjin Kim]

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

[PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board

[Mark Rutland]

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.

[PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board

[Kukjin Kim]

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

[PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board

[Olof Johansson]

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

[PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board

[Kukjin Kim]

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

[PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board

[Marc Zyngier]

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...

[PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board

[Mark Rutland]

> >> +       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.

[PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board

[Marc Zyngier]

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...

[PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board

[Kukjin Kim]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Kukjin Kim]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Olof Johansson]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Catalin Marinas]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Kumar Gala]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Catalin Marinas]

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).

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Kumar Gala]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Arnd Bergmann]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Olof Johansson]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Arnd Bergmann]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Kukjin Kim]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Arnd Bergmann]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Olof Johansson]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Arnd Bergmann]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[John Stultz]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Olof Johansson]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[John Stultz]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Olof Johansson]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Catalin Marinas]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Arnd Bergmann]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Olof Johansson]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Catalin Marinas]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Kukjin Kim]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Kukjin Kim]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Kukjin Kim]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Catalin Marinas]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Rob Herring]

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

[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Olof Johansson]

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

[PATCH 3/3] Documentation: DT: add new entry for Samsung GH7 SoC and SSDK board

[Kukjin Kim]

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