On Thursday 28 October 2004 13:58, Pavel Machek wrote:
> Hi!
>
> > > > Yes, that's what everyone wants to do.
> > >
> > > Not all devices need to do that - only the console device and the target
> > > device we're writing to (and all of their ancestors)
> >
> > And USB devices should certainly avoid extra resumes ...
> > and there's no point in restarting the highspeed PLLs
> > unless they're actually going to be needed. There
> > might not even be time or power enough to reactivate
> > everything.
>
> I believe right solution is not to stop highspeed PLLs during freeze
> phase. Just stop DMA and be done with that. That makes unfreeze fast
> and all hardware work is postponed to powerdown phase.
I'm not sure what hardware model you were thinking of,
but that approach doesn't seem like it can be "right"
for all hardware. The very thing that enables you to
enter the deepest sleep state might be that you had
already stopped using the 48MHz clock, PLL shut down.
That's a real world example from OMAP(*).
So that issue is what I said: "don't restart". You
were talking about "don't stop".
> > enough to write the suspend image. (Console special
> > handling would be wanted for STR too, I suspect.)
>
> I do not understand this one. How is console special for
> suspend-to-RAM?
The same way it'd be special for STD: as a way to debug
interesting things during later stages of entering that
system sleep state. It could be using a serial line if
the UART were still clocked. Some developers wouldn't
care at all about that stuff, if a hardware tool like a
JTAG debugger were the right system tool.
- Dave
(*) Which has PM hardware that's interesting enough
to be a very useful counterbalance to x86-pc/acpi.
Linux doesn't use all of it yet, but there's no
reason it shouldn't be able to do so.
