From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05A6BC43140 for ; Fri, 6 Sep 2019 00:39:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F234020820 for ; Fri, 6 Sep 2019 00:39:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="VKalJm2E" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391599AbfIFAjy (ORCPT ); Thu, 5 Sep 2019 20:39:54 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:38123 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391509AbfIFAjy (ORCPT ); Thu, 5 Sep 2019 20:39:54 -0400 Received: by mail-pf1-f194.google.com with SMTP id h195so3085379pfe.5 for ; Thu, 05 Sep 2019 17:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=message-id:mime-version:content-transfer-encoding:in-reply-to :references:to:from:cc:subject:user-agent:date; bh=UgLwGOLd9Qaofpb/EMRahwjwW4TzGd9hkLOFeY5MZAY=; b=VKalJm2EThnQ27lsNLgCNQVCIu2xu0aPd0QmMEODnmLKOaOclAraltTAFz5qlLmPsz OrIA51ux0pzJWcRc2yp/pmbwTzvDB4HOW92Frt21D4wp9mkgTWh2fR9CTKbeHFvVcS50 49B6sW1p1h3yjjezZwnpLETheL6yUorgutylc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version :content-transfer-encoding:in-reply-to:references:to:from:cc:subject :user-agent:date; bh=UgLwGOLd9Qaofpb/EMRahwjwW4TzGd9hkLOFeY5MZAY=; b=I/n08W1E238KQAX+1/KyNleaVwQX5N93UnwB4sYRNogEPNJ36vwkV1wzuPrHpymFy8 9Uuj6dmrgFQcCyvso6GeTC4Oyh2BCWPEm4yeQrt6EgGHBQUiAxX7TbV13Ph3GFMWkurj rtgr7PTobfIQ4dS+woZVMeI1wTGsgGP1yBra7vAQLra4/Kxe8R8VFznQv/PChVVwzXm5 rDLNzsKiVRVgXbIzeBvA2fM1dkPUzzG1J4RuarVede+pArjXNioIsMhSADC+8VE2jXSI ZgHaWvsnilQVe09wk6LtKc/THTPJsseeB2KtEWWtsO4qfvjbJGFigyq1szDKAoHcrsA3 18MA== X-Gm-Message-State: APjAAAXpGgal0guOYMxaipzAPP+x/UmGhgUWMWKbm6Ez4w24vC5teTlA H9PBK//qQuBn7yWMn8KdD7lD7w== X-Google-Smtp-Source: APXvYqzsUIedg/kFHh7n2df4VYVSimGTOumXrGupH6BrHebKIF4HmZ8VC2KdVr+TA3cvwdNwNGA7AQ== X-Received: by 2002:a62:d45a:: with SMTP id u26mr4972214pfl.137.1567730393567; Thu, 05 Sep 2019 17:39:53 -0700 (PDT) Received: from chromium.org ([2620:15c:202:1:fa53:7765:582b:82b9]) by smtp.gmail.com with ESMTPSA id 127sm7907733pfy.56.2019.09.05.17.39.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Sep 2019 17:39:53 -0700 (PDT) Message-ID: <5d71aad9.1c69fb81.f469e.262f@mx.google.com> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20190829181203.2660-3-ilina@codeaurora.org> References: <20190829181203.2660-1-ilina@codeaurora.org> <20190829181203.2660-3-ilina@codeaurora.org> To: Lina Iyer , evgreen@chromium.org, linus.walleij@linaro.org, marc.zyngier@arm.com From: Stephen Boyd Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, bjorn.andersson@linaro.org, mkshah@codeaurora.org, linux-gpio@vger.kernel.org, rnayak@codeaurora.org, Lina Iyer Subject: Re: [PATCH RFC 02/14] drivers: irqchip: pdc: Do not toggle IRQ_ENABLE during mask/unmask User-Agent: alot/0.8.1 Date: Thu, 05 Sep 2019 17:39:52 -0700 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Lina Iyer (2019-08-29 11:11:51) > When an interrupt is to be serviced, the convention is to mask the > interrupt at the chip and unmask after servicing the interrupt. Enabling > and disabling the interrupt at the PDC irqchip causes an interrupt storm > due to the way dual edge interrupts are handled in hardware. >=20 > Skip configuring the PDC when the IRQ is masked and unmasked, instead > use the irq_enable/irq_disable callbacks to toggle the IRQ_ENABLE > register at the PDC. The PDC's IRQ_ENABLE register is only used during > the monitoring mode when the system is asleep and is not needed for > active mode detection. I think this is saying that we want to always let the line be sent through the PDC to the parent irqchip, in this case GIC, so that we don't get an interrupt storm for dual edge interrupts? Why does dual edge interrupts cause a problem? >=20 > Signed-off-by: Lina Iyer