[PATCH 0/2] arm: dts: Legacy board IRQ issues

[PATCH 0/2] arm: dts: Legacy board IRQ issues

[Magnus Damm]

arm: dts: Legacy board IRQ issues

[PATCH 1/2] arm: dts: r8a7778 Bock-W Ethernet has busted IRQs
[PATCH 2/2] arm: dts: sh73a0 KZM9 as unhandled IRQs on boot

These patches highlight two IRQ-related issues on the 32-bit ARM
legacy boards. I've managed to reproduce the issues but not solve
them. I'd be happy to see someone else fixing these if possible.

Not-Yet-Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
---

 Developed on top of renesas-drivers-2018-03-13-v4.16-rc5
 
 arch/arm/boot/dts/r8a7778-bockw.dts       |   12 ++++++++----
 arch/arm/boot/dts/r8a7778.dtsi            |    8 ++++----
 drivers/irqchip/irq-renesas-intc-irqpin.c |    4 ++--
 3 files changed, 14 insertions(+), 10 deletions(-)

[PATCH 1/2] arm: dts: r8a7778 Bock-W Ethernet has busted IRQs

[Magnus Damm]

From: Magnus Damm <damm+renesas@opensource.se>

The on-board ethernet on r8a7778 Bock-W does not work out of the
box. Booting with initramfs and trying to do ifconfig up/down will
show that something is busted.

Judging by the board schematics the IRQ signal from the LAN89218
chip gets routed to some magic board-specific FPGA and if the stars
happen to be aligned this signal may also reach the r8a7778 SoC.

This temporary hack tries to use the on-chip GPIO device in r8a7778 for
interrupts however on r8a7778 all the GPIO devices share the same interrupt
line in the GIC but I wonder if this really has been tested. I recall
writing the GPIO driver on r8a7779 and r8a73a4 and then extending to
R-Car Gen2 and Gen3. Not sure if it will work on r8a7778 or not.

Most likely the PFC needs to be configured to configure the IRQ0 signal
to use the irqpin driver, or the GPIO device may be used in a similar
fashion as this patch.

Unfortunately more effort is needed to track this down. A perhaps related
issue on Bock-W is that it sometimes hangs on boot without output on
the serial console. Yum.

Not for upstream merge.

Not-Yet-Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
---

 Built on top of renesas-drivers-2018-03-13-v4.16-rc5

 arch/arm/boot/dts/r8a7778-bockw.dts |   12 ++++++++----
 arch/arm/boot/dts/r8a7778.dtsi      |    8 ++++----
 2 files changed, 12 insertions(+), 8 deletions(-)

--- 0001/arch/arm/boot/dts/r8a7778-bockw.dts
+++ work/arch/arm/boot/dts/r8a7778-bockw.dts	2018-03-20 13:56:14.270607110 +0900
@@ -66,13 +66,15 @@
 
 &bsc {
 	ethernet@18300000 {
-		compatible = "smsc,lan9220", "smsc,lan9115";
+		compatible = "smsc,lan89218", "smsc,lan9115";
 		reg = <0x18300000 0x1000>;
 
-		phy-mode = "mii";
-		interrupt-parent = <&irqpin>;
-		interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
 		reg-io-width = <4>;
+		smsc,force-internal-phy;
+		smsc,irq-active-high;
+		smsc,irq-push-pull;
 		vddvario-supply = <&fixedregulator3v3>;
 		vdd33a-supply = <&fixedregulator3v3>;
 	};
@@ -185,6 +187,7 @@
 	#sound-dai-cells = <0>;
 };
 
+#if 0
 &sdhi0 {
 	pinctrl-0 = <&sdhi0_pins>, <&sdhi0_pup_pins>;
 	pinctrl-names = "default";
@@ -194,6 +197,7 @@
 	status = "okay";
 	wp-gpios = <&gpio3 18 GPIO_ACTIVE_HIGH>;
 };
+#endif
 
 &hspi0 {
 	pinctrl-0 = <&hspi0_pins>;
--- 0001/arch/arm/boot/dts/r8a7778.dtsi
+++ work/arch/arm/boot/dts/r8a7778.dtsi	2018-03-20 14:01:03.260607110 +0900
@@ -88,7 +88,7 @@
 				GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		sense-bitfield-width = <2>;
 	};
-
+#if 0
 	gpio0: gpio@ffc40000 {
 		compatible = "renesas,gpio-r8a7778", "renesas,rcar-gen1-gpio";
 		reg = <0xffc40000 0x2c>;
@@ -99,7 +99,7 @@
 		#interrupt-cells = <2>;
 		interrupt-controller;
 	};
-
+#endif
 	gpio1: gpio@ffc41000 {
 		compatible = "renesas,gpio-r8a7778", "renesas,rcar-gen1-gpio";
 		reg = <0xffc41000 0x2c>;
@@ -110,7 +110,7 @@
 		#interrupt-cells = <2>;
 		interrupt-controller;
 	};
-
+#if 0
 	gpio2: gpio@ffc42000 {
 		compatible = "renesas,gpio-r8a7778", "renesas,rcar-gen1-gpio";
 		reg = <0xffc42000 0x2c>;
@@ -143,7 +143,7 @@
 		#interrupt-cells = <2>;
 		interrupt-controller;
 	};
-
+#endif
 	pfc: pin-controller@fffc0000 {
 		compatible = "renesas,pfc-r8a7778";
 		reg = <0xfffc0000 0x118>;

[PATCH 2/2] arm: dts: sh73a0 KZM9 as unhandled IRQs on boot

[Magnus Damm]

From: Magnus Damm <damm+renesas@opensource.se>

Booting sh73a0 KZM9G results in the following on the console:

[    0.030000] renesas_intc_irqpin e6900000.interrupt-controller: driving 8 irqs
[    0.040000] random: crng init done
[    0.120000] irq 35: nobody cared (try booting with the "irqpoll" option)
[    0.120000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.16.0-rc5 #4
[    0.120000] Hardware name: Generic SH73A0 (Flattened Device Tree)
...
[    0.120000] Disabling IRQ #35
[    0.120000] renesas_intc_irqpin e6900004.interrupt-controller: driving 8 irqs

Judging by the friendly board documentation there is nothing hooked up to
that IRQ line. I wish we had proper schematics and not a less detailed
board manual.

With this patch I've tried to extend the irqpin driver to mask all interrupts
on boot but it does not seem to help. Perhaps the PFC hardware needs to be
configured somehow. More effort is needed to solve this issue.

Not for upstream merge.

Not-Yet-Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
---

 Developed on top of renesas-drivers-2018-03-13-v4.16-rc5
 
 drivers/irqchip/irq-renesas-intc-irqpin.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- 0001/drivers/irqchip/irq-renesas-intc-irqpin.c
+++ work/drivers/irqchip/irq-renesas-intc-irqpin.c	2018-03-20 14:31:02.420607110 +0900
@@ -558,11 +558,11 @@ static int intc_irqpin_probe(struct plat
 			}
 		}
 	}
-
+#if 0
 	/* unmask all interrupts on prio level */
 	for (k = 0; k < nirqs; k++)
 		intc_irqpin_mask_unmask_prio(p, k, 0);
-
+#endif
 	dev_info(dev, "driving %d irqs\n", nirqs);
 
 	return 0;

Re: [PATCH 1/2] arm: dts: r8a7778 Bock-W Ethernet has busted IRQs

[Geert Uytterhoeven]

Hi Magnus, Uli,

On Tue, Mar 20, 2018 at 9:20 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
>
> The on-board ethernet on r8a7778 Bock-W does not work out of the
> box. Booting with initramfs and trying to do ifconfig up/down will
> show that something is busted.
>
> Judging by the board schematics the IRQ signal from the LAN89218
> chip gets routed to some magic board-specific FPGA and if the stars
> happen to be aligned this signal may also reach the r8a7778 SoC.
>
> This temporary hack tries to use the on-chip GPIO device in r8a7778 for
> interrupts however on r8a7778 all the GPIO devices share the same interrupt
> line in the GIC but I wonder if this really has been tested. I recall
> writing the GPIO driver on r8a7779 and r8a73a4 and then extending to
> R-Car Gen2 and Gen3. Not sure if it will work on r8a7778 or not.
>
> Most likely the PFC needs to be configured to configure the IRQ0 signal
> to use the irqpin driver, or the GPIO device may be used in a similar
> fashion as this patch.
>
> Unfortunately more effort is needed to track this down. A perhaps related
> issue on Bock-W is that it sometimes hangs on boot without output on
> the serial console. Yum.
>
> Not for upstream merge.
>
> Not-Yet-Signed-off-by: Magnus Damm <damm+renesas@opensource.se>

Is this the issue "[PATCH v3 0/5] r8a7778/bockw: fix SMSC Ethernet for MP"
(https://marc.info/?l=linux-sh&m=144172695421685&w=2) was meant to fix?

  irqchip: renesas-intc-irqpin: r8a7778 IRLM setup support
  ARM: shmobile: r8a7778: enable IRLM setup via DT
  ARM: shmobile: bockw dts: enable SMSC interrupt
  ARM: shmobile_defconfig: enable PINCTRL_SINGLE
  ARM: multi_v7_defconfig: enable PINCTRL_SINGLE

Seems like only the first patch in that series ever made it upstream.

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/2] arm: dts: sh73a0 KZM9 as unhandled IRQs on boot

[Geert Uytterhoeven]

Hi Magnus,

On Tue, Mar 20, 2018 at 9:20 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
>
> Booting sh73a0 KZM9G results in the following on the console:
>
> [    0.030000] renesas_intc_irqpin e6900000.interrupt-controller: driving 8 irqs
> [    0.040000] random: crng init done
> [    0.120000] irq 35: nobody cared (try booting with the "irqpoll" option)
> [    0.120000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.16.0-rc5 #4
> [    0.120000] Hardware name: Generic SH73A0 (Flattened Device Tree)
> ...
> [    0.120000] Disabling IRQ #35
> [    0.120000] renesas_intc_irqpin e6900004.interrupt-controller: driving 8 irqs

Thanks for bringing this to my attention again. I always assumed it was one of
the IIO devices keeping an IRQ line asserted, but it turns out I was wrong...

> Judging by the friendly board documentation there is nothing hooked up to
> that IRQ line. I wish we had proper schematics and not a less detailed
> board manual.

Oh there is: PORT54/IRQ10/FSICCK is driven by the same 11.2896 MHz
oscillator (OSC4) as FSIACK.

> With this patch I've tried to extend the irqpin driver to mask all interrupts
> on boot but it does not seem to help. Perhaps the PFC hardware needs to be
> configured somehow. More effort is needed to solve this issue.

That pin is part of the HDMI interface, cfr. section 5.27.

I've tried the below, but it doesn't work, as the interrupt controller is probed
before the pfc (it has to, due to dependencies from pfc on irqpin[0-3]).

--- a/arch/arm/boot/dts/sh73a0-kzm9g.dts
+++ b/arch/arm/boot/dts/sh73a0-kzm9g.dts
@@ -331,6 +331,15 @@
 };

 &pfc {
+       pinctrl-0 = <&fsic_pins>;
+       pinctrl-names = "default";
+
+       fsic_pins: hdmi {
+               /* FSICCK is driven by OSC4, causing interrupt storm */
+               groups = "fsic_mclk_in";
+               function = "fsic";
+       };
+
        i2c3_pins: i2c3 {
                groups = "i2c3_1";
                function = "i2c3";

So probably we need some early quirk in pfc-sh73a0.c, to configure the
pin as fsicck on kzm9g.

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/2] arm: dts: sh73a0 KZM9 as unhandled IRQs on boot

[Geert Uytterhoeven]

Hi Magnus,

On Wed, Mar 21, 2018 at 11:34 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Tue, Mar 20, 2018 at 9:20 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
>> From: Magnus Damm <damm+renesas@opensource.se>
>>
>> Booting sh73a0 KZM9G results in the following on the console:
>>
>> [    0.030000] renesas_intc_irqpin e6900000.interrupt-controller: driving 8 irqs
>> [    0.040000] random: crng init done
>> [    0.120000] irq 35: nobody cared (try booting with the "irqpoll" option)
>> [    0.120000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.16.0-rc5 #4
>> [    0.120000] Hardware name: Generic SH73A0 (Flattened Device Tree)
>> ...
>> [    0.120000] Disabling IRQ #35
>> [    0.120000] renesas_intc_irqpin e6900004.interrupt-controller: driving 8 irqs
>
> Thanks for bringing this to my attention again. I always assumed it was one of
> the IIO devices keeping an IRQ line asserted, but it turns out I was wrong...
>
>> Judging by the friendly board documentation there is nothing hooked up to
>> that IRQ line. I wish we had proper schematics and not a less detailed
>> board manual.
>
> Oh there is: PORT54/IRQ10/FSICCK is driven by the same 11.2896 MHz
> oscillator (OSC4) as FSIACK.
>
>> With this patch I've tried to extend the irqpin driver to mask all interrupts
>> on boot but it does not seem to help. Perhaps the PFC hardware needs to be
>> configured somehow. More effort is needed to solve this issue.
>
> That pin is part of the HDMI interface, cfr. section 5.27.
>
> I've tried the below, but it doesn't work, as the interrupt controller is probed
> before the pfc (it has to, due to dependencies from pfc on irqpin[0-3]).
>
> --- a/arch/arm/boot/dts/sh73a0-kzm9g.dts
> +++ b/arch/arm/boot/dts/sh73a0-kzm9g.dts
> @@ -331,6 +331,15 @@
>  };
>
>  &pfc {
> +       pinctrl-0 = <&fsic_pins>;
> +       pinctrl-names = "default";
> +
> +       fsic_pins: hdmi {
> +               /* FSICCK is driven by OSC4, causing interrupt storm */
> +               groups = "fsic_mclk_in";
> +               function = "fsic";
> +       };
> +
>         i2c3_pins: i2c3 {
>                 groups = "i2c3_1";
>                 function = "i2c3";
>
> So probably we need some early quirk in pfc-sh73a0.c, to configure the
> pin as fsicck on kzm9g.

That's done by switching PORT54 from FN0 to FN6, i.e. changing 0xe6051036
from 0xa0 to 0xa6.

I did that from U-Boot, and verified it's still that way when the PFC driver
initializes, but it doesn't help, with or without your patch.

So it seems more likely the intc-irqpin driver is not disabling interrupts that
are not requested?

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/2] arm: dts: sh73a0 KZM9 as unhandled IRQs on boot

[Magnus Damm]

Hi Geert,

On Thu, Mar 22, 2018 at 6:55 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Magnus,
>
> On Wed, Mar 21, 2018 at 11:34 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Tue, Mar 20, 2018 at 9:20 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
>>> From: Magnus Damm <damm+renesas@opensource.se>
>>>
>>> Booting sh73a0 KZM9G results in the following on the console:
>>>
>>> [    0.030000] renesas_intc_irqpin e6900000.interrupt-controller: driving 8 irqs
>>> [    0.040000] random: crng init done
>>> [    0.120000] irq 35: nobody cared (try booting with the "irqpoll" option)
>>> [    0.120000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.16.0-rc5 #4
>>> [    0.120000] Hardware name: Generic SH73A0 (Flattened Device Tree)
>>> ...
>>> [    0.120000] Disabling IRQ #35
>>> [    0.120000] renesas_intc_irqpin e6900004.interrupt-controller: driving 8 irqs
>>
>> Thanks for bringing this to my attention again. I always assumed it was one of
>> the IIO devices keeping an IRQ line asserted, but it turns out I was wrong...
>>
>>> Judging by the friendly board documentation there is nothing hooked up to
>>> that IRQ line. I wish we had proper schematics and not a less detailed
>>> board manual.
>>
>> Oh there is: PORT54/IRQ10/FSICCK is driven by the same 11.2896 MHz
>> oscillator (OSC4) as FSIACK.
>>
>>> With this patch I've tried to extend the irqpin driver to mask all interrupts
>>> on boot but it does not seem to help. Perhaps the PFC hardware needs to be
>>> configured somehow. More effort is needed to solve this issue.
>>
>> That pin is part of the HDMI interface, cfr. section 5.27.
>>
>> I've tried the below, but it doesn't work, as the interrupt controller is probed
>> before the pfc (it has to, due to dependencies from pfc on irqpin[0-3]).
>>
>> --- a/arch/arm/boot/dts/sh73a0-kzm9g.dts
>> +++ b/arch/arm/boot/dts/sh73a0-kzm9g.dts
>> @@ -331,6 +331,15 @@
>>  };
>>
>>  &pfc {
>> +       pinctrl-0 = <&fsic_pins>;
>> +       pinctrl-names = "default";
>> +
>> +       fsic_pins: hdmi {
>> +               /* FSICCK is driven by OSC4, causing interrupt storm */
>> +               groups = "fsic_mclk_in";
>> +               function = "fsic";
>> +       };
>> +
>>         i2c3_pins: i2c3 {
>>                 groups = "i2c3_1";
>>                 function = "i2c3";
>>
>> So probably we need some early quirk in pfc-sh73a0.c, to configure the
>> pin as fsicck on kzm9g.
>
> That's done by switching PORT54 from FN0 to FN6, i.e. changing 0xe6051036
> from 0xa0 to 0xa6.
>
> I did that from U-Boot, and verified it's still that way when the PFC driver
> initializes, but it doesn't help, with or without your patch.
>
> So it seems more likely the intc-irqpin driver is not disabling interrupts that
> are not requested?

Thanks for checking. Yeah the interrupt disabling poriton in the
driver might not work as expected. Also there is that "control-parent"
workaround in the driver as well, and perhaps combined with that the
PFC is not working as expected might result in spurious interrupts -
not sure.

I wonder if we still get interrupts if we configure the pin as GPIO?

Thanks,

/ magnus

Re: [PATCH 2/2] arm: dts: sh73a0 KZM9 as unhandled IRQs on boot

[Geert Uytterhoeven]

Hi Magnus,

On Fri, Mar 23, 2018 at 5:54 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> On Thu, Mar 22, 2018 at 6:55 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Wed, Mar 21, 2018 at 11:34 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Tue, Mar 20, 2018 at 9:20 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
>>>> From: Magnus Damm <damm+renesas@opensource.se>
>>>>
>>>> Booting sh73a0 KZM9G results in the following on the console:
>>>>
>>>> [    0.030000] renesas_intc_irqpin e6900000.interrupt-controller: driving 8 irqs
>>>> [    0.040000] random: crng init done
>>>> [    0.120000] irq 35: nobody cared (try booting with the "irqpoll" option)
>>>> [    0.120000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.16.0-rc5 #4
>>>> [    0.120000] Hardware name: Generic SH73A0 (Flattened Device Tree)
>>>> ...
>>>> [    0.120000] Disabling IRQ #35
>>>> [    0.120000] renesas_intc_irqpin e6900004.interrupt-controller: driving 8 irqs
>>>
>>> Thanks for bringing this to my attention again. I always assumed it was one of
>>> the IIO devices keeping an IRQ line asserted, but it turns out I was wrong...
>>>
>>>> Judging by the friendly board documentation there is nothing hooked up to
>>>> that IRQ line. I wish we had proper schematics and not a less detailed
>>>> board manual.
>>>
>>> Oh there is: PORT54/IRQ10/FSICCK is driven by the same 11.2896 MHz
>>> oscillator (OSC4) as FSIACK.
>>>
>>>> With this patch I've tried to extend the irqpin driver to mask all interrupts
>>>> on boot but it does not seem to help. Perhaps the PFC hardware needs to be
>>>> configured somehow. More effort is needed to solve this issue.
>>>
>>> That pin is part of the HDMI interface, cfr. section 5.27.
>>>
>>> I've tried the below, but it doesn't work, as the interrupt controller is probed
>>> before the pfc (it has to, due to dependencies from pfc on irqpin[0-3]).

>>> So probably we need some early quirk in pfc-sh73a0.c, to configure the
>>> pin as fsicck on kzm9g.
>>
>> That's done by switching PORT54 from FN0 to FN6, i.e. changing 0xe6051036
>> from 0xa0 to 0xa6.
>>
>> I did that from U-Boot, and verified it's still that way when the PFC driver
>> initializes, but it doesn't help, with or without your patch.
>>
>> So it seems more likely the intc-irqpin driver is not disabling interrupts that
>> are not requested?
>
> Thanks for checking. Yeah the interrupt disabling poriton in the
> driver might not work as expected. Also there is that "control-parent"
> workaround in the driver as well, and perhaps combined with that the
> PFC is not working as expected might result in spurious interrupts -
> not sure.

At least the actual disabling ("Disabling IRQ #35") seems to work.

> I wonder if we still get interrupts if we configure the pin as GPIO?

Thanks or the suggesion! I will try, eventually...

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