Hi Magnus,
On Fri, Mar 23, 2018 at 5:54 AM, Magnus Damm <magnus.damm@xxxxxxxxx> wrote:
> On Thu, Mar 22, 2018 at 6:55 PM, Geert Uytterhoeven
> <geert@xxxxxxxxxxxxxx> wrote:
>> On Wed, Mar 21, 2018 at 11:34 AM, Geert Uytterhoeven
>> <geert@xxxxxxxxxxxxxx> wrote:
>>> On Tue, Mar 20, 2018 at 9:20 AM, Magnus Damm <magnus.damm@xxxxxxxxx> wrote:
>>>> From: Magnus Damm <damm+renesas@xxxxxxxxxxxxx>
>>>>
>>>> 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@xxxxxxxxxxxxxx
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
