* Dave Gerlach <d-gerlach@xxxxxx> [160509 14:44]: > Hi, > There are several instances when one would want to execute out of on-chip > SRAM, such as PM code on ARM platforms, so once again revisiting this > series to allow that. Seems that having a solution for allowing SRAM to be > mapped as executable will help clean up PM code on several ARM platforms and > also open the door for others like TI AM335x and AM437x. This was first sent > here [1] but this is rebased and updated for v4.6-rc. > > Many platforms have migrated to using the generic SRAM driver at > drivers/misc/sram.c but it doesn't seem like there is a clean solution > for the common problem of needing to map executable pages. > > Currently I see several platforms (at-91, imx6, socfpga) taking the > address allocated by the genpool given by the SRAM driver and then calling > __arm_ioremap_exec on it again to get a new address that can be executed. > This doesn't seem like the cleanest solution, but maybe it works for code > that is under mach-xxx but what about code that migrates outside into the > drivers layer? Do any other architectures have a requirement for this? > > I've converted omap3 PM code to use the generic SRAM driver which I'll send > in a series right after this one, and AM335x and AM437x can both make use of > this series as well and even go as far as to move a chunk of the PM > code into drivers (needs to be updated but sent long ago here [2]), but > that will be blocked if we don't have a generic way to ioremap memory as > exec, or at least a way to do it from drivers/. > > If we don't want to go down this path, is there a better idea for how to > call ioremap_exec from drivers/ that we can all agree on? Looks to me that this should allow moving the current SRAM code into drivers. So feel free to add: Acked-by: Tony Lindgren <tony@xxxxxxxxxxx> -- 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
