Especially vesafb likes to map everything as uc- (yikes), and if that
mapping hangs around still while we try to map the gtt as wc the
kernel will downgrade our request to uc-, resulting in abyssal
performance.

Unfortunately we can't do this as early as readon does (i.e. as the
first thing we do when initializing the hw) because our fb/mmio space
region moves around on a per-gen basis. So I've had to move it below
the gtt initialization, but that seems to work, too. The important
thing is that we do this before we set up the gtt wc mapping.

Now an altogether different question is why people compile their
kernels with vesafb enabled, but I guess making things just work isn't
bad per se ...

v2:
- s/radeondrmfb/inteldrmfb/
- fix up error handling

v3: Kill #ifdef X86, this is Intel after all. Noticed by Ben Widawsky.

v4: Jani Nikula complained about the pointless bool primary
initialization.

v5: Don't oops if we can't allocate, noticed by Chris Wilson.

v6: Resolve conflicts with agp rework and fixup whitespace.

This is commit e188719a2891f01b3100d in drm-next.

Backport to 3.5 -fixes queue requested by Dave Airlie - due to grub
using vesa on fedora their initrd seems to load vesafb before loading
the real kms driver. So tons more people actually experience a
dead-slow gpu. Hence also the Cc: stable.

Cc: stable@vger.kernel.org
Reported-and-tested-by: "Kilarski, Bernard R" <bernard.r.kilarski@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

This reverts commit f82cfb6bcda164ef3a66b8c3fc549b1f9bdd09ad.

This breaks the backlight controls on my IVB asus zenbook with an eDP
panel.

I guess the right fix would be to read this bit and use either the pch
or the cpu register to frob the backlight values. But that is stuff
for -next.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This patch fixes the problem on some HP desktop machines with eDP
which give blank screens after S3 resume.

It turned out that BLC_PWM_CPU_CTL must be written after
BLC_PWM_CPU_CTL2.  Otherwise it doesn't take effect on these
SNB machines.

Tested with 3.5-rc3 kernel.

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

Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

After banging my head against this for the past few months, I still
don't see how this could possible race under the premise that once an
irq bit is masked in PM_IMR and reset in PM_IIR it won't show up again
until we unmask it in PM_IMR.

Still, we have reports of this being seen in the wild. Now Bspec has
this little bit of lovely language in the PMIIR register:

Public SNB Docs, Vol3Part2, 2.5.14 "PMIIR":

"For each bit, the IIR can store a second pending interrupt if two or
more of the same interrupt conditions occur before the first condition
is cleared. Upon clearing the interrupt, the IIR bit will momentarily
go low, then return high to indicate there is another interrupt
pending."

Now if we presume that PMIMR only prevent new interrupts from being
queued, we could easily end up masking an interrupt and clearing it,
but the 2nd pending interrupt setting the bit in PMIIR right away
again. Which leads, the next time the irq handler runs, to hitting the
WARN.

Also, no bad side effects of this have ever been reported. And we've
tracked down our issues with the gpu turbo getting stuck to bogus
interrupt generation limits in th RPLIMIT register.

So let's just rip out this WARN as bogus and call it a day. The only
shallow thing here is that this 2-deep irq queue in the hw makes you
wonder how racy the windows irq handler is ...

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42907
Cc: stable@vger.kernel.org
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

They aren't going anywhere, and probing on DDC can cause the panel to
blank briefly, so read them up front and cache them for later queries.

v2: fix potential NULL derefs in intel_dp_get_edid_modes and
    intel_dp_get_edid (Jani)
    copy full EDID length, including extension blocks (Takashi)
    free EDID on teardown (Takashi)
v3: malloc a new EDID buffer that's big enough for the memcpy (Chris)
v4: change handling of NULL EDIDs, just preserve the NULL behavior
    across detects and mode list fetches rather than trying to re-fetch
    the EDID (Chris)
v5: be glad that Chris is around to remind me to hit C-x C-s before
    committing.

References: https://bugs.freedesktop.org/show_bug.cgi?id=46856
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit 092945e11c5b84f66dd08f0b87fb729715d377bc.

This commit prevents a DP screen from properly training the link.
Oddly enough it works, once the machine has been warm-booted with an
older kernel.

According to DP docs this _should_ have been the right precharge time.
Also, the commit that originally introduces this was just general snb
DP enabling and didn't mention any specific reason for this special
value. Whatever, trust the reporter that this makes things worse and
let's just revert it.

v2: Less spelling fail.

Cc: Adam Jackson <ajax@redhat.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reported-by: "Wouter M. Koolen" <W.M.Koolen-Wijkstra@cwi.nl>
Buglink: https://lkml.org/lkml/2012/6/14/301
Cc: stable@vger.kernel.org (only for 3.4)
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

The new oui probe has been missing these.

This issue has been introduce in

commit 0d198328538276c4459ef5de081e68ae60e6c4c2
Author: Adam Jackson <ajax@redhat.com>
Date:   Mon May 14 16:05:47 2012 -0400

    drm/i915/dp: Probe branch/sink OUIs

v2: Do the eDP vdd dance of simply not probing the OUI on eDP panels
as suggested by Chris Wilson.

v3: Fix up the error path fail - I suck.

Cc: Adam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50808
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Bugreport: http://permalink.gmane.org/gmane.comp.video.dri.devel/69695
Tested-by: Yang Guang <guang.a.yang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This prevents the HDMI detect functions from poking at an eDP
connected panel, which can lead to trouble.

[danvet: Note that we have some other reports of DP vs. HDMI fighting,
but the general case is a much bigger fish to fry.]

References: https://bugs.freedesktop.org/show_bug.cgi?id=42278
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit 9e612a008fa7fe493a473454def56aa321479495.

It incorrectly finds VGA connectors where none are attached, apparently
not noticing that nothing replied to the EDID queries, and happily using
the default EDID modes that have nothing to do with actual hardware.

That in turn then causes X to fall down to the lowest common
denominator, which is usually the default 1024x768 mode that is in the
default EDID and pretty much anything supports).

I'd suggest that if not relying on the HDP pin, the code should at least
check whether it gets valid EDID data back, rather than just assume
there's something on the VGA connector.

Cc: Dave Airlie <airlied@linux.ie>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: pch_irq_handler -> {ibx, cpt}_irq_handler
  char/agp: add another Ironlake host bridge
  drm/i915: fix up ivb plane 3 pageflips
  drm/i915: hold forcewake around ring hw init
  drm/i915: Mark the ringbuffers as being in the GTT domain
  drm/i915/crt: Do not rely upon the HPD presence pin
  drm/i915: Reset last_retired_head when resetting ring