Behaviour of input-polldev?

Behaviour of input-polldev?

[Florian Echtler]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

Hello everyone,

I'm in the process of writing an input driver for the Microsoft
Pixelsense (formerly Surface 2.0). The device only has bulk endpoints
and consequently needs to be polled regularly. My beta driver uses
input-polldev for this, and it appears to work nicely, however, I
couldn't find out how input-polldev behaves if one polling cycle takes
longer than expected and a new poll would already be triggered while the
first one is still running?

Thanks & BR, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Behaviour of input-polldev?

[David Herrmann]

Hi Florian

On Tue, Sep 3, 2013 at 1:39 PM, Florian Echtler <floe@butterbrot.org> wrote:
> Hello everyone,
>
> I'm in the process of writing an input driver for the Microsoft
> Pixelsense (formerly Surface 2.0). The device only has bulk endpoints
> and consequently needs to be polled regularly. My beta driver uses
> input-polldev for this, and it appears to work nicely, however, I
> couldn't find out how input-polldev behaves if one polling cycle takes
> longer than expected and a new poll would already be triggered while the
> first one is still running?

(CC'ing polldev author Dmitry in case I'm missing something)

input-polldev uses the system-freezable-wq. The related code is
./drivers/input/input-polldev.c:33:
  queue_delayed_work(system_freezable_wq, &dev->work, delay);

Since the wq-rewrite all default workqueues are non-reentrant. That
is, the new work is still scheduled but only executed after the
previous worker returned (in this case, once your ->poll() callback
returns).

Regards
David

Re: Behaviour of input-polldev?

[Dmitry Torokhov]

On Tue, Sep 03, 2013 at 01:54:45PM +0200, David Herrmann wrote:
> Hi Florian
> 
> On Tue, Sep 3, 2013 at 1:39 PM, Florian Echtler <floe@butterbrot.org> wrote:
> > Hello everyone,
> >
> > I'm in the process of writing an input driver for the Microsoft
> > Pixelsense (formerly Surface 2.0). The device only has bulk endpoints
> > and consequently needs to be polled regularly. My beta driver uses
> > input-polldev for this, and it appears to work nicely, however, I
> > couldn't find out how input-polldev behaves if one polling cycle takes
> > longer than expected and a new poll would already be triggered while the
> > first one is still running?

With input-polldev new poll can not get scheduled until driver's poll()
method returns:

static void input_polled_device_work(struct work_struct *work)
{
	struct input_polled_dev *dev =
		container_of(work, struct input_polled_dev, work.work);

	dev->poll(dev);
	input_polldev_queue_work(dev);
}

The expectation here is that poll function is quick and does not
introduce much skew into scheduling of polls (although of course error
is accumulating).

-- 
Dmitry