moving this thread from the vdr mailing list...
On Donnerstag 16 Juni 2005 12:11, Dr. Werner Fink wrote:
> One problem I see is stopping a running replay. After
> receiving and executing the __Stop request the firmware
> goes two steps: first it waits on a free TX slot, if it
> get one it performs an empty TX request
> (debitype = DATA_MPEG_PLAY and debilen = 0 -> gpioirq()).
> Note if the command and OSD queue is filled there is a
> delay between receiving and executing commands.
>
> Now you can slow down this two steps by Bitmap uploads
> and if the firmware is receiving a __Play or __Stop
> and executing this within those two steps the __Play
> or __Stop commands are simply lost (which maybe leads
> t oa wrong state in the driver).
Like this?
Thread A: __Stop, waits for free TX slot
Thread B: __Stop or __Play, request is thrown away
Thread A: gets free TX slot
In thread B, will the firmware throw away the request
silently, or will it return -EAGAIN or whatever? If
it returns -EAGAIN, could this be used as a quickfix
instead of a wait queue? Just to try if this helps
__Stop
do {
msleep(1)
__Stop
} while -EAGAIN
--
Wolfgang
