Re: Atomicity in GPIO pin changes

Benjamin Walsh <benjamin.walsh@...>

On Fri, Aug 26, 2016 at 12:10:40PM +0100, Jon Medhurst (Tixy) wrote:

I have a hardware register I want to change individual bits in as they
are used for different purposes on my SoC. I thought the GPIO APIs might
be the correct abstraction to represent that, and even if that wasn't
suitable I thought I could at least look at those to work out how
atomicity of updates is achieved (Zephyr doesn't seem to have spinlocks,
and mutexes and the like seem a bit heavyweight for the task, ...).
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.

A mutex is indeed too heavy for this, and they're currently not usable
by fibers (upcoming change in the unified kernel as well). A nanokernel
semaphore might be a good fit. Or interrupt locking.

However, looking at the GPIO API's and various implementations I can't
spot anything that serialises register updates, it just seems to boil
down to an unsafe "port |= (1 << bit_to_set)" or similar. Have I missed
things or is it expected that all users of a given port agree on a
mutual exclusion method? That doesn't seem very practical if they are
each different drivers or apps with no real need to know of each others

Join to automatically receive all group messages.