[Q] USB urb completion handler

[Q] USB urb completion handler

[Ezequiel Garcia]

Hi,

I have a very simple question:
Is it possible for an urb completion handler (the function that you
put in the urb->complete field)
to execute concurrently with itself?

And in what context does it get called? Is it in interrupt context or
in the context of a kernel thread?

Hope my question is clear enough,
Regards,
Ezequiel.

Fwd: [Q] USB urb completion handler

[Ezequiel Garcia]

On Mon, May 7, 2012 at 2:48 PM, Peter Senna Tschudin
<peter.senna@gmail.com> wrote:
> http://www.makelinux.net/ldd3/chp-13-sect-3#chp-13-sect-3.4
>
> " If the function succeeds, the completion handler of the urb (as
> specified by the complete function pointer) is called exactly once
> when the urb is completed. When this function is called, the USB core
> is finished with the URB, and control of it is now returned to the
> device driver."
>

Bingo! Because the driver will only submit *one* urb at a time,
how could it possible have more than one completion handlers
called at a time?

I wasn't thinking with the right half of my brain.
Thanks,
Ezequiel.

[Q] USB urb completion handler

[loody]

hi:

2012/5/8 Ezequiel Garcia <elezegarcia@gmail.com>:
> On Mon, May 7, 2012 at 2:48 PM, Peter Senna Tschudin
> <peter.senna@gmail.com> wrote:
>> http://www.makelinux.net/ldd3/chp-13-sect-3#chp-13-sect-3.4
>>
>> " If the function succeeds, the completion handler of the urb (as
>> specified by the complete function pointer) is called exactly once
>> when the urb is completed. When this function is called, the USB core
>> is finished with the URB, and control of it is now returned to the
>> device driver."
>>
>
> Bingo! Because the driver will only submit *one* urb at a time,
> how could it possible have more than one completion handlers
> called at a time?
how about multi-thread try to send urbs on the same pipe with the same
complete function?
>
> I wasn't thinking with the right half of my brain.
> Thanks,
> Ezequiel.
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



-- 
Regards,

[Q] USB urb completion handler

[loody]

hi

2012/5/8 Ezequiel Garcia <elezegarcia@gmail.com>:
> Hi,
>
> I have a very simple question:
> Is it possible for an urb completion handler (the function that you
> put in the urb->complete field)
> to execute concurrently with itself?
>
> And in what context does it get called? Is it in interrupt context or
> in the context of a kernel thread?

Both conditions will try to call complete functions.

>
> Hope my question is clear enough,
> Regards,
> Ezequiel.
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

-- 
Regards,

[Q] USB urb completion handler

[Ezequiel Garcia]

Hi,

>> Bingo! Because the driver will only submit *one* urb at a time,
>> how could it possible have more than one completion handlers
>> called at a time?
>
> how about multi-thread try to send urbs on the same pipe with the same
> complete function?

Actually, I was wrong because my driver (being a video capture driver)
submits several
isoc urbs at the same time.

I'm still not sure how this works regarding concurrency, but I guess
(or hope) the usb core calls
the completion handler one at a time OR the device sends interrupts
one at a time for each urb.

I know it's a terrible thing for me to guess (or hope), but these days
I've been testing
the driver under several conditions and it seems to work fine.
So I'm not worrying too much.

If someone more knowledgeable reads this and can put a light upon this issue,
I would appreciate it.

loody: Thanks for your answer regarding context ;)
Ezequiel.

[Q] USB urb completion handler

[loody]

hi:

2012/5/23 Ezequiel Garcia <elezegarcia@gmail.com>:
> Hi,
>
>>> Bingo! Because the driver will only submit *one* urb at a time,
>>> how could it possible have more than one completion handlers
>>> called at a time?
>>
>> how about multi-thread try to send urbs on the same pipe with the same
>> complete function?
>
> Actually, I was wrong because my driver (being a video capture driver)
> submits several
> isoc urbs at the same time.
>
> I'm still not sure how this works regarding concurrency, but I guess
> (or hope) the usb core calls
> the completion handler one at a time OR the device sends interrupts
> one at a time for each urb.
take multi-core system for example, it is possible your completion
handler execute at the same time, except you add a spin lock for
activating your completion function.


>
> I know it's a terrible thing for me to guess (or hope), but these days
> I've been testing
> the driver under several conditions and it seems to work fine.
> So I'm not worrying too much.
>
> If someone more knowledgeable reads this and can put a light upon this issue,
> I would appreciate it.
>
> loody: Thanks for your answer regarding context ;)
> Ezequiel.



-- 
Regards,

[Q] USB urb completion handler

[Ezequiel Garcia]

On Wed, May 23, 2012 at 10:44 PM, loody <miloody@gmail.com> wrote:
> take multi-core system for example, it is possible your completion
> handler execute at the same time, except you add a spin lock for
> activating your completion function.
>

That's the reason I'm asking in first place.
But if that is true, then it seems to me some drivers wouldn't be
working (unlikely, right?)

You can take a look at pwc completion for instance:

static void pwc_isoc_handler(struct urb *urb)
{
[snip]
        if (pdev->fill_buf == NULL)
                pdev->fill_buf = pwc_get_next_fill_buf(pdev);
---

As you can see, there is no lock here (though there is lock
to get the next fill_buf) and pdev->fill_buf is obviously not local.

On the other hand, em28xx has a tighter locking scheme:

static void em28xx_irq_callback(struct urb *urb)
{
[snip]
        /* Copy data from URB */
        spin_lock(&dev->slock);
        dev->isoc_ctl.isoc_copy(dev, urb);
        spin_unlock(&dev->slock);
---

Currently, I'm running a three core (yes three!) streaming at a high
rate and I'm following pwc locking (per queue). So far no races found (phew).

As a sidenote, em28xx locking can be improved for a very simple
reason: it's locking code instead of data.
Unfortunately, I don't own that hardware to fix and test such a patch.