arm64: dts: renesas: Cleanup Beacon Kit and support more SoC's

When the board was added, clock drivers were being updated done at the same time to allow the versaclock driver to properly configure the modes. Unforutnately, the updates were not applied to the board

files at the time they should have been, so do it now.

Signed-off-by Adam Ford <[email protected]>

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -0

@@ -5,6 +5,7 @@
 
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/input/input.h>
+#include <dt-bindings/clk/versaclock.h>
 
 / {
        backlight_lvds: backlight-lvds {

Hi Adam,

Quoted 3 lines · Adam Ford

When the board was added, clock drivers were being updated done at the same time to allow the versaclock driver to properly configure the modes. Unforutnately, the updates were not applied to the board

Unfortunately

Quoted 4 lines

files at the time they should have been, so do it now.

Signed-off-by Adam Ford <[email protected]>

Thanks for your patch!

Quoted 8 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -0

@@ -5,6 +5,7 @@
 
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/input/input.h>
+#include <dt-bindings/clk/versaclock.h>
 

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &du_out_rgb { · line 298

Quoted 8 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -1

 / {
        backlight_lvds: backlight-lvds {

@@ -294,12 +295,12 @@ &du_out_rgb {
 &ehci0 {
        dr_mode = "otg";
        status = "okay";
-       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;
+       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&versaclock5 3>;

Why this change? You said before you don't need this
https://lore.kernel.org/linux-renesas-soc/CAHCN7xJWbP16SA-Ok-5syNnqOZAt8OFJo2_rtg5VrNVsN2-eiQ@mail.gmail.com/

BTW, something I missed in the earlier review: is there an override needed at all?

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &du_out_rgb { · line 303

Quoted 7 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -1

 };
 
 &ehci1 {
        status = "okay";
-       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;
+       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&versaclock5 3>;

Same here.

BTW, something I missed in the earlier review: why did you override

    clocks = <&cpg CPG_MOD 702>;

by

    clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;

?

Quoted 2 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +0 -0

 };
 

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi versaclock6_bb: clock-controller@6a { · line 381

Quoted 11 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +5 -1

 &hdmi0 {

@@ -373,12 +374,40 @@ versaclock6_bb: clock-controller@6a {
                #clock-cells = <1>;
                clocks = <&x304_clk>;
                clock-names = "xin";
-               /* CSI0_MCLK, CSI1_MCLK, AUDIO_CLKIN, USB_HUB_MCLK_BB */
+               clock-output-names = "versaclock6_bb.out0_sel_i2cb",
+                                     "versaclock6_bb.out1",
+                                     "versaclock6_bb.out2",
+                                     "versaclock6_bb.out3",
+                                     "versaclock6_bb.out4";

Why? IIUIC, the driver doesn't parse clock-output-names (and it shouldn't).

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi versaclock6_bb: clock-controller@6a { · line 390

Quoted 10 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +4 -0

                assigned-clocks = <&versaclock6_bb 1>,
                                   <&versaclock6_bb 2>,
                                   <&versaclock6_bb 3>,
                                   <&versaclock6_bb 4>;
                assigned-clock-rates =  <24000000>, <24000000>, <24000000>, <24576000>;
+
+               OUT1 {
+                       idt,mode = <VC5_CMOS>;
+                       idt,voltage-microvolts = <1800000>;

Oops. The DT bindings say "idt,voltage-microvolt", the example in the DT bindings says "idt,voltage-microvolts", and the driver parses "idt,voltage-microvolts".

According to Documentation/devicetree/bindings/property-units.txt, the property name should end in "microvolt".

Patch sent.
https://lore.kernel.org/linux-clk/[email protected]/

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi versaclock6_bb: clock-controller@6a { · line 392

Quoted 2 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +2 -0

+                       idt,slew-percent = <100>;
+               };

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

Quoted 3 lines

files at the time they should have been, so do it now.

Signed-off-by Adam Ford <[email protected]>

Thanks for your patch!

Quoted 11 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -0

@@ -5,6 +5,7 @@
 
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/input/input.h>
+#include <dt-bindings/clk/versaclock.h>
 
 / {
        backlight_lvds: backlight-lvds {

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &du_out_rgb { · line 298

Quoted 5 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -1

@@ -294,12 +295,12 @@ &du_out_rgb {
 &ehci0 {
        dr_mode = "otg";
        status = "okay";
-       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;
+       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&versaclock5 3>;

Why this change? You said before you don't need this
https://lore.kernel.org/linux-renesas-soc/CAHCN7xJWbP16SA-Ok-5syNnqOZAt8OFJo2_rtg5VrNVsN2-eiQ@mail.gmail.com/

BTW, something I missed in the earlier review: is there an override needed at all?

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &du_out_rgb { · line 303

Quoted 6 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -1

 };
 
 &ehci1 {
        status = "okay";
-       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;
+       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&versaclock5 3>;

Same here.

BTW, something I missed in the earlier review: why did you override

    clocks = <&cpg CPG_MOD 702>;

by

    clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;

?

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi versaclock6_bb: clock-controller@6a { · line 381

Quoted 13 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +5 -1

 };
 
 &hdmi0 {

@@ -373,12 +374,40 @@ versaclock6_bb: clock-controller@6a {
                #clock-cells = <1>;
                clocks = <&x304_clk>;
                clock-names = "xin";
-               /* CSI0_MCLK, CSI1_MCLK, AUDIO_CLKIN, USB_HUB_MCLK_BB */
+               clock-output-names = "versaclock6_bb.out0_sel_i2cb",
+                                     "versaclock6_bb.out1",
+                                     "versaclock6_bb.out2",
+                                     "versaclock6_bb.out3",
+                                     "versaclock6_bb.out4";

Why? IIUIC, the driver doesn't parse clock-output-names (and it shouldn't).

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi versaclock6_bb: clock-controller@6a { · line 390

Quoted 9 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +4 -0

                assigned-clocks = <&versaclock6_bb 1>,
                                   <&versaclock6_bb 2>,
                                   <&versaclock6_bb 3>,
                                   <&versaclock6_bb 4>;
                assigned-clock-rates =  <24000000>, <24000000>, <24000000>, <24576000>;
+
+               OUT1 {
+                       idt,mode = <VC5_CMOS>;
+                       idt,voltage-microvolts = <1800000>;

Oops. The DT bindings say "idt,voltage-microvolt", the example in the DT bindings says "idt,voltage-microvolts", and the driver parses "idt,voltage-microvolts".

According to Documentation/devicetree/bindings/property-units.txt, the property name should end in "microvolt".

Patch sent.
https://lore.kernel.org/linux-clk/[email protected]/

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi versaclock6_bb: clock-controller@6a { · line 392

Quoted 2 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +2 -0

+                       idt,slew-percent = <100>;
+               };

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

Quoted 13 lines · Geert Uytterhoeven

Quoted 12 lines · Adam Ford

When the board was added, clock drivers were being updated done at the same time to allow the versaclock driver to properly configure the modes. Unforutnately, the updates were not applied to the board

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -0

@@ -5,6 +5,7 @@
 
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/input/input.h>
+#include <dt-bindings/clk/versaclock.h>
 

Quoted 12 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &du_out_rgb { · line 298

Quoted 8 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -1

 / {
        backlight_lvds: backlight-lvds {

@@ -294,12 +295,12 @@ &du_out_rgb {
 &ehci0 {
        dr_mode = "otg";
        status = "okay";
-       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;
+       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&versaclock5 3>;

Why this change? You said before you don't need this
https://lore.kernel.org/linux-renesas-soc/CAHCN7xJWbP16SA-Ok-5syNnqOZAt8OFJo2_rtg5VrNVsN2-eiQ@mail.gmail.com/

I had talked with the hardware guys about buy pre-programmed versaclock chips which would have been pre-configured and pre-enabled. I thought it was going to happen, but it didn't, so we need the versaclock driver to enable the reference clock for the USB controllers, ethernet controller and audio clocks. Previously we were manually configuring it or it was coincidentally working. Ideally, we'd have the clock system intentionally enable/disable the clocks when drivers are loaded/unloaded for for power management reasons.

Thank you for the review. Is that the only patch in the series with concerns? I probably won't get to V2 until this weekend.

Hi Adam,

Quoted 27 lines · Adam Ford

Quoted 13 lines · Geert Uytterhoeven

Quoted 12 lines · Adam Ford

When the board was added, clock drivers were being updated done at the same time to allow the versaclock driver to properly configure the modes. Unforutnately, the updates were not applied to the board

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -0

@@ -5,6 +5,7 @@
 
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/input/input.h>
+#include <dt-bindings/clk/versaclock.h>
 

Quoted 12 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &du_out_rgb { · line 298

Quoted 8 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -1

 / {
        backlight_lvds: backlight-lvds {

@@ -294,12 +295,12 @@ &du_out_rgb {
 &ehci0 {
        dr_mode = "otg";
        status = "okay";
-       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;
+       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&versaclock5 3>;

Why this change? You said before you don't need this
https://lore.kernel.org/linux-renesas-soc/CAHCN7xJWbP16SA-Ok-5syNnqOZAt8OFJo2_rtg5VrNVsN2-eiQ@mail.gmail.com/

Quoted 8 lines

I had talked with the hardware guys about buy pre-programmed versaclock chips which would have been pre-configured and pre-enabled. I thought it was going to happen, but it didn't, so we need the versaclock driver to enable the reference clock for the USB controllers, ethernet controller and audio clocks. Previously we were manually configuring it or it was coincidentally working. Ideally, we'd have the clock system intentionally enable/disable the clocks when drivers are loaded/unloaded for for power management reasons.

Can you tell me how exactly the Versaclock outputs are wired?

E.g. for USB, the bindings don't say anything about a third clock input, so I'd like to know where that clock is fed into USB.

Quoted 3 lines

Thank you for the review. Is that the only patch in the series with concerns? I probably won't get to V2 until this weekend.

Sorry, I still have to review the other patches in your series. Anyway, we have time until the end of January to queue DT patches for v5.12...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

Quoted 37 lines · Geert Uytterhoeven

Quoted 27 lines · Adam Ford

Quoted 13 lines · Geert Uytterhoeven

Quoted 12 lines · Adam Ford

When the board was added, clock drivers were being updated done at the same time to allow the versaclock driver to properly configure the modes. Unforutnately, the updates were not applied to the board

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -0

@@ -5,6 +5,7 @@
 
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/input/input.h>
+#include <dt-bindings/clk/versaclock.h>
 

Quoted 12 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &du_out_rgb { · line 298

Quoted 8 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -1

 / {
        backlight_lvds: backlight-lvds {

@@ -294,12 +295,12 @@ &du_out_rgb {
 &ehci0 {
        dr_mode = "otg";
        status = "okay";
-       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;
+       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&versaclock5 3>;

Why this change? You said before you don't need this
https://lore.kernel.org/linux-renesas-soc/CAHCN7xJWbP16SA-Ok-5syNnqOZAt8OFJo2_rtg5VrNVsN2-eiQ@mail.gmail.com/

Quoted 8 lines

I had talked with the hardware guys about buy pre-programmed versaclock chips which would have been pre-configured and pre-enabled. I thought it was going to happen, but it didn't, so we need the versaclock driver to enable the reference clock for the USB controllers, ethernet controller and audio clocks. Previously we were manually configuring it or it was coincidentally working. Ideally, we'd have the clock system intentionally enable/disable the clocks when drivers are loaded/unloaded for for power management reasons.

Quoted 1 line

Can you tell me how exactly the Versaclock outputs are wired?

The SoC is expecting a fixed external 50 MHz clock connected to USB_EXTAL. Instead of a fixed clock, we're using the Versaclock. We're also using the Versaclock to drive the AVB TXCRefClk, du_dotclkiun0 and du_dotclkin2 (also also called du_dotclkin3 on RZ/G2N) instead of fixed clocks.

Quoted 2 lines

E.g. for USB, the bindings don't say anything about a third clock input, so I'd like to know where that clock is fed into USB.

The way the driver is crafted, it can take in multiple clocks and it goes through a list to enable them all, so I added the versaclock to the array. Without the versaclock reference, the clock doesn't get turned on and the USB fails to operate.

The DU clocks are also expecting an array, so I added the versaclock to that array as well.

It's similar to the rationale that I'm trying to add the option clock for the AVB TXC_Ref clock on the other path. We're using the versaclock there as well. The difference is that in the case of the AVB_TXCRefClk, the driver isn't expecting an array of clocks, it's only expecting a single clock. In order to enable the additional clock, I started the patch to accept the optional clock for the TXCRefClk in order to get the clock system to enable the clock.

Because the Versaclock isn't programmed to automatically start, they need the consumers of the clock to request and enable them.

I admit that I'll probably need to update the bindings to add the extra clocks as optional, so if you want, I can submit additional patches to add these optional clocks to their respective bindings.

Hi Adam,

CC Shimoda-san

Quoted 46 lines · Adam Ford

Quoted 37 lines · Geert Uytterhoeven

Quoted 27 lines · Adam Ford

Quoted 13 lines · Geert Uytterhoeven

Quoted 12 lines · Adam Ford

When the board was added, clock drivers were being updated done at the same time to allow the versaclock driver to properly configure the modes. Unforutnately, the updates were not applied to the board

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -0

@@ -5,6 +5,7 @@
 
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/input/input.h>
+#include <dt-bindings/clk/versaclock.h>
 

Quoted 12 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &du_out_rgb { · line 298

Quoted 8 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -1

 / {
        backlight_lvds: backlight-lvds {

@@ -294,12 +295,12 @@ &du_out_rgb {
 &ehci0 {
        dr_mode = "otg";
        status = "okay";
-       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;
+       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&versaclock5 3>;

Why this change? You said before you don't need this
https://lore.kernel.org/linux-renesas-soc/CAHCN7xJWbP16SA-Ok-5syNnqOZAt8OFJo2_rtg5VrNVsN2-eiQ@mail.gmail.com/

Quoted 8 lines

I had talked with the hardware guys about buy pre-programmed versaclock chips which would have been pre-configured and pre-enabled. I thought it was going to happen, but it didn't, so we need the versaclock driver to enable the reference clock for the USB controllers, ethernet controller and audio clocks. Previously we were manually configuring it or it was coincidentally working. Ideally, we'd have the clock system intentionally enable/disable the clocks when drivers are loaded/unloaded for for power management reasons.

Quoted 1 line

Can you tell me how exactly the Versaclock outputs are wired?

The SoC is expecting a fixed external 50 MHz clock connected to USB_EXTAL. Instead of a fixed clock, we're using the Versaclock. We're also using the Versaclock to drive the AVB TXCRefClk, du_dotclkiun0 and du_dotclkin2 (also also called du_dotclkin3 on RZ/G2N) instead of fixed clocks.

Quoted 7 lines

Quoted 2 lines

E.g. for USB, the bindings don't say anything about a third clock input, so I'd like to know where that clock is fed into USB.

The way the driver is crafted, it can take in multiple clocks and it goes through a list to enable them all, so I added the versaclock to the array. Without the versaclock reference, the clock doesn't get turned on and the USB fails to operate.

According to the Hardware User's Manual, USBL_EXTAL is used for USB3.0, while you added the clock references to the EHCI nodes.
Are you sure EHCI is failing without this?

Still, it means we need to extend the bindings/driver for renesas,rcar-gen3-xhci to handle USB_EXTAL.

Quoted 3 lines

The DU clocks are also expecting an array, so I added the versaclock to that array as well.

For DU, the clock inputs are clearly defined in the bindings.

Quoted 7 lines

It's similar to the rationale that I'm trying to add the option clock for the AVB TXC_Ref clock on the other path. We're using the versaclock there as well. The difference is that in the case of the AVB_TXCRefClk, the driver isn't expecting an array of clocks, it's only expecting a single clock. In order to enable the additional clock, I started the patch to accept the optional clock for the TXCRefClk in order to get the clock system to enable the clock.

Sure.

Quoted 6 lines

Because the Versaclock isn't programmed to automatically start, they need the consumers of the clock to request and enable them.

I admit that I'll probably need to update the bindings to add the extra clocks as optional, so if you want, I can submit additional patches to add these optional clocks to their respective bindings.

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

Quoted 55 lines · Geert Uytterhoeven

Quoted 46 lines · Adam Ford

Quoted 37 lines · Geert Uytterhoeven

Quoted 27 lines · Adam Ford

Quoted 13 lines · Geert Uytterhoeven

Quoted 12 lines · Adam Ford

When the board was added, clock drivers were being updated done at the same time to allow the versaclock driver to properly configure the modes. Unforutnately, the updates were not applied to the board

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -0

@@ -5,6 +5,7 @@
 
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/input/input.h>
+#include <dt-bindings/clk/versaclock.h>
 

Quoted 12 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &du_out_rgb { · line 298

Quoted 8 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -1

 / {
        backlight_lvds: backlight-lvds {

@@ -294,12 +295,12 @@ &du_out_rgb {
 &ehci0 {
        dr_mode = "otg";
        status = "okay";
-       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;
+       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&versaclock5 3>;

Why this change? You said before you don't need this
https://lore.kernel.org/linux-renesas-soc/CAHCN7xJWbP16SA-Ok-5syNnqOZAt8OFJo2_rtg5VrNVsN2-eiQ@mail.gmail.com/

Quoted 8 lines

I had talked with the hardware guys about buy pre-programmed versaclock chips which would have been pre-configured and pre-enabled. I thought it was going to happen, but it didn't, so we need the versaclock driver to enable the reference clock for the USB controllers, ethernet controller and audio clocks. Previously we were manually configuring it or it was coincidentally working. Ideally, we'd have the clock system intentionally enable/disable the clocks when drivers are loaded/unloaded for for power management reasons.

Quoted 1 line

Can you tell me how exactly the Versaclock outputs are wired?

The SoC is expecting a fixed external 50 MHz clock connected to USB_EXTAL. Instead of a fixed clock, we're using the Versaclock. We're also using the Versaclock to drive the AVB TXCRefClk, du_dotclkiun0 and du_dotclkin2 (also also called du_dotclkin3 on RZ/G2N) instead of fixed clocks.

Quoted 7 lines

Quoted 2 lines

E.g. for USB, the bindings don't say anything about a third clock input, so I'd like to know where that clock is fed into USB.

The way the driver is crafted, it can take in multiple clocks and it goes through a list to enable them all, so I added the versaclock to the array. Without the versaclock reference, the clock doesn't get turned on and the USB fails to operate.

Quoted 6 lines

According to the Hardware User's Manual, USBL_EXTAL is used for USB3.0, while you added the clock references to the EHCI nodes.
Are you sure EHCI is failing without this?

Still, it means we need to extend the bindings/driver for renesas,rcar-gen3-xhci to handle USB_EXTAL.

After investigating this, it looks like the USB_EXTAL is already referenced from the device tree and it's referenced by the USB3 Phy. The SoC calls it usb_extal_clk. Since the phy driver is calling devm_clk_get() it looks like i could just redefine the clocks of usb3_phy0 to point to the versaclock instead of usb_extal_clk.

The other option is to use a similar method I proposed for the audio reference clock and redefine the usb_extal_clk as a fixed fixed-factor-clock.

Do you have a preference as to which direction I go?

Hi Adam,

Quoted 59 lines · Adam Ford

Quoted 58 lines · Geert Uytterhoeven

Quoted 46 lines · Adam Ford

Quoted 37 lines · Geert Uytterhoeven

Quoted 27 lines · Adam Ford

Quoted 13 lines · Geert Uytterhoeven

Quoted 12 lines · Adam Ford

When the board was added, clock drivers were being updated done at the same time to allow the versaclock driver to properly configure the modes. Unforutnately, the updates were not applied to the board

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -0

@@ -5,6 +5,7 @@
 
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/input/input.h>
+#include <dt-bindings/clk/versaclock.h>
 

Quoted 12 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &du_out_rgb { · line 298

Quoted 8 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -1

 / {
        backlight_lvds: backlight-lvds {

@@ -294,12 +295,12 @@ &du_out_rgb {
 &ehci0 {
        dr_mode = "otg";
        status = "okay";
-       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;
+       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&versaclock5 3>;

Why this change? You said before you don't need this
https://lore.kernel.org/linux-renesas-soc/CAHCN7xJWbP16SA-Ok-5syNnqOZAt8OFJo2_rtg5VrNVsN2-eiQ@mail.gmail.com/

Quoted 8 lines

I had talked with the hardware guys about buy pre-programmed versaclock chips which would have been pre-configured and pre-enabled. I thought it was going to happen, but it didn't, so we need the versaclock driver to enable the reference clock for the USB controllers, ethernet controller and audio clocks. Previously we were manually configuring it or it was coincidentally working. Ideally, we'd have the clock system intentionally enable/disable the clocks when drivers are loaded/unloaded for for power management reasons.

Quoted 1 line

Can you tell me how exactly the Versaclock outputs are wired?

The SoC is expecting a fixed external 50 MHz clock connected to USB_EXTAL. Instead of a fixed clock, we're using the Versaclock. We're also using the Versaclock to drive the AVB TXCRefClk, du_dotclkiun0 and du_dotclkin2 (also also called du_dotclkin3 on RZ/G2N) instead of fixed clocks.

Quoted 7 lines

Quoted 2 lines

E.g. for USB, the bindings don't say anything about a third clock input, so I'd like to know where that clock is fed into USB.

The way the driver is crafted, it can take in multiple clocks and it goes through a list to enable them all, so I added the versaclock to the array. Without the versaclock reference, the clock doesn't get turned on and the USB fails to operate.

According to the Hardware User's Manual, USBL_EXTAL is used for USB3.0, while you added the clock references to the EHCI nodes.
Are you sure EHCI is failing without this?

Quoted 9 lines

Quoted 2 lines

Still, it means we need to extend the bindings/driver for renesas,rcar-gen3-xhci to handle USB_EXTAL.

After investigating this, it looks like the USB_EXTAL is already referenced from the device tree and it's referenced by the USB3 Phy. The SoC calls it usb_extal_clk. Since the phy driver is calling devm_clk_get() it looks like i could just redefine the clocks of usb3_phy0 to point to the versaclock instead of usb_extal_clk.

Quoted 5 lines

The other option is to use a similar method I proposed for the audio reference clock and redefine the usb_extal_clk as a fixed fixed-factor-clock.

Do you have a preference as to which direction I go?

I'd go for the classical solution: override the clocks property of the usb3_phy0 node.

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

Quoted 52 lines · Geert Uytterhoeven

Quoted 51 lines · Adam Ford

Quoted 50 lines · Geert Uytterhoeven

Quoted 49 lines · Adam Ford

Quoted 37 lines · Geert Uytterhoeven

Quoted 27 lines · Adam Ford

Quoted 13 lines · Geert Uytterhoeven

Quoted 12 lines · Adam Ford

When the board was added, clock drivers were being updated done at the same time to allow the versaclock driver to properly configure the modes. Unforutnately, the updates were not applied to the board

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -0

@@ -5,6 +5,7 @@
 
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/input/input.h>
+#include <dt-bindings/clk/versaclock.h>
 

Quoted 12 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &du_out_rgb { · line 298

Quoted 8 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -1

 / {
        backlight_lvds: backlight-lvds {

@@ -294,12 +295,12 @@ &du_out_rgb {
 &ehci0 {
        dr_mode = "otg";
        status = "okay";
-       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;
+       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&versaclock5 3>;

Why this change? You said before you don't need this
https://lore.kernel.org/linux-renesas-soc/CAHCN7xJWbP16SA-Ok-5syNnqOZAt8OFJo2_rtg5VrNVsN2-eiQ@mail.gmail.com/

Quoted 8 lines

I had talked with the hardware guys about buy pre-programmed versaclock chips which would have been pre-configured and pre-enabled. I thought it was going to happen, but it didn't, so we need the versaclock driver to enable the reference clock for the USB controllers, ethernet controller and audio clocks. Previously we were manually configuring it or it was coincidentally working. Ideally, we'd have the clock system intentionally enable/disable the clocks when drivers are loaded/unloaded for for power management reasons.

Quoted 1 line

Can you tell me how exactly the Versaclock outputs are wired?

The SoC is expecting a fixed external 50 MHz clock connected to USB_EXTAL. Instead of a fixed clock, we're using the Versaclock. We're also using the Versaclock to drive the AVB TXCRefClk, du_dotclkiun0 and du_dotclkin2 (also also called du_dotclkin3 on RZ/G2N) instead of fixed clocks.

Quoted 2 lines

E.g. for USB, the bindings don't say anything about a third clock input, so I'd like to know where that clock is fed into USB.

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 4 lines

The way the driver is crafted, it can take in multiple clocks and it goes through a list to enable them all, so I added the versaclock to the array. Without the versaclock reference, the clock doesn't get turned on and the USB fails to operate.

According to the Hardware User's Manual, USBL_EXTAL is used for USB3.0, while you added the clock references to the EHCI nodes.
Are you sure EHCI is failing without this?

I talked to a colleague about the USB_EXTAL. He pointed me to table 60.1 of the RZ/2 Series, 2nd Generate reference manual (R01UH0808EJ0100 Rev.1.00), which shows the USB EHCI needing the 50MHz. When I clear out the references from ehci0 and echi1, the USB stops working, so it does appear that using the versaclock as the 3rd clock is needed for operating. The device tree bindings for the generic-ehci provide for up to 4 clocks, so it seems like referencing clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&versaclock5 3> are not a violation of the bindings.

Hi Adam,

Quoted 62 lines · Adam Ford

Quoted 52 lines · Geert Uytterhoeven

Quoted 51 lines · Adam Ford

Quoted 50 lines · Geert Uytterhoeven

Quoted 49 lines · Adam Ford

Quoted 37 lines · Geert Uytterhoeven

Quoted 27 lines · Adam Ford

Quoted 13 lines · Geert Uytterhoeven

Quoted 12 lines · Adam Ford

When the board was added, clock drivers were being updated done at the same time to allow the versaclock driver to properly configure the modes. Unforutnately, the updates were not applied to the board

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -0

@@ -5,6 +5,7 @@
 
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/input/input.h>
+#include <dt-bindings/clk/versaclock.h>
 

Quoted 12 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &du_out_rgb { · line 298

Quoted 8 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -1

 / {
        backlight_lvds: backlight-lvds {

@@ -294,12 +295,12 @@ &du_out_rgb {
 &ehci0 {
        dr_mode = "otg";
        status = "okay";
-       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;
+       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&versaclock5 3>;

Why this change? You said before you don't need this
https://lore.kernel.org/linux-renesas-soc/CAHCN7xJWbP16SA-Ok-5syNnqOZAt8OFJo2_rtg5VrNVsN2-eiQ@mail.gmail.com/

Quoted 8 lines

I had talked with the hardware guys about buy pre-programmed versaclock chips which would have been pre-configured and pre-enabled. I thought it was going to happen, but it didn't, so we need the versaclock driver to enable the reference clock for the USB controllers, ethernet controller and audio clocks. Previously we were manually configuring it or it was coincidentally working. Ideally, we'd have the clock system intentionally enable/disable the clocks when drivers are loaded/unloaded for for power management reasons.

Quoted 1 line

Can you tell me how exactly the Versaclock outputs are wired?

The SoC is expecting a fixed external 50 MHz clock connected to USB_EXTAL. Instead of a fixed clock, we're using the Versaclock. We're also using the Versaclock to drive the AVB TXCRefClk, du_dotclkiun0 and du_dotclkin2 (also also called du_dotclkin3 on RZ/G2N) instead of fixed clocks.

Quoted 2 lines

E.g. for USB, the bindings don't say anything about a third clock input, so I'd like to know where that clock is fed into USB.

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 4 lines

The way the driver is crafted, it can take in multiple clocks and it goes through a list to enable them all, so I added the versaclock to the array. Without the versaclock reference, the clock doesn't get turned on and the USB fails to operate.

According to the Hardware User's Manual, USBL_EXTAL is used for USB3.0, while you added the clock references to the EHCI nodes.
Are you sure EHCI is failing without this?

Quoted 9 lines

I talked to a colleague about the USB_EXTAL. He pointed me to table 60.1 of the RZ/2 Series, 2nd Generate reference manual (R01UH0808EJ0100 Rev.1.00), which shows the USB EHCI needing the 50MHz. When I clear out the references from ehci0 and echi1, the USB stops working, so it does appear that using the versaclock as the 3rd clock is needed for operating. The device tree bindings for the generic-ehci provide for up to 4 clocks, so it seems like referencing clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&versaclock5 3> are not a violation of the bindings.

Perhaps you need to use renesas,rcar-usb2-clock-sel? Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

Quoted 73 lines · Geert Uytterhoeven

Quoted 62 lines · Adam Ford

Quoted 52 lines · Geert Uytterhoeven

Quoted 51 lines · Adam Ford

Quoted 50 lines · Geert Uytterhoeven

Quoted 49 lines · Adam Ford

Quoted 37 lines · Geert Uytterhoeven

Quoted 27 lines · Adam Ford

Quoted 13 lines · Geert Uytterhoeven

Quoted 12 lines · Adam Ford

When the board was added, clock drivers were being updated done at the same time to allow the versaclock driver to properly configure the modes. Unforutnately, the updates were not applied to the board

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -0

@@ -5,6 +5,7 @@
 
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/input/input.h>
+#include <dt-bindings/clk/versaclock.h>
 

Quoted 12 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &du_out_rgb { · line 298

Quoted 8 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -1

 / {
        backlight_lvds: backlight-lvds {

@@ -294,12 +295,12 @@ &du_out_rgb {
 &ehci0 {
        dr_mode = "otg";
        status = "okay";
-       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;
+       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&versaclock5 3>;

Why this change? You said before you don't need this
https://lore.kernel.org/linux-renesas-soc/CAHCN7xJWbP16SA-Ok-5syNnqOZAt8OFJo2_rtg5VrNVsN2-eiQ@mail.gmail.com/

Quoted 8 lines

I had talked with the hardware guys about buy pre-programmed versaclock chips which would have been pre-configured and pre-enabled. I thought it was going to happen, but it didn't, so we need the versaclock driver to enable the reference clock for the USB controllers, ethernet controller and audio clocks. Previously we were manually configuring it or it was coincidentally working. Ideally, we'd have the clock system intentionally enable/disable the clocks when drivers are loaded/unloaded for for power management reasons.

Quoted 1 line

Can you tell me how exactly the Versaclock outputs are wired?

The SoC is expecting a fixed external 50 MHz clock connected to USB_EXTAL. Instead of a fixed clock, we're using the Versaclock. We're also using the Versaclock to drive the AVB TXCRefClk, du_dotclkiun0 and du_dotclkin2 (also also called du_dotclkin3 on RZ/G2N) instead of fixed clocks.

Quoted 2 lines

E.g. for USB, the bindings don't say anything about a third clock input, so I'd like to know where that clock is fed into USB.

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 4 lines

The way the driver is crafted, it can take in multiple clocks and it goes through a list to enable them all, so I added the versaclock to the array. Without the versaclock reference, the clock doesn't get turned on and the USB fails to operate.

According to the Hardware User's Manual, USBL_EXTAL is used for USB3.0, while you added the clock references to the EHCI nodes.
Are you sure EHCI is failing without this?

Quoted 9 lines

I talked to a colleague about the USB_EXTAL. He pointed me to table 60.1 of the RZ/2 Series, 2nd Generate reference manual (R01UH0808EJ0100 Rev.1.00), which shows the USB EHCI needing the 50MHz. When I clear out the references from ehci0 and echi1, the USB stops working, so it does appear that using the versaclock as the 3rd clock is needed for operating. The device tree bindings for the generic-ehci provide for up to 4 clocks, so it seems like referencing clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&versaclock5 3> are not a violation of the bindings.

Quoted 2 lines

Perhaps you need to use renesas,rcar-usb2-clock-sel? Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml

Thanks for the pointer. I didn't know this existed. It looks like the right thing to do. With that node, it appears to enable the versaclock and USB works.
I'll submit a V3 at some point with this node added to each of the kit-level files since they use slightly different power-domains.

Do I need to add updates to the bindings for renesas,r8a774a1-rcar-usb2-clock-sel; r8a774b1-rcar-usb2-clock-sel; and renesas,r8a774e1-rcar-usb2-clock-sel; or I can I just use the generic reference to renesas,rcar-gen3-usb2-clock-sel?

Hi Adam,

Quoted 62 lines · Adam Ford

Quoted 52 lines · Geert Uytterhoeven

Quoted 51 lines · Adam Ford

Quoted 50 lines · Geert Uytterhoeven

Quoted 49 lines · Adam Ford

Quoted 37 lines · Geert Uytterhoeven

Quoted 27 lines · Adam Ford

Quoted 13 lines · Geert Uytterhoeven

Quoted 12 lines · Adam Ford

When the board was added, clock drivers were being updated done at the same time to allow the versaclock driver to properly configure the modes. Unforutnately, the updates were not applied to the board

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -0

@@ -5,6 +5,7 @@
 
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/input/input.h>
+#include <dt-bindings/clk/versaclock.h>
 

Quoted 12 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &du_out_rgb { · line 298

Quoted 8 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -1

 / {
        backlight_lvds: backlight-lvds {

@@ -294,12 +295,12 @@ &du_out_rgb {
 &ehci0 {
        dr_mode = "otg";
        status = "okay";
-       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;
+       clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&versaclock5 3>;

Why this change? You said before you don't need this
https://lore.kernel.org/linux-renesas-soc/CAHCN7xJWbP16SA-Ok-5syNnqOZAt8OFJo2_rtg5VrNVsN2-eiQ@mail.gmail.com/

Quoted 8 lines

I had talked with the hardware guys about buy pre-programmed versaclock chips which would have been pre-configured and pre-enabled. I thought it was going to happen, but it didn't, so we need the versaclock driver to enable the reference clock for the USB controllers, ethernet controller and audio clocks. Previously we were manually configuring it or it was coincidentally working. Ideally, we'd have the clock system intentionally enable/disable the clocks when drivers are loaded/unloaded for for power management reasons.

Quoted 1 line

Can you tell me how exactly the Versaclock outputs are wired?

The SoC is expecting a fixed external 50 MHz clock connected to USB_EXTAL. Instead of a fixed clock, we're using the Versaclock. We're also using the Versaclock to drive the AVB TXCRefClk, du_dotclkiun0 and du_dotclkin2 (also also called du_dotclkin3 on RZ/G2N) instead of fixed clocks.

Quoted 2 lines

E.g. for USB, the bindings don't say anything about a third clock input, so I'd like to know where that clock is fed into USB.

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 4 lines

The way the driver is crafted, it can take in multiple clocks and it goes through a list to enable them all, so I added the versaclock to the array. Without the versaclock reference, the clock doesn't get turned on and the USB fails to operate.

According to the Hardware User's Manual, USBL_EXTAL is used for USB3.0, while you added the clock references to the EHCI nodes.
Are you sure EHCI is failing without this?

Quoted 9 lines

I talked to a colleague about the USB_EXTAL. He pointed me to table 60.1 of the RZ/2 Series, 2nd Generate reference manual (R01UH0808EJ0100 Rev.1.00), which shows the USB EHCI needing the 50MHz. When I clear out the references from ehci0 and echi1, the USB stops working, so it does appear that using the versaclock as the 3rd clock is needed for operating. The device tree bindings for the generic-ehci provide for up to 4 clocks, so it seems like referencing clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&versaclock5 3> are not a violation of the bindings.

Perhaps you need to use renesas,rcar-usb2-clock-sel? Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

The Bluetooth chip is capable of operating at 4Mbps, but the max-speed setting was on the UART node instead of the Bluetooth node, so the chip didn't operate at the correct speed resulting in choppy audio. Fix this by setting the max-speed in the proper node.

Fixes a1d8a344f1ca ("arm64: dts: renesas: Introduce r8a774a1-beacon-rzg2m-kit")

Signed-off-by Adam Ford <[email protected]>

Quoted 6 lines · Adam Ford

The Bluetooth chip is capable of operating at 4Mbps, but the max-speed setting was on the UART node instead of the Bluetooth node, so the chip didn't operate at the correct speed resulting in choppy audio. Fix this by setting the max-speed in the proper node.

Quoted 2 lines

Fixes a1d8a344f1ca ("arm64: dts: renesas: Introduce r8a774a1-beacon-rzg2m-kit")

Signed-off-by Adam Ford <[email protected]>

Reviewed-by Geert Uytterhoeven <[email protected]>

i.e. will queue in renesas-devel for v5.12.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

Quoted 7 lines · Geert Uytterhoeven

Quoted 6 lines · Adam Ford

The Bluetooth chip is capable of operating at 4Mbps, but the max-speed setting was on the UART node instead of the Bluetooth node, so the chip didn't operate at the correct speed resulting in choppy audio. Fix this by setting the max-speed in the proper node.

Quoted 5 lines

Quoted 2 lines

Fixes a1d8a344f1ca ("arm64: dts: renesas: Introduce r8a774a1-beacon-rzg2m-kit")

Signed-off-by Adam Ford <[email protected]>

Reviewed-by Geert Uytterhoeven <[email protected]>

i.e. will queue in renesas-devel for v5.12.

Since various other patches in the series need a V2, should this be included in the V2 as no-change, or should I skip this and others that have been queued? If/when they appear in your branch, I can rebase the series against that branch and just submit V2's on what's missing.

I want to do whatever creates less work for you.

VSPI0 and VSPB are already enabled by default. There is no need to add extra nodes to enable them. Remove the redundant nodes.

Signed-off-by Adam Ford <[email protected]>

The SoC was expecting two clock sources with different frequencies. One to support 44.1KHz and one to support 48KHz. With the newly added ability to configure the programmably clock, configure both clocks.

Beacause the SoC is expecting a fixed clock/oscillator, it doesn't attempt to get and enable the clock for audio_clk_a. The choice to use a fixed-factor-clock was due to the fact that it will automatically enable the programmable clock frequency without change any code.

Signed-off-by Adam Ford <[email protected]>

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +0 -0

@@ -250,9 +250,12 @@ ss_ep: endpoint {
 };
 
 &audio_clk_a {

Hi Adam,

Quoted 10 lines · Adam Ford

The SoC was expecting two clock sources with different frequencies. One to support 44.1KHz and one to support 48KHz. With the newly added ability to configure the programmably clock, configure both clocks.

Beacause the SoC is expecting a fixed clock/oscillator, it doesn't attempt to get and enable the clock for audio_clk_a. The choice to use a fixed-factor-clock was due to the fact that it will automatically enable the programmable clock frequency without change any code.

Signed-off-by Adam Ford <[email protected]>

Thanks for your patch!

Quoted 5 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +0 -0

@@ -250,9 +250,12 @@ ss_ep: endpoint {
 };
 

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi ss_ep: endpoint { · line 259

Quoted 11 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +6 -3

 &audio_clk_a {
-       clock-frequency = <24576000>;
-       assigned-clocks = <&versaclock6_bb 4>;
-       assigned-clock-rates = <24576000>;
+       /delete-property/ clock-frequency;
+       #clock-cells = <0>;
+       compatible = "fixed-factor-clock";
+       clock-mult = <1>;
+       clock-div = <1>;
+       clocks = <&versaclock6_bb 4>;
 };

Shouldn't you override the clocks property in the rcar_sound node instead, like is done in several other board DTS files (with cs2000)?

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi sound_pins: sound { · line 599

Quoted 10 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -1

 &audio_clk_b {

@@ -591,7 +594,7 @@ sound_pins: sound {
        };
 
        sound_clk_pins: sound_clk {
-               groups = "audio_clk_a_a";
+               groups = "audio_clk_a_a", "audio_clk_b_a";
                function = "audio_clk";
        };

Yes, this part was definitely missing.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

Quoted 19 lines · Geert Uytterhoeven

Quoted 10 lines · Adam Ford

The SoC was expecting two clock sources with different frequencies. One to support 44.1KHz and one to support 48KHz. With the newly added ability to configure the programmably clock, configure both clocks.

Beacause the SoC is expecting a fixed clock/oscillator, it doesn't attempt to get and enable the clock for audio_clk_a. The choice to use a fixed-factor-clock was due to the fact that it will automatically enable the programmable clock frequency without change any code.

Signed-off-by Adam Ford <[email protected]>

Thanks for your patch!

Quoted 5 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +0 -0

@@ -250,9 +250,12 @@ ss_ep: endpoint {
 };
 

Quoted 15 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi ss_ep: endpoint { · line 259

Quoted 11 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +6 -3

 &audio_clk_a {
-       clock-frequency = <24576000>;
-       assigned-clocks = <&versaclock6_bb 4>;
-       assigned-clock-rates = <24576000>;
+       /delete-property/ clock-frequency;
+       #clock-cells = <0>;
+       compatible = "fixed-factor-clock";
+       clock-mult = <1>;
+       clock-div = <1>;
+       clocks = <&versaclock6_bb 4>;
 };

Shouldn't you override the clocks property in the rcar_sound node instead, like is done in several other board DTS files (with cs2000)?

I guess there are multiple ways to do this. Because the rcar_sound was already expecting a reference to audio_clk_a, it seemed less intrusive this way. The way I proposed, we can use the default rcar_sound clocking and just change the audio_clk node to enable the versaclock output. The versaclock is driving the audio_clk_a reference clock, so it seemed appropriate to put it there.

If you want me to change, I will.

The fact the audio worked at all was a coindicence because the wrong

gpio enable was used. Use the correct GPIO pin to ensure its operation.

Fixes a1d8a344f1ca ("arm64: dts: renesas: Introduce r8a774a1-beacon-rzg2m-kit")

Signed-off-by Adam Ford <[email protected]>

With the newly added configurable clock options, the audio CODEC can configure the mclk automatically. Add the reference to the versaclock. Since the devices on I2C5 can communicate at 400KHz, let's also increase that too

Signed-off-by Adam Ford <[email protected]>

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +0 -0

@@ -424,13 +424,15 @@ &i2c0 {
 
 &i2c5 {
        status = "okay";

Hi Adam,

CC alsa-devel

Quoted 6 lines · Adam Ford

With the newly added configurable clock options, the audio CODEC can configure the mclk automatically. Add the reference to the versaclock. Since the devices on I2C5 can communicate at 400KHz, let's also increase that too

Signed-off-by Adam Ford <[email protected]>

Thanks for your patch!

Quoted 11 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -1

@@ -424,13 +424,15 @@ &i2c0 {
 
 &i2c5 {
        status = "okay";
-       clock-frequency = <100000>;
+       clock-frequency = <400000>;
        pinctrl-0 = <&i2c5_pins>;
        pinctrl-names = "default";
 

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &i2c0 { · line 435

Quoted 5 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +2 -0

        codec: wm8962@1a {
                compatible = "wlf,wm8962";
                reg = <0x1a>;
+               clocks = <&versaclock6_bb 3>;
+               clock-names = "mclk";

While the driver does get the (nameless) clock, the DT bindings lack any mention of a clocks property. It would be good to update the bindings.

Note that arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi and arch/arm64/boot/dts/freescale/imx8mm-beacon-baseboard.dtsi (both by your hand) use "xclk" instead of "mclk"?

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &i2c0 { · line 438

Quoted 4 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +0 -0

                DCVDD-supply = <&reg_audio>;
                DBVDD-supply = <&reg_audio>;
                AVDD-supply = <&reg_audio>;

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

Quoted 26 lines · Geert Uytterhoeven

Hi Adam,

CC alsa-devel

Quoted 6 lines · Adam Ford

With the newly added configurable clock options, the audio CODEC can configure the mclk automatically. Add the reference to the versaclock. Since the devices on I2C5 can communicate at 400KHz, let's also increase that too

Signed-off-by Adam Ford <[email protected]>

Thanks for your patch!

Quoted 11 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -1

@@ -424,13 +424,15 @@ &i2c0 {
 
 &i2c5 {
        status = "okay";
-       clock-frequency = <100000>;
+       clock-frequency = <400000>;
        pinctrl-0 = <&i2c5_pins>;
        pinctrl-names = "default";
 

Quoted 8 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &i2c0 { · line 435

Quoted 5 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +2 -0

        codec: wm8962@1a {
                compatible = "wlf,wm8962";
                reg = <0x1a>;
+               clocks = <&versaclock6_bb 3>;
+               clock-names = "mclk";

While the driver does get the (nameless) clock, the DT bindings lack any mention of a clocks property. It would be good to update the bindings.

Agreed. I'll push an update to add the clocks property.

Quoted 4 lines

Note that arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi and arch/arm64/boot/dts/freescale/imx8mm-beacon-baseboard.dtsi (both by your hand) use "xclk" instead of "mclk"?

On the schematics for the two imx boards, it's labeled as xclk, so it was named as such. For this board, the schematic names it mclk. The driver doesn't care about the clock-names property, so I'll just remove them.

adam

Quoted 15 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &i2c0 { · line 438

Quoted 4 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +0 -0

                DCVDD-supply = <&reg_audio>;
                DBVDD-supply = <&reg_audio>;
                AVDD-supply = <&reg_audio>;

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

Quoted 23 lines · Geert Uytterhoeven

CC alsa-devel

Quoted 6 lines · Adam Ford

With the newly added configurable clock options, the audio CODEC can configure the mclk automatically. Add the reference to the versaclock. Since the devices on I2C5 can communicate at 400KHz, let's also increase that too

Signed-off-by Adam Ford <[email protected]>

Thanks for your patch!

Quoted 11 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -1

@@ -424,13 +424,15 @@ &i2c0 {
 
 &i2c5 {
        status = "okay";
-       clock-frequency = <100000>;
+       clock-frequency = <400000>;
        pinctrl-0 = <&i2c5_pins>;
        pinctrl-names = "default";
 

Quoted 8 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &i2c0 { · line 435

Quoted 5 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +2 -0

        codec: wm8962@1a {
                compatible = "wlf,wm8962";
                reg = <0x1a>;
+               clocks = <&versaclock6_bb 3>;
+               clock-names = "mclk";

While the driver does get the (nameless) clock, the DT bindings lack any mention of a clocks property. It would be good to update the bindings.

Agreed. I'll push an update to add the clocks property.

Quoted 3 lines

Note that arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi and arch/arm64/boot/dts/freescale/imx8mm-beacon-baseboard.dtsi (both by your hand) use "xclk" instead of "mclk"?

On the schematics for the two imx boards, it's labeled as xclk, so it was named as such. For this board, the schematic names it mclk. The driver doesn't care about the clock-names property, so I'll just remove them.

Hi Adam,

Quoted 33 lines · Adam Ford

Quoted 23 lines · Geert Uytterhoeven

CC alsa-devel

Quoted 6 lines · Adam Ford

With the newly added configurable clock options, the audio CODEC can configure the mclk automatically. Add the reference to the versaclock. Since the devices on I2C5 can communicate at 400KHz, let's also increase that too

Signed-off-by Adam Ford <[email protected]>

Thanks for your patch!

Quoted 11 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +1 -1

@@ -424,13 +424,15 @@ &i2c0 {
 
 &i2c5 {
        status = "okay";
-       clock-frequency = <100000>;
+       clock-frequency = <400000>;
        pinctrl-0 = <&i2c5_pins>;
        pinctrl-names = "default";
 

Quoted 8 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi &i2c0 { · line 435

Quoted 5 lines

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +2 -0

        codec: wm8962@1a {
                compatible = "wlf,wm8962";
                reg = <0x1a>;
+               clocks = <&versaclock6_bb 3>;
+               clock-names = "mclk";

While the driver does get the (nameless) clock, the DT bindings lack any mention of a clocks property. It would be good to update the bindings.

Quoted 1 line

Agreed. I'll push an update to add the clocks property.

Thanks!

Quoted 4 lines

Quoted 3 lines

Note that arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi and arch/arm64/boot/dts/freescale/imx8mm-beacon-baseboard.dtsi (both by your hand) use "xclk" instead of "mclk"?

Quoted 4 lines

On the schematics for the two imx boards, it's labeled as xclk, so it was named as such. For this board, the schematic names it mclk. The driver doesn't care about the clock-names property, so I'll just remove them.

If there's a single clock, not using clock-names is fine. If you do use clock-names, the names should be clock-centric, not board-centric.

BTW, looking at the WM8962 datasheet, it's called "MCLK".

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

The backlight didn't really work correctly due to some updates that were made in hardware. It should be safe to apply these, because the older hardware was never shipped to anyone, so it shouldn't break anything.

Signed-off-by Adam Ford <[email protected]>

The baseboard supports SCIF4, enable the pins and the node for it.

Signed-off-by Adam Ford <[email protected]>

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +5 -0

@@ -578,6 +578,11 @@ pwm2_pins: pwm2 {
                function = "pwm2";
        };
 
+       scif4_pins: scif4 {
+               groups = "scif4_data_c";
+               function = "scif4";
+       };
+
        sdhi0_pins: sd0 {
                groups = "sdhi0_data4", "sdhi0_ctrl";
                function = "sdhi0";

@@ -706,6 +711,12 @@ &scif0 {
        status = "okay";
 };

The backlight didn't really work correctly due to some updates that were made in hardware. It should be safe to apply these, because the older hardware was never shipped to anyone, so it shouldn't break anything. Because the display driver refers to the display as DPI, this also renames the backlight to use DPI for consistency.

Signed-off-by Adam Ford <[email protected]>

vccq_sdhi0 is referenced from sdhi0, so there is no need to force this regualtor to be always-on. In theory it could help with

low power modes in the future.

Signed-off-by Adam Ford <[email protected]>

The keys on the baseboard are laid out in an diamond pattern, up, down, left, right and center. Update the descriptions to make it easier to read.

Signed-off-by Adam Ford <[email protected]>

arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi +8 -8

@@ -40,38 +40,38 @@ hdmi0_con: endpoint {
        keys {
                compatible = "gpio-keys";
 
-               key-1 {
+               key-1 { /* S19 */
                        gpios = <&gpio4 6 GPIO_ACTIVE_LOW>;
                        linux,code = <KEY_1>;
-                       label = "Switch-1";
+                       label = "Up";
                        wakeup-source;
                        debounce-interval = <20>;
                };
-               key-2 {
+               key-2 { /*S20 */
                        gpios = <&gpio3 13 GPIO_ACTIVE_LOW>;
                        linux,code = <KEY_2>;
-                       label = "Switch-2";
+                       label = "Left";
                        wakeup-source;
                        debounce-interval = <20>;
                };
-               key-3 {
+               key-3 { /* S21 */
                        gpios = <&gpio5 17 GPIO_ACTIVE_LOW>;
                        linux,code = <KEY_3>;
-                       label = "Switch-3";
+                       label = "Down";
                        wakeup-source;
                        debounce-interval = <20>;
                };
-               key-4 {
+               key-4 { /* S22 */
                        gpios = <&gpio5 20 GPIO_ACTIVE_LOW>;
                        linux,code = <KEY_4>;
-                       label = "Switch-4";
+                       label = "Right";
                        wakeup-source;
                        debounce-interval = <20>;

The baseboard routes the SPI to a header which can/will be configured at either the kit level or using device tree overlays. Because the baseboard be supporting more than one kit, enable at the baseboard level rather than a bunch of duplicates later.

Signed-off-by Adam Ford <[email protected]>

For greater compatibility with upcoming kits that will reuse the baseboard and SOM-level files, adjust the I2C speeds to make it the most compatible with all devices.

Signed-off-by Adam Ford <[email protected]>

In preparation for adding new dev kits, move anything specific to the RZ/G2M from the SOM-level and baseboard-levels and move them to the kit-level. This allows the SOM and baseboard to be reused with other SoC's.

Signed-off-by Adam Ford <[email protected]>

Quoted 6 lines · Adam Ford

In preparation for adding new dev kits, move anything specific to the RZ/G2M from the SOM-level and baseboard-levels and move them to the kit-level. This allows the SOM and baseboard to be reused with other SoC's.

Signed-off-by Adam Ford <[email protected]>

Reviewed-by Geert Uytterhoeven <[email protected]>

i.e. will queue in renesas-devel for v5.12.

Add beacon,beacon-rzg2n and beacon,beacon-rzg2h to the bindings list.

Signed-off-by Adam Ford <[email protected]>

---
 Documentation/devicetree/bindings/arm/renesas.yaml | 2 ++
 1 file changed, 2 insertions(+)

Add beacon,beacon-rzg2n and beacon,beacon-rzg2h to the bindings list.

Signed-off-by Adam Ford <[email protected]>

Beacon EmebeddedWorks is introducing a new kit based on the RZ/G2N SoC from Renesas.

The SOM supports eMMC, WiFi and Bluetooth, along with a Cat-M1 cellular radio.

The Baseboard has Ethernet, USB, HDMI, stereo audio in and out, along with a variety of push buttons and LED's, and support for a parallel RGB and an LVDS display. It uses the same baseboard and SOM as the RZ/G2M.

Signed-off-by Adam Ford <[email protected]>

arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts new file +19 -0

@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020, Compass Electronics Group, LLC
+ */
+
+/dts-v1/;
+
+#include "r8a774b1.dtsi"
+#include "beacon-renesom-som.dtsi"
+#include "beacon-renesom-baseboard.dtsi"
+
+/ {
+       model = "Beacon Embedded Works RZ/G2N Development Kit";
+       compatible =    "beacon,beacon-rzg2n", "renesas,r8a774b1";
+
+       aliases {
+               serial0 = &scif2;
+               serial1 = &hscif0;
+               serial2 = &hscif1;

Hi Adam,

Quoted 6 lines · Adam Ford

Beacon EmebeddedWorks is introducing a new kit based on the RZ/G2N SoC from Renesas.

The SOM supports eMMC, WiFi and Bluetooth, along with a Cat-M1 cellular radio.

Quoted 6 lines

The Baseboard has Ethernet, USB, HDMI, stereo audio in and out, along with a variety of push buttons and LED's, and support for a parallel RGB and an LVDS display. It uses the same baseboard and SOM as the RZ/G2M.

Signed-off-by Adam Ford <[email protected]>

Thanks for your patch!

Quoted 28 lines

arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts new file +24 -0

@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020, Compass Electronics Group, LLC
+ */
+
+/dts-v1/;
+
+#include "r8a774b1.dtsi"
+#include "beacon-renesom-som.dtsi"
+#include "beacon-renesom-baseboard.dtsi"
+
+/ {
+       model = "Beacon Embedded Works RZ/G2N Development Kit";
+       compatible =    "beacon,beacon-rzg2n", "renesas,r8a774b1";
+
+       aliases {
+               serial0 = &scif2;
+               serial1 = &hscif0;
+               serial2 = &hscif1;
+               serial3 = &scif0;
+               serial4 = &hscif2;
+               serial5 = &scif5;
+               serial6 = &scif4;
+               ethernet0 = &avb;

arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts line 29

Quoted 5 lines

arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts new file +5 -0

+       };
+
+       chosen {
+               stdout-path = "serial0:115200n8";
+       };

No memory nodes? Are you relying on U-Boot to fill them in? If yes, why do you have them in the other board DTS files?

arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts line 33

Quoted 5 lines

arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts new file +4 -0

+};
+
+&du {
+       status = "okay";

Missing pinctrl properties?

arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts line 43

Quoted 10 lines

arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts new file +10 -0

+
+       clocks = <&cpg CPG_MOD 724>,
+               <&cpg CPG_MOD 723>,
+               <&cpg CPG_MOD 721>,
+               <&versaclock5 1>,
+               <&x302_clk>,
+               <&versaclock5 2>;
+       clock-names = "du.0", "du.1", "du.3",
+               "dclkin.0", "dclkin.1", "dclkin.3";
+};

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

Subject: Re: [PATCH 17/18] arm64: dts: renesas: Introduce r8a774b1-beacon- rzg2n-kit

Quoted 10 lines · Geert Uytterhoeven

Hi Adam,

Quoted 6 lines · Adam Ford

Beacon EmebeddedWorks is introducing a new kit based on the RZ/G2N SoC from Renesas.

The SOM supports eMMC, WiFi and Bluetooth, along with a Cat-M1 cellular radio.

Quoted 8 lines

Quoted 6 lines

The Baseboard has Ethernet, USB, HDMI, stereo audio in and out, along with a variety of push buttons and LED's, and support for a parallel RGB and an LVDS display. It uses the same baseboard and SOM as the RZ/G2M.

Signed-off-by Adam Ford <[email protected]>

Thanks for your patch!

Thank you for the review!

Quoted 27 lines

Quoted 27 lines

arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts new file +23 -0

@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020, Compass Electronics Group, LLC  */
+
+/dts-v1/;
+
+#include "r8a774b1.dtsi"
+#include "beacon-renesom-som.dtsi"
+#include "beacon-renesom-baseboard.dtsi"
+
+/ {
+       model = "Beacon Embedded Works RZ/G2N Development Kit";
+       compatible =    "beacon,beacon-rzg2n", "renesas,r8a774b1";
+
+       aliases {
+               serial0 = &scif2;
+               serial1 = &hscif0;
+               serial2 = &hscif1;
+               serial3 = &scif0;
+               serial4 = &hscif2;
+               serial5 = &scif5;
+               serial6 = &scif4;
+               ethernet0 = &avb;

Quoted 8 lines

arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts line 29

Quoted 5 lines

arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts new file +5 -0

+       };
+
+       chosen {
+               stdout-path = "serial0:115200n8";
+       };

No memory nodes? Are you relying on U-Boot to fill them in? If yes, why do you have them in the other board DTS files?

There is already a memory node included in the beacon-renesom.dtsi file which is defining memory@48000000 node which is common to the M,
N and H. If I understand it correctly, the extra memory nodes
defined in the higher-level dts for M and H variation are not applicable on the N.

Beacon EmebeddedWorks is introducing a new kit based on the

RZ/G2H SoC from Renesas.

The SOM supports eMMC, WiFi and Bluetooth, along with a Cat-M1 cellular radio.

The Baseboard has Ethernet, USB, HDMI, stereo audio in and out, along with a variety of push buttons and LED's, and support for a parallel RGB and an LVDS display. It uses the same baseboard and SOM files as the RZ/G2M and RZ/G2N kits.

Signed-off-by Adam Ford <[email protected]>