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: Mon, 20 Mar 2017 15:14:13 +0000	[thread overview]
Message-ID: <20170320151413.GT6986@localhost.localdomain> (raw)
In-Reply-To: <20170317003633.7361-2-tony@atomide.com>

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?

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: Mon, 20 Mar 2017 15:14:13 +0000	[thread overview]
Message-ID: <20170320151413.GT6986@localhost.localdomain> (raw)
In-Reply-To: <20170317003633.7361-2-tony@atomide.com>

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?

Thanks,
Charles

  reply	other threads:[~2017-03-20 15:14 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 [this message]
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
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
  -- strict thread matches above, loose matches on Subject: below --
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=20170320151413.GT6986@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.