From: khilman@kernel•org (Kevin Hilman)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v2 7/7] ARM: smp: Add runtime PM support for CPU hotplug
Date: Tue, 08 Sep 2015 15:03:52 -0700 [thread overview]
Message-ID: <7h613kmuuv.fsf@deeprootsystems.com> (raw)
In-Reply-To: <55EE9AA1.8020200@ti.com> (Grygorii Strashko's message of "Tue, 8 Sep 2015 11:21:53 +0300")
Grygorii Strashko <grygorii.strashko@ti•com> writes:
> On 09/07/2015 11:42 PM, Rafael J. Wysocki wrote:
>> On Monday, September 07, 2015 04:37:44 PM Grygorii Strashko wrote:
>>> On 09/07/2015 04:04 PM, Rafael J. Wysocki wrote:
>>>> On Saturday, September 05, 2015 11:39:20 AM Alan Stern wrote:
>>>>> On Sat, 5 Sep 2015, Grygorii Strashko wrote:
>>>>>
>>>>>> On 09/04/2015 09:45 PM, Alan Stern wrote:
>>>>>>> On Fri, 4 Sep 2015, Grygorii Strashko wrote:
>>>>>>>
>>>>>>>> There is one "small" problem with such approach :(
>>>>>>>>
>>>>>>>> - It's incompatible with -RT kernel, because PM runtime can't be used
>>>>>>>> in atomic context on -RT.
>>>>>>>
>>>>>>> Can you explain this more fully? Why can't runtime PM be used in
>>>>>>> atomic context in the -rt kernels?
>>>>>>>
>>>>>>
>>>>>> See:
>>>>>> http://lwn.net/Articles/146861/
>>>>>> https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#How_does_the_CONFIG_PREEMPT_RT_patch_work.3F
>>>>>>
>>>>>> spinlock_t
>>>>>> Critical sections are preemptible. The _irq operations (e.g., spin_lock_irqsave())
>>>>>> do -not- disable hardware interrupts. Priority inheritance is used to prevent priority
>>>>>> inversion. An underlying rt_mutex is used to implement spinlock_t in PREEMPT_RT.
>>>>>>
>>>>>> As result, have to do things like:
>>>>>> https://lkml.org/lkml/2015/8/18/161
>>>>>> https://lkml.org/lkml/2015/8/18/162
>>>>>>
>>>>>> Sorry for brief reply - Friday/Sat night :)
>>>>>
>>>>> I see. Although we normally think of interrupt contexts as being
>>>>> atomic, in an -rt kernel this isn't true any more because things like
>>>>> spin_lock_irq don't actually disable interrupts.
>>>>>
>>>>> Therefore it would be correct to say that in -rt kernels, runtime PM
>>>>> can be used in interrupt context (if the device is marked as irq-safe),
>>>>> but not in atomic context. Right?
>>>>
>>>> Right.
>>>>
>>>> Whatever is suitable for interrupt context in the mainline, will be suitable
>>>> for that in -rt kernels too.
>>>
>>> Not exactly true :(, since spinlock is converted to [rt_] mutex.
>>> Usually, this difference can't be seen because on -RT kernel all or
>>> mostly all HW IRQ handlers will be forced to be threaded.
>>
>> Exactly. And that's what I'm talking about.
>>
>>> For the cases, where such automatic conversion is not working,
>>> (like chained irq handlers or HW-handler+Threaded handler) the code
>>> has to be carefully patched to work properly as for non-RT as for -RT.
>>
>> Right.
>>
>>> Also, this triggers some -RT incompatibility issues, like with PM runtime or
>>
>> That I'm not sure about. Why would runtime PM cause problems with -RT (apart
>> from attempts to use it from the idle loop, but that's not happening in the
>> mainline anyway)?
>
>
> I have to be more specific - sorry. "irq_safe" mode of PM runtime is incompatible with -RT.
>
> Here is an example:
> - HW IRQ handler in TI OMAP GPIO driver is implemented as chained IRQ handler and
> contains pm_runtime_get_sync()/pm_runtime_put(). This works properly with vanilla kernel
> because OMAP GPIO devices marked as irq_safe.
> Chained IRQ handlers can't be forced threaded and PM runtime APIs trigger
> "sleeping function called from invalid context" issues there, so corresponding code has to be reworked.
Isn't that why those are being converted to raw_*[1] ?
Kevin
[1] http://marc.info/?l=linux-omap&m=143749603401221&w=2
next prev parent reply other threads:[~2015-09-08 22:03 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-03 19:58 [PATCH v2 0/7] PM / Domains: Generic PM domains for CPUs/Clusters Lina Iyer
2015-09-03 19:58 ` [PATCH v2 1/7] PM / Domains: Allocate memory outside domain locks Lina Iyer
2015-09-03 19:58 ` [PATCH v2 2/7] PM / Domains: Support IRQ safe PM domains Lina Iyer
2015-09-04 10:02 ` Ulf Hansson
2015-09-04 16:05 ` Lina Iyer
2015-10-01 21:11 ` Geert Uytterhoeven
2015-09-03 19:58 ` [PATCH v2 3/7] drivers: cpu: Define CPU devices as IRQ safe Lina Iyer
2015-09-04 4:00 ` Stephen Boyd
2015-09-03 19:58 ` [PATCH v2 4/7] PM / Domains: Introduce PM domains for CPUs/clusters Lina Iyer
2015-09-04 3:54 ` Stephen Boyd
2015-09-03 19:58 ` [PATCH v2 5/7] ARM: cpuidle: Add runtime PM support for CPU idle Lina Iyer
2015-09-03 19:58 ` [PATCH v2 6/7] ARM64: smp: Add runtime PM support for CPU hotplug Lina Iyer
2015-09-30 12:36 ` Geert Uytterhoeven
2015-09-03 19:58 ` [PATCH v2 7/7] ARM: " Lina Iyer
2015-09-04 3:59 ` Stephen Boyd
2015-09-04 15:13 ` Lina Iyer
2015-09-04 7:39 ` Geert Uytterhoeven
2015-09-04 9:17 ` Russell King - ARM Linux
2015-09-04 9:27 ` Russell King - ARM Linux
2015-09-04 15:12 ` Lina Iyer
2015-09-04 16:23 ` Russell King - ARM Linux
2015-09-04 17:02 ` Lina Iyer
2015-09-04 17:46 ` Russell King - ARM Linux
2015-09-04 17:57 ` Grygorii Strashko
2015-09-04 18:45 ` Alan Stern
2015-09-04 21:46 ` Grygorii Strashko
2015-09-05 15:39 ` Alan Stern
2015-09-07 13:04 ` Rafael J. Wysocki
2015-09-07 13:37 ` Grygorii Strashko
2015-09-07 20:42 ` Rafael J. Wysocki
2015-09-08 8:21 ` Grygorii Strashko
2015-09-08 22:03 ` Kevin Hilman [this message]
2015-09-10 11:01 ` Grygorii Strashko
2015-09-22 17:32 ` Lina Iyer
2015-09-22 20:53 ` Thomas Gleixner
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=7h613kmuuv.fsf@deeprootsystems.com \
--to=khilman@kernel$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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