lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 26 Aug 2015 12:25:32 +0100 From: Sudeep Holla <sudeep.holla@....com> To: Shenwei Wang <shenwei.wang@...escale.com> CC: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>, "arnd@...db.de" <arnd@...db.de>, "robh+dt@...nel.org" <robh+dt@...nel.org>, Pawel Moll <Pawel.Moll@....com>, Mark Rutland <Mark.Rutland@....com>, "ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>, "galak@...eaurora.org" <galak@...eaurora.org>, Sudeep Holla <sudeep.holla@....com>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, "b20788@...escale.com" <b20788@...escale.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org> Subject: Re: [PATCH v3 1/1][Resend] misc: sram: add dev_pm_ops to support module power gate On 25/08/15 23:03, Shenwei Wang wrote: > When system goes into low power states like SUSPEND_MEM and > HIBERNATION, the hardware IP block may be powered off to reduce > the power consumption. This power down will lost all the > data inside the ram. This patch added the dev_pm_ops and > implemented two callbacks: suspend_noirq and resume_noirq, which > will save the data in the on-chip-ram right before power down > and restore it after system resumes. > > A new property string named "can-power-gate" is added to > the devicetree bindings too. > > Based-on-a-patch-by: Anson Huang <b20788@...escale.com> > Signed-off-by: Shenwei Wang <shenwei.wang@...escale.com> > > --- > Change log: > > PATCH v3 > Removed the unnecessary clk_enable/clk_disable. > > PATCH v2 > Use vmalloc to allocate the SRAM backup memory. > Code clean up. > > Documentation/devicetree/bindings/misc/sram.txt | 2 ++ > drivers/misc/sram.c | 42 +++++++++++++++++++++++++ > 2 files changed, 44 insertions(+) > > diff --git a/Documentation/devicetree/bindings/misc/sram.txt b/Documentation/devicetree/bindings/misc/sram.txt > index 36cbe5a..1170086 100644 > --- a/Documentation/devicetree/bindings/misc/sram.txt > +++ b/Documentation/devicetree/bindings/misc/sram.txt > @@ -33,6 +33,8 @@ Optional properties in the area nodes: > > - compatible : standard definition, should contain a vendor specific string > in the form <vendor>,[<device>-]<usage> > +- can-power-gate: a property to tell the driver that the sram can support > + power gate > > Example: > > diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c > index 15c33cc..db9f1fa 100644 > --- a/drivers/misc/sram.c > +++ b/drivers/misc/sram.c > @@ -30,7 +30,9 @@ > > struct sram_dev { > struct device *dev; > + void *power_off_save; > void __iomem *virt_base; > + u32 size; > > struct gen_pool *pool; > struct clk *clk; > @@ -156,6 +158,33 @@ static int sram_reserve_regions(struct sram_dev *sram, struct resource *res) > return ret; > } > > +static int sram_suspend_noirq(struct device *dev) > +{ > + struct platform_device *pdev = to_platform_device(dev); > + struct sram_dev *sram = platform_get_drvdata(pdev); > + > + if (!sram->power_off_save) > + return 0; > + > + /* Save necessary regs */ > + memcpy(sram->power_off_save, sram->virt_base, sram->size); > + > + return 0; > +} > + > +static int sram_resume_noirq(struct device *dev) > +{ > + struct platform_device *pdev = to_platform_device(dev); > + struct sram_dev *sram = platform_get_drvdata(pdev); > + > + if (!sram->power_off_save) > + return 0; > + > + memcpy(sram->virt_base, sram->power_off_save, sram->size); As I objected in the original thread[1], I am just iterating myself here again. IMO this is unnecessary and can be avoided. It's also not scalable for large SRAM. I *still can't understand* what's the use-case where you need to save/restore the entire SRAM content. I see it's mostly used for audio/video and some crypto use-case(in the mainline). In most of those cases, when you enter S2R, all the devices *needs to be in quiescent state* which implies they no longer use SRAM. So can you please care to provide your reasons for this save/restore ? On some platforms, it's used for PM in which case it needs to be always on. Regards, Sudeep [1] http://www.spinics.net/lists/arm-kernel/msg441449.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists