From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751415AbdJEP0v (ORCPT ); Thu, 5 Oct 2017 11:26:51 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:38875 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751317AbdJEP0u (ORCPT ); Thu, 5 Oct 2017 11:26:50 -0400 Date: Thu, 5 Oct 2017 16:26:47 +0100 From: James Hogan To: Ed Blake CC: , , , Subject: Re: [PATCH 4/4] irqchip: imgpdc: Pass on peripheral mask/unmasks to the parent Message-ID: <20171005152647.GL25320@jhogan-linux.le.imgtec.org> References: <1506938159-466-1-git-send-email-ed.blake@sondrel.com> <1506938159-466-5-git-send-email-ed.blake@sondrel.com> <20171004140302.GG25320@jhogan-linux.le.imgtec.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FEz7ebHBGB6b2e8X" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-Originating-IP: [192.168.154.110] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --FEz7ebHBGB6b2e8X Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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? >=20 > It's level triggered. >=20 > > 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. >=20 > 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.=C2=A0 This is > causing the parent handler (MIPS GIC in this case) to be called > continuously.=C2=A0 This leads to the PDC irq being masked each time, but= not > the parent irq.=C2=A0 This is the callstack: >=20 > =C2=A0=C2=A0=C2=A0 "irq-imgpdc.c"::perip_irq_mask > =C2=A0=C2=A0=C2=A0 mask_ack_irq > =C2=A0=C2=A0=C2=A0 handle_level_irq > =C2=A0=C2=A0=C2=A0 generic_handle_irq_desc > =C2=A0=C2=A0=C2=A0 generic_handle_irq > =C2=A0=C2=A0=C2=A0 generic_handle_irq_desc > =C2=A0=C2=A0=C2=A0 generic_handle_irq > =C2=A0=C2=A0=C2=A0 gic_handle_shared_int > =C2=A0=C2=A0=C2=A0 gic_handle_local_int > =C2=A0=C2=A0=C2=A0 "irq-mips-gic.c"::gic_irq_dispatch > =C2=A0=C2=A0=C2=A0 generic_handle_irq_desc > =C2=A0=C2=A0=C2=A0 generic_handle_irq > =C2=A0=C2=A0=C2=A0 do_IRQ > =C2=A0=C2=A0=C2=A0 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 --FEz7ebHBGB6b2e8X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEd80NauSabkiESfLYbAtpk944dnoFAlnWTzcACgkQbAtpk944 dnrbGxAAlNepJ+tc/mrNu8+K/Ld+6GBVcGgL88wgjKg6z0+iOMfM4epZdAs4MP/T qSMzW6KuBE6QoMBX9vd9XIUwqMdzBxfg/8O527m+8R0CRLK/RMCc//pS9DXNeYO9 k4HOMcXIgQeAGKkXNRdcml2IqZdiWYuP2dZvPqyiY31EY4TYwnqzwgMQ3m76KgPX lXajdC/w8bGlEB5Yl1iyz5lPb53TTML7CMM9C4r5dNrV4CoPTLUTVvf4jmIJmI7m yZeN2UodTOZo/w9u6+jxj/VEv/xsosicH7XPyCkLjTLNuT2THBwUcCjF1UrnfEHa 5RhanC29JRGw1CAUcJDmrrIf/vSPKjbDUwf6/qgOkqEvl3XN6IU/8Q2/Lj+Ffbw/ 9xO0exG/ypKIgtL86W3UKdHLSQkjFrIty0rQNnIQx/DH0ESe9mPGv4TnX15wvOpk zkQDe3wzmsXXjSycprvkibHCo2CPc1zRn1gFArahkk5RKcAPAwr4fKBMB4Yaoqva abIo0SogjJ6/7JEVPAvdV5nMMsOOuHWoHv2pQw+CpWn45w0E/ublU8C7qWcrJ4Xn oS6DJNjhnTk6eMPODohWmkna7KdX/5hetrfJwwK3U0Ex5uSGNm26zrmnvuafGUVY i7HCaL7qFb/nkIQMLHbJ5zLE6cwsek88szapUiUgTRv+JPar4EQ= =eTL2 -----END PGP SIGNATURE----- --FEz7ebHBGB6b2e8X--