Dear Andrew Lunn, On Fri, 24 Oct 2014 16:51:19 +0200, Andrew Lunn wrote: > > > I'm wondering if this code should be a power driver, living in > > > drivers/power/reset/. > > > > I'm fine with that, but have you seen the *very* tight interaction > > between the SoC-specific code and the board-specific code? The problem > > is that the board-specific code needs to put the SDRAM into > > self-refresh *right* before shutting down the SoC, and all that while > > making sure the code doing both of these operations remains in the > > I-Cache, and does not touch any other location in memory (which has > > become inaccessible due to being in self-refresh mode). > > > > Look at the mvebu_armada_xp_gp_pm_enter() function: it takes two > > arguments, received from the SoC-level code. How to handle this thing > > with a driver in drivers/power/reset/ ? > > It looks like reset drivers can register a notifier block, and you can > pass this notifier a void * parameter. So you should be able to pass > parameters. Nobody currently does this, so it might not work.... I had a closer look, but I'm sorry, I don't really see how drivers/power/reset can help here. In drivers/power/reset, there are only drivers that handle powering off a platform, or rebooting a platform. They hook up by setting a value to the pm_power_off and/or arm_pm_restart function pointers. But in my case, what's needed is neither a power off nor a reboot, but an entry to suspend to RAM, which is a different state. I don't see how the drivers/power/reset driver would get "called" by the suspend/resume procedure. I also don't see how notifiers can help here. On which notification would the drivers/power/reset driver register itself? By creating a new notification type, specific to the mvebu platform? I'm fine with reworking the implementation I've proposed, but if you could shed some more light on what your proposal would look like, it would be useful, as I currently don't see how drivers/power/reset fits the need of the Armada XP suspend/resume mechanism. Thanks, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
