From: Stephen Boyd <sboyd@codeaurora.org>
To: Rob Clark <robdclark@gmail.com>
Cc: Stanimir Varbanov <stanimir.varbanov@linaro.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Bjorn Andersson <bjorn.andersson@sonymobile.com>
Subject: Re: [PATCH 6/6] drm/msm: add OCMEM driver
Date: Thu, 1 Oct 2015 17:59:44 -0700 [thread overview]
Message-ID: <20151002005944.GI12338@codeaurora.org> (raw)
In-Reply-To: <CAF6AEGvdyG+=c3jvDP2CFN3xUpxuVPsoUG+X8GHah+nKyefJyA@mail.gmail.com>
On 10/01, Rob Clark wrote:
> On Thu, Oct 1, 2015 at 3:25 PM, Rob Clark <robdclark@gmail.com> wrote:
> > On Thu, Oct 1, 2015 at 2:00 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> >>
> >> The simplest thing to do is to split the memory between GPU and
> >> vidc statically. The other use cases with preemption and eviction
> >> and DMA add a lot of complexity that we can explore at a later
> >> time if need be.
> >
> > true, as long as one of the clients is the static gpu client, I guess
> > we could reasonably easily support up to two clients reasonably
> > easily...
>
> btw, random thought.. drm_mm is a utility in drm that serves a
> similar function to genalloc for graphics drivers to manage their
> address space(s) (used for everything from mmap virtual address space
> of buffers allocated against device to managing vram and gart
> allocations, etc... when vram carveout is used w/ drm/msm (due to no
> iommu) I use it to manage allocations from the carveout). It has some
> potentially convenient twists, like supporting allocation from top of
> the "address space" instead of bottom. I'm thinking in particular of
> allocating "narrow mode" allocations from top and "wide mode" from
> bottom since wide vs narrow can only be set per region and not per
> macro within the region. (It can also search by first-fit or
> best-fit.. although not sure if that is useful to us, since OCMEM size
> is relatively constrained.)
>
> Not that I really want to keep ocmem allocator in drm.. I'd really
> rather it be someone else's headache once it gets to implementing the
> crazy stuff for all the random use-cases of other OCMEM users, since
> gpu's use of OCMEM is rather simple/static..
>
> The way downstream driver does this is with a bunch of extra
> bookkeeping on top of genalloc so it can do a dummy allocation to
> force "from the top" allocation (and then immediately freeing the
> dummy allocation).. Maybe it just makes sense to teach genalloc how
> to do from-top vs from-bottom allocations? Not really sure..
>
It looks like video and GPU both use wide mode, if I'm reading
the code correctly. So it seems that we don't need to do anything
special for allocations, just hand the GPU and vidc a chunk of
the memory in wide mode and then let the GPU and vidc drivers
manage buffers within their chunk however they see fit.
One pitfall is going to be power management. ocmem is closely
tied to the GPU power domains, so when video is using its chunk
of memory we're going to need to keep ocmem powered up even if
the GPU is off. I suppose for now we can just leave it always
powered on once the driver probes, but if we ever want to turn it
off we're going to need some tracking mechanism to make sure we
don't turn it off when buffers are in use.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2015-10-02 0:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-29 19:48 [PATCH 0/6] Add OCMEM support (v2) Rob Clark
2015-09-29 19:48 ` [PATCH 1/6] qcom-scm: fix endianess issue in __qcom_scm_is_call_available Rob Clark
2015-09-29 21:00 ` Stephen Boyd
2015-09-29 19:48 ` [PATCH 2/6] qcom-scm: fix header compile errors Rob Clark
2015-09-29 21:02 ` Stephen Boyd
2015-09-29 19:48 ` [PATCH 3/6] qcom-scm: add missing prototype for qcom_scm_is_available() Rob Clark
2015-09-29 19:48 ` [PATCH 4/6] qcom-scm: add ocmem support Rob Clark
2015-09-29 21:38 ` Stephen Boyd
2015-09-29 21:53 ` Rob Clark
2015-09-29 22:33 ` Stephen Boyd
2015-10-01 20:13 ` Rob Clark
2015-10-01 21:52 ` Stephen Boyd
2015-09-29 19:48 ` [PATCH 5/6] drm/msm: update generated headers Rob Clark
2015-09-29 19:48 ` [PATCH 6/6] drm/msm: add OCMEM driver Rob Clark
2015-09-30 7:51 ` Stanimir Varbanov
2015-09-30 11:31 ` Rob Clark
2015-09-30 11:45 ` Rob Clark
2015-10-01 8:23 ` Stanimir Varbanov
2015-10-01 18:00 ` Stephen Boyd
2015-10-01 19:25 ` Rob Clark
2015-10-02 0:26 ` Rob Clark
2015-10-02 0:59 ` Stephen Boyd [this message]
2015-10-02 1:37 ` Rob Clark
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=20151002005944.GI12338@codeaurora.org \
--to=sboyd@codeaurora.org \
--cc=bjorn.andersson@sonymobile.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=robdclark@gmail.com \
--cc=stanimir.varbanov@linaro.org \
/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).