Re: Atomicity in GPIO pin changes


Benjamin Walsh <benjamin.walsh@...>
 

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

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
existence.

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