All of lore.kernel.org
 help / color / mirror / Atom feed
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Mark Brown <broonie@kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-omap@vger.kernel.org>, Lee Jones <lee.jones@linaro.org>,
	Marcel Partap <mpartap@gmx.net>,
	Michael Scott <michael.scott@linaro.org>,
	"Sebastian Reichel" <sre@kernel.org>
Subject: Re: [PATCH 1/4] regmap: irq: Fix lost interrupts by introducing handle_reread
Date: Tue, 21 Mar 2017 16:43:30 +0000	[thread overview]
Message-ID: <20170321164330.GB6986@localhost.localdomain> (raw)
In-Reply-To: <20170321154122.GB10760@atomide.com>

On Tue, Mar 21, 2017 at 08:41:22AM -0700, Tony Lindgren wrote:
> * Charles Keepax <ckeepax@opensource.wolfsonmicro.com> [170321 02:24]:
> > On Mon, Mar 20, 2017 at 08:33:42AM -0700, Tony Lindgren wrote:
> > > * Charles Keepax <ckeepax@opensource.wolfsonmicro.com> [170320 08:15]:
> > > > On Thu, Mar 16, 2017 at 05:36:30PM -0700, Tony Lindgren wrote:
> > 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.
> 
> Yeah.. Actually my description above is a bit wrong sorry. It seems
> the GPIO line changes status too early in some cases meaning the
> interrupts stop. So it's like a buggy implementation of level IRQ
> that stops driving the GPIO interrupt line to the SoC in some cases
> even with PMIC interrupts pending. So it seems like a bug in the
> CPCAP PMIC.
> 
> So the handling needs to be "read while CPCAP interrupts in the
> registers even if the GPIO line to SoC has cleared stopped
> signaling interrupts" :)
> 

Ah ok thanks for taking the time to explain that. Yeah that
sounds like the PMIC hardware is a bit buggy so you will
presumably need something to support this.

Thanks,
Charles

WARNING: multiple messages have this Message-ID (diff)
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Mark Brown <broonie@kernel.org>,
	linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
	Lee Jones <lee.jones@linaro.org>, Marcel Partap <mpartap@gmx.net>,
	Michael Scott <michael.scott@linaro.org>,
	Sebastian Reichel <sre@kernel.org>
Subject: Re: [PATCH 1/4] regmap: irq: Fix lost interrupts by introducing handle_reread
Date: Tue, 21 Mar 2017 16:43:30 +0000	[thread overview]
Message-ID: <20170321164330.GB6986@localhost.localdomain> (raw)
In-Reply-To: <20170321154122.GB10760@atomide.com>

On Tue, Mar 21, 2017 at 08:41:22AM -0700, Tony Lindgren wrote:
> * Charles Keepax <ckeepax@opensource.wolfsonmicro.com> [170321 02:24]:
> > On Mon, Mar 20, 2017 at 08:33:42AM -0700, Tony Lindgren wrote:
> > > * Charles Keepax <ckeepax@opensource.wolfsonmicro.com> [170320 08:15]:
> > > > On Thu, Mar 16, 2017 at 05:36:30PM -0700, Tony Lindgren wrote:
> > 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.
> 
> Yeah.. Actually my description above is a bit wrong sorry. It seems
> the GPIO line changes status too early in some cases meaning the
> interrupts stop. So it's like a buggy implementation of level IRQ
> that stops driving the GPIO interrupt line to the SoC in some cases
> even with PMIC interrupts pending. So it seems like a bug in the
> CPCAP PMIC.
> 
> So the handling needs to be "read while CPCAP interrupts in the
> registers even if the GPIO line to SoC has cleared stopped
> signaling interrupts" :)
> 

Ah ok thanks for taking the time to explain that. Yeah that
sounds like the PMIC hardware is a bit buggy so you will
presumably need something to support this.

Thanks,
Charles

  reply	other threads:[~2017-03-21 16:42 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-17  0:36 [PATCH 0/4] Regmap IRQ fix and related changes CPCAP Tony Lindgren
2017-03-17  0:36 ` [PATCH 1/4] regmap: irq: Fix lost interrupts by introducing handle_reread Tony Lindgren
2017-03-20 15:14   ` Charles Keepax
2017-03-20 15:14     ` Charles Keepax
2017-03-20 15:33     ` Tony Lindgren
2017-03-21  9:23       ` Charles Keepax
2017-03-21  9:23         ` Charles Keepax
2017-03-21 15:41         ` Tony Lindgren
2017-03-21 16:43           ` Charles Keepax [this message]
2017-03-21 16:43             ` Charles Keepax
2017-03-17  0:36 ` [PATCH 2/4] mfd: cpcap: Use handle_reread flag for interrupts Tony Lindgren
2017-03-17  0:36 ` [PATCH 3/4] mfd: cpcap: Use ack_invert interrupts Tony Lindgren
2017-03-17  0:36 ` [PATCH 4/4] mfd: cpcap: Fix bad use of IRQ sense register Tony Lindgren
2017-03-19  2:01   ` Sebastian Reichel
2017-03-19 16:07     ` Tony Lindgren
2017-03-20 10:47   ` Lee Jones
2017-03-22  2:22 ` [PATCH 0/4] Regmap IRQ fix and related changes CPCAP Sebastian Reichel
2017-03-22 17:10 [PATCHv2 " Tony Lindgren
2017-03-22 17:10 ` [PATCH 1/4] regmap: irq: Fix lost interrupts by introducing handle_reread Tony Lindgren
2017-03-27 17:49   ` Mark Brown
2017-03-28  0:36     ` Tony Lindgren
2017-03-28 15:18       ` Mark Brown
2017-03-28 15:47         ` Tony Lindgren
2017-03-28 16:49           ` Mark Brown
2017-03-28 17:10             ` Tony Lindgren
2017-04-04  3:03               ` Tony Lindgren
2017-04-04 12:19                 ` Mark Brown
2017-04-04 13:56                   ` Tony Lindgren
2017-04-04 15:28                     ` Mark Brown
2017-04-03 11:27   ` Lee Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170321164330.GB6986@localhost.localdomain \
    --to=ckeepax@opensource.wolfsonmicro.com \
    --cc=broonie@kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=michael.scott@linaro.org \
    --cc=mpartap@gmx.net \
    --cc=sre@kernel.org \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.