From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Thomas Gleixner <tglx@linutronix.de>, Tony Lindgren <tony@atomide.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Sebastian Reichel <sebastian.reichel@collabora.co.uk>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
Pavel Machek <pavel@ucw.cz>,
Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [GIT pull] irq updates for 4.13
Date: Tue, 11 Jul 2017 10:39:34 -0500 [thread overview]
Message-ID: <b84a42bf-f4e5-8fe1-0798-a7cee72d116a@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1707111636180.1799@nanos>
On 07/11/2017 09:41 AM, Thomas Gleixner wrote:
> On Tue, 11 Jul 2017, Tony Lindgren wrote:
>> * Thomas Gleixner <tglx@linutronix.de> [170711 02:48]:
>> And "external abort on non-linefetch" means something is not clocked
>> in this case. The following alone makes things boot for me again, but I don't
>> quite follow what has now changed with the ordering.. Thomas, any ideas?
>
> Ah. Now that makes sense.
>
> Unpatched the ordering is:
>
> chip_bus_lock(desc);
> irq_request_resources(desc);
>
> Now the offending change reordered the calls. OMAP gpio has:
>
> omap_gpio_irq_bus_lock()
> pm_runtime_get_sync(bank->chip.parent);
>
> So that at least explains the error. So that omap gpio irq chip (ab)uses
> the bus_lock() callback to do runtime power management. Sigh, I did not
> expect that. Let me have a deeper look if that's OMAP only or whether this
> happens in other places as well.
It was the only one way to power on GPIO bank when the first GPIO IRQ is requested,
as all other irqchip callbacks are under raw_lock while pm_runtime uses spinlock, as
result on -RT it was not possible to use PM runtime in other irqchip callbacks.
Now, I think, It might be possible to use irq_chip_pm_get(), but there is one problem -
OMAP Power management platform code can call omap2_gpio_prepare_for_idle()/omap2_gpio_resume_after_idle()
which expected to disable GPIO banks using PM runtime and current driver implementation
expect to have PM runtime usage_count = 1.
Tony, Potentially we can use pm_runtime_force_suspend()/resume() there, but they are not compatible with
irqoff context (CPUIdle late stages).
In other words, below patch should fix this issue, but will break CPUIdle on OMAP :(
--
>From dfca1c806f03ad6bdd72b634d71c96d39bda2046 Mon Sep 17 00:00:00 2001
From: Grygorii Strashko <grygorii.strashko@ti.com>
Date: Tue, 11 Jul 2017 10:36:23 -0500
Subject: [PATCH] gpio: omap: switch to use irq_chip_pm_get/put()
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
drivers/gpio/gpio-omap.c | 23 +----------------------
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index ba58c8b..b614475 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -787,26 +787,6 @@ static void omap_gpio_irq_shutdown(struct irq_data *d)
raw_spin_unlock_irqrestore(&bank->lock, flags);
}
-static void omap_gpio_irq_bus_lock(struct irq_data *data)
-{
- struct gpio_bank *bank = omap_irq_data_get_bank(data);
-
- if (!BANK_USED(bank))
- pm_runtime_get_sync(bank->chip.parent);
-}
-
-static void gpio_irq_bus_sync_unlock(struct irq_data *data)
-{
- struct gpio_bank *bank = omap_irq_data_get_bank(data);
-
- /*
- * If this is the last IRQ to be freed in the bank,
- * disable the bank module.
- */
- if (!BANK_USED(bank))
- pm_runtime_put(bank->chip.parent);
-}
-
static void omap_gpio_ack_irq(struct irq_data *d)
{
struct gpio_bank *bank = omap_irq_data_get_bank(d);
@@ -1168,10 +1148,9 @@ static int omap_gpio_probe(struct platform_device *pdev)
irqc->irq_unmask = omap_gpio_unmask_irq,
irqc->irq_set_type = omap_gpio_irq_type,
irqc->irq_set_wake = omap_gpio_wake_enable,
- irqc->irq_bus_lock = omap_gpio_irq_bus_lock,
- irqc->irq_bus_sync_unlock = gpio_irq_bus_sync_unlock,
irqc->name = dev_name(&pdev->dev);
irqc->flags = IRQCHIP_MASK_ON_SUSPEND;
+ irqc->parent_device = dev;
bank->irq = platform_get_irq(pdev, 0);
if (bank->irq <= 0) {
--
2.10.1
--
regards,
-grygorii
next prev parent reply other threads:[~2017-07-11 15:40 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-09 8:49 Thomas Gleixner
2017-07-10 13:35 ` Sebastian Reichel
2017-07-10 17:01 ` Linus Torvalds
2017-07-10 19:38 ` Pavel Machek
2017-07-10 20:15 ` Sebastian Reichel
2017-07-10 21:29 ` Linus Torvalds
2017-07-11 6:55 ` Thomas Gleixner
2017-07-11 9:26 ` Sebastian Reichel
2017-07-11 9:55 ` Thomas Gleixner
2017-07-11 10:52 ` Thomas Gleixner
2017-07-11 11:21 ` Sebastian Reichel
2017-07-11 13:27 ` Thomas Gleixner
2017-07-11 13:51 ` Marc Zyngier
2017-07-11 14:39 ` Sebastian Reichel
2017-07-11 9:47 ` Thomas Gleixner
2017-07-11 13:51 ` Tony Lindgren
2017-07-11 14:41 ` Thomas Gleixner
2017-07-11 15:07 ` Thomas Gleixner
2017-07-11 15:43 ` Tony Lindgren
2017-07-11 15:39 ` Grygorii Strashko [this message]
2017-07-11 16:17 ` Tony Lindgren
2017-07-12 8:00 ` Geert Uytterhoeven
2017-07-11 15:40 ` Linus Torvalds
2017-07-11 16:14 ` Sebastian Reichel
2017-07-11 16:15 ` Tony Lindgren
2017-07-11 17:17 ` Thomas Gleixner
2017-07-11 17:39 ` Tony Lindgren
2017-07-11 16:19 ` Thomas Gleixner
2017-07-11 16:31 ` Linus Torvalds
2017-07-11 17:52 ` Thomas Gleixner
2017-07-11 18:16 ` Linus Torvalds
2017-07-11 21:30 ` Sebastian Reichel
2017-07-11 21:41 ` Thomas Gleixner
2017-07-11 22:04 ` Linus Torvalds
2017-07-11 22:51 ` Sebastian Reichel
2017-07-12 5:29 ` Tony Lindgren
2017-07-15 20:24 ` Pavel Machek
2017-07-17 6:21 ` Tony Lindgren
2017-07-17 20:01 ` Linus Torvalds
2017-07-17 21:33 ` Pavel Machek
2017-07-11 16:34 ` Tony Lindgren
2017-07-11 14:41 ` Sebastian Reichel
2017-07-11 16:20 ` Tony Lindgren
2017-07-11 16:34 ` Sebastian Reichel
-- strict thread matches above, loose matches on Subject: below --
2017-07-03 7:42 Thomas Gleixner
2017-07-04 0:00 ` Linus Torvalds
2017-07-04 8:12 ` Thomas Gleixner
2017-07-04 10:29 ` Thomas Gleixner
2017-07-04 15:17 ` Jens Axboe
2017-07-04 18:34 ` Linus Torvalds
2017-07-04 19:10 ` Thomas Gleixner
2017-07-04 20:48 ` Max Gurtovoy
2017-07-06 13:58 ` Max Gurtovoy
2017-07-04 21:56 ` Jens Axboe
2017-07-05 15:14 ` Christoph Hellwig
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=b84a42bf-f4e5-8fe1-0798-a7cee72d116a@ti.com \
--to=grygorii.strashko@ti.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=pavel@ucw.cz \
--cc=sebastian.reichel@collabora.co.uk \
--cc=tglx@linutronix.de \
--cc=tony@atomide.com \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®