Messages in this thread | | | Date | Thu, 15 Nov 2007 09:43:00 +0100 | From | Haavard Skinnemoen <> | Subject | Re: [patch 2.6.24-rc2 1/3] generic gpio -- gpio_chip support |
| |
On Wed, 14 Nov 2007 22:50:17 -0800 David Brownell <david-b@pacbell.net> wrote:
> > Since this is the code that runs under the lock > > No, there's more than that. This is what runs under it in > the hot paths, yes, but the gpio request/free paths do > more work than this. (That includes direction setting, > since that can be an implicit request.)
Yeah, I was talking about the hot paths. That's the only place where raw vs. non-raw performance matters.
> The get/set bit calls are the hot paths. Locking on those paths > buys us a consistent locking policy, which is obviously correct. > It's consistent with the request/free paths. > > But I think what you're suggesting is that the "requested" flag > is effectively a long-term lock, so grabbing the spinlock on > those paths is not necessary. Right?
Exactly. If we add two (quite reasonable) restrictions: * The GPIO framework must ensure that GPIO chips cannot be removed when one or more pins have been assigned to a client. * The client must ensure that it never calls gpio_free() simultaneously with gpio_[sg]et_value(), adding locking of its own if necessary.
this should be safe.
Håvard - 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/
| |