More info from Stephan, thanks! ---------- Forwarded message ---------- From: StephanT <stman937-linewbie@xxxxxxxxx> Date: Fri, Nov 14, 2008 at 2:00 AM Subject: Re: Please suggest a way to synchronize tasklets. To: Peter Teoh <htmldeveloper@xxxxxxxxx> Hi there, > q1: when u disable it, and it does have something to send, will it > have its own queue and buffer up, so that upon enabling it will DO A > RESENT....? Yes. In fact in my particular case you reason on a per buffer basis. The DSP interrupts to tell you it has a buffer to send. You say "OK I'm going to get it - give me a break". And you spawn the tasklet which will get the buffer and copy it to user space. Now, if the DSP has multiple buffers to send it will queue them and send them one by one. > q2: if it does not resend....then u have losts information (losts > interrupt...or spurious interrupts....missing interrupts etc) correct? It may happen. It is for that there is S/W to deal with. If some information is lost the upper layer will notice it and will ask for a re-send. Just think how tcp secures the exchange. Each frame is numbered and acknowledged. There are T.Outs watching for things to happen... and so on. In my case enable/disable interrupts does not concern Linux at all. I do not ask Linux to disable interrupts - I ask the other part (the DSP) to stop the send process because I'm busy getting what it already sent. When I'm done I tell them: "OK guys, now you can start sending again." :-). My problem is to be _SURE_ re-enabling the send process under the pain of breaking the communication mechanism. Of course the DSP S/W has buffers to keep the information and has a strategy implemented to communicate. H/W and S/W work together to get the job done. have a nice day, /st -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
