From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 53C631A704B for ; Sun, 22 Feb 2026 22:55:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771800936; cv=none; b=ELUFSDSwkgSa2K82Pu0UBiXx9w3D+5iRFx2/QVer/LZ5dpgYJomcRNKXa/NcKciTXSxoi+t+4bMDfLrelVAUoon1A4P9TYvx/8b0ZC14kRVR9+BbvDgGZVcgm/ZbJaRJXSF8StfJ6xTR6goc9izISepRPy+stdfpB8K6xhsxvvs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771800936; c=relaxed/simple; bh=s+LvcqSDcmYSjp0wObgVLgicJGsC7NHnBp4BHzP32Qg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=eAF0njUW9VbEkArAkW4XpC9OA4DjwC6jLaab4oRDtwvYP+Xm8mafO9HXUUdKiz7ewqX9sLlL8s0oqxn2LdWxKoEfC5Fs/tOEPHUWyl93A82c0h/2sPE5uoJ4SSLPRJgKLFnz8dPwmu20YF7AzExlAl7BttSHPn34VkYLdkHi1K8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=o/oLQSEd; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="o/oLQSEd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0DE8EC116D0; Sun, 22 Feb 2026 22:55:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771800935; bh=s+LvcqSDcmYSjp0wObgVLgicJGsC7NHnBp4BHzP32Qg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=o/oLQSEdSFOf2uQKfJ/c2Lj3YdzY6O0p8g9qfHx1ju94JuSyqgwJKe2DIn3k/e1Qy GnmL3t817opy4pGdVJChmByXJBNr+kmsdlF2UF7/mPrcGQlgIval59st3fmFnxQ7B7 pRrAxCE64HkYYuLaZLG7J/RQtb2ga7NIsN33AebyZHoR83cAd2Zw7zgxz3w1FK7z9D yQdcDaxjfx7kSCosYH2LFB8V5/sWrPawvlTkwZFKjPcVsWgV+L8mp2goubNvwocHBK 9cNxtPcaXUda4BAQPEDKk8Nku1ylIBws5k+S6QMKl0tUZ4kYbfLZrFSejrVRtQflGN 8UIOZMwvBXOrQ== From: Thomas Gleixner To: Meghana Malladi , grzegorz.jaszczyk@linaro.org, maz@kernel.org, rogerq@ti.com, david@lechnology.com, afd@ti.com Cc: linux-kernel@vger.kernel.org, srk@ti.com, Vignesh Raghavendra , Roger Quadros , danishanwar@ti.com, m-malladi@ti.com, Suman Anna , Grygorii Strashko Subject: Re: [PATCH v2 3/3] irqchip/irq-pruss-intc: Fix processing of IEP interrupts In-Reply-To: <20260218093730.3123342-4-m-malladi@ti.com> References: <20260218093730.3123342-1-m-malladi@ti.com> <20260218093730.3123342-4-m-malladi@ti.com> Date: Sun, 22 Feb 2026 23:55:32 +0100 Message-ID: <87v7fov15n.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 18 2026 at 15:07, Meghana Malladi wrote: > IEP compare/capture events are level-triggered and remain asserted until > the IEP CMP/CAP status register is cleared. The PRUSS INTC acknowledges The INTC does not acknowledge anything. The driver does. > this event (via SICR) before the IEP source is actually cleared, leaving = the > SECR latch still set. When linux unmasks the interrupt after the threaded > handler completes, the INTC still sees the event as pending, resulting in > an unintended second interrupt. > > The solution is to actually ack these IRQs from pruss_intc_irq_unmask() s/IRQ/interrupt/g > after the IRQ source is cleared in HW. > > The interrupt handling sequence is as follows: > IEP hardware > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > [1] Compare match occurs > [2] IEP sets CMP/CAP status bit =3D 1 > [3] Output level stays HIGH until software clears IEP status > > PRUSS INTC > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > [4] Detects level HIGH =E2=86=92 sets SECR[event] =3D 1 > [5] Raises host IRQ to Linux > > Linux interrupt flow (oneshot) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > HARD IRQ: > [6] pruss_intc_irq_handler() > [7] mask_ack_irq() > =E2=86=92 writes SICR =3D event > =E2=86=92 tries to clear SECR > BUT level still HIGH =E2=86=92 INTC still sees it pending > > THREAD HANDLER: > [8] icss_iep_cap_cmp_handler() > =E2=86=92 clears IEP CMP/CAP status bit > =E2=86=92 IEP output level goes LOW > > IRQ FINALIZATION: > [9] irq_finalize_oneshot() > [10] pruss_intc_irq_unmask(): > Without fix: > - EISR reenables event > - INTC still thinks event pending (stale SECR) > =E2=86=92 SECOND IRQ (spurious) > > With fix: > - Write SICR again (now level LOW =E2=86=92 INTC clears latc= h) > - Then EISR enables event cleanly > =E2=86=92 No spurious IRQ Having the ACK in the unmask is fundamentally wrong and a horrible hack. The driver uses the wrong handler. That's what handle_fasteoi_irq() is for. All you need is to set the IRQCHIP_EOI_THREADED flag on the interrupt chip and implement irq_eoi() instead of irq_ack(). For the non-threaded cases this spares the mask/unmask dance completely. For the threaded oneshot case it masks on entry and irq_finalize_oneshot() does the EOI and the unmask via unmask_threaded_irq(). No? Thanks, tglx