That's one subject of discussion here. I got the expected
knee-jerk responses (saying just that) -- right, ignore those
and aim for ones that look at the actual issues.
Which is why bitops like <asm-generic/bitops/atomic.h> use
normal spinlocks. Oh, wait, no they don't ...
Today, platform GPIO logic has no preemption points.
There are a few dozen implementations in the tree, not all
using the generic calls (yet!), none radically different.
Certainly when gpio_set_value() is inlined, it works very
much like set_bit()/clear_bit() on hardware with atomic ops.
Not a preemption point
But it often turns into a function call that needs to map
from GPIO number to GPIO bank, and then to a bitslice through
that bank's registers. I know of only one platform which
even has any locking on those code paths(*) ... so again
those calls aren't preemption points.
Nope. Just saying that the relevant instructions (three, in the
hot path I looked at, and not a case where priority inversion
scenarios should be a concern) shouldn't be forcibly morphed into
preemption points. Any more than other bitops were (not).
If a higher priority task needs that CPU, nothing prevents it
from being immediately descheduled. Ditto handling a hardirq.
All this does is prevent constant and needless checking for
"do you want to preempt me now?" "now?" "now?" in "now?" the
middle "now?" of "now?" i/o "now?" loops.
This isn't driver code...
I think you've just presented an argument why that stuff
shouldn't really exist in -rt either... :)
- Dave
(*) Exception, arch/arm/plat-omap/gpio.c uses spinlocks.
Maybe I should say "misuses"; ISTR getting various
lockdep complaints about the same spinlock being used
both from IRQ and non-IRQ contexts. In some common
cases that lock could probably be eliminated, but
if you look at the code you'll know why nobody's much
wanted to clean it up.
-
