linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
Date: Mon, 12 Nov 2012 22:50:37 +0000	[thread overview]
Message-ID: <20121112225037.GU6801@atomide.com> (raw)
In-Reply-To: <1352715906-16946-1-git-send-email-tomi.valkeinen@ti.com>

* 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.

Regards,

Tony

  parent reply	other threads:[~2012-11-12 22:50 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 [this message]
2012-11-16  7:15   ` Tomi Valkeinen
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=20121112225037.GU6801@atomide.com \
    --to=tony@atomide.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).