[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-kernel
Subject: Re: [PATCH] Document Linux's memory barriers [try #4]
From: Michael Buesch <mbuesch () freenet ! de>
Date: 2006-03-10 0:07:46
Message-ID: 200603100107.46655.mbuesch () freenet ! de
[Download RAW message or body]
On Friday 10 March 2006 00:56, you wrote:
>
> On Fri, 10 Mar 2006, Michael Buesch wrote:
> >
> > So what about:
> >
> > #define spin_lock_mmio(lock) spin_lock(lock)
> > #define spin_unlock_mmio(lock) do { spin_unlock(lock); mmiowb(); } while (0)
>
> You need to put the mmiowb() inside the spinlock.
Ok, sorry. That was a typo.
I should not do more than 3 things at the same time. :)
> Yes, that is painful. But the point being that if it's outside, then when
> somebody else gets the lock, the previous lock-owners MMIO stores may
> still be in flight, which is what you didn't want in the first place.
>
> Anyway, no need to make a new name for it, since you might as well just
> use the mmiowb() explicitly. At least until this has been shown to be a
> really common pattern (it clearly isn't, right now ;)
Ok, so maybe it is best if every device creates its own macros
for convenience (if needed => if it is a common pattern
in the scope of the driver).
Example:
#define bcm43xx_lock(bcm, flags) spin_lock_irqsave(&(bcm)->lock, flags)
#define bcm43xx_unlock(bcm, flags) do { mmiowb(); spin_unlock_irqrestore(&(bcm)->lock, flags); } while (0)
--
Greetings Michael.
[Attachment #3 (application/pgp-signature)]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic