linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Fri, 16 Nov 2012 07:15:13 +0000	[thread overview]
Message-ID: <50A5E801.3000100@ti.com> (raw)
In-Reply-To: <20121112225037.GU6801@atomide.com>

[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]

On 2012-11-13 00:50, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [121112 02:27]:
>> Hi,
>>
>> This series changes omapfb to use standard dma_alloc funcs instead of omap
>> specific vram allocator. This let's us remove the omap vram allocator, making
>> omapfb platform independent.
>>
>> However, note that using standard dma funcs causes the following downsides:
>>
>> 1) dma_alloc_attrs doesn't let us allocate at certain physical address.
>> However, this should not be a problem as this feature of vram allocator
>> is only used when reserving the framebuffer that was initialized by the
>> bootloader, and we don't currently support "passing" a framebuffer from
>> the bootloader to the kernel anyway.
>>
>> 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and
>> we don't need the ioremap when using VRFB. This patch uses
>> DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently
>> not operational.
>>
>> 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
>> changed the ioctl to return 64M for all the values, which, I hope, the
>> applications will interpret as "there's enough vram".
>>
>> 4) "vram" kernel parameter to define how much ram to reserve for video use no
>> longer works. The user needs to enable CMA and use "cma" parameter.
> 
> Great, thanks for fixing these. Could you please queue these into
> a separate branch against v3.7-rc5 that I can also merge into
> omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3?
> 
> Feel free to add my Acked-by: Tony Lindgren <tony@atomide.com> to the
> arch/arm/*omap*/* parts.

I added your acks, and pushed:

git://gitorious.org/linux-omap-dss2/linux.git 3.8/vram-conversion

It's based on -rc4 as my other branches are based on that.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]

  reply	other threads:[~2012-11-16  7:15 UTC|newest]

Thread overview: 17+ 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 ` [PATCH 1/5] OMAP: FB: use DMA_BIT_MASK() for fb's coherent_dma_mask 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 ` [PATCH 3/5] OMAP: RX51: remove use of vram 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 ` [PATCH 5/5] OMAP: remove vram allocator 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:50   ` Tomi Valkeinen
2012-11-12 13:57   ` Tomi Valkeinen
2012-11-12 22:50 ` Tony Lindgren
2012-11-16  7:15   ` Tomi Valkeinen [this message]
2012-11-20 22:14     ` Tony Lindgren
2012-11-21 14:22       ` Jello huang
2012-11-22 13:52         ` Tomi Valkeinen
2012-11-16  9:06   ` Tomi Valkeinen
2012-11-19 22:04     ` Tony Lindgren
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=50A5E801.3000100@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 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).