From mboxrd@z Thu Jan 1 00:00:00 1970 From: jocke@holstenhof.se (Joachim Holst) Date: Thu, 19 May 2011 14:30:18 +0200 Subject: Putting artificial delays in a char driver In-Reply-To: References: Message-ID: <201105191430.19320.jocke@holstenhof.se> To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org On Thursday 19 May 2011 13:30:33 Mandeep Sandhu wrote: > Hi All, > > Whats the recommended way of solving this issue? I'm working on > drivers after a really long time (last time I worked on a driver was > when LDD 2nd ed was published!) so I'm not sure if bottom-halves or > work-queues should be used. Regarding bottom/top halves, modern 2.6 kernels have so called threaded interrupts. This basically means that when an IRQ is triggered, the ISR is already executing in a thread. So, if you use threaded IRQ's you don't quite have to worry about bottom/top halves of old. You can even use mutexes (not spinlocks) in the ISR. I believe that the threaded interrupts will generate some small delay before the ISR is executed, but if memory serves me right it's basically too small to matter in the most cases. May the list correct me if I'm wrong... > > I was thinking what if I introduce an artificial delay in my driver > where I "sleep/wait" for a few millsecs after switching on the LED and > then switch it off after the incoming data has been processed. Is that > a good idea? I think that the solution described by Felix Varghese, is a quite good solution. By triggering the timer in the ISR function, it will be lit constantly if there is very much IR communications going on. BRs, /Jocke!