On Fri, Mar 10, 2017 at 09:28:08AM -0800, Ray Jui wrote: > Hi Julia/Linus, > > On 3/9/2017 8:21 AM, Julia Cartwright wrote: > > The bcm-kona gpio driver currently implements an irq_chip for handling > > interrupts; due to how irq_chip handling is done, it's necessary for the > > irq_chip methods to be invoked from hardirq context, even on a a > > real-time kernel. Because the spinlock_t type becomes a "sleeping" > > spinlock w/ RT kernels, it is not suitable to be used with irq_chips. > > > > A quick audit of the operations under the lock reveal that they do only > > minimal, bounded work, and are therefore safe to do under a raw spinlock. > > This is new to me. But it seems like, for the vast majority cases, user > can still continue to use spin_lock as it is without needing to worry > about the underlying difference between standard or RT kernels. If by "user" you mean, "driver developer", then yes. For most driver authors, the distinction between raw and non-raw spinlocks is irrelevant, they can use spinlocks and everything will work out just fine w/ mainline and on RT. > But in certain cases, e.g., irq_chips, extra care needs to be done, > i.e., swtching to use raw spin lock to make sure that it is not > blocking in the case of RT. Correct, on RT the goal is to push as much as possible into a preemptible context, including driver interrupts, etc. However, there are still codepaths which necessarily need to be executed in hardirq context, including anything necessary to support scheduling. This includes: interrupt-dispatching (irq_chips), timers, and the scheduler itself, which is why this "core" code must use the raw spinlock variants. > Is such API use change well accepted by the open source community > already? In what way is this an API change? The API isn't changing, what's changing in this patch is to fix what is an irq_chip implementation which is _currently broken_ on RT. Julia
Attachment:
signature.asc
Description: PGP signature
