Re: mfd regmap irq to handle some cases

Re: mfd regmap irq to handle some cases

[Ashish Jangam]

On Wed, 2012-02-01 at 13:10 +0530, Ashish Jangam wrote:
> 
> > spurious interrupt we get on clearing event and event can be from any
> > mfd children. But since now, deferring event clear is not the approach
> > we can ignore about the spurious interrupt.
> > Now looking at the old issue of determining the RTC type (periodic or tick)
> > on event clearing this info (RTC type) gets lost for the register since in regmap_irq
> > we first clear and then process the event.
> 
> That we can handle easily enough by adding a flag to the interrupt
> definition deferring the acknowledgement.
> 
Can you let me know in which linux-next version this will be available so
that I can test it against the DA9052/53 RTC?

Re: mfd regmap irq to handle some cases

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

On Wed, Feb 01, 2012 at 01:25:14PM +0530, Ashish Jangam wrote:
> On Wed, 2012-02-01 at 13:10 +0530, Ashish Jangam wrote:

> > That we can handle easily enough by adding a flag to the interrupt
> > definition deferring the acknowledgement.

> Can you let me know in which linux-next version this will be available so
> that I can test it against the DA9052/53 RTC?

I've no particular plan to work on this myself - I would suggest that
you work on this if it is an urgent requirement for your device.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: mfd regmap irq to handle some cases

[Mark Brown]

On Wed, Jan 25, 2012 at 04:28:29AM +0000, Ashish Jangam wrote:

> > > There will processing of false events which is undesirable.

> > But what actually happens?  RTC interrupts aren't going to be high
> > volume, if we get the odd spurious interrupt and handle it gracefully
> > I'm not sure we really care.

> spurious interrupt we get on clearing event and event can be from any
> mfd children. But since now, deferring event clear is not the approach
> we can ignore about the spurious interrupt.
> Now looking at the old issue of determining the RTC type (periodic or tick)
> on event clearing this info (RTC type) gets lost for the register since in regmap_irq
> we first clear and then process the event.

That we can handle easily enough by adding a flag to the interrupt
definition deferring the acknowledgement.

RE: mfd regmap irq to handle some cases

[Ashish Jangam]

________________________________________
From: Mark Brown [broonie@opensource.wolfsonmicro.com]
Sent: Monday, January 23, 2012 8:48 PM
To: Ashish Jangam
Cc: linux-kernel@vger.kernel.org
Subject: Re: mfd regmap irq to handle some cases

On Mon, Jan 23, 2012 at 07:03:31PM +0530, Ashish Jangam wrote:
> On Mon, 2012-01-23 at 19:02 +0530, Ashish Jangam wrote:

> > > > approach for some variants of DA9052 and DA9053 when event is cleared
> > > > a spurious interrupt gets generated therefore in earlier release of
> > > > DA9052/53 MFD module a delay was added. Therefore we need to think on
> > > > how to handle such cases in regmap irq.

> > > What are the consequences of the spurious interrupt?

> There will processing of false events which is undesirable.

But what actually happens?  RTC interrupts aren't going to be high
volume, if we get the odd spurious interrupt and handle it gracefully
I'm not sure we really care.

( As I'm traveling so please ignore the mail format)
spurious interrupt we get on clearing event and event can be from any
mfd children. But since now, deferring event clear is not the approach
we can ignore about the spurious interrupt.
Now looking at the old issue of determining the RTC type (periodic or tick)
on event clearing this info (RTC type) gets lost for the register since in regmap_irq
we first clear and then process the event.

Re: mfd regmap irq to handle some cases

[Mark Brown]

On Mon, Jan 23, 2012 at 07:03:31PM +0530, Ashish Jangam wrote:
> On Mon, 2012-01-23 at 19:02 +0530, Ashish Jangam wrote:

> > > > approach for some variants of DA9052 and DA9053 when event is cleared
> > > > a spurious interrupt gets generated therefore in earlier release of
> > > > DA9052/53 MFD module a delay was added. Therefore we need to think on
> > > > how to handle such cases in regmap irq.

> > > What are the consequences of the spurious interrupt?

> There will processing of false events which is undesirable. 

But what actually happens?  RTC interrupts aren't going to be high
volume, if we get the odd spurious interrupt and handle it gracefully
I'm not sure we really care.

Re: mfd regmap irq to handle some cases

[Ashish Jangam]

On Mon, 2012-01-23 at 19:02 +0530, Ashish Jangam wrote:
> 
> > -----Original Message-----
> > From: Mark Brown [mailto:broonie@opensource.wolfsonmicro.com]
> > Sent: Monday, January 23, 2012 5:22 PM
> > To: Ashish Jangam
> > Cc: linux-kernel@vger.kernel.org
> > Subject: Re: mfd regmap irq to handle some cases
> > 
> > On Mon, Jan 23, 2012 at 02:17:03PM +0530, Ashish Jangam wrote:
> > 
> > Please fix your mailer to word wrap within 80 columns.  I've reflowed
> > your text for legibility.
> > 
> > > For a quick fix in regmap irq we may tempt to defer event
> > > clarification after processing of event but there is a problem in this
> > 
> > That's not going to work in general, it means there's a race between
> > handling the interrupt and acknowledging the interrupt which leads to
> > interrupts being dropped if you get a new interrupt before the ack has
> > been written back.
I'm aware of this but added to this there is also another issue specific
to DA9052 that was highlighted.
> > 
> > > approach for some variants of DA9052 and DA9053 when event is cleared
> > > a spurious interrupt gets generated therefore in earlier release of
> > > DA9052/53 MFD module a delay was added. Therefore we need to think on
> > > how to handle such cases in regmap irq.
> > 
> > What are the consequences of the spurious interrupt?
> 
There will processing of false events which is undesirable. 

Re: mfd regmap irq to handle some cases

[Mark Brown]

On Mon, Jan 23, 2012 at 02:17:03PM +0530, Ashish Jangam wrote:

Please fix your mailer to word wrap within 80 columns.  I've reflowed
your text for legibility.

> For a quick fix in regmap irq we may tempt to defer event
> clarification after processing of event but there is a problem in this

That's not going to work in general, it means there's a race between
handling the interrupt and acknowledging the interrupt which leads to
interrupts being dropped if you get a new interrupt before the ack has
been written back.

> approach for some variants of DA9052 and DA9053 when event is cleared
> a spurious interrupt gets generated therefore in earlier release of
> DA9052/53 MFD module a delay was added. Therefore we need to think on
> how to handle such cases in regmap irq.

What are the consequences of the spurious interrupt?

mfd regmap irq to handle some cases

[Ashish Jangam]

Hi Mark,

DA9052-53 PMIC supports Tick & Periodic Alarm. On expiry of Alarm an event gets generate
and data ( about the alram type - Tick or Periodic) also gets lock in a register. This
data needs to be read from the register before event is cleared . But since in regmap irq
events are cleared first and then left for processing (which is the obvious way to do) but
in this approach data gets loss from the DA9052-53 register and alarm type cannot be
determined.

For a quick fix in regmap irq we may tempt to defer event clarification after processing of
event but there is a problem in this approach for some variants of DA9052 and DA9053 when
event is cleared a spurious interrupt gets generated therefore in earlier release of DA9052/53
MFD module a delay was added. Therefore we need to think on how to handle such cases in regmap irq.

Regards,
Ashish