Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: [PATCH 1/3] drivers: misc: add omap_hwspinlock driver | Date | Tue, 19 Oct 2010 22:58:27 +0200 |
| |
On Tuesday 19 October 2010 22:43:34 Ohad Ben-Cohen wrote: > > Disabling irqs might be a concern as a source of RT latency. It > > might be better to make the caller responsible for managing local spin > > locks and irq disable/enable. > > This a coming from an hardware requirement, rather than a choice the > user should take. > > If a hwspinlock is taken over a long period of time, its other user > (with which we try to achieve synchronization) might be polling the > OMAP interconnect for too long (trying to take the hwspinlock) and > thus preventing it to be used for other transactions.
This sounds exactly like any other spinlock.
> To prevent such lengthy polling on the interconnect, the hwspinlock > should only be used for very short period of times, with preemption > and interrupts disabled.
Interrupts disabled in general might go a bit too far -- they are also short and infrequent events unless you have seriously broken drivers.
When running with CONFIG_PREEMPT, I would guess you actually want to turn the omap_hwspinlock into a sleeping operation, though that would require much extra work to implement. Disabling preemption while the hwspinlock is held is of course a correct implementation technically, but it might not be what someone enabling CONFIG_PREEMPT expects.
> That's why we don't give users the choice whether to disable > interrupts or not - it's simply not a decision they should take.
What about those cases where you already know that interrupts are disabled, e.g. while holding a regular spin_lock_irq or inside of an interrupt handler?
Arnd
| |