Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp8986330ybi; Tue, 23 Jul 2019 19:30:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqyk6w6RbY82o8/c7fxwTAVTCxrQKN5j+e3r5t+Jxdd0x5Moknac/YuqparmULMMmXsxNUVo X-Received: by 2002:a65:6691:: with SMTP id b17mr63919528pgw.217.1563935448724; Tue, 23 Jul 2019 19:30:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563935448; cv=none; d=google.com; s=arc-20160816; b=O8AxWuZdTaAcIcKgQmLNj4pm3duoc49O0iJs0/b5FOwZtGmUJxqMB0r8GSmKaviaqE dzAoP2XZ5V5Q7sAF8URSUsXa3gGzvubGnvhGHUSePIB98yUYE/0KPT50GBYuN7b75lOH mH+UVIYojDwJav5KqV/bYpWERV7LG6ftjX3qDqjtgDSfNt7KqqSmMxMVP6s+bR59MIiG j9zmLLmgxj0CJ+eGH/xNcY1VlNOndY2XIFJ/Q2D0CX6ARBbsZ2yqtf8FS1RZ9hEmWQDz 6RZBuvyGZhNuIsIobzbqcTUQCcpXn9FHj7OHKPsk+PYSQNcysTUWN63lEEwT6jHKfjNf DrvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=tUGsIMqs+SNwG7Wa9YryBNQpEKIGP6cwaQO1e+qGdxc=; b=Ms37Pcb/KFvkwWQcrP2aPgFon0yuyBfx8vJKbxFgt/0v2twAhgM6W1c0UsDHhMZxGW 5fxQ3IC4CnhwnC1X8KZ9dYAN5NHbLkpy0ktaDzYAXamp6IEd9b3Y/NjQh+eSCjtv5aLa RcTsnDkLSXqdPUARq8R5JOXl6Ecv9vKS8gWlF5i7oQZSEJaELfKVLdPnUkFjuSTT+mjZ XE0TG7gQ6OjQGguhhEW4hbmrshFs+RjgGBTx6CI+ZKYdoLjyQ+J5fOwgiGhWvXjzIcU4 dd9k8iLeLL+ZM0f9VHwUfEtS6wjsAuWot22J5os//vyRsVptAs3yg7NZeH4WyXBHZUPH tPJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UDPrieZ6; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 68si11612249ple.89.2019.07.23.19.30.33; Tue, 23 Jul 2019 19:30:48 -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=@gmail.com header.s=20161025 header.b=UDPrieZ6; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729177AbfGWUKI (ORCPT + 99 others); Tue, 23 Jul 2019 16:10:08 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:38196 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726343AbfGWUKH (ORCPT ); Tue, 23 Jul 2019 16:10:07 -0400 Received: by mail-ed1-f67.google.com with SMTP id r12so10299939edo.5 for ; Tue, 23 Jul 2019 13:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tUGsIMqs+SNwG7Wa9YryBNQpEKIGP6cwaQO1e+qGdxc=; b=UDPrieZ62DZ2mz2+GrBJZ4KAevDIjPajIqVhkjl2OjmbVFtwXQggxYhH/QuuJAvk35 1T6VBw9/33sOIL8raiWYoSMHWLIko/lgbzkxEZPp9dZ4Xn0O3GitxItv4t5EeELcg3tY V07jYxMBs4xXkAKNMyzbedqrCkl1yYzHG+0W2sfZIK7dKnDXnurviMo/kO+47YSr/t3p 8LLJpiV1smiHKIiCDXDYCNc8IBPKlmCd1dGasujo7jS02GhqaVxBKFTurNAKtZiC7Rd4 SHGu7j6p/OvE0lU1fUJFFIyKieaxXKU98sxS/cdL0mE+7/uyW5G6zWVvZKRdwXbKIWwl GK3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tUGsIMqs+SNwG7Wa9YryBNQpEKIGP6cwaQO1e+qGdxc=; b=GAF/9n7RK67HF9kTr9aiWs7vib9vZ4VREL8432HNM/43JS64WLtjnPm54be7aQFYGL F9Rm/Qv7FdV/dsn7oKKx/LaNufdNPp40RnGiZnTYqPUvxSA1mpjEJZB7WvjKjfcZ1b74 BekdYxagGS1CVo8DJOlVl9mPVCikszqIp0BG+X0utCuAJvUtUpxNj/r8mvnJPOxgaSZQ 1GaCpGFKjl1DcI72aDdn0atx0iHs4jFQq09lSVXtEWyKMmj9T1dXvomIiFaTmHIDBQhX AmZvv8Lb+DtBblSBOVTFgZr0+zO95Nikc9/yfSfNCf8J8+wBrQR1daaAH60FF8jN21N4 pgfA== X-Gm-Message-State: APjAAAWqG6m0Lxlte00H1lfZiJokzvZ4qlSqwxwhxwCx6YCWyTWNhxvx uwIaIyjohliONu9gxWBHV5XocXsdLmeZHzzENqY= X-Received: by 2002:a17:906:f85:: with SMTP id q5mr60616455ejj.192.1563912606283; Tue, 23 Jul 2019 13:10:06 -0700 (PDT) MIME-Version: 1.0 References: <20190624194908.121273-1-john.stultz@linaro.org> <20190624194908.121273-3-john.stultz@linaro.org> <20190718100654.GA19666@infradead.org> In-Reply-To: From: Rob Clark Date: Tue, 23 Jul 2019 13:09:55 -0700 Message-ID: Subject: Re: [PATCH v6 2/5] dma-buf: heaps: Add heap helpers To: John Stultz Cc: Christoph Hellwig , lkml , Laura Abbott , Benjamin Gaignard , Sumit Semwal , Liam Mark , Pratik Patel , Brian Starkey , Vincent Donnefort , Sudipto Paul , "Andrew F . Davis" , Xu YiPing , "Chenfeng (puck)" , butao , "Xiaqing (A)" , Yudongbin , Chenbo Feng , Alistair Strachan , dri-devel , Hridya Valsaraju Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 22, 2019 at 9:09 PM John Stultz wrote: > > On Thu, Jul 18, 2019 at 3:06 AM Christoph Hellwig wrote: > > > > Is there any exlusion between mmap / vmap and the device accessing > > the data? Without that you are going to run into a lot of coherency > > problems. dma_fence is basically the way to handle exclusion between different device access (since device access tends to be asynchronous). For device<->device access, each driver is expected to take care of any cache(s) that the device might have. (Ie. device writing to buffer should flush it's caches if needed before signalling fence to let reading device know that it is safe to read, etc.) _begin/end_cpu_access() is intended to be the exclusion for CPU access (which is synchronous) BR, -R > This has actually been a concern of mine recently, but at the higher > dma-buf core level. Conceptually, there is the > dma_buf_map_attachment() and dma_buf_unmap_attachment() calls drivers > use to map the buffer to an attached device, and there are the > dma_buf_begin_cpu_access() and dma_buf_end_cpu_access() calls which > are to be done when touching the cpu mapped pages. These look like > serializing functions, but actually don't seem to have any enforcement > mechanism to exclude parallel access. > > To me it seems like adding the exclusion between those operations > should be done at the dmabuf core level, and would actually be helpful > for optimizing some of the cache maintenance rules w/ dmabuf. Does > this sound like something closer to what your suggesting, or am I > misunderstanding your point? > > Again, I really appreciate the review and feedback! > > Thanks so much! > -john