[PATCH 0/3] ARM: dts: uniphier: DTS updates for UniPhier SoCs for Linux 4.14-rc1

[PATCH 0/3] ARM: dts: uniphier: DTS updates for UniPhier SoCs for Linux 4.14-rc1

[Masahiro Yamada]

Hi Olof and Arnd,

Please apply this series to ARM-SOC for the next merge window.

Thanks
Masahiro Yamada



Masahiro Yamada (3):
  ARM: dts: uniphier: change the external bus address mapping
  ARM: dts: uniphier: add ProXstream2 Vodka board support
  ARM: dts: uniphier: add ProXstream2 Gentil board support

 arch/arm/boot/dts/Makefile                        |  4 +-
 arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts        |  5 +-
 arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts       |  5 +-
 arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts       |  5 +-
 arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts       |  5 +-
 arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts       |  5 +-
 arch/arm/boot/dts/uniphier-proxstream2-gentil.dts | 79 +++++++++++++++++++++++
 arch/arm/boot/dts/uniphier-proxstream2-vodka.dts  | 79 +++++++++++++++++++++++
 8 files changed, 171 insertions(+), 16 deletions(-)
 create mode 100644 arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
 create mode 100644 arch/arm/boot/dts/uniphier-proxstream2-vodka.dts

-- 
1.9.1

[PATCH 1/3] ARM: dts: uniphier: change the external bus address mapping

[Masahiro Yamada]

In UniPhier SoCs before ProXstream2 and PH1-LD6b, two address spaces
 0x00000000 - 0x0fffffff
 0x40000000 - 0x4fffffff
are both mapped to the external bus (also called system bus),
so either was OK.

In the newest two SoCs, the former (0x00000000 - 0x0fffffff) is
assigned for the serial NOR interface.

For the consistency, use the latter for all the SoCs.

Also, fix the range properties to reflect the real address mapping,
where the support card is located at the offset address 0x01f00000
of CS1 of the external bus.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts  | 5 ++---
 arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 5 ++---
 arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts | 5 ++---
 arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts | 5 ++---
 arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts | 5 ++---
 5 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
index bfd3bb8..e9722a5 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
@@ -74,12 +74,11 @@
 };
 
 &extbus {
-	ranges = <0 0x00000000 0x0f000000 0x01000000
-		  1 0x00000000 0x00000000 0x08000000>;
+	ranges = <1 0x00000000 0x42000000 0x02000000>;
 };
 
 &support_card {
-	ranges = <0x00000000 1 0x03f00000 0x00100000>;
+	ranges = <0x00000000 1 0x01f00000 0x00100000>;
 };
 
 &ethsc {
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
index 3a6f1f6..1a402ed 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
@@ -76,12 +76,11 @@
 };
 
 &extbus {
-	ranges = <0 0x00000000 0x0f000000 0x01000000
-		  1 0x00000000 0x00000000 0x08000000>;
+	ranges = <1 0x00000000 0x42000000 0x02000000>;
 };
 
 &support_card {
-	ranges = <0x00000000 1 0x03f00000 0x00100000>;
+	ranges = <0x00000000 1 0x01f00000 0x00100000>;
 };
 
 &ethsc {
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
index 69a5b7d..47e2edb 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
@@ -76,12 +76,11 @@
 };
 
 &extbus {
-	ranges = <0 0x00000000 0x0f000000 0x01000000
-		  1 0x00000000 0x00000000 0x08000000>;
+	ranges = <1 0x00000000 0x42000000 0x02000000>;
 };
 
 &support_card {
-	ranges = <0x00000000 1 0x03f00000 0x00100000>;
+	ranges = <0x00000000 1 0x01f00000 0x00100000>;
 };
 
 &ethsc {
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
index 1a440f8..adcbbc6 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
@@ -75,12 +75,11 @@
 };
 
 &extbus {
-	ranges = <0 0x00000000 0x0f000000 0x01000000
-		  1 0x00000000 0x00000000 0x08000000>;
+	ranges = <1 0x00000000 0x42000000 0x02000000>;
 };
 
 &support_card {
-	ranges = <0x00000000 1 0x03f00000 0x00100000>;
+	ranges = <0x00000000 1 0x01f00000 0x00100000>;
 };
 
 &ethsc {
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts b/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
index 955d417..bcf2e7c 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
@@ -74,12 +74,11 @@
 };
 
 &extbus {
-	ranges = <0 0x00000000 0x0f000000 0x01000000
-		  1 0x00000000 0x00000000 0x08000000>;
+	ranges = <1 0x00000000 0x42000000 0x02000000>;
 };
 
 &support_card {
-	ranges = <0x00000000 1 0x03f00000 0x00100000>;
+	ranges = <0x00000000 1 0x01f00000 0x00100000>;
 };
 
 &ethsc {
-- 
1.9.1

[PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support

[Masahiro Yamada]

Initial version of DTS for ProXstream2 Vodka board.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 arch/arm/boot/dts/Makefile                       |  3 +-
 arch/arm/boot/dts/uniphier-proxstream2-vodka.dts | 79 ++++++++++++++++++++++++
 2 files changed, 81 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/uniphier-proxstream2-vodka.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bb8fa02..9232018 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -672,7 +672,8 @@ dtb-$(CONFIG_ARCH_UNIPHIER) += \
 	uniphier-ph1-ld6b-ref.dtb \
 	uniphier-ph1-pro4-ref.dtb \
 	uniphier-ph1-sld3-ref.dtb \
-	uniphier-ph1-sld8-ref.dtb 
+	uniphier-ph1-sld8-ref.dtb \
+	uniphier-proxstream2-vodka.dtb
 dtb-$(CONFIG_ARCH_VERSATILE) += \
 	versatile-ab.dtb \
 	versatile-pb.dtb
diff --git a/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts b/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts
new file mode 100644
index 0000000..27691f9
--- /dev/null
+++ b/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts
@@ -0,0 +1,79 @@
+/*
+ * Device Tree Source for UniPhier ProXstream2 Vodka Board
+ *
+ * Copyright (C) 2015 Masahiro Yamada <yamada.masahiro@socionext.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+/include/ "uniphier-proxstream2.dtsi"
+
+/ {
+	model = "UniPhier ProXstream2 Vodka Board";
+	compatible = "socionext,proxstream2-vodka", "socionext,proxstream2";
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x80000000>;
+	};
+
+	chosen {
+		bootargs = "console=ttyS2,115200";
+		stdout-path = &serial2;
+	};
+
+	aliases {
+		serial0 = &serial0;
+		serial1 = &serial1;
+		serial2 = &serial2;
+		i2c0 = &i2c0;
+		i2c4 = &i2c4;
+		i2c5 = &i2c5;
+		i2c6 = &i2c6;
+	};
+};
+
+&serial2 {
+	status = "okay";
+};
+
+&i2c0 {
+	status = "okay";
+};
-- 
1.9.1

[PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support

[Arnd Bergmann]

On Thursday 15 October 2015 18:05:33 Masahiro Yamada wrote:
> +       aliases {
> +               serial0 = &serial0;
> +               serial1 = &serial1;
> +               serial2 = &serial2;
> +               i2c0 = &i2c0;
> +               i2c4 = &i2c4;
> +               i2c5 = &i2c5;
> +               i2c6 = &i2c6;
> 

This looks like a typo, you probably mean

               i2c0 = &i2c0;
               i2c1 = &i2c4;
               i2c2 = &i2c5;
               i2c3 = &i2c6;

Can you re-send this?

	Arnd

[PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support

[Masahiro Yamada]

Hi Arnd,

2015-10-16 0:17 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> On Thursday 15 October 2015 18:05:33 Masahiro Yamada wrote:
>> +       aliases {
>> +               serial0 = &serial0;
>> +               serial1 = &serial1;
>> +               serial2 = &serial2;
>> +               i2c0 = &i2c0;
>> +               i2c4 = &i2c4;
>> +               i2c5 = &i2c5;
>> +               i2c6 = &i2c6;
>>
>
> This looks like a typo, you probably mean
>
>                i2c0 = &i2c0;
>                i2c1 = &i2c4;
>                i2c2 = &i2c5;
>                i2c3 = &i2c6;
>
> Can you re-send this?
>


No, it is not a typo, but intentional.


i2c0 - i2c3 are connected to the pads of the SoC package.
On the other hand, i2c-4 - i2c-6 are connected to
internal devices inside the SoC package.

i2c-4 - i2c-6 are always connected to the same hardware
devices and always used for the same purpose.


My expected scenario is:

[1] i2c0 - i2c3 are connected to the on-board devices
    depending on board variants.
    On some boards, their status is "okay" and
    on some boards, their status is "disabled".

[2] i2c4 - i2c6 are always used to communicate
    with in-package devices.  The status is always "okay".

[3] Some user-land applications may want to have access
     through the same character devices,
      /dev/i2c4, /dev/i2c5, /dev/i2c6


If your way is adopted,
the real hardware "i2c4" might be aligned to /dev/i2c1 on some boards,
and /dev/i2c2 on others, etc.



-- 
Best Regards
Masahiro Yamada

[PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support

[Arnd Bergmann]

On Friday 16 October 2015 14:24:30 Masahiro Yamada wrote:
> 
> No, it is not a typo, but intentional.
> 
> 
> i2c0 - i2c3 are connected to the pads of the SoC package.
> On the other hand, i2c-4 - i2c-6 are connected to
> internal devices inside the SoC package.
> 
> i2c-4 - i2c-6 are always connected to the same hardware
> devices and always used for the same purpose.
> 
> 
> My expected scenario is:
> 
> [1] i2c0 - i2c3 are connected to the on-board devices
>     depending on board variants.
>     On some boards, their status is "okay" and
>     on some boards, their status is "disabled".
> 
> [2] i2c4 - i2c6 are always used to communicate
>     with in-package devices.  The status is always "okay".

I think you are getting confused because the data sheet uses
the same names as the kernel, but they are really different
things.

How about boards that have i2c connectors that are labeled
differently?

We want the aliases to match whatever is written on the
board normally, to make it easier for users.

> [3] Some user-land applications may want to have access
>      through the same character devices,
>       /dev/i2c4, /dev/i2c5, /dev/i2c6

That user space would however only work on boards with the
same SoC, which is not a safe assumption to make. Either
it should be specific to just one board which has a known
set of buses, or it should be done in a way that works
across SoC generations of families.

Ideally the devices on the internal buses would have an
in-kernel driver that exports a high-level API to avoid this
problem. What devices are these?

> If your way is adopted,
> the real hardware "i2c4" might be aligned to /dev/i2c1 on some boards,
> and /dev/i2c2 on others, etc.

Right, I think that is how it should be. You could also make
the chip's i2c4 always link to user space /dev/i2c0 if you
want to keep those stable, but as I said that is still not
a good (software) system design.

	Arnd

[PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support

[Masahiro Yamada]

Hi Arnd,

2015-10-16 18:18 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> On Friday 16 October 2015 14:24:30 Masahiro Yamada wrote:
>>
>> No, it is not a typo, but intentional.
>>
>>
>> i2c0 - i2c3 are connected to the pads of the SoC package.
>> On the other hand, i2c-4 - i2c-6 are connected to
>> internal devices inside the SoC package.
>>
>> i2c-4 - i2c-6 are always connected to the same hardware
>> devices and always used for the same purpose.
>>
>>
>> My expected scenario is:
>>
>> [1] i2c0 - i2c3 are connected to the on-board devices
>>     depending on board variants.
>>     On some boards, their status is "okay" and
>>     on some boards, their status is "disabled".
>>
>> [2] i2c4 - i2c6 are always used to communicate
>>     with in-package devices.  The status is always "okay".
>
> I think you are getting confused because the data sheet uses
> the same names as the kernel, but they are really different
> things.
>
> How about boards that have i2c connectors that are labeled
> differently?


I guess it would rarely happen as it is confusing.

The board connectors are generally named
correspondingly to the hardware block ID in the SoC.



> We want the aliases to match whatever is written on the
> board normally, to make it easier for users.
>
>> [3] Some user-land applications may want to have access
>>      through the same character devices,
>>       /dev/i2c4, /dev/i2c5, /dev/i2c6
>
> That user space would however only work on boards with the
> same SoC, which is not a safe assumption to make.

Right.

> Either
> it should be specific to just one board which has a known
> set of buses, or it should be done in a way that works
> across SoC generations of families.
>
> Ideally the devices on the internal buses would have an
> in-kernel driver that exports a high-level API to avoid this
> problem. What devices are these?

HDMI transmitter, TV signal demodulator, etc.



>> If your way is adopted,
>> the real hardware "i2c4" might be aligned to /dev/i2c1 on some boards,
>> and /dev/i2c2 on others, etc.
>
> Right, I think that is how it should be. You could also make
> the chip's i2c4 always link to user space /dev/i2c0 if you
> want to keep those stable, but as I said that is still not
> a good (software) system design.
>

Right.  In-kernel drivers can handle it nicely.

Also, we can write a device tree that specifies device connection
hierarchy like follows.
The device names will appear under /sys/ directory and user-land
applications can check them.

&i2c4 {
        demodulator {
                 compatible = "...";

        };
};

&i2c6 {
         hdmi_tx {

                   compatible = "...";
         };
}


I understand that I2C bus number assumption is avoidable,
but I am still not fully convinced.

Matching /dev/i2c* and the real hardware block ID (this is written in
the SoC spec book)
makes things clearer, I think.



-- 
Best Regards
Masahiro Yamada

[PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support

[Masahiro Yamada]

Hi Arnd,


2015-10-16 18:50 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> Hi Arnd,
>
> 2015-10-16 18:18 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
>> On Friday 16 October 2015 14:24:30 Masahiro Yamada wrote:
>>>
>>> No, it is not a typo, but intentional.
>>>
>>>
>>> i2c0 - i2c3 are connected to the pads of the SoC package.
>>> On the other hand, i2c-4 - i2c-6 are connected to
>>> internal devices inside the SoC package.
>>>
>>> i2c-4 - i2c-6 are always connected to the same hardware
>>> devices and always used for the same purpose.
>>>
>>>
>>> My expected scenario is:
>>>
>>> [1] i2c0 - i2c3 are connected to the on-board devices
>>>     depending on board variants.
>>>     On some boards, their status is "okay" and
>>>     on some boards, their status is "disabled".
>>>
>>> [2] i2c4 - i2c6 are always used to communicate
>>>     with in-package devices.  The status is always "okay".
>>
>> I think you are getting confused because the data sheet uses
>> the same names as the kernel, but they are really different
>> things.
>>
>> How about boards that have i2c connectors that are labeled
>> differently?
>
>
> I guess it would rarely happen as it is confusing.
>
> The board connectors are generally named
> correspondingly to the hardware block ID in the SoC.
>
>
>
>> We want the aliases to match whatever is written on the
>> board normally, to make it easier for users.
>>
>>> [3] Some user-land applications may want to have access
>>>      through the same character devices,
>>>       /dev/i2c4, /dev/i2c5, /dev/i2c6
>>
>> That user space would however only work on boards with the
>> same SoC, which is not a safe assumption to make.
>
> Right.
>
>> Either
>> it should be specific to just one board which has a known
>> set of buses, or it should be done in a way that works
>> across SoC generations of families.
>>
>> Ideally the devices on the internal buses would have an
>> in-kernel driver that exports a high-level API to avoid this
>> problem. What devices are these?
>
> HDMI transmitter, TV signal demodulator, etc.
>
>
>
>>> If your way is adopted,
>>> the real hardware "i2c4" might be aligned to /dev/i2c1 on some boards,
>>> and /dev/i2c2 on others, etc.
>>
>> Right, I think that is how it should be. You could also make
>> the chip's i2c4 always link to user space /dev/i2c0 if you
>> want to keep those stable, but as I said that is still not
>> a good (software) system design.
>>
>
> Right.  In-kernel drivers can handle it nicely.
>
> Also, we can write a device tree that specifies device connection
> hierarchy like follows.
> The device names will appear under /sys/ directory and user-land
> applications can check them.
>
> &i2c4 {
>         demodulator {
>                  compatible = "...";
>
>         };
> };
>
> &i2c6 {
>          hdmi_tx {
>
>                    compatible = "...";
>          };
> }
>
>
> I understand that I2C bus number assumption is avoidable,
> but I am still not fully convinced.
>
> Matching /dev/i2c* and the real hardware block ID (this is written in
> the SoC spec book)
> makes things clearer, I think.
>


Anyway, this version is unacceptable, right?





-- 
Best Regards
Masahiro Yamada

[PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support

[Arnd Bergmann]

On Wednesday 21 October 2015 17:49:12 Masahiro Yamada wrote:
> > Right.  In-kernel drivers can handle it nicely.
> >
> > Also, we can write a device tree that specifies device connection
> > hierarchy like follows.
> > The device names will appear under /sys/ directory and user-land
> > applications can check them.
> >
> > &i2c4 {
> >         demodulator {
> >                  compatible = "...";
> >
> >         };
> > };
> >
> > &i2c6 {
> >          hdmi_tx {
> >
> >                    compatible = "...";
> >          };
> > }
> >
> >
> > I understand that I2C bus number assumption is avoidable,
> > but I am still not fully convinced.
> >
> > Matching /dev/i2c* and the real hardware block ID (this is written in
> > the SoC spec book)
> > makes things clearer, I think.
> >
> 
> 
> Anyway, this version is unacceptable, right?

Sorry for the late reply.

I would not call it unacceptable, just a bit unpleasant. We can merge it
if you cannot come up with a nicer way to do this. It was a good idea
to split to resend the series without this patch, but the replacement
to delete the aliases also doesn't look nice. If we can't come up with
a better way to do this, I'd suggest you re-send this patch and add a
bit more explanation into the changelog as to why you want this to
be done in an unusual way.

	Arnd

[PATCH 3/3] ARM: dts: uniphier: add ProXstream2 Gentil board support

[Masahiro Yamada]

Initial version of DTS for ProXstream2 Gentil board.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 arch/arm/boot/dts/Makefile                        |  1 +
 arch/arm/boot/dts/uniphier-proxstream2-gentil.dts | 79 +++++++++++++++++++++++
 2 files changed, 80 insertions(+)
 create mode 100644 arch/arm/boot/dts/uniphier-proxstream2-gentil.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9232018..2e1bc82 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -673,6 +673,7 @@ dtb-$(CONFIG_ARCH_UNIPHIER) += \
 	uniphier-ph1-pro4-ref.dtb \
 	uniphier-ph1-sld3-ref.dtb \
 	uniphier-ph1-sld8-ref.dtb \
+	uniphier-proxstream2-gentil.dtb \
 	uniphier-proxstream2-vodka.dtb
 dtb-$(CONFIG_ARCH_VERSATILE) += \
 	versatile-ab.dtb \
diff --git a/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
new file mode 100644
index 0000000..3ea2a87
--- /dev/null
+++ b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
@@ -0,0 +1,79 @@
+/*
+ * Device Tree Source for UniPhier ProXstream2 Gentil Board
+ *
+ * Copyright (C) 2015 Masahiro Yamada <yamada.masahiro@socionext.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+/include/ "uniphier-proxstream2.dtsi"
+
+/ {
+	model = "UniPhier ProXstream2 Gentil Board";
+	compatible = "socionext,proxstream2-gentil", "socionext,proxstream2";
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x80000000>;
+	};
+
+	chosen {
+		bootargs = "console=ttyS2,115200";
+		stdout-path = &serial2;
+	};
+
+	aliases {
+		serial0 = &serial0;
+		serial1 = &serial1;
+		serial2 = &serial2;
+		i2c0 = &i2c0;
+		i2c4 = &i2c4;
+		i2c5 = &i2c5;
+		i2c6 = &i2c6;
+	};
+};
+
+&serial2 {
+	status = "okay";
+};
+
+&i2c0 {
+	status = "okay";
+};
-- 
1.9.1

[PATCH 0/3] ARM: dts: uniphier: DTS updates for UniPhier SoCs for Linux 4.14-rc1

[Arnd Bergmann]

On Thursday 15 October 2015 18:05:31 Masahiro Yamada wrote:
> Hi Olof and Arnd,
> 
> Please apply this series to ARM-SOC for the next merge window.
> 

Applied the first patch, but not the other two, which look slightly wrong.
Can you check and send them again?

	Arnd