[PATCH 1/4] arm64: dts: beacon-renesom: Fix gpio expander reference

[PATCH 1/4] arm64: dts: beacon-renesom: Fix gpio expander reference

[Adam Ford]

The board used to originally introduce the Beacon Embedded
RZ/G2[M/N/H] boards had a GPIO expander with address 20, but
this was change when the final board went to production.

The production boards changed both the part itself and
the address.  With the incorrect address, the LCD cannot
come up.  If the LCD fails, the rcar-du driver fails to come up,
and that also breaks HDMI.

Pre-release board were not shipped to the general public, so it
should be safe to push this as a fix.  Anyone with a production
board would have video fail due to this GPIO expander change.

Fixes: a1d8a344f1ca ("arm64: dts: renesas: Introduce r8a774a1-beacon-rzg2m-kit")
Signed-off-by: Adam Ford <aford173@gmail.com>

diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
index 8166e3c1ff4e..8b6fe235a8f0 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
@@ -437,20 +437,6 @@ wm8962_endpoint: endpoint {
 		};
 	};
 
-	/* 0 - lcd_reset */
-	/* 1 - lcd_pwr */
-	/* 2 - lcd_select */
-	/* 3 - backlight-enable */
-	/* 4 - Touch_shdwn */
-	/* 5 - LCD_H_pol */
-	/* 6 - lcd_V_pol */
-	gpio_exp1: gpio@20 {
-		compatible = "onnn,pca9654";
-		reg = <0x20>;
-		gpio-controller;
-		#gpio-cells = <2>;
-	};
-
 	touchscreen@26 {
 		compatible = "ilitek,ili2117";
 		reg = <0x26>;
@@ -482,6 +468,21 @@ hd3ss3220_out_ep: endpoint {
 			};
 		};
 	};
+
+	gpio_exp1: gpio@70 {
+		compatible = "onnn,pca9654";
+		reg = <0x70>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		gpio-line-names =
+			"lcd_reset",
+			"lcd_pwr",
+			"lcd_select",
+			"backlight-enable",
+			"Touch_shdwn",
+			"LCD_H_pol",
+			"lcd_V_pol";
+	};
 };
 
 &lvds0 {
-- 
2.34.1

[PATCH 2/4] Revert "arm64: dts: renesas: Add compatible properties to AR8031 Ethernet PHYs"

[Adam Ford]

This reverts commit 18a2427146bf8a3da8fc7825051d6aadb9c2d8fb.

Due to the part shortage, the AR8031 PHY was replaced with a
Micrel KSZ9131.  Hard-coding the ID of the PHY makes this new
PHY non-operational.  Since previous hardware had shipped,
it's not as simple as just replacing the ID number as it would
break the older hardware.  Since the generic mode can correctly
identify both versions of hardware, it seems safer to revert
this patch.

Signed-off-by: Adam Ford <aford173@gmail.com>

diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
index d3fc8ffd5b4c..1eb713530878 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
@@ -59,8 +59,6 @@ &avb {
 	status = "okay";
 
 	phy0: ethernet-phy@0 {
-		compatible = "ethernet-phy-id004d.d074",
-			     "ethernet-phy-ieee802.3-c22";
 		reg = <0>;
 		interrupt-parent = <&gpio2>;
 		interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
-- 
2.34.1

Re: [PATCH 2/4] Revert "arm64: dts: renesas: Add compatible properties to AR8031 Ethernet PHYs"

[Geert Uytterhoeven]

Hi Adam,

CC Ethernet phy

On Wed, Jan 4, 2023 at 3:12 PM Adam Ford <aford173@gmail.com> wrote:
> This reverts commit 18a2427146bf8a3da8fc7825051d6aadb9c2d8fb.
>
> Due to the part shortage, the AR8031 PHY was replaced with a
> Micrel KSZ9131.  Hard-coding the ID of the PHY makes this new
> PHY non-operational.  Since previous hardware had shipped,
> it's not as simple as just replacing the ID number as it would
> break the older hardware.  Since the generic mode can correctly
> identify both versions of hardware, it seems safer to revert
> this patch.
>
> Signed-off-by: Adam Ford <aford173@gmail.com>

Thanks for your patch!

> --- a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
> +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
> @@ -59,8 +59,6 @@ &avb {
>         status = "okay";
>
>         phy0: ethernet-phy@0 {
> -               compatible = "ethernet-phy-id004d.d074",
> -                            "ethernet-phy-ieee802.3-c22";
>                 reg = <0>;
>                 interrupt-parent = <&gpio2>;
>                 interrupts = <11 IRQ_TYPE_LEVEL_LOW>;

The next line:

                reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;

Unfortunately, removing the compatible value will cause regressions
for kexec/kdump and for Ethernet driver unbind, as the PHY reset will
be asserted before starting the new kernel, or on driver unbind.
Due to a deficiency in the Ethernet PHY subsystem, the PHY will be
probed while the reset is still asserted, and thus fail probing[1].

Is there a (new) proper way to handle this?
Perhaps the issue has been fixed in the PHY subsystem meanwhile?

Thanks!

[1] https://lore.kernel.org/all/cover.1631174218.git.geert+renesas@glider.be

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 2/4] Revert "arm64: dts: renesas: Add compatible properties to AR8031 Ethernet PHYs"

[Adam Ford]

On Fri, Jan 6, 2023 at 8:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Adam,
>
> CC Ethernet phy
>
> On Wed, Jan 4, 2023 at 3:12 PM Adam Ford <aford173@gmail.com> wrote:
> > This reverts commit 18a2427146bf8a3da8fc7825051d6aadb9c2d8fb.
> >
> > Due to the part shortage, the AR8031 PHY was replaced with a
> > Micrel KSZ9131.  Hard-coding the ID of the PHY makes this new
> > PHY non-operational.  Since previous hardware had shipped,
> > it's not as simple as just replacing the ID number as it would
> > break the older hardware.  Since the generic mode can correctly
> > identify both versions of hardware, it seems safer to revert
> > this patch.
> >
> > Signed-off-by: Adam Ford <aford173@gmail.com>
>
> Thanks for your patch!
>
> > --- a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
> > @@ -59,8 +59,6 @@ &avb {
> >         status = "okay";
> >
> >         phy0: ethernet-phy@0 {
> > -               compatible = "ethernet-phy-id004d.d074",
> > -                            "ethernet-phy-ieee802.3-c22";
> >                 reg = <0>;
> >                 interrupt-parent = <&gpio2>;
> >                 interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
>
> The next line:
>
>                 reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
>
> Unfortunately, removing the compatible value will cause regressions
> for kexec/kdump and for Ethernet driver unbind, as the PHY reset will
> be asserted before starting the new kernel, or on driver unbind.
> Due to a deficiency in the Ethernet PHY subsystem, the PHY will be
> probed while the reset is still asserted, and thus fail probing[1].

FWIW, the bootloader brings the device out of reset.  Would it be
sufficient to keep  "ethernet-phy-ieee802.3-c22" and drop the
hard-coded ID?

thanks,

adam
>
> Is there a (new) proper way to handle this?
> Perhaps the issue has been fixed in the PHY subsystem meanwhile?
>
> Thanks!
>
> [1] https://lore.kernel.org/all/cover.1631174218.git.geert+renesas@glider.be
>
> 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 2/4] Revert "arm64: dts: renesas: Add compatible properties to AR8031 Ethernet PHYs"

[Geert Uytterhoeven]

Hi Adam,

On Fri, Jan 6, 2023 at 3:35 PM Adam Ford <aford173@gmail.com> wrote:
> On Fri, Jan 6, 2023 at 8:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Wed, Jan 4, 2023 at 3:12 PM Adam Ford <aford173@gmail.com> wrote:
> > > This reverts commit 18a2427146bf8a3da8fc7825051d6aadb9c2d8fb.
> > >
> > > Due to the part shortage, the AR8031 PHY was replaced with a
> > > Micrel KSZ9131.  Hard-coding the ID of the PHY makes this new
> > > PHY non-operational.  Since previous hardware had shipped,
> > > it's not as simple as just replacing the ID number as it would
> > > break the older hardware.  Since the generic mode can correctly
> > > identify both versions of hardware, it seems safer to revert
> > > this patch.
> > >
> > > Signed-off-by: Adam Ford <aford173@gmail.com>
> >
> > Thanks for your patch!
> >
> > > --- a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
> > > @@ -59,8 +59,6 @@ &avb {
> > >         status = "okay";
> > >
> > >         phy0: ethernet-phy@0 {
> > > -               compatible = "ethernet-phy-id004d.d074",
> > > -                            "ethernet-phy-ieee802.3-c22";
> > >                 reg = <0>;
> > >                 interrupt-parent = <&gpio2>;
> > >                 interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
> >
> > The next line:
> >
> >                 reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
> >
> > Unfortunately, removing the compatible value will cause regressions
> > for kexec/kdump and for Ethernet driver unbind, as the PHY reset will
> > be asserted before starting the new kernel, or on driver unbind.
> > Due to a deficiency in the Ethernet PHY subsystem, the PHY will be
> > probed while the reset is still asserted, and thus fail probing[1].
>
> FWIW, the bootloader brings the device out of reset.  Would it be

The bootloader is not involved when using kexec/kdump, or when
unbinding the Ethernet driver.

> sufficient to keep  "ethernet-phy-ieee802.3-c22" and drop the
> hard-coded ID?

I am afraid not, as that still requires actual probing to determine
the PHY ID.

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 2/4] Revert "arm64: dts: renesas: Add compatible properties to AR8031 Ethernet PHYs"

[Adam Ford]

On Fri, Jan 6, 2023 at 8:45 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Adam,
>
> On Fri, Jan 6, 2023 at 3:35 PM Adam Ford <aford173@gmail.com> wrote:
> > On Fri, Jan 6, 2023 at 8:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Wed, Jan 4, 2023 at 3:12 PM Adam Ford <aford173@gmail.com> wrote:
> > > > This reverts commit 18a2427146bf8a3da8fc7825051d6aadb9c2d8fb.
> > > >
> > > > Due to the part shortage, the AR8031 PHY was replaced with a
> > > > Micrel KSZ9131.  Hard-coding the ID of the PHY makes this new
> > > > PHY non-operational.  Since previous hardware had shipped,
> > > > it's not as simple as just replacing the ID number as it would
> > > > break the older hardware.  Since the generic mode can correctly
> > > > identify both versions of hardware, it seems safer to revert
> > > > this patch.
> > > >
> > > > Signed-off-by: Adam Ford <aford173@gmail.com>
> > >
> > > Thanks for your patch!
> > >
> > > > --- a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
> > > > +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
> > > > @@ -59,8 +59,6 @@ &avb {
> > > >         status = "okay";
> > > >
> > > >         phy0: ethernet-phy@0 {
> > > > -               compatible = "ethernet-phy-id004d.d074",
> > > > -                            "ethernet-phy-ieee802.3-c22";
> > > >                 reg = <0>;
> > > >                 interrupt-parent = <&gpio2>;
> > > >                 interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
> > >
> > > The next line:
> > >
> > >                 reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
> > >
> > > Unfortunately, removing the compatible value will cause regressions
> > > for kexec/kdump and for Ethernet driver unbind, as the PHY reset will
> > > be asserted before starting the new kernel, or on driver unbind.
> > > Due to a deficiency in the Ethernet PHY subsystem, the PHY will be
> > > probed while the reset is still asserted, and thus fail probing[1].
> >
> > FWIW, the bootloader brings the device out of reset.  Would it be
>
> The bootloader is not involved when using kexec/kdump, or when
> unbinding the Ethernet driver.
>
> > sufficient to keep  "ethernet-phy-ieee802.3-c22" and drop the
> > hard-coded ID?
>
> I am afraid not, as that still requires actual probing to determine
> the PHY ID.

OK.  I'll try to find out how many of the older versions of the board
shipped. I don't really want to maintain two device trees for a small
population of boards.  Even those customers with early hardware won't
be getting the same versions going forward and Qualcomm/Atheros told
us it's an EOL part and cancelled our orders.  If there are no
objections, I might just change the ID to the new PHY.  The customers
who received the older hardware should have already been notified of
the hardware change and the fact they won't get any more with that
PHY.

adam
>
> 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

[PATCH 3/4] arm64: dts: renesas: r8a774[a/b/e]1-beacon: Update corporate name

[Adam Ford]

At the end of 2021, Beacon EmbeddedWorks was sold off from Compass.
Its legal name is now 'Logic PD, Inc. dba Beacon EmbeddedWorks" and
as far as I know Compass Electronics doesn't exist anymore.

Signed-off-by: Adam Ford <aford173@gmail.com>

diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
index 8b6fe235a8f0..b7741c10e778 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright 2020, Compass Electronics Group, LLC
+ * Copyright 2020, Logic PD, Inc. dba Beacon EmbeddedWorks
  */
 
 #include <dt-bindings/gpio/gpio.h>
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
index 1eb713530878..86a9d6381166 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright 2020, Compass Electronics Group, LLC
+ * Copyright 2020, Logic PD, Inc. dba Beacon EmbeddedWorks
  */
 
 #include <dt-bindings/gpio/gpio.h>
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts b/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
index 9ae67263c0df..7c0e3252ce65 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
+++ b/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright 2020, Compass Electronics Group, LLC
+ * Copyright 2020, Logic PD, Inc. dba Beacon EmbeddedWorks
  */
 
 /dts-v1/;
diff --git a/arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts b/arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts
index 89d708346ba8..f1fbd687d0f4 100644
--- a/arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts
+++ b/arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright 2020, Compass Electronics Group, LLC
+ * Copyright 2020, Logic PD, Inc. dba Beacon EmbeddedWorks
  */
 
 /dts-v1/;
diff --git a/arch/arm64/boot/dts/renesas/r8a774e1-beacon-rzg2h-kit.dts b/arch/arm64/boot/dts/renesas/r8a774e1-beacon-rzg2h-kit.dts
index 3e9ced3b2d33..7ee1a1bed212 100644
--- a/arch/arm64/boot/dts/renesas/r8a774e1-beacon-rzg2h-kit.dts
+++ b/arch/arm64/boot/dts/renesas/r8a774e1-beacon-rzg2h-kit.dts
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright 2020, Compass Electronics Group, LLC
+ * Copyright 2020, Logic PD, Inc. dba Beacon EmbeddedWorks
  */
 
 /dts-v1/;
-- 
2.34.1

Re: [PATCH 3/4] arm64: dts: renesas: r8a774[a/b/e]1-beacon: Update corporate name

[Geert Uytterhoeven]

Hi Adam,

CC GregKH

On Wed, Jan 4, 2023 at 3:12 PM Adam Ford <aford173@gmail.com> wrote:
> At the end of 2021, Beacon EmbeddedWorks was sold off from Compass.
> Its legal name is now 'Logic PD, Inc. dba Beacon EmbeddedWorks" and
> as far as I know Compass Electronics doesn't exist anymore.
>
> Signed-off-by: Adam Ford <aford173@gmail.com>

Thanks for your patch!

> --- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> @@ -1,6 +1,6 @@
>  // SPDX-License-Identifier: GPL-2.0
>  /*
> - * Copyright 2020, Compass Electronics Group, LLC
> + * Copyright 2020, Logic PD, Inc. dba Beacon EmbeddedWorks

IANAL, but I don't think this change is appropriate: the copyright date
is 2020, which is the year when the file was created, and the copyright
owner at that time was Compass.  The current copyright owner is the
current owner of the assets of Compass, which may change again in
the future.

I'm also not aware of people changing copyright headers for code owned
by now defunct companies, see the existence of code still copyrighted
by e.g. Motorola Inc., Digital Equipment Corporation, and Compaq
Computer Corporation.

If/when you make (substantial) changes to these files, you can add a
"Copyright 2023, Logic PD, Inc. dba Beacon EmbeddedWorks" line.

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 3/4] arm64: dts: renesas: r8a774[a/b/e]1-beacon: Update corporate name

[Adam Ford]

On Fri, Jan 6, 2023 at 8:14 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Adam,
>
> CC GregKH
>
> On Wed, Jan 4, 2023 at 3:12 PM Adam Ford <aford173@gmail.com> wrote:
> > At the end of 2021, Beacon EmbeddedWorks was sold off from Compass.
> > Its legal name is now 'Logic PD, Inc. dba Beacon EmbeddedWorks" and
> > as far as I know Compass Electronics doesn't exist anymore.
> >
> > Signed-off-by: Adam Ford <aford173@gmail.com>
>
> Thanks for your patch!
>
> > --- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > @@ -1,6 +1,6 @@
> >  // SPDX-License-Identifier: GPL-2.0
> >  /*
> > - * Copyright 2020, Compass Electronics Group, LLC
> > + * Copyright 2020, Logic PD, Inc. dba Beacon EmbeddedWorks
>
> IANAL, but I don't think this change is appropriate: the copyright date
> is 2020, which is the year when the file was created, and the copyright
> owner at that time was Compass.  The current copyright owner is the
> current owner of the assets of Compass, which may change again in
> the future.
>
> I'm also not aware of people changing copyright headers for code owned
> by now defunct companies, see the existence of code still copyrighted
> by e.g. Motorola Inc., Digital Equipment Corporation, and Compaq
> Computer Corporation.
>
> If/when you make (substantial) changes to these files, you can add a
> "Copyright 2023, Logic PD, Inc. dba Beacon EmbeddedWorks" line.

OK.   We can drop this patch from the series.

thanks,

adam
>
> 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

[PATCH 4/4] arm64: boot: dts: r8a774[a/b/e]1-beacon: Consolidate sound clocks

[Adam Ford]

Each kit-level file represents a SOM + baseboard for a specific
SoC type and uses specific clocks unique to each SoC.  With the
exception of one clock, the rest of the clock info was duplicated.

There is a generic clock called CPG_AUDIO_CLK_I defined in each of
the SoC DTSI files which points to this unique clock. By using that,
the clock information for the rcar_sound can be consolidated into
the baseboard file and have it reference this generic clock thus
removing the duplication from the three variants.

Signed-off-by: Adam Ford <aford173@gmail.com>

diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
index b7741c10e778..b31634c13d21 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
@@ -639,6 +639,25 @@ &rcar_sound {
 	#clock-cells = <1>;
 	clock-frequency = <11289600>;
 
+	/* Reference versaclock instead of audio_clk_a */
+	clocks = <&cpg CPG_MOD 1005>,
+		 <&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>,
+		 <&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>,
+		 <&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>,
+		 <&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>,
+		 <&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>,
+		 <&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>,
+		 <&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>,
+		 <&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
+		 <&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
+		 <&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
+		 <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+		 <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+		 <&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
+		 <&versaclock6_bb 4>, <&audio_clk_b>,
+		 <&audio_clk_c>,
+		 <&cpg CPG_CORE CPG_AUDIO_CLK_I>;
+
 	status = "okay";
 
 	ports {
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts b/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
index 7c0e3252ce65..e077079099c4 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
+++ b/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
@@ -58,24 +58,3 @@ &du {
 	clock-names = "du.0", "du.1", "du.2",
 		      "dclkin.0", "dclkin.1", "dclkin.2";
 };
-
-/* Reference versaclock instead of audio_clk_a */
-&rcar_sound {
-	clocks = <&cpg CPG_MOD 1005>,
-		 <&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>,
-		 <&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>,
-		 <&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>,
-		 <&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>,
-		 <&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>,
-		 <&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>,
-		 <&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>,
-		 <&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
-		 <&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
-		 <&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
-		 <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
-		 <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
-		 <&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
-		 <&versaclock6_bb 4>, <&audio_clk_b>,
-		 <&audio_clk_c>,
-		 <&cpg CPG_CORE R8A774A1_CLK_S0D4>;
-};
diff --git a/arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts b/arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts
index f1fbd687d0f4..df51c4c46c9a 100644
--- a/arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts
+++ b/arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts
@@ -46,24 +46,3 @@ &du {
 	clock-names = "du.0", "du.1", "du.3",
 		"dclkin.0", "dclkin.1", "dclkin.3";
 };
-
-/* Reference versaclock instead of audio_clk_a */
-&rcar_sound {
-	clocks = <&cpg CPG_MOD 1005>,
-		 <&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>,
-		 <&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>,
-		 <&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>,
-		 <&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>,
-		 <&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>,
-		 <&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>,
-		 <&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>,
-		 <&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
-		 <&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
-		 <&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
-		 <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
-		 <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
-		 <&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
-		 <&versaclock6_bb 4>, <&audio_clk_b>,
-		 <&audio_clk_c>,
-		 <&cpg CPG_CORE R8A774B1_CLK_S0D4>;
-};
diff --git a/arch/arm64/boot/dts/renesas/r8a774e1-beacon-rzg2h-kit.dts b/arch/arm64/boot/dts/renesas/r8a774e1-beacon-rzg2h-kit.dts
index 7ee1a1bed212..943671177991 100644
--- a/arch/arm64/boot/dts/renesas/r8a774e1-beacon-rzg2h-kit.dts
+++ b/arch/arm64/boot/dts/renesas/r8a774e1-beacon-rzg2h-kit.dts
@@ -51,24 +51,3 @@ &du {
 	clock-names = "du.0", "du.1", "du.3",
 		"dclkin.0", "dclkin.1", "dclkin.3";
 };
-
-/* Reference versaclock instead of audio_clk_a */
-&rcar_sound {
-	clocks = <&cpg CPG_MOD 1005>,
-		 <&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>,
-		 <&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>,
-		 <&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>,
-		 <&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>,
-		 <&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>,
-		 <&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>,
-		 <&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>,
-		 <&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
-		 <&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
-		 <&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
-		 <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
-		 <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
-		 <&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
-		 <&versaclock6_bb 4>, <&audio_clk_b>,
-		 <&audio_clk_c>,
-		 <&cpg CPG_CORE R8A774E1_CLK_S0D4>;
-};
-- 
2.34.1

Re: [PATCH 4/4] arm64: boot: dts: r8a774[a/b/e]1-beacon: Consolidate sound clocks

[Geert Uytterhoeven]

On Wed, Jan 4, 2023 at 3:18 PM Adam Ford <aford173@gmail.com> wrote:
> Each kit-level file represents a SOM + baseboard for a specific
> SoC type and uses specific clocks unique to each SoC.  With the
> exception of one clock, the rest of the clock info was duplicated.
>
> There is a generic clock called CPG_AUDIO_CLK_I defined in each of
> the SoC DTSI files which points to this unique clock. By using that,
> the clock information for the rcar_sound can be consolidated into
> the baseboard file and have it reference this generic clock thus
> removing the duplication from the three variants.
>
> Signed-off-by: Adam Ford <aford173@gmail.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.3.

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 1/4] arm64: dts: beacon-renesom: Fix gpio expander reference

[Adam Ford]

On Wed, Jan 4, 2023 at 8:12 AM Adam Ford <aford173@gmail.com> wrote:
>
> The board used to originally introduce the Beacon Embedded
> RZ/G2[M/N/H] boards had a GPIO expander with address 20, but
> this was change when the final board went to production.
>
> The production boards changed both the part itself and
> the address.  With the incorrect address, the LCD cannot
> come up.  If the LCD fails, the rcar-du driver fails to come up,
> and that also breaks HDMI.
>
> Pre-release board were not shipped to the general public, so it
> should be safe to push this as a fix.  Anyone with a production
> board would have video fail due to this GPIO expander change.
>
Geert,

Is this patch OK as-is? This is more critical to me than the other
patches in the series.

adam

> Fixes: a1d8a344f1ca ("arm64: dts: renesas: Introduce r8a774a1-beacon-rzg2m-kit")
> Signed-off-by: Adam Ford <aford173@gmail.com>
>
> diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> index 8166e3c1ff4e..8b6fe235a8f0 100644
> --- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> @@ -437,20 +437,6 @@ wm8962_endpoint: endpoint {
>                 };
>         };
>
> -       /* 0 - lcd_reset */
> -       /* 1 - lcd_pwr */
> -       /* 2 - lcd_select */
> -       /* 3 - backlight-enable */
> -       /* 4 - Touch_shdwn */
> -       /* 5 - LCD_H_pol */
> -       /* 6 - lcd_V_pol */
> -       gpio_exp1: gpio@20 {
> -               compatible = "onnn,pca9654";
> -               reg = <0x20>;
> -               gpio-controller;
> -               #gpio-cells = <2>;
> -       };
> -
>         touchscreen@26 {
>                 compatible = "ilitek,ili2117";
>                 reg = <0x26>;
> @@ -482,6 +468,21 @@ hd3ss3220_out_ep: endpoint {
>                         };
>                 };
>         };
> +
> +       gpio_exp1: gpio@70 {
> +               compatible = "onnn,pca9654";
> +               reg = <0x70>;
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               gpio-line-names =
> +                       "lcd_reset",
> +                       "lcd_pwr",
> +                       "lcd_select",
> +                       "backlight-enable",
> +                       "Touch_shdwn",
> +                       "LCD_H_pol",
> +                       "lcd_V_pol";
> +       };
>  };
>
>  &lvds0 {
> --
> 2.34.1
>

Re: [PATCH 1/4] arm64: dts: beacon-renesom: Fix gpio expander reference

[Geert Uytterhoeven]

Hi Adam,

On Wed, Jan 4, 2023 at 3:12 PM Adam Ford <aford173@gmail.com> wrote:
> The board used to originally introduce the Beacon Embedded
> RZ/G2[M/N/H] boards had a GPIO expander with address 20, but
> this was change when the final board went to production.
>
> The production boards changed both the part itself and
> the address.  With the incorrect address, the LCD cannot
> come up.  If the LCD fails, the rcar-du driver fails to come up,
> and that also breaks HDMI.
>
> Pre-release board were not shipped to the general public, so it
> should be safe to push this as a fix.  Anyone with a production
> board would have video fail due to this GPIO expander change.
>
> Fixes: a1d8a344f1ca ("arm64: dts: renesas: Introduce r8a774a1-beacon-rzg2m-kit")
> Signed-off-by: Adam Ford <aford173@gmail.com>

Thanks for your patch!

> --- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> @@ -437,20 +437,6 @@ wm8962_endpoint: endpoint {
>                 };
>         };
>
> -       /* 0 - lcd_reset */
> -       /* 1 - lcd_pwr */
> -       /* 2 - lcd_select */
> -       /* 3 - backlight-enable */
> -       /* 4 - Touch_shdwn */
> -       /* 5 - LCD_H_pol */
> -       /* 6 - lcd_V_pol */
> -       gpio_exp1: gpio@20 {
> -               compatible = "onnn,pca9654";
> -               reg = <0x20>;
> -               gpio-controller;
> -               #gpio-cells = <2>;
> -       };
> -
>         touchscreen@26 {
>                 compatible = "ilitek,ili2117";
>                 reg = <0x26>;
> @@ -482,6 +468,21 @@ hd3ss3220_out_ep: endpoint {
>                         };
>                 };
>         };
> +
> +       gpio_exp1: gpio@70 {
> +               compatible = "onnn,pca9654";

According to the patch description, the actual part was changed, too?

> +               reg = <0x70>;
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               gpio-line-names =
> +                       "lcd_reset",
> +                       "lcd_pwr",
> +                       "lcd_select",
> +                       "backlight-enable",
> +                       "Touch_shdwn",
> +                       "LCD_H_pol",
> +                       "lcd_V_pol";
> +       };
>  };

The rest LGTM.

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 1/4] arm64: dts: beacon-renesom: Fix gpio expander reference

[Adam Ford]

On Wed, Jan 11, 2023 at 10:29 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Hi Adam,
>
> On Wed, Jan 4, 2023 at 3:12 PM Adam Ford <aford173@gmail.com> wrote:
> > The board used to originally introduce the Beacon Embedded
> > RZ/G2[M/N/H] boards had a GPIO expander with address 20, but
> > this was change when the final board went to production.
> >
> > The production boards changed both the part itself and
> > the address.  With the incorrect address, the LCD cannot
> > come up.  If the LCD fails, the rcar-du driver fails to come up,
> > and that also breaks HDMI.
> >
> > Pre-release board were not shipped to the general public, so it
> > should be safe to push this as a fix.  Anyone with a production
> > board would have video fail due to this GPIO expander change.
> >
> > Fixes: a1d8a344f1ca ("arm64: dts: renesas: Introduce r8a774a1-beacon-rzg2m-kit")
> > Signed-off-by: Adam Ford <aford173@gmail.com>
>
> Thanks for your patch!
>
> > --- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > @@ -437,20 +437,6 @@ wm8962_endpoint: endpoint {
> >                 };
> >         };
> >
> > -       /* 0 - lcd_reset */
> > -       /* 1 - lcd_pwr */
> > -       /* 2 - lcd_select */
> > -       /* 3 - backlight-enable */
> > -       /* 4 - Touch_shdwn */
> > -       /* 5 - LCD_H_pol */
> > -       /* 6 - lcd_V_pol */
> > -       gpio_exp1: gpio@20 {
> > -               compatible = "onnn,pca9654";
> > -               reg = <0x20>;
> > -               gpio-controller;
> > -               #gpio-cells = <2>;
> > -       };
> > -
> >         touchscreen@26 {
> >                 compatible = "ilitek,ili2117";
> >                 reg = <0x26>;
> > @@ -482,6 +468,21 @@ hd3ss3220_out_ep: endpoint {
> >                         };
> >                 };
> >         };
> > +
> > +       gpio_exp1: gpio@70 {
> > +               compatible = "onnn,pca9654";
>
> According to the patch description, the actual part was changed, too?

humm.. I was under the impression it was after talking with one of the
hardware developers, but clearly it's using the same compatible name.
I will investigate this further.  One way or the other, I'll redo the
commit message.

adam
>
> > +               reg = <0x70>;
> > +               gpio-controller;
> > +               #gpio-cells = <2>;
> > +               gpio-line-names =
> > +                       "lcd_reset",
> > +                       "lcd_pwr",
> > +                       "lcd_select",
> > +                       "backlight-enable",
> > +                       "Touch_shdwn",
> > +                       "LCD_H_pol",
> > +                       "lcd_V_pol";
> > +       };
> >  };
>
> The rest LGTM.
>
> 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 1/4] arm64: dts: beacon-renesom: Fix gpio expander reference

[Adam Ford]

On Wed, Jan 11, 2023 at 11:05 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Wed, Jan 11, 2023 at 10:29 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> >
> > Hi Adam,
> >
> > On Wed, Jan 4, 2023 at 3:12 PM Adam Ford <aford173@gmail.com> wrote:
> > > The board used to originally introduce the Beacon Embedded
> > > RZ/G2[M/N/H] boards had a GPIO expander with address 20, but
> > > this was change when the final board went to production.
> > >
> > > The production boards changed both the part itself and
> > > the address.  With the incorrect address, the LCD cannot
> > > come up.  If the LCD fails, the rcar-du driver fails to come up,
> > > and that also breaks HDMI.
> > >
> > > Pre-release board were not shipped to the general public, so it
> > > should be safe to push this as a fix.  Anyone with a production
> > > board would have video fail due to this GPIO expander change.
> > >
> > > Fixes: a1d8a344f1ca ("arm64: dts: renesas: Introduce r8a774a1-beacon-rzg2m-kit")
> > > Signed-off-by: Adam Ford <aford173@gmail.com>
> >
> > Thanks for your patch!
> >
> > > --- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > @@ -437,20 +437,6 @@ wm8962_endpoint: endpoint {
> > >                 };
> > >         };
> > >
> > > -       /* 0 - lcd_reset */
> > > -       /* 1 - lcd_pwr */
> > > -       /* 2 - lcd_select */
> > > -       /* 3 - backlight-enable */
> > > -       /* 4 - Touch_shdwn */
> > > -       /* 5 - LCD_H_pol */
> > > -       /* 6 - lcd_V_pol */
> > > -       gpio_exp1: gpio@20 {
> > > -               compatible = "onnn,pca9654";
> > > -               reg = <0x20>;
> > > -               gpio-controller;
> > > -               #gpio-cells = <2>;
> > > -       };
> > > -
> > >         touchscreen@26 {
> > >                 compatible = "ilitek,ili2117";
> > >                 reg = <0x26>;
> > > @@ -482,6 +468,21 @@ hd3ss3220_out_ep: endpoint {
> > >                         };
> > >                 };
> > >         };
> > > +
> > > +       gpio_exp1: gpio@70 {
> > > +               compatible = "onnn,pca9654";
> >
> > According to the patch description, the actual part was changed, too?

After a bit of some investigation, the part was changed to
nxp,pca9538.  It appears to be the same driver and the same ".data"
structure is used.  This probably explains why I didn't see any issues
when I was testing this.  Unfortunately, the hardware engineer who
made this hardware change is not around to ask why the change was
made.    I'll do a V2 since, I don't see this in renesas-devel.

adam
>
> humm.. I was under the impression it was after talking with one of the
> hardware developers, but clearly it's using the same compatible name.
> I will investigate this further.  One way or the other, I'll redo the
> commit message.
>
> adam
> >
> > > +               reg = <0x70>;
> > > +               gpio-controller;
> > > +               #gpio-cells = <2>;
> > > +               gpio-line-names =
> > > +                       "lcd_reset",
> > > +                       "lcd_pwr",
> > > +                       "lcd_select",
> > > +                       "backlight-enable",
> > > +                       "Touch_shdwn",
> > > +                       "LCD_H_pol",
> > > +                       "lcd_V_pol";
> > > +       };
> > >  };
> >
> > The rest LGTM.
> >
> > 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 1/4] arm64: dts: beacon-renesom: Fix gpio expander reference

[Geert Uytterhoeven]

Hi Adam,

On Fri, Jan 13, 2023 at 2:17 PM Adam Ford <aford173@gmail.com> wrote:
> On Wed, Jan 11, 2023 at 11:05 AM Adam Ford <aford173@gmail.com> wrote:
> > On Wed, Jan 11, 2023 at 10:29 AM Geert Uytterhoeven
> > <geert@linux-m68k.org> wrote:
> > > On Wed, Jan 4, 2023 at 3:12 PM Adam Ford <aford173@gmail.com> wrote:
> > > > The board used to originally introduce the Beacon Embedded
> > > > RZ/G2[M/N/H] boards had a GPIO expander with address 20, but
> > > > this was change when the final board went to production.
> > > >
> > > > The production boards changed both the part itself and
> > > > the address.  With the incorrect address, the LCD cannot
> > > > come up.  If the LCD fails, the rcar-du driver fails to come up,
> > > > and that also breaks HDMI.
> > > >
> > > > Pre-release board were not shipped to the general public, so it
> > > > should be safe to push this as a fix.  Anyone with a production
> > > > board would have video fail due to this GPIO expander change.
> > > >
> > > > Fixes: a1d8a344f1ca ("arm64: dts: renesas: Introduce r8a774a1-beacon-rzg2m-kit")
> > > > Signed-off-by: Adam Ford <aford173@gmail.com>

> > > > --- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > > +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > > @@ -437,20 +437,6 @@ wm8962_endpoint: endpoint {
> > > >                 };
> > > >         };
> > > >
> > > > -       /* 0 - lcd_reset */
> > > > -       /* 1 - lcd_pwr */
> > > > -       /* 2 - lcd_select */
> > > > -       /* 3 - backlight-enable */
> > > > -       /* 4 - Touch_shdwn */
> > > > -       /* 5 - LCD_H_pol */
> > > > -       /* 6 - lcd_V_pol */
> > > > -       gpio_exp1: gpio@20 {
> > > > -               compatible = "onnn,pca9654";
> > > > -               reg = <0x20>;
> > > > -               gpio-controller;
> > > > -               #gpio-cells = <2>;
> > > > -       };
> > > > -
> > > >         touchscreen@26 {
> > > >                 compatible = "ilitek,ili2117";
> > > >                 reg = <0x26>;
> > > > @@ -482,6 +468,21 @@ hd3ss3220_out_ep: endpoint {
> > > >                         };
> > > >                 };
> > > >         };
> > > > +
> > > > +       gpio_exp1: gpio@70 {
> > > > +               compatible = "onnn,pca9654";
> > >
> > > According to the patch description, the actual part was changed, too?
>
> After a bit of some investigation, the part was changed to
> nxp,pca9538.  It appears to be the same driver and the same ".data"
> structure is used.  This probably explains why I didn't see any issues
> when I was testing this.  Unfortunately, the hardware engineer who
> made this hardware change is not around to ask why the change was
> made.

Yeah, there are lots of compatible parts.

> I'll do a V2 since, I don't see this in renesas-devel.

Correct, I was waiting for clarification.
Looking forward to v2...

Thanks!

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