| Message ID | 1523505239-16229-2-git-send-email-j-keerthy@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 4/11/18 9:53 PM, Keerthy wrote: > From: Dave Gerlach <d-gerlach@ti.com> > > After an RTC+DDR cycle we lose sram context so emif pm functions present > in sram are lost. We can check if the first byte of the original > code in DDR contains the same first byte as the code in sram, and if > they do not match we know we have lost context and must recopy the > functions to the previous address to maintain PM functionality. > > Signed-off-by: Dave Gerlach <d-gerlach@ti.com> > Signed-off-by: Keerthy <j-keerthy@ti.com> > --- > drivers/memory/ti-emif-pm.c | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) > > diff --git a/drivers/memory/ti-emif-pm.c b/drivers/memory/ti-emif-pm.c > index 632651f..ec4a62c 100644 > --- a/drivers/memory/ti-emif-pm.c > +++ b/drivers/memory/ti-emif-pm.c > @@ -249,6 +249,25 @@ int ti_emif_get_mem_type(void) > }; > MODULE_DEVICE_TABLE(of, ti_emif_of_match); > > +#ifdef CONFIG_PM_SLEEP > +static int ti_emif_resume(struct device *dev) > +{ > + unsigned long tmp = > + __raw_readl((void *)emif_instance->ti_emif_sram_virt); > + > + /* > + * Check to see if what we are copying is already present in the > + * first byte at the destination, only copy if it is not which > + * indicates we have lost context and sram no longer contains > + * the PM code > + */ > + if (tmp != ti_emif_sram) > + ti_emif_push_sram(dev, emif_instance); > + > + return 0; > +} > +#endif /* CONFIG_PM_SLEEP */ Instead of this indirect method , why can't just check the previous deep sleep mode and based on that do copy or not. EMIF power status register should have something like that ? Another minor point is even though there is nothing to do in suspend, might be good to have a callback with comment that nothing to do with some explanation why not. Don't have strong preference but may for better readability. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 12 April 2018 10:14 PM, santosh.shilimkar@oracle.com wrote: > On 4/11/18 9:53 PM, Keerthy wrote: >> From: Dave Gerlach <d-gerlach@ti.com> >> >> After an RTC+DDR cycle we lose sram context so emif pm functions present >> in sram are lost. We can check if the first byte of the original >> code in DDR contains the same first byte as the code in sram, and if >> they do not match we know we have lost context and must recopy the >> functions to the previous address to maintain PM functionality. >> >> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >> Signed-off-by: Keerthy <j-keerthy@ti.com> >> --- >> drivers/memory/ti-emif-pm.c | 24 ++++++++++++++++++++++++ >> 1 file changed, 24 insertions(+) >> >> diff --git a/drivers/memory/ti-emif-pm.c b/drivers/memory/ti-emif-pm.c >> index 632651f..ec4a62c 100644 >> --- a/drivers/memory/ti-emif-pm.c >> +++ b/drivers/memory/ti-emif-pm.c >> @@ -249,6 +249,25 @@ int ti_emif_get_mem_type(void) >> }; >> MODULE_DEVICE_TABLE(of, ti_emif_of_match); >> +#ifdef CONFIG_PM_SLEEP >> +static int ti_emif_resume(struct device *dev) >> +{ >> + unsigned long tmp = >> + __raw_readl((void *)emif_instance->ti_emif_sram_virt); >> + >> + /* >> + * Check to see if what we are copying is already present in the >> + * first byte at the destination, only copy if it is not which >> + * indicates we have lost context and sram no longer contains >> + * the PM code >> + */ > >> + if (tmp != ti_emif_sram) >> + ti_emif_push_sram(dev, emif_instance); >> + >> + return 0; >> +} >> +#endif /* CONFIG_PM_SLEEP */ > Instead of this indirect method , why can't just check the previous > deep sleep mode and based on that do copy or not. EMIF power status > register should have something like that ? I will check if we have a register that tells previous state of sram, not sure of it. > > Another minor point is even though there is nothing to do in suspend, > might be good to have a callback with comment that nothing to do with > some explanation why not. Don't have strong preference but may for > better readability. > > Regards, > Santosh > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 12 April 2018 10:14 PM, santosh.shilimkar@oracle.com wrote: > On 4/11/18 9:53 PM, Keerthy wrote: >> From: Dave Gerlach <d-gerlach@ti.com> >> >> After an RTC+DDR cycle we lose sram context so emif pm functions present >> in sram are lost. We can check if the first byte of the original >> code in DDR contains the same first byte as the code in sram, and if >> they do not match we know we have lost context and must recopy the >> functions to the previous address to maintain PM functionality. >> >> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >> Signed-off-by: Keerthy <j-keerthy@ti.com> >> --- >> drivers/memory/ti-emif-pm.c | 24 ++++++++++++++++++++++++ >> 1 file changed, 24 insertions(+) >> >> diff --git a/drivers/memory/ti-emif-pm.c b/drivers/memory/ti-emif-pm.c >> index 632651f..ec4a62c 100644 >> --- a/drivers/memory/ti-emif-pm.c >> +++ b/drivers/memory/ti-emif-pm.c >> @@ -249,6 +249,25 @@ int ti_emif_get_mem_type(void) >> }; >> MODULE_DEVICE_TABLE(of, ti_emif_of_match); >> +#ifdef CONFIG_PM_SLEEP >> +static int ti_emif_resume(struct device *dev) >> +{ >> + unsigned long tmp = >> + __raw_readl((void *)emif_instance->ti_emif_sram_virt); >> + >> + /* >> + * Check to see if what we are copying is already present in the >> + * first byte at the destination, only copy if it is not which >> + * indicates we have lost context and sram no longer contains >> + * the PM code >> + */ > >> + if (tmp != ti_emif_sram) >> + ti_emif_push_sram(dev, emif_instance); >> + >> + return 0; >> +} >> +#endif /* CONFIG_PM_SLEEP */ > Instead of this indirect method , why can't just check the previous > deep sleep mode and based on that do copy or not. EMIF power status > register should have something like that ? I will check if we have a register that tells the previous state of sram. > > Another minor point is even though there is nothing to do in suspend, > might be good to have a callback with comment that nothing to do with > some explanation why not. Don't have strong preference but may for > better readability. Okay. Thanks a lot for the quick feedback! > > Regards, > Santosh > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday 16 April 2018 03:59 PM, Keerthy wrote: > > > On Thursday 12 April 2018 10:14 PM, santosh.shilimkar@oracle.com wrote: >> On 4/11/18 9:53 PM, Keerthy wrote: >>> From: Dave Gerlach <d-gerlach@ti.com> >>> >>> After an RTC+DDR cycle we lose sram context so emif pm functions present >>> in sram are lost. We can check if the first byte of the original >>> code in DDR contains the same first byte as the code in sram, and if >>> they do not match we know we have lost context and must recopy the >>> functions to the previous address to maintain PM functionality. >>> >>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >>> Signed-off-by: Keerthy <j-keerthy@ti.com> >>> --- >>> drivers/memory/ti-emif-pm.c | 24 ++++++++++++++++++++++++ >>> 1 file changed, 24 insertions(+) >>> >>> diff --git a/drivers/memory/ti-emif-pm.c b/drivers/memory/ti-emif-pm.c >>> index 632651f..ec4a62c 100644 >>> --- a/drivers/memory/ti-emif-pm.c >>> +++ b/drivers/memory/ti-emif-pm.c >>> @@ -249,6 +249,25 @@ int ti_emif_get_mem_type(void) >>> }; >>> MODULE_DEVICE_TABLE(of, ti_emif_of_match); >>> +#ifdef CONFIG_PM_SLEEP >>> +static int ti_emif_resume(struct device *dev) >>> +{ >>> + unsigned long tmp = >>> + __raw_readl((void *)emif_instance->ti_emif_sram_virt); >>> + >>> + /* >>> + * Check to see if what we are copying is already present in the >>> + * first byte at the destination, only copy if it is not which >>> + * indicates we have lost context and sram no longer contains >>> + * the PM code >>> + */ >> >>> + if (tmp != ti_emif_sram) >>> + ti_emif_push_sram(dev, emif_instance); >>> + >>> + return 0; >>> +} >>> +#endif /* CONFIG_PM_SLEEP */ >> Instead of this indirect method , why can't just check the previous >> deep sleep mode and based on that do copy or not. EMIF power status >> register should have something like that ? > > I will check if we have a register that tells the previous state of sram. Unfortunately i do not see any such register for knowing SRAM previous state in am43 TRM and hence this indirect way of knowing. http://www.ti.com/lit/ug/spruhl7h/spruhl7h.pdf > >> >> Another minor point is even though there is nothing to do in suspend, >> might be good to have a callback with comment that nothing to do with >> some explanation why not. Don't have strong preference but may for >> better readability. I can add a blank suspend call with comment "The contents are already present in DDR hence no need to explicitly save" The comment in resume function pretty much explains the above. So let me know if i need to add the suspend callback. Regards, Keerthy > > Okay. Thanks a lot for the quick feedback! > >> >> Regards, >> Santosh >> >> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 5/23/2018 1:47 AM, Keerthy wrote: > > > On Monday 16 April 2018 03:59 PM, Keerthy wrote: >> [..] >>> Instead of this indirect method , why can't just check the previous >>> deep sleep mode and based on that do copy or not. EMIF power status >>> register should have something like that ? >> >> I will check if we have a register that tells the previous state of sram. > > Unfortunately i do not see any such register for knowing SRAM previous > state in am43 TRM and hence this indirect way of knowing. > OK. > >> >>> >>> Another minor point is even though there is nothing to do in suspend, >>> might be good to have a callback with comment that nothing to do with >>> some explanation why not. Don't have strong preference but may for >>> better readability. > > I can add a blank suspend call with comment > > "The contents are already present in DDR hence no need to explicitly save" > > The comment in resume function pretty much explains the above. So let me > know if i need to add the suspend callback. > Please add the empty suspend callback with comment. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/memory/ti-emif-pm.c b/drivers/memory/ti-emif-pm.c index 632651f..ec4a62c 100644 --- a/drivers/memory/ti-emif-pm.c +++ b/drivers/memory/ti-emif-pm.c @@ -249,6 +249,25 @@ int ti_emif_get_mem_type(void) }; MODULE_DEVICE_TABLE(of, ti_emif_of_match); +#ifdef CONFIG_PM_SLEEP +static int ti_emif_resume(struct device *dev) +{ + unsigned long tmp = + __raw_readl((void *)emif_instance->ti_emif_sram_virt); + + /* + * Check to see if what we are copying is already present in the + * first byte at the destination, only copy if it is not which + * indicates we have lost context and sram no longer contains + * the PM code + */ + if (tmp != ti_emif_sram) + ti_emif_push_sram(dev, emif_instance); + + return 0; +} +#endif /* CONFIG_PM_SLEEP */ + static int ti_emif_probe(struct platform_device *pdev) { int ret; @@ -308,12 +327,17 @@ static int ti_emif_remove(struct platform_device *pdev) return 0; } +static const struct dev_pm_ops ti_emif_pm_ops = { + SET_SYSTEM_SLEEP_PM_OPS(NULL, ti_emif_resume) +}; + static struct platform_driver ti_emif_driver = { .probe = ti_emif_probe, .remove = ti_emif_remove, .driver = { .name = KBUILD_MODNAME, .of_match_table = of_match_ptr(ti_emif_of_match), + .pm = &ti_emif_pm_ops, }, }; module_platform_driver(ti_emif_driver);