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;
MIME-Version: 1.0
References: <20190624194908.121273-1-john.stultz@linaro.org>
 <20190624194908.121273-5-john.stultz@linaro.org> <20190718100840.GB19666@infradead.org>
 <CALAqxLWLx_tHVjZqrSNWfQ_M2RGGqh4qth3hi9GGRdSPov-gcw@mail.gmail.com>
 <20190724065958.GC16225@infradead.org> <CALAqxLUbsz+paJ=P2hwKecuN8DQjJt9Vj4MENCnFuEh6waxsXg@mail.gmail.com>
 <20190725125206.GE20286@infradead.org>
In-Reply-To: <20190725125206.GE20286@infradead.org>
From:   Benjamin Gaignard <benjamin.gaignard@linaro.org>
Date:   Thu, 25 Jul 2019 15:20:11 +0200
Message-ID: <CA+M3ks52ADKVCw_pZP9=LSNt+vhiEFyrtB-Jm2x=p62kSV7qVA@mail.gmail.com>
Subject: Re: [PATCH v6 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
To:     Christoph Hellwig <hch@infradead.org>
Cc:     John Stultz <john.stultz@linaro.org>,
        lkml <linux-kernel@vger.kernel.org>,
        Laura Abbott <labbott@redhat.com>,
        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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Le jeu. 25 juil. 2019 =C3=A0 14:52, Christoph Hellwig <hch@infradead.org> a=
 =C3=A9crit :
>
> On Wed, Jul 24, 2019 at 11:46:24AM -0700, John Stultz wrote:
> > 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.

No we have uses cases where graphic buffers can go directly to display with=
out
using GPU. For example we can grab frames from the camera and send them dir=
ectly
in display (same for video decoder) because we have planes for that.

>
> But that just means we need a flag that memory needs to be contiguous,
> which totally makes sense at the API level.  But CMA is not the only
> source of contigous memory, so we should not conflate the two.

We have one file descriptor per heap to be able to add access control
on each heap.
That wasn't possible with ION because the heap was selected given the
flags in ioctl
structure and we can't do access control based on that. If we put flag
to select the
allocation mechanism (system, CMA, other) in ioctl we come back to ION stat=
us.
For me one allocation mechanism =3D one heap.

>
> > 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.
>
> And for that we already have per-device CMA areas hanging off struct
> device, which this should reuse instead of adding another duplicate
> CMA area lookup scheme.