0049fb2603
Use dma_alloc_attrs to allocate memory instead of omap specific vram allocator. After this we can remove the omap vram allocator. There are some downsides to this change: 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. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
28 lines
738 B
Plaintext
28 lines
738 B
Plaintext
menuconfig FB_OMAP2
|
|
tristate "OMAP2+ frame buffer support"
|
|
depends on FB && OMAP2_DSS && !DRM_OMAP
|
|
|
|
select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
|
|
select FB_CFB_FILLRECT
|
|
select FB_CFB_COPYAREA
|
|
select FB_CFB_IMAGEBLIT
|
|
help
|
|
Frame buffer driver for OMAP2+ based boards.
|
|
|
|
config FB_OMAP2_DEBUG_SUPPORT
|
|
bool "Debug support for OMAP2+ FB"
|
|
default y
|
|
depends on FB_OMAP2
|
|
help
|
|
Support for debug output. You have to enable the actual printing
|
|
with 'debug' module parameter.
|
|
|
|
config FB_OMAP2_NUM_FBS
|
|
int "Number of framebuffers"
|
|
range 1 10
|
|
default 3
|
|
depends on FB_OMAP2
|
|
help
|
|
Select the number of framebuffers created. OMAP2/3 has 3 overlays
|
|
so normally this would be 3.
|