[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201010192308.02018.arnd@arndb.de>
Date: Tue, 19 Oct 2010 23:08:01 +0200
From: Arnd Bergmann <arnd@...db.de>
To: linux-arm-kernel@...ts.infradead.org
Cc: "Ohad Ben-Cohen" <ohad@...ery.com>,
Hari Kanigeri <h-kanigeri2@...com>, Suman Anna <s-anna@...com>,
Benoit Cousson <b-cousson@...com>,
Tony Lindgren <tony@...mide.com>, Greg KH <greg@...ah.com>,
linux-kernel@...r.kernel.org,
Grant Likely <grant.likely@...retlab.ca>,
akpm@...ux-foundation.org, linux-omap@...r.kernel.org,
"Krishnamoorthy, Balaji T" <balajitk@...com>
Subject: Re: [PATCH 1/3] drivers: misc: add omap_hwspinlock driver
On Tuesday 19 October 2010 22:51:22 Ohad Ben-Cohen wrote:
> >, which is generally discouraged
> > in all places where you know if you need to disable interrupts or not.
> >
> > IMHO the default should be a version that only allows locks that don't get
> > taken at IRQ time and consequently don't require saving the interrupt flags.
>
> Please note that the hwspinlocks should never be used to achieve
> synchronization with Linux contexts running on the same cpu - it's
> always about achieving mutual exclusion with a remote processor.
Ok, I see.
> So whether the lock is taken at IRQ time or not does not affect the
> requirement to disable interrupts while it is taken (very differently
> from local spin_lock{_irqsave} synchronizations).
Right. There are two more things to consider though:
If you know that interrupts are disabled, you may still want to avoid
having to save the interrupt flag to the stack, to save some cycles
saving and restoring it. I don't know how expensive that is on ARM,
some other architectures take an microseconds to restore the interrupt
enabled flag from a register.
Even in the case where you know that interrupts are enabled, you may
want to avoid saving the interrupt flag to the stack, the simpler
API (one argument instead of two) gives less room for screwing up.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists