Putting artificial delays in a char driver

Putting artificial delays in a char driver

[Mandeep Sandhu]

Hi All,

I was fiddling around with an IR remote driver for my embedded
platform to see if I can make the IR LED light (connected to GPIO's)
blink on IR activity.

The IR driver behaves like a char driver. The way to make the LED
on/off is to simply write to some GPIO reg with a 1/0. So I was
switching on the LED at the beginning of the function that reads data
(in ISR context) and then switching it off at the end of that
function.

The problem was that all this happens too fats and I'm barely able to
see the LED blink (there's only a faint flicker)! :)

I tired various places in the driver to keep on/off calls as "far" as
possible (ON in ISR and then OFF _after_ a copy_to_user()), but that
did not help much.

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.

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?

TIA,
-mandeep

Putting artificial delays in a char driver

[Felix Varghese]

Hi,

I can't say I have understood your scenario completely. Maybe you
could turn your LED on when you want to (say in the ISR) and then
start a kernel timer of sufficient duration. In the timer expiry
handler, you could switch it off. By adjusting the duration, you could
make sure that the LED stays on long enough to be visible.

Regards,
Felix.

Putting artificial delays in a char driver

[Joachim Holst]

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!

Putting artificial delays in a char driver

[Mandeep Sandhu]

Thanks Felix.

This looks better than putting a delay in the ISR's execution path.

I've implemented a simple fxn to be called by a timer after 10ms and
it looks fine..as in I can see the LED blink! :)

Thanks,
-mandeep

On Thu, May 19, 2011 at 5:21 PM, Felix Varghese <felixv1986@gmail.com> wrote:
> Hi,
>
> I can't say I have understood your scenario completely. Maybe you
> could turn your LED on when you want to (say in the ISR) and then
> start a kernel timer of sufficient duration. In the timer expiry
> handler, you could switch it off. By adjusting the duration, you could
> make sure that the LED stays on long enough to be visible.
>
> Regards,
> Felix.
>

Putting artificial delays in a char driver

[Mandeep Sandhu]

> 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.

Thanks for pointing this out. Didn't we now have threader IRQs! Nice.

> 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.

True. Using timers now. It's quite simple to use and looks
clean...plus my fxn that toggles the LED states are quite simple/basic
and have no resource locking requirements so no worries of race cond's
too.

Thanks,
-mandeep

>
> BRs,
> /Jocke!
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>