Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp1271752ybl; Fri, 23 Aug 2019 16:38:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqy/5jy9tL4QUo0x1qA6PS7e5qfoZfmJqTzA9cU/7NuTk43QcigvwDLdLXJyh4lCxbYvQ2vc X-Received: by 2002:a17:90a:a611:: with SMTP id c17mr6146474pjq.17.1566603533697; Fri, 23 Aug 2019 16:38:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566603533; cv=none; d=google.com; s=arc-20160816; b=bneX/tParHlXhq3TNrPU27nj02NuN9CKYy2MGEktjv99pLesMdx9Z2I2HzV1D2E6iH 3py3dQpSrCl17CT8CONkeI6uCrFl34ojW1xvupP5k/SJSatMPJsUUNdOzo17/HdcDp1i OARUXb2X+6hnsR3nHoqINl8pFkEwP32PKQMknvRAyL3ANZ1ye9AhNbrK4T2nCGihmUoO HlmieDXdaEWKzykA7mlQE3BczQl1XYW8kaU0NZDx/cYF9vlQf+crv1rjRp9jOeARf3ya ZlFsGRHgT3PO9GDmnrOVisQw3vnqY6+/kekdQbnh+VqRWbOFeZvMq5i3S8lkSAla6neW AaaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:subject:user-agent:message-id :references:cc:in-reply-to:from:to:content-transfer-encoding :mime-version; bh=aKNam9dMZN9mA6KZ51jQO0xjsntRLmGCNRlKCusw2NM=; b=jlJyrz6vFb/Y6jqmRBdxiEUCpXN5ZlaQ4UjDErM42zjvFOkCWnf+ywQ178FxFb3y1k FtF8GSzgkDyVc4oiyFt6MBHDYDq12piEHqVqGJ1GnaBShonDFrLDrtvKVnVxy/SrvxbZ bey4Qym3bfApRIvYuDSzrpAcvEJBDwTcOpQel0D0v/8y+ZHYqAXbIRZWKyM3bfjrndoG o8hLOZaWGze13qi4OIvwo7w9Rsh3c9VS8jGKTIL7AAwK11viyNCSh0IQ3t0oUq0qCeRz rqF31NxYyLRQyBrzdI9mCP/SONKw//HFCJmCfsN2hsQDAIhWhLa51QDZ8WgMVam2KpUN xhnA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i6si3836967pfb.122.2019.08.23.16.38.38; Fri, 23 Aug 2019 16:38:53 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392155AbfHWTxi convert rfc822-to-8bit (ORCPT + 99 others); Fri, 23 Aug 2019 15:53:38 -0400 Received: from mail.fireflyinternet.com ([109.228.58.192]:57675 "EHLO fireflyinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2392123AbfHWTxh (ORCPT ); Fri, 23 Aug 2019 15:53:37 -0400 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from localhost (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP (TLS) id 18244603-1500050 for multiple; Fri, 23 Aug 2019 20:53:34 +0100 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT To: Lyude Paul , intel-gfx@lists.freedesktop.org From: Chris Wilson In-Reply-To: <20190822203127.24648-1-lyude@redhat.com> Cc: stable@vger.kernel.org, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , Daniel Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20190822203127.24648-1-lyude@redhat.com> Message-ID: <156659001202.4019.17272565895689332680@skylake-alporthouse-com> User-Agent: alot/0.6 Subject: Re: [PATCH v2 1/2] drm/i915: Call dma_set_max_seg_size() in i915_ggtt_probe_hw() Date: Fri, 23 Aug 2019 20:53:32 +0100 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Lyude Paul (2019-08-22 21:31:26) > Currently, we don't call dma_set_max_seg_size() for i915 because we > intentionally do not limit the segment length that the device supports. > However, this results in a warning being emitted if we try to map > anything larger than SZ_64K on a kernel with CONFIG_DMA_API_DEBUG_SG > enabled: > > [ 7.751926] DMA-API: i915 0000:00:02.0: mapping sg segment longer > than device claims to support [len=98304] [max=65536] > [ 7.751934] WARNING: CPU: 5 PID: 474 at kernel/dma/debug.c:1220 > debug_dma_map_sg+0x20f/0x340 > > This was originally brought up on > https://bugs.freedesktop.org/show_bug.cgi?id=108517 , and the consensus > there was it wasn't really useful to set a limit (and that dma-debug > isn't really all that useful for i915 in the first place). Unfortunately > though, CONFIG_DMA_API_DEBUG_SG is enabled in the debug configs for > various distro kernels. Since a WARN_ON() will disable automatic problem > reporting (and cause any CI with said option enabled to start > complaining), we really should just fix the problem. > > Note that as me and Chris Wilson discussed, the other solution for this > would be to make DMA-API not make such assumptions when a driver hasn't > explicitly set a maximum segment size. But, taking a look at the commit > which originally introduced this behavior, commit 78c47830a5cb > ("dma-debug: check scatterlist segments"), there is an explicit mention > of this assumption and how it applies to devices with no segment size: > > Conversely, devices which are less limited than the rather > conservative defaults, or indeed have no limitations at all > (e.g. GPUs with their own internal MMU), should be encouraged to > set appropriate dma_parms, as they may get more efficient DMA > mapping performance out of it. > > So unless there's any concerns (I'm open to discussion!), let's just > follow suite and call dma_set_max_seg_size() with UINT_MAX as our limit > to silence any warnings. > > Signed-off-by: Lyude Paul > Cc: Chris Wilson > Cc: # v4.18+ > --- > drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c > index 0b81e0b64393..a1475039d182 100644 > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > @@ -3152,6 +3152,11 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct intel_gt *gt) > if (ret) > return ret; > > + /* We don't have a max segment size, so set it to the max so sg's > + * debugging layer doesn't complain > + */ > + dma_set_max_seg_size(ggtt->vm.dma, UINT_MAX); The rest of the dma setup is in i915_driver_hw_probe, so I would put it there just after dma_set_coherent_mask() (maybe one day even being brave enough to pull out those to their own function). I think I've made my point about the futility of dma-debug and you've made yours about the simplicity of the patch to shut it up, so move it across and Reviewed-by: Chris Wilson -Chris