[PATCH v3 1/1] misc: sram: add dev_pm_ops to support module power gate

[Sudeep Holla]

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