New-ish devices have 3 pipes, so let's not just hardcode 2 but use the
for_each_pipe() macro and make struct intel_display_error_state is big
enough.

V2: Also add the number of pipes emitted (Chris Wilson)
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Yet again the too close relationship between the fb helper and the
crtc helper code strikes. This time around the fb helper resets all
encoder->crtc pointers to NULL before starting to set up it's own
mode. Which is total bullocks, because this will clobber the existing
output routing, which the new drm/i915 code depends upon to be
absolutely correct.

The crtc helper itself doesn't really care about that, since it
disables unused encoders in a rather roundabout way anyway.

Two places call drm_setup_crts:

- For the initial fb config. I've auditted all current drivers, and
  they all allocate their encoders with kzalloc. So there's no need to
  clear encoder->crtc once more.

- When processing hotplug events while showing the fb console. This
  one is a bit more tricky, but both the crtc helper code and the new
  drm/i915 modeset code disable encoders if their crtc is changed and
  that encoder isn't part of the new config. Also, both disable any
  disconnected outputs, too.

  Which only leaves encoders that are on, connected, but for some odd
  reason the fb helper code doesn't want to use. That would be a bug
  in the fb configuration selector, since it tries to light up as many
  outputs as possible.

v2: Kill the now unused encoders variable.
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use _PIPE macro to get correct register definition for IBX/CPT, discard
old variable "i" way.
Signed-off-by: NWang Xingchao <xingchao.wang@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
[danvet: Added the DIP_PORT_SEL #define from a preceeding patch in the
series that needs more work.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

HDMI audio related registers will be configured in write_eld callback.
Signed-off-by: NWang Xingchao <xingchao.wang@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add hsw audio registers definition
Signed-off-by: NWang Xingchao <xingchao.wang@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Simply to make the ilk+ crtc disable path clearer and more symmetric
with the enable function.

Also switch to intel_crtc for the enable function.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

... and move a few others only used by i915_dma.c into the dri1
dungeon.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

All dvo drivers only support 2 dpms states, and our dvo driver
even switches of the dvo port for anything else than DPMS_ON. Hence
ditch this complexity and simply use bool enable.

While reading through this code I've noticed that the mode_set
function of ch7017 is a bit peculiar - it disable the lvds again, even
though the crtc helper code should have done that ... This might be to
work around an issue at driver load, we pretty much ignore the hw
state when taking over.

v2: Also do the conversion for the new ns2501 driver.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since it's redundant - we can get the attached encoder in the
functions themselves.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A few things need adjustement:
- Change the dpms state by calling the dpms connector function and
  not some crtc helper internal callbacks. Otherwise this will break
  once we switch to our own dpms handling.
- Instead of tracking and restoring intel_crtc->dpms_mode use the
  connector's dpms variable - the former relies on the dpms compuation
  rules used by the crtc helper. And it would break when the encoder
  is cloned and the other output has a different dpms state. But luckily
  no one is crazy enough for that.
- Properly clear the connector -> encoder -> crtc linking, even when
  failing (note that the crtc helper removes the encoder -> crtc link
  in disabled_unused_functions for us).
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that all affected i830M systems have the pipe A quirk set,
we don't need to do any special dances in the overlay code any
longer. And reading through the code I'm rather dubios that it
actually does what it claims to do ...

As a nice benefit this rips out a users of the crtc helper dpms
callback.

v2: As suggested by Chris Wilson, replace the code by an appropriate
WARN to ensure that the pipe A is indeed running.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the pipe A quirk properly fixed up for i830M, this shouldn't be
required any longer.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For some odd reason we've missed i830 and a i855 variant. Also
kill the two now redundant i830 entries.

v2: Don't add the missing 855 id to the pipe A quirk list, we seem to
lack justification for it.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Wrong order of parameters passed-in when calling hdmi/adpa
/lvds_pipe_enabled(), 2nd and 3rd parameters are reversed.

This bug was indroduced by

commit 1519b995
Author: Keith Packard <keithp@keithp.com>
Date:   Sat Aug 6 10:35:34 2011 -0700

    drm/i915: Fix PCH port pipe select in CPT disable paths

The reachable tag for this commit is v3.1-rc1-3-g1519b995Signed-off-by: NAnhua Xu <anhua.xu@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When invalidating the TLBs it is documentated as requiring a post-sync
write. Failure to do so seems to result in a GPU hang.

Exposure to this hang on IVB seems to be a result of removing the extra
stalls required for SNB pipecontrol workarounds:

commit 6c6cf5aa
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jul 20 18:02:28 2012 +0100

    drm/i915: Only apply the SNB pipe control w/a to gen6

Note: Manually switch the pipe_control cmd to 4 dwords to avoid a
(silent) functional conflict with -next. This way will get a loud (but
conflict with next (since the scratch_addr has been deleted there).

Reported-and-tested-by: yex.tian@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53322Acked-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: added note about merge conflict with -next.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

eDP is tons of fun. It turns out that at least the new MacBook Air 5,1
model absolutely doesn't like the new force vdd dance we've introduced
in

commit 6cb49835
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun May 20 17:14:50 2012 +0200

    drm/i915: enable vdd when switching off the eDP panel

But that patch also tried to fix some neat edp sequence issue with the
force_vdd timings. Closer inspection reveals that we've raised
force_vdd only to do the aux channel communication dp_sink_dpms. If we
move the edp_panel_off below that, we don't need any force_vdd for the
disable sequence, which makes the Air happy.

Unfortunately the reporter of the original bug that the above commit
fixed is travelling, so we can't test whether this regresses things.
But my theory is that since we don't check for any power-off ->
force_vdd-on delays in edp_panel_vdd_on, this was the actual
root-cause of this failure. With that force_vdd dance completely
eliminated, I'm hopeful the original bug stays fixed, too.

For reference the old bug, which hopefully doesn't get broken by this:

https://bugzilla.kernel.org/show_bug.cgi?id=43163

In any case, regression fixers win over plain bugfixes, so this needs
to go in asap.

v2: The crucial pieces seems to be to clear the force_vdd flag
uncoditionally, too, in edp_panel_off. Looks like this is left behind
by the firmware somehow.

v3: The Apple firmware seems to switch off the panel on it's own, hence
we still need to keep force_vdd on, but properly clear it when switching
the panel off.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45671Tested-by: NRoberto Romer <sildurin@gmail.com>
Tested-by: NDaniel Wagner <wagi@monom.org>
Tested-by: NKeith Packard <keithp@keithp.com>
Cc: stable@vger.kernel.org
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This fix is a backport from the reworked nouveau driver.  It masks off the
engines we're not expecting to use before attempting a channel kickoff.
Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The copy engine exhibits random memory corruption in at least one case, the
GeForce 320M (nv50, 0xaf) in the MacBookAir3,1.

This patch omits creating the engine for the specific chipset, falling back
to M2MF, which kills the symptoms.
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Fixes screen being black after changing performance level.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: stable@vger.kernel.org [3.5+]
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

At least partially fixes DP output detection on W530.  Not sure if more
issues remain, or if my adaptor is just behaving weirdly (it does that
sometimes).

In any case, this patch is necessary.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NChristoph Bumiller <e0425955@student.tuwien.ac.at>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

i2c_add_adapter() may do i2c transfers on the bus to detect supported
devices. Therefore the adapter needs to be all set before adding it. This
was not the case for the bit-banging fallback, resulting in an oops if the
device detection GMBUS transfers timed out. Fix the issue by calling
i2c_add_adapter() only after intel_gpio_setup().

LKML-Reference: <5021F00B.7000503@ionic.de>
Tested-by: NMihai Moldovan <ionic@ionic.de>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NDmitrii Cherkasov <DCherkasov@luxsoft.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Returns a snapshot of the GPU clock counter.  Needed
for certain OpenGL extensions.

v2: agd5f
- address Jerome's comments
- add function documentation
Signed-off-by: NMarek Olšák <maraeo@gmail.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Most of the checking seems to be in place already. As you can see,
log2(number of samples) resides in LAST_LEVEL.

This is required for MSAA support (namely for depth-stencil resolve and
blitting between MSAA resources).
Signed-off-by: NMarek Olšák <maraeo@gmail.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NMarek Olšák <maraeo@gmail.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Virtual address need to be fenced to know when we can safely remove it.
This patch also properly clear the pagetable. Previously it was
serouisly broken.

Kernel 3.5/3.4 need a similar patch but adapted for difference in mutex locking.

v2: For to update pagetable when unbinding bo (don't bailout if
    bo_va->valid is true).
v3: Add kernel 3.5/3.4 comment.
v4: Fix compilation warnings.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>

Better safe than sorry.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>

No functional change, but re-order the cases so they
evaluate properly due to the way the DCE macros work.

Noticed by kallisti5 on IRC.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It seems we can not update the crtc scanout address. After disabling
crtc, update to base address do not take effect after crtc being
reenable leading to at least frame being scanout from the old crtc
base address. Disabling crtc display request lead to same behavior.

So after changing the vram address if we don't keep crtc disabled
we will have the GPU trying to read some random system memory address
with some iommu this will broke the crtc engine and will lead to
broken display and iommu error message.

So to avoid this, disable crtc. For flicker less boot we will need
to avoid moving the vram start address.

This patch should also fix :

https://bugs.freedesktop.org/show_bug.cgi?id=42373

Cc: <stable@vger.kernel.org>
Signed-off-by: NJerome Glisse <jglisse@redhat.com>

Handle the 16 bank case.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Handle the 16 bank case.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The sixteen bank case wasn't handled here, leading to GPU
crashes because of userspace miscalculation.
Signed-off-by: NChristian König <deathsimple@vodafone.de>
Cc: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Need to make sure the crtc is gated on before modesetting.
Explicitly gate the crtc on in prepare() and set a flag
so that the dpms functions don't gate it off during
mode set.

Noticed by sylware on IRC.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The IntegratedSystemInfo table changed versions
on TN.  Update the SS override lookup to handle it.

v2: fix copy-paste typo.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Set a more reasonable default cursor watermark. The
recommended default value is 4.  This should reduce
urgency requests to the MC form the display hw.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

When ddc type is 5, need to look up the i2c channel
in the i2c table.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Since forcewake is now protected by a spinlock, we don't need to grab
dev->struct_mutex any more. This way we can also get rid of a stale
comment, noticed by Ben Widawsky while reviewing some locking changes.

v2: Kill the unused variable ret, noticed by Fengguang Wu.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This has originally been introduced to not oversubscribe the dp links
in

commit 885a5fb5
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date:   Tue Jan 12 05:38:31 2010 +0800

    drm/i915: fix pixel color depth setting on eDP

Since then we've fixed up the dp link bandwidth calculation code and
should now automatically fall back to 6bpc dithering. So this is
unnecessary.

Furthermore it seems to break the new MacbookPro with retina display,
hence let's just rip this out.
Reported-by: NBenoit Gschwind <gschwind@gnu-log.net>
Cc: Benoit Gschwind <gschwind@gnu-log.net>
Cc: Francois Rigaut <frigaut@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
Tested-by: NBenoit Gschwind <gschwind@gnu-log.net>
Tested-by: Bernhard Froemel <froemel at vmars tuwien.ac.at>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

--

Testing feedback highgly welcome, and thanks for Benoit for finding
out that the bpc computations are busted.
-Daniel

When you reopen the lid on a laptop with PCH, the panel suddenly goes
blank sometimes.  It seems because BLC_PWM_CPU_CTL register is cleared
to zero when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 registers are
enabled.

This patch fixes the problem by moving the call of the function setting
BLC_PWM_CPU_CTL after enabling other two registers.
Reported-and-tested-by: NHugh Dickins <hughd@google.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>