Re: [PATCH 2/2] Fix console handling during suspend/resume

[Adam Belay <ambx1@neo.rr.com>]

On Sat, Jun 24, 2006 at 04:30:43PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2006-06-23 at 22:18 -0700, Linus Torvalds wrote:
> > And the "suspend_late()" thing really is fundamentally different from 
> > "suspend()". As mentioned several times, splitting suspend() up is what 
> > allows us to, very specifically, avoid having to shut down the console 
> > early. I want to be able to do printk() until as late in the game as 
> > possible, and preferably as early in the game as possible. 
> >
> > And splitting suspend was the way to do that. And when I actually started 
> > doing that, splitting resume (which is even _better_) actually fell out of 
> > it automatically - I needed to do that just to handle the nested error 
> > cases correctly (which I had earlier thought I'd just punt entirely, and 
> > require that we do errors in the "prepare/save_state" phase only).
> > 
> > In other words, I think that this patch will allow us to resume, say VGA 
> > early, and reliably, and get a working console by the time we resume USB.
> 
> So your resume_early is equivalent to my pmac specific hack to resume
> the fbdev early (except that my hack is really very very very early :)
> Before I even bring the L2 cache back, but that's almost a detail. After
> all, nothing says the L2 cache couldn't be just another driver with a
> suspend and a resume method :)
> 
> However, I do still think that this late/early business is problematic
> with "runtime/dynamic" suspend of individual devices or sub-trees
> because of the "irq off" requirement of the late round of calls and I'm
> not necessarily fan of having drivers split themselves between the 2
> phases. If there is a case where we would be tempted to do that, then I
> tend to prefer splitting into 2 drivers instead. The PHY example is a
> good one: move the PHY suspend/resume to the new PHY layer and have
> proper PHY drivers with their suspend/resume etc... (reminds me I sitll
> need to port sungem to that new stuff... )
> 
> > Now, it does require that PCI buses (and preferably other devices) go to 
> > D3 only in suspend_late(), and come back in resume_early(), so that VGA is 
> > reachable. So that _will_ require driver modifications.
> 
> Yes, though doing the PCI busses that way is fair enough provided we
> don't get into semaphore/msleep/etc... vs. interrupt off kind of issues.
> I really don't think we need irq off for that late phase :) Let's just
> quickly look at the reason why you want IRQs off. I think that it's a
> way to avoid being hit by requests etc... right ?

Yes, and pci_set_power_state() can require msleep().  A suspend_late()
and resume_early() pass with interrupts off does cleanup the ugly
legacy device problem and gives some new debugging opportunities.  However,
I agree, it may not be very useful for most modern devices, especially when
considering a possible runtime suspend requirement.

Thanks,
Adam