On Mon, Feb 17, 2003 at 11:54:55AM +0100, Ralph Metzler wrote:
Hi,
Emard writes:
> I was thinking of a possible workaround in higher layers.
> So the current problem is:
>
> 1. irq tasklet constantly uses sw_demux
>
> 2. applications want to change sw_demux parameters in
> runtime
>
> 3. if applicatons use semaphore lock for sw_demux and
> tasklet attempts to execute (too long ?) locked
> sw_demux machine will freeze
>
> So I (foggy) see 2 ways out of this:
>
> WAY 1
>
> Have a copy of all sw_demux related structures.
> Applications will change it at will, and have semaphores
> to differentiate one from another, but not from the tasklet.
>
> When application changes the sw_demux, it will keep it
> locked and inform tasklet that changes have been done
> by incrementing one byte somewhere in the tasklet readable
> data. Tasklet will it its new IRQ cycle copy sw_demux stuff
> to its active profile and somehow send application the message
> that it has accepted the setting so lock can be removed.
>
>
> WAY 2
>
> Have some queue of small changes commited to sw_demux but
> not yet applied. When tasklet executes its next IRQ, it will
> go through the queue, applying changes to sw_demux structures
> and use there. Mutual locking of the queue may be tricky.
But this will not work with the big cards. They need to sleep
when talking to the AV7110 and waiting for reply.
A tasklet cannot sleep.
This would even be the case if you change the communication
with the AV7110 to use some kind of message queues because
filter setting needs a response.
Other cards with a separate processor will need that too.
Sleeping in the kernel is as well not acceptable even if
tasklet could sleep, it will jitter the machine.
How about making an userspace daemon that will actually talk
to av7110 and feed back data to kernel?
Kernel driver would provide only saa7146 transport interface.
?!?