Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1986766pxk; Tue, 1 Sep 2020 12:37:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzIHFZdRLX849/9B/koe8A7Ms5FhKnLABlSPCL21dJad3QSzzO6cgHz+3X/3YjMhUbBwGFx X-Received: by 2002:a17:906:7715:: with SMTP id q21mr3031810ejm.251.1598989045569; Tue, 01 Sep 2020 12:37:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598989045; cv=none; d=google.com; s=arc-20160816; b=gQNc2hUWbDahhVKM7oP+ycPUYphvKN7AMOjzpVh1jSbs2aIV1DJBl+830nuSyiWT3G RR547+ZCHqm6eWILkEvO0eANqZZJvcrsnt57/3dWFFjGQeZkxEKPiisylJjxbE5d9tfm 5Ea+CupZ5HQsX8KSljokL6p0ThRlnDSVXfXTiMw64bolj2duVt4GqA841zD45jfjc4Wt LFXlDj9WfbjpAq0n7vPK+t0do4MmFZLHSYpcBbRuEFuarcJ9p/71YEcbUKkWEjKeyc28 F1YHj5qvXzUDIe8wwDjZfO5SrXlS7EZC2qpeHnG1AUOLJlmsHV9nJnvarPW96gYGy6OX IUmA== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=ZkKlRXEMUG1+IKTVCgOLHe3X31s7vXiSnzJb7w3hzLA=; b=FKvTLeu+ESviwAaEEYuXG+ysQOvNS9+oJLSfP7pf3IVXfidj+kyqCEYn4Xw8/wUZcm 8M9k1B2GI6WvWoDcc5c1d1PqMJQa3o4j1Ln2arLTLho9a6m1PSfiRv1Zogx8qI/wPDVa abPSrxgLGaJ/gFPD5p6wBoTg8DaXRDMfa1FD3rFJZrZVKL4u/PgxouI94nvX3RKWhx9q UZxzzyaf8GEIeAieMeJNeg8CkbBARH3Zzyo4tezWVlvGHyz3Gg5SpGTps9OuGa9HVg99 egRoNeAOxxpu0yIvrY68l662TLEUxFg7Ks6O88Oy48B1BrLbD/B93yMvif0hBB3NgXOo 5onQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i3si1092908eds.570.2020.09.01.12.36.38; Tue, 01 Sep 2020 12:37:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728329AbgIATdd (ORCPT + 99 others); Tue, 1 Sep 2020 15:33:33 -0400 Received: from foss.arm.com ([217.140.110.172]:48924 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726102AbgIATdd (ORCPT ); Tue, 1 Sep 2020 15:33:33 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 67D051FB; Tue, 1 Sep 2020 12:33:32 -0700 (PDT) Received: from [10.57.40.122] (unknown [10.57.40.122]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id ABCE13F71F; Tue, 1 Sep 2020 12:33:30 -0700 (PDT) Subject: Re: [PATCH v9 14/32] drm: omapdrm: fix common struct sg_table related issues To: Marek Szyprowski , dri-devel@lists.freedesktop.org, iommu@lists.linux-foundation.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org Cc: Christoph Hellwig , Bartlomiej Zolnierkiewicz , linux-arm-kernel@lists.infradead.org, David Airlie , Daniel Vetter , Tomi Valkeinen References: <20200826063316.23486-1-m.szyprowski@samsung.com> <20200826063316.23486-15-m.szyprowski@samsung.com> From: Robin Murphy Message-ID: <7298cc55-c550-0b41-3f3c-8eebed845848@arm.com> Date: Tue, 1 Sep 2020 20:33:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20200826063316.23486-15-m.szyprowski@samsung.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-08-26 07:32, Marek Szyprowski wrote: > The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function > returns the number of the created entries in the DMA address space. > However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and > dma_unmap_sg must be called with the original number of the entries > passed to the dma_map_sg(). > > struct sg_table is a common structure used for describing a non-contiguous > memory buffer, used commonly in the DRM and graphics subsystems. It > consists of a scatterlist with memory pages and DMA addresses (sgl entry), > as well as the number of scatterlist entries: CPU pages (orig_nents entry) > and DMA mapped pages (nents entry). > > It turned out that it was a common mistake to misuse nents and orig_nents > entries, calling DMA-mapping functions with a wrong number of entries or > ignoring the number of mapped entries returned by the dma_map_sg() > function. > > Fix the code to refer to proper nents or orig_nents entries. This driver > checks for a buffer contiguity in DMA address space, so it should test > sg_table->nents entry. > > Signed-off-by: Marek Szyprowski > --- > drivers/gpu/drm/omapdrm/omap_gem.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c b/drivers/gpu/drm/omapdrm/omap_gem.c > index ff0c4b0c3fd0..a7a9a0afe2b6 100644 > --- a/drivers/gpu/drm/omapdrm/omap_gem.c > +++ b/drivers/gpu/drm/omapdrm/omap_gem.c > @@ -48,7 +48,7 @@ struct omap_gem_object { > * OMAP_BO_MEM_DMA_API flag set) > * > * - buffers imported from dmabuf (with the OMAP_BO_MEM_DMABUF flag set) > - * if they are physically contiguous (when sgt->orig_nents == 1) > + * if they are physically contiguous (when sgt->nents == 1) Hmm, if this really does mean *physically* contiguous - i.e. if buffers might be shared between DMA-translatable and non-DMA-translatable devices - then these changes might not be appropriate. If not and it only actually means DMA-contiguous, then it would be good to clarify the comments to that effect. Can anyone familiar with omapdrm clarify what exactly the case is here? I know that IOMMUs might be involved to some degree, and I've skimmed the interconnect chapters of enough OMAP TRMs to be scared by the reference to the tiler aperture in the context below :) Robin. > * > * - buffers mapped through the TILER when dma_addr_cnt is not zero, in > * which case the DMA address points to the TILER aperture > @@ -1279,7 +1279,7 @@ struct drm_gem_object *omap_gem_new_dmabuf(struct drm_device *dev, size_t size, > union omap_gem_size gsize; > > /* Without a DMM only physically contiguous buffers can be supported. */ > - if (sgt->orig_nents != 1 && !priv->has_dmm) > + if (sgt->nents != 1 && !priv->has_dmm) > return ERR_PTR(-EINVAL); > > gsize.bytes = PAGE_ALIGN(size); > @@ -1293,7 +1293,7 @@ struct drm_gem_object *omap_gem_new_dmabuf(struct drm_device *dev, size_t size, > > omap_obj->sgt = sgt; > > - if (sgt->orig_nents == 1) { > + if (sgt->nents == 1) { > omap_obj->dma_addr = sg_dma_address(sgt->sgl); > } else { > /* Create pages list from sgt */ >