From: John Stultz <john.stultz@linaro.org> To: Christoph Hellwig <hch@infradead.org> Cc: lkml <linux-kernel@vger.kernel.org>, Laura Abbott <labbott@redhat.com>, Benjamin Gaignard <benjamin.gaignard@linaro.org>, Sumit Semwal <sumit.semwal@linaro.org>, Liam Mark <lmark@codeaurora.org>, Pratik Patel <pratikp@codeaurora.org>, Brian Starkey <Brian.Starkey@arm.com>, Vincent Donnefort <Vincent.Donnefort@arm.com>, Sudipto Paul <Sudipto.Paul@arm.com>, "Andrew F . Davis" <afd@ti.com>, Xu YiPing <xuyiping@hisilicon.com>, "Chenfeng (puck)" <puck.chen@hisilicon.com>, butao <butao@hisilicon.com>, "Xiaqing (A)" <saberlily.xia@hisilicon.com>, Yudongbin <yudongbin@hisilicon.com>, Chenbo Feng <fengc@google.com>, Alistair Strachan <astrachan@google.com>, dri-devel <dri-devel@lists.freedesktop.org> Subject: Re: [PATCH v6 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps Date: Wed, 24 Jul 2019 11:46:24 -0700 [thread overview] Message-ID: <CALAqxLUbsz+paJ=P2hwKecuN8DQjJt9Vj4MENCnFuEh6waxsXg@mail.gmail.com> (raw) In-Reply-To: <20190724065958.GC16225@infradead.org> On Wed, Jul 24, 2019 at 12:00 AM Christoph Hellwig <hch@infradead.org> wrote: > On Mon, Jul 22, 2019 at 10:04:06PM -0700, John Stultz wrote: > > Apologies, I'm not sure I'm understanding your suggestion here. > > dma_alloc_contiguous() does have some interesting optimizations > > (avoiding allocating single page from cma), though its focus on > > default area vs specific device area doesn't quite match up the usage > > model for dma heaps. Instead of allocating memory for a single > > device, we want to be able to allow userland, for a given usage mode, > > to be able to allocate a dmabuf from a specific heap of memory which > > will satisfy the usage mode for that buffer pipeline (across multiple > > devices). > > > > Now, indeed, the system and cma heaps in this patchset are a bit > > simple/trivial (though useful with my devices that require contiguous > > buffers for the display driver), but more complex ION heaps have > > traditionally stayed out of tree in vendor code, in many cases making > > incompatible tweaks to the ION core dmabuf exporter logic. > > So what would the more complicated heaps be? Mostly secure heaps, but there have been work in the past with specially aligned chunk heaps in the past. Unfortunately since every vendor tree also include many of their own hacks to the core ION code (usually without changelogs or comments) its hard to decipher much of it. Some examples: msm: https://github.com/Panchajanya1999/msm-4.14/blob/Pie/drivers/staging/android/ion/ion_cma_secure_heap.c exynos: https://github.com/exynos-linux-stable/starlte/tree/tw90-android-p/drivers/staging/android/ion/exynos hisi: https://github.com/hexdebug/android_kernel_huawei_hi3660/blob/master/drivers/staging/android/ion/ion_seccm_heap.c https://github.com/hexdebug/android_kernel_huawei_hi3660/blob/master/drivers/staging/android/ion/ion_secsg_heap.c https://github.com/hexdebug/android_kernel_huawei_hi3660/blob/master/drivers/staging/android/ion/ion_fama_misc_heap.c mediatek: https://android.googlesource.com/kernel/mediatek/+/android-mtk-3.18/drivers/staging/android/ion/mtk/ion_mm_heap.c But Andrew's example is probably a better example against the dmabuf heaps frameworks > > That's why > > dmabuf heaps is trying to destage ION in a way that allows heaps to > > implement their exporter logic themselves, so we can start pulling > > those more complicated heaps out of their vendor hidey-holes and get > > some proper upstream review. > > > > But I suspect I just am confused as to what your suggesting. Maybe > > could you expand a bit? Apologies for being a bit dense. > > My suggestion is to merge the system and CMA heaps. CMA (at least > the system-wide CMA area) is really just an optimization to get > large contigous regions more easily. We should make use of it as > transparent as possible, just like we do in the DMA code. I'm still not understanding how this would work. Benjamin and Laura already commented on this point, but for a simple example, with the HiKey boards, the DRM driver requires contiguous memory for the framebuffer, but the GPU can handle non-contiguous. Thus the target framebuffers that we pass to the display has to be CMA allocated, but all the other graphics buffers that the GPU will render to and composite can be system. Having the separate heaps allows the gralloc code to allocate the proper buffer depending on the planned usage (GRALLOC_USAGE_HW_FB or not), and that way we don't waste CMA on buffers that don't have to be contiguous. Laura already touched on this, but similar logic can be used for camera buffers, which can make sure we allocate from a specifically reserved CMA region that is only used for the camera so we can always be sure to have N free buffers immediately to capture with, etc. But let me know if I'm still misunderstanding your suggestion. thanks -john
WARNING: multiple messages have this Message-ID (diff)
From: John Stultz <john.stultz@linaro.org> To: Christoph Hellwig <hch@infradead.org> Cc: Yudongbin <yudongbin@hisilicon.com>, Sudipto Paul <Sudipto.Paul@arm.com>, Xu YiPing <xuyiping@hisilicon.com>, Vincent Donnefort <Vincent.Donnefort@arm.com>, "Chenfeng (puck)" <puck.chen@hisilicon.com>, dri-devel <dri-devel@lists.freedesktop.org>, Chenbo Feng <fengc@google.com>, lkml <linux-kernel@vger.kernel.org>, Liam Mark <lmark@codeaurora.org>, Alistair Strachan <astrachan@google.com>, "Xiaqing (A)" <saberlily.xia@hisilicon.com>, "Andrew F . Davis" <afd@ti.com>, Pratik Patel <pratikp@codeaurora.org>, butao <butao@hisilicon.com> Subject: Re: [PATCH v6 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps Date: Wed, 24 Jul 2019 11:46:24 -0700 [thread overview] Message-ID: <CALAqxLUbsz+paJ=P2hwKecuN8DQjJt9Vj4MENCnFuEh6waxsXg@mail.gmail.com> (raw) In-Reply-To: <20190724065958.GC16225@infradead.org> On Wed, Jul 24, 2019 at 12:00 AM Christoph Hellwig <hch@infradead.org> wrote: > On Mon, Jul 22, 2019 at 10:04:06PM -0700, John Stultz wrote: > > Apologies, I'm not sure I'm understanding your suggestion here. > > dma_alloc_contiguous() does have some interesting optimizations > > (avoiding allocating single page from cma), though its focus on > > default area vs specific device area doesn't quite match up the usage > > model for dma heaps. Instead of allocating memory for a single > > device, we want to be able to allow userland, for a given usage mode, > > to be able to allocate a dmabuf from a specific heap of memory which > > will satisfy the usage mode for that buffer pipeline (across multiple > > devices). > > > > Now, indeed, the system and cma heaps in this patchset are a bit > > simple/trivial (though useful with my devices that require contiguous > > buffers for the display driver), but more complex ION heaps have > > traditionally stayed out of tree in vendor code, in many cases making > > incompatible tweaks to the ION core dmabuf exporter logic. > > So what would the more complicated heaps be? Mostly secure heaps, but there have been work in the past with specially aligned chunk heaps in the past. Unfortunately since every vendor tree also include many of their own hacks to the core ION code (usually without changelogs or comments) its hard to decipher much of it. Some examples: msm: https://github.com/Panchajanya1999/msm-4.14/blob/Pie/drivers/staging/android/ion/ion_cma_secure_heap.c exynos: https://github.com/exynos-linux-stable/starlte/tree/tw90-android-p/drivers/staging/android/ion/exynos hisi: https://github.com/hexdebug/android_kernel_huawei_hi3660/blob/master/drivers/staging/android/ion/ion_seccm_heap.c https://github.com/hexdebug/android_kernel_huawei_hi3660/blob/master/drivers/staging/android/ion/ion_secsg_heap.c https://github.com/hexdebug/android_kernel_huawei_hi3660/blob/master/drivers/staging/android/ion/ion_fama_misc_heap.c mediatek: https://android.googlesource.com/kernel/mediatek/+/android-mtk-3.18/drivers/staging/android/ion/mtk/ion_mm_heap.c But Andrew's example is probably a better example against the dmabuf heaps frameworks > > That's why > > dmabuf heaps is trying to destage ION in a way that allows heaps to > > implement their exporter logic themselves, so we can start pulling > > those more complicated heaps out of their vendor hidey-holes and get > > some proper upstream review. > > > > But I suspect I just am confused as to what your suggesting. Maybe > > could you expand a bit? Apologies for being a bit dense. > > My suggestion is to merge the system and CMA heaps. CMA (at least > the system-wide CMA area) is really just an optimization to get > large contigous regions more easily. We should make use of it as > transparent as possible, just like we do in the DMA code. I'm still not understanding how this would work. Benjamin and Laura already commented on this point, but for a simple example, with the HiKey boards, the DRM driver requires contiguous memory for the framebuffer, but the GPU can handle non-contiguous. Thus the target framebuffers that we pass to the display has to be CMA allocated, but all the other graphics buffers that the GPU will render to and composite can be system. Having the separate heaps allows the gralloc code to allocate the proper buffer depending on the planned usage (GRALLOC_USAGE_HW_FB or not), and that way we don't waste CMA on buffers that don't have to be contiguous. Laura already touched on this, but similar logic can be used for camera buffers, which can make sure we allocate from a specifically reserved CMA region that is only used for the camera so we can always be sure to have N free buffers immediately to capture with, etc. But let me know if I'm still misunderstanding your suggestion. thanks -john _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-07-24 18:46 UTC|newest] Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-24 19:49 [PATCH v6 0/5] DMA-BUF Heaps (destaging ION) John Stultz 2019-06-24 19:49 ` [PATCH v6 1/5] dma-buf: Add dma-buf heaps framework John Stultz 2019-06-24 19:49 ` [PATCH v6 2/5] dma-buf: heaps: Add heap helpers John Stultz 2019-06-24 19:49 ` John Stultz 2019-07-18 10:06 ` Christoph Hellwig 2019-07-23 4:09 ` John Stultz 2019-07-23 4:09 ` John Stultz 2019-07-23 20:09 ` Rob Clark 2019-07-23 20:09 ` Rob Clark 2019-07-24 6:55 ` Christoph Hellwig 2019-07-24 6:55 ` Christoph Hellwig 2019-07-24 15:20 ` Andrew F. Davis 2019-07-24 15:20 ` Andrew F. Davis 2019-07-25 12:41 ` Christoph Hellwig 2019-07-25 12:41 ` Christoph Hellwig 2019-07-25 15:23 ` Rob Clark 2019-07-25 15:23 ` Rob Clark 2019-07-24 6:58 ` Christoph Hellwig 2019-07-24 6:58 ` Christoph Hellwig 2019-06-24 19:49 ` [PATCH v6 3/5] dma-buf: heaps: Add system heap to dmabuf heaps John Stultz 2019-06-24 19:49 ` [PATCH v6 4/5] dma-buf: heaps: Add CMA " John Stultz 2019-07-18 10:08 ` Christoph Hellwig 2019-07-23 5:04 ` John Stultz 2019-07-23 5:04 ` John Stultz 2019-07-24 6:59 ` Christoph Hellwig 2019-07-24 8:08 ` Benjamin Gaignard 2019-07-25 12:45 ` Christoph Hellwig 2019-07-24 11:38 ` Laura Abbott 2019-07-25 12:48 ` Christoph Hellwig 2019-07-25 13:47 ` Andrew F. Davis 2019-07-25 13:47 ` Andrew F. Davis 2019-07-25 14:05 ` Christoph Hellwig 2019-07-24 15:46 ` Andrew F. Davis 2019-07-25 12:50 ` Christoph Hellwig 2019-07-25 13:31 ` Andrew F. Davis 2019-07-25 13:31 ` Andrew F. Davis 2019-07-25 14:04 ` Christoph Hellwig 2019-07-25 14:10 ` Andrew F. Davis 2019-07-25 14:11 ` Christoph Hellwig 2019-07-25 14:25 ` Andrew F. Davis 2019-07-25 14:30 ` Christoph Hellwig 2019-07-25 14:51 ` Andrew F. Davis 2019-07-25 14:51 ` Andrew F. Davis 2019-07-24 18:46 ` John Stultz [this message] 2019-07-24 18:46 ` John Stultz 2019-07-25 12:52 ` Christoph Hellwig 2019-07-25 13:20 ` Benjamin Gaignard 2019-07-25 14:33 ` Christoph Hellwig 2019-07-25 14:46 ` Benjamin Gaignard 2019-06-24 19:49 ` [PATCH v6 5/5] kselftests: Add dma-heap test John Stultz 2019-06-24 19:49 ` John Stultz 2019-07-01 21:45 ` [PATCH v6 0/5] DMA-BUF Heaps (destaging ION) Laura Abbott 2019-07-01 21:55 ` John Stultz
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='CALAqxLUbsz+paJ=P2hwKecuN8DQjJt9Vj4MENCnFuEh6waxsXg@mail.gmail.com' \ --to=john.stultz@linaro.org \ --cc=Brian.Starkey@arm.com \ --cc=Sudipto.Paul@arm.com \ --cc=Vincent.Donnefort@arm.com \ --cc=afd@ti.com \ --cc=astrachan@google.com \ --cc=benjamin.gaignard@linaro.org \ --cc=butao@hisilicon.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=fengc@google.com \ --cc=hch@infradead.org \ --cc=labbott@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=lmark@codeaurora.org \ --cc=pratikp@codeaurora.org \ --cc=puck.chen@hisilicon.com \ --cc=saberlily.xia@hisilicon.com \ --cc=sumit.semwal@linaro.org \ --cc=xuyiping@hisilicon.com \ --cc=yudongbin@hisilicon.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.