[RFC PATCH] Consolidate SRAM support

[Tomi Valkeinen]

On Mon, 2011-04-18 at 09:48 +0300, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux at arm.linux.org.uk> [110416 16:06]:
> > On Sat, Apr 16, 2011 at 09:01:26PM +0800, Haojian Zhuang wrote:
> > > On Fri, Apr 15, 2011 at 9:06 PM, Russell King - ARM Linux
> > > >
> > > > This uses the physical address, and unlike Davinci's dma address usage,
> > > > it always wants to have the physical address, and will always return
> > > > the corresponding physical address when passed that pointer.
> > > >
> > > > OMAP could probably do with some more work to make the omapfb and other
> > > > allocations use the sram allocator, rather than hooking in before the
> > > > sram allocator is initialized - and then further cleanups so that we
> > > > have an initialization function which just does
> 
> I think we can just remove the omapfb SRAM support for now as it should
> be optional. That will then leave out that dependency and can be added
> back once we have a common framework in place.
> 
> Tomi do you see any problems with that?

I agree. Only OMAP2 has enough SRAM to possibly have a framebuffer
there, and even on OMAP2 the SRAM size is so small that it works only
for rather small displays. I'm not aware of anyone using omapfb's SRAM
support.

The SRAM support also makes our video ram allocator and omapfb more
complex, without much benefit, so I'm more than happy to remove it
totally. Additionally, I believe there is work going on with memory
allocators that omapfb could also use, and migrating to any new mem
allocator will no doubt be much easier if we just handle normal RAM.

So, I can make a patch that removes the SRAM support from omapfb, and
queue it up for the next merge window.

 Tomi