All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Stefan Wahren <stefan.wahren@i2se.com>,
	Maxime Ripard <maxime@cerno.tech>
Cc: Phil Elwell <phil@raspberrypi.com>,
	Dave Stevenson <dave.stevenson@raspberrypi.com>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>,
	Nicolas Saenz Julienne <nsaenz@kernel.org>
Subject: Re: [BUG] bcm2711: bad_chained_irq in brcmstb_l2_intc_irq_handle
Date: Thu, 20 Jan 2022 11:48:30 -0800	[thread overview]
Message-ID: <409091e8-abec-ce90-a247-246167223d92@gmail.com> (raw)
In-Reply-To: <84253e32-8dbf-dc2e-f44f-4555b8888f8c@i2se.com>



On 1/20/2022 10:10 AM, Stefan Wahren wrote:
> Hi Maxime,
> 
> Am 20.01.22 um 16:39 schrieb Maxime Ripard:
>> Hi Stefan,
>>
>> On Sun, Jan 16, 2022 at 06:26:58PM +0100, Stefan Wahren wrote:
>>> recently i saw a report [1] about bad chained IRQ with Linux 5.15.13
>>> Aarch64 with Arch Linux. I'm able to reproduce this issue on my
>>> Raspberry Pi 4 B (8 GB RAM, Firmware: 2022-01-06T15:39:30) by turning
>>> the connected HDMI monitor off and on again.
>> By turning the monitor on and off, you mean that you used the power
>> button on it?
> yes, correct
>>   Not something like disabling the output in sysfs, right?
>>
>>> Kernel output is the following:
>>>
>>> [15053.285438] irq 10, desc: 00000000acc41fca, depth: 0, count: 0,
>>> unhandled: 0
>>> [15053.295440] ->handle_irq():  00000000b28cf1d1,
>>> brcmstb_l2_intc_irq_handle+0x0/0x1e0
>>> [15053.306049] ->irq_data.chip(): 000000005f172760, gic_data+0x0/0x768
>>> [15053.315233] ->action(): 00000000236e815e
>>> [15053.322022] ->action->handler(): 0000000013023289,
>>> bad_chained_irq+0x0/0x50
>>> [15053.331909]      IRQ_LEVEL set
>>> [15053.337822]    IRQ_NOPROBE set
>>> [15053.343715]  IRQ_NOREQUEST set
>>> [15053.349585]   IRQ_NOTHREAD set
>> IRQ10 is the interrupt that a monitor has been connected on HDMI1, which
>> makes sense if you were using HDMI1.
> 
> The irq number in this output is always 10 regardless of the used HDMI
> connector (0 or 1). So maybe it's the hardware interrupt? Also in the
> interrupts list there is a interrupt with number 10 in the first column,
> which has the name (null) and it's count is identical to the occured
> warnings.

10 is the virtual interrupt number of the interrupt descriptor 
allocated, the hardware interrupt is 128 (32 for the SPI offset and 96 
for the actual number within the SPI).

> 
> [    0.000000] irq_brcmstb_l2: registered L2 intc
> (/soc/interrupt-controller@7ef00100, parent irq: 10)
> 
>>   Usually, when a display is turned
>> on, it will issue a pulse on the HPD line so we would have a
>> disconnection interrupt followed by a connection interrupt.
>>
>> This is weird though, since we have an interrupt handler on that
>> interrupt (hpd-connected in the DT binding):
>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/vc4/vc4_hdmi.c#L1578
> 
> I played a little bit with turn on/off and it seems the connect
> interrupts get lost sometimes (see below). I mean the warning doesn't
> occur always, it happens most of the time.

The fact that you are losing interrupts makes sense because we have a 
level handler registered for HW interrupt 128 which "steals" the 
interrupt events from the L2 interrupt controller handler that would 
process them as edge, if used. The complains from the kernel is because 
on one hand the interrupt descriptor wants a certain set of properties 
(level triggered in particular), but the flow that is installed by 
irq-brcmstb-l2 is of edge type, mayhem ensues.

> 
> reduced /proc/interrupts for HDMI 0 case:
> 
>   10:          5          0          0          0     GICv2 128 Level
> (null)
>   ...
> 
>   43:          1          0          0          0
> interrupt-controller@7ef00100   0 Edge      vc4 hdmi cec tx
>   44:          0          0          0          0
> interrupt-controller@7ef00100   1 Edge      vc4 hdmi cec rx
>   47:          4          0          0          0
> interrupt-controller@7ef00100   4 Edge      vc4 hdmi hpd connected
>   48:          7          0          0          0
> interrupt-controller@7ef00100   5 Edge      vc4 hdmi hpd disconnected
>   49:          0          0          0          0
> interrupt-controller@7ef00100   8 Edge      vc4 hdmi cec tx
>   50:          0          0          0          0
> interrupt-controller@7ef00100   7 Edge      vc4 hdmi cec rx
>   53:          0          0          0          0
> interrupt-controller@7ef00100  10 Edge      vc4 hdmi hpd connected
>   54:          0          0          0          0
> interrupt-controller@7ef00100  11 Edge      vc4 hdmi hpd disconnected
> 
> ...
> 
> Err:          5
> 
> /proc/interrupts for HDMI 1 case:
> 
>   10:          6          0          0          0     GICv2 128 Level
> (null)
> ...
>   43:          0          0          0          0
> interrupt-controller@7ef00100   0 Edge      vc4 hdmi cec tx
>   44:          0          0          0          0
> interrupt-controller@7ef00100   1 Edge      vc4 hdmi cec rx
>   47:          0          0          0          0
> interrupt-controller@7ef00100   4 Edge      vc4 hdmi hpd connected
>   48:          0          0          0          0
> interrupt-controller@7ef00100   5 Edge      vc4 hdmi hpd disconnected
>   49:          0          0          0          0
> interrupt-controller@7ef00100   8 Edge      vc4 hdmi cec tx
>   50:          0          0          0          0
> interrupt-controller@7ef00100   7 Edge      vc4 hdmi cec rx
>   53:          3          0          0          0
> interrupt-controller@7ef00100  10 Edge      vc4 hdmi hpd connected
>   54:          7          0          0          0
> interrupt-controller@7ef00100  11 Edge      vc4 hdmi hpd disconnected
> 
> ...
> 
> Err:          6
> 
> I could send a diff of the config against arm64/defconfig? Contrary to
> the Raspberry Pi OS, Arch Linux uses U-Boot not sure this is related.

Can we get the full dump of the Device Tree that you are running with? 
Something like:

dtc -I fs /proc/device-tree -O dts > live.dts

would be helpful to figure out what is going on here.
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-01-20 19:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-16 17:26 [BUG] bcm2711: bad_chained_irq in brcmstb_l2_intc_irq_handle Stefan Wahren
2022-01-16 20:15 ` Florian Fainelli
2022-01-17  4:59   ` Florian Fainelli
2022-01-20 15:54     ` Maxime Ripard
2022-01-20 15:39 ` Maxime Ripard
2022-01-20 18:10   ` Stefan Wahren
2022-01-20 19:48     ` Florian Fainelli [this message]
2022-01-20 21:23       ` Stefan Wahren
2022-01-20 21:38         ` Florian Fainelli
2022-01-21  3:51           ` Florian Fainelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=409091e8-abec-ce90-a247-246167223d92@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=dave.stevenson@raspberrypi.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maxime@cerno.tech \
    --cc=nsaenz@kernel.org \
    --cc=phil@raspberrypi.com \
    --cc=stefan.wahren@i2se.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.