On Tue, Aug 18, 2015 at 09:32:26AM +0200, Vincent Pelletier wrote:
> On Mon, 17 Aug 2015 23:08:23 +0200, Vincent Pelletier
> <plr.vincent@xxxxxxxxx> wrote:
> > How can I debug this further ?
>
> I made a bit of progress: disabling all but one cpu (...which, in this
> case, just means disabling the second core) makes the error messages go
> away, and blinking works fine.
>
> There is a lock taken in __request_region, and released around
> schedule() when muxed. I guess this means region request is just pushed
> into a queue when resource is busy, then scheduler is told to let
> whatever else available run.
> I have no idea if the lock should be taken before or after
> remove_wait_queue after schedule call.
For each GPIO operation the f7188x driver calls
superio_enter()/superio_exit().
However, I don't think that is enough to prevent multiple threads
accessing a GPIO at the same time.
One option is to add mutex to the private structure and then do
something like this in each callback:
static int f7188x_gpio_get(...)
{
mutex_lock(&sio->lock);
/* request the resource and touch the hardware */
mutex_unlock(&sio->lock);
...
}
It is a bit weird that it needs to acquire/release the ioport region each
time.
--
To unsubscribe from this list: send the line "unsubscribe linux-leds" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
