From: Suravee Suthikulpanit <[email protected]>
Initial revision of device tree for AMD Seattle platform
Cc: Mark Rutland <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Rob Herring <[email protected]>
Signed-off-by: Suravee Suthikulpanit <[email protected]>
Signed-off-by: Thomas Lendacky <[email protected]>
Signed-off-by: Joel Schopp <[email protected]>
---
arch/arm64/Kconfig | 5 +
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/amd-seattle-periph.dtsi | 164 ++++++++++++++++++++++++++++
arch/arm64/boot/dts/amd-seattle.dts | 126 +++++++++++++++++++++
4 files changed, 296 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 48b7437..e4c052f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -137,6 +137,11 @@ source "kernel/Kconfig.freezer"
menu "Platform selection"
+config ARCH_SEATTLE
+ bool "AMD Seattle SoC Family"
+ help
+ This enables support for AMD Seattle SOC Family
+
config ARCH_THUNDER
bool "Cavium Inc. Thunder SoC Family"
help
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index f8001a6..6c27047 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,6 +1,7 @@
dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb
dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
+dtb-$(CONFIG_ARCH_SEATTLE) += amd-seattle.dtb
targets += dtbs
targets += $(dtb-y)
diff --git a/arch/arm64/boot/dts/amd-seattle-periph.dtsi b/arch/arm64/boot/dts/amd-seattle-periph.dtsi
new file mode 100644
index 0000000..273b7fc
--- /dev/null
+++ b/arch/arm64/boot/dts/amd-seattle-periph.dtsi
@@ -0,0 +1,164 @@
+/*
+ * DTS file for AMD Seattle Peripheral
+ *
+ * Copyright (C) 2014 Advanced Micro Devices, Inc.
+ */
+
+motherboard {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ adl3clk_100mhz: clk100mhz_0 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100000000>;
+ clock-output-names = "adl3clk_100mhz";
+ };
+
+ ccpclk_375mhz: clk375mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <375000000>;
+ clock-output-names = "ccpclk_375mhz";
+ };
+
+ sataclk_333mhz: clk333mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <333000000>;
+ clock-output-names = "sataclk_333mhz";
+ };
+
+ pcieclk_500mhz: clk500mhz_0 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <500000000>;
+ clock-output-names = "pcieclk_500mhz";
+ };
+
+ dmaclk_500mhz: clk500mhz_1 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <500000000>;
+ clock-output-names = "dmaclk_500mhz";
+ };
+
+ miscclk_250mhz: clk250mhz_4 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <250000000>;
+ clock-output-names = "miscclk_250mhz";
+ };
+
+ uartspiclk_100mhz: clk100mhz_1 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100000000>;
+ clock-output-names = "uartspiclk_100mhz";
+ };
+
+ dma0: dma@0500000 {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0 0x0500000 0 0x1000>;
+ interrupts =
+ <0 368 4>,
+ <0 369 4>,
+ <0 370 4>,
+ <0 371 4>,
+ <0 372 4>,
+ <0 373 4>,
+ <0 374 4>,
+ <0 375 4>;
+ clocks = <&dmaclk_500mhz>;
+ clock-names = "apb_pclk";
+ #dma-cells = <1>;
+ };
+
+ sata0: sata@00300000 {
+ compatible = "snps,spear-ahci";
+ reg = <0 0x300000 0 0x800>;
+ interrupts = <0 355 4>;
+ clocks = <&sataclk_333mhz>;
+ clock-names = "apb_pclk";
+ dma-coherent;
+ };
+
+ i2c@1000000 {
+ compatible = "snps,designware-i2c";
+ reg = <0 0x01000000 0 0x1000>;
+ interrupts = <0 357 4>;
+ clocks = <&uartspiclk_100mhz>;
+ clock-names = "apb_pclk";
+ };
+
+ v2m_serial0: uart@1010000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0 0x1010000 0 0x1000>;
+ interrupts = <0 328 4>;
+ clocks = <&uartspiclk_100mhz>, <&uartspiclk_100mhz>;
+ clock-names = "uartclk", "apb_pclk";
+ };
+
+ ssp@1020000 {
+ compatible = "arm,pl022", "arm,primecell";
+ #gpio-cells = <2>;
+ reg = <0 0x1020000 0 0x1000>;
+ spi-controller;
+ interrupts = <0 330 4>;
+ clocks = <&uartspiclk_100mhz>;
+ clock-names = "apb_pclk";
+ };
+
+ ssp@1030000 {
+ compatible = "arm,pl022", "arm,primecell";
+ #gpio-cells = <2>;
+ reg = <0 0x1030000 0 0x1000>;
+ spi-controller;
+ interrupts = <0 329 4>;
+ clocks = <&uartspiclk_100mhz>;
+ clock-names = "apb_pclk";
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sdcard@0 {
+ compatible = "mmc-spi-slot";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ pl022,hierarchy = <0>;
+ pl022,interface = <0>;
+ pl022,com-mode = <0x0>;
+ pl022,rx-level-trig = <0>;
+ pl022,tx-level-trig = <0>;
+ };
+ };
+
+ gpio0: gpio@1040000 {
+ compatible = "arm,pl061", "arm,primecell";
+ #gpio-cells = <2>;
+ reg = <0 0x1040000 0 0x1000>;
+ gpio-controller;
+ interrupts = <0 359 4>;
+ clocks = <&uartspiclk_100mhz>;
+ clock-names = "apb_pclk";
+ };
+
+ gpio1: gpio@1050000 {
+ compatible = "arm,pl061", "arm,primecell";
+ #gpio-cells = <2>;
+ reg = <0 0x1050000 0 0x1000>;
+ gpio-controller;
+ interrupts = <0 358 4>;
+ clocks = <&uartspiclk_100mhz>;
+ clock-names = "apb_pclk";
+ };
+
+ ccp: ccp@00100000 {
+ compatible = "amd,ccp-seattle-v1a";
+ reg = <0 0x00100000 0 0x10000>;
+ interrupts = <0 3 4>;
+ dma-coherent;
+ };
+};
diff --git a/arch/arm64/boot/dts/amd-seattle.dts b/arch/arm64/boot/dts/amd-seattle.dts
new file mode 100644
index 0000000..2988637
--- /dev/null
+++ b/arch/arm64/boot/dts/amd-seattle.dts
@@ -0,0 +1,126 @@
+/*
+ * DTS file for AMD Seattle
+ *
+ * Copyright (C) 2014 Advanced Micro Devices, Inc.
+ */
+
+/dts-v1/;
+
+/ {
+ compatible = "amd,seattle";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ chosen {
+ linux,stdout-path = "console=ttyAMA0,115200 earlycon=pl011,0xe1010000";
+ linux,pci-probe-only;
+ };
+
+ aliases {
+ serial0 = &v2m_serial0;
+ };
+
+ gic: interrupt-controller@e1101000 {
+ compatible = "arm,gic-400", "arm,cortex-a15-gic";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ reg = <0x0 0xe1110000 0 0x1000>,
+ <0x0 0xe112f000 0 0x2000>,
+ <0x0 0xe1140000 0 0x10000>,
+ <0x0 0xe1160000 0 0x10000>;
+ interrupts = <1 8 0xf04>;
+ ranges;
+ v2m0: v2m@e1180000 {
+ compatible = "arm,gic-v2m-frame";
+ msi-controller;
+ arm,msi-base-spi = <64>;
+ arm,msi-num-spis = <256>;
+ reg = <0x0 0xe1180000 0 0x1000>;
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <1 13 0xff01>,
+ <1 14 0xff01>,
+ <1 11 0xff01>,
+ <1 10 0xff01>;
+ };
+
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = <0 7 4>,
+ <0 8 4>,
+ <0 9 4>,
+ <0 10 4>,
+ <0 11 4>,
+ <0 12 4>,
+ <0 13 4>,
+ <0 14 4>;
+ };
+
+ /* This entry is modified by UEFI */
+ pcie0: pcie-controller{
+ compatible = "pci-host-ecam-generic";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ bus-range = <0 0xff>;
+ reg = <0 0xf0000000 0 0x10000000>;
+ dma-coherent;
+ msi-parent = <&v2m0>;
+
+ interrupts =
+ <0 320 4>, /* ioc_soc_serr */
+ <0 321 4>; /* ioc_soc_sci */
+
+ ranges =
+ /* I/O Memory (size=64K) */
+ <0x01000000 0x00 0xefff0000 0x00 0xefff0000 0x00 0x00010000>,
+
+ /* Non-Pref 32-bit MMIO (size=512M) */
+ <0x02000000 0x00 0x40000000 0x00 0x40000000 0x00 0x20000000>,
+
+ /* Non-Pref 32-bit MMIO (size=512M) */
+ <0x02000000 0x00 0x60000000 0x00 0x60000000 0x00 0x20000000>,
+
+ /* Non-Pref 32-bit MMIO (size=512M) */
+ <0x02000000 0x00 0x80000000 0x00 0x80000000 0x00 0x20000000>,
+
+ /* Non-Pref 32-bit MMIO (size=512M) */
+ <0x02000000 0x00 0xa0000000 0x00 0xa0000000 0x00 0x20000000>,
+
+ /* Pref 64-bit MMIO (size= 4G) */
+ <0x43000000 0x01 0x00000000 0x01 0x00000000 0x01 0x00000000>,
+
+ /* Pref 64-bit MMIO (size= 8G) */
+ <0x43000000 0x02 0x00000000 0x02 0x00000000 0x02 0x00000000>,
+
+ /* Pref 64-bit MMIO (size=16G) */
+ <0x43000000 0x04 0x00000000 0x04 0x00000000 0x04 0x00000000>,
+
+ /* Pref 64-bit MMIO (size=32G) */
+ <0x43000000 0x08 0x00000000 0x08 0x00000000 0x08 0x00000000>,
+
+ /* Pref 64-bit MMIO (size=64G) */
+ <0x43000000 0x10 0x00000000 0x10 0x00000000 0x10 0x00000000>,
+
+ /* Pref 64-bit MMIO (size=128G) */
+ <0x43000000 0x20 0x00000000 0x20 0x00000000 0x20 0x00000000>,
+
+ /* Pref 64-bit MMIO (size=256G) */
+ <0x43000000 0x40 0x00000000 0x40 0x00000000 0x40 0x00000000>;
+ };
+
+ smb {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0 0 0 0xE0000000 0 0x01300000>;
+
+ /include/ "amd-seattle-periph.dtsi"
+ };
+};
--
1.9.3
On 24.10.14 14:20, [email protected] wrote:
> From: Suravee Suthikulpanit <[email protected]>
>
> Initial revision of device tree for AMD Seattle platform
>
> Cc: Mark Rutland <[email protected]>
> Cc: Will Deacon <[email protected]>
> Cc: Catalin Marinas <[email protected]>
> Cc: Rob Herring <[email protected]>
> Signed-off-by: Suravee Suthikulpanit <[email protected]>
> Signed-off-by: Thomas Lendacky <[email protected]>
> Signed-off-by: Joel Schopp <[email protected]>
> ---
> arch/arm64/Kconfig | 5 +
> arch/arm64/boot/dts/Makefile | 1 +
> arch/arm64/boot/dts/amd-seattle-periph.dtsi | 164 ++++++++++++++++++++++++++++
> arch/arm64/boot/dts/amd-seattle.dts | 126 +++++++++++++++++++++
> 4 files changed, 296 insertions(+)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 48b7437..e4c052f 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -137,6 +137,11 @@ source "kernel/Kconfig.freezer"
>
> menu "Platform selection"
>
> +config ARCH_SEATTLE
> + bool "AMD Seattle SoC Family"
> + help
> + This enables support for AMD Seattle SOC Family
> +
> config ARCH_THUNDER
> bool "Cavium Inc. Thunder SoC Family"
> help
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index f8001a6..6c27047 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -1,6 +1,7 @@
> dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb
> dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
> dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
> +dtb-$(CONFIG_ARCH_SEATTLE) += amd-seattle.dtb
This option doesn't exist in upstream kernels, does it? Why not just
make it dtb-y?
Alex
Am 26.10.2014 um 01:08 schrieb Alexander Graf:
> On 24.10.14 14:20, [email protected] wrote:
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 48b7437..e4c052f 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -137,6 +137,11 @@ source "kernel/Kconfig.freezer"
>>
>> menu "Platform selection"
>>
>> +config ARCH_SEATTLE
>> + bool "AMD Seattle SoC Family"
>> + help
>> + This enables support for AMD Seattle SOC Family
>> +
>> config ARCH_THUNDER
>> bool "Cavium Inc. Thunder SoC Family"
>> help
>> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
>> index f8001a6..6c27047 100644
>> --- a/arch/arm64/boot/dts/Makefile
>> +++ b/arch/arm64/boot/dts/Makefile
>> @@ -1,6 +1,7 @@
>> dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb
>> dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
>> dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
>> +dtb-$(CONFIG_ARCH_SEATTLE) += amd-seattle.dtb
>
> This option doesn't exist in upstream kernels, does it? Why not just
> make it dtb-y?
CONFIG_ARCH_SEATTLE is being added one hunk above. :)
Cheers,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
> Am 26.10.2014 um 13:43 schrieb Andreas Färber <[email protected]>:
>
>> Am 26.10.2014 um 01:08 schrieb Alexander Graf:
>>> On 24.10.14 14:20, [email protected] wrote:
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index 48b7437..e4c052f 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -137,6 +137,11 @@ source "kernel/Kconfig.freezer"
>>>
>>> menu "Platform selection"
>>>
>>> +config ARCH_SEATTLE
>>> + bool "AMD Seattle SoC Family"
>>> + help
>>> + This enables support for AMD Seattle SOC Family
>>> +
>>> config ARCH_THUNDER
>>> bool "Cavium Inc. Thunder SoC Family"
>>> help
>>> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
>>> index f8001a6..6c27047 100644
>>> --- a/arch/arm64/boot/dts/Makefile
>>> +++ b/arch/arm64/boot/dts/Makefile
>>> @@ -1,6 +1,7 @@
>>> dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb
>>> dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
>>> dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
>>> +dtb-$(CONFIG_ARCH_SEATTLE) += amd-seattle.dtb
>>
>> This option doesn't exist in upstream kernels, does it? Why not just
>> make it dtb-y?
>
> CONFIG_ARCH_SEATTLE is being added one hunk above. :)
Oops :).
I'm not convinced we need a config option just for the sake of compiling a device tree though.
Alex
Hi,
Am 24.10.2014 um 14:20 schrieb [email protected]:
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index f8001a6..6c27047 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -1,6 +1,7 @@
> dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb
> dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
> dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
> +dtb-$(CONFIG_ARCH_SEATTLE) += amd-seattle.dtb
It seems these lines are sorted alphabetically, so Seattle should go
somewhere before Thunder.
>
> targets += dtbs
> targets += $(dtb-y)
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
Hi Suravee,
[...]
> dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb
> dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
> dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
> +dtb-$(CONFIG_ARCH_SEATTLE) += amd-seattle.dtb
This should move earlier in the list (to keep things organised
alphabetically).
[...]
> + v2m_serial0: uart@1010000 {
Drop the "v2m_" prefix -- in other dts that refers to a Versatile
Express μATX motherboard (the V2M-P1), and this isn't a Versatile
Express.
Also, I believe the preferred node name is "serial" rather than "uart".
[...]
> + chosen {
> + linux,stdout-path = "console=ttyAMA0,115200 earlycon=pl011,0xe1010000";
The stdout-path property should just be a path to the UART node. It's
not a direct replacement for /chosen/bootargs.
This should be (assuming you fix up the label above):
stdout-path = &serial0;
That will give us earlycon if "earlycon" (with no arguments) is provided
on the command line, and should set up that UART as the console. There's
no need for the "linux," prefix now either.
Unfortuantely, I believe that the UART rate will get changed when the
real PL011 driver registers, unless the rate is explicitly provided on
the command line. It might be worth looking into retaining the
configured rate somehow indepentent of bootargs (unless overriden).
Thanks,
Mark.
On 10/26/2014 9:08 AM, Alexander Graf wrote:
>>> This option doesn't exist in upstream kernels, does it? Why not just
>>> >>make it dtb-y?
>> >
>> >CONFIG_ARCH_SEATTLE is being added one hunk above.:)
> Oops:).
>
> I'm not convinced we need a config option just for the sake of compiling a device tree though.
>
>
> Alex
>
Eventually, we would add other device driver selections when
CONFIG_ARCH_SEATTLE=y. At this point, those drivers are still not ready.
Suravee
On 10/26/2014 9:09 AM, Andreas F?rber wrote:
> Hi,
>
> Am 24.10.2014 um 14:20 schrieb [email protected]:
>> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
>> index f8001a6..6c27047 100644
>> --- a/arch/arm64/boot/dts/Makefile
>> +++ b/arch/arm64/boot/dts/Makefile
>> @@ -1,6 +1,7 @@
>> dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb
>> dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
>> dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
>> +dtb-$(CONFIG_ARCH_SEATTLE) += amd-seattle.dtb
>
> It seems these lines are sorted alphabetically, so Seattle should go
> somewhere before Thunder.
>
>>
>> targets += dtbs
>> targets += $(dtb-y)
>
> Regards,
> Andreas
>
Ah.. right. I'll fix this and send out V2.
Suravee
On 10/27/2014 8:50 AM, Mark Rutland wrote:
> Hi Suravee,
>
> [...]
>
>> + chosen {
>> + linux,stdout-path = "console=ttyAMA0,115200 earlycon=pl011,0xe1010000";
>
> The stdout-path property should just be a path to the UART node. It's
> not a direct replacement for /chosen/bootargs.
>
> This should be (assuming you fix up the label above):
>
> stdout-path = &serial0;
>
> That will give us earlycon if "earlycon" (with no arguments) is provided
> on the command line, and should set up that UART as the console. There's
> no need for the "linux," prefix now either.
>
> Unfortuantely, I believe that the UART rate will get changed when the
> real PL011 driver registers, unless the rate is explicitly provided on
> the command line. It might be worth looking into retaining the
> configured rate somehow indepentent of bootargs (unless overriden).
Thanks for the explanation. I think I should be able to get rid of the
"console=ttyAMA0,115200 earlycon=pl011,0xe1010000" altogether. I'll send
out V2 soon.
Thanks,
Suravee
> Thanks,
> Mark.
>
On 27.10.14 15:29, Suravee Suthikulanit wrote:
> On 10/26/2014 9:08 AM, Alexander Graf wrote:
>>>> This option doesn't exist in upstream kernels, does it? Why not just
>>>> >>make it dtb-y?
>>> >
>>> >CONFIG_ARCH_SEATTLE is being added one hunk above.:)
>> Oops:).
>>
>> I'm not convinced we need a config option just for the sake of
>> compiling a device tree though.
>>
>>
>> Alex
>>
>
> Eventually, we would add other device driver selections when
> CONFIG_ARCH_SEATTLE=y. At this point, those drivers are still not ready.
Could you please give me some examples of drivers that would depend on
CONFIG_ARCH_SEATTLE? I like the current way things work without the need
for such an option, where everything's implemented purely as drivers you
can opt in our out of.
You don't have a CONFIG_ARCH_SB7XX on x86 either, right? ;)
Alex
On 10/27/2014 6:25 PM, Alexander Graf wrote:
>
>
> On 27.10.14 15:29, Suravee Suthikulanit wrote:
>> On 10/26/2014 9:08 AM, Alexander Graf wrote:
>>>>> This option doesn't exist in upstream kernels, does it? Why not just
>>>>>>> make it dtb-y?
>>>>>
>>>>> CONFIG_ARCH_SEATTLE is being added one hunk above.:)
>>> Oops:).
>>>
>>> I'm not convinced we need a config option just for the sake of
>>> compiling a device tree though.
>>>
>>>
>>> Alex
>>>
>>
>> Eventually, we would add other device driver selections when
>> CONFIG_ARCH_SEATTLE=y. At this point, those drivers are still not ready.
>
> Could you please give me some examples of drivers that would depend on
> CONFIG_ARCH_SEATTLE? I like the current way things work without the need
> for such an option, where everything's implemented purely as drivers you
> can opt in our out of.
>
> You don't have a CONFIG_ARCH_SB7XX on x86 either, right? ;)
>
>
> Alex
>
I am not saying that device drivers need to depend on
CONFIG_ARCH_SEATTLE. I am thinking along the line of an easy way to
enable SOC without having to manually select each of the required
drivers to support the SOC. An example is the "ARCH_VEXPRESS".
Suravee
> Am 28.10.2014 um 14:07 schrieb Suravee Suthikulanit <[email protected]>:
>
>> On 10/27/2014 6:25 PM, Alexander Graf wrote:
>>
>>
>>> On 27.10.14 15:29, Suravee Suthikulanit wrote:
>>> On 10/26/2014 9:08 AM, Alexander Graf wrote:
>>>>>> This option doesn't exist in upstream kernels, does it? Why not just
>>>>>>>> make it dtb-y?
>>>>>>
>>>>>> CONFIG_ARCH_SEATTLE is being added one hunk above.:)
>>>> Oops:).
>>>>
>>>> I'm not convinced we need a config option just for the sake of
>>>> compiling a device tree though.
>>>>
>>>>
>>>> Alex
>>>>
>>>
>>> Eventually, we would add other device driver selections when
>>> CONFIG_ARCH_SEATTLE=y. At this point, those drivers are still not ready.
>>
>> Could you please give me some examples of drivers that would depend on
>> CONFIG_ARCH_SEATTLE? I like the current way things work without the need
>> for such an option, where everything's implemented purely as drivers you
>> can opt in our out of.
>>
>> You don't have a CONFIG_ARCH_SB7XX on x86 either, right? ;)
>>
>>
>> Alex
>>
>
> I am not saying that device drivers need to depend on CONFIG_ARCH_SEATTLE. I am thinking along the line of an easy way to enable SOC without having to manually select each of the required drivers to support the SOC. An example is the "ARCH_VEXPRESS".
Works for me, but then please don't make anything depend on CONFIG_ARCH_SEATTLE. Everything you need for seattle support should be possible to select without the easy enable switch until we see a good reason to have one ;).
So in this particular case, we shouldn't build the device tree depending on CONFIG_ARCH_SEATTLE but rather slways which again means the switch does not need to get introduced by this patch ;)
But at the end of the day, this is Catalin's subsystem and his opinion counts more than mine. Catalin, do you have strong feelings in any direction here?
Alex
On Tue, Oct 28, 2014 at 01:07:49PM +0000, Suravee Suthikulanit wrote:
> On 10/27/2014 6:25 PM, Alexander Graf wrote:
> >
> >
> > On 27.10.14 15:29, Suravee Suthikulanit wrote:
> >> On 10/26/2014 9:08 AM, Alexander Graf wrote:
> >>>>> This option doesn't exist in upstream kernels, does it? Why not just
> >>>>>>> make it dtb-y?
> >>>>>
> >>>>> CONFIG_ARCH_SEATTLE is being added one hunk above.:)
> >>> Oops:).
> >>>
> >>> I'm not convinced we need a config option just for the sake of
> >>> compiling a device tree though.
> >>>
> >>>
> >>> Alex
> >>>
> >>
> >> Eventually, we would add other device driver selections when
> >> CONFIG_ARCH_SEATTLE=y. At this point, those drivers are still not ready.
> >
> > Could you please give me some examples of drivers that would depend on
> > CONFIG_ARCH_SEATTLE? I like the current way things work without the need
> > for such an option, where everything's implemented purely as drivers you
> > can opt in our out of.
> >
> > You don't have a CONFIG_ARCH_SB7XX on x86 either, right? ;)
> >
> >
> > Alex
> >
>
> I am not saying that device drivers need to depend on
> CONFIG_ARCH_SEATTLE. I am thinking along the line of an easy way to
> enable SOC without having to manually select each of the required
> drivers to support the SOC. An example is the "ARCH_VEXPRESS".
ARCH_VEXPRESS is an historical artifact and we have discussed a few times
internally in ARM to remove it as it brings no value until some other platform
can't work with the default options comes in.
I agree with Alexander here, I think the device tree should be compiled
in regardless. One reason for it is because it will make it easier to
dis-entangle the .dt{s,b} files from the tree in the future and have them
hosted in a different place.
Best regards,
Liviu
>
> Suravee
>
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯