Messages in this thread | | | From | David Brownell <> | Subject | Re: Locking in the (now generic) GPIO infrastructure? | Date | Fri, 6 Jun 2008 13:13:10 -0700 |
| |
On Friday 06 June 2008, Leon Woestenberg wrote: > In fact, on the IXP4xx, gpio_set_value() is just gpio_line_set(),
OK, so the generic GPIO calls are inheriting a locking bug from the older code. Calls to the older stuff should probably start getting phased out.
> so I > think it is valid to understand where the locking should occur (lowest > level, higher level?) > > > most spinlocks to establish its atomicity guarantee; it's > > described as "spinlock-safe", and in distinction to the > > gpio_set_value_cansleep() call which could use a mutex or > > other sleeping synch primitive. > > > > So, the solution (for the upstream work on -rt) would be to add > spinlock protection to gpio_line_set(), mutex protection for > _cansleep() variants?
Given this is on -RT, yes it seems like a spinlock is needed to protect against preemption (but not against concurrency, which those XScale chips don't provide).
Though with that addition, the size of that function exceeds what I'd call appropriate to inline.
- Dave
| |