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

Message ID 1444899934-4754-3-git-send-email-yamada.masahiro@socionext.com
State New, archived
Headers show

Commit Message

Masahiro Yamada Oct. 15, 2015, 9:05 a.m. UTC
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

Comments

Arnd Bergmann Oct. 15, 2015, 3:17 p.m. UTC | #1
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
Masahiro Yamada Oct. 16, 2015, 5:24 a.m. UTC | #2
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.
Arnd Bergmann Oct. 16, 2015, 9:18 a.m. UTC | #3
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
Masahiro Yamada Oct. 16, 2015, 9:50 a.m. UTC | #4
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.
Masahiro Yamada Oct. 21, 2015, 8:49 a.m. UTC | #5
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?
Arnd Bergmann Oct. 23, 2015, 8:10 p.m. UTC | #6
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
diff mbox

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";
+};