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
WARNING: multiple messages have this Message-ID (diff)
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 15:34:42 +0000 [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: 81+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-02-20 23:10 [Patch 0/3] backlight Bruno Prémont 2010-02-20 23:10 ` Bruno Prémont 2010-02-20 23:18 ` [PATCH 2/3] backlight: mark struct backlight_ops const Bruno Prémont 2010-02-20 23:18 ` Bruno Prémont 2010-02-20 23:18 ` Bruno Prémont 2010-02-20 23:18 ` Bruno Prémont [not found] ` <20100221001851.673db863-hY15tx4IgV39zxVx7UNMDg@public.gmane.org> 2010-02-22 19:35 ` Mike Frysinger 2010-02-22 19:35 ` Mike Frysinger 2010-02-22 19:35 ` Mike Frysinger 2010-02-22 19:35 ` Mike Frysinger 2010-02-26 11:56 ` [PATCH] " Bruno Prémont 2010-02-26 11:56 ` Bruno Prémont 2010-02-20 23:20 ` [PATCH 1/3] backlight: Add backlight_device parameter to check_fb Bruno Prémont 2010-02-20 23:20 ` Bruno Prémont 2010-02-24 16:00 ` [PATCH 1/3] picolcd: driver for PicoLCD HID device Bruno Prémont 2010-02-24 16:00 ` Bruno Prémont 2010-02-24 16:00 ` 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 16:01 ` [PATCH 3/3] hid-picolcd: make use of new suspend/resume hooks Bruno Prémont 2010-02-24 16:01 ` Bruno Prémont 2010-02-24 18:27 ` [PATCH 1/3] picolcd: driver for PicoLCD HID device Oliver Neukum 2010-02-24 18:27 ` Oliver Neukum 2010-02-24 18:27 ` Oliver Neukum 2010-02-24 21:44 ` Rick L. Vinyard, Jr. 2010-02-24 21:44 ` Rick L. Vinyard, Jr. 2010-02-24 21:44 ` Rick L. Vinyard, Jr. 2010-02-25 4:11 ` Oliver Neukum 2010-02-25 4:11 ` Oliver Neukum 2010-02-25 11:00 ` Jiri Kosina 2010-02-25 11:00 ` Jiri Kosina 2010-02-25 15:34 ` Rick L. Vinyard, Jr. [this message] 2010-02-25 15:34 ` Rick L. Vinyard, Jr. 2010-02-26 8:12 ` Dmitry Torokhov 2010-02-26 8:12 ` Dmitry Torokhov 2010-02-25 11:07 ` Jiri Kosina 2010-02-25 11:07 ` Jiri Kosina 2010-02-25 11:07 ` Jiri Kosina 2010-02-25 11:32 ` Bruno Prémont 2010-02-25 11:32 ` Bruno Prémont 2010-02-25 11:32 ` Bruno Prémont 2010-02-25 15:18 ` Jiri Kosina 2010-02-25 15:18 ` Jiri Kosina 2010-02-25 15:18 ` Jiri Kosina 2010-02-25 15:29 ` Bruno Prémont 2010-02-25 15:29 ` Bruno Prémont 2010-03-13 19:39 ` Bruno Prémont 2010-03-13 19:39 ` Bruno Prémont 2010-03-13 21:35 ` Alan Stern 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-13 22:13 ` Bruno Prémont 2010-03-15 13:48 ` Jiri Kosina 2010-02-25 17:52 ` [PATCH 1/3] picolcd: driver for PicoLCD HID device Rick L. Vinyard, Jr. 2010-02-25 17:52 ` Rick L. Vinyard, Jr. 2010-02-25 17:52 ` Rick L. Vinyard, Jr. 2010-02-26 8:15 ` Dmitry Torokhov 2010-02-26 8:15 ` Dmitry Torokhov 2010-02-26 8:15 ` Dmitry Torokhov 2010-03-03 6:04 ` Pavel Machek 2010-03-03 6:04 ` Pavel Machek 2010-02-26 11:53 ` [PATCH] backlight: Add backlight_device parameter to check_fb Bruno Prémont 2010-02-26 11:53 ` Bruno Prémont 2010-02-20 23:28 ` [PATCH 3/3] backlight: fix missing/incomplete registration failure handling Bruno Prémont 2010-02-20 23:28 ` [PATCH 3/3] backlight: fix missing/incomplete registration failure Bruno Prémont 2010-02-21 8:04 ` [PATCH 3/3] backlight: fix missing/incomplete registration failure handling Harald Welte 2010-02-21 13:35 ` Thadeu Lima de Souza Cascardo 2010-02-21 13:35 ` [PATCH 3/3] backlight: fix missing/incomplete registration Thadeu Lima de Souza Cascardo 2010-02-24 15:33 ` [PATCH 3/3] backlight: fix missing/incomplete registration failure handling Anisse Astier 2010-02-24 15:33 ` [PATCH 3/3] backlight: fix missing/incomplete registration Anisse Astier 2010-02-26 11:59 ` [PATCH] backlight, classmate-laptop: fix missing registration failure handling Bruno Prémont 2010-02-26 16:20 ` Thadeu Lima de Souza Cascardo 2010-02-26 16:32 ` Matthew Garrett 2010-02-26 16:45 ` Richard Purdie 2010-02-26 22:25 ` Bruno Prémont 2010-02-26 12:02 ` [PATCH] backlight, appledisplay: fix incomplete " Bruno Prémont 2010-02-26 12:04 ` [PATCH] backlight, blackfin: fix missing " Bruno Prémont 2010-02-26 12:04 ` [PATCH] backlight, blackfin: fix missing registration failure Bruno Prémont 2010-02-26 12:17 ` [PATCH] backlight, msi-laptop, msi-wmi: fix incomplete registration failure handling Bruno Prémont 2010-02-26 12:20 ` [PATCH] backlight, panasonic-laptop: " Bruno Prémont
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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.