Continuing with IR transmit after resuming from suspend seems fairly
useless, given that the only place we can actually end up suspending is
after IR has been send and we're simply mdelay'ing. Lets simplify the
resume path by just waiting on tx to complete in the suspend path, then
we know we can't be transmitting on resume, and reinitialization of the
hardware registers becomes more straight-forward.

CC: Juan Jesús García de Soria <skanda...@gmail.com>
Signed-off-by: Jarod Wilson <ja...@redhat.com>
---
Nb: this patch relies upon my earlier patch to add the init_hardware
calls to the resume path in the first place.

 drivers/media/rc/ite-cir.c |   16 +++++++---------
 1 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite-cir.c
index d1dec5c..e716b93 100644
--- a/drivers/media/rc/ite-cir.c
+++ b/drivers/media/rc/ite-cir.c
@@ -1650,6 +1650,9 @@ static int ite_suspend(struct pnp_dev *pdev, pm_message_t 
state)
 
        ite_dbg("%s called", __func__);
 
+       /* wait for any transmission to end */
+       wait_event_interruptible(dev->tx_ended, !dev->transmitting);
+
        spin_lock_irqsave(&dev->lock, flags);
 
        /* disable all interrupts */
@@ -1670,15 +1673,10 @@ static int ite_resume(struct pnp_dev *pdev)
 
        spin_lock_irqsave(&dev->lock, flags);
 
-       if (dev->transmitting) {
-               /* 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);
-       }
+       /* reinitialize hardware config registers */
+       dev->params.init_hardware(dev);
+       /* enable the receiver */
+       dev->params.enable_rx(dev);
 
        spin_unlock_irqrestore(&dev->lock, flags);
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to