From: Daniel Walker <dwalker@codeaurora.org>
To: "Michał Nazarewicz" <m.nazarewicz@samsung.com>
Cc: linux-mm@kvack.org, Marek Szyprowski <m.szyprowski@samsung.com>,
Pawel Osciak <p.osciak@samsung.com>,
Xiaolin Zhang <xiaolin.zhang@intel.com>,
Hiremath Vaibhav <hvaibhav@ti.com>,
Robert Fekete <robert.fekete@stericsson.com>,
Marcus Lorentzon <marcus.xm.lorentzon@stericsson.com>,
linux-kernel@vger.kernel.org,
Kyungmin Park <kyungmin.park@samsung.com>,
linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH 2/4] mm: cma: Contiguous Memory Allocator added
Date: Tue, 20 Jul 2010 12:38:18 -0700 [thread overview]
Message-ID: <1279654698.26765.31.camel@c-dwalke-linux.qualcomm.com> (raw)
In-Reply-To: <op.vf5o28st7p4s8u@pikus>
On Tue, 2010-07-20 at 21:14 +0200, Michał Nazarewicz wrote:
> On Tue, 20 Jul 2010 20:15:24 +0200, Daniel Walker <dwalker@codeaurora.org> wrote:
>
> > On Tue, 2010-07-20 at 17:51 +0200, Michal Nazarewicz wrote:
> >> +** Use cases
> >> +
> >> + Lets analyse some imaginary system that uses the CMA to see how
> >> + the framework can be used and configured.
> >> +
> >> +
> >> + We have a platform with a hardware video decoder and a camera
> >> each
> >> + needing 20 MiB of memory in worst case. Our system is written in
> >> + such a way though that the two devices are never used at the same
> >> + time and memory for them may be shared. In such a system the
> >> + following two command line arguments would be used:
> >> +
> >> + cma=r=20M cma_map=video,camera=r
> >
> > This seems inelegant to me.. It seems like these should be connected
> > with the drivers themselves vs. doing it on the command like for
> > everything. You could have the video driver declare it needs 20megs, and
> > the the camera does the same but both indicate it's shared ..
> >
> > If you have this disconnected from the drivers it will just cause
> > confusion, since few will know what these parameters should be for a
> > given driver set. It needs to be embedded in the kernel.
>
> I see your point but the problem is that devices drivers don't know the
> rest of the system neither they know what kind of use cases the system
> should support.
>
>
> Lets say, we have a camera, a JPEG encoder, a video decoder and
> scaler (ie. devices that scales raw image). We want to support the
> following 3 use cases:
>
> 1. Camera's output is scaled and displayed in real-time.
> 2. Single frame is taken from camera and saved as JPEG image.
> 3. A video file is decoded, scaled and displayed.
>
> What is apparent is that camera and video decoder are never running
> at the same time. The same situation is with JPEG encoder and scaler.
> From this knowledge we can construct the following:
>
> cma=a=10M;b=10M cma_map=camera,video=a;jpeg,scaler=b
It should be implicit tho. If the video driver isn't using the memory
then it should tell your framework that the memory is not used. That way
something else can use it.
(btw, these strings your creating yikes, talk about confusing ..)
> One of the purposes of the CMA framework is to make it let device
> drivers completely forget about the memory management and enjoy
> a simple API.
The driver, and it's maintainer, are really the best people to know how
much memory they need and when it's used/unused. You don't really want
to architect them out.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2010-07-20 19:38 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1279639238.git.m.nazarewicz@samsung.com>
[not found] ` <d6d104950c1391eaf3614d56615617cee5722fb4.1279639238.git.m.nazarewicz@samsung.com>
[not found] ` <adceebd371e8a66a2c153f429b38068eca99e99f.1279639238.git.m.nazarewicz@samsung.com>
2010-07-20 18:15 ` [PATCH 2/4] mm: cma: Contiguous Memory Allocator added Daniel Walker
2010-07-20 19:14 ` Michał Nazarewicz
2010-07-20 19:38 ` Daniel Walker [this message]
2010-07-21 12:01 ` Michał Nazarewicz
2010-07-21 17:35 ` Daniel Walker
2010-07-21 18:11 ` Michał Nazarewicz
2010-07-21 18:19 ` Daniel Walker
2010-07-21 18:38 ` Michał Nazarewicz
2010-07-21 18:58 ` Daniel Walker
2010-07-21 19:21 ` Michał Nazarewicz
2010-07-21 19:37 ` Daniel Walker
2010-07-21 19:53 ` Michał Nazarewicz
2010-07-21 20:03 ` Daniel Walker
2010-07-21 20:22 ` Michał Nazarewicz
2010-07-21 20:34 ` Daniel Walker
2010-07-21 20:43 ` Michał Nazarewicz
2010-07-21 20:45 ` Daniel Walker
2010-07-21 20:56 ` Michał Nazarewicz
2010-07-21 21:01 ` Daniel Walker
2010-07-22 9:34 ` Michał Nazarewicz
2010-07-21 13:52 ` Mark Brown
2010-07-21 14:31 ` Michał Nazarewicz
2010-07-21 18:24 ` Mark Brown
2010-07-21 18:41 ` Michał Nazarewicz
2010-07-22 9:06 ` Mark Brown
2010-07-22 9:25 ` Marek Szyprowski
2010-07-22 10:52 ` Mark Brown
2010-07-22 11:30 ` Michał Nazarewicz
2010-07-22 12:46 ` Mark Brown
2010-07-22 13:24 ` Michał Nazarewicz
2010-07-22 13:40 ` Mark Brown
2010-07-22 14:58 ` Michał Nazarewicz
2010-07-22 15:05 ` Mark Brown
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=1279654698.26765.31.camel@c-dwalke-linux.qualcomm.com \
--to=dwalker@codeaurora.org \
--cc=hvaibhav@ti.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=m.nazarewicz@samsung.com \
--cc=m.szyprowski@samsung.com \
--cc=marcus.xm.lorentzon@stericsson.com \
--cc=p.osciak@samsung.com \
--cc=robert.fekete@stericsson.com \
--cc=xiaolin.zhang@intel.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).