pm: add suspend_mem and suspend_standby support

[plagnioj@jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)]

On 07:58 Tue 09 Oct     , Greg Kroah-Hartman wrote:
> On Tue, Oct 09, 2012 at 01:46:33PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 22:02 Sun 07 Oct     , Rafael J. Wysocki wrote:
> > > On Sunday 07 of October 2012 15:12:01 Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > On 00:18 Sun 07 Oct     , Rafael J. Wysocki wrote:
> > > > > On Saturday 06 of October 2012 18:14:29 Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > The following changes since commit 5f3d2f2e1a63679cf1c4a4210f2f1cc2f335bef6:
> > > > > > 
> > > > > >   Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2012-10-06 03:16:12 +0900)
> > > > > > 
> > > > > > are available in the git repository at:
> > > > > > 
> > > > > > 
> > > > > >   git://git.jcrosoft.org/linux-2.6.git tags/pm_suspend_standby_mem
> > > > > > 
> > > > > > for you to fetch changes up to b73c8f97aa8e720bd3b921159687d00626c99d63:
> > > > > > 
> > > > > >   arm: at91: drop at91_suspend_entering_slow_clock (2012-10-06 18:06:25 +0800)
> > > > > > 
> > > > > > ----------------------------------------------------------------
> > > > > > pm: add suspend_mem and suspend_standby support
> > > > > > 
> > > > > > Today when we go to suspend we can not knwon at drivers level if we go in
> > > > > > STANDBY or MEM. Fix this by introducing two new callback suspend_mem and
> > > > > > suspend_standby.
> > > > > 
> > > > > No way. Device drivers shouldn't be concerned about that.
> > > > I do need it on at91 as we swith to slow_clock in MEM suspend and some ip
> > > > need special handling when switching to slow_clock
> > > 
> > > Well, my answer to that is: please fix your platform code instead of
> > > hacking the PM core to work around its problems.
> > how can I fix drivers pm issue when I no way to known at driver level the
> > real suspend, the PM core is supposed to proivde the right information to the
> > drivers so the driver can put it's in the right pm mode. If the pm core can not
> > provide such inforation the PM core is broken as we will have to do dirty
> > hack.
> 
> Why do you need to know the difference in your driver?  We used to
> provide this information a long time ago, but it turned out to not be
> needed at all and just caused problems.
because on at91 I need to handle the mem standby at drviers level.

We do it today already by a hack in different drivers at91_udc (usb device),
atmel_serail and at91_ohci. Those 3 IP have specifci handling when switching
to mem pm. On at91 when switch to mem we shutdown everything and run form a slow
clock - this is done at soc level - but those IP have issue and need specific
care before doing so. Ohterwise when the SoC will wakeup but those IP will not

in this patch series I send the update of those 3 drivers too
and kill the hack
> 
> > Any generic framework is supposed to evolve for real user need here I've one
> > so I udpate the core to mach a need
> 
> I'll push back and ask again why your driver cares about this?  It
> shouldn't.

I'm doing it right now in the kernel but in a dirty way and want to fix it.
And honestly If I could not do it I will

Best Regards,
J.