Question about using spinlock to synchronize between kernel driver and an interrupt handler

[Pranay Srivastava]

On Feb 4, 2014 12:00 AM, "m silverstri" <michael.j.silverstri at gmail.com>
wrote:
>
> Thanks Arun,
>
> But why not just use mutex and remove the completion?
> i.e. do this:
>
> struct mutex dev_lock;
>
> some_func()
> {
> mutex_lock(&dev_lock);
> set_register_value
>
>
> }
>
You'll block all tasks until your handler unlock the mutex.

The idea is to let the tasks block on driver code and let them submit
request to your driver.

This mutex should be private to your driver code and not visible to upper
layer tasks.

> interrupt_handler(){
> mutex_unloc(&dev_lock);
> }

What if the interrupt never happens? Or is lost?.

Whatever your task want to do with device it should be like a private
binding. Like for example the input buffer would be per task and the output
as well.

Your device may handle multiple functions so setting register values should
also be per task. So it can be like each task sets the desired value in the
request structure and when driver gets to this request it would call the
appropriate function to set the values for register. I would recommend
keeping register setting functions private to your driver code and only
expose some integers corresponding to functions provided by your device.

Keeping it clean will help you manage your code.
>
> mutex_init(&dev_lock);
> request_irq(interrupt_handler);
>
> On Mon, Feb 3, 2014 at 1:54 AM, Arun KS <getarunks at gmail.com> wrote:
> > Hi Silverstri,
> >
> >
> > On Sun, Feb 2, 2014 at 1:19 PM, m silverstri
> > <michael.j.silverstri at gmail.com> wrote:
> >>
> >> On Sat, Feb 1, 2014 at 5:34 AM, Josh Cartwright <joshc at eso.teric.us>
> >> wrote:
> >> > On Sat, Feb 01, 2014 at 01:32:49AM -0800, anish singh wrote:
> >> >> On Sat, Feb 1, 2014 at 1:15 AM, m silverstri
> >> >> <michael.j.silverstri at gmail.com> wrote:
> >> >> > By driver code , I mean the code which set the register values and
> >> >> > wait till the values is set (via an interrupt handler) before
> >> >> > continues doing something else
> >> >> ok so you are looking for below code:
> >> >>
> >> >>
> >> >> some_func()
> >> >> {
> >> >> set_register_value
> >> >> x_variable=0
> >> >> wait_for_event*(x_variable);
> >> >> }
> >> >>
> >> >> interrupt_handler(){
> >> >> x_variable=1
> >> >> wake_up();
> >> >> }
> >> >>
> >> >> request_irq(interrupt_handler);
> >> >
> >> > Please investigate the usage of completions in your driver.  See
> >> > include/linux/completion.h.  It sounds like it fits your usecase
nicely.
> >> >
> >> >   Josh
> >>
> >> I have loooked at linux completion for my usecase
> >> So I think I can do
> >>
> >> DECLARE_COMPLETION(my_completion);
> >>
> >> some_func()
> >> {
> >> set_register_value
> >> wait_for_completion(my_completion);
> >> }
> >>
> >> interrupt_handler(){
> >> complete(my_completion);
> >> }
> >>
> >> request_irq(interrupt_handler);
> >>
> >>
> >> My question now is what if 1 kernel thread execute some_funct(), but
> >> before interrupt_handler() get invoked (from HW), another kernel
> >> thread executes some_func(). In essence, set_register_value is execute
> >> twice before interrupt_handler() return once.
> >
> > Use a mutex_lock().
> > So your code will be as follows:
> >
> > DECLARE_COMPLETION(my_completion);
> > struct mutex dev_lock;
> >
> > some_func()
> > {
> > mutex_lock(&dev_lock);
> > set_register_value
> > wait_for_completion(my_completion);
> > mutex_unloc(&dev_lock);
> > }
> >
> > interrupt_handler(){
> > complete(my_completion);
> > }
> >
> > mutex_init(&dev_lock);
> > request_irq(interrupt_handler);
> >
> > Thanks,
> > Arun
> >
> >>
> >>
> >> how can I prevent another kernel thread from executing
> >> "set_register_value()" when 1 is wait_for_completion?
> >>
> >> _______________________________________________
> >> Kernelnewbies mailing list
> >> Kernelnewbies at kernelnewbies.org
> >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
> >
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

   ---P.K.S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140204/0312fd7b/attachment.html