Hi Inaky,
On Tuesday, 27. February 2007, Inaky Perez-Gonzalez wrote:
> On Monday 26 February 2007 18:18, Alan wrote:
> > > Yeah, I need semaphore. This is a hw register that says when the hw
> > > is ready to accept a new command. Code that wants to send commands has
> > > to down the semaphore and then send it. When hw is ready to get a new
> > > command, it sends and IRQ and the IRQ up()s the semaphore.
> >
> > So you need a mutex not a semaphore
>
> Theoretically I could use a mutex. Practically it would trigger ugly
> complications. Only the owner can unlock a mutex (for example), so
> I could not unlock from an IRQ handler -- not to mention that the
> semantic rules outlined in Documentation/mutex-design.txt explicitly
> forbid IRQ usage.
>
> And then, this is what semaphores where designed for, as gates :)
> for once that I get to use a semaphore properly...
But they are not required for that :-)
I would suggest to use an irq-safe spinlock for the hardware access
and a status indicator (ready for command), if this is really just a command
register.
If the status indicator is updated (in IRQ) and read under spinlock, that is
safe.
If that command sending is speed critical, please try a FIFO and batch that
stuff.
Timeout based locking mechanisms are flawed, because they introduce the hard to
find
timing sensitive bugs.
Please try sth. different (e.g. like suggested above).
Semaphores aren't good "busy/ready flags", as you might have already noticed.
Many Thanks and Best Regards
Ingo Oeser, the down{_interruptible,}_timeout() implementation of Linux :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
