Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp326576imm; Wed, 29 Aug 2018 00:42:31 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZgDFuubDeGaikT6d54obt5arO8alsEvaUafpL6ovHk7WenecARLots1LRC8gYxwi+dVGTx X-Received: by 2002:a65:4285:: with SMTP id j5-v6mr4626019pgp.446.1535528550980; Wed, 29 Aug 2018 00:42:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535528550; cv=none; d=google.com; s=arc-20160816; b=UIE4QgY1j6sV9ExGWxy3ivTEG8QUOGbJRpk2uiz7etShOX6rntxPZxjdTEpBgX/foj bGqk7mJgaCm2Kvu53iqzCc7tTDbh7dYK1164CLTsKIWMkhlA548v806u8mM4ggLZGwTL 5/EPJacR8vXDYOve92HeUSb6kToSq4djlJwrObikEvimIdMn7LEyRrG4w/ie92irvMsF WtCOryfHDZ7CrNeWYhAxuHRTOnmZj7TlZ/jxGVK3KzlvUt2eZJ1y7JVokEqFVaVY5ZT7 xUYzuardIziNWSBUnEh8htG3PpsM1MhqzoACOOVvutrTl2kQH4rTEmCIQkz/xz2ALunw +vCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=uONAZEG+xvWRL7/1zDHI0ovoG06Jhaf7tDWY6382jHs=; b=0g6P3hgNqcImqU8FnMUGkP4tc7ONpU35f82hU0K0tFzRWeAeUUFDUx+faJSjYDRDpR j3fNXLYMbVXmkmMTtnT0NXYygqCKByvGPIiGdMiOTn6t7PaQ940scnqIMolGqTz0ZcoM BuDIHCw8siopGGjC8ReyZrOtRASQSVO0NXST3ckg4fMoAtGCFgRL+OqRkf27XUcQG1Qt AOAa/MBm7xsML90r2RsnQHqNJz47/FGpC1Q+wB5CJz907CgiO3oi3vDwbPVVGfdpKBBu ZhoHndWWdHRuQY8hGrafXbZNhCF2xZ7BhHuS9ZDh+nI2p1NjKgdVbc9kpUpJvdIm5qH6 tI9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="h/O+c7sb"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p19-v6si3136313pgm.109.2018.08.29.00.42.15; Wed, 29 Aug 2018 00:42:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="h/O+c7sb"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727724AbeH2LgI (ORCPT + 99 others); Wed, 29 Aug 2018 07:36:08 -0400 Received: from mail-it0-f65.google.com ([209.85.214.65]:36284 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727642AbeH2LgI (ORCPT ); Wed, 29 Aug 2018 07:36:08 -0400 Received: by mail-it0-f65.google.com with SMTP id u13-v6so6023257iti.1 for ; Wed, 29 Aug 2018 00:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uONAZEG+xvWRL7/1zDHI0ovoG06Jhaf7tDWY6382jHs=; b=h/O+c7sbjLDPCNPyyLfH3qPbjKE4+56zKko6zcTBfhRkWd48TqqVjdGkSx/5t/R3uD UAm9SaIJ/Ek7rDCVT3Sc1bgkAeW/J3USFg4JT0Jb7CRMx7PudBV1ByoiTWww0b5N1vwT 1uuB2nHgHmpHYcSYNlYOqElORxKH/XmhjYuYE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uONAZEG+xvWRL7/1zDHI0ovoG06Jhaf7tDWY6382jHs=; b=kbrHMX/gmY1piyYNmlH7UbXwljiavMNFjzXYwSZSncSIgexfmRFeinkb80+vZUoAzp 0ZsE8RU4q5MGyGu0kq50ulnO2FYnxRNLXZuidbkVjbHecnm3U0iqOF6SUTwbqrZ4WSDx U5iZ5nnIC3cEIKueJz1cY6zddscpziE+w6TChgEBbp9hb4gBpQ35pNalTPtqQnlPMH7K /lpI57iSqZNywT2eelAuJHLBgv7fbyk7JCjXk33LVbfxBPvQhMsS9lQhDY8Sx9P7phdu yUiXw5PcCAPKfHUYaWJ1lVnV2DIJDrHb61pxA6Uoy+RA3Wx4NxY1c/sEsPvnHybBch8Q 8aNg== X-Gm-Message-State: APzg51CLYXpk9/V6pArtTl5clS6w4rC38wtxu5vGCxUtPdnBuh7uwAgf +pg7JL2Unwxiu1R4jHkSmxdKv6YUcvAAVkl3b9a1pQ== X-Received: by 2002:a02:5916:: with SMTP id p22-v6mr4171137jab.113.1535528435058; Wed, 29 Aug 2018 00:40:35 -0700 (PDT) MIME-Version: 1.0 References: <20180816200648.90458-1-swboyd@chromium.org> <20180816200648.90458-2-swboyd@chromium.org> In-Reply-To: <20180816200648.90458-2-swboyd@chromium.org> From: Linus Walleij Date: Wed, 29 Aug 2018 09:40:23 +0200 Message-ID: Subject: Re: [PATCH v3 1/3] pinctrl: msm: Really mask level interrupts to prevent latching To: Stephen Boyd Cc: "linux-kernel@vger.kernel.org" , "open list:GPIO SUBSYSTEM" , linux-arm-msm@vger.kernel.org, Bjorn Andersson , Doug Anderson Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 16, 2018 at 10:06 PM Stephen Boyd wrote: > The interrupt controller hardware in this pin controller has two status > enable bits. The first "normal" status enable bit enables or disables > the summary interrupt line being raised when a gpio interrupt triggers > and the "raw" status enable bit allows or prevents the hardware from > latching an interrupt into the status register for a gpio interrupt. > Currently we just toggle the "normal" status enable bit in the mask and > unmask ops so that the summary irq interrupt going to the CPU's > interrupt controller doesn't trigger for the masked gpio interrupt. > > For a level triggered interrupt, the flow would be as follows: the pin > controller sees the interrupt, latches the status into the status > register, raises the summary irq to the CPU, summary irq handler runs > and calls handle_level_irq(), handle_level_irq() masks and acks the gpio > interrupt, the interrupt handler runs, and finally unmask the interrupt. > When the interrupt handler completes, we expect that the interrupt line > level will go back to the deasserted state so the genirq code can unmask > the interrupt without it triggering again. > > If we only mask the interrupt by clearing the "normal" status enable bit > then we'll ack the interrupt but it will continue to show up as pending > in the status register because the raw status bit is enabled, the > hardware hasn't deasserted the line, and thus the asserted state latches > into the status register again. When the hardware deasserts the > interrupt the pin controller still thinks there is a pending unserviced > level interrupt because it latched it earlier. This behavior causes > software to see an extra interrupt for level type interrupts each time > the interrupt is handled. > > Let's fix this by clearing the raw status enable bit for level type > interrupts so that the hardware stops latching the status of the > interrupt after we ack it. We don't do this for edge type interrupts > because it seems that toggling the raw status enable bit for edge type > interrupts causes spurious edge interrupts. > > Cc: Bjorn Andersson > Cc: Doug Anderson > Signed-off-by: Stephen Boyd This patch applied for fixes with Doug and Bjorn's ACKs. I suppose you will respin the two others and obtain buy-in from the same people for these. Yours, Linus Walleij