From: John Einar Reitan <john.reitan@foss.arm.com>
To: Rob Clark <robdclark@gmail.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>, Cc Ma <cc.ma@mediatek.com>,
Joakim Bech <joakim.bech@linaro.org>,
Burt Lien <burt.lien@linaro.org>,
Linus Walleij <linus.walleij@linaro.org>,
Linaro MM SIG Mailman List <linaro-mm-sig@lists.linaro.org>,
Linaro Kernel Mailman List <linaro-kernel@lists.linaro.org>
Subject: Re: [PATCH v10 0/3] Secure Memory Allocation Framework
Date: Mon, 10 Oct 2016 14:51:37 +0200 [thread overview]
Message-ID: <20161010125136.GA2844@e106921-lin.trondheim.arm.com> (raw)
In-Reply-To: <CAF6AEGtH+sgSHgmjK2-jCrsuV-Uz0bOz32s1w2Wy41RnTS0t1g@mail.gmail.com>
On Fri, Oct 07, 2016 at 10:42:17AM -0400, Rob Clark wrote:
> probably should keep the discussion on github (USAGE.md was updated a
> bit more and merged into https://github.com/cubanismo/allocator so
> look there for the latest)..
>
> but briefly:
>
> 1) my expectation is if the user is implementing some use-case, it
> knows what devices and APIs are involved, otherwise it wouldn't be
> able to pass a buffer to that device/API..
As I described at Linaro Connect late-connected devices could cause new
constrains to appear. I.e. some (additonal) HDMI connection or WiFi Display etc.
Including all the might-happen devices might lead to unoptimal buffers
just to be able to handle some rarely-happen events.
I guess the easy resolve here is for the user to do a reallocation with
the new constraints added and replace the buffer(s) in question, but
with a slight lag in enabling the new device.
John
prev parent reply other threads:[~2016-10-10 12:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-04 11:47 [PATCH v10 0/3] Secure Memory Allocation Framework Benjamin Gaignard
2016-10-04 11:47 ` [PATCH v10 1/3] create SMAF module Benjamin Gaignard
2016-10-04 11:47 ` [PATCH v10 2/3] SMAF: add CMA allocator Benjamin Gaignard
2016-10-04 11:47 ` [PATCH v10 3/3] SMAF: add test secure module Benjamin Gaignard
2016-10-05 13:19 ` [PATCH v10 0/3] Secure Memory Allocation Framework Daniel Vetter
2016-10-05 13:40 ` Benjamin Gaignard
2016-10-05 13:43 ` Daniel Vetter
2016-10-06 12:18 ` Benjamin Gaignard
2016-10-06 16:54 ` Rob Clark
2016-10-07 13:54 ` Benjamin Gaignard
2016-10-07 14:42 ` Rob Clark
2016-10-10 12:51 ` John Einar Reitan [this message]
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=20161010125136.GA2844@e106921-lin.trondheim.arm.com \
--to=john.reitan@foss.arm.com \
--cc=benjamin.gaignard@linaro.org \
--cc=burt.lien@linaro.org \
--cc=cc.ma@mediatek.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=joakim.bech@linaro.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=robdclark@gmail.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).