From patchwork Fri Apr 27 16:33:11 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 10369391 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 8B7CB601D3 for ; Fri, 27 Apr 2018 16:33:24 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7BE2029232 for ; Fri, 27 Apr 2018 16:33:24 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 70774293C1; Fri, 27 Apr 2018 16:33:24 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3EFB229249 for ; Fri, 27 Apr 2018 16:33:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758472AbeD0QdW (ORCPT ); Fri, 27 Apr 2018 12:33:22 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:43604 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757562AbeD0QdV (ORCPT ); Fri, 27 Apr 2018 12:33:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To: From:Date:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=znkJwFAAY7F4LahU6TAKGJW/O6KIJ22+aSy56klvLjM=; b=WSmvbdM0xrA6hrHW4D/AYboOd C9L5sXuH6S+nTpqS+qm3aTYR8XeqXGQkkeR2OWRaI7viFEleEQv6ZYkg7AbQ18Dqfch40ZNYi6IcM /PK/E1OFw9CfcMniXHy+EwVcQxloDyPBzYOQxMYBqKyLoAvLw9ZRbXlSwk3RXJcfEebaJnGKFpGu4 0dGYPmbPWQ8GgFEDtYVeHU7kT1liE56EmljKvTmdWCu+lkevgR8RuQywAq3Nxf8vxJC9SN9g1EYKt MK3mk/7kSsbSZu5E+Logw5hrByUVCdbBJvQ/YBQi7j2rd/hn6UKMizbPMIuGlgpUXudoIQMU7wRww 13iDUx2cw==; Received: from 179.176.123.138.dynamic.adsl.gvt.net.br ([179.176.123.138] helo=vento.lan) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1fC6JB-000312-Jr; Fri, 27 Apr 2018 16:33:18 +0000 Date: Fri, 27 Apr 2018 13:33:11 -0300 From: Mauro Carvalho Chehab To: Olli Salonen Cc: Antti Palosaari , Peter Zijlstra , Nibble Max , linux-media , wsa@the-dreams.de Subject: Re: Regression: DVBSky S960 USB tuner doesn't work in 4.10 or newer Message-ID: <20180427133311.5789da57@vento.lan> In-Reply-To: References: <20180409091441.GX4043@hirez.programming.kicks-ass.net> <18b9e776-3558-30ed-f616-a0ba8e4d177d@iki.fi> X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Em Fri, 27 Apr 2018 16:25:08 +0200 Olli Salonen escreveu: > Thanks for the suggestion Antti. > > I've tried to add a delay in various places, but haven't seen any > improvement. However, what I did saw was that if I added an msleep > after the lock: > > static int dvbsky_usb_generic_rw(struct dvb_usb_device *d, > u8 *wbuf, u16 wlen, u8 *rbuf, u16 rlen) > { > int ret; > struct dvbsky_state *state = d_to_priv(d); > > mutex_lock(&d->usb_mutex); > msleep(20); > > The error was seen very within a minute. If I increased the msleep to > 50, it failed within seconds. This doesn't seem to make sense to me. > This is the only function where usb_mutex is used. If the mutex is > held for a longer time, the next attempt to lock the mutex should just > be delayed a bit, no? I don't like the idea of having two mutexes there to protect reading/writing to data one for "generic" r/w ops, and another one just for streaming control, with ends by calling the "generic" mutex. IMHO, I would get rid of one of the mutexes, e. g. something like the patch below (untested). Regards, Mauro media: dvbsky: use just one mutex for serializing device R/W ops Right now, there are two mutexes serializing r/w ops: one "generic" and another one specifically for stream on/off. Clean it a little bit, getting rid of one of the mutexes. Signed-off-by: Mauro Carvalho Chehab Thanks, Mauro diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c b/drivers/media/usb/dvb-usb-v2/dvbsky.c index 43eb82884555..50553975c39d 100644 --- a/drivers/media/usb/dvb-usb-v2/dvbsky.c +++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c @@ -31,7 +31,6 @@ MODULE_PARM_DESC(disable_rc, "Disable inbuilt IR receiver."); DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr); struct dvbsky_state { - struct mutex stream_mutex; u8 ibuf[DVBSKY_BUF_LEN]; u8 obuf[DVBSKY_BUF_LEN]; u8 last_lock; @@ -68,18 +67,17 @@ static int dvbsky_usb_generic_rw(struct dvb_usb_device *d, static int dvbsky_stream_ctrl(struct dvb_usb_device *d, u8 onoff) { - struct dvbsky_state *state = d_to_priv(d); int ret; - u8 obuf_pre[3] = { 0x37, 0, 0 }; - u8 obuf_post[3] = { 0x36, 3, 0 }; + static u8 obuf_pre[3] = { 0x37, 0, 0 }; + static u8 obuf_post[3] = { 0x36, 3, 0 }; - mutex_lock(&state->stream_mutex); - ret = dvbsky_usb_generic_rw(d, obuf_pre, 3, NULL, 0); + mutex_lock(&d->usb_mutex); + ret = dvb_usbv2_generic_rw_locked(d, obuf_pre, 3, NULL, 0); if (!ret && onoff) { msleep(20); - ret = dvbsky_usb_generic_rw(d, obuf_post, 3, NULL, 0); + ret = dvb_usbv2_generic_rw_locked(d, obuf_post, 3, NULL, 0); } - mutex_unlock(&state->stream_mutex); + mutex_unlock(&d->usb_mutex); return ret; } @@ -744,8 +742,6 @@ static int dvbsky_init(struct dvb_usb_device *d) if (ret) return ret; */ - mutex_init(&state->stream_mutex); - state->last_lock = 0; return 0;