From: "Rick L. Vinyard, Jr." <rvinyard@cs.nmsu.edu>
To: Jiri Kosina <jkosina@suse.cz>
Cc: "Oliver Neukum" <oliver@neukum.org>,
"Bruno Prémont" <bonbons@linux-vserver.org>,
linux-input@vger.kernel.org, linux-usb@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
"Nicu Pavel" <npavel@ituner.com>
Subject: Re: [PATCH 1/3] picolcd: driver for PicoLCD HID device
Date: Thu, 25 Feb 2010 08:34:42 -0700 [thread overview]
Message-ID: <7316226fbd1cb53b7f90965c54acd343.squirrel@intranet.cs.nmsu.edu> (raw)
In-Reply-To: <alpine.LNX.2.00.1002251157500.30967@pobox.suse.cz>
Jiri Kosina wrote:
> On Wed, 24 Feb 2010, Rick L. Vinyard, Jr. wrote:
>
>> The key difference is the replacement of spin_lock() with spin_trylock()
>> such that if the non-interrupt code has already obtained the lock, the
>> interrupt will not deadlock but instead take the else path and schedule
>> a
>> framebuffer update at the next interval.
>
> Why is _irqsave() and/or deferred work not enough? The aproach with
> _trylock() seems to be overly complicated for no good reason (I personally
> become very suspicious every time I see code that is using _trylock()).
>
I was concerned about _irqsave() because the lock is split across two
functions to protect the urb after it is handed off to the usb subsystem
with usb_submit_urb(). It's locked in g13_fb_send() and unlocked in the
urb completion callback.
As for deferred work, the g13_fb_send() is the I/O portion of the deferred
framebuffer callback. I was concerned that without a lock one deferred
update could hand the urb off to the usb subsystem and a second could try
to access it before it was handed back to the driver.
In this case the _trylock() would fail and in the else patch we would
defer yet again until the next update cycle.
I took this approach because usb_interrupt_msg() couldn't be used from an
interrupt context, such as a resume hook because eventually down the chain
it does a wait_for_completion_timeout().
It has the added benefit of reusing the urb instead of creating a new one
for each framebuffer sent out, but that wasn't a reason... just a side
effect.
The downside is that I had to manage the urb.
One thing I could do is forget about directly calling g13_fb_send() from
any context and instead use the deferred framebuffer workqueue.
That's probably a simpler approach anyway.
> [ by the way, Rick, are you planning to resubmit the G13 driver with
> incorporated feedback from the last review round? ]
>
Yes. I just wanted to get the details of suspend/resume worked out before
resubmitting.
--
Rick
next prev parent reply other threads:[~2010-02-25 15:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100221002001.0a7e05a7@neptune.home>
[not found] ` <20100221002001.0a7e05a7-hY15tx4IgV39zxVx7UNMDg@public.gmane.org>
2010-02-24 16:00 ` [PATCH 1/3] picolcd: driver for PicoLCD HID device Bruno Prémont
2010-02-24 16:01 ` [PATCH 2/3] hid: add suspend/resume hooks for hid drivers Bruno Prémont
2010-02-25 4:19 ` Oliver Neukum
2010-02-25 10:12 ` Bruno Prémont
2010-02-24 18:27 ` [PATCH 1/3] picolcd: driver for PicoLCD HID device Oliver Neukum
[not found] ` <201002241927.53532.oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
2010-02-24 21:44 ` Rick L. Vinyard, Jr.
2010-02-25 4:11 ` Oliver Neukum
2010-02-25 11:00 ` Jiri Kosina
2010-02-25 15:34 ` Rick L. Vinyard, Jr. [this message]
2010-02-26 8:12 ` Dmitry Torokhov
2010-03-03 6:04 ` Pavel Machek
[not found] ` <20100224163101.3622d69f@neptune.home>
[not found] ` <20100224170049.0d04af3c-hY15tx4IgV39zxVx7UNMDg@public.gmane.org>
[not found] ` <20100224163101.3622d69f-hY15tx4IgV39zxVx7UNMDg@public.gmane.org>
2010-02-24 16:01 ` [PATCH 3/3] hid-picolcd: make use of new suspend/resume hooks Bruno Prémont
2010-02-25 11:07 ` [PATCH 1/3] picolcd: driver for PicoLCD HID device Jiri Kosina
[not found] ` <alpine.LNX.2.00.1002251201430.30967-ztGlSCb7Y1iN3ZZ/Hiejyg@public.gmane.org>
2010-02-25 11:32 ` Bruno Prémont
2010-02-25 15:18 ` Jiri Kosina
2010-02-25 15:29 ` Bruno Prémont
[not found] ` <alpine.LNX.2.00.1002251615570.30967-ztGlSCb7Y1iN3ZZ/Hiejyg@public.gmane.org>
2010-03-13 19:39 ` Bruno Prémont
2010-03-13 21:35 ` Alan Stern
2010-03-13 22:13 ` [PATCH] hid: Register debugfs entries before adding device Bruno Prémont
2010-03-15 13:48 ` Jiri Kosina
[not found] ` <20100225123214.0523a310-hY15tx4IgV39zxVx7UNMDg@public.gmane.org>
2010-02-25 17:52 ` [PATCH 1/3] picolcd: driver for PicoLCD HID device Rick L. Vinyard, Jr.
2010-02-26 8:15 ` Dmitry Torokhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7316226fbd1cb53b7f90965c54acd343.squirrel@intranet.cs.nmsu.edu \
--to=rvinyard@cs.nmsu.edu \
--cc=bonbons@linux-vserver.org \
--cc=jkosina@suse.cz \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=npavel@ituner.com \
--cc=oliver@neukum.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).