Hi, * Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [160211 02:43]: > On Thu, Feb 11, 2016 at 04:55:37AM +0000, Woodruff, Richard wrote: > > > From: Sasha Levin [mailto:sasha.levin@xxxxxxxxxx] > > > Sent: Wednesday, February 10, 2016 9:11 AM > > > > Did you test these changes? I certainly did with off idle and retention idle for omap3 on 3430 and 36xx. And on n900 that's the HS omap 3430. And we don't have any HS 36xx in the mainline. > > > We don't want to write to .text, so let's move l2_inv_api_params > > > to .data and access it via a pointer. > > > > At one point in time some of these functions were copied from DRAM load > > address into SRAM and executed from there. > > > > Some of these sections had to be executed outside of DDR due to issues. > > The copy assumed contagious section. If you move some of the data into > > a separate section and any copy is still in code the result won't work > > as expected. If the code has changed then maybe its OK. Back when > > this code was entered it was hand stepped to ensure correct behavior. > > Yes, this isn't going to work if it is copied out of the DDR, because > moving the data to the .data section and introducing a PC relative > access to it will make the code expect to access data at a relative > offset from the SRAM. > > Sascha, please drop this for now. Hmm did I miss something? Since commit 46e130d298a3 ("ARM: pm: omap3: run the ASM sleep code from DDR") we only run minimal parts of the code in SRAM. Naturally if any SRAM code uses PC relative access things won't work. Here are the only pieces running in SRAM: - omap3_do_wfi running in SRAM only for retention idle as off idle restores DDR for us - For HS omaps, save_secure_ram_context is already in .data as it's only run in SRAM - For some revisions, we have es3_sdrc_fix dynamically copied to SRAM If there are other places that I've missed, please let me know and I'll take a look ASAP! Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html