From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756982AbdCUJ2x (ORCPT ); Tue, 21 Mar 2017 05:28:53 -0400 Received: from mx0b-001ae601.pphosted.com ([67.231.152.168]:36938 "EHLO mx0b-001ae601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753279AbdCUJ2u (ORCPT ); Tue, 21 Mar 2017 05:28:50 -0400 Authentication-Results: ppops.net; spf=none smtp.mailfrom=ckeepax@opensource.wolfsonmicro.com Date: Tue, 21 Mar 2017 09:23:40 +0000 From: Charles Keepax To: Tony Lindgren CC: Mark Brown , , , Lee Jones , Marcel Partap , Michael Scott , "Sebastian Reichel" Subject: Re: [PATCH 1/4] regmap: irq: Fix lost interrupts by introducing handle_reread Message-ID: <20170321092340.GU6986@localhost.localdomain> References: <20170317003633.7361-1-tony@atomide.com> <20170317003633.7361-2-tony@atomide.com> <20170320151413.GT6986@localhost.localdomain> <20170320153341.GK20572@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20170320153341.GK20572@atomide.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703210084 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 20, 2017 at 08:33:42AM -0700, Tony Lindgren wrote: > * Charles Keepax [170320 08:15]: > > On Thu, Mar 16, 2017 at 05:36:30PM -0700, Tony Lindgren wrote: > > > At least Motorola CPCAP PMIC needs it's device interrupts re-read > > > until there are no more interrupts. Otherwise the PMIC interrupt to > > > the SoC will eventually stop toggling. > > > > > > Let's allow doing that by introducing a flag for handle_reread > > > and by splitting regmap_irq_thread() into two separate functions > > > for regmap_read_irq_status() and regmap_irq_handle_pending(). > > > > > > > Is this actually a property of this hardware or is this just a > > result of connecting a device that generates level IRQs to a host > > that is expecting an edge triggered IRQ? > > Well the CPCAP PMIC interrupt is connected to a GPIO edge interrupt > on the SoC in the Motorola v3.8 based kernel tree. But what the CPCAP > PMIC interrupt handler does in the Motorola kernel is keep handling > the CPCAP internal interrupts (and also keep reading the SoC GPIO > line status!) until the GPIO line changes status. So yeah it's a > property of the CPCAP PMIC hardware. > That sounds a lot like a level triggered IRQ. If they are repeatedly reading the GPIO line until it returns to high to know they need to process more IRQs, that implies the line is staying low whilst IRQs need handling which is level triggered. > Changing the GPIO interrupt to level makes no difference here. It's > not clear why they had marked the CPCAP PMIC to SoC GPIO interrupt > as edge though in the Motorola kernel. My guess is that some PMIC > to SoC wake-up events are edge interrupts. So we have it set up as > edge interrupt in the mainline kernel too. > I guess my only comment here is are we sure this isn't a bug in supporting level IRQs in the GPIO driver, of course it could be that the SoC simply doesn't support level IRQs that is fairly common as well. But I guess we should be clear in the commit message if this is adding emulation of level triggered IRQs and possible add some gating on type of IRQ requested. Thanks, Charles From mboxrd@z Thu Jan 1 00:00:00 1970 From: Charles Keepax Subject: Re: [PATCH 1/4] regmap: irq: Fix lost interrupts by introducing handle_reread Date: Tue, 21 Mar 2017 09:23:40 +0000 Message-ID: <20170321092340.GU6986@localhost.localdomain> References: <20170317003633.7361-1-tony@atomide.com> <20170317003633.7361-2-tony@atomide.com> <20170320151413.GT6986@localhost.localdomain> <20170320153341.GK20572@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Return-path: Content-Disposition: inline In-Reply-To: <20170320153341.GK20572@atomide.com> Sender: linux-kernel-owner@vger.kernel.org To: Tony Lindgren Cc: Mark Brown , linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, Lee Jones , Marcel Partap , Michael Scott , Sebastian Reichel List-Id: linux-omap@vger.kernel.org On Mon, Mar 20, 2017 at 08:33:42AM -0700, Tony Lindgren wrote: > * Charles Keepax [170320 08:15]: > > On Thu, Mar 16, 2017 at 05:36:30PM -0700, Tony Lindgren wrote: > > > At least Motorola CPCAP PMIC needs it's device interrupts re-read > > > until there are no more interrupts. Otherwise the PMIC interrupt to > > > the SoC will eventually stop toggling. > > > > > > Let's allow doing that by introducing a flag for handle_reread > > > and by splitting regmap_irq_thread() into two separate functions > > > for regmap_read_irq_status() and regmap_irq_handle_pending(). > > > > > > > Is this actually a property of this hardware or is this just a > > result of connecting a device that generates level IRQs to a host > > that is expecting an edge triggered IRQ? > > Well the CPCAP PMIC interrupt is connected to a GPIO edge interrupt > on the SoC in the Motorola v3.8 based kernel tree. But what the CPCAP > PMIC interrupt handler does in the Motorola kernel is keep handling > the CPCAP internal interrupts (and also keep reading the SoC GPIO > line status!) until the GPIO line changes status. So yeah it's a > property of the CPCAP PMIC hardware. > That sounds a lot like a level triggered IRQ. If they are repeatedly reading the GPIO line until it returns to high to know they need to process more IRQs, that implies the line is staying low whilst IRQs need handling which is level triggered. > Changing the GPIO interrupt to level makes no difference here. It's > not clear why they had marked the CPCAP PMIC to SoC GPIO interrupt > as edge though in the Motorola kernel. My guess is that some PMIC > to SoC wake-up events are edge interrupts. So we have it set up as > edge interrupt in the mainline kernel too. > I guess my only comment here is are we sure this isn't a bug in supporting level IRQs in the GPIO driver, of course it could be that the SoC simply doesn't support level IRQs that is fairly common as well. But I guess we should be clear in the commit message if this is adding emulation of level triggered IRQs and possible add some gating on type of IRQ requested. Thanks, Charles