Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1905210imu; Thu, 24 Jan 2019 04:07:35 -0800 (PST) X-Google-Smtp-Source: ALg8bN5OOXKqlnr0E+u6ygqmcz2sA4QgFQztw8C5IoNslWfvtwmvCItBx8qRKxTKqkeawV6WDQLE X-Received: by 2002:a65:5387:: with SMTP id x7mr5713578pgq.412.1548331655445; Thu, 24 Jan 2019 04:07:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548331655; cv=none; d=google.com; s=arc-20160816; b=qFMEy37YEO4pkngY+6Fub5CG8XvJAal4WwVOO0+IwSiQ/WdV/PQ2L7h0c9+svgYbG1 oY5AAkNwXOnYCfEDEYKYuL/4JWi+FVSqEuJGMqg2Bbb1KmrD0tThmAGlyFlhrguH1Np7 eQEgrPVKFregub7Z48T/LNNX6NazpWRN2sZewLctVsvc789rERaaI8vs5fHvT5fmPn+o 9CHakup03hAXI+iWK7cZHjoBy5PPE8fwhgUbqbmSMG67l3On7r/HfOvSBY4oMxpnXlA6 wBRtyq7oD/0TNLXidQWQ0sB0xm9owyau+oWRdImivk1Ik7xFTG1MD/fs8AZQrLJdwJ92 dcOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=GsPSU83pbk1uWSobF359Hmb25tSiPCSXYSiAdhiX2K0=; b=nlB+85WdOJ6LIeBSGyuD4dZN7YDR95i3W2x9Mox47oOe4x2pBwguQP0DCz0YQMK0Ta OjAJfhaIV1905ruLmuPRsmfvvXJqbS1dcPmGctpzLaZ1pv/OQ3xWp0PUyeu4FyJBGt74 Heu+BvRHNHPG3LwcbIXwjYc9yKj0nHeEOu8yGBbIvxmdrxZF1k6TGpthDVJn1Y6aPk1O IvgWSbjZ4de2793UnbZuh4JWS+PtrCMYtvdJtPcUHsuNWVXQMcvfwpvMZ7o//XTxUYGc NmB1ZyocGrOX2yywcnX7kD78F2gQkb2sZO45FcUpUU6J2kjuJpPNKObHYqEEn9Ilw4v7 GrOQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=MVHv9eio; 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=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x64si4525940pfb.120.2019.01.24.04.07.14; Thu, 24 Jan 2019 04:07:35 -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=@linaro.org header.s=google header.b=MVHv9eio; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727665AbfAXMHJ (ORCPT + 99 others); Thu, 24 Jan 2019 07:07:09 -0500 Received: from mail-wm1-f65.google.com ([209.85.128.65]:54857 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727455AbfAXMHJ (ORCPT ); Thu, 24 Jan 2019 07:07:09 -0500 Received: by mail-wm1-f65.google.com with SMTP id a62so2851453wmh.4 for ; Thu, 24 Jan 2019 04:07:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=GsPSU83pbk1uWSobF359Hmb25tSiPCSXYSiAdhiX2K0=; b=MVHv9eioSsA83BVb2J9fi21oGdNAhe8L5mYX67nd+XBNW59IxbYWyPCjLtaUXXFxQx C8eDCimc2jtV5LiHYUHkJKhoQYN40/4u2K6EOoUunE10yy3C+J6aGY9JX5gh7mgstcNp Dvdm9CHYXs35/N3s4bzP1fUHVnLbpVKVammw0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=GsPSU83pbk1uWSobF359Hmb25tSiPCSXYSiAdhiX2K0=; b=JhSOfm2087Yah04xighE+lUF1akID+OL/3dzE0tmEY8rP86dMwQN65r9R7miB/9GqI pO7wAqqkkQKk2mbjvEb3c7EqMzZr57+Xu+AVO4HfSGsZdw87cmA5EXQbGczbz0OIFo71 3ZZHW/aQ2quocrd0bq9LyZSK0zG6s4JXym0vNe0zO0u0b2CexF9WQkv2J/qMmEUDJfyy GdMPEJEw987JWQrxnBcssCAjf2p4hqPsilJYLl/FzeDjRuDAbMfi/JJDosCjKPwd7ePy Yaoz5Beq6CHqFLQD0zbLJ4TwvfXMBRROiydP2dY6dT5Wc8whAwxno6xmMtVNZF9bIYpg ZXQQ== X-Gm-Message-State: AJcUukftf5v1qFSfyjrjgymjK57U54fSvf6rJ8F41KVB01J/AygJaCIx gnMTXlPmuFTty3Auk4SY/psJmIw6oRrPkw== X-Received: by 2002:a1c:bdc5:: with SMTP id n188mr2530824wmf.69.1548331626262; Thu, 24 Jan 2019 04:07:06 -0800 (PST) Received: from localhost.localdomain (laubervilliers-657-1-83-120.w92-154.abo.wanadoo.fr. [92.154.90.120]) by smtp.gmail.com with ESMTPSA id t12sm98842348wrr.65.2019.01.24.04.07.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Jan 2019 04:07:05 -0800 (PST) From: Ard Biesheuvel To: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org, Ard Biesheuvel , 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 Subject: [PATCH] drm: enable uncached DMA optimization for ARM and arm64 Date: Thu, 24 Jan 2019 13:06:58 +0100 Message-Id: <20190124120658.30288-1-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- 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 bfe1639df02d..97fc498dc767 100644 --- a/include/drm/drm_cache.h +++ b/include/drm/drm_cache.h @@ -47,6 +47,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.20.1