All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Pelletier <plr.vincent@gmail.com>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: linux-leds@vger.kernel.org, Simon Guinot <simon.guinot@sequanux.org>
Subject: Re: leds-gpio on x86
Date: Tue, 18 Aug 2015 13:38:50 +0200	[thread overview]
Message-ID: <20150818133850.42bb31cf@x2> (raw)
In-Reply-To: <20150818090216.GG1552@lahna.fi.intel.com>

(CC'ing gpio-f7188x author)

Discussion summary:
I'm writing a minimal platform driver, declaring 8 GPIO leds and 2 GPIO
input keys. When setting two leds to blink ("timer" trigger) in very
short succession (ie, enable both next to each other in shell script),
kernel emits:

[ 1210.586990] Trying to free nonexistent resource <000000000000002e-000000000000002f>
[ 1211.227414] Trying to free nonexistent resource <000000000000002e-000000000000002f>
[ 1211.867890] Trying to free nonexistent resource <000000000000002e-000000000000002f>
[ 1212.508299] Trying to free nonexistent resource <000000000000002e-000000000000002f>
[ 1213.148734] Trying to free nonexistent resource <000000000000002e-000000000000002f>
[ 1213.789172] Trying to free nonexistent resource <000000000000002e-000000000000002f>
[ 1214.429607] Trying to free nonexistent resource <000000000000002e-000000000000002f>

This is with 500ms on & 500ms off, which matches the aproximate 2
lines/s from this log.
This error goes away when running on a single core.
2e-2f is the f7188x GPIO address range.

On Tue, 18 Aug 2015 12:02:16 +0300, Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
> 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.

There several modules which are using the same two IO addresses for the
many function the SuperIO has, I assumed acquiring the IO range would
prevent them to do any access once the first is loaded.

But as you point out, it seem to not be the case. I also noticed the
fintek-cir driver (for IR sensor, also managed by GPIO) calls
request_region in .probe and release_region() in .remove, which also
goes in this direction.

Regards,
-- 
Vincent Pelletier

  reply	other threads:[~2015-08-18 11:38 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-05 20:09 leds-gpio on x86 Vincent Pelletier
2015-08-06 16:59 ` Mika Westerberg
2015-08-06 17:17   ` Vincent Pelletier
2015-08-06 17:35     ` Mika Westerberg
2015-08-06 18:18       ` Vincent Pelletier
2015-08-07 10:57         ` Mika Westerberg
2015-08-08 12:06           ` Vincent Pelletier
2015-08-11 12:00             ` Mika Westerberg
2015-08-11 17:42               ` Vincent Pelletier
2015-08-12 12:53                 ` Mika Westerberg
2015-08-15 10:36                   ` Vincent Pelletier
2015-08-17 21:08                     ` Vincent Pelletier
2015-08-18  7:32                       ` Vincent Pelletier
2015-08-18  9:02                         ` Mika Westerberg
2015-08-18 11:38                           ` Vincent Pelletier [this message]
2015-08-18 22:56                             ` Vincent Pelletier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150818133850.42bb31cf@x2 \
    --to=plr.vincent@gmail.com \
    --cc=linux-leds@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=simon.guinot@sequanux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.