| Message ID | 1444899934-4754-3-git-send-email-yamada.masahiro@socionext.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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.
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
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.
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?
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
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"; +};
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