From patchwork Sun Nov 4 13:53:43 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sasha Levin X-Patchwork-Id: 150117 Delivered-To: patch@linaro.org Received: by 2002:a2e:299d:0:0:0:0:0 with SMTP id p29-v6csp1541808ljp; Sun, 4 Nov 2018 05:58:11 -0800 (PST) X-Google-Smtp-Source: AJdET5cs6FPIGtK209VXawVWWOFxdk79wWi9QQzcsSm/LCQjmBBYLDb5RZ5akavDmC0xm+CvHpDb X-Received: by 2002:a62:7701:: with SMTP id s1-v6mr18928555pfc.159.1541339891822; Sun, 04 Nov 2018 05:58:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541339891; cv=none; d=google.com; s=arc-20160816; b=vcNw6dZZZ55frPN/3uqVWPld7yEgpgn1nVUSRg0MoPmm0C24lpINbo9J3cgi9rATt4 35bPkcUK7eGGSojtUnQUZgPICJWs5oRZ9ICBnVxch8279sDdl6qPlNVrlooEzkQLSFUl lPzopWMh8nyv8yHkDi2VjQFhYsx9L/J8Soh1PzTdktr4kZWIcOuxDdxK/pPlkrJjMIKm hdCXIcwWLmsDbrC814PNGv496Ac4GekTI/wSNv5sdiNh/hEfSAxUbpaWe8VN+F+28eDo h/YOx2vaK84oT8VY5V82FBi4XSrpQZYKsIIwptSU7NWm9UBMRDjNwLz7YiGgbwQY6KvD oYZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature; bh=HT4ydf8sMiS5OfdJuU8S9kY6XYJ4y+4qxqT5GlO5y9k=; b=VRQUGADV1txF2Va/E0Vs+SmGIjJ2wzs365+Ks1jjYdGN2GkgnqgHxDQqNjhqtLj3Jx 0l2f7gFmRS68KyIVa/1TjqlbXa/JbrHEy1WX9LSXo9d86Y/f1qbUjVnA3+wUku+s3hLp nVIXIUbbklzj47ODxrzqnSMsvhWQlkJd3si8+3ixLwNnqNfDOhLPLhJm99BhKNdraxVh QFrGM+mJlKsqznXFWMcfyFfvHNDo3qjgTaJngbuzCiX6IMDj+rq1udb3ombSBB8XmQPy 9CPVGkBQ/cCE2FLxFlgSFTS4T4XVTNRP8eafh/3437nlAPQ/rlfLZi5LwZ0zbrYSvAwA TO6g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=vPmnkLcY; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d4-v6si39379325pgl.524.2018.11.04.05.58.11; Sun, 04 Nov 2018 05:58:11 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=vPmnkLcY; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731827AbeKDXNP (ORCPT + 32 others); Sun, 4 Nov 2018 18:13:15 -0500 Received: from mail.kernel.org ([198.145.29.99]:48674 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729578AbeKDXJK (ORCPT ); Sun, 4 Nov 2018 18:09:10 -0500 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4934B20868; Sun, 4 Nov 2018 13:54:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1541339645; bh=1LCoqMme9EkjSmjaptctFWP+ZbmEY9m8AZp8nw60RK4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vPmnkLcYqmPKe+BccAM5zpFMhWuiZkvd4yfGtdQiACw1njVKiyC165fX8BGrur+ox 8iABYteeWmYj3hhr+kNRlkHsz3EzLMLCAGAru2ENWqdyxdg+auacLEhWkTlHuV4l+U DCX29hrsPbYW9pr460LoCUXZKM6wrm2cGy9p599w= From: Sasha Levin To: stable@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Tomi Valkeinen , Peter Ujfalusi , Sasha Levin Subject: [PATCH AUTOSEL 4.9 09/21] drm/omap: fix memory barrier bug in DMM driver Date: Sun, 4 Nov 2018 08:53:43 -0500 Message-Id: <20181104135355.88602-9-sashal@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20181104135355.88602-1-sashal@kernel.org> References: <20181104135355.88602-1-sashal@kernel.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Tomi Valkeinen [ Upstream commit 538f66ba204944470a653a4cccc5f8befdf97c22 ] A DMM timeout "timed out waiting for done" has been observed on DRA7 devices. The timeout happens rarely, and only when the system is under heavy load. Debugging showed that the timeout can be made to happen much more frequently by optimizing the DMM driver, so that there's almost no code between writing the last DMM descriptors to RAM, and writing to DMM register which starts the DMM transaction. The current theory is that a wmb() does not properly ensure that the data written to RAM is observable by all the components in the system. This DMM timeout has caused interesting (and rare) bugs as the error handling was not functioning properly (the error handling has been fixed in previous commits): * If a DMM timeout happened when a GEM buffer was being pinned for display on the screen, a timeout error would be shown, but the driver would continue programming DSS HW with broken buffer, leading to SYNCLOST floods and possible crashes. * If a DMM timeout happened when other user (say, video decoder) was pinning a GEM buffer, a timeout would be shown but if the user handled the error properly, no other issues followed. * If a DMM timeout happened when a GEM buffer was being released, the driver does not even notice the error, leading to crashes or hang later. This patch adds wmb() and readl() calls after the last bit is written to RAM, which should ensure that the execution proceeds only after the data is actually in RAM, and thus observable by DMM. The read-back should not be needed. Further study is required to understand if DMM is somehow special case and read-back is ok, or if DRA7's memory barriers do not work correctly. Signed-off-by: Tomi Valkeinen Signed-off-by: Peter Ujfalusi Signed-off-by: Sasha Levin --- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 +++++++++++ 1 file changed, 11 insertions(+) -- 2.17.1 diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c index 7def04049498..6a0b25e0823f 100644 --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c @@ -273,6 +273,17 @@ static int dmm_txn_commit(struct dmm_txn *txn, bool wait) } txn->last_pat->next_pa = 0; + /* ensure that the written descriptors are visible to DMM */ + wmb(); + + /* + * NOTE: the wmb() above should be enough, but there seems to be a bug + * in OMAP's memory barrier implementation, which in some rare cases may + * cause the writes not to be observable after wmb(). + */ + + /* read back to ensure the data is in RAM */ + readl(&txn->last_pat->next_pa); /* write to PAT_DESCR to clear out any pending transaction */ dmm_write(dmm, 0x0, reg[PAT_DESCR][engine->id]); From patchwork Sun Nov 4 13:53:49 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sasha Levin X-Patchwork-Id: 150116 Delivered-To: patch@linaro.org Received: by 2002:a2e:299d:0:0:0:0:0 with SMTP id p29-v6csp1541422ljp; Sun, 4 Nov 2018 05:57:41 -0800 (PST) X-Google-Smtp-Source: AJdET5dXuIsfGuh9KiqRj+rWbPvmqdy08k6xOoHAVpNJ3m4FeIuZJhkKKxcISA/Bt9oB7DpOAG9k X-Received: by 2002:a62:6981:: with SMTP id e123-v6mr3475322pfc.104.1541339860871; Sun, 04 Nov 2018 05:57:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541339860; cv=none; d=google.com; s=arc-20160816; b=keNKT2pk8b/3S8eRhLcZUesVIn7fQmPNW4w7eUflZ5ln2/It2cCRNfyAo8B/3zRmFM DX1mT9JWHtzoVtAC9HDdkXMm1vCApOwLl4xbL2XINdtFhq26M8/aHn6cBsE5ffnxmb/A ZtfhLU2fj/pUz4G0k7qwq+2NQOWaAfsFRCvXUCQbj4uzNA4R1Q/HO86W8ypTG5j80Ytu t7RhxAY+DtX2NFsfnFjCjhQw8KSO0f0KNCakdQ9NLtpOETqXSmgDBTpoVBVS6YtmKpcU J8a6R6r9NIiERMZaJxgpELemkVX1aHvGVnPIibx4vGJxGP0eafIqnWfUCZeUtSofvNxB EC+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature; bh=dCQmcTWLQBWwu8JEKvV7pwmT+DoMB6TOpMfZGztJi3k=; b=psJ7myUCkZjhaB7ffRtyV7Kx2+xz/73IJjmM1vFfeTIfWoZ4VF1s8S8A9ecomsgyGI RQzfkXSk+kDFXY0WljS/ILIn6739lIS4OBpRPWDj6AAATgu3IKXG8K6XCseXa3p4DZ+n uxB9qhi9mFVjToDGrAoG7iwgmuErIzFwGQfeYzGv5TEi4sEjYpuwygWmnof4wfpRl9J6 m1YVXmwS8OgFLepAEpJbj8rGODHfDGhLenJofJLFO6kish84/TjgzoBEwODNTn7ooFon g7K3MBVIj1qyN0mfbuREHjzqikTrMhEgUOBVYHDEbDbBD4Vpy27v2t96D0tXAWe+Hx5Z z35Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=I0HTopOD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n3-v6si36305044pld.137.2018.11.04.05.57.40; Sun, 04 Nov 2018 05:57:40 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=I0HTopOD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731706AbeKDXMo (ORCPT + 32 others); Sun, 4 Nov 2018 18:12:44 -0500 Received: from mail.kernel.org ([198.145.29.99]:48862 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731603AbeKDXJQ (ORCPT ); Sun, 4 Nov 2018 18:09:16 -0500 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5131620866; Sun, 4 Nov 2018 13:54:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1541339651; bh=TnRIjMVaCIulJyvLRBVq8CVZFdBXdgeLzJn3J/NidgI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=I0HTopOD1Mq/VdLAAAbBv4EKyoNgJ6HgiY1Zw92oI9dt8OA0n8y+3NckP9uXy42pk ETdnAIV6YjRfi7xBmYfu+Tpj2HYDfAypun0fLjCSnkMXmoN8QhEsmjI4ZgkgRrerwY 3QmE/3XI7bCnz3IIFctqe3ydjG4u45mYcHxf5OLI= From: Sasha Levin To: stable@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Joel Stanley , Michael Ellerman , Sasha Levin Subject: [PATCH AUTOSEL 4.9 15/21] powerpc/boot: Ensure _zimage_start is a weak symbol Date: Sun, 4 Nov 2018 08:53:49 -0500 Message-Id: <20181104135355.88602-15-sashal@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20181104135355.88602-1-sashal@kernel.org> References: <20181104135355.88602-1-sashal@kernel.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Joel Stanley [ Upstream commit ee9d21b3b3583712029a0db65a4b7c081d08d3b3 ] When building with clang crt0's _zimage_start is not marked weak, which breaks the build when linking the kernel image: $ objdump -t arch/powerpc/boot/crt0.o |grep _zimage_start$ 0000000000000058 g .text 0000000000000000 _zimage_start ld: arch/powerpc/boot/wrapper.a(crt0.o): in function '_zimage_start': (.text+0x58): multiple definition of '_zimage_start'; arch/powerpc/boot/pseries-head.o:(.text+0x0): first defined here Clang requires the .weak directive to appear after the symbol is declared. The binutils manual says: This directive sets the weak attribute on the comma separated list of symbol names. If the symbols do not already exist, they will be created. So it appears this is different with clang. The only reference I could see for this was an OpenBSD mailing list post[1]. Changing it to be after the declaration fixes building with Clang, and still works with GCC. $ objdump -t arch/powerpc/boot/crt0.o |grep _zimage_start$ 0000000000000058 w .text 0000000000000000 _zimage_start Reported to clang as https://bugs.llvm.org/show_bug.cgi?id=38921 [1] https://groups.google.com/forum/#!topic/fa.openbsd.tech/PAgKKen2YCY Signed-off-by: Joel Stanley Reviewed-by: Nick Desaulniers Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin --- arch/powerpc/boot/crt0.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.17.1 diff --git a/arch/powerpc/boot/crt0.S b/arch/powerpc/boot/crt0.S index 12866ccb5694..5c2199857aa8 100644 --- a/arch/powerpc/boot/crt0.S +++ b/arch/powerpc/boot/crt0.S @@ -47,8 +47,10 @@ p_end: .long _end p_pstack: .long _platform_stack_top #endif - .weak _zimage_start .globl _zimage_start + /* Clang appears to require the .weak directive to be after the symbol + * is defined. See https://bugs.llvm.org/show_bug.cgi?id=38921 */ + .weak _zimage_start _zimage_start: .globl _zimage_start_lib _zimage_start_lib: