kernel.git/drivers/platform/x86/intel_ips.c, branch linux-3.3.y

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

2012-02-22T00:47:28Z

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:49Z

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:44Z

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:15Z

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:25Z

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:36Z

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:35Z

Values here are in internal units rather than Watts, so we shouldn't perform any conversion. Signed-off-by: Matthew Garrett

[PATCH 2/2] IPS driver: disable CPU turbo

2010-10-05T18:59:28Z

The undocumented interface we're using for reading CPU power seems to be overreporting power. Until we figure out how to correct it, disable CPU turbo and power reporting to be safe. This will keep the CPU within default limits and still allow us to increase GPU frequency as needed. Signed-off-by: Jesse Barnes Signed-off-by: Matthew Garrett

IPS driver: apply BIOS provided CPU limit if different from default

2010-10-05T18:59:25Z

The BIOS may hand us a lower CPU power limit than the default for a given SKU. We should use it in case the platform isn't designed to dissapate the full TDP of a given part. Signed-off-by: Jesse Barnes Signed-off-by: Matthew Garrett

intel_ips -- ensure we do not enable gpu turbo mode without driver linkage

2010-10-05T18:59:21Z

Both when polling the current turbo status (in poll_turbo_status mode) and when handling thermal events (in ips_irq_handler) the current status of GPU turbo is updated to match the hardware status. However if during driver initialisation we were unable aquire linkage to the i915 driver enabling GPU turbo will lead to an oops on the first attempt to determine GPU busy status. Ensure that we do not enable GPU turbo unless we have driver linkage. BugLink: http://bugs.launchpad.net/bugs/632430 Cc: stable@kernel.org Signed-off-by: Andy Whitcroft Signed-off-by: Matthew Garrett