Hello,
I'm converting an out-of-tree (*1) driver from binary semaphore to mutex.
Userspace updates a look-up-table using write(). The driver tries to
write this LUT to the FPGA in the (video frame) interrupt handler. It
is important that the LUT is consistent and thus changed atomically.
Note that it is not important that the LUT is updated each interrupt.
The current approach is to try-down()ing a binary semaphore in
interrupt context, and write the LUT to the FPGA if the semaphore was
down()ed, do nothing else.
The write() down()s the semaphore as well before updating the
in-driver-copy of the LUT, then up()s it again.
I understand this design is not clean (*2), and not even possible with
mutexes, as mutex_trylock() is not interrupt safe.
My current approach would be to have userspace write into a shadow
copy, and use a spinlock to update the live copy. The interrupt then
would try a spinlock.
My feeling is that we have a valid use of mutex_trylock() in
interrupt context; "i.e. update LUT if we can do so consistently and
in time, or not at all".
I would like to know why this is not so, and if someone has a cleaner
proposal than the "try spinlock" approach?
Regards,
--
Leon
*1: specific to driving a certain FPGA with certain logic. I can post
the source code on request.
*2: http://lkml.org/lkml/2007/6/23/143
Am Donnerstag 22 November 2007 schrieb Leon Woestenberg:
> I would like to know why this is not so, and if someone has a cleaner
> proposal than the "try spinlock" approach?
Keep the semaphore.
Regards
Oliver
Hello,
On Nov 22, 2007 5:11 PM, Oliver Neukum <[email protected]> wrote:
> Am Donnerstag 22 November 2007 schrieb Leon Woestenberg:
> > I would like to know why this is not so, and if someone has a cleaner
> > proposal than the "try spinlock" approach?
>
> Keep the semaphore.
>
I forgot to mention that I would like to be prepared for, and use the
-rt patch soon. I understand (maybe wrongly?) that semaphores are not
real-time pre-emptible, mutexes and spinlocks are.
Regards,
--
Leon
On Thu, 22 Nov 2007 17:19:44 +0100
"Leon Woestenberg" <[email protected]> wrote:
> I forgot to mention that I would like to be prepared for, and use the
> -rt patch soon. I understand (maybe wrongly?) that semaphores are not
> real-time pre-emptible, mutexes and spinlocks are.
Semaphores are preemptible, but they don't do priority inheritance.
Michal
On Thu, 22 Nov 2007 17:02:44 +0100
"Leon Woestenberg" <[email protected]> wrote:
> Hello,
>
>
> I'm converting an out-of-tree (*1) driver from binary semaphore to
> mutex.
>
> Userspace updates a look-up-table using write(). The driver tries to
> write this LUT to the FPGA in the (video frame) interrupt handler. It
> is important that the LUT is consistent and thus changed atomically.
> Note that it is not important that the LUT is updated each interrupt.
>
> The current approach is to try-down()ing a binary semaphore in
> interrupt context, and write the LUT to the FPGA if the semaphore was
> down()ed, do nothing else.
> The write() down()s the semaphore as well before updating the
> in-driver-copy of the LUT, then up()s it again.
>
> I understand this design is not clean (*2), and not even possible with
> mutexes, as mutex_trylock() is not interrupt safe.
>
> My current approach would be to have userspace write into a shadow
> copy, and use a spinlock to update the live copy. The interrupt then
> would try a spinlock.
>
I suspect you need to copy the userspace data anyway, so I don't see
why the spinlock approach would be wrong; if the update itself is short
and non-sleeping, it's even better than a mutex or semaphore.
--
If you want to reach me at my work email, use [email protected]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
Leon Woestenberg wrote:
> Hello,
>
>
> I'm converting an out-of-tree (*1) driver from binary semaphore to mutex.
>
> Userspace updates a look-up-table using write(). The driver tries to
> write this LUT to the FPGA in the (video frame) interrupt handler. It
> is important that the LUT is consistent and thus changed atomically.
> Note that it is not important that the LUT is updated each interrupt.
>
> The current approach is to try-down()ing a binary semaphore in
> interrupt context, and write the LUT to the FPGA if the semaphore was
> down()ed, do nothing else.
> The write() down()s the semaphore as well before updating the
> in-driver-copy of the LUT, then up()s it again.
>
> I understand this design is not clean (*2), and not even possible with
> mutexes, as mutex_trylock() is not interrupt safe.
>
> My current approach would be to have userspace write into a shadow
> copy, and use a spinlock to update the live copy. The interrupt then
> would try a spinlock.
Unless this update into the FPGA takes a significant amount of time, I
wouldn't bother with that complexity - just do spin_lock_irq/irqsave on
that spinlock.
Using a trylock for this rather sucks since the behavior is entirely
non-deterministic. It could take a really long time in some cases for
the trylock to ever succeed.
>
> My feeling is that we have a valid use of mutex_trylock() in
> interrupt context; "i.e. update LUT if we can do so consistently and
> in time, or not at all".
>
> I would like to know why this is not so, and if someone has a cleaner
> proposal than the "try spinlock" approach?
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/