Re: [PATCH 12/17] ARM: mvebu: Armada XP GP specific suspend/resume code

[Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html