From: Shubhrajyoti <shubhrajyoti-l0cyMroinI0@public.gmane.org>
To: Kevin Hilman <khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
kalle.jokiniemi-4y2FMlU5MS8onNqTyK5kxQ@public.gmane.org,
grygorii.strashko-l0cyMroinI0@public.gmane.org,
huzefank-l0cyMroinI0@public.gmane.org
Subject: Re: [PATCH 1/3] i2c: omap: Do not enable the irq always
Date: Fri, 12 Oct 2012 20:29:14 +0530 [thread overview]
Message-ID: <50783042.2040609@ti.com> (raw)
In-Reply-To: <87lifb7odc.fsf-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
On Friday 12 October 2012 08:01 PM, Kevin Hilman wrote:
> When using runtime PM with auto-suspend timeouts, why would you disable
> the IRQ before the runtime suspend handlers have run?
>
> If you really want to do this, you probably should have these in the
> runtime PM callbacks. But I'll wait until you add a more descriptive
> changelog before I can really tell why this is being done. Based on the
> discussion in the patch from Kalle, I'm assuming this is to prevent
> interrups when I2C is being used by co-processors. If so, plese
> describe in the changelog.
>
> That being said, doesn't the runtime suspend callback already disable
> IRQs at the device level instead of the INTC level?
I thought of not relying on the intc as the registers may be reconfigured.
> Kevin
WARNING: multiple messages have this Message-ID (diff)
From: shubhrajyoti@ti.com (Shubhrajyoti)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] i2c: omap: Do not enable the irq always
Date: Fri, 12 Oct 2012 20:29:14 +0530 [thread overview]
Message-ID: <50783042.2040609@ti.com> (raw)
In-Reply-To: <87lifb7odc.fsf@deeprootsystems.com>
On Friday 12 October 2012 08:01 PM, Kevin Hilman wrote:
> When using runtime PM with auto-suspend timeouts, why would you disable
> the IRQ before the runtime suspend handlers have run?
>
> If you really want to do this, you probably should have these in the
> runtime PM callbacks. But I'll wait until you add a more descriptive
> changelog before I can really tell why this is being done. Based on the
> discussion in the patch from Kalle, I'm assuming this is to prevent
> interrups when I2C is being used by co-processors. If so, plese
> describe in the changelog.
>
> That being said, doesn't the runtime suspend callback already disable
> IRQs at the device level instead of the INTC level?
I thought of not relying on the intc as the registers may be reconfigured.
> Kevin
next prev parent reply other threads:[~2012-10-12 14:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-08 9:05 [PATCH 1/3] i2c: omap: Do not enable the irq always Shubhrajyoti D
2012-10-08 9:05 ` Shubhrajyoti D
[not found] ` <1349687116-14463-1-git-send-email-shubhrajyoti-l0cyMroinI0@public.gmane.org>
2012-10-08 9:05 ` [PATCH 2/3] i2c: omap: Remove the redundant fifo clear Shubhrajyoti D
2012-10-08 9:05 ` Shubhrajyoti D
2012-10-08 9:05 ` [PATCH 3/3] i2c: omap: Remove Address as slave wakeup Shubhrajyoti D
2012-10-08 9:05 ` Shubhrajyoti D
2012-10-08 9:46 ` [PATCH 1/3] i2c: omap: Do not enable the irq always Russell King - ARM Linux
2012-10-08 9:46 ` Russell King - ARM Linux
2012-10-12 14:26 ` Kevin Hilman
2012-10-12 14:26 ` Kevin Hilman
[not found] ` <87txtz7on9.fsf-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
2012-10-12 18:00 ` Shubhrajyoti Datta
2012-10-12 18:00 ` Shubhrajyoti Datta
2012-10-12 14:31 ` Kevin Hilman
2012-10-12 14:31 ` Kevin Hilman
[not found] ` <87lifb7odc.fsf-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
2012-10-12 14:59 ` Shubhrajyoti [this message]
2012-10-12 14:59 ` Shubhrajyoti
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=50783042.2040609@ti.com \
--to=shubhrajyoti-l0cymroini0@public.gmane.org \
--cc=ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org \
--cc=grygorii.strashko-l0cyMroinI0@public.gmane.org \
--cc=huzefank-l0cyMroinI0@public.gmane.org \
--cc=kalle.jokiniemi-4y2FMlU5MS8onNqTyK5kxQ@public.gmane.org \
--cc=khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
/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.