From patchwork Mon Jul 18 19:54:24 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jarod Wilson X-Patchwork-Id: 7470 Return-path: Envelope-to: mchehab@infradead.org Delivery-date: Mon, 18 Jul 2011 19:54:57 +0000 Received: from casper.infradead.org [85.118.1.10] by gaivota with IMAP (fetchmail-6.3.20) for (single-drop); Mon, 18 Jul 2011 16:56:25 -0300 (BRT) Received: from vger.kernel.org ([209.132.180.67]) by casper.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1Qitu5-0003u0-2e; Mon, 18 Jul 2011 19:54:57 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753540Ab1GRTyv (ORCPT + 1 other); Mon, 18 Jul 2011 15:54:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45720 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751692Ab1GRTyu (ORCPT ); Mon, 18 Jul 2011 15:54:50 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p6IJsoX1008912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 18 Jul 2011 15:54:50 -0400 Received: from xavier.bos.redhat.com (xavier.bos.redhat.com [10.16.16.50]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p6IJsWQI029395; Mon, 18 Jul 2011 15:54:49 -0400 From: Jarod Wilson To: linux-media@vger.kernel.org Cc: Jarod Wilson Subject: [PATCH v2 4/9] [media] mceusb: issue device resume cmd when needed Date: Mon, 18 Jul 2011 15:54:24 -0400 Message-Id: <1311018869-22794-5-git-send-email-jarod@redhat.com> In-Reply-To: <1310681394-3530-1-git-send-email-jarod@redhat.com> References: <1310681394-3530-1-git-send-email-jarod@redhat.com> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org According to MS docs, the device firmware may halt after receiving an unknown instruction, but that it should be possible to tell the firmware to continue running by simply sending a device resume command. So lets do that. v2: use msleep instead of mdelay per Mauro's suggestion Signed-off-by: Jarod Wilson --- drivers/media/rc/mceusb.c | 13 +++++++++++++ 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c index ab074a3..f1fc11d 100644 --- a/drivers/media/rc/mceusb.c +++ b/drivers/media/rc/mceusb.c @@ -436,6 +436,8 @@ struct mceusb_dev { char name[128]; char phys[64]; enum mceusb_model_type model; + + bool need_reset; /* flag to issue a device resume cmd */ }; /* MCE Device Command Strings, generally a port and command pair */ @@ -735,6 +737,14 @@ static void mce_request_packet(struct mceusb_dev *ir, unsigned char *data, static void mce_async_out(struct mceusb_dev *ir, unsigned char *data, int size) { + int rsize = sizeof(DEVICE_RESUME); + + if (ir->need_reset) { + ir->need_reset = false; + mce_request_packet(ir, DEVICE_RESUME, rsize, MCEUSB_TX); + msleep(10); + } + mce_request_packet(ir, data, size, MCEUSB_TX); msleep(10); } @@ -911,6 +921,9 @@ static void mceusb_handle_command(struct mceusb_dev *ir, int index) case MCE_RSP_EQIRRXPORTEN: ir->learning_enabled = ((hi & 0x02) == 0x02); break; + case MCE_RSP_CMD_ILLEGAL: + ir->need_reset = true; + break; default: break; }