On Mon, 2010-05-17 at 19:37 +0200, ext Tony Lindgren wrote:
> Sorry if I've been confused about what vram.c is doing.
>
> How about change vram.c to use dma_alloc_coherent for now? That would
> break the non-standard behaviour to preserve the log set by the
> bootloader, but that should be OK until we know how to deal with that
> properly.
>
> After that you could just optionally reserve the bootloader memory
> area using LMB based on some flags in the platform init data.
>From vram.c's commit log about features vram.c supports but dma_alloc_*
doesn't:
- Support for OMAP2's SRAM
- Allocate without ioremapping
- Allocate at defined physical addresses
- Allows larger VRAM area and larger allocations
I haven't heard anybody using OMAP2's SRAM for framebuffer, so that's
probably not an issue.
Reserving the memory at defined physical address is needed for the
bootloader-framebuffer, but I think it's only used on N900's product
kernel with some additional hacks. So that's probably not an issue
either.
Allocating without ioremapping... dma_alloc_* always ioremaps the
allocated area, even though it's never used (in some cases). I think
this is the case when using OMAP's VRFB rotation HW. This may or may not
be an issue, depending on the amount of memory allocated and the
available virtual mem area.
And the last point, I think there was a limit of about 8MB when
allocating with dma_alloc_* (I may remember wrong). This could be a
problem for some use cases.
So, I guess it's possible to use dma_alloc_*, but there may be some
complications.
I still haven't found time to look at the LMB stuff, but I hope I'll
manage to do that this week.
Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
