From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
Date: Thu, 22 Nov 2012 13:52:21 +0000 [thread overview]
Message-ID: <50AE2E15.2070501@ti.com> (raw)
In-Reply-To: <CAPFyZi52e+BPLFQoSn_scdru=MP2NeBUNUkHnym8W3t90JW2jA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 625 bytes --]
Hi,
On 2012-11-21 16:22, Jello huang wrote:
> HI Tomi,
> we need one rank of cma to allocate the memory for driver in kernel
> space .And the default CMA is for allocating memory frome usespace.So
> if we allocate the memory from the
> default CMA zone ,there maybe introduce fragmention to the default CMA
> zone.The kernel space memory donot touch the memory from userspace
Can you elaborate a bit? I didn't understand your point. Are you saying
each kernel driver that uses dma_alloc should have their own CMA zone?
That doesn't make sense...
How do you allocate CMA memory from userspace?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Jello huang <ruifeihuang@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>,
linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org,
archit@ti.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
Date: Thu, 22 Nov 2012 15:52:21 +0200 [thread overview]
Message-ID: <50AE2E15.2070501@ti.com> (raw)
In-Reply-To: <CAPFyZi52e+BPLFQoSn_scdru=MP2NeBUNUkHnym8W3t90JW2jA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 625 bytes --]
Hi,
On 2012-11-21 16:22, Jello huang wrote:
> HI Tomi,
> we need one rank of cma to allocate the memory for driver in kernel
> space .And the default CMA is for allocating memory frome usespace.So
> if we allocate the memory from the
> default CMA zone ,there maybe introduce fragmention to the default CMA
> zone.The kernel space memory donot touch the memory from userspace
Can you elaborate a bit? I didn't understand your point. Are you saying
each kernel driver that uses dma_alloc should have their own CMA zone?
That doesn't make sense...
How do you allocate CMA memory from userspace?
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: tomi.valkeinen@ti.com (Tomi Valkeinen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
Date: Thu, 22 Nov 2012 15:52:21 +0200 [thread overview]
Message-ID: <50AE2E15.2070501@ti.com> (raw)
In-Reply-To: <CAPFyZi52e+BPLFQoSn_scdru=MP2NeBUNUkHnym8W3t90JW2jA@mail.gmail.com>
Hi,
On 2012-11-21 16:22, Jello huang wrote:
> HI Tomi,
> we need one rank of cma to allocate the memory for driver in kernel
> space .And the default CMA is for allocating memory frome usespace.So
> if we allocate the memory from the
> default CMA zone ,there maybe introduce fragmention to the default CMA
> zone.The kernel space memory donot touch the memory from userspace
Can you elaborate a bit? I didn't understand your point. Are you saying
each kernel driver that uses dma_alloc should have their own CMA zone?
That doesn't make sense...
How do you allocate CMA memory from userspace?
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121122/69798536/attachment.sig>
next prev parent reply other threads:[~2012-11-22 13:52 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-12 10:25 [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram Tomi Valkeinen
2012-11-12 10:25 ` Tomi Valkeinen
2012-11-12 10:25 ` Tomi Valkeinen
2012-11-12 10:25 ` [PATCH 1/5] OMAP: FB: use DMA_BIT_MASK() for fb's coherent_dma_mask Tomi Valkeinen
2012-11-12 10:25 ` Tomi Valkeinen
2012-11-12 10:25 ` Tomi Valkeinen
2012-11-12 10:25 ` [PATCH 2/5] OMAPFB: use dma_alloc_attrs to allocate memory Tomi Valkeinen
2012-11-12 10:25 ` Tomi Valkeinen
2012-11-12 10:25 ` Tomi Valkeinen
2012-11-12 10:25 ` [PATCH 3/5] OMAP: RX51: remove use of vram Tomi Valkeinen
2012-11-12 10:25 ` Tomi Valkeinen
2012-11-12 10:25 ` Tomi Valkeinen
2012-11-12 10:25 ` [PATCH 4/5] OMAP: common.c: remove init call to vram Tomi Valkeinen
2012-11-12 10:25 ` Tomi Valkeinen
2012-11-12 10:25 ` Tomi Valkeinen
2012-11-12 10:25 ` [PATCH 5/5] OMAP: remove vram allocator Tomi Valkeinen
2012-11-12 10:25 ` Tomi Valkeinen
2012-11-12 10:25 ` Tomi Valkeinen
2012-11-12 13:39 ` [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram Grazvydas Ignotas
2012-11-12 13:39 ` Grazvydas Ignotas
2012-11-12 13:39 ` Grazvydas Ignotas
2012-11-12 13:50 ` Tomi Valkeinen
2012-11-12 13:50 ` Tomi Valkeinen
2012-11-12 13:50 ` Tomi Valkeinen
2012-11-12 13:57 ` Tomi Valkeinen
2012-11-12 13:57 ` Tomi Valkeinen
2012-11-12 13:57 ` Tomi Valkeinen
2012-11-12 22:50 ` Tony Lindgren
2012-11-12 22:50 ` Tony Lindgren
2012-11-12 22:50 ` Tony Lindgren
2012-11-16 7:15 ` Tomi Valkeinen
2012-11-16 7:15 ` Tomi Valkeinen
2012-11-16 7:15 ` Tomi Valkeinen
2012-11-20 22:14 ` Tony Lindgren
2012-11-20 22:14 ` Tony Lindgren
2012-11-20 22:14 ` Tony Lindgren
2012-11-21 14:22 ` Jello huang
2012-11-21 14:22 ` Jello huang
2012-11-21 14:22 ` Jello huang
2012-11-22 13:52 ` Tomi Valkeinen [this message]
2012-11-22 13:52 ` Tomi Valkeinen
2012-11-22 13:52 ` Tomi Valkeinen
2012-11-23 10:07 ` Jello huang
2012-11-23 10:07 ` Jello huang
2012-11-16 9:06 ` Tomi Valkeinen
2012-11-16 9:06 ` Tomi Valkeinen
2012-11-16 9:06 ` Tomi Valkeinen
2012-11-19 22:04 ` Tony Lindgren
2012-11-19 22:04 ` Tony Lindgren
2012-11-19 22:04 ` Tony Lindgren
2012-11-20 15:09 ` Tomi Valkeinen
2012-11-20 15:09 ` Tomi Valkeinen
2012-11-20 15:09 ` Tomi Valkeinen
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=50AE2E15.2070501@ti.com \
--to=tomi.valkeinen@ti.com \
--cc=linux-arm-kernel@lists.infradead.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 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.