Re: Atomicity in GPIO pin changes


Jon Medhurst (Tixy) <tixy@...>
 

On Fri, 2016-08-26 at 17:18 +0200, Maciek Borzecki wrote:
On Fri, Aug 26, 2016 at 4:57 PM, Jon Medhurst (Tixy) <tixy(a)linaro.org> wrote:
On Fri, 2016-08-26 at 10:32 -0400, Benjamin Walsh wrote:
Spinlocks don't give you anything more than interrupt or scheduler
locking in a uniprocessor system with a scheduler like Zephyr's, since
you need to lock interrupts and/or scheduling as well when you're holing
them or there is a good chance you'll deadlock. You probably want just
interrupt or scheduler locking instead. Scheduler locking is coming up
in the upcoming unified kernel, but is not available at the moment;
interrupt locking is of course available.
I figured that interrupt locking was the way to go, was just wary of it
since it would break with SMP. Guess when that arrives all interrupt
disabling will need to be audited and converted to spinlocks if
appropriate.

That still leaves the issue that current GPIO drivers look dodgy without
any locking.
Not entirely. A particular SoC may provide means of setting/resetting
GPIO in an atomic fashion. Driver implementation should use such
mechanism if present.

For instance, STM32 GPIO peripheral has 2 dedicated bit set/reset
registers (GPIOx_BSRR/BRR) that allow for switching individual line
states in an atomic fashion. In this case, the driver does not perform
an intermediate read, but rather writes a desired value to the
register.
Thanks. I can see stm32 is OK in this regard, none of the others appear
to be.

I'll use interrupt disabling for my code to make it safe until SMP
arrives.

--
Tixy

Join devel@lists.zephyrproject.org to automatically receive all group messages.