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

On Wed, May 05, 2004 at 03:05:36PM +0100, Stuart MENEFY wrote:
> 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.
> 
That's interesting, I could've sworn the last time I looked it wrapped into
hlt as well.

> 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.
> 
That's a good point. In that case, I'll back it out for cpu_relax() and add
the hlt_counter back in for the idle loop. This should fix serial on ST40.

> 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.
> 
Something like this is possible with DPM policies, but as it hasn't been
integrated into mainline, it's not anything we'll be worrying about at this
point.

> 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...
>
Well, with hlt_counter back in place, this should at least provide an easy
workaround for HCMOS7 parts. Though it might be worthwhile to have a defconfig
for boards that have this problem so that other people don't run into the same
thing.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAmPez1K+teJFxZ9wRAofJAJ4q69MzKfP4TQlhbsweH4WpXe3j9wCeJgG5
1JPwQ5pJ7+R8RbackF7h04I=
=NOvT
-----END PGP SIGNATURE-----