From: Jarod Wilson <jarod@redhat.com>
To: "Juan Jesús García de Soria Lucena" <skandalfo@gmail.com>
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH] [media] ite-cir: make IR receive work after resume
Date: Mon, 09 May 2011 15:45:52 -0400 [thread overview]
Message-ID: <4DC84470.7060603@redhat.com> (raw)
In-Reply-To: <dwy71fckod7ba37187igo82l.1304967460349@email.android.com>
Juan Jesús García de Soria Lucena wrote:
> Hi Jarod, and thanks for looking at this.
>
> El 09/05/2011 20:28, "Jarod Wilson"<jarod@redhat.com> escribió:
>> --- a/drivers/media/rc/ite-cir.c
>> +++ b/drivers/media/rc/ite-cir.c
>> @@ -1684,6 +1684,8 @@ static int ite_resume(struct pnp_dev *pdev)
>> /* wake up the transmitter */
>> wake_up_interruptible(&dev->tx_queue);
>> } else {
>> + /* reinitialize hardware config registers */
>> + dev->params.init_hardware(dev);
>> /* enable the receiver */
>> dev->params.enable_rx(dev);
>> }
>> --
>> 1.7.1
>>
>
> But... wouldn't the hardware initialization be required too if the hardware got suspended while doing TX? I mean, probably the call to init_hardware() should be done in any case, just before the if... (forgive me if I'm off target; I'm looking at the code as I remember it, since I don't have it before me right now).
Well, looking at the resume function, I wasn't sure if I wanted to
mess with things while it was possibly trying to finish up tx, but
upon closer inspection, I don't think we can ever get into the
state where we're actually doing anything in the tx handler where
it would matter. If dev->transmitting is true and we're actually
able to grab the spinlock, it means we're just in the middle of
the mdelay for remaining_us, and everything done after that is
partially redundant with init_hardware anyway. So yeah, it looks
safe to me to just put in the init_hardware unconditionally above
the check for dev->transmitting.
On a related note though... what are the actual chances that we are
suspending in the middle of tx, and what are the chances it would
actually be of any use to resume that tx after waking up?
So what I'm now thinking is this: add a wait_event_interruptible on
tx_ended in the suspend path if dev->transmitting to let tx finish
before we suspend. Then in resume, we're never resuming in the
middle of tx and the whole conditional goes away.
--
Jarod Wilson
jarod@redhat.com
next prev parent reply other threads:[~2011-05-09 19:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-09 18:57 [PATCH] [media] ite-cir: make IR receive work after resume Juan Jesús García de Soria Lucena
2011-05-09 19:45 ` Jarod Wilson [this message]
2011-05-09 19:59 ` [PATCH] [media] ite-cir: finish tx before suspending Jarod Wilson
2011-05-09 20:07 ` Jarod Wilson
2011-05-09 20:00 ` [PATCH] [media] ite-cir: make IR receive work after resume Juan Jesús García de Soria Lucena
-- strict thread matches above, loose matches on Subject: below --
2011-05-09 15:08 Jarod Wilson
2011-05-09 18:25 ` Jarod Wilson
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=4DC84470.7060603@redhat.com \
--to=jarod@redhat.com \
--cc=linux-media@vger.kernel.org \
--cc=skandalfo@gmail.com \
/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