From: "Andrew F. Davis" <afd@ti.com> To: Liam Mark <lmark@codeaurora.org> Cc: Christoph Hellwig <hch@infradead.org>, Laura Abbott <labbott@redhat.com>, <sumit.semwal@linaro.org>, <arve@android.com>, <tkjos@android.com>, <maco@android.com>, <joel@joelfernandes.org>, <christian@brauner.io>, <devel@driverdev.osuosl.org>, <dri-devel@lists.freedesktop.org>, <linaro-mm-sig@lists.linaro.org>, <linux-kernel@vger.kernel.org>, <john.stultz@linaro.org> Subject: Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes Date: Mon, 21 Jan 2019 14:24:09 -0600 [thread overview] Message-ID: <4925c9db-fc73-1ccb-1766-ef68d014d55a@ti.com> (raw) In-Reply-To: <alpine.DEB.2.10.1901211214570.11004@lmark-linux.qualcomm.com> On 1/21/19 2:20 PM, Liam Mark wrote: > On Mon, 21 Jan 2019, Andrew F. Davis wrote: > >> On 1/21/19 1:44 PM, Liam Mark wrote: >>> On Mon, 21 Jan 2019, Christoph Hellwig wrote: >>> >>>> On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote: >>>>>> And who is going to decide which ones to pass? And who documents >>>>>> which ones are safe? >>>>>> >>>>>> I'd much rather have explicit, well documented dma-buf flags that >>>>>> might get translated to the DMA API flags, which are not error checked, >>>>>> not very well documented and way to easy to get wrong. >>>>>> >>>>> >>>>> I'm not sure having flags in dma-buf really solves anything >>>>> given drivers can use the attributes directly with dma_map >>>>> anyway, which is what we're looking to do. The intention >>>>> is for the driver creating the dma_buf attachment to have >>>>> the knowledge of which flags to use. >>>> >>>> Well, there are very few flags that you can simply use for all calls of >>>> dma_map*. And given how badly these flags are defined I just don't want >>>> people to add more places where they indirectly use these flags, as >>>> it will be more than enough work to clean up the current mess. >>>> >>>> What flag(s) do you want to pass this way, btw? Maybe that is where >>>> the problem is. >>>> >>> >>> The main use case is for allowing clients to pass in >>> DMA_ATTR_SKIP_CPU_SYNC in order to skip the default cache maintenance >>> which happens in dma_buf_map_attachment and dma_buf_unmap_attachment. In >>> ION the buffers aren't usually accessed from the CPU so this allows >>> clients to often avoid doing unnecessary cache maintenance. >>> >> >> How can a client know that no CPU access has occurred that needs to be >> flushed out? >> > > I have left this to clients, but if they own the buffer they can have the > knowledge as to whether CPU access is needed in that use case (example for > post-processing). > > For example with the previous version of ION we left all decisions of > whether cache maintenance was required up to the client, they would use > the ION cache maintenance IOCTL to force cache maintenance only when it > was required. > In these cases almost all of the access was being done by the device and > in the rare cases CPU access was required clients would initiate the > required cache maintenance before and after the CPU access. > I think we have different definitions of "client", I'm talking about the DMA-BUF client (the importer), that is who can set this flag. It seems you mean the userspace application, which has no control over this flag. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project >
WARNING: multiple messages have this Message-ID (diff)
From: "Andrew F. Davis" <afd@ti.com> To: Liam Mark <lmark@codeaurora.org> Cc: devel@driverdev.osuosl.org, linaro-mm-sig@lists.linaro.org, tkjos@android.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Christoph Hellwig <hch@infradead.org>, arve@android.com, john.stultz@linaro.org, joel@joelfernandes.org, maco@android.com, sumit.semwal@linaro.org, christian@brauner.io Subject: Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes Date: Mon, 21 Jan 2019 14:24:09 -0600 [thread overview] Message-ID: <4925c9db-fc73-1ccb-1766-ef68d014d55a@ti.com> (raw) In-Reply-To: <alpine.DEB.2.10.1901211214570.11004@lmark-linux.qualcomm.com> On 1/21/19 2:20 PM, Liam Mark wrote: > On Mon, 21 Jan 2019, Andrew F. Davis wrote: > >> On 1/21/19 1:44 PM, Liam Mark wrote: >>> On Mon, 21 Jan 2019, Christoph Hellwig wrote: >>> >>>> On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote: >>>>>> And who is going to decide which ones to pass? And who documents >>>>>> which ones are safe? >>>>>> >>>>>> I'd much rather have explicit, well documented dma-buf flags that >>>>>> might get translated to the DMA API flags, which are not error checked, >>>>>> not very well documented and way to easy to get wrong. >>>>>> >>>>> >>>>> I'm not sure having flags in dma-buf really solves anything >>>>> given drivers can use the attributes directly with dma_map >>>>> anyway, which is what we're looking to do. The intention >>>>> is for the driver creating the dma_buf attachment to have >>>>> the knowledge of which flags to use. >>>> >>>> Well, there are very few flags that you can simply use for all calls of >>>> dma_map*. And given how badly these flags are defined I just don't want >>>> people to add more places where they indirectly use these flags, as >>>> it will be more than enough work to clean up the current mess. >>>> >>>> What flag(s) do you want to pass this way, btw? Maybe that is where >>>> the problem is. >>>> >>> >>> The main use case is for allowing clients to pass in >>> DMA_ATTR_SKIP_CPU_SYNC in order to skip the default cache maintenance >>> which happens in dma_buf_map_attachment and dma_buf_unmap_attachment. In >>> ION the buffers aren't usually accessed from the CPU so this allows >>> clients to often avoid doing unnecessary cache maintenance. >>> >> >> How can a client know that no CPU access has occurred that needs to be >> flushed out? >> > > I have left this to clients, but if they own the buffer they can have the > knowledge as to whether CPU access is needed in that use case (example for > post-processing). > > For example with the previous version of ION we left all decisions of > whether cache maintenance was required up to the client, they would use > the ION cache maintenance IOCTL to force cache maintenance only when it > was required. > In these cases almost all of the access was being done by the device and > in the rare cases CPU access was required clients would initiate the > required cache maintenance before and after the CPU access. > I think we have different definitions of "client", I'm talking about the DMA-BUF client (the importer), that is who can set this flag. It seems you mean the userspace application, which has no control over this flag. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project >
next prev parent reply other threads:[~2019-01-21 20:24 UTC|newest] Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-18 18:37 [PATCH 0/4] ION stability and perf changes Liam Mark 2019-01-18 18:37 ` [PATCH 1/4] staging: android: ion: Support cpu access during dma_buf_detach Liam Mark 2019-01-18 18:37 ` Liam Mark 2019-01-18 19:34 ` Andrew F. Davis 2019-01-18 19:34 ` Andrew F. Davis 2019-01-18 20:40 ` Laura Abbott 2019-01-18 18:37 ` [PATCH 2/4] staging: android: ion: Restrict cache maintenance to dma mapped memory Liam Mark 2019-01-18 18:37 ` Liam Mark 2019-01-18 20:20 ` Andrew F. Davis 2019-01-18 20:20 ` Andrew F. Davis 2019-01-18 21:18 ` Liam Mark 2019-01-18 21:18 ` Liam Mark 2019-01-29 23:44 ` Liam Mark 2019-01-29 23:44 ` Liam Mark 2019-01-30 11:31 ` Brian Starkey 2019-01-30 11:31 ` Brian Starkey 2019-02-06 15:40 ` [Linaro-mm-sig] " Ørjan Eide 2019-02-07 7:31 ` Christoph Hellwig 2019-02-07 7:31 ` Christoph Hellwig 2019-02-07 15:45 ` Ørjan Eide 2019-02-28 23:49 ` Liam Mark 2019-01-30 14:31 ` Andrew F. Davis 2019-01-30 14:31 ` Andrew F. Davis 2019-01-18 18:37 ` [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes Liam Mark 2019-01-18 18:37 ` Liam Mark 2019-01-18 20:48 ` Laura Abbott 2019-01-18 21:32 ` Liam Mark 2019-01-18 22:45 ` Laura Abbott 2019-01-18 22:45 ` Laura Abbott 2019-01-19 10:25 ` Christoph Hellwig 2019-01-19 10:25 ` Christoph Hellwig 2019-01-19 16:50 ` Laura Abbott 2019-01-21 8:30 ` Christoph Hellwig 2019-01-21 19:44 ` Liam Mark 2019-01-21 19:49 ` Andrew F. Davis 2019-01-21 19:49 ` Andrew F. Davis 2019-01-21 20:20 ` Liam Mark 2019-01-21 20:24 ` Andrew F. Davis [this message] 2019-01-21 20:24 ` Andrew F. Davis 2019-01-21 22:18 ` Liam Mark 2019-01-22 15:42 ` Andrew F. Davis 2019-01-22 15:42 ` Andrew F. Davis 2019-01-22 22:47 ` Liam Mark 2019-01-22 22:47 ` Liam Mark 2019-01-21 21:30 ` Christoph Hellwig 2019-01-21 22:14 ` Liam Mark 2019-01-21 22:14 ` Liam Mark 2019-01-21 21:29 ` Christoph Hellwig 2019-01-21 21:29 ` Christoph Hellwig 2019-01-21 22:12 ` Liam Mark 2019-01-21 22:12 ` Liam Mark 2019-01-22 16:06 ` Andrew F. Davis 2019-01-22 16:06 ` Andrew F. Davis 2019-01-22 22:50 ` Liam Mark 2019-01-18 18:37 ` [PATCH 4/4] staging: android: ion: Support " Liam Mark 2019-01-18 18:37 ` Liam Mark 2019-01-21 12:19 ` Brian Starkey 2019-01-21 12:19 ` Brian Starkey 2019-01-22 22:37 ` Liam Mark
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4925c9db-fc73-1ccb-1766-ef68d014d55a@ti.com \ --to=afd@ti.com \ --cc=arve@android.com \ --cc=christian@brauner.io \ --cc=devel@driverdev.osuosl.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=hch@infradead.org \ --cc=joel@joelfernandes.org \ --cc=john.stultz@linaro.org \ --cc=labbott@redhat.com \ --cc=linaro-mm-sig@lists.linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lmark@codeaurora.org \ --cc=maco@android.com \ --cc=sumit.semwal@linaro.org \ --cc=tkjos@android.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.