[PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7

Naveen Krishna Ch naveenkrishna.ch at gmail.com
Wed Sep 3 00:48:41 PDT 2014


Hi Mark,

On 27 August 2014 16:12, Mark Rutland <mark.rutland at arm.com> wrote:
> Hi Naveen,
>
> On Wed, Aug 27, 2014 at 10:44:18AM +0100, Naveen Krishna Chatradhi wrote:
>> Add initial device tree nodes for EXYNOS7 SoC.
>> Also, includes the dt-binding definitions for clock ids.
>
> Fallout from a rebase? That latter part doesn't seem to be relevant.

Yes, this is fixed now.

>
>> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen at samsung.com>
>> Cc: Thomas Abraham <thomas.ab at samsung.com>
>> Cc: Rob Herring <robh at kernel.org>
>> Cc: Catalin Marinas <catalin.marinas at arm.com>
>> ---
>>  arch/arm64/boot/dts/exynos7.dtsi |  553 ++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 553 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/exynos7.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/exynos7.dtsi b/arch/arm64/boot/dts/exynos7.dtsi
>> new file mode 100644
>> index 0000000..6b9eaf4
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/exynos7.dtsi
>> @@ -0,0 +1,553 @@
>> +/*
>> + * SAMSUNG EXYNOS7 SoC device tree source
>> + *
>> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
>> + *             http://www.samsung.com
>> + *
>> + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file.
>> + * EXYNOS7 based board files can include this file and provide
>> + * values for board specfic bindings.
>> + *
>> + * 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.
>> + */
>> +
>> +#include <dt-bindings/clock/exynos7-clk.h>
>> +
>> +/ {
>> +       compatible = "samsung,exynos7";
>> +       interrupt-parent = <&gic>;
>> +       #address-cells = <1>;
>> +       #size-cells = <1>;
>
> Can we guarantee everything going to live within 0x0 - 0xffffffff for
> all boards using the SoC?
>
> I suspect that we can't, so the addresses and sizes at the top level
> should be two cells. At some point there is bound to be something above
> 4GB that we'll need to map, so to save us from a painful dts refactoring
> we should have the dts organised to support that from the outside.

Ok, this is fixed with #address-cells = 2 and #size-cells = 2.

>
> [...]
>
>> +       cpus {
>> +               #address-cells = <2>;
>> +               #size-cells = <0>;
>> +
>> +               cpu at 0 {
>> +                       device_type = "cpu";
>> +                       compatible = "arm,cortex-a57", "arm,armv8";
>> +                       reg = <0x0 0x0>;
>> +               };
>> +       };
>
> Only UP?

This is a quad core SoC and the rest of the CPU nodes have been added
in the second version of this series.

>
> [...]
>
>> +       gic: interrupt-controller at 11001000 {
>> +               compatible = "arm,gic-400";
>> +               #interrupt-cells = <3>;
>> +               #address-cells = <0>;
>> +               interrupt-controller;
>> +               reg =   <0x11001000 0x1000>,
>> +                       <0x11002000 0x1000>,
>> +                       <0x11004000 0x2000>,
>> +                       <0x11006000 0x2000>;
>> +       };
>
> Nice to see GICV and GICH.
>
> [...]
>
>> +       mct at 101C0000 {
>> +               compatible = "samsung,exynos4210-mct";
>> +               reg = <0x101C0000 0x800>;
>> +               interrupt-controller;
>> +               #interrupt-cells = <1>;
>> +               interrupt-parent = <&mct_map>;
>> +               interrupts =    <0>, <1>, <2>, <3>,
>> +                               <4>, <5>, <6>, <7>,
>> +                               <8>, <9>, <10>, <11>;
>> +               clocks = <&fin_pll>, <&clock_peris PCLK_MCT>;
>> +               clock-names = "fin_pll", "mct";
>> +
>> +               mct_map: mct-map {
>> +                       #interrupt-cells = <1>;
>> +                       #address-cells = <0>;
>> +                       #size-cells = <0>;
>> +                       interrupt-map = <0 &gic 0 112 0>,
>> +                                       <1 &gic 0 113 0>,
>> +                                       <2 &gic 0 114 0>,
>> +                                       <3 &gic 0 115 0>,
>> +                                       <4 &gic 0 116 0>,
>> +                                       <5 &gic 0 117 0>,
>> +                                       <6 &gic 0 118 0>,
>> +                                       <7 &gic 0 119 0>,
>> +                                       <8 &gic 0 120 0>,
>> +                                       <9 &gic 0 121 0>,
>> +                                       <10 &gic 0 122 0>,
>> +                                       <11 &gic 0 123 0>;
>> +               };
>> +       };
>
> I don't see why need the map here. Why can't we describe the GIC
> interrupts directly?

Right, it was not required. Also, we will try and use only arch timer
and not MCT.

>
> [...]
>
>> +       timer {
>> +               compatible = "arm,armv8-timer";
>> +               interrupts = <1 13 0xff01>,
>> +                            <1 14 0xff01>,
>> +                            <1 11 0xff01>,
>> +                            <1 10 0xff01>;
>> +               clock-frequency = <24000000>;
>
> Your firmware/bootloader should configure CNTFRQ, and this shouldn't be
> necessary. The clock-frequency property is an incomplete workaround for
> broken firmware that in an ideal world we could kill off.
>
>> +               use-clocksource-only;
>> +               use-physical-timer;
>
> Neither of these properties were introduced by this series, and no
> rationale was given.
>
> What are these properties for, and why do you believe they are
> necessary?

Sorry, that was a mistake. This has been fixed.

>
> Thanks,
> Mark.

Thanks.

-- 
Shine bright,
(: Nav :)



More information about the linux-arm-kernel mailing list