[PATCH 00/14] Add minimal DTS support for M3-N Starter Kit

[PATCH 00/14] Add minimal DTS support for M3-N Starter Kit

[Eugeniu Rosca]

Hello Renesas community,

This patch series arised during the bring-up of M3-N-based ULCB board.
It adds minimal DTS support and documents some new DT bindings.

It also does some collateral changes in the area of ULCB compatible
strings, to avoid defining something like "renesas,m3nulcb". Similar to
how "renesas,salvator-x{s}" compatibles are constructed, in my opinion,
"renesas,(m3|m3n|h3)ulcb" should not use the SoC model in their name,
for consistency.

Another change done in preparation of the M3-N DTS commits is renaming
the ULCB device trees:
 - from "<SoC>-<SoC>ulcb*.dts"
 - to   "<SoC>-ulcb*.dts"

These patches have been tested on M3-N ULCB using v4.18-rc7 kernel.
Any comments would be greatly appreciated.

Best regards,
Eugeniu.

Eugeniu Rosca (14):
  arm64: dts: renesas: Cut redundant <SoC> in *<SoC>-<SoC>ulcb*.dts
  dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible
  arm64: dts: renesas: r8a7795-es1: ulcb: Use "renesas,ulcb" compatible
  arm64: dts: renesas: r8a7795-es1: ulcb-kf: Use "renesas,ulcb" compatible
  arm64: dts: renesas: r8a7795: ulcb: Use "renesas,ulcb" compatible
  arm64: dts: renesas: r8a7795: ulcb-kf: Use "renesas,ulcb" compatible
  arm64: dts: renesas: r8a7796: ulcb: Use "renesas,ulcb" compatible
  arm64: dts: renesas: r8a7796: ulcb-kf: Use "renesas,ulcb" compatible
  dt-bindings: arm: Document Renesas R-Car M3-N-based ULCB board
  arm64: dts: renesas: r8a77965: ulcb: Initial device tree
  dt-bindings: can: rcar_can: document r8a77965 can support
  arm64: dts: renesas: r8a77965: add CAN support
  arm64: dts: renesas: r8a77965: Add HSCIF0 device node
  arm64: dts: renesas: r8a77965: ulcb-kf: Initial device tree

 .../devicetree/bindings/arm/shmobile.txt      |  6 ++-
 .../devicetree/bindings/net/can/rcar_can.txt  | 10 ++--
 arch/arm64/boot/dts/renesas/Makefile          | 14 +++---
 ...-h3ulcb-kf.dts => r8a7795-es1-ulcb-kf.dts} |  4 +-
 ...95-es1-h3ulcb.dts => r8a7795-es1-ulcb.dts} |  2 +-
 ...7795-h3ulcb-kf.dts => r8a7795-ulcb-kf.dts} |  4 +-
 .../{r8a7795-h3ulcb.dts => r8a7795-ulcb.dts}  |  2 +-
 ...7796-m3ulcb-kf.dts => r8a7796-ulcb-kf.dts} |  4 +-
 .../{r8a7796-m3ulcb.dts => r8a7796-ulcb.dts}  |  2 +-
 .../boot/dts/renesas/r8a77965-ulcb-kf.dts     | 20 ++++++++
 arch/arm64/boot/dts/renesas/r8a77965-ulcb.dts | 37 ++++++++++++++
 arch/arm64/boot/dts/renesas/r8a77965.dtsi     | 50 +++++++++++++++++++
 12 files changed, 135 insertions(+), 20 deletions(-)
 rename arch/arm64/boot/dts/renesas/{r8a7795-es1-h3ulcb-kf.dts => r8a7795-es1-ulcb-kf.dts} (84%)
 rename arch/arm64/boot/dts/renesas/{r8a7795-es1-h3ulcb.dts => r8a7795-es1-ulcb.dts} (94%)
 rename arch/arm64/boot/dts/renesas/{r8a7795-h3ulcb-kf.dts => r8a7795-ulcb-kf.dts} (84%)
 rename arch/arm64/boot/dts/renesas/{r8a7795-h3ulcb.dts => r8a7795-ulcb.dts} (96%)
 rename arch/arm64/boot/dts/renesas/{r8a7796-m3ulcb-kf.dts => r8a7796-ulcb-kf.dts} (84%)
 rename arch/arm64/boot/dts/renesas/{r8a7796-m3ulcb.dts => r8a7796-ulcb.dts} (95%)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dts
 create mode 100644 arch/arm64/boot/dts/renesas/r8a77965-ulcb.dts

-- 
2.18.0

[PATCH 01/14] arm64: dts: renesas: Cut redundant <SoC> in *<SoC>-<SoC>ulcb*.dts

[Eugeniu Rosca]

Perform a 's/(h|m)3ulcb/ulcb/' substitution in below DTS filenames:
 - r8a7795-es1-h3ulcb.dts    => r8a7795-es1-ulcb.dts
 - r8a7795-es1-h3ulcb-kf.dts => r8a7795-es1-ulcb-kf.dts
 - r8a7795-h3ulcb.dts        => r8a7795-ulcb.dts
 - r8a7795-h3ulcb-kf.dts     => r8a7795-ulcb-kf.dts
 - r8a7796-m3ulcb.dts        => r8a7796-ulcb.dts
 - r8a7796-m3ulcb-kf.dts     => r8a7796-ulcb-kf.dts

The background of this commit is M3-N ULCB (RTP0RC77965SKBX010SA00)
bring-up, which (assuming no change in existing DTS name patterns)
requires two new DTS files:
 - r8a77965-m3nulcb.dts
 - r8a77965-m3nulcb-kf.dts

In all above examples:
 - "m3n" prefix is redundant, since r8a77965 denotes the M3-N SoC
 - "m3"  prefix is redundant, since r8a7796  denotes the M3/M3-W SoC
 - "h3"  prefix is redundant, since r8a7795  denotes the H3 SoC

To make the DTS naming conventions consistent, drop the unneeded
prefixes. Similar reasoning was applied by Marek in U-Boot v2017.09
commit bd39050cb2a0 ("ARM: rmobile: ulcb: Add ULCB board support"):

$ git log -1 --format= --name-only bd39050cb2a -- "*defconfig"
configs/r8a7795_ulcb_defconfig
configs/r8a7796_ulcb_defconfig

DTB md5 sums match with and w/o the patch (hence no functional change).

Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
---
 arch/arm64/boot/dts/renesas/Makefile                                               | 12 ++++++------
 arch/arm64/boot/dts/renesas/{r8a7795-es1-h3ulcb-kf.dts => r8a7795-es1-ulcb-kf.dts} |  2 +-
 arch/arm64/boot/dts/renesas/{r8a7795-es1-h3ulcb.dts => r8a7795-es1-ulcb.dts}       |  0
 arch/arm64/boot/dts/renesas/{r8a7795-h3ulcb-kf.dts => r8a7795-ulcb-kf.dts}         |  2 +-
 arch/arm64/boot/dts/renesas/{r8a7795-h3ulcb.dts => r8a7795-ulcb.dts}               |  0
 arch/arm64/boot/dts/renesas/{r8a7796-m3ulcb-kf.dts => r8a7796-ulcb-kf.dts}         |  2 +-
 arch/arm64/boot/dts/renesas/{r8a7796-m3ulcb.dts => r8a7796-ulcb.dts}               |  0
 7 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
index 9e2394bc3c62..5debb02fad2c 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -1,11 +1,11 @@
 # SPDX-License-Identifier: GPL-2.0
-dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-x.dtb r8a7795-h3ulcb.dtb
-dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-h3ulcb-kf.dtb
+dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-x.dtb r8a7795-ulcb.dtb
+dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-ulcb-kf.dtb
 dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-xs.dtb
-dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-es1-salvator-x.dtb r8a7795-es1-h3ulcb.dtb
-dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-es1-h3ulcb-kf.dtb
-dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb r8a7796-m3ulcb.dtb
-dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-m3ulcb-kf.dtb
+dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-es1-salvator-x.dtb r8a7795-es1-ulcb.dtb
+dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-es1-ulcb-kf.dtb
+dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb r8a7796-ulcb.dtb
+dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-ulcb-kf.dtb
 dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-xs.dtb
 dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-salvator-x.dtb r8a77965-salvator-xs.dtb
 dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle.dtb r8a77970-v3msk.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dts b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
similarity index 93%
rename from arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dts
rename to arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
index 009cb1cb0dde..06deb67c36c8 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
@@ -9,7 +9,7 @@
  * kind, whether express or implied.
  */
 
-#include "r8a7795-es1-h3ulcb.dts"
+#include "r8a7795-es1-ulcb.dts"
 #include "ulcb-kf.dtsi"
 
 / {
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb.dts
similarity index 100%
rename from arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts
rename to arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb.dts
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dts b/arch/arm64/boot/dts/renesas/r8a7795-ulcb-kf.dts
similarity index 94%
rename from arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dts
rename to arch/arm64/boot/dts/renesas/r8a7795-ulcb-kf.dts
index 4403227c0f97..70a0c5332d54 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-ulcb-kf.dts
@@ -9,7 +9,7 @@
  * kind, whether express or implied.
  */
 
-#include "r8a7795-h3ulcb.dts"
+#include "r8a7795-ulcb.dts"
 #include "ulcb-kf.dtsi"
 
 / {
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-ulcb.dts
similarity index 100%
rename from arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
rename to arch/arm64/boot/dts/renesas/r8a7795-ulcb.dts
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dts b/arch/arm64/boot/dts/renesas/r8a7796-ulcb-kf.dts
similarity index 94%
rename from arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dts
rename to arch/arm64/boot/dts/renesas/r8a7796-ulcb-kf.dts
index de2390f009e7..faa32c28eef7 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-ulcb-kf.dts
@@ -9,7 +9,7 @@
  * kind, whether express or implied.
  */
 
-#include "r8a7796-m3ulcb.dts"
+#include "r8a7796-ulcb.dts"
 #include "ulcb-kf.dtsi"
 
 / {
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-ulcb.dts
similarity index 100%
rename from arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
rename to arch/arm64/boot/dts/renesas/r8a7796-ulcb.dts
-- 
2.18.0

Re: [PATCH 01/14] arm64: dts: renesas: Cut redundant <SoC> in *<SoC>-<SoC>ulcb*.dts

[Laurent Pinchart]

Hello Eugeniu,

Thank you for the patch.

On Sunday, 5 August 2018 02:11:01 EEST Eugeniu Rosca wrote:
> Perform a 's/(h|m)3ulcb/ulcb/' substitution in below DTS filenames:
>  - r8a7795-es1-h3ulcb.dts    => r8a7795-es1-ulcb.dts
>  - r8a7795-es1-h3ulcb-kf.dts => r8a7795-es1-ulcb-kf.dts
>  - r8a7795-h3ulcb.dts        => r8a7795-ulcb.dts
>  - r8a7795-h3ulcb-kf.dts     => r8a7795-ulcb-kf.dts
>  - r8a7796-m3ulcb.dts        => r8a7796-ulcb.dts
>  - r8a7796-m3ulcb-kf.dts     => r8a7796-ulcb-kf.dts
> 
> The background of this commit is M3-N ULCB (RTP0RC77965SKBX010SA00)
> bring-up, which (assuming no change in existing DTS name patterns)
> requires two new DTS files:
>  - r8a77965-m3nulcb.dts
>  - r8a77965-m3nulcb-kf.dts
> 
> In all above examples:
>  - "m3n" prefix is redundant, since r8a77965 denotes the M3-N SoC
>  - "m3"  prefix is redundant, since r8a7796  denotes the M3/M3-W SoC
>  - "h3"  prefix is redundant, since r8a7795  denotes the H3 SoC

The naming convention is roughly <soc>-<board>.dts. For instance, in r8a7795-
h3ulcb.dts, the SoC is R8A7795 and the board "H3 ULCB". With the proposed 
rename we would break that convention.

However, the name ULCB itself (which stands for Ultra Low Cost Board) might 
already not follow the naming convention, as the boards are officially called 
R-Car Starter Kit (Pro and Premier). The V3M and V3H "low-cost" boards reflect 
that properly, with their .dts files named r8a77970-v3msk.dts and r8a77970-
v3hsk.dts respectively.

I'm not opposed to simplifying the file names, but I think we should then 
decide on a simpler convention. In particular the H3/M3 and V3 .dts files 
should in my opinion follow the same convention.

I'll now let others comment on this as I don't have such a strong opinion on 
this topic.

> To make the DTS naming conventions consistent, drop the unneeded
> prefixes. Similar reasoning was applied by Marek in U-Boot v2017.09
> commit bd39050cb2a0 ("ARM: rmobile: ulcb: Add ULCB board support"):
> 
> $ git log -1 --format= --name-only bd39050cb2a -- "*defconfig"
> configs/r8a7795_ulcb_defconfig
> configs/r8a7796_ulcb_defconfig
> 
> DTB md5 sums match with and w/o the patch (hence no functional change).
> 
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> ---
>  arch/arm64/boot/dts/renesas/Makefile                                       
>        | 12 ++++++------
> arch/arm64/boot/dts/renesas/{r8a7795-es1-h3ulcb-kf.dts =>
> r8a7795-es1-ulcb-kf.dts} |  2 +-
> arch/arm64/boot/dts/renesas/{r8a7795-es1-h3ulcb.dts =>
> r8a7795-es1-ulcb.dts}       |  0
> arch/arm64/boot/dts/renesas/{r8a7795-h3ulcb-kf.dts => r8a7795-ulcb-kf.dts} 
>        |  2 +- arch/arm64/boot/dts/renesas/{r8a7795-h3ulcb.dts =>
> r8a7795-ulcb.dts}               |  0
> arch/arm64/boot/dts/renesas/{r8a7796-m3ulcb-kf.dts => r8a7796-ulcb-kf.dts} 
>        |  2 +- arch/arm64/boot/dts/renesas/{r8a7796-m3ulcb.dts =>
> r8a7796-ulcb.dts}               |  0 7 files changed, 9 insertions(+), 9
> deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/renesas/Makefile
> b/arch/arm64/boot/dts/renesas/Makefile index 9e2394bc3c62..5debb02fad2c
> 100644
> --- a/arch/arm64/boot/dts/renesas/Makefile
> +++ b/arch/arm64/boot/dts/renesas/Makefile
> @@ -1,11 +1,11 @@
>  # SPDX-License-Identifier: GPL-2.0
> -dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-x.dtb r8a7795-h3ulcb.dtb
> -dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-h3ulcb-kf.dtb
> +dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-x.dtb r8a7795-ulcb.dtb
> +dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-ulcb-kf.dtb
>  dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-xs.dtb
> -dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-es1-salvator-x.dtb
> r8a7795-es1-h3ulcb.dtb -dtb-$(CONFIG_ARCH_R8A7795) +=
> r8a7795-es1-h3ulcb-kf.dtb
> -dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb r8a7796-m3ulcb.dtb
> -dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-m3ulcb-kf.dtb
> +dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-es1-salvator-x.dtb
> r8a7795-es1-ulcb.dtb +dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-es1-ulcb-kf.dtb
> +dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb r8a7796-ulcb.dtb
> +dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-ulcb-kf.dtb
>  dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-xs.dtb
>  dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-salvator-x.dtb
> r8a77965-salvator-xs.dtb dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle.dtb
> r8a77970-v3msk.dtb diff --git
> a/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dts
> b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts similarity index 93%
> rename from arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dts
> rename to arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
> index 009cb1cb0dde..06deb67c36c8 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
> @@ -9,7 +9,7 @@
>   * kind, whether express or implied.
>   */
> 
> -#include "r8a7795-es1-h3ulcb.dts"
> +#include "r8a7795-es1-ulcb.dts"
>  #include "ulcb-kf.dtsi"
> 
>  / {
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts
> b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb.dts similarity index 100%
> rename from arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts
> rename to arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb.dts
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dts
> b/arch/arm64/boot/dts/renesas/r8a7795-ulcb-kf.dts similarity index 94%
> rename from arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dts
> rename to arch/arm64/boot/dts/renesas/r8a7795-ulcb-kf.dts
> index 4403227c0f97..70a0c5332d54 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-ulcb-kf.dts
> @@ -9,7 +9,7 @@
>   * kind, whether express or implied.
>   */
> 
> -#include "r8a7795-h3ulcb.dts"
> +#include "r8a7795-ulcb.dts"
>  #include "ulcb-kf.dtsi"
> 
>  / {
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> b/arch/arm64/boot/dts/renesas/r8a7795-ulcb.dts similarity index 100%
> rename from arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> rename to arch/arm64/boot/dts/renesas/r8a7795-ulcb.dts
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dts
> b/arch/arm64/boot/dts/renesas/r8a7796-ulcb-kf.dts similarity index 94%
> rename from arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dts
> rename to arch/arm64/boot/dts/renesas/r8a7796-ulcb-kf.dts
> index de2390f009e7..faa32c28eef7 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7796-ulcb-kf.dts
> @@ -9,7 +9,7 @@
>   * kind, whether express or implied.
>   */
> 
> -#include "r8a7796-m3ulcb.dts"
> +#include "r8a7796-ulcb.dts"
>  #include "ulcb-kf.dtsi"
> 
>  / {
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
> b/arch/arm64/boot/dts/renesas/r8a7796-ulcb.dts similarity index 100%
> rename from arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
> rename to arch/arm64/boot/dts/renesas/r8a7796-ulcb.dts


-- 
Regards,

Laurent Pinchart

Re: [PATCH 01/14] arm64: dts: renesas: Cut redundant <SoC> in *<SoC>-<SoC>ulcb*.dts

[Simon Horman]

On Mon, Aug 06, 2018 at 01:35:08PM +0300, Laurent Pinchart wrote:
> Hello Eugeniu,
> 
> Thank you for the patch.
> 
> On Sunday, 5 August 2018 02:11:01 EEST Eugeniu Rosca wrote:
> > Perform a 's/(h|m)3ulcb/ulcb/' substitution in below DTS filenames:
> >  - r8a7795-es1-h3ulcb.dts    => r8a7795-es1-ulcb.dts
> >  - r8a7795-es1-h3ulcb-kf.dts => r8a7795-es1-ulcb-kf.dts
> >  - r8a7795-h3ulcb.dts        => r8a7795-ulcb.dts
> >  - r8a7795-h3ulcb-kf.dts     => r8a7795-ulcb-kf.dts
> >  - r8a7796-m3ulcb.dts        => r8a7796-ulcb.dts
> >  - r8a7796-m3ulcb-kf.dts     => r8a7796-ulcb-kf.dts
> > 
> > The background of this commit is M3-N ULCB (RTP0RC77965SKBX010SA00)
> > bring-up, which (assuming no change in existing DTS name patterns)
> > requires two new DTS files:
> >  - r8a77965-m3nulcb.dts
> >  - r8a77965-m3nulcb-kf.dts
> > 
> > In all above examples:
> >  - "m3n" prefix is redundant, since r8a77965 denotes the M3-N SoC
> >  - "m3"  prefix is redundant, since r8a7796  denotes the M3/M3-W SoC
> >  - "h3"  prefix is redundant, since r8a7795  denotes the H3 SoC
> 
> The naming convention is roughly <soc>-<board>.dts. For instance, in r8a7795-
> h3ulcb.dts, the SoC is R8A7795 and the board "H3 ULCB". With the proposed 
> rename we would break that convention.
> 
> However, the name ULCB itself (which stands for Ultra Low Cost Board) might 
> already not follow the naming convention, as the boards are officially called 
> R-Car Starter Kit (Pro and Premier). The V3M and V3H "low-cost" boards reflect 
> that properly, with their .dts files named r8a77970-v3msk.dts and r8a77970-
> v3hsk.dts respectively.
> 
> I'm not opposed to simplifying the file names, but I think we should then 
> decide on a simpler convention. In particular the H3/M3 and V3 .dts files 
> should in my opinion follow the same convention.
> 
> I'll now let others comment on this as I don't have such a strong opinion on 
> this topic.

At this point I'd prefer to keep the current, albeit imperfect scheme,
and avoid churn.

Re: [PATCH 01/14] arm64: dts: renesas: Cut redundant <SoC> in *<SoC>-<SoC>ulcb*.dts

[Eugeniu Rosca]

Hi Simon, Laurent,

On Fri, Aug 10, 2018 at 01:22:49PM +0200, Simon Horman wrote:
> On Mon, Aug 06, 2018 at 01:35:08PM +0300, Laurent Pinchart wrote:
[snip]
> > The naming convention is roughly <soc>-<board>.dts. For instance, in r8a7795-
> > h3ulcb.dts, the SoC is R8A7795 and the board "H3 ULCB". With the proposed 
> > rename we would break that convention.
> > 
> > However, the name ULCB itself (which stands for Ultra Low Cost Board) might 
> > already not follow the naming convention, as the boards are officially called 
> > R-Car Starter Kit (Pro and Premier). The V3M and V3H "low-cost" boards reflect 
> > that properly, with their .dts files named r8a77970-v3msk.dts and r8a77970-
> > v3hsk.dts respectively.
> > 
> > I'm not opposed to simplifying the file names, but I think we should then 
> > decide on a simpler convention. In particular the H3/M3 and V3 .dts files 
> > should in my opinion follow the same convention.
> > 
> > I'll now let others comment on this as I don't have such a strong opinion on 
> > this topic.
> 
> At this point I'd prefer to keep the current, albeit imperfect scheme,
> and avoid churn.

To be able to push a v2, I interpret this input as using below strings
for the newly supported M3-N Starter Kit board:
 - r8a77965-m3nulcb.dts and r8a77965-m3nulcb-kf.dts for device tree sources
 - "renesas,m3nulcb" for compatible string
 - M3NULCB for board name in the shmobile.txt DT bindings

I still think there is some redundancy in this naming scheme, but I can
live with that.

Thanks,
Eugeniu.

[PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible

[Eugeniu Rosca]

In the context of M3N-ULCB (RTP0RC77965SKBX010SA00) board bring-up, it's
rather pointless to add a new "renesas,m3nulcb" compatible string. Any
SoC-level differences between the two variants of ULCB (M3 and M3-N)
should be successfully covered by making use of existing
"renesas,r8a7796" and "renesas,r8a77965" compatibles.

Prior to adding M3-N Starter Kit to the list, rename:
 - "renesas,h3ulcb" => "renesas,ulcb"
 - "renesas,m3ulcb" => "renesas,ulcb"

Relevant DTS changes come in separate per-DTS commits.

Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
---
 Documentation/devicetree/bindings/arm/shmobile.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index d8cf740132c6..f391dba10574 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -81,7 +81,7 @@ Boards:
     compatible = "renesas,gose", "renesas,r8a7793"
   - H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1))
     H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0))
-    compatible = "renesas,h3ulcb", "renesas,r8a7795"
+    compatible = "renesas,ulcb", "renesas,r8a7795"
   - Henninger
     compatible = "renesas,henninger", "renesas,r8a7791"
   - iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S)
@@ -105,7 +105,7 @@ Boards:
   - Lager (RTP0RC7790SEB00010S)
     compatible = "renesas,lager", "renesas,r8a7790"
   - M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0))
-    compatible = "renesas,m3ulcb", "renesas,r8a7796"
+    compatible = "renesas,ulcb", "renesas,r8a7796"
   - Marzen (R0P7779A00010S)
     compatible = "renesas,marzen", "renesas,r8a7779"
   - Porter (M2-LCDP)
-- 
2.18.0

Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible

[Kuninori Morimoto]

Hi Eugeniu

> In the context of M3N-ULCB (RTP0RC77965SKBX010SA00) board bring-up, it's
> rather pointless to add a new "renesas,m3nulcb" compatible string. Any
> SoC-level differences between the two variants of ULCB (M3 and M3-N)
> should be successfully covered by making use of existing
> "renesas,r8a7796" and "renesas,r8a77965" compatibles.
> 
> Prior to adding M3-N Starter Kit to the list, rename:
>  - "renesas,h3ulcb" => "renesas,ulcb"
>  - "renesas,m3ulcb" => "renesas,ulcb"

I'm not sure detail, but
does it mean, both H3/M3 board can boot/work with
"renesas,ulcb" compatible if we had such driver/soc ?

> diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
> index d8cf740132c6..f391dba10574 100644
> --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> @@ -81,7 +81,7 @@ Boards:
>      compatible = "renesas,gose", "renesas,r8a7793"
>    - H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1))
>      H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0))
> -    compatible = "renesas,h3ulcb", "renesas,r8a7795"
> +    compatible = "renesas,ulcb", "renesas,r8a7795"
>    - Henninger
>      compatible = "renesas,henninger", "renesas,r8a7791"
>    - iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S)
> @@ -105,7 +105,7 @@ Boards:
>    - Lager (RTP0RC7790SEB00010S)
>      compatible = "renesas,lager", "renesas,r8a7790"
>    - M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0))
> -    compatible = "renesas,m3ulcb", "renesas,r8a7796"
> +    compatible = "renesas,ulcb", "renesas,r8a7796"
>    - Marzen (R0P7779A00010S)
>      compatible = "renesas,marzen", "renesas,r8a7779"
>    - Porter (M2-LCDP)

My opinion is that if you want to exchange compatible name,
related all driver/document should be exchanged in same patch.

For example, above "h3ulcb" case, patch subject indicates
"rename h3ulcb" or something, and it include [03/14][04/14][05/14][06/14].
Same for m3

Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible

[Eugeniu Rosca]

Hi Morimoto-san,

Thank you for your comments.

On Mon, Aug 06, 2018 at 12:33:34AM +0000, Kuninori Morimoto wrote:
> Hi Eugeniu
> 
> > In the context of M3N-ULCB (RTP0RC77965SKBX010SA00) board bring-up, it's
> > rather pointless to add a new "renesas,m3nulcb" compatible string. Any
> > SoC-level differences between the two variants of ULCB (M3 and M3-N)
> > should be successfully covered by making use of existing
> > "renesas,r8a7796" and "renesas,r8a77965" compatibles.
> > 
> > Prior to adding M3-N Starter Kit to the list, rename:
> >  - "renesas,h3ulcb" => "renesas,ulcb"
> >  - "renesas,m3ulcb" => "renesas,ulcb"
> 
> I'm not sure detail, but
> does it mean, both H3/M3 board can boot/work with
> "renesas,ulcb" compatible if we had such driver/soc ?

First, assuming latest vanilla v4.18-rc8 kernel, neither
"renesas,salvator-x[s]" nor "renesas,(m3|h3)ulcb" compatibles are
used anywhere outside of DTS and DT bindings documentation:

$ git grep -E --name-only "renesas,(h3ulcb|m3ulcb|salvator-x)" | xargs dirname | sort -u
arch/arm64/boot/dts/renesas
Documentation/devicetree/bindings/arm

Since there is no driver using these compatibles, no functional
breakage is expected by changing the compatible format/name.

Secondly, as pointed out in the commit summary line and description,
there is an overlap in scope between the SoC-level compatibles and
ULCB board-level compatibles, which doesn't happen for Salvator-X{S}
targets and creates some inconsistency. This inconsistency now spawns
debates about how other ULCB-based board compatibles should be named and
for that single reason IMO should be fixed.

Lastly, I don't think any driver will ever need to use
"renesas,(m3|m3n|h3)ulcb" string, since it is too broad. On/off-chip
IP-oriented compatibles are probably better candidates for that.

> 
> > diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
> > index d8cf740132c6..f391dba10574 100644
> > --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> > +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> > @@ -81,7 +81,7 @@ Boards:
> >      compatible = "renesas,gose", "renesas,r8a7793"
> >    - H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1))
> >      H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0))
> > -    compatible = "renesas,h3ulcb", "renesas,r8a7795"
> > +    compatible = "renesas,ulcb", "renesas,r8a7795"
> >    - Henninger
> >      compatible = "renesas,henninger", "renesas,r8a7791"
> >    - iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S)
> > @@ -105,7 +105,7 @@ Boards:
> >    - Lager (RTP0RC7790SEB00010S)
> >      compatible = "renesas,lager", "renesas,r8a7790"
> >    - M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0))
> > -    compatible = "renesas,m3ulcb", "renesas,r8a7796"
> > +    compatible = "renesas,ulcb", "renesas,r8a7796"
> >    - Marzen (R0P7779A00010S)
> >      compatible = "renesas,marzen", "renesas,r8a7779"
> >    - Porter (M2-LCDP)
> 
> My opinion is that if you want to exchange compatible name,
> related all driver/document should be exchanged in same patch.

AFAIK Simon maintains a number of branches hosting solely the DT
bindings. More precisely it is the "dt-bindings-for-v4.*" branch series
in https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git

For that reason, IMO it might be worth to detach the document updates
from DTS updates. I have no problems squashing the DTS and doc patches
into one single commit, but before doing that I would appreciate a
confirmation from the maintainer. Anyhow, many thanks for your feedback!

> 
> For example, above "h3ulcb" case, patch subject indicates
> "rename h3ulcb" or something, and it include [03/14][04/14][05/14][06/14].
> Same for m3

It was my impression that the DTS patches are always partitioned
per-file, to avoid misleading globbing patterns in the commit subjects
and allow easier DTS commit porting to future SoCs/boards. I will
gladly follow your suggestion once I get the confirmation from
maintainer.

Thank you very much!

Best regards,
Eugeniu.

Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible

[Kuninori Morimoto]

Hi Eugeniu

Thank you for your reply

> > > Prior to adding M3-N Starter Kit to the list, rename:
> > >  - "renesas,h3ulcb" => "renesas,ulcb"
> > >  - "renesas,m3ulcb" => "renesas,ulcb"
> > 
> > I'm not sure detail, but
> > does it mean, both H3/M3 board can boot/work with
> > "renesas,ulcb" compatible if we had such driver/soc ?
> 
> First, assuming latest vanilla v4.18-rc8 kernel, neither
> "renesas,salvator-x[s]" nor "renesas,(m3|h3)ulcb" compatibles are
> used anywhere outside of DTS and DT bindings documentation:
(snip)
> Since there is no driver using these compatibles, no functional
> breakage is expected by changing the compatible format/name.

Yeah, it is true "so far". I think there is no problem on current kernel.
But, unfortunately we need to keep compatibility for old/new DT
(= actually, I don't like this DT rule. It is 100% "shackles for the legs")
Thus, my big concern is that, in the future,
"if" we added "renesas,ulcb" compatible driver/soc,
both h3/m3 ulcb will use it.
Then, if "h3" can work/boot by using same "m3" settings, it is no problem for me
(= "works but limited" is also OK, of course.
 This means "matched to more generic compatible")

> > My opinion is that if you want to exchange compatible name,
> > related all driver/document should be exchanged in same patch.
(snip)
> For that reason, IMO it might be worth to detach the document updates
> from DTS updates. I have no problems squashing the DTS and doc patches
> into one single commit, but before doing that I would appreciate a
> confirmation from the maintainer. Anyhow, many thanks for your feedback!
(snip)
> It was my impression that the DTS patches are always partitioned
> per-file, to avoid misleading globbing patterns in the commit subjects
> and allow easier DTS commit porting to future SoCs/boards. I will
> gladly follow your suggestion once I get the confirmation from
> maintainer.

Oops, I noticed that Simon was requested from ARM maintainer(?)
to merge/reduce patches
Let's follow Simon's opinion
(This kind of "patch categorize" is based on each ML...)

Best regards
---
Kuninori Morimoto

Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible

[Kuninori Morimoto]

Hi Eugeniu, again

> Yeah, it is true "so far". I think there is no problem on current kernel.
> But, unfortunately we need to keep compatibility for old/new DT
> (= actually, I don't like this DT rule. It is 100% "shackles for the legs")
> Thus, my big concern is that, in the future,
> "if" we added "renesas,ulcb" compatible driver/soc,
> both h3/m3 ulcb will use it.
> Then, if "h3" can work/boot by using same "m3" settings, it is no problem for me
> (= "works but limited" is also OK, of course.
>  This means "matched to more generic compatible")

"renesas,ulcb" is very generic naming.
Not only h3/m3, if we had v3/e3/d3 etc ulcb,
and if we had such compatible driver/soc, it needs to match to all ulcb.
In reality, maybe we don't create such compatible driver, though.
But, I don't know, I can follow to maintainer opinion.

Best regards
---
Kuninori Morimoto

Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible

[Laurent Pinchart]

Hi Morimoto-san,

On Tuesday, 7 August 2018 11:18:11 EEST Kuninori Morimoto wrote:
> Hi Eugeniu, again
> 
> > Yeah, it is true "so far". I think there is no problem on current kernel.
> > But, unfortunately we need to keep compatibility for old/new DT
> > (= actually, I don't like this DT rule. It is 100% "shackles for the
> > legs")
> > Thus, my big concern is that, in the future,
> > "if" we added "renesas,ulcb" compatible driver/soc,
> > both h3/m3 ulcb will use it.
> > Then, if "h3" can work/boot by using same "m3" settings, it is no problem
> > for me (= "works but limited" is also OK, of course.
> > 
> >  This means "matched to more generic compatible")
> 
> "renesas,ulcb" is very generic naming.
> Not only h3/m3, if we had v3/e3/d3 etc ulcb,

Furthermore, "ulcb" is an unofficial term, the boards are named "starter kit" 
(SK). Using internal names in code or device tree sources is a normal practice 
and is fine with me, but I'm a bit bothered by the fact that the H3/M3 boards 
are called ULCB in DT, while the V3 board are called SK. I wonder if we should 
unify that or if it's too late.

> and if we had such compatible driver/soc, it needs to match to all ulcb.
> In reality, maybe we don't create such compatible driver, though.
> But, I don't know, I can follow to maintainer opinion.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible

[Geert Uytterhoeven]

Hi Laurent,

On Tue, Aug 7, 2018 at 10:21 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Tuesday, 7 August 2018 11:18:11 EEST Kuninori Morimoto wrote:
> > > Yeah, it is true "so far". I think there is no problem on current kernel.
> > > But, unfortunately we need to keep compatibility for old/new DT
> > > (= actually, I don't like this DT rule. It is 100% "shackles for the
> > > legs")
> > > Thus, my big concern is that, in the future,
> > > "if" we added "renesas,ulcb" compatible driver/soc,
> > > both h3/m3 ulcb will use it.
> > > Then, if "h3" can work/boot by using same "m3" settings, it is no problem
> > > for me (= "works but limited" is also OK, of course.
> > >
> > >  This means "matched to more generic compatible")
> >
> > "renesas,ulcb" is very generic naming.
> > Not only h3/m3, if we had v3/e3/d3 etc ulcb,
>
> Furthermore, "ulcb" is an unofficial term, the boards are named "starter kit"
> (SK). Using internal names in code or device tree sources is a normal practice
> and is fine with me, but I'm a bit bothered by the fact that the H3/M3 boards
> are called ULCB in DT, while the V3 board are called SK. I wonder if we should
> unify that or if it's too late.

Perhaps we should.

Renesas has a long history of boards named <foo>SK or RSK<foo>.
The inconsistency started when suddenly SK was spelled out in full, with
"Premier" or "Pro" added to differentiate, and the need arose for a shorter
nickname, which became "ULCB"....

> > and if we had such compatible driver/soc, it needs to match to all ulcb.
> > In reality, maybe we don't create such compatible driver, though.
> > But, I don't know, I can follow to maintainer opinion.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible

[Eugeniu Rosca]

Hello Geert, Laurent, Morimoto-san,

On Tue, Aug 07, 2018 at 10:30:14AM +0200, Geert Uytterhoeven wrote:
> Hi Laurent,
> 
> On Tue, Aug 7, 2018 at 10:21 AM Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > On Tuesday, 7 August 2018 11:18:11 EEST Kuninori Morimoto wrote:
> > > > Yeah, it is true "so far". I think there is no problem on current kernel.
> > > > But, unfortunately we need to keep compatibility for old/new DT
> > > > (= actually, I don't like this DT rule. It is 100% "shackles for the
> > > > legs")
> > > > Thus, my big concern is that, in the future,
> > > > "if" we added "renesas,ulcb" compatible driver/soc,
> > > > both h3/m3 ulcb will use it.
> > > > Then, if "h3" can work/boot by using same "m3" settings, it is no problem
> > > > for me (= "works but limited" is also OK, of course.
> > > >
> > > >  This means "matched to more generic compatible")
> > >
> > > "renesas,ulcb" is very generic naming.
> > > Not only h3/m3, if we had v3/e3/d3 etc ulcb,
> >
> > Furthermore, "ulcb" is an unofficial term, the boards are named "starter kit"
> > (SK). Using internal names in code or device tree sources is a normal practice
> > and is fine with me, but I'm a bit bothered by the fact that the H3/M3 boards
> > are called ULCB in DT, while the V3 board are called SK. I wonder if we should
> > unify that or if it's too late.
> 
> Perhaps we should.
> 
> Renesas has a long history of boards named <foo>SK or RSK<foo>.
> The inconsistency started when suddenly SK was spelled out in full, with
> "Premier" or "Pro" added to differentiate, and the need arose for a shorter
> nickname, which became "ULCB"....

I really appreciate your comments, but it looks like at least the
following open questions prevent this series to advance into v2 (feel
free to point out flaws in my understanding):
 - [A] it is not clear if H3ULCB, M3ULCB and M3NULCB boards should use
       a common compatible string or dedicated ones.
 - [B] In case a common string is used for all *ULCB boards, should it
       drop the unofficial "ulcb" (Ultra Low Cost Board, thanks Laurent)
       in exchange to "sk", "starter-kit" or similar?
 - [C] Same as [A] and [B], but applied to ULCB DTS filenames, which are
       currently formed based on the same "ulcb" stem.

IMHO these questions go somewhat beyond the scope of M3-N ULCB bring-up.
In spite of this, I would be happy to implement your proposals. I am
also fine to wait a couple more days to collect more feedback, as well
as let the ideas/thoughts to settle. However, if you expect the latter
to take longer, maybe we can find some "acceptable" solution and defer
the naming issues to a later point?

Thanks,
Eugeniu.

Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible

[Laurent Pinchart]

Hi Eugeniu,

Thank you for the patch.

On Sunday, 5 August 2018 02:11:02 EEST Eugeniu Rosca wrote:
> In the context of M3N-ULCB (RTP0RC77965SKBX010SA00) board bring-up, it's
> rather pointless to add a new "renesas,m3nulcb" compatible string. Any
> SoC-level differences between the two variants of ULCB (M3 and M3-N)
> should be successfully covered by making use of existing
> "renesas,r8a7796" and "renesas,r8a77965" compatibles.
> 
> Prior to adding M3-N Starter Kit to the list, rename:
>  - "renesas,h3ulcb" => "renesas,ulcb"
>  - "renesas,m3ulcb" => "renesas,ulcb"

This bothers me more than the naming convention in patch 01/14, as this change 
would completely hide differences between the H3 and M3-N versions of the 
ULCB. Compatible strings are listed in a decreasing order of specificity, and 
having "renesas,ulcb" as the most-specific compatible string means that the 
two boards are supposed to be identical, while they are not.

> Relevant DTS changes come in separate per-DTS commits.
> 
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> ---
>  Documentation/devicetree/bindings/arm/shmobile.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt
> b/Documentation/devicetree/bindings/arm/shmobile.txt index
> d8cf740132c6..f391dba10574 100644
> --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> @@ -81,7 +81,7 @@ Boards:
>      compatible = "renesas,gose", "renesas,r8a7793"
>    - H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1))
>      H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0))
> -    compatible = "renesas,h3ulcb", "renesas,r8a7795"
> +    compatible = "renesas,ulcb", "renesas,r8a7795"
>    - Henninger
>      compatible = "renesas,henninger", "renesas,r8a7791"
>    - iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S)
> @@ -105,7 +105,7 @@ Boards:
>    - Lager (RTP0RC7790SEB00010S)
>      compatible = "renesas,lager", "renesas,r8a7790"
>    - M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0))
> -    compatible = "renesas,m3ulcb", "renesas,r8a7796"
> +    compatible = "renesas,ulcb", "renesas,r8a7796"
>    - Marzen (R0P7779A00010S)
>      compatible = "renesas,marzen", "renesas,r8a7779"
>    - Porter (M2-LCDP)

-- 
Regards,

Laurent Pinchart

Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible

[Geert Uytterhoeven]

Hi Laurent,

On Mon, Aug 6, 2018 at 12:38 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Sunday, 5 August 2018 02:11:02 EEST Eugeniu Rosca wrote:
> > In the context of M3N-ULCB (RTP0RC77965SKBX010SA00) board bring-up, it's
> > rather pointless to add a new "renesas,m3nulcb" compatible string. Any
> > SoC-level differences between the two variants of ULCB (M3 and M3-N)
> > should be successfully covered by making use of existing
> > "renesas,r8a7796" and "renesas,r8a77965" compatibles.
> >
> > Prior to adding M3-N Starter Kit to the list, rename:
> >  - "renesas,h3ulcb" => "renesas,ulcb"
> >  - "renesas,m3ulcb" => "renesas,ulcb"
>
> This bothers me more than the naming convention in patch 01/14, as this change
> would completely hide differences between the H3 and M3-N versions of the
> ULCB. Compatible strings are listed in a decreasing order of specificity, and
> having "renesas,ulcb" as the most-specific compatible string means that the
> two boards are supposed to be identical, while they are not.

AFAIK the boards are identical (cfr. ), except for the SiP mounted.
Cfr. e.g. the combined R-Car_StarterKit_Gen3_H3_M3_DEV_Rev.053.pdf
("Renesas R-Car H3/M3 Device Manual", incl. schematics).

Hence to me the patch makes sense (modulo out-of-tree dependencies on the
old compatible values).

> > Relevant DTS changes come in separate per-DTS commits.
> >
> > Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> > ---
> >  Documentation/devicetree/bindings/arm/shmobile.txt | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt
> > b/Documentation/devicetree/bindings/arm/shmobile.txt index
> > d8cf740132c6..f391dba10574 100644
> > --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> > +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> > @@ -81,7 +81,7 @@ Boards:
> >      compatible = "renesas,gose", "renesas,r8a7793"
> >    - H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1))
> >      H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0))
> > -    compatible = "renesas,h3ulcb", "renesas,r8a7795"
> > +    compatible = "renesas,ulcb", "renesas,r8a7795"
> >    - Henninger
> >      compatible = "renesas,henninger", "renesas,r8a7791"
> >    - iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S)
> > @@ -105,7 +105,7 @@ Boards:
> >    - Lager (RTP0RC7790SEB00010S)
> >      compatible = "renesas,lager", "renesas,r8a7790"
> >    - M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0))
> > -    compatible = "renesas,m3ulcb", "renesas,r8a7796"
> > +    compatible = "renesas,ulcb", "renesas,r8a7796"
> >    - Marzen (R0P7779A00010S)
> >      compatible = "renesas,marzen", "renesas,r8a7779"
> >    - Porter (M2-LCDP)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible

[Geert Uytterhoeven]

On Mon, Aug 6, 2018 at 1:13 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, Aug 6, 2018 at 12:38 PM Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > On Sunday, 5 August 2018 02:11:02 EEST Eugeniu Rosca wrote:
> > > In the context of M3N-ULCB (RTP0RC77965SKBX010SA00) board bring-up, it's
> > > rather pointless to add a new "renesas,m3nulcb" compatible string. Any
> > > SoC-level differences between the two variants of ULCB (M3 and M3-N)
> > > should be successfully covered by making use of existing
> > > "renesas,r8a7796" and "renesas,r8a77965" compatibles.
> > >
> > > Prior to adding M3-N Starter Kit to the list, rename:
> > >  - "renesas,h3ulcb" => "renesas,ulcb"
> > >  - "renesas,m3ulcb" => "renesas,ulcb"
> >
> > This bothers me more than the naming convention in patch 01/14, as this change
> > would completely hide differences between the H3 and M3-N versions of the
> > ULCB. Compatible strings are listed in a decreasing order of specificity, and
> > having "renesas,ulcb" as the most-specific compatible string means that the
> > two boards are supposed to be identical, while they are not.
>
> AFAIK the boards are identical (cfr. ), except for the SiP mounted.
> Cfr. e.g. the combined R-Car_StarterKit_Gen3_H3_M3_DEV_Rev.053.pdf
> ("Renesas R-Car H3/M3 Device Manual", incl. schematics).

Sorry, the schematics are in a separate file
R-Car_StarterKit_Gen3_SCH_Rev.110.pdf
with title "R-Car_Gen3 Starterkit", for both the Pro and Premier versions.

But "ULCB" is an unofficial name.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible

[Eugeniu Rosca]

On Sun, Aug 05, 2018 at 01:11:02AM +0200, Eugeniu Rosca wrote:
> diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
> index d8cf740132c6..f391dba10574 100644
> --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> @@ -81,7 +81,7 @@ Boards:
>      compatible = "renesas,gose", "renesas,r8a7793"
>    - H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1))
>      H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0))

FWIW/FTR, I have found the schematics of RTP0RC7795SKB00010S
(looks like a H3-ES1x Starter-Kit) and this specific board doesn't
have an entry in Documentation/devicetree/bindings/arm/shmobile.txt.

Also, there is RTP0RC77951SKBX010SA03 (8GB version H3-ES20 Starter-Kit).
This is also not documented.

Interestingly, there is one digit difference between:
 - 4GiB H3-ES2.0 Starter-Kit: RTP0RC77951SKBX010SA00
 - 8GiB H3-ES2.0 Starter-Kit: RTP0RC77951SKBX010SA03

which means Renesas encodes the amount of RAM in the board id/string.

> -    compatible = "renesas,h3ulcb", "renesas,r8a7795"
> +    compatible = "renesas,ulcb", "renesas,r8a7795"
>    - Henninger
>      compatible = "renesas,henninger", "renesas,r8a7791"
>    - iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S)
> @@ -105,7 +105,7 @@ Boards:
>    - Lager (RTP0RC7790SEB00010S)
>      compatible = "renesas,lager", "renesas,r8a7790"
>    - M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0))
> -    compatible = "renesas,m3ulcb", "renesas,r8a7796"
> +    compatible = "renesas,ulcb", "renesas,r8a7796"
>    - Marzen (R0P7779A00010S)
>      compatible = "renesas,marzen", "renesas,r8a7779"
>    - Porter (M2-LCDP)
> -- 
> 2.18.0

Best regards,
Eugeniu.

[PATCH 03/14] arm64: dts: renesas: r8a7795-es1: ulcb: Use "renesas,ulcb" compatible

[Eugeniu Rosca]

Following the recent change in dt-bindings [1], switch from
"renesas,h3ulcb" to "renesas,ulcb" compatible string.

[1] Documentation/devicetree/bindings/arm/shmobile.txt

Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
---
 arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb.dts
index dd4f9b6a4254..8ec1695ca9ee 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb.dts
@@ -15,7 +15,7 @@
 
 / {
 	model = "Renesas H3ULCB board based on r8a7795 ES1.x";
-	compatible = "renesas,h3ulcb", "renesas,r8a7795";
+	compatible = "renesas,ulcb", "renesas,r8a7795";
 
 	memory@48000000 {
 		device_type = "memory";
-- 
2.18.0

[PATCH 04/14] arm64: dts: renesas: r8a7795-es1: ulcb-kf: Use "renesas,ulcb" compatible

[Eugeniu Rosca]

Following the recent change in dt-bindings [1], switch from
"renesas,h3ulcb" to "renesas,ulcb" compatible string.

[1] Documentation/devicetree/bindings/arm/shmobile.txt

Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
---
 arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
index 06deb67c36c8..7a5b1dc64090 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
@@ -14,6 +14,6 @@
 
 / {
 	model = "Renesas H3ULCB Kingfisher board based on r8a7795 ES1.x";
-	compatible = "shimafuji,kingfisher", "renesas,h3ulcb",
+	compatible = "shimafuji,kingfisher", "renesas,ulcb",
 		     "renesas,r8a7795";
 };
-- 
2.18.0

Re: [PATCH 04/14] arm64: dts: renesas: r8a7795-es1: ulcb-kf: Use "renesas,ulcb" compatible

[Laurent Pinchart]

Hi Eugeniu,

Thank you for the patch.

On Sunday, 5 August 2018 02:11:04 EEST Eugeniu Rosca wrote:
> Following the recent change in dt-bindings [1], switch from
> "renesas,h3ulcb" to "renesas,ulcb" compatible string.
> 
> [1] Documentation/devicetree/bindings/arm/shmobile.txt
> 
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> ---
>  arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
> b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts index
> 06deb67c36c8..7a5b1dc64090 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
> @@ -14,6 +14,6 @@
> 
>  / {
>  	model = "Renesas H3ULCB Kingfisher board based on r8a7795 ES1.x";
> -	compatible = "shimafuji,kingfisher", "renesas,h3ulcb",
> +	compatible = "shimafuji,kingfisher", "renesas,ulcb",
>  		     "renesas,r8a7795";

This is unrelated to your patch, but due to the reason explained in my review 
of 02/14, I think "shimafuji,kingfisher" should include the SoC name.

This brings up the topic of how to describe boards that are made of an SoC 
"module" board plugged into an expansion "motherboard".

>  };

-- 
Regards,

Laurent Pinchart

Re: [PATCH 04/14] arm64: dts: renesas: r8a7795-es1: ulcb-kf: Use "renesas,ulcb" compatible

[Kieran Bingham]

Hi Laurent, Eugeniu,

On 06/08/18 11:42, Laurent Pinchart wrote:
> Hi Eugeniu,
> 
> Thank you for the patch.
> 
> On Sunday, 5 August 2018 02:11:04 EEST Eugeniu Rosca wrote:
>> Following the recent change in dt-bindings [1], switch from
>> "renesas,h3ulcb" to "renesas,ulcb" compatible string.
>>
>> [1] Documentation/devicetree/bindings/arm/shmobile.txt
>>
>> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
>> ---
>>  arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
>> b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts index
>> 06deb67c36c8..7a5b1dc64090 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
>> +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
>> @@ -14,6 +14,6 @@
>>
>>  / {
>>  	model = "Renesas H3ULCB Kingfisher board based on r8a7795 ES1.x";
>> -	compatible = "shimafuji,kingfisher", "renesas,h3ulcb",
>> +	compatible = "shimafuji,kingfisher", "renesas,ulcb",
>>  		     "renesas,r8a7795";
> 
> This is unrelated to your patch, but due to the reason explained in my review 
> of 02/14, I think "shimafuji,kingfisher" should include the SoC name.
> 
> This brings up the topic of how to describe boards that are made of an SoC 
> "module" board plugged into an expansion "motherboard".

Isn't it the point that the shimafuji board is agnostic to the SoC on
the ULCB?

I presume the Kingfisher board is just the expansion board which would
be identical regardless of if it was put on an H3 ULCB, or an M3 ULCB?


> 
>>  };
> 

Regards

Kieran

Re: [PATCH 04/14] arm64: dts: renesas: r8a7795-es1: ulcb-kf: Use "renesas,ulcb" compatible

[Kieran Bingham]

On 06/08/18 11:45, Kieran Bingham wrote:
> Hi Laurent, Eugeniu,
> 
> On 06/08/18 11:42, Laurent Pinchart wrote:
>> Hi Eugeniu,
>>
>> Thank you for the patch.
>>
>> On Sunday, 5 August 2018 02:11:04 EEST Eugeniu Rosca wrote:
>>> Following the recent change in dt-bindings [1], switch from
>>> "renesas,h3ulcb" to "renesas,ulcb" compatible string.
>>>
>>> [1] Documentation/devicetree/bindings/arm/shmobile.txt
>>>
>>> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
>>> ---
>>>  arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
>>> b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts index
>>> 06deb67c36c8..7a5b1dc64090 100644
>>> --- a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
>>> +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
>>> @@ -14,6 +14,6 @@
>>>
>>>  / {
>>>  	model = "Renesas H3ULCB Kingfisher board based on r8a7795 ES1.x";
>>> -	compatible = "shimafuji,kingfisher", "renesas,h3ulcb",
>>> +	compatible = "shimafuji,kingfisher", "renesas,ulcb",
>>>  		     "renesas,r8a7795";
>>
>> This is unrelated to your patch, but due to the reason explained in my review 
>> of 02/14, I think "shimafuji,kingfisher" should include the SoC name.
>>
>> This brings up the topic of how to describe boards that are made of an SoC 
>> "module" board plugged into an expansion "motherboard".
> 
> Isn't it the point that the shimafuji board is agnostic to the SoC on
> the ULCB?
> 
> I presume the Kingfisher board is just the expansion board which would
> be identical regardless of if it was put on an H3 ULCB, or an M3 ULCB?


In fact possibly the interesting point is that the kingfisher as an
expansion board is surely an 'overlay', rather than the board itself ?

>>
>>>  };


Regards

Kieran

Re: [PATCH 04/14] arm64: dts: renesas: r8a7795-es1: ulcb-kf: Use "renesas,ulcb" compatible

[Laurent Pinchart]

Hi Kieran,

On Monday, 6 August 2018 13:49:59 EEST Kieran Bingham wrote:
> On 06/08/18 11:45, Kieran Bingham wrote:
> > On 06/08/18 11:42, Laurent Pinchart wrote:
> >> On Sunday, 5 August 2018 02:11:04 EEST Eugeniu Rosca wrote:
> >>> Following the recent change in dt-bindings [1], switch from
> >>> "renesas,h3ulcb" to "renesas,ulcb" compatible string.
> >>> 
> >>> [1] Documentation/devicetree/bindings/arm/shmobile.txt
> >>> 
> >>> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> >>> ---
> >>> 
> >>>  arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>> 
> >>> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
> >>> b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts index
> >>> 06deb67c36c8..7a5b1dc64090 100644
> >>> --- a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
> >>> +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
> >>> @@ -14,6 +14,6 @@
> >>> 
> >>>  / {
> >>>  	model = "Renesas H3ULCB Kingfisher board based on r8a7795 ES1.x";
> >>> 
> >>> -	compatible = "shimafuji,kingfisher", "renesas,h3ulcb",
> >>> +	compatible = "shimafuji,kingfisher", "renesas,ulcb",
> >>>  		     "renesas,r8a7795";
> >> 
> >> This is unrelated to your patch, but due to the reason explained in my
> >> review of 02/14, I think "shimafuji,kingfisher" should include the SoC
> >> name.
> >> 
> >> This brings up the topic of how to describe boards that are made of an
> >> SoC "module" board plugged into an expansion "motherboard".
> > 
> > Isn't it the point that the shimafuji board is agnostic to the SoC on
> > the ULCB?
> > 
> > I presume the Kingfisher board is just the expansion board which would
> > be identical regardless of if it was put on an H3 ULCB, or an M3 ULCB?
> 
> In fact possibly the interesting point is that the kingfisher as an
> expansion board is surely an 'overlay', rather than the board itself ?

In a way it's both. From an SoC point of view, the KingFisher board can be 
seen as an expansion board. From a system point of view, it's a KingFisher 
system.

If you built a car around an H3 ULCB, would you consider that to be an H3 with 
a car extension, or a car with an H3 inside ? :-)

> >>>  };

-- 
Regards,

Laurent Pinchart

Re: [PATCH 04/14] arm64: dts: renesas: r8a7795-es1: ulcb-kf: Use "renesas,ulcb" compatible

[Vladimir Zapolskiy]

Hi Laurent,

[Adding Rob and DT ML]

On 08/06/2018 01:42 PM, Laurent Pinchart wrote:
> Hi Eugeniu,
> 
> Thank you for the patch.
> 
> On Sunday, 5 August 2018 02:11:04 EEST Eugeniu Rosca wrote:
>> Following the recent change in dt-bindings [1], switch from
>> "renesas,h3ulcb" to "renesas,ulcb" compatible string.
>>
>> [1] Documentation/devicetree/bindings/arm/shmobile.txt
>>
>> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
>> ---
>>  arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
>> b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts index
>> 06deb67c36c8..7a5b1dc64090 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
>> +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
>> @@ -14,6 +14,6 @@
>>
>>  / {
>>  	model = "Renesas H3ULCB Kingfisher board based on r8a7795 ES1.x";
>> -	compatible = "shimafuji,kingfisher", "renesas,h3ulcb",
>> +	compatible = "shimafuji,kingfisher", "renesas,ulcb",
>>  		     "renesas,r8a7795";
> 
> This is unrelated to your patch, but due to the reason explained in my review 
> of 02/14, I think "shimafuji,kingfisher" should include the SoC name.
> 
> This brings up the topic of how to describe boards that are made of an SoC 
> "module" board plugged into an expansion "motherboard".
> 

Diving into (probably shatteredly recollected by me) history, a board
'compatible' property appears as a handle to deal with incomplete board
description represented in DTB, so that arch code or drivers can catch on it
and fill some board specific missing parts in runtime, commonly the related
code takes a shape of quirks.

If we accept it, SoC specific drivers would take their interest in SoC model
and revision, and out-of-SoC/platform/board drivers and legacy arch board
code can look at a PCB board model variant. Note that for both separated
but comparably large and important pieces of board/platform knowledge there
is a single compatible property in use, namely the compatible property of
the root node. Also note that both ePAPR and Devicetree Specification describe
'compatible' property of the root node as a special one, as "a list of
platform architectures with which this platform is compatible".

In my opinion a better board representation would be to add a 'soc' device
node as a child of the root node, and the former one has its own fixed
compatible property, but a protocol based on such view has to be agreed
and accepted firstly, and it falls into "forever unrealistic tasks" category.

Today the SoC part of compatible property value is still in active use, and
PCB\SoC part is almost abandoned, so I would propose to diminish the asset
of the latter. Since both board/platform descriptions are alloyed in one
list of values, I'd like to see a better description of acceptable values
of 'compatible' property of the root node.

The common practice is to put SoC specific values into the right tail,
and place (kind of optional) board specific values on the left, let's
continue to follow it, but unrestrict SoC agnostic string names of boards
and further board extensions, if PCB\SoC (or PCB\PCB for extension boards)
are about identical. Anyway those values are mainly unused nowadays, so
nothing is lost but another dimension in board/platform description and
naming is avoided. I do understand that likely most of PCBs are very SoC
centric, and the proposal shared above should not be considered as a rule,
but rather as a reasonable and valid exception.

--
Best wishes,
Vladimir

Re: [PATCH 04/14] arm64: dts: renesas: r8a7795-es1: ulcb-kf: Use "renesas,ulcb" compatible

[Vladimir Zapolskiy]

Hi Laurent,

[Adding Rob and DT ML]

On 08/06/2018 01:42 PM, Laurent Pinchart wrote:
> Hi Eugeniu,
> 
> Thank you for the patch.
> 
> On Sunday, 5 August 2018 02:11:04 EEST Eugeniu Rosca wrote:
>> Following the recent change in dt-bindings [1], switch from
>> "renesas,h3ulcb" to "renesas,ulcb" compatible string.
>>
>> [1] Documentation/devicetree/bindings/arm/shmobile.txt
>>
>> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
>> ---
>>  arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
>> b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts index
>> 06deb67c36c8..7a5b1dc64090 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
>> +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
>> @@ -14,6 +14,6 @@
>>
>>  / {
>>  	model = "Renesas H3ULCB Kingfisher board based on r8a7795 ES1.x";
>> -	compatible = "shimafuji,kingfisher", "renesas,h3ulcb",
>> +	compatible = "shimafuji,kingfisher", "renesas,ulcb",
>>  		     "renesas,r8a7795";
> 
> This is unrelated to your patch, but due to the reason explained in my review 
> of 02/14, I think "shimafuji,kingfisher" should include the SoC name.
> 
> This brings up the topic of how to describe boards that are made of an SoC 
> "module" board plugged into an expansion "motherboard".
> 

Diving into (probably shatteredly recollected by me) history, a board
'compatible' property appears as a handle to deal with incomplete board
description represented in DTB, so that arch code or drivers can catch on it
and fill some board specific missing parts in runtime, commonly the related
code takes a shape of quirks.

If we accept it, SoC specific drivers would take their interest in SoC model
and revision, and out-of-SoC/platform/board drivers and legacy arch board
code can look at a PCB board model variant. Note that for both separated
but comparably large and important pieces of board/platform knowledge there
is a single compatible property in use, namely the compatible property of
the root node. Also note that both ePAPR and Devicetree Specification describe
'compatible' property of the root node as a special one, as "a list of
platform architectures with which this platform is compatible".

In my opinion a better board representation would be to add a 'soc' device
node as a child of the root node, and the former one has its own fixed
compatible property, but a protocol based on such view has to be agreed
and accepted firstly, and it falls into "forever unrealistic tasks" category.

Today the SoC part of compatible property value is still in active use, and
PCB\SoC part is almost abandoned, so I would propose to diminish the asset
of the latter. Since both board/platform descriptions are alloyed in one
list of values, I'd like to see a better description of acceptable values
of 'compatible' property of the root node.

The common practice is to put SoC specific values into the right tail,
and place (kind of optional) board specific values on the left, let's
continue to follow it, but unrestrict SoC agnostic string names of boards
and further board extensions, if PCB\SoC (or PCB\PCB for extension boards)
are about identical. Anyway those values are mainly unused nowadays, so
nothing is lost but another dimension in board/platform description and
naming is avoided. I do understand that likely most of PCBs are very SoC
centric, and the proposal shared above should not be considered as a rule,
but rather as a reasonable and valid exception.

--
Best wishes,
Vladimir

[PATCH 05/14] arm64: dts: renesas: r8a7795: ulcb: Use "renesas,ulcb" compatible

[Eugeniu Rosca]

Following the recent change in dt-bindings [1], switch from
"renesas,h3ulcb" to "renesas,ulcb" compatible string.

[1] Documentation/devicetree/bindings/arm/shmobile.txt

Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
---
 arch/arm64/boot/dts/renesas/r8a7795-ulcb.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-ulcb.dts
index 0afe777973de..9cccdef23634 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-ulcb.dts
@@ -15,7 +15,7 @@
 
 / {
 	model = "Renesas H3ULCB board based on r8a7795 ES2.0+";
-	compatible = "renesas,h3ulcb", "renesas,r8a7795";
+	compatible = "renesas,ulcb", "renesas,r8a7795";
 
 	memory@48000000 {
 		device_type = "memory";
-- 
2.18.0

[PATCH 06/14] arm64: dts: renesas: r8a7795: ulcb-kf: Use "renesas,ulcb" compatible

[Eugeniu Rosca]

Following the recent change in dt-bindings [1], switch from
"renesas,h3ulcb" to "renesas,ulcb" compatible string.

[1] Documentation/devicetree/bindings/arm/shmobile.txt

Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
---
 arch/arm64/boot/dts/renesas/r8a7795-ulcb-kf.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-ulcb-kf.dts b/arch/arm64/boot/dts/renesas/r8a7795-ulcb-kf.dts
index 70a0c5332d54..5a3a79bd0849 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-ulcb-kf.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-ulcb-kf.dts
@@ -14,6 +14,6 @@
 
 / {
 	model = "Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+";
-	compatible = "shimafuji,kingfisher", "renesas,h3ulcb",
+	compatible = "shimafuji,kingfisher", "renesas,ulcb",
 		     "renesas,r8a7795";
 };
-- 
2.18.0

[PATCH 07/14] arm64: dts: renesas: r8a7796: ulcb: Use "renesas,ulcb" compatible

[Eugeniu Rosca]

Following the recent change in dt-bindings [1], switch from
"renesas,m3ulcb" to "renesas,ulcb" compatible string.

[1] Documentation/devicetree/bindings/arm/shmobile.txt

Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
---
 arch/arm64/boot/dts/renesas/r8a7796-ulcb.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796-ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-ulcb.dts
index daee1f1a3f68..c7f5ddd70a5c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-ulcb.dts
@@ -15,7 +15,7 @@
 
 / {
 	model = "Renesas M3ULCB board based on r8a7796";
-	compatible = "renesas,m3ulcb", "renesas,r8a7796";
+	compatible = "renesas,ulcb", "renesas,r8a7796";
 
 	memory@48000000 {
 		device_type = "memory";
-- 
2.18.0

[PATCH 08/14] arm64: dts: renesas: r8a7796: ulcb-kf: Use "renesas,ulcb" compatible

[Eugeniu Rosca]

Following the recent change in dt-bindings [1], switch from
"renesas,m3ulcb" to "renesas,ulcb" compatible string.

[1] Documentation/devicetree/bindings/arm/shmobile.txt

Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
---
 arch/arm64/boot/dts/renesas/r8a7796-ulcb-kf.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796-ulcb-kf.dts b/arch/arm64/boot/dts/renesas/r8a7796-ulcb-kf.dts
index faa32c28eef7..5bd655c0355e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-ulcb-kf.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-ulcb-kf.dts
@@ -14,6 +14,6 @@
 
 / {
 	model = "Renesas M3ULCB Kingfisher board based on r8a7796";
-	compatible = "shimafuji,kingfisher", "renesas,m3ulcb",
+	compatible = "shimafuji,kingfisher", "renesas,ulcb",
 		     "renesas,r8a7796";
 };
-- 
2.18.0

[PATCH 09/14] dt-bindings: arm: Document Renesas R-Car M3-N-based ULCB board

[Eugeniu Rosca]

In harmony with ATF and U-Boot outputs [1] and [2], the new board is
based on M3-N revision ES1.1 and the amount of memory present on SiP
is 2GiB, contiguously addressed.

[1] BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.21
    BL2: PRR is R-Car M3N Ver.1.1

[2] U-Boot 2015.04-00295-*
    CPU: Renesas Electronics R8A77965 rev 1.1
    ---8<----
    DRAM:  1.9 GiB
    Bank #0: 0x048000000 - 0x0bfffffff, 1.9 GiB
    ---8<----

Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
---
 Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index f391dba10574..2f3494a0107c 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -106,6 +106,8 @@ Boards:
     compatible = "renesas,lager", "renesas,r8a7790"
   - M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0))
     compatible = "renesas,ulcb", "renesas,r8a7796"
+  - M3-N ULCB (R-Car Starter Kit Pro, RTP0RC77965SKBX010SA00 (M3-N ES1.1))
+    compatible = "renesas,ulcb", "renesas,r8a77965"
   - Marzen (R0P7779A00010S)
     compatible = "renesas,marzen", "renesas,r8a7779"
   - Porter (M2-LCDP)
-- 
2.18.0

Re: [PATCH 09/14] dt-bindings: arm: Document Renesas R-Car M3-N-based ULCB board

[jacopo mondi]

[-- Attachment #1: Type: text/plain, Size: 3434 bytes --]

Helle Eugeniu,

On Sun, Aug 05, 2018 at 01:11:09AM +0200, Eugeniu Rosca wrote:
> In harmony with ATF and U-Boot outputs [1] and [2], the new board is
> based on M3-N revision ES1.1 and the amount of memory present on SiP
> is 2GiB, contiguously addressed.

Not sure why the amount of installed system memory is relevant for
this commit..

>
> [1] BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.21
>     BL2: PRR is R-Car M3N Ver.1.1
>
> [2] U-Boot 2015.04-00295-*
>     CPU: Renesas Electronics R8A77965 rev 1.1
>     ---8<----
>     DRAM:  1.9 GiB
>     Bank #0: 0x048000000 - 0x0bfffffff, 1.9 GiB
>     ---8<----
>
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> ---
>  Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
> index f391dba10574..2f3494a0107c 100644
> --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> @@ -106,6 +106,8 @@ Boards:
>      compatible = "renesas,lager", "renesas,r8a7790"
>    - M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0))
>      compatible = "renesas,ulcb", "renesas,r8a7796"
> +  - M3-N ULCB (R-Car Starter Kit Pro, RTP0RC77965SKBX010SA00 (M3-N ES1.1))

Other documented ULCB description entries in this file are
H3ULCB and M3ULCB, so for consistency you should add M3NULCB, which
isn't that nice.

Imo, or you either replace "[H|M]3ULCB" with "[H|M]3 ULCB" in other
entries and you keep your "M3-N ULCB" here, which is nicer (you could
do that in patch 2).

Or maybe could you consider doing what has been done for
Salvator-x(s), which do not have the SoC model name in the entry description
at all (but please wait for others to comment before doing something
like that):

        - Salvator-X (RTP0RC7795SIPB0010S)
          compatible = "renesas,salvator-x", "renesas,r8a7795"
        - Salvator-X (RTP0RC7796SIPB0011S)
          compatible = "renesas,salvator-x", "renesas,r8a7796"
        - Salvator-X (RTP0RC7796SIPB0011S (M3-N))
          compatible = "renesas,salvator-x", "renesas,r8a77965"
        - Salvator-XS (Salvator-X 2nd version, RTP0RC7795SIPB0012S)
          compatible = "renesas,salvator-xs", "renesas,r8a7795"
        - Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012S)
          compatible = "renesas,salvator-xs", "renesas,r8a7796"
        - Salvator-XS (Salvator-X 2nd version, RTP0RC77965SIPB012S)
          compatible = "renesas,salvator-xs", "renesas,r8a77965"

This would then be
        - ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1))
          ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0))
          compatible = "renesas,ulcb", "renesas,r8a7795
        - ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0)
          compatible = "renesas,ulcb", "renesas,r8a7796"
        - ULCB (R-Car Starter Kit Pro, RTP0RC77965SKBX010SA00 (M3-N ES1.1))
          compatible = "renesas,ulcb", "renesas,r8a77965"

Thanks
   j

PS: why the r8a7795-es1 version of Salvator-X is not listed? I assume
it has a different part number than the ES2.0 one, as ULCB with es1
does.


> +    compatible = "renesas,ulcb", "renesas,r8a77965"
>    - Marzen (R0P7779A00010S)
>      compatible = "renesas,marzen", "renesas,r8a7779"
>    - Porter (M2-LCDP)
> --
> 2.18.0
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 09/14] dt-bindings: arm: Document Renesas R-Car M3-N-based ULCB board

[Eugeniu Rosca]

Hi Jacopo,

Thanks for your comments. Please, find my replies below.

On Sun, Aug 05, 2018 at 10:15:43AM +0200, jacopo mondi wrote:
> Helle Eugeniu,
> 
> On Sun, Aug 05, 2018 at 01:11:09AM +0200, Eugeniu Rosca wrote:
> > In harmony with ATF and U-Boot outputs [1] and [2], the new board is
> > based on M3-N revision ES1.1 and the amount of memory present on SiP
> > is 2GiB, contiguously addressed.
> 
> Not sure why the amount of installed system memory is relevant for
> this commit..

To be honest, I don't know precisely what's encoded in the board string
(particularly the one documented in this commit RTP0RC77965SKBX010SA00).

The only thing unmistakenly present there is the SoC model 77965 (i.e.
M3-N), but I am quite clueless about the rest.

What I can say for sure is that the end-user experience of a R-Car Gen3
reference board clearly depends on below parameters:
 - [A] SoC (model, revision) including SRAM and on-chip peripherals
 - [B] DRAM (amount, linear/2ch/4ch split) 
 - [C] Hyperflash (amount)
 - [D] board's PCB (revision)
 - [E] board's off-chip peripherals (model, revision)

I don't know how many of these parameters are embedded in the board
string, but since you are suggesting that RAM amount is not (IOW
Renesas will potentially release several RTP0RC77965SKBX010SA00
boards with different amounts of memory), I will happily update
the commit description.

> 
> >
> > [1] BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.21
> >     BL2: PRR is R-Car M3N Ver.1.1
> >
> > [2] U-Boot 2015.04-00295-*
> >     CPU: Renesas Electronics R8A77965 rev 1.1
> >     ---8<----
> >     DRAM:  1.9 GiB
> >     Bank #0: 0x048000000 - 0x0bfffffff, 1.9 GiB
> >     ---8<----
> >
> > Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> > ---
> >  Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
> > index f391dba10574..2f3494a0107c 100644
> > --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> > +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> > @@ -106,6 +106,8 @@ Boards:
> >      compatible = "renesas,lager", "renesas,r8a7790"
> >    - M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0))
> >      compatible = "renesas,ulcb", "renesas,r8a7796"
> > +  - M3-N ULCB (R-Car Starter Kit Pro, RTP0RC77965SKBX010SA00 (M3-N ES1.1))
> 
> Other documented ULCB description entries in this file are
> H3ULCB and M3ULCB, so for consistency you should add M3NULCB, which
> isn't that nice.

This was my initial intent, but then I noticed commits like
519df0e05d27 ("dt-bindings: arm: consistently name r8a77965 as M3-N"),
which try to use "M3-N" notation consistently and avoid "M3N". So, I
tried to avoid "M3N" too.

> 
> Imo, or you either replace "[H|M]3ULCB" with "[H|M]3 ULCB" in other
> entries and you keep your "M3-N ULCB" here, which is nicer (you could
> do that in patch 2).
> 
> Or maybe could you consider doing what has been done for
> Salvator-x(s), which do not have the SoC model name in the entry description
> at all (but please wait for others to comment before doing something
> like that):

I prefer this second variant, but I will wait for others to comment.

> 
>         - Salvator-X (RTP0RC7795SIPB0010S)
>           compatible = "renesas,salvator-x", "renesas,r8a7795"
>         - Salvator-X (RTP0RC7796SIPB0011S)
>           compatible = "renesas,salvator-x", "renesas,r8a7796"
>         - Salvator-X (RTP0RC7796SIPB0011S (M3-N))
>           compatible = "renesas,salvator-x", "renesas,r8a77965"
>         - Salvator-XS (Salvator-X 2nd version, RTP0RC7795SIPB0012S)
>           compatible = "renesas,salvator-xs", "renesas,r8a7795"
>         - Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012S)
>           compatible = "renesas,salvator-xs", "renesas,r8a7796"
>         - Salvator-XS (Salvator-X 2nd version, RTP0RC77965SIPB012S)
>           compatible = "renesas,salvator-xs", "renesas,r8a77965"
> 
> This would then be
>         - ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1))
>           ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0))
>           compatible = "renesas,ulcb", "renesas,r8a7795
>         - ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0)
>           compatible = "renesas,ulcb", "renesas,r8a7796"
>         - ULCB (R-Car Starter Kit Pro, RTP0RC77965SKBX010SA00 (M3-N ES1.1))
>           compatible = "renesas,ulcb", "renesas,r8a77965"
> 
> Thanks
>    j
> 
> PS: why the r8a7795-es1 version of Salvator-X is not listed? I assume
> it has a different part number than the ES2.0 one, as ULCB with es1
> does.

That's a good question, but I think the concern is not too big since
r8a7795-es1 is EOL. 

> 
> > +    compatible = "renesas,ulcb", "renesas,r8a77965"
> >    - Marzen (R0P7779A00010S)
> >      compatible = "renesas,marzen", "renesas,r8a7779"
> >    - Porter (M2-LCDP)
> > --
> > 2.18.0
> >

Thanks!

Best regards,
Eugeniu.

Re: [PATCH 09/14] dt-bindings: arm: Document Renesas R-Car M3-N-based ULCB board

[Eugeniu Rosca]

Hi again Jacopo,

On Mon, Aug 06, 2018 at 12:40:02AM +0200, Eugeniu Rosca wrote:
> Hi Jacopo,
> 
> Thanks for your comments. Please, find my replies below.
> 
> On Sun, Aug 05, 2018 at 10:15:43AM +0200, jacopo mondi wrote:
> > Helle Eugeniu,
> > 
> > On Sun, Aug 05, 2018 at 01:11:09AM +0200, Eugeniu Rosca wrote:
> > > In harmony with ATF and U-Boot outputs [1] and [2], the new board is
> > > based on M3-N revision ES1.1 and the amount of memory present on SiP
> > > is 2GiB, contiguously addressed.
> > 
> > Not sure why the amount of installed system memory is relevant for
> > this commit..
> 
> To be honest, I don't know precisely what's encoded in the board string
> (particularly the one documented in this commit RTP0RC77965SKBX010SA00).
> 
> The only thing unmistakenly present there is the SoC model 77965 (i.e.
> M3-N), but I am quite clueless about the rest.
> 
> What I can say for sure is that the end-user experience of a R-Car Gen3
> reference board clearly depends on below parameters:
>  - [A] SoC (model, revision) including SRAM and on-chip peripherals
>  - [B] DRAM (amount, linear/2ch/4ch split) 
>  - [C] Hyperflash (amount)
>  - [D] board's PCB (revision)
>  - [E] board's off-chip peripherals (model, revision)
> 
> I don't know how many of these parameters are embedded in the board
> string, but since you are suggesting that RAM amount is not (IOW
> Renesas will potentially release several RTP0RC77965SKBX010SA00
> boards with different amounts of memory), I will happily update
> the commit description.

Since I found two H3-ES2.0 Starter Kit samples with different amount of
RAM (4 vs 8 GiB) each having a unique board id [1], I take this as
evidence that Renesas encodes the amount of RAM in the board id.
Therefore, I will not change the description of this patch in v2,
unless you comment/NAK. Thank you.

[1] https://patchwork.kernel.org/patch/10555957/#22169325

Best regards,
Eugeniu.

Re: [PATCH 09/14] dt-bindings: arm: Document Renesas R-Car M3-N-based ULCB board

[jacopo mondi]

[-- Attachment #1: Type: text/plain, Size: 2153 bytes --]

Hello Engeniu,

On Fri, Aug 10, 2018 at 03:48:44PM +0200, Eugeniu Rosca wrote:
> Hi again Jacopo,
>
> On Mon, Aug 06, 2018 at 12:40:02AM +0200, Eugeniu Rosca wrote:
> > Hi Jacopo,
> >
> > Thanks for your comments. Please, find my replies below.
> >
> > On Sun, Aug 05, 2018 at 10:15:43AM +0200, jacopo mondi wrote:
> > > Helle Eugeniu,
> > >
> > > On Sun, Aug 05, 2018 at 01:11:09AM +0200, Eugeniu Rosca wrote:
> > > > In harmony with ATF and U-Boot outputs [1] and [2], the new board is
> > > > based on M3-N revision ES1.1 and the amount of memory present on SiP
> > > > is 2GiB, contiguously addressed.
> > >
> > > Not sure why the amount of installed system memory is relevant for
> > > this commit..
> >
> > To be honest, I don't know precisely what's encoded in the board string
> > (particularly the one documented in this commit RTP0RC77965SKBX010SA00).
> >
> > The only thing unmistakenly present there is the SoC model 77965 (i.e.
> > M3-N), but I am quite clueless about the rest.
> >
> > What I can say for sure is that the end-user experience of a R-Car Gen3
> > reference board clearly depends on below parameters:
> >  - [A] SoC (model, revision) including SRAM and on-chip peripherals
> >  - [B] DRAM (amount, linear/2ch/4ch split)
> >  - [C] Hyperflash (amount)
> >  - [D] board's PCB (revision)
> >  - [E] board's off-chip peripherals (model, revision)
> >
> > I don't know how many of these parameters are embedded in the board
> > string, but since you are suggesting that RAM amount is not (IOW
> > Renesas will potentially release several RTP0RC77965SKBX010SA00
> > boards with different amounts of memory), I will happily update
> > the commit description.
>
> Since I found two H3-ES2.0 Starter Kit samples with different amount of
> RAM (4 vs 8 GiB) each having a unique board id [1], I take this as
> evidence that Renesas encodes the amount of RAM in the board id.
> Therefore, I will not change the description of this patch in v2,
> unless you comment/NAK. Thank you.
>

Thanks for digging into this, feel free to ignore my comment.


> [1] https://patchwork.kernel.org/patch/10555957/#22169325
>
> Best regards,
> Eugeniu.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 10/14] arm64: dts: renesas: r8a77965: ulcb: Initial device tree

[Eugeniu Rosca]

Allow the bare M3-N-based ULCB board to boot.

Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
---
 arch/arm64/boot/dts/renesas/Makefile          |  1 +
 arch/arm64/boot/dts/renesas/r8a77965-ulcb.dts | 37 +++++++++++++++++++++++++++++++++++++
 2 files changed, 38 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
index 5debb02fad2c..ad7be9a8ca56 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -8,6 +8,7 @@ dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb r8a7796-ulcb.dtb
 dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-ulcb-kf.dtb
 dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-xs.dtb
 dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-salvator-x.dtb r8a77965-salvator-xs.dtb
+dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-ulcb.dtb
 dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle.dtb r8a77970-v3msk.dtb
 dtb-$(CONFIG_ARCH_R8A77980) += r8a77980-condor.dtb r8a77980-v3hsk.dtb
 dtb-$(CONFIG_ARCH_R8A77990) += r8a77990-ebisu.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a77965-ulcb.dts b/arch/arm64/boot/dts/renesas/r8a77965-ulcb.dts
new file mode 100644
index 000000000000..4dde14738fb0
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a77965-ulcb.dts
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the M3-N ULCB (R-Car Starter Kit Pro) board
+ *
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ * Copyright (C) 2018 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a77965.dtsi"
+#include "ulcb.dtsi"
+
+/ {
+	model = "Renesas ULCB board based on r8a77965";
+	compatible = "renesas,ulcb", "renesas,r8a77965";
+
+	memory@48000000 {
+		device_type = "memory";
+		/* first 128MB is reserved for secure area. */
+		reg = <0x0 0x48000000 0x0 0x78000000>;
+	};
+};
+
+&du {
+	clocks = <&cpg CPG_MOD 724>,
+		 <&cpg CPG_MOD 723>,
+		 <&cpg CPG_MOD 721>,
+		 <&versaclock5 1>,
+		 <&versaclock5 3>,
+		 <&versaclock5 2>;
+	clock-names = "du.0", "du.1", "du.3",
+		      "dclkin.0", "dclkin.1", "dclkin.3";
+};
-- 
2.18.0

Re: [PATCH 10/14] arm64: dts: renesas: r8a77965: ulcb: Initial device tree

[jacopo mondi]

[-- Attachment #1: Type: text/plain, Size: 2745 bytes --]

Hi Engeniu,

On Sun, Aug 05, 2018 at 01:11:10AM +0200, Eugeniu Rosca wrote:
> Allow the bare M3-N-based ULCB board to boot.
>
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> ---
>  arch/arm64/boot/dts/renesas/Makefile          |  1 +
>  arch/arm64/boot/dts/renesas/r8a77965-ulcb.dts | 37 +++++++++++++++++++++++++++++++++++++
>  2 files changed, 38 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
> index 5debb02fad2c..ad7be9a8ca56 100644
> --- a/arch/arm64/boot/dts/renesas/Makefile
> +++ b/arch/arm64/boot/dts/renesas/Makefile
> @@ -8,6 +8,7 @@ dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb r8a7796-ulcb.dtb
>  dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-ulcb-kf.dtb
>  dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-xs.dtb
>  dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-salvator-x.dtb r8a77965-salvator-xs.dtb
> +dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-ulcb.dtb
>  dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle.dtb r8a77970-v3msk.dtb
>  dtb-$(CONFIG_ARCH_R8A77980) += r8a77980-condor.dtb r8a77980-v3hsk.dtb
>  dtb-$(CONFIG_ARCH_R8A77990) += r8a77990-ebisu.dtb
> diff --git a/arch/arm64/boot/dts/renesas/r8a77965-ulcb.dts b/arch/arm64/boot/dts/renesas/r8a77965-ulcb.dts
> new file mode 100644
> index 000000000000..4dde14738fb0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r8a77965-ulcb.dts
> @@ -0,0 +1,37 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for the M3-N ULCB (R-Car Starter Kit Pro) board
> + *
> + * Copyright (C) 2018 Renesas Electronics Corp.
> + * Copyright (C) 2018 Cogent Embedded, Inc.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2.  This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */

With SPDX identifier you can drop the license text from the patch

> +
> +/dts-v1/;
> +#include "r8a77965.dtsi"
> +#include "ulcb.dtsi"
> +
> +/ {
> +	model = "Renesas ULCB board based on r8a77965";
> +	compatible = "renesas,ulcb", "renesas,r8a77965";
> +
> +	memory@48000000 {
> +		device_type = "memory";
> +		/* first 128MB is reserved for secure area. */
> +		reg = <0x0 0x48000000 0x0 0x78000000>;
> +	};
> +};
I failed to find schematics for this board but comparing this with the M3-N
revision of Salvator-X, this seems correct to me.
> +
> +&du {
> +	clocks = <&cpg CPG_MOD 724>,
> +		 <&cpg CPG_MOD 723>,
> +		 <&cpg CPG_MOD 721>,
> +		 <&versaclock5 1>,
> +		 <&versaclock5 3>,
> +		 <&versaclock5 2>;
> +	clock-names = "du.0", "du.1", "du.3",
> +		      "dclkin.0", "dclkin.1", "dclkin.3";
> +};
Ditto.

With the license things fixed,
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

Thanks
  j
> --
> 2.18.0
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 11/14] dt-bindings: can: rcar_can: document r8a77965 can support

[Eugeniu Rosca]

After adding CAN support to arch/arm64/boot/dts/renesas/r8a77965.dtsi,
checkpatch complained that the new compatible string
"renesas,can-r8a77965" is not documented. Fix the warning.

Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
---
 Documentation/devicetree/bindings/net/can/rcar_can.txt | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
index 94a7f33ac5e9..23264451a5a4 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
@@ -13,6 +13,7 @@ Required properties:
 	      "renesas,can-r8a7794" if CAN controller is a part of R8A7794 SoC.
 	      "renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC.
 	      "renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC.
+	      "renesas,can-r8a77965" if CAN controller is a part of R8A77965 SoC.
 	      "renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device.
 	      "renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1
 	      compatible device.
@@ -28,9 +29,8 @@ Required properties:
 - pinctrl-0: pin control group to be used for this controller.
 - pinctrl-names: must be "default".
 
-Required properties for "renesas,can-r8a7795" and "renesas,can-r8a7796"
-compatible:
-In R8A7795 and R8A7796 SoCs, "clkp2" can be CANFD clock. This is a div6 clock
+Required properties for compatibles [A], [B] and [C]:
+For the denoted SoCs, "clkp2" can be CANFD clock. This is a div6 clock
 and can be used by both CAN and CAN FD controller at the same time. It needs to
 be scaled to maximum frequency if any of these controllers use it. This is done
 using the below properties:
@@ -38,6 +38,10 @@ using the below properties:
 - assigned-clocks: phandle of clkp2(CANFD) clock.
 - assigned-clock-rates: maximum frequency of this clock.
 
+[A] "renesas,can-r8a7795"
+[B] "renesas,can-r8a7796"
+[C] "renesas,can-r8a77965"
+
 Optional properties:
 - renesas,can-clock-select: R-Car CAN Clock Source Select. Valid values are:
 			    <0x0> (default) : Peripheral clock (clkp1)
-- 
2.18.0

Re: [PATCH 11/14] dt-bindings: can: rcar_can: document r8a77965 can support

[Kieran Bingham]

Hi Eugeniu

On 05/08/18 00:11, Eugeniu Rosca wrote:
> After adding CAN support to arch/arm64/boot/dts/renesas/r8a77965.dtsi,
> checkpatch complained that the new compatible string
> "renesas,can-r8a77965" is not documented. Fix the warning.
> 

Thanks to the correct ordering of your patches, (you have this one
*before* adding the CAN support to r8a77965) This commit message seems
to be predicting the future somewhat.

Perhaps just a simpler commit message would suffice:

"Document the support for rcar_can on R8A77965 SoC devices."


> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> ---
>  Documentation/devicetree/bindings/net/can/rcar_can.txt | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> index 94a7f33ac5e9..23264451a5a4 100644
> --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
> +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> @@ -13,6 +13,7 @@ Required properties:
>  	      "renesas,can-r8a7794" if CAN controller is a part of R8A7794 SoC.
>  	      "renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC.
>  	      "renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC.
> +	      "renesas,can-r8a77965" if CAN controller is a part of R8A77965 SoC.
>  	      "renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device.
>  	      "renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1
>  	      compatible device.
> @@ -28,9 +29,8 @@ Required properties:
>  - pinctrl-0: pin control group to be used for this controller.
>  - pinctrl-names: must be "default".
>  
> -Required properties for "renesas,can-r8a7795" and "renesas,can-r8a7796"
> -compatible:
> -In R8A7795 and R8A7796 SoCs, "clkp2" can be CANFD clock. This is a div6 clock
> +Required properties for compatibles [A], [B] and [C]:
> +For the denoted SoCs, "clkp2" can be CANFD clock. This is a div6 clock


This paragraph could be rewrapped...

>  and can be used by both CAN and CAN FD controller at the same time. It needs to
>  be scaled to maximum frequency if any of these controllers use it. This is done
>  using the below properties:
> @@ -38,6 +38,10 @@ using the below properties:
>  - assigned-clocks: phandle of clkp2(CANFD) clock.
>  - assigned-clock-rates: maximum frequency of this clock.
>  
> +[A] "renesas,can-r8a7795"
> +[B] "renesas,can-r8a7796"
> +[C] "renesas,can-r8a77965"
> +>  Optional properties:
>  - renesas,can-clock-select: R-Car CAN Clock Source Select. Valid values are:
>  			    <0x0> (default) : Peripheral clock (clkp1)
> 

Re: [PATCH 11/14] dt-bindings: can: rcar_can: document r8a77965 can support

[Eugeniu Rosca]

Hi Kieran,

On Mon, Aug 06, 2018 at 11:56:56AM +0100, Kieran Bingham wrote:
> Hi Eugeniu
> 
> On 05/08/18 00:11, Eugeniu Rosca wrote:
> > After adding CAN support to arch/arm64/boot/dts/renesas/r8a77965.dtsi,
> > checkpatch complained that the new compatible string
> > "renesas,can-r8a77965" is not documented. Fix the warning.
> > 
> 
> Thanks to the correct ordering of your patches, (you have this one
> *before* adding the CAN support to r8a77965) This commit message seems
> to be predicting the future somewhat.
> 
> Perhaps just a simpler commit message would suffice:
> 
> "Document the support for rcar_can on R8A77965 SoC devices."

I like giving the true story behind the patch and the story was that I
was hit by the checkpatch warning, fixed it and re-ordered the commits.
But I will use your version if it sounds better to you.

> 
> > Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> > ---
> >  Documentation/devicetree/bindings/net/can/rcar_can.txt | 10 +++++++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> > index 94a7f33ac5e9..23264451a5a4 100644
> > --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
> > +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> > @@ -13,6 +13,7 @@ Required properties:
> >  	      "renesas,can-r8a7794" if CAN controller is a part of R8A7794 SoC.
> >  	      "renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC.
> >  	      "renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC.
> > +	      "renesas,can-r8a77965" if CAN controller is a part of R8A77965 SoC.
> >  	      "renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device.
> >  	      "renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1
> >  	      compatible device.
> > @@ -28,9 +29,8 @@ Required properties:
> >  - pinctrl-0: pin control group to be used for this controller.
> >  - pinctrl-names: must be "default".
> >  
> > -Required properties for "renesas,can-r8a7795" and "renesas,can-r8a7796"
> > -compatible:
> > -In R8A7795 and R8A7796 SoCs, "clkp2" can be CANFD clock. This is a div6 clock
> > +Required properties for compatibles [A], [B] and [C]:
> > +For the denoted SoCs, "clkp2" can be CANFD clock. This is a div6 clock
> 
> 
> This paragraph could be rewrapped...

Will implement in v2.

> 
> >  and can be used by both CAN and CAN FD controller at the same time. It needs to
> >  be scaled to maximum frequency if any of these controllers use it. This is done
> >  using the below properties:
> > @@ -38,6 +38,10 @@ using the below properties:
> >  - assigned-clocks: phandle of clkp2(CANFD) clock.
> >  - assigned-clock-rates: maximum frequency of this clock.
> >  
> > +[A] "renesas,can-r8a7795"
> > +[B] "renesas,can-r8a7796"
> > +[C] "renesas,can-r8a77965"
> > +>  Optional properties:
> >  - renesas,can-clock-select: R-Car CAN Clock Source Select. Valid values are:
> >  			    <0x0> (default) : Peripheral clock (clkp1)
> > 
> 

Thanks,
Eugeniu.

Re: [PATCH 11/14] dt-bindings: can: rcar_can: document r8a77965 can support

[Sergei Shtylyov]

Hello!

On 08/05/2018 02:11 AM, Eugeniu Rosca wrote:

> After adding CAN support to arch/arm64/boot/dts/renesas/r8a77965.dtsi,
> checkpatch complained that the new compatible string
> "renesas,can-r8a77965" is not documented. Fix the warning.
> 
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> ---
>  Documentation/devicetree/bindings/net/can/rcar_can.txt | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> index 94a7f33ac5e9..23264451a5a4 100644
> --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
> +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
[...]
> @@ -28,9 +29,8 @@ Required properties:
>  - pinctrl-0: pin control group to be used for this controller.
>  - pinctrl-names: must be "default".
>  
> -Required properties for "renesas,can-r8a7795" and "renesas,can-r8a7796"
> -compatible:
> -In R8A7795 and R8A7796 SoCs, "clkp2" can be CANFD clock. This is a div6 clock
> +Required properties for compatibles [A], [B] and [C]:

   I'd suggest to avoid the footnotes:

Required properties for compatibles R8A7795, R8A7796, and R8A77965:

> +For the denoted SoCs, "clkp2" can be CANFD clock. This is a div6 clock
>  and can be used by both CAN and CAN FD controller at the same time. It needs to
>  be scaled to maximum frequency if any of these controllers use it. This is done
>  using the below properties:
[...]

MBR, Sergei

Re: [PATCH 11/14] dt-bindings: can: rcar_can: document r8a77965 can support

[Eugeniu Rosca]

Hi Sergei,

On Mon, Aug 06, 2018 at 06:21:09PM +0300, Sergei Shtylyov wrote:
> Hello!
> 
> On 08/05/2018 02:11 AM, Eugeniu Rosca wrote:
> 
> > After adding CAN support to arch/arm64/boot/dts/renesas/r8a77965.dtsi,
> > checkpatch complained that the new compatible string
> > "renesas,can-r8a77965" is not documented. Fix the warning.
> > 
> > Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> > ---
> >  Documentation/devicetree/bindings/net/can/rcar_can.txt | 10 +++++++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> > index 94a7f33ac5e9..23264451a5a4 100644
> > --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
> > +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> [...]
> > @@ -28,9 +29,8 @@ Required properties:
> >  - pinctrl-0: pin control group to be used for this controller.
> >  - pinctrl-names: must be "default".
> >  
> > -Required properties for "renesas,can-r8a7795" and "renesas,can-r8a7796"
> > -compatible:
> > -In R8A7795 and R8A7796 SoCs, "clkp2" can be CANFD clock. This is a div6 clock
> > +Required properties for compatibles [A], [B] and [C]:
> 
>    I'd suggest to avoid the footnotes:
> 
> Required properties for compatibles R8A7795, R8A7796, and R8A77965:

I like this proposal, since it is the least intrusive and allows future
addition of SoC models with minimum amount of lines changed. Will use it
in v2.

> 
> > +For the denoted SoCs, "clkp2" can be CANFD clock. This is a div6 clock
> >  and can be used by both CAN and CAN FD controller at the same time. It needs to
> >  be scaled to maximum frequency if any of these controllers use it. This is done
> >  using the below properties:
> [...]
> 
> MBR, Sergei

Thanks,
Eugeniu.

Re: [PATCH 11/14] dt-bindings: can: rcar_can: document r8a77965 can support

[Sergei Shtylyov]

On 08/06/2018 06:21 PM, Sergei Shtylyov wrote:

>> After adding CAN support to arch/arm64/boot/dts/renesas/r8a77965.dtsi,
>> checkpatch complained that the new compatible string
>> "renesas,can-r8a77965" is not documented. Fix the warning.
>>
>> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
>> ---
>>  Documentation/devicetree/bindings/net/can/rcar_can.txt | 10 +++++++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
>> index 94a7f33ac5e9..23264451a5a4 100644
>> --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
>> +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> [...]
>> @@ -28,9 +29,8 @@ Required properties:
>>  - pinctrl-0: pin control group to be used for this controller.
>>  - pinctrl-names: must be "default".
>>  
>> -Required properties for "renesas,can-r8a7795" and "renesas,can-r8a7796"
>> -compatible:
>> -In R8A7795 and R8A7796 SoCs, "clkp2" can be CANFD clock. This is a div6 clock
>> +Required properties for compatibles [A], [B] and [C]:
> 
>    I'd suggest to avoid the footnotes:
> 
> Required properties for compatibles R8A7795, R8A7796, and R8A77965:

   Oops, the word "compatibles" shouldn't have been there...

>> +For the denoted SoCs, "clkp2" can be CANFD clock. This is a div6 clock
>>  and can be used by both CAN and CAN FD controller at the same time. It needs to
>>  be scaled to maximum frequency if any of these controllers use it. This is done
>>  using the below properties:
> [...]

MBR, Sergei

[PATCH 12/14] arm64: dts: renesas: r8a77965: add CAN support

[Eugeniu Rosca]

According to R-Car Gen3 HW manual rev0.55E, R-Car M3-N has two CAN
interfaces, similar to H3, M3-W and other SoCs from the same family.

Add CAN nodes to avoid below r8a77965-ulcb-kf.dtb build failure:
Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:19.1-6 Label or path can0 not found
Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:25.1-6 Label or path can1 not found

CAN support is inspired from below commits:
 - v4.7 commit 308b7e4ba62e ("arm64: dts: r8a7795: Add CAN support")
 - v4.11 commit 909c16252415 ("arm64: dts: r8a7796: Add CAN support")
 - v4.12 commit bec0948e810f ("arm64: dts: r8a7796: Add reset control properties")

Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 486aecacb22a..cb8f8573d9ef 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -656,6 +656,38 @@
 			status = "disabled";
 		};
 
+		can0: can@e6c30000 {
+			compatible = "renesas,can-r8a77965",
+				     "renesas,rcar-gen3-can";
+			reg = <0 0xe6c30000 0 0x1000>;
+			interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 916>,
+			       <&cpg CPG_CORE R8A77965_CLK_CANFD>,
+			       <&can_clk>;
+			clock-names = "clkp1", "clkp2", "can_clk";
+			assigned-clocks = <&cpg CPG_CORE R8A77965_CLK_CANFD>;
+			assigned-clock-rates = <40000000>;
+			power-domains = <&sysc R8A77965_PD_ALWAYS_ON>;
+			resets = <&cpg 916>;
+			status = "disabled";
+		};
+
+		can1: can@e6c38000 {
+			compatible = "renesas,can-r8a77965",
+				     "renesas,rcar-gen3-can";
+			reg = <0 0xe6c38000 0 0x1000>;
+			interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 915>,
+			       <&cpg CPG_CORE R8A77965_CLK_CANFD>,
+			       <&can_clk>;
+			clock-names = "clkp1", "clkp2", "can_clk";
+			assigned-clocks = <&cpg CPG_CORE R8A77965_CLK_CANFD>;
+			assigned-clock-rates = <40000000>;
+			power-domains = <&sysc R8A77965_PD_ALWAYS_ON>;
+			resets = <&cpg 915>;
+			status = "disabled";
+		};
+
 		pwm0: pwm@e6e30000 {
 			compatible = "renesas,pwm-r8a77965", "renesas,pwm-rcar";
 			reg = <0 0xe6e30000 0 8>;
-- 
2.18.0

Re: [PATCH 12/14] arm64: dts: renesas: r8a77965: add CAN support

[Kieran Bingham]

Hi Eugeniu,

On 05/08/18 00:11, Eugeniu Rosca wrote:
> According to R-Car Gen3 HW manual rev0.55E, R-Car M3-N has two CAN

rev 0.55E sounds like rather an old version of this document. Do you
have access to the later rev1.00 release?

(Not an issue for this patch itself, I can confirm that revision 1.00
still confirms M3-N CAN support)

> interfaces, similar to H3, M3-W and other SoCs from the same family.
> 
> Add CAN nodes to avoid below r8a77965-ulcb-kf.dtb build failure:
> Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:19.1-6 Label or path can0 not found
> Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:25.1-6 Label or path can1 not found

Again, this is somewhat referencing the future, as (in patch sequence)
the file "r8a77965-ulcb-kf.dts" does not yet exist, so does not really
need to be mentioned here.


> CAN support is inspired from below commits:
>  - v4.7 commit 308b7e4ba62e ("arm64: dts: r8a7795: Add CAN support")
>  - v4.11 commit 909c16252415 ("arm64: dts: r8a7796: Add CAN support")
>  - v4.12 commit bec0948e810f ("arm64: dts: r8a7796: Add reset control properties")
> 
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> ---
>  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 32 ++++++++++++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> index 486aecacb22a..cb8f8573d9ef 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> @@ -656,6 +656,38 @@
>  			status = "disabled";
>  		};
>  
> +		can0: can@e6c30000 {
> +			compatible = "renesas,can-r8a77965",
> +				     "renesas,rcar-gen3-can";
> +			reg = <0 0xe6c30000 0 0x1000>;
> +			interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&cpg CPG_MOD 916>,
> +			       <&cpg CPG_CORE R8A77965_CLK_CANFD>,
> +			       <&can_clk>;
> +			clock-names = "clkp1", "clkp2", "can_clk";
> +			assigned-clocks = <&cpg CPG_CORE R8A77965_CLK_CANFD>;
> +			assigned-clock-rates = <40000000>;

This doesn't look right. Sections 52A.2 has a note stating:

CANFD? must be set as follows.
R-Car H3, R-Car M3-W, R-Car M3-N, R-Car V3M, R-Car V3H, R-Car E3: 80 (MHz)

R-Car D3: 40 (MHz)


Could you verify / check in case this value should be 80MHz?

> +			power-domains = <&sysc R8A77965_PD_ALWAYS_ON>;
> +			resets = <&cpg 916>;
> +			status = "disabled";
> +		};
> +
> +		can1: can@e6c38000 {
> +			compatible = "renesas,can-r8a77965",
> +				     "renesas,rcar-gen3-can";
> +			reg = <0 0xe6c38000 0 0x1000>;
> +			interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&cpg CPG_MOD 915>,
> +			       <&cpg CPG_CORE R8A77965_CLK_CANFD>,
> +			       <&can_clk>;
> +			clock-names = "clkp1", "clkp2", "can_clk";
> +			assigned-clocks = <&cpg CPG_CORE R8A77965_CLK_CANFD>;
> +			assigned-clock-rates = <40000000>;

Same here of course.


> +			power-domains = <&sysc R8A77965_PD_ALWAYS_ON>;
> +			resets = <&cpg 915>;
> +			status = "disabled";
> +		};
> +
>  		pwm0: pwm@e6e30000 {
>  			compatible = "renesas,pwm-r8a77965", "renesas,pwm-rcar";
>  			reg = <0 0xe6e30000 0 8>;
> 

Re: [PATCH 12/14] arm64: dts: renesas: r8a77965: add CAN support

[Eugeniu Rosca]

Hi Kieran,

On Mon, Aug 06, 2018 at 12:11:22PM +0100, Kieran Bingham wrote:
> Hi Eugeniu,
> 
> On 05/08/18 00:11, Eugeniu Rosca wrote:
> > According to R-Car Gen3 HW manual rev0.55E, R-Car M3-N has two CAN
> 
> rev 0.55E sounds like rather an old version of this document. Do you
> have access to the later rev1.00 release?

Thanks for this feedback. I was able to find the newer version.

> 
> (Not an issue for this patch itself, I can confirm that revision 1.00
> still confirms M3-N CAN support)
> 
> > interfaces, similar to H3, M3-W and other SoCs from the same family.
> > 
> > Add CAN nodes to avoid below r8a77965-ulcb-kf.dtb build failure:
> > Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:19.1-6 Label or path can0 not found
> > Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:25.1-6 Label or path can1 not found
> 
> Again, this is somewhat referencing the future, as (in patch sequence)
> the file "r8a77965-ulcb-kf.dts" does not yet exist, so does not really
> need to be mentioned here.

Will remove the "r8a77965-ulcb-kf.dtb" line from commit description.

> 
> 
> > CAN support is inspired from below commits:
> >  - v4.7 commit 308b7e4ba62e ("arm64: dts: r8a7795: Add CAN support")
> >  - v4.11 commit 909c16252415 ("arm64: dts: r8a7796: Add CAN support")
> >  - v4.12 commit bec0948e810f ("arm64: dts: r8a7796: Add reset control properties")
> > 
> > Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> > ---
> >  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 32 ++++++++++++++++++++++++++++++++
> >  1 file changed, 32 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > index 486aecacb22a..cb8f8573d9ef 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > @@ -656,6 +656,38 @@
> >  			status = "disabled";
> >  		};
> >  
> > +		can0: can@e6c30000 {
> > +			compatible = "renesas,can-r8a77965",
> > +				     "renesas,rcar-gen3-can";
> > +			reg = <0 0xe6c30000 0 0x1000>;
> > +			interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
> > +			clocks = <&cpg CPG_MOD 916>,
> > +			       <&cpg CPG_CORE R8A77965_CLK_CANFD>,
> > +			       <&can_clk>;
> > +			clock-names = "clkp1", "clkp2", "can_clk";
> > +			assigned-clocks = <&cpg CPG_CORE R8A77965_CLK_CANFD>;
> > +			assigned-clock-rates = <40000000>;
> 
> This doesn't look right. Sections 52A.2 has a note stating:
> 
> CANFD? must be set as follows.
> R-Car H3, R-Car M3-W, R-Car M3-N, R-Car V3M, R-Car V3H, R-Car E3: 80 (MHz)
> 
> R-Car D3: 40 (MHz)
> 
> 
> Could you verify / check in case this value should be 80MHz?

Are you sure section "52A. CAN-FD" is the right one for describing the
CAN (non-FD) nodes? For non-FD CAN there is another chapter called
"52. Controller Area Network Interface (CAN interface)". Since the
latter doesn't point out any differences between M3-W and M3-N, I
re-used the M3-W (r8A7796.dtsi) configuration.

FWIW, r8a7795 (H3), r8a7796 (M3) and r8a77995 (D3) all currently
(v4.18-rc8) use the same "assigned-clock-rates" value for can0
and can1 nodes:

$ git grep -E -A 10 "can[01]:" -- arch/arm64/boot/dts/renesas | grep assigned-clock-rates
arch/arm64/boot/dts/renesas/r8a7795.dtsi-	assigned-clock-rates = <40000000>;
arch/arm64/boot/dts/renesas/r8a7795.dtsi-	assigned-clock-rates = <40000000>;
arch/arm64/boot/dts/renesas/r8a7796.dtsi-	assigned-clock-rates = <40000000>;
arch/arm64/boot/dts/renesas/r8a7796.dtsi-	assigned-clock-rates = <40000000>;
arch/arm64/boot/dts/renesas/r8a77995.dtsi-	assigned-clock-rates = <40000000>;
arch/arm64/boot/dts/renesas/r8a77995.dtsi-	assigned-clock-rates = <40000000>;

Anyway, given that this patch only intended to avoid the "make dtbs"
failure and given that any CAN tests are out of scope, I will just leave
a placeholder for can0 and can1 nodes, as suggested by Geert.

> 
> > +			power-domains = <&sysc R8A77965_PD_ALWAYS_ON>;
> > +			resets = <&cpg 916>;
> > +			status = "disabled";
> > +		};
> > +
> > +		can1: can@e6c38000 {
> > +			compatible = "renesas,can-r8a77965",
> > +				     "renesas,rcar-gen3-can";
> > +			reg = <0 0xe6c38000 0 0x1000>;
> > +			interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
> > +			clocks = <&cpg CPG_MOD 915>,
> > +			       <&cpg CPG_CORE R8A77965_CLK_CANFD>,
> > +			       <&can_clk>;
> > +			clock-names = "clkp1", "clkp2", "can_clk";
> > +			assigned-clocks = <&cpg CPG_CORE R8A77965_CLK_CANFD>;
> > +			assigned-clock-rates = <40000000>;
> 
> Same here of course.
> 
> 
> > +			power-domains = <&sysc R8A77965_PD_ALWAYS_ON>;
> > +			resets = <&cpg 915>;
> > +			status = "disabled";
> > +		};
> > +
> >  		pwm0: pwm@e6e30000 {
> >  			compatible = "renesas,pwm-r8a77965", "renesas,pwm-rcar";
> >  			reg = <0 0xe6e30000 0 8>;
> > 
> 

Thanks,
Eugeniu.

Re: [PATCH 12/14] arm64: dts: renesas: r8a77965: add CAN support

[Kieran Bingham]

Hi Eugeniu,

On 06/08/18 21:14, Eugeniu Rosca wrote:
> Hi Kieran,
> 
> On Mon, Aug 06, 2018 at 12:11:22PM +0100, Kieran Bingham wrote:
>> Hi Eugeniu,
>>
>> On 05/08/18 00:11, Eugeniu Rosca wrote:
>>> According to R-Car Gen3 HW manual rev0.55E, R-Car M3-N has two CAN
>>
>> rev 0.55E sounds like rather an old version of this document. Do you
>> have access to the later rev1.00 release?
> 
> Thanks for this feedback. I was able to find the newer version.
> 
>>
>> (Not an issue for this patch itself, I can confirm that revision 1.00
>> still confirms M3-N CAN support)
>>
>>> interfaces, similar to H3, M3-W and other SoCs from the same family.
>>>
>>> Add CAN nodes to avoid below r8a77965-ulcb-kf.dtb build failure:
>>> Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:19.1-6 Label or path can0 not found
>>> Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:25.1-6 Label or path can1 not found
>>
>> Again, this is somewhat referencing the future, as (in patch sequence)
>> the file "r8a77965-ulcb-kf.dts" does not yet exist, so does not really
>> need to be mentioned here.
> 
> Will remove the "r8a77965-ulcb-kf.dtb" line from commit description.
> 
>>
>>
>>> CAN support is inspired from below commits:
>>>  - v4.7 commit 308b7e4ba62e ("arm64: dts: r8a7795: Add CAN support")
>>>  - v4.11 commit 909c16252415 ("arm64: dts: r8a7796: Add CAN support")
>>>  - v4.12 commit bec0948e810f ("arm64: dts: r8a7796: Add reset control properties")
>>>
>>> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
>>> ---
>>>  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 32 ++++++++++++++++++++++++++++++++
>>>  1 file changed, 32 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>>> index 486aecacb22a..cb8f8573d9ef 100644
>>> --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>>> +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>>> @@ -656,6 +656,38 @@
>>>  			status = "disabled";
>>>  		};
>>>  
>>> +		can0: can@e6c30000 {
>>> +			compatible = "renesas,can-r8a77965",
>>> +				     "renesas,rcar-gen3-can";
>>> +			reg = <0 0xe6c30000 0 0x1000>;
>>> +			interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
>>> +			clocks = <&cpg CPG_MOD 916>,
>>> +			       <&cpg CPG_CORE R8A77965_CLK_CANFD>,
>>> +			       <&can_clk>;
>>> +			clock-names = "clkp1", "clkp2", "can_clk";
>>> +			assigned-clocks = <&cpg CPG_CORE R8A77965_CLK_CANFD>;
>>> +			assigned-clock-rates = <40000000>;
>>
>> This doesn't look right. Sections 52A.2 has a note stating:
>>
>> CANFD? must be set as follows.
>> R-Car H3, R-Car M3-W, R-Car M3-N, R-Car V3M, R-Car V3H, R-Car E3: 80 (MHz)
>>
>> R-Car D3: 40 (MHz)
>>
>>
>> Could you verify / check in case this value should be 80MHz?
> 
> Are you sure section "52A. CAN-FD" is the right one for describing the
> CAN (non-FD) nodes? For non-FD CAN there is another chapter called
> "52. Controller Area Network Interface (CAN interface)". Since the
> latter doesn't point out any differences between M3-W and M3-N, I
> re-used the M3-W (r8A7796.dtsi) configuration.

My apologies - It looks like I had got the wrong section.

> 
> FWIW, r8a7795 (H3), r8a7796 (M3) and r8a77995 (D3) all currently
> (v4.18-rc8) use the same "assigned-clock-rates" value for can0
> and can1 nodes:
> 
> $ git grep -E -A 10 "can[01]:" -- arch/arm64/boot/dts/renesas | grep assigned-clock-rates
> arch/arm64/boot/dts/renesas/r8a7795.dtsi-	assigned-clock-rates = <40000000>;
> arch/arm64/boot/dts/renesas/r8a7795.dtsi-	assigned-clock-rates = <40000000>;
> arch/arm64/boot/dts/renesas/r8a7796.dtsi-	assigned-clock-rates = <40000000>;
> arch/arm64/boot/dts/renesas/r8a7796.dtsi-	assigned-clock-rates = <40000000>;
> arch/arm64/boot/dts/renesas/r8a77995.dtsi-	assigned-clock-rates = <40000000>;
> arch/arm64/boot/dts/renesas/r8a77995.dtsi-	assigned-clock-rates = <40000000>;
> 
> Anyway, given that this patch only intended to avoid the "make dtbs"
> failure and given that any CAN tests are out of scope, I will just leave
> a placeholder for can0 and can1 nodes, as suggested by Geert.

Well - I certainly have no complaints about functionality which isn't
present :)

--
Regards

Kieran



> 
>>
>>> +			power-domains = <&sysc R8A77965_PD_ALWAYS_ON>;
>>> +			resets = <&cpg 916>;
>>> +			status = "disabled";
>>> +		};
>>> +
>>> +		can1: can@e6c38000 {
>>> +			compatible = "renesas,can-r8a77965",
>>> +				     "renesas,rcar-gen3-can";
>>> +			reg = <0 0xe6c38000 0 0x1000>;
>>> +			interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
>>> +			clocks = <&cpg CPG_MOD 915>,
>>> +			       <&cpg CPG_CORE R8A77965_CLK_CANFD>,
>>> +			       <&can_clk>;
>>> +			clock-names = "clkp1", "clkp2", "can_clk";
>>> +			assigned-clocks = <&cpg CPG_CORE R8A77965_CLK_CANFD>;
>>> +			assigned-clock-rates = <40000000>;
>>
>> Same here of course.
>>
>>
>>> +			power-domains = <&sysc R8A77965_PD_ALWAYS_ON>;
>>> +			resets = <&cpg 915>;
>>> +			status = "disabled";
>>> +		};
>>> +
>>>  		pwm0: pwm@e6e30000 {
>>>  			compatible = "renesas,pwm-r8a77965", "renesas,pwm-rcar";
>>>  			reg = <0 0xe6e30000 0 8>;
>>>
>>
> 
> Thanks,
> Eugeniu.
> 

Re: [PATCH 12/14] arm64: dts: renesas: r8a77965: add CAN support

[Geert Uytterhoeven]

Hi Eugeniu,

On Sun, Aug 5, 2018 at 1:14 AM Eugeniu Rosca <roscaeugeniu@gmail.com> wrote:
> According to R-Car Gen3 HW manual rev0.55E, R-Car M3-N has two CAN
> interfaces, similar to H3, M3-W and other SoCs from the same family.
>
> Add CAN nodes to avoid below r8a77965-ulcb-kf.dtb build failure:
> Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:19.1-6 Label or path can0 not found
> Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:25.1-6 Label or path can1 not found
>
> CAN support is inspired from below commits:
>  - v4.7 commit 308b7e4ba62e ("arm64: dts: r8a7795: Add CAN support")
>  - v4.11 commit 909c16252415 ("arm64: dts: r8a7796: Add CAN support")
>  - v4.12 commit bec0948e810f ("arm64: dts: r8a7796: Add reset control properties")
>
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>

Thanks for your patch!

Have you actually tested CAN operation, or were you just fixing the
build failure?
In case of the latter, please just add minimal placeholders, like were present
for other device nodes in early versions of r8a77965.dtsi.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 12/14] arm64: dts: renesas: r8a77965: add CAN support

[Eugeniu Rosca]

Hi Geert,

On Mon, Aug 06, 2018 at 05:15:37PM +0200, Geert Uytterhoeven wrote:
> Hi Eugeniu,
> 
> On Sun, Aug 5, 2018 at 1:14 AM Eugeniu Rosca <roscaeugeniu@gmail.com> wrote:
> > According to R-Car Gen3 HW manual rev0.55E, R-Car M3-N has two CAN
> > interfaces, similar to H3, M3-W and other SoCs from the same family.
> >
> > Add CAN nodes to avoid below r8a77965-ulcb-kf.dtb build failure:
> > Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:19.1-6 Label or path can0 not found
> > Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:25.1-6 Label or path can1 not found
> >
> > CAN support is inspired from below commits:
> >  - v4.7 commit 308b7e4ba62e ("arm64: dts: r8a7795: Add CAN support")
> >  - v4.11 commit 909c16252415 ("arm64: dts: r8a7796: Add CAN support")
> >  - v4.12 commit bec0948e810f ("arm64: dts: r8a7796: Add reset control properties")
> >
> > Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> 
> Thanks for your patch!
> 
> Have you actually tested CAN operation, or were you just fixing the
> build failure?
> In case of the latter, please just add minimal placeholders, like were present
> for other device nodes in early versions of r8a77965.dtsi.

Same as replied to Kieran, I will add some skeleton nodes for can0 and
can1, just to avoid DTC errors. It was not my goal to do CAN bring-up.

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Best regards,
Eugeniu.

[PATCH 13/14] arm64: dts: renesas: r8a77965: Add HSCIF0 device node

[Eugeniu Rosca]

Add hscif0 node to avoid below r8a77965-ulcb-kf.dtb build failure:
Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:36.1-8 Label or path hscif0 not found

Inspired from v4.12-rc1 commits:
 - commit 68cd16107260 ("arm64: dts: r8a7796 dtsi: Add all HSCIF nodes")
 - commit 6d50bb893504 ("arm64: dts: r8a7796: Enable HSCIF DMA")
 - commit bec0948e810f ("arm64: dts: r8a7796: Add reset control properties")

Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index cb8f8573d9ef..53405af41e34 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -451,6 +451,24 @@
 			status = "disabled";
 		};
 
+		hscif0: serial@e6540000 {
+			compatible = "renesas,hscif-r8a77965",
+				     "renesas,rcar-gen3-hscif",
+				     "renesas,hscif";
+			reg = <0 0xe6540000 0 0x60>;
+			interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 520>,
+				 <&cpg CPG_CORE R8A77965_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "brg_int", "scif_clk";
+			dmas = <&dmac1 0x31>, <&dmac1 0x30>,
+			       <&dmac2 0x31>, <&dmac2 0x30>;
+			dma-names = "tx", "rx", "tx", "rx";
+			power-domains = <&sysc R8A77965_PD_ALWAYS_ON>;
+			resets = <&cpg 520>;
+			status = "disabled";
+		};
+
 		hsusb: usb@e6590000 {
 			compatible = "renesas,usbhs-r8a7796",
 				     "renesas,rcar-gen3-usbhs";
-- 
2.18.0

Re: [PATCH 13/14] arm64: dts: renesas: r8a77965: Add HSCIF0 device node

[Eugeniu Rosca]

Hello Simon, Geert, Takeshi,

On Sun, Aug 05, 2018 at 01:11:13AM +0200, Eugeniu Rosca wrote:
> Add hscif0 node to avoid below r8a77965-ulcb-kf.dtb build failure:
> Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:36.1-8 Label or path hscif0 not found
> 
> Inspired from v4.12-rc1 commits:
>  - commit 68cd16107260 ("arm64: dts: r8a7796 dtsi: Add all HSCIF nodes")
>  - commit 6d50bb893504 ("arm64: dts: r8a7796: Enable HSCIF DMA")
>  - commit bec0948e810f ("arm64: dts: r8a7796: Add reset control properties")
> 
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> ---
>  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)

I noticed that this patch (adding HSCIF0 node only) conflicts with
below commit (adding all HSCIF nodes) from the "devel" branch of
horms/renesas.git repository:

https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git/commit/?h=b8e3c8e17611

Please, feel free to ignore my patch. It only ensures that this series
doesn't break the "make dtbs" build.

Thanks,
Eugeniu.

[PATCH 14/14] arm64: dts: renesas: r8a77965: ulcb-kf: Initial device tree

[Eugeniu Rosca]

Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
---
 arch/arm64/boot/dts/renesas/Makefile             |  1 +
 arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dts | 20 ++++++++++++++++++++
 2 files changed, 21 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
index ad7be9a8ca56..3e2c5be65a14 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-ulcb-kf.dtb
 dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-xs.dtb
 dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-salvator-x.dtb r8a77965-salvator-xs.dtb
 dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-ulcb.dtb
+dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-ulcb-kf.dtb
 dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle.dtb r8a77970-v3msk.dtb
 dtb-$(CONFIG_ARCH_R8A77980) += r8a77980-condor.dtb r8a77980-v3hsk.dtb
 dtb-$(CONFIG_ARCH_R8A77990) += r8a77990-ebisu.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dts b/arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dts
new file mode 100644
index 000000000000..5c719fb87d8b
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dts
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the M3-N ULCB Kingfisher board
+ *
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ * Copyright (C) 2018 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include "r8a77965-ulcb.dts"
+#include "ulcb-kf.dtsi"
+
+/ {
+	model = "Renesas ULCB Kingfisher board based on r8a77965";
+	compatible = "shimafuji,kingfisher", "renesas,ulcb",
+		     "renesas,r8a77965";
+};
-- 
2.18.0

Re: [PATCH 14/14] arm64: dts: renesas: r8a77965: ulcb-kf: Initial device tree

[jacopo mondi]

[-- Attachment #1: Type: text/plain, Size: 2024 bytes --]

Hi Eugeniu,

On Sun, Aug 05, 2018 at 01:11:14AM +0200, Eugeniu Rosca wrote:
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> ---
>  arch/arm64/boot/dts/renesas/Makefile             |  1 +
>  arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dts | 20 ++++++++++++++++++++
>  2 files changed, 21 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
> index ad7be9a8ca56..3e2c5be65a14 100644
> --- a/arch/arm64/boot/dts/renesas/Makefile
> +++ b/arch/arm64/boot/dts/renesas/Makefile
> @@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-ulcb-kf.dtb
>  dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-xs.dtb
>  dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-salvator-x.dtb r8a77965-salvator-xs.dtb
>  dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-ulcb.dtb
> +dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-ulcb-kf.dtb
>  dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle.dtb r8a77970-v3msk.dtb
>  dtb-$(CONFIG_ARCH_R8A77980) += r8a77980-condor.dtb r8a77980-v3hsk.dtb
>  dtb-$(CONFIG_ARCH_R8A77990) += r8a77990-ebisu.dtb
> diff --git a/arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dts b/arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dts
> new file mode 100644
> index 000000000000..5c719fb87d8b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dts
> @@ -0,0 +1,20 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for the M3-N ULCB Kingfisher board
> + *
> + * Copyright (C) 2018 Renesas Electronics Corp.
> + * Copyright (C) 2018 Cogent Embedded, Inc.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2.  This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */

Drop the license text please :)

Thanks
  j
> +
> +#include "r8a77965-ulcb.dts"
> +#include "ulcb-kf.dtsi"
> +
> +/ {
> +	model = "Renesas ULCB Kingfisher board based on r8a77965";
> +	compatible = "shimafuji,kingfisher", "renesas,ulcb",
> +		     "renesas,r8a77965";
> +};
> --
> 2.18.0
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 14/14] arm64: dts: renesas: r8a77965: ulcb-kf: Initial device tree

[Eugeniu Rosca]

Hi Jacopo,

On Sun, Aug 05, 2018 at 11:01:36AM +0200, jacopo mondi wrote:
> Hi Eugeniu,
> 
> On Sun, Aug 05, 2018 at 01:11:14AM +0200, Eugeniu Rosca wrote:
> > Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> > ---
> >  arch/arm64/boot/dts/renesas/Makefile             |  1 +
> >  arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dts | 20 ++++++++++++++++++++
> >  2 files changed, 21 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
> > index ad7be9a8ca56..3e2c5be65a14 100644
> > --- a/arch/arm64/boot/dts/renesas/Makefile
> > +++ b/arch/arm64/boot/dts/renesas/Makefile
> > @@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-ulcb-kf.dtb
> >  dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-xs.dtb
> >  dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-salvator-x.dtb r8a77965-salvator-xs.dtb
> >  dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-ulcb.dtb
> > +dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-ulcb-kf.dtb
> >  dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle.dtb r8a77970-v3msk.dtb
> >  dtb-$(CONFIG_ARCH_R8A77980) += r8a77980-condor.dtb r8a77980-v3hsk.dtb
> >  dtb-$(CONFIG_ARCH_R8A77990) += r8a77990-ebisu.dtb
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dts b/arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dts
> > new file mode 100644
> > index 000000000000..5c719fb87d8b
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dts
> > @@ -0,0 +1,20 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Device Tree Source for the M3-N ULCB Kingfisher board
> > + *
> > + * Copyright (C) 2018 Renesas Electronics Corp.
> > + * Copyright (C) 2018 Cogent Embedded, Inc.
> > + *
> > + * This file is licensed under the terms of the GNU General Public License
> > + * version 2.  This program is licensed "as is" without any warranty of any
> > + * kind, whether express or implied.
> > + */
> 
> Drop the license text please :)

I will. Thanks!

> 
> Thanks
>   j
> > +
> > +#include "r8a77965-ulcb.dts"
> > +#include "ulcb-kf.dtsi"
> > +
> > +/ {
> > +	model = "Renesas ULCB Kingfisher board based on r8a77965";
> > +	compatible = "shimafuji,kingfisher", "renesas,ulcb",
> > +		     "renesas,r8a77965";
> > +};
> > --
> > 2.18.0
> >

Best regards,
Eugeniu.