Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1247589 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support Masahiro Yamada <yamada.masahiro@socionext.com> - 2015-10-15 11:10 +0200
    Re: [PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support Arnd Bergmann <arnd@arndb.de> - 2015-10-15 17:20 +0200
      Re: [PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support Masahiro Yamada <yamada.masahiro@socionext.com> - 2015-10-16 07:30 +0200
        Re: [PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support Arnd Bergmann <arnd@arndb.de> - 2015-10-16 11:20 +0200
          Re: [PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support Masahiro Yamada <yamada.masahiro@socionext.com> - 2015-10-16 12:00 +0200

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

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1247878

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1248340

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1248507

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1248538

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web