Re: [PATCH 07/19] gpio: bcm-kona: make use of raw_spinlock variants
From: Julia Cartwright
Date: Fri Mar 10 2017 - 14:36:01 EST
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
> Is such API use change well accepted by the open source community
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.
Description: PGP signature