Received: by 10.192.165.156 with SMTP id m28csp813117imm; Wed, 11 Apr 2018 07:40:10 -0700 (PDT) X-Google-Smtp-Source: AIpwx490gcfPDdZW8yOavg0LsH7AP+DixdAGHbYXlx4kDnUex1MJyrx6tDJTNjWYN0K6niX1y6k+ X-Received: by 2002:a17:902:748a:: with SMTP id h10-v6mr5494445pll.160.1523457610100; Wed, 11 Apr 2018 07:40:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523457609; cv=none; d=google.com; s=arc-20160816; b=BUZeXPA5sqJrUIS64MBwvI2/QmGxbVmO/Glz9lOlQP3m7TQHWPamAygNg4XU2m7pHM EHbjpL/UugWcKhPMwsufozzVUqUwkHtCRmmm5+owTgcco9zYwfKxo0FJjoF2mX32eRKP xbjC68eHHaUFWkF0tHr38UPnb4fC4DeOOO0HXZkBZZ3UCfqTo0sPYheo1uoBOxwOP/7X xMFyZIbmHzZiAAHBOdvGXoEmaydnp2Ruic74vXDw6SlKAPzioI9qfPYp9tlEniX8rxXu EZjq0hFy965g1mfKd123wD06t9ZZhRLx7DMBchP36y6zRWlRZZg8fptYM0AqfayZc2AW GdRg== 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:dmarc-filter :dkim-signature:dkim-signature:arc-authentication-results; bh=FLQHwecKQWoVJ3XrrDLmD2e5I20XZX5Be+Gp62volvk=; b=XOVN+v6TKftq0ivWQMWj8laIQP4QzCUhurk81tl26hktk2vfln59fYvMH+f0pJqVIW ocFBHzv9ak9y2CW1t7yC5Zn8XCOogXgXQfzgpNdW9mZcxh2pb+kaY9Ytfr5klGNIfc+A XrpRYI6U2g9fwdEqzF9SRpSaopxgvyHFEQMAHFkKxl4zaKkxQeBprQraeRFtT802Zhgo JG386qJf4kPyAmxBfGEDYKL0YMQjlVXj6pbqmIdp6kKp2jI7tLe3mmXiHoSUGKbK2i7k ZAEo0OYaK/ixpWWtjWoNBBqcIef/9wGSHRTYFgbpcrKlRv30fn4UVxM1bnSm3JVhBSMy yX4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=FxncYeKP; dkim=pass header.i=@codeaurora.org header.s=default header.b=P76Pf94z; 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 y11-v6si1153661pln.525.2018.04.11.07.39.33; Wed, 11 Apr 2018 07:40:09 -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; dkim=pass header.i=@codeaurora.org header.s=default header.b=FxncYeKP; dkim=pass header.i=@codeaurora.org header.s=default header.b=P76Pf94z; 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 S1753639AbeDKOdW (ORCPT + 99 others); Wed, 11 Apr 2018 10:33:22 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:38646 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753347AbeDKOdS (ORCPT ); Wed, 11 Apr 2018 10:33:18 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 2F0D160F72; Wed, 11 Apr 2018 14:33:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1523457198; bh=N/Cnc0ZMHkP2hvZMaXDNbAlM+PaEXy/TRU2VZ0blYtE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FxncYeKPBtJDWdFYiQKN5TidC5z2h/BMwxfLFRTgxb2fWeaCs8vsTl1ng4DqOi8Y/ 5I65fSnReDRQqecvjkv7Ns46wjtDpGFEQkFD2iMQa/Ru8zZxJmU6LElgyt5gcmmS0I Ot84m0IBeRwQj7ns4KHmoHA9lt1Lk3rd288KqXp0= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from [10.235.228.150] (global_nat1_iad_fw.qualcomm.com [129.46.232.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: okaya@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 49914603AF; Wed, 11 Apr 2018 14:33:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1523457197; bh=N/Cnc0ZMHkP2hvZMaXDNbAlM+PaEXy/TRU2VZ0blYtE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=P76Pf94zdlsTF0gWxZzrBlR9F0d63/ilm9hf7WrkTnMZviOBJ//6w8Z2TbBa9I0rQ RGl3KhcjFUIRI/YgZjcSXUWWhl+fLZdXa/G+lCyPNc7v9MCDiDG8IsoDy6zK+01vfL MT0q03Q67s7HTiAnbx5ewBlzZhnmOLRX+k7UAXm4= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 49914603AF Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=okaya@codeaurora.org Subject: Re: [PATCH V2] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers To: Robin Murphy , amd-gfx@lists.freedesktop.org, timur@codeaurora.org, sulrich@codeaurora.org Cc: Tom St Denis , "David (ChunMing) Zhou" , Emily Deng , David Airlie , linux-arm-msm@vger.kernel.org, Felix Kuehling , open list , "open list:DRM DRIVERS" , David Panariti , Jim Qu , Huang Rui , Roger He , Monk Liu , Feifei Xu , Alex Deucher , =?UTF-8?Q?Christian_K=c3=b6nig?= , linux-arm-kernel@lists.infradead.org, iommu@lists.linux-foundation.org, hch@lst.de References: <1523394001-4615-1-git-send-email-okaya@codeaurora.org> <32b82296-bba5-b5f1-266b-45c1ed66da94@arm.com> From: Sinan Kaya Message-ID: <1a1d0069-c8d3-cc0d-cf1c-8e90e4a2b0d7@codeaurora.org> Date: Wed, 11 Apr 2018 10:33:14 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <32b82296-bba5-b5f1-266b-45c1ed66da94@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/11/2018 8:03 AM, Robin Murphy wrote: > On 10/04/18 21:59, Sinan Kaya wrote: >> Code is expecing to observe the same number of buffers returned from >> dma_map_sg() function compared to sg_alloc_table_from_pages(). This >> doesn't hold true universally especially for systems with IOMMU. > > So why not fix said code? It's clearly not a real hardware limitation, and the map_sg() APIs have potentially returned fewer than nents since forever, so there's really no excuse. Sure, I'll take a better fix if there is one. > >> IOMMU driver tries to combine buffers into a single DMA address as much >> as it can. The right thing is to tell the DMA layer how much combining >> IOMMU can do. > > Disagree; this is a dodgy hack, since you'll now end up passing scatterlists into dma_map_sg() which already violate max_seg_size to begin with, and I think a conscientious DMA API implementation would be at rights to fail the mapping for that reason (I know arm64 happens not to, but that was a deliberate design decision to make my life easier at the time). > > As a short-term fix, at least do something like what i915 does and constrain the table allocation to the desired segment size as well, so things remain self-consistent. But still never claim that faking a hardware constraint as a workaround for a driver shortcoming is "the right thing to do" ;) You are asking for something like this from here, right? https://elixir.bootlin.com/linux/v4.16.1/source/drivers/gpu/drm/i915/i915_gem_dmabuf.c#L58 ret = sg_alloc_table(st, obj->mm.pages->nents, GFP_KERNEL); if (ret) goto err_free; src = obj->mm.pages->sgl; dst = st->sgl; for (i = 0; i < obj->mm.pages->nents; i++) { sg_set_page(dst, sg_page(src), src->length, 0); dst = sg_next(dst); src = sg_next(src); } This seems to allocate the scatter gather list and fill it in manually before passing it to dma_map_sg(). I'll give it a try. Just double checking. > > Robin. > >> Signed-off-by: Sinan Kaya -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.