From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 74F37C43381 for ; Tue, 12 Mar 2019 17:31:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 478DD214AE for ; Tue, 12 Mar 2019 17:31:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1552411866; bh=tE+hKSrppXi4h4U212ftd0/Ckuy9VBAyRNh5+TNbS0Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=MYBSyHpZ51XzIiRYzKbVczfyVzd96eXS66mY2ooihgl6FpoEMRQYcxYYsGCxgXiR8 lUFqnzR0uwFEOcVx0swrhxNbFfzZcKjlpxBqeVzDqk6QuNL5xL3hEqVs1E7knxq66w Cz0ZF2LYpOiDZCgjaSdHwVP00+b9GcgEFPubWbAE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729735AbfCLRay (ORCPT ); Tue, 12 Mar 2019 13:30:54 -0400 Received: from mail.kernel.org ([198.145.29.99]:60634 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729491AbfCLRRN (ORCPT ); Tue, 12 Mar 2019 13:17:13 -0400 Received: from localhost (unknown [104.133.8.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 14A062087C; Tue, 12 Mar 2019 17:17:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1552411032; bh=tE+hKSrppXi4h4U212ftd0/Ckuy9VBAyRNh5+TNbS0Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Cs454gDdOPs59G9LmzA/cOEc+x6vchue+7tpMNMH8jUOpGf5Q8cYG+vErWuZuoF1S Q5jQUigTptnNyPzdAG5JEVFxrN8B2BIBCPdr28HpjkATQHAKyHqMrmLaJwXXdRXp6U 7SFX1GTkQoRgzT+kcNNMVZ8mTxo/8XkHc+bisfZo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Christian Koenig , Alex Deucher , David Zhou , Huang Rui , Junwei Zhang , Michel Daenzer , David Airlie , Daniel Vetter , Maarten Lankhorst , Maxime Ripard , Sean Paul , Michael Ellerman , Benjamin Herrenschmidt , Will Deacon , Christoph Hellwig , Robin Murphy , amd-gfx list , dri-devel , Carsten Haitzler , Ard Biesheuvel , Sasha Levin Subject: [PATCH 4.14 127/135] drm: disable uncached DMA optimization for ARM and arm64 Date: Tue, 12 Mar 2019 10:09:34 -0700 Message-Id: <20190312170352.839578994@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190312170341.127810985@linuxfoundation.org> References: <20190312170341.127810985@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ [ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ] The DRM driver stack is designed to work with cache coherent devices only, but permits an optimization to be enabled in some cases, where for some buffers, both the CPU and the GPU use uncached mappings, removing the need for DMA snooping and allocation in the CPU caches. The use of uncached GPU mappings relies on the correct implementation of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU will use cached mappings nonetheless. On x86 platforms, this does not seem to matter, as uncached CPU mappings will snoop the caches in any case. However, on ARM and arm64, enabling this optimization on a platform where NoSnoop is ignored results in loss of coherency, which breaks correct operation of the device. Since we have no way of detecting whether NoSnoop works or not, just disable this optimization entirely for ARM and arm64. Cc: Christian Koenig Cc: Alex Deucher Cc: David Zhou Cc: Huang Rui Cc: Junwei Zhang Cc: Michel Daenzer Cc: David Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Will Deacon Cc: Christoph Hellwig Cc: Robin Murphy Cc: amd-gfx list Cc: dri-devel Reported-by: Carsten Haitzler Signed-off-by: Ard Biesheuvel Reviewed-by: Christian König Reviewed-by: Alex Deucher Link: https://patchwork.kernel.org/patch/10778815/ Signed-off-by: Christian König Signed-off-by: Sasha Levin --- include/drm/drm_cache.h | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h index beab0f0d0cfb..250e2d13c61b 100644 --- a/include/drm/drm_cache.h +++ b/include/drm/drm_cache.h @@ -45,6 +45,24 @@ static inline bool drm_arch_can_wc_memory(void) return false; #elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3) return false; +#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64) + /* + * The DRM driver stack is designed to work with cache coherent devices + * only, but permits an optimization to be enabled in some cases, where + * for some buffers, both the CPU and the GPU use uncached mappings, + * removing the need for DMA snooping and allocation in the CPU caches. + * + * The use of uncached GPU mappings relies on the correct implementation + * of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU + * will use cached mappings nonetheless. On x86 platforms, this does not + * seem to matter, as uncached CPU mappings will snoop the caches in any + * case. However, on ARM and arm64, enabling this optimization on a + * platform where NoSnoop is ignored results in loss of coherency, which + * breaks correct operation of the device. Since we have no way of + * detecting whether NoSnoop works or not, just disable this + * optimization entirely for ARM and arm64. + */ + return false; #else return true; #endif -- 2.19.1