All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@deeprootsystems.com>
To: Felipe Balbi <balbi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>, Paul Walmsley <paul@pwsan.com>,
	Santosh Shilimkar <santosh.shilimkar@ti.com>,
	Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
	Linux ARM Kernel Mailing List
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC/NOT FOR MERGING 4/5] i2c: omap: don't re-enable IRQs after masking them
Date: Thu, 18 Oct 2012 10:10:06 -0700	[thread overview]
Message-ID: <874nlrg101.fsf@deeprootsystems.com> (raw)
In-Reply-To: <1350488043-5053-5-git-send-email-balbi@ti.com> (Felipe Balbi's message of "Wed, 17 Oct 2012 18:34:02 +0300")

Felipe Balbi <balbi@ti.com> writes:

> OMAP I2C driver will re-enable IRQs right after
> masking them during suspend.
>
> That's not what we want. We want to keep IRQs
> masked until our resume method is called.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>  drivers/i2c/busses/i2c-omap.c | 10 ++--------
>  1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index db31eae..7eeae11 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -1247,14 +1247,8 @@ static int omap_i2c_runtime_suspend(struct device *dev)
>  
>  	omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
>  
> -	if (_dev->rev < OMAP_I2C_OMAP1_REV_2) {
> -		iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
> -	} else {
> -		omap_i2c_write_reg(_dev, OMAP_I2C_STAT_REG, _dev->iestate);
> -
> -		/* Flush posted write */
> -		omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG);
> -	}

Are you sure this re-enables the interrupt?  It looks to me like
it's meant to clear the interrupt.    

> +	/* Flush posted write */
> +	omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG);

Assuming the above is correct, should this be IE_REG?

>  	return 0;
>  }

Kevin

WARNING: multiple messages have this Message-ID (diff)
From: khilman@deeprootsystems.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC/NOT FOR MERGING 4/5] i2c: omap: don't re-enable IRQs after masking them
Date: Thu, 18 Oct 2012 10:10:06 -0700	[thread overview]
Message-ID: <874nlrg101.fsf@deeprootsystems.com> (raw)
In-Reply-To: <1350488043-5053-5-git-send-email-balbi@ti.com> (Felipe Balbi's message of "Wed, 17 Oct 2012 18:34:02 +0300")

Felipe Balbi <balbi@ti.com> writes:

> OMAP I2C driver will re-enable IRQs right after
> masking them during suspend.
>
> That's not what we want. We want to keep IRQs
> masked until our resume method is called.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>  drivers/i2c/busses/i2c-omap.c | 10 ++--------
>  1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index db31eae..7eeae11 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -1247,14 +1247,8 @@ static int omap_i2c_runtime_suspend(struct device *dev)
>  
>  	omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
>  
> -	if (_dev->rev < OMAP_I2C_OMAP1_REV_2) {
> -		iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
> -	} else {
> -		omap_i2c_write_reg(_dev, OMAP_I2C_STAT_REG, _dev->iestate);
> -
> -		/* Flush posted write */
> -		omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG);
> -	}

Are you sure this re-enables the interrupt?  It looks to me like
it's meant to clear the interrupt.    

> +	/* Flush posted write */
> +	omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG);

Assuming the above is correct, should this be IE_REG?

>  	return 0;
>  }

Kevin

  reply	other threads:[~2012-10-18 17:09 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-17 15:33 [RFC/NOT FOR MERGING 0/5] OMAP PM patches Felipe Balbi
2012-10-17 15:33 ` Felipe Balbi
2012-10-17 15:33 ` [RFC/NOT FOR MERGING 1/5] arm: omap: fix up _od_suspend_noirq and _od_resume_noirq Felipe Balbi
2012-10-17 15:39   ` Felipe Balbi
2012-10-18 16:34   ` Kevin Hilman
2012-10-18 16:34     ` Kevin Hilman
2012-10-18 16:55     ` Felipe Balbi
2012-10-18 16:55       ` Felipe Balbi
2012-10-18 17:42       ` Kevin Hilman
2012-10-18 17:42         ` Kevin Hilman
2012-10-18 17:50         ` Felipe Balbi
2012-10-18 17:50           ` Felipe Balbi
2012-10-18 18:42           ` Kevin Hilman
2012-10-18 18:42             ` Kevin Hilman
2012-10-18 19:34             ` Felipe Balbi
2012-10-18 19:34               ` Felipe Balbi
2012-10-18 20:47               ` Kevin Hilman
2012-10-18 20:47                 ` Kevin Hilman
2012-10-18 20:58               ` Kevin Hilman
2012-10-18 20:58                 ` Kevin Hilman
2012-10-17 15:34 ` [RFC/NOT FOR MERGING 2/5] arm: omap: don't forcefully runtime suspend a device Felipe Balbi
2012-10-17 15:39   ` Felipe Balbi
2012-10-18 17:01   ` Kevin Hilman
2012-10-18 17:01     ` Kevin Hilman
2012-10-18 17:05     ` Felipe Balbi
2012-10-18 17:05       ` Felipe Balbi
2012-10-17 15:34 ` [RFC/NOT FOR MERGING 3/5] arm: omap: introduce other PM methods Felipe Balbi
2012-10-17 15:39   ` Felipe Balbi
2012-10-18 17:07   ` Kevin Hilman
2012-10-18 17:07     ` Kevin Hilman
2012-10-18 17:06     ` Felipe Balbi
2012-10-18 17:06       ` Felipe Balbi
2012-10-18 17:23       ` Felipe Balbi
2012-10-18 17:23         ` Felipe Balbi
2012-10-17 15:34 ` [RFC/NOT FOR MERGING 4/5] i2c: omap: don't re-enable IRQs after masking them Felipe Balbi
2012-10-17 15:39   ` Felipe Balbi
2012-10-18 17:10   ` Kevin Hilman [this message]
2012-10-18 17:10     ` Kevin Hilman
2012-10-18 17:07     ` Felipe Balbi
2012-10-18 17:07       ` Felipe Balbi
2012-10-17 15:34 ` [RFC/NOT FOR MERGING 5/5] i2c: omap: introduce suspend/resume methods Felipe Balbi
2012-10-17 15:39   ` Felipe Balbi

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=874nlrg101.fsf@deeprootsystems.com \
    --to=khilman@deeprootsystems.com \
    --cc=balbi@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=santosh.shilimkar@ti.com \
    --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.