Santosh Shilimkar <[email protected]> writes: >> -----Original Message----- >> From: Kevin Hilman [mailto:[email protected]] >> Sent: Thursday, March 03, 2011 4:00 AM >> To: Santosh Shilimkar >> Cc: [email protected]; [email protected] >> Subject: Re: [PATCH 08/17] omap4: pm: Add GIC save/restore support > [...] > >> > @@ -67,6 +82,17 @@ struct omap4_cpu_pm_info { >> > >> > static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info); >> > >> > +/* Helper functions */ >> > +static inline void sar_writel(u32 val, u32 offset, u8 idx) >> > +{ >> > + __raw_writel(val, sar_ram_base + offset + 4 * idx); >> > +} >> >> aha, this is what I was thinking of in the earlier SAR patch. >> >> Something like this should be part of the SAR code, not here. >> > If you remember during the internal review, this helpers > are added to improve the readability and they are inline > functions. Same is the case with wakeupgen save code. > > If you move this code to SAR file and GIC helper > to gic file, the save routine will become highly > un-optimal. > > In General Save is like below. > Read_Harfware_register() > Write_it_sar_location() > > This happens for every GIC and wakeupgen > registers and hence moving this across files > and calling them from there is going add un-necessary > stack overhead. > > I already got rid-off the global address pointers. I will > get those now using omap4_get_*_base() and store it for > local use in the file.
OK, that should be fine. Thanks, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
