From mboxrd@z Thu Jan 1 00:00:00 1970 From: alexandre.belloni@free-electrons.com (Alexandre Belloni) Date: Thu, 22 Jun 2017 10:51:02 +0200 Subject: Drivers taking different actions depending on sleep state In-Reply-To: References: <9dc7b7f4-e47d-59f3-3b51-52e0aefd2487@free.fr> <7001768d-9134-4975-127e-e8444e00f677@gmail.com> Message-ID: <20170622085102.mpk7vxodpgxtrlfd@piout.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 21/06/2017 at 16:55:04 -0700, Florian Fainelli wrote: > > That is conceivable, but again, the meaning of STANDBY and MEM is > > platform-specific. Actions to be taken for, say, STANDBY, may differ > > from one platform to another. > > True, though I would only expect drivers for that particular platform to > care about that information and these drivers would only make sense on > that particular platform so the meaning of STANDBY and MEM would be > clear for those drivers. The intent is really to keep the "distributed" > model where individual drivers manage their particular piece of HW, > while utilizing a global piece of information that is platform specific. > > If this seems acceptable to you along with proper documentation to > illustrate the platform specific meaning of these states, I will got > ahead and cook a patch. Well, that won't work for us. We need need two kind of information: - whether main clock is switched from the master clock to the slow clock - whether VDDcore will be cut for the first one, we already have an hackish callback: at91_suspend_entering_slow_clock() that will call from the platform specific drivers. The main issue now is for the second one. We also need it for IPs that are shared with other SoCs. For example, the macb ethernet controller that is shared with the zynq and the m_can controller. In those cases, I don't think it is a good idea to add platform specific code in the drivers but at the same time, I don't think it is reasonable to unconditionally reinit the IP on resume as there is a significant latency hit. I don't think that the xilinx guys will like when suddenly their platform takes 500ms to resume. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com