This reverts commit c3dfefa0.

gmbus in 3.4 has simply too many known issues:
- gmbus is too noisy, we need to rework the logging:
  https://bugs.freedesktop.org/show_bug.cgi?id=48248
- zero-length writes cause an OOPS, and they are
  userspace-triggerable:
  https://lkml.org/lkml/2012/3/30/176
- same for zero-length reads:
  https://bugs.freedesktop.org/show_bug.cgi?id=48269

We can try again for 3.5.
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the rework to merge the bit-banging fallback into the gmbus
i2c adapter we've gotten rid of the deadlock possibility that
originally lead to the disabling of this code.

This reverts the revert

commit 826c7e41
Author: Jean Delvare <khali@linux-fr.org>
Date:   Sat Jun 4 19:34:56 2011 +0000

    Revert "drm/i915: Enable GMBUS for post-gen2 chipsets"

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=35572Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This way we can simplify the setup and teardown a bit.

Because we don't actually allocate anything anymore for the force_bit
case, we can now convert that into a boolean.

Also and the functionality supported by the bit-banging together with
what gmbus can do, so that this doesn't randomly change any more.

v2: Chris Wilson noticed that I've mixed up && and & ...

v3: Clarify an if block as suggested by Eugeni Dodonov.
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

... and directly call the newly exported i2c bit-banging functions.

The code is still pretty convoluted because we only set up the gpio
i2c stuff when actually falling back, resulting in more complexity
than necessary. This will be fixed up in the next patch.

v2: Use exported i2c_bit_algo vtable instead of exported functions.
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When we set up the gpio fallback, we always have a 1:1 relationship
with an intel_gmbus. Exploit that to store all gpio related data in
there, too. This is a preparation step to merge the tw i2c adapters
controlling the same bus into one.

Just mundane code-munging in this patch.
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This way we can free up the bus->adaptor.algo_data pointer and make it
available for use with the bitbanging fallback algo.
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

gmbus_xfer with a single message (particularly a single message write) would
set Bus Cycle Select to 100b, the Gen Stop cycle, instead of 101b,
No Index, Stop cycle. This would not start single message i2c transactions.

Also, gmbus_xfer done: will disable the interface without checking if
it is idle. In the case of writes, there will be no wait on status or delay
to ensure the write starts and completes before the interface is turned off.

Fixed the former issue by using the same cycle selection as used in the
I2C_M_RD for the write case.
GMBUS_CYCLE_WAIT | (i + 1 == num ? GMBUS_CYCLE_STOP : 0)
Fixed the latter by waiting on GMBUS_ACTIVE to deassert before disable.

Note from the grumpy d-i-n maintainer: The first hunk that changes the
gmbus read path is just cosmetics to align the code with the write
path.  I.e. the commit message above is slightly lying because the
first issue is _only_ with writes (and not simply "particularly").
Signed-off-by: NBenson Leung <bleung@chromium.org>
Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

GMBUS has several ports and each has it's own corresponding
I2C adpater. When multiple I2C adapters call gmbus_xfer() at
the same time there is a race condition in using the underlying
GMBUS controller. Fixing this by adding a mutex lock when calling
gmbus_xfer().

v2: Moved gmbus_mutex below intel_gmbus and added comments.
Rebased to drm-intel-next-queued.
Signed-off-by: NYufeng Shen <miletus@chromium.org>
[danvet: Shortened the gmbus_mutex comment a bit and add the patch
revision comment to the commit message.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The first parameter should be "number of elements" and the second parameter
should be "element size".
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
devices can typically operate faster than this, 50 kbps should be fine
for all devices (and compliant devices can always stretch the clock if
needed.)

FWIW, the vast majority of framebuffer drivers set udelay to 10
already. So set it to 10 in DRM drivers too, this will make EDID block
reads faster. We might even lower the udelay value later if no problem
is reported.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Acked-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Cc: Keith Packard <keithp@keithp.com>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

They need this to get all the EXPORT_SYMBOL variants and THIS_MODULE
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Revert commit 8f9a3f9b. This fixes a
hang when loading the eeprom driver (see bug #35572.) GMBUS will be
re-enabled later, differently.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Reported-by: NMarek Otahal <markotahal@gmail.com>
Tested-by: NYermandu Patapitafious <yermandu.dev@gmail.com>
Tested-by: NAndrew Lutomirski <luto@mit.edu>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Once a NAK has been asserted by the slave, we need to reset the GMBUS
controller in order to continue. This is done by asserting the Software
Clear Interrupt bit and then clearing it again to restore operations.

If we don't clear the NAK, then all future GMBUS xfers will fail,
including DDC probes and EDID retrieval.

v2: Add some comments as suggested by Keith Packard.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35781Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Tested-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: N"Mengmeng Meng" <mengmeng.meng@intel.com>

With the recent SDVO fix, this is working on all the machines I have to
hand - except for an 845G.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Fix many small bugs in I2C adapter registration:
* Properly reject unsupported GPIO pin.
* Fix improper use of I2C_NAME_SIZE (which is the size of
  i2c_client.name, not i2c_adapter.name.)
* Prefix adapter names with "i915" so that the user knows what the
  I2C channel is connected to.
* Fix swapped characters in the string used to name the GPIO-based
  adapter.
* Add missing comma in gmbus name table.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

As we use POSTING_READ to flush the write to the register before
proceeding, we do not care what the return value is and similar we do
not care for the read to be recorded whilst tracing register
read/writes.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

These registers are written very frequently, are timing sensitive, and
not particularly relevant to any debugging, so remove the tracepoints
from these.
Signed-off-by: NYuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

In i2c GPIO fallback, index 6 is reserved for nothing.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

There are several reported instances of GMBUS failing to successfully
read the EDID, so revert back to bit banging until the issue is
resolved.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30371Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Besides a couple of bugs when writing more than a single byte along the
GMBUS, SDVO was completely failing whilst trying to use GMBUS, so use
bit banging instead.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Use the GMBUS interface rather than direct bit banging to grab the EDID
over DDC (and for other forms of auxiliary communication with external
display controllers). The hope is that this method will be much faster
and more reliable than bit banging for fetching EDIDs from buggy monitors
or through switches, though we still preserve the bit banging as a
fallback in case GMBUS fails.

Based on an original patch by Jesse Barnes.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The SDVO proxy i2c adapter wants to be able to use information stored in
the encoder, so pass that through intel_i2c rather than iterate over all
known encoders every time.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Remove our redundant udelay() as the timings are already handled by the
i2c-algo-bit controller.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

I think this is pretty much correct.  Not really tested.
Signed-off-by: NEric Anholt <eric@anholt.net>

IGD* isn't a useful name.  Replace with the codenames, as sourced from
pci.ids.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
[anholt: Fixed up for merge with pineview/ironlake changes]
Signed-off-by: NEric Anholt <eric@anholt.net>

This is a sync of a fix I made in the old UMS code.  If the BIOS uses
the GMBUS and doesn't clear that setup, then our bit-banging I2C can
fail, leading to monitors not being detected.
Signed-off-by: NEric Anholt <eric@anholt.net>

There are several sources of unnecessary power consumption on Intel
graphics systems. The first is the LVDS clock. TFTs don't suffer from
persistence issues like CRTs, and so we can reduce the LVDS refresh rate
when the screen is idle. It will be automatically upclocked when
userspace triggers graphical activity. Beyond that, we can enable memory
self refresh. This allows the memory to go into a lower power state when
the graphics are idle. Finally, we can drop some clocks on the gpu
itself. All of these things can be reenabled between frames when GPU
activity is triggered, and so there should be no user visible graphical
changes.
Signed-off-by: NJesse Barnes <jesse.barnes@intel.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

The existing API passed around intel_i2c_chan pointers, which are dependent
on the i2c bit-banging algo. This precluded the driver from using outputs
which use a different algo. Switching to the more general i2c_adpater allows
the driver to support non bit-banging DDC.

This also required moving the slave address into the output private
structures.
Signed-off-by: NKeith Packard <keithp@keithp.com>

In IGD, DPCUNIT_CLOCK_GATE_DISABLE bit should be set, otherwise i2c
access will be wrong.

v2: Disable CLOCK_GATE_DISABLE bit after bit bashing as suggested by Eric.
Signed-off-by: NShaohua Li <shaohua.li@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NJean Delvare <khali@linux-fr.org>

This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported.  HDMI, DisplayPort and additional SDVO output support will
follow.

Support for the mode setting code is controlled by the new 'modeset'
module option.  A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.

Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing.  So use caution when
enabling this code; be sure your user level code supports the new
interfaces.

A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.

Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>