From: tony@atomide•com (Tony Lindgren)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v2 1/4] drivers: hwspinlock: add generic framework
Date: Tue, 30 Nov 2010 11:00:58 -0800 [thread overview]
Message-ID: <20101130190058.GX17222@atomide.com> (raw)
In-Reply-To: <1290526740-27624-2-git-send-email-ohad@wizery.com>
* Ohad Ben-Cohen <ohad@wizery•com> [101123 07:27]:
> Add a common, platform-independent, hwspinlock framework.
>
> Hardware spinlock devices are needed, e.g., in order to access data
> that is shared between remote processors, that otherwise have no
> alternative mechanism to accomplish synchronization and mutual exclusion
> operations.
<snip>
> + int hwspin_lock(struct hwspinlock *hwlock);
> + - lock a previously assigned hwspinlock. If the hwspinlock is already
> + taken, the function will busy loop waiting for it to be released.
> + Note: if a faulty remote core never releases this lock, this function
> + will deadlock.
> + This function will fail only if hwlock is invalid. Otherwise, it will
> + always succeed (or deadlock; see above) and it will never sleep.
> + Upon a successful return from this function, preemption is disabled so
> + the caller must not sleep, and is advised to release the hwspinlock as
> + soon as possible, in order to minimize remote cores polling on the
> + hardware interconnect.
...
> + int hwspin_lock_timeout(struct hwspinlock *hwlock, unsigned long timeout);
> + - lock a previously-assigned hwspinlock with a timeout limit (specified in
> + jiffies). If the hwspinlock is already taken, the function will busy loop
> + waiting for it to be released, but give up when the timeout meets jiffies.
> + If timeout is 0, the function will never give up (therefore if a faulty
> + remote core never releases the hwspinlock, it will deadlock).
> + Upon a successful return from this function, preemption is disabled so
> + the caller must not sleep, and is advised to release the hwspinlock as
> + soon as possible, in order to minimize remote cores polling on the
> + hardware interconnect.
> + Returns 0 when successful and an appropriate error code otherwise (most
> + notably -ETIMEDOUT if the hwspinlock is still busy after timeout meets
> + jiffies). The function will never sleep.
Do we even need the hwspin_lock variants, why can't we always use the
hwspin_lock_timeout variants?
To me the idea of looping waiting for some external system to release
a lock is not a good idea..
Regards,
Tony
next prev parent reply other threads:[~2010-11-30 19:00 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-23 15:38 [PATCH v2 0/4] Introduce common hardware spinlock interface Ohad Ben-Cohen
2010-11-23 15:38 ` [PATCH v2 1/4] drivers: hwspinlock: add generic framework Ohad Ben-Cohen
2010-11-24 7:44 ` Kamoolkar, Mugdha
2010-11-24 19:59 ` Ohad Ben-Cohen
2010-11-25 3:59 ` David Brownell
2010-11-25 6:40 ` Ohad Ben-Cohen
2010-11-25 20:22 ` David Brownell
2010-11-26 7:34 ` Ohad Ben-Cohen
2010-11-27 1:24 ` David Brownell
2010-11-29 9:57 ` Ohad Ben-Cohen
2010-11-25 6:05 ` Kamoolkar, Mugdha
2010-11-25 14:29 ` Ohad Ben-Cohen
2010-11-26 4:59 ` Olof Johansson
2010-11-26 7:18 ` Grant Likely
2010-11-26 21:00 ` Olof Johansson
2010-11-26 8:53 ` Ohad Ben-Cohen
2010-11-26 9:18 ` Russell King - ARM Linux
2010-11-26 10:16 ` Ohad Ben-Cohen
2010-11-26 10:45 ` Russell King - ARM Linux
2010-11-26 22:18 ` Ohad Ben-Cohen
2010-11-26 22:53 ` Russell King - ARM Linux
2010-11-29 9:46 ` Ohad Ben-Cohen
2010-11-26 22:51 ` Olof Johansson
2010-11-29 21:31 ` Ohad Ben-Cohen
2010-11-30 19:00 ` Tony Lindgren [this message]
2010-11-30 22:20 ` Ohad Ben-Cohen
2010-11-30 22:23 ` Tony Lindgren
2010-11-23 15:38 ` [PATCH v2 2/4] drivers: hwspinlock: add OMAP implementation Ohad Ben-Cohen
2010-11-23 23:23 ` Ionut Nicu
2010-11-24 10:33 ` Ohad Ben-Cohen
2010-11-23 15:38 ` [PATCH v2 3/4] OMAP4: hwmod data: Add hwspinlock Ohad Ben-Cohen
2010-11-23 15:39 ` [PATCH v2 4/4] omap: add hwspinlock device Ohad Ben-Cohen
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=20101130190058.GX17222@atomide.com \
--to=tony@atomide$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox