Re: [linux-sh:03225] Re: SH SCI output weirdness...

On Tue, 4 May 2004 18:25:21 -0400 Paul Mundt <[email protected]> wrote:

> On Tue, May 04, 2004 at 09:48:55PM +0100, Stuart MENEFY wrote:
> > The problem is the idle loop has been modified to call cpu_relax(), and
> > cpu_relax() now includes a "sleep" instruction. The hlt_counter, although
> > still present, is ignored.
> > 
> That's an oversight, the hlt_counter should be added back in to cpu_idle().
> Additionally, it's probably worth having cpu_relax() check hlt_counter
> prior to emitting the sleep instruction.
> 
> Putting this into cpu_relax() was ultimately a power saving hack (in the same
> capacity as x86 hlt). But this does depend on the power-down mode config.

Note that x86 does not use "hlt" in cpu_relax(), it only uses it in the
idle loop. On x86 cpu_relax() uses the bizarre "rep;nop" sequence which as
I understand it is much lighter weight, effectively causes the CPU to wait
until the pipeline empties and then restarts. Its also effectively a yield
on hyperthreaded systems. So people calling cpu_relax() are not going to
expect a fairly major power down.

> I agree that cpu_relax() is a bit of a problematic case, but in the case
> where a module is well aware of when it can sleep, it certainly helps in
> the power consumption case. As such, the power-down mode configuration needs
> to be quite precise.
> 
> In the event that sleep is possible, it's certainly nicer to have in a busy
> loop than a do { } while (0), particularly if you're going to be there for
> awhile.

While I agree it would be nice to have a way of doing this, "sleep" is not
it. The only way to get out of a "sleep" is an interrupt or reset. A busy
loop is explicitly polling for something to happen, not waiting for an
interrupt. So putting a "sleep" in a busy loop is going to play havoc
with latency.

To do this properly we need a way of saying "the CPU isn't doing much, so
maybe reduce its clock frequency, reduce its bus priority, but keep it
going". I don't see any light weight way of doing this on an SH.

> > On the ST40, with the default power management configuration, this appears
> > to try and power down or reduce the clock speed of the serial port. So any
> > data still in the FIFO gets corrupted.
> > 
> In that case, ST40 needs to setup the power management configuration in a way
> that won't power down serial, or hlt_counter needs to be wrapped in and then
> disabled for ST40.

Agreed. I've never tried running without the sleep being disabled since it was
known to be broken on early HCMOS7 parts. Given correct configuration, I think
it should work on all HCMOS8 parts. Something else to add to the TODO list...

Stuart

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (SunOS)

iD8DBQFAmPSx61BlSKQGbXkRAlhNAJ4/o9TGFHiCRvoG0C8KKUfg3MkQyACfX//K
+ssEtgWkXpQsz+TIWqp0+3I=
=tad/
-----END PGP SIGNATURE-----