linux-toradex.git/drivers/platform/x86/intel_ips.c, branch v3.4.27

intel_ips: blacklist HP ProBook laptops

2012-07-19T15:58:56+00:00

commit 88ca518b0bb4161e5f20f8a1d9cc477cae294e54 upstream.

intel_ips driver spews the warning message
  "ME failed to update for more than 1s, likely hung"
at each second endlessly on HP ProBook laptops with IronLake.

As this has never worked, better to blacklist the driver for now.

Signed-off-by: Takashi Iwai 
Signed-off-by: Matthew Garrett 
Signed-off-by: Greg Kroah-Hartman

intel_ips: Hush the i915 symbols message

2012-04-17T13:31:33+00:00

We can't control order here, and getting it inverted is harmless.  So
turn this down to dev_info() and leave a note about how to fix it in
case userspace is insufficiently automagic.

Bugzilla: https://bugzilla.redhat.com/794953
Signed-off-by: Adam Jackson 
Signed-off-by: Matthew Garrett

Disable MCP limit exceeded messages from Intel IPS driver

2012-03-30T20:06:12+00:00

On a system on the thermal limit these are quite noisy and flood the logs.
Better would be a counter anyways. But given that we don't even have
anything for normal throttling this doesn't seem to be urgent either.

Reviewed-by: Jesse Barnes 
Signed-off-by: Andi Kleen 
Signed-off-by: Len Brown

asm-generic: architecture independent readq/writeq for 32bit environment

2012-02-22T00:47:28+00:00

This provides unified readq()/writeq() helper functions for 32-bit
drivers.

For some cases, readq/writeq without atomicity is harmful, and order of
io access has to be specified explicitly.  So in this patch, new two
header files which contain non-atomic readq/writeq are added.

 -  provides non-atomic readq/
   writeq with the order of lower address -> higher address

 -  provides non-atomic readq/
   writeq with reversed order

This allows us to remove some readq()s that were added drivers when the
default non-atomic ones were removed in commit dbee8a0affd5 ("x86:
remove 32-bit versions of readq()/writeq()")

The drivers which need readq/writeq but can do with the non-atomic ones
must add the line:

  #include  /* or hi-lo.h */

But this will be nop in 64-bit environments, and no other #ifdefs are
required.  So I believe that this patch can solve the problem of
 1. driver-specific readq/writeq
 2. atomicity and order of io access

This patch is tested with building allyesconfig and allmodconfig as
ARCH=x86 and ARCH=i386 on top of tip/master.

Cc: Kashyap Desai 
Cc: Len Brown 
Cc: Ravi Anand 
Cc: Vikas Chaudhary 
Cc: Matthew Garrett 
Cc: Jason Uhlenkott 
Cc: James Bottomley 
Cc: Thomas Gleixner 
Cc: "H. Peter Anvin" 
Cc: Roland Dreier 
Cc: James Bottomley 
Cc: Alan Cox 
Cc: Matthew Wilcox 
Cc: Andrew Morton 
Signed-off-by: Hitoshi Mitake 
Signed-off-by: Linus Torvalds

x86 driver: fix typo in TDP override enabling

2011-08-05T19:21:49+00:00

When enabling turbo, we need to set both the TDC and TDP bits.  IIRC
only the TDC one actually matters, but fix it up anyway since the
current code is confusing.

Signed-off-by: Jesse Barnes 
Signed-off-by: Matthew Garrett

x86: remove 32-bit versions of readq()/writeq()

2011-05-25T15:39:44+00:00

The presense of a writeq() implementation on 32-bit x86 that splits the
64-bit write into two 32-bit writes turns out to break the mpt2sas driver
(and in general is risky for drivers as was discussed in
).  To fix this,
revert 2c5643b1c5c7 ("x86: provide readq()/writeq() on 32-bit too") and
follow-on cleanups.

This unfortunately leads to pushing non-atomic definitions of readq() and
write() to various x86-only drivers that in the meantime started using the
definitions in the x86 version of .  However as discussed
exhaustively, this is actually the right thing to do, because the right
way to split a 64-bit transaction is hardware dependent and therefore
belongs in the hardware driver (eg mpt2sas needs a spinlock to make sure
no other accesses occur in between the two halves of the access).

Build tested on 32- and 64-bit x86 allmodconfig.

Link: http://lkml.kernel.org/r/x86-32-writeq-is-broken@mdm.bga.com
Acked-by: Hitoshi Mitake 
Cc: Kashyap Desai 
Cc: Len Brown 
Cc: Ravi Anand 
Cc: Vikas Chaudhary 
Cc: Matthew Garrett 
Cc: Jason Uhlenkott 
Acked-by: James Bottomley 
Acked-by: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: "H. Peter Anvin" 
Signed-off-by: Roland Dreier 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ips: use interruptible waits in ips-monitor

2011-03-28T10:46:15+00:00

This is what I intended to do since:
  1) the driver handles variable waits just fine, and
  2) interruptible waits aren't reported as load in the load avg.

Reported-and-tested-by: Andreas Hartmann 
Signed-off-by: Jesse Barnes 
Signed-off-by: Matthew Garrett

intel_ips: fix sparse non-ANSI function warning

2011-01-10T16:55:25+00:00

Fix sparse warning for non-ANSI function declaration:

drivers/platform/x86/intel_ips.c:1477:25: warning: non-ANSI function declaration of function 'ips_link_to_i915_driver'

Signed-off-by: Randy Dunlap 
Cc:	Matthew Garrett 
Signed-off-by: Matthew Garrett

drm/i915, intel_ips: When i915 loads after IPS, make IPS relink to i915.

2010-12-23T09:51:36+00:00

The IPS driver is designed to be able to run detached from i915 and
just not enable GPU turbo in that case, in order to avoid module
dependencies between the two drivers.  This means that we don't know
what the load order between the two is going to be, and we had
previously only supported IPS after (optionally) i915, but not i915
after IPS.  If the wrong order was chosen, you'd get no GPU turbo, and
something like half the possible graphics performance.

Signed-off-by: Eric Anholt 
Signed-off-by: Chris Wilson 
Cc: stable@kernel.org

IPS driver: Fix limit clamping when reducing CPU power

2010-10-05T18:59:35+00:00

Values here are in internal units rather than Watts, so we shouldn't
perform any conversion.

Signed-off-by: Matthew Garrett