From mboxrd@z Thu Jan 1 00:00:00 1970 From: sudeep.holla@arm.com (Sudeep Holla) Date: Wed, 26 Aug 2015 10:26:54 +0100 Subject: [PATCH v3 1/1] misc: sram: add dev_pm_ops to support module power gate In-Reply-To: References: <1438272681-29338-1-git-send-email-shenwei.wang@freescale.com> <55DC677E.1030004@arm.com> <55DC74CF.7070300@arm.com> <55DC7E5E.5020701@arm.com> <55DC91BE.7090107@arm.com> Message-ID: <55DD865E.4050603@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 25/08/15 20:35, Shenwei Wang wrote: > > >> -----Original Message----- >> From: Sudeep Holla [mailto:sudeep.holla at arm.com] >> Sent: 2015?8?25? 11:03 >> To: Wang Shenwei-B38339 >> Cc: Sudeep Holla; gregkh at linuxfoundation.org; arnd at arndb.de; Huang >> Yongcai-B20788; linux-arm-kernel at lists.infradead.org >> Subject: Re: [PATCH v3 1/1] misc: sram: add dev_pm_ops to support module >> power gate >>>> I don't like that solution as it's not scalable with SRAM size and >>>> saving all the content of SRAM just because of few active regions >>>> makes no sense to me at-least. I prefer leaving it to the users to >>>> handle that rather than SRAM driver. >>> >>> I don't think it is not scalable. The choice should be made by the >>> application. From the driver side, it should be able to provide the >>> way to retain its contents during power gate. >>> >> >> OK that was just my opinion. I just wanted to avoid unnecessary save/restore, e.g. >> if say just few kilobytes are active in say 32MB SRAM, you will save/restore entire >> SRAM ? > > Although in theory a SoC can integrate such a big SRAM like 32MB inside, but I don't > think anyone will practice it because the cost is too high. So far, the most popular size > of a SRAM in a SoC is hundreds of KB. > I have seen 32MB SRAM and people are thinking of doubling it. So I disagree, especially if that's your main argument. On Android targets, I have seen suspend-to-ram used quite aggressively and this save/restore might add significant delay and might be unnecessary most of the time. >> Anyways, the driver is saving/restoring the memory unconditionally whenever DT >> sets that boolean right ? at-least as the patch stands. > > The saving/restoring feature is not enabled by default in this patch. To enable it you > need to add the can-power-gate string in the relating DT node. Yes I understood and that's what I mentioned above, but once it's present in DT, it's unconditional for the entire SRAM which might not be used actively. So I still don't like this approach. Regards, Sudeep