public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: James Hogan <james.hogan@imgtec.com>
To: Ed Blake <ed.blake@sondrel.com>
Cc: <tglx@linutronix.de>, <jason@lakedaemon.net>,
	<marc.zyngier@arm.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/4] irqchip: imgpdc: Pass on peripheral mask/unmasks to the parent
Date: Thu, 5 Oct 2017 16:26:47 +0100	[thread overview]
Message-ID: <20171005152647.GL25320@jhogan-linux.le.imgtec.org> (raw)
In-Reply-To: <f37a8073-791e-2e87-a42e-51e1637b4f91@sondrel.com>

[-- Attachment #1: Type: text/plain, Size: 2433 bytes --]

On Thu, Oct 05, 2017 at 03:48:53PM +0100, Ed Blake wrote:
> On 04/10/17 15:03, James Hogan wrote:
> > Hi Ed,
> >
> > On Mon, Oct 02, 2017 at 10:55:59AM +0100, Ed Blake wrote:
> >> Pass on peripheral (RTC/IR/WD) irq masks and unmasks to the parent
> >> interrupt controller, as well as setting / clearing the relevant bits
> >> in the IRQ_ROUTE register.
> >>
> >> Clearing bits in the IRQ_ROUTE register will prevent future interrupts
> >> from being passed on to the parent, but won't mask an existing
> >> interrupt which has already made it to the parent.
> > Is it an edge or level sensitive interrupt from the PDC?
> 
> It's level triggered.
> 
> > I'm a little rusty on the IRQ subsystem TBH, but if edge sensitive I
> > would have expected the parent interrupt to be acked/cleared by the
> > parent handler.
> >
> > And if level sensitive I would have expected the deasserted parent
> > interrupt to be masked by the parent handler, and immediately cleared
> > upon rerouting.
> >
> > Maybe you can clarify whats going on here.
> 
> I'm not sure how this is supposed to work, but the issue seems to be
> that without this patch the parent irq isn't being masked.  This is
> causing the parent handler (MIPS GIC in this case) to be called
> continuously.  This leads to the PDC irq being masked each time, but not
> the parent irq.  This is the callstack:
> 
>     "irq-imgpdc.c"::perip_irq_mask
>     mask_ack_irq
>     handle_level_irq
>     generic_handle_irq_desc
>     generic_handle_irq
>     generic_handle_irq_desc
>     generic_handle_irq
>     gic_handle_shared_int
>     gic_handle_local_int
>     "irq-mips-gic.c"::gic_irq_dispatch
>     generic_handle_irq_desc
>     generic_handle_irq
>     do_IRQ
>     plat_irq_dispatch()

Right, yeh it shouldn't technically be masked by the parent (contrary to
what I said above) because its a chained handler, i.e. as far as the
kernel knows there could be other IRQs coming through that GIC pin that
would also get masked.

(though IIRC the perip IRQs can wake, but then they go straight out to
separate dedicated IRQ pins into the main IRQ chip, i.e. the GIC in this
case).

I think its worth understanding the root cause here though. Disabling
routing of an IRQ fundamentally should deassert it. Is it an actual
hardware bug that has reached silicon?

Cheers
James

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-10-05 15:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-02  9:55 [PATCH 0/4] irqchip: imgpdc: Fix various issues Ed Blake
2017-10-02  9:55 ` [PATCH 1/4] irqchip: imgpdc: Avoid unbalanced irq wake disable Ed Blake
2017-10-02  9:55 ` [PATCH 2/4] irqchip: imgpdc: Avoid immediate wake event during set_wake Ed Blake
2017-10-02  9:55 ` [PATCH 3/4] irqchip: imgpdc: Set sys wake polarities to active high Ed Blake
2017-10-04 13:14   ` James Hogan
2017-10-05 14:37     ` Ed Blake
2017-10-02  9:55 ` [PATCH 4/4] irqchip: imgpdc: Pass on peripheral mask/unmasks to the parent Ed Blake
2017-10-04 14:03   ` James Hogan
2017-10-05 14:48     ` Ed Blake
2017-10-05 15:26       ` James Hogan [this message]
2017-10-05 15:43         ` Ed Blake
2017-10-05 16:42           ` Ed Blake
2017-10-03 20:32 ` [PATCH 0/4] irqchip: imgpdc: Fix various issues Thomas Gleixner

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=20171005152647.GL25320@jhogan-linux.le.imgtec.org \
    --to=james.hogan@imgtec.com \
    --cc=ed.blake@sondrel.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox