lkml.org 
[lkml]   [2008]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Locking in the (now generic) GPIO infrastructure?
    Date
    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



    \
     
     \ /
      Last update: 2008-06-06 22:15    [W:0.042 / U:91.012 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site