From patchwork Thu Sep 15 13:04:41 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrey Utkin X-Patchwork-Id: 9333593 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 E7F3E6077A for ; Thu, 15 Sep 2016 13:06:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DA43C296F8 for ; Thu, 15 Sep 2016 13:06:52 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id CE95229712; Thu, 15 Sep 2016 13:06:52 +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=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, 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 E12B4296F8 for ; Thu, 15 Sep 2016 13:06:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752297AbcIONGq (ORCPT ); Thu, 15 Sep 2016 09:06:46 -0400 Received: from mail-lf0-f42.google.com ([209.85.215.42]:35228 "EHLO mail-lf0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752197AbcIONGo (ORCPT ); Thu, 15 Sep 2016 09:06:44 -0400 Received: by mail-lf0-f42.google.com with SMTP id l131so34112930lfl.2 for ; Thu, 15 Sep 2016 06:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=corp-bluecherry-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:user-agent; bh=9pKHaoj2C8F1gDh+dBpupwnE6FaMi8rVVeZ2b10P9UQ=; b=HTViF/njII3JfmIwzPiTWdvwIpyGPuR5nThNa16jHtN5/qChPcV/LRqy1fc6Zq1EOM dw/QabVJpD/VZGuX1CATeImypw5f49yzeZ5Eis72ar6V9YtOSw/QJ1XuNB2lDUIlMQjt 9zrKG0f1t5cswF/VD9A4JoFEN8vb+9nUSM1eAATDyB2eFYWrL1A08SEZMr2Avo2K4j+7 m3VsFqaWCuvy5uJEiFxrrDikCXJqkXIpY9Wq5+025Am2J7h5NKvDbeq9Fwl88o9aqm8O rPj42m4muJ3/UaO6NZI18MHIQqn9Y7tRhmFFz2Czuw9rCRFraWqccwkZ6PmtDMqtJrpr 6YIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:user-agent; bh=9pKHaoj2C8F1gDh+dBpupwnE6FaMi8rVVeZ2b10P9UQ=; b=d6CK0WAcvU0gC4bptPsn4MR1K5k3mBH4Pa+iRvT8ZzNGQC16vRTmCPvqsQkAvq8+DM ehV5SQPZw1rPvKJjifq0NghQ8nbeqIsrwOX1fzwfCX6Y6tfVK15rRnRLXFmwP/y3TWx/ ySNyOS2eOaYS+XyCttvreeIYUPX42dHyyx1f24hkb0CG0H0RqF0g664pRmGN/6U1iJ9D P9BJUfVEXEFlfpsnNl2JBFKFTL5XBgVfYNbP9HiPy0aPGkRuRSVlC8q5TueUWJUi7lZ+ ExRdFV7hCKHfzZRkTkh7cpiNK20zkEgz+5zVM/Dv8sihM2tGSnrg5nk54HXx8Si5qskP D7hg== X-Gm-Message-State: AE9vXwOcW46OS/4iAWepZVydVktFWJCD5/r5Xov8d51E5OXRTSKpGygzANVAyRdlHhbw9tN1 X-Received: by 10.46.32.4 with SMTP id g4mr3644761ljg.69.1473944799921; Thu, 15 Sep 2016 06:06:39 -0700 (PDT) Received: from acer ([78.111.186.128]) by smtp.gmail.com with ESMTPSA id d130sm965559lfd.12.2016.09.15.06.06.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Sep 2016 06:06:39 -0700 (PDT) Date: Thu, 15 Sep 2016 16:04:41 +0300 From: Andrey Utkin To: Krzysztof =?utf-8?Q?Ha=C5=82asa?= , linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, Mauro Carvalho Chehab , Hans Verkuil , Ismael Luceno Cc: Bluecherry Maintainers , andrey_utkin@fastmail.com Subject: solo6010 modprobe lockup since e1ceb25a (v4.3 regression) Message-ID: <20160915130441.ji3f3jiiebsnsbct@acer> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.6.2 (2016-06-11) 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 Hi Krzysztof, Me and one more solo6010 board user experience machine lockup when solo6x10 module is loaded on kernel series starting with 4.3 (despite solo6110 board probes just fine on all kernels). That is, 3.16, 3.18, 4.1 and 4.2 are tested and fine, and 4.3, 4.4, and others up to current linux-next are bad. So regression slipped in between 4.2 and 4.3. The diff between stable/linux-4.2.y and ...-4.3.y (which were tested) is not large, and my suspect fell on ripoff of register writing procedures complexity, which was introduced in e1ceb25a (see below). Reversion of that fixes lockup. However, if, on top of reversion of e1ceb25a, i drop barrier stuff and pci_read_config... (see https://github.com/bluecherrydvr/linux/commit/d59aaf3), leaving the spinlock stuff, it locks up again. This is a matter in which I'm not quite qualified, so I have no idea what that code copes with and why this workaround works for solo6010. For now I think I'll tell the customer to use kernel with e1ceb25a reverted, but for upstream fix, I'm interested in more in-depth investigation. I'll be able to provide dmesg logs a bit later. The breaking commit is quoted below. commit e1ceb25a1569ce5b61b9c496dd32d038ba8cb936 Author: Krzysztof Hałasa Date: Mon Jun 8 10:42:24 2015 -0300 [media] SOLO6x10: remove unneeded register locking and barriers readl() and writel() are atomic, we don't need the spin lock. Also, flushing posted write buffer isn't required. Especially on read :-) Signed-off-by: Krzysztof Ha?asa Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/media/pci/solo6x10/solo6x10-core.c b/drivers/media/pci/solo6x10/solo6x10-core.c index 84627e6..9c948b1 100644 --- a/drivers/media/pci/solo6x10/solo6x10-core.c +++ b/drivers/media/pci/solo6x10/solo6x10-core.c @@ -483,7 +483,6 @@ static int solo_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) solo_dev->type = id->driver_data; solo_dev->pdev = pdev; - spin_lock_init(&solo_dev->reg_io_lock); ret = v4l2_device_register(&pdev->dev, &solo_dev->v4l2_dev); if (ret) goto fail_probe; diff --git a/drivers/media/pci/solo6x10/solo6x10.h b/drivers/media/pci/solo6x10/solo6x10.h index 1ca54b0..27423d7 100644 --- a/drivers/media/pci/solo6x10/solo6x10.h +++ b/drivers/media/pci/solo6x10/solo6x10.h @@ -199,7 +199,6 @@ struct solo_dev { int nr_ext; u32 irq_mask; u32 motion_mask; - spinlock_t reg_io_lock; struct v4l2_device v4l2_dev; /* tw28xx accounting */ @@ -281,36 +280,13 @@ struct solo_dev { static inline u32 solo_reg_read(struct solo_dev *solo_dev, int reg) { - unsigned long flags; - u32 ret; - u16 val; - - spin_lock_irqsave(&solo_dev->reg_io_lock, flags); - - ret = readl(solo_dev->reg_base + reg); - rmb(); - pci_read_config_word(solo_dev->pdev, PCI_STATUS, &val); - rmb(); - - spin_unlock_irqrestore(&solo_dev->reg_io_lock, flags); - - return ret; + return readl(solo_dev->reg_base + reg); } static inline void solo_reg_write(struct solo_dev *solo_dev, int reg, u32 data) { - unsigned long flags; - u16 val; - - spin_lock_irqsave(&solo_dev->reg_io_lock, flags); - writel(data, solo_dev->reg_base + reg); - wmb(); - pci_read_config_word(solo_dev->pdev, PCI_STATUS, &val); - rmb(); - - spin_unlock_irqrestore(&solo_dev->reg_io_lock, flags); } static inline void solo_irq_on(struct solo_dev *dev, u32 mask)