* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [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? > > TCM driver can allocate code into SRAM section in link stage. It needs to > > update link file and virtual memory layout. Is it worth to make SRAM driver > > support this behavior? The case of using SRAM as memory for instruction > > is switching frequency or entering/exiting low power mode in PXA silicons. > > This is more or less the same scenario which OMAP is using its SRAM > for, although that's explicitly SRAM and not TCM. > > I don't think we need position dependent code requiring fixup for > these applications as such things tend to be fairly easily coded in a > position independent way. There should not be any need code requiring fixup in most cases using parameters passed to the functions should be enough. Usually it's just register addresses that are different. > Also note that C functions can't be copied because C produces position > dependent code, and we have no way of extracting the relocation > dependencies from such code. C functions should not be needed. The SRAM size is small and typical usage is a loop waiting for some register to lock. For any larger SRAM areas NUMA can be used instead. Regards, Tony -- 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
