drm/i915: Fix port name in vlv_wait_port_ready() timeout warning

We're currently misprinting the port name when vlv_wait_port_ready()
times out. Fix it by using port_name().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Return a drm_mode_status enum in the mode_valid vfuncs

We had some mode_valid() vfuncs returning an int, others the enum. Let's
use the latter everywhere.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add intel_display_power_enabled_sw() for use in atomic ctx

Atm we call intel_display_power_enabled() from
i915_capture_error_state() in IRQ context and then take a mutex. To fix
this add a new intel_display_power_enabled_sw() which returns the domain
state based on software tracking as opposed to reading the actual HW
state.

Since we use domain_use_count for this without locking on the reader
side make sure we increase the counter only after enabling all required
power wells and decrease it before disabling any of these power wells.

Regression introduced in
commit 1b02383464b4a915627ef3b8fd0ad7f07168c54c
Author: Imre Deak <imre.deak@intel.com>
Date:   Tue Sep 24 16:17:09 2013 +0300

    drm/i915: support for multiple power wells

Note that atm we depend on the value returned by
intel_display_power_enabled_sw() in i915_capture_error_state() to avoid
unclaimed register access reports. This was never guaranteed though,
since another thread can disable the power concurrently. If this is a
problem we need another explicit way to disable the reporting during
error captures.

v2:
- remove barriers as the caller can't depend on the value
  returned from i915_capture_error_state_sw() anyway (Ville)
- dump the state of pipe/transcoder power domain state (Daniel)

Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: drop DRM_ERROR in intel_fbdev init

This should just be a debug.  Add another debug msg to the inherit path
while we're at it.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72098
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/vlv: use parallel context restore when coming out of RC6

Setting this bit restores all ring contexts in parallel rather than
serially.  Matches current BWG recommendations.

Tested-by: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Deepak S <deepak.s@inel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/vlv: use a lower RC6 timeout on VLV

We use timeout mode, and we need to lower the timeout to get good RC6
residency when loads are running.  This gets me from 0% residency during
glxgears to 77%, which is a pretty good improvement.  This value also
matches the current BWG recommentations.

Tested-by: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Deepak S <deepak.s@inel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/sdvo: Fix up debug output to not split lines

It leads to a big mess when stuff interleaves. Especially with the new
patch I've submitted for the drm core to no longer artificially split
up debug messages.

v2: The size parameter to snprintf includes the terminating 0, but the
return value does not. Adjust the logic accordingly. Spotted by Mika.

Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: make sparse happy for the new vlv mmio read function

It doesn't like that we assign 0 to a pointer, it wants the real NULL.

On closer look that initialization is actually bogus, and the compiler
can easily see that we never use it unitialized. So let's just drop
this.

Cc: Deepak S <deepak.s@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: drop the right force-wake engine in the vlv mmio funcs

This was fumbled in the conversion to per-engine forcewake.

Cc: Deepak S <deepak.s@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix GT wake FIFO free entries for VLV

On VLV the GTFIFOCTL register has other bits besides the number of free
entries in the GT wake FIFO. Apply a mask when we read th register to
make sure we don't misinterpret the number of free FIFO entries.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: There's some unclarity about hsw, but brushed off as todays'
Bspec just acting up a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Report all GTFIFODBG errors

On VLV GTFIFODBG has more bits. Just report them all.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Enabling DebugFS for valleyview forcewake counts

Forcewake counts for valleyview are not exposed throgh DebugFS.
Exposing with this change.

Signed-off-by: Deepak S <deepak.s@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/vlv: Valleyview support for forcewake Individual power wells.

Split vlv force wake routines to help individually control Media/Render
well based on the register access.

We've seen power savings in the lower sub-1W range on workloads that
only need on of the power wells, e.g. glbenchmark, media playback

Note: The same split isn't there for the forcewake queue, only the
forcwake domains are split.

Signed-off-by: Deepak S <deepak.s@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Rebase on top of the removed forcewake hack in the ring irq
get/put code and add a note to add Deepak's answer to Chris question.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add power well arguments to force wake routines.

Added power well arguments to all the force wake routines
to help us individually control power well based on the
scenario.

Signed-off-by: Deepak S <deepak.s@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Resolve conflict with the removed forcewake hack and drop one
spurious hunk Jesse noticed.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Do not attempt to re-enable an unconnected primary plane

Due to user fudging (for instance using video=VGA-1:e with FBDEV=n) we can
attempt to reset an inconsistent CRTC that is marked as active but has
no assigned fb. It would be wise to fix this earlier, but the long
term plan is to have primary and secondary planes associated with a
CRTC, in which crtc->fb being NULL will be expected. So for a quick
short term fix with pretensions of grandeur, just check for a NULL fb
during GPU reset and ignore the plane restoration.

This fixes a potential hard hang (a panic in the panic handler)
following a GPU hang.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
[danvet: Add a corresponding fixme comment.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add a debugfs entry for power domain info

Add a debugfs entry showing the use-count for all power domains of each
power well.

v3: address comments from Paulo:
- simplify power_domain_str() by using a switch table
- move power_well::domain_count to power_domains
- WARN_ON decrementing a 0 refcount

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add a default always-on power well

So far we distinguished platforms without a dynamic power well with
the HAS_POWER_WELL macro and for such platforms we didn't call any power
domain functions. Instead of doing this check we can add an always-on
power well for these platforms and call the power domain functions
unconditionally. For always-on power wells we only increase/decrease
their refcounts, otherwise they are nop.

This makes high level driver code more readable and as a bonus provides
some idea of the current power domains state for all platforms (once
the relevant debugfs entry is added).

v3: rename intel_power_wells to i9xx_always_on_power_well (Paulo)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't do BDW/HSW specific powerdomains init on other platforms

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: protect HSW power well check with IS_HASWELL in redisable_vga

This may need work if other platforms do the same thing, but in the
meantime we should avoid looking at HSW specific bits in this generic
function.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[added IS_BROADWELL too as that needs the same handling (Imre)]
Signed-off-by: Imre Deak <imre.deak@intel.com>
[danvet: Add Imre's missing sob.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use IS_HASWELL/BROADWELL instead of HAS_POWER_WELL

In intel_display_capture_error_state we use HAS_POWER_WELL to check if
we are running on Haswell/Broadwell when accessing HSW_PWR_WELL_DRIVER
which is specific to these platforms. Future platforms with power wells
don't have this register, so HAS_POWER_WELL won't work there any more.
Use IS_HASWELL/IS_BROADWELL instead.

v3: fix using logical || instead of bitwise | (Paulo)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add always-on power wells instead of special casing them

Instead of using a separate function to check whether a power domain is
is always on, add an always-on power well covering all these power
domains and do the usual get/put on these unconditionally. Since we
don't assign a .set handler for these the get/put won't have any effect
besides the adjusted refcount.

This makes the code more readable and provides debug info also on the
use of always-on power wells (once the relevant debugfs entry is added.)

v3: make is_always_on to be bool instead of a bit field (Paulo)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: support for multiple power wells

HW generations so far had only one always-on power well and optionally
one dynamic power well. Upcoming HW gens may have multiple dynamic power
wells, so add some infrastructure to support them.

The idea is to keep the existing power domain API used by the rest of
the driver and create a mapping between these power domains and the
underlying power wells. This mapping can differ from one HW to another
but high level driver code doesn't need to know about this. Through the
existing get/put API it would just ask for a given power domain and the
power domain framework would make sure the relevant power wells get
enabled in the right order.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add audio power domain

This way the code is simpler and can also be used for other platforms
where the audio power domain->power well mapping is different.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: split fb allocation and initialization v2

If we use a stolen buffer, our probe callback shouldn't allocate a new
buffer; we should re-use the one from the BIOS instead if possible.

v2: fix locking (Jesse)

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Drop forcewake w/a for missed interrupts/seqno on Sandybridge

I believe, and an evening of i-g-t, that our original workaround for the
missed interrupts on Sandybridge, that of holding forcewake whilst we
wait for an interrupts, is no longer required. This leaves us dependent
on the second workaround of forcing an UC read of the ACTHD before
reading back the seqno from the snooped HWS. Dropping the forcewake
should allow us to conserve a little power, not much as the GPU is meant
to be busy whilst we wait for it!

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Move the gtt mm takedown to cleanup

Our VM code already has a cleanup function, and this is a nice place to
put the drm_mm_takedown. This should have no functional impact, it just
leaves the unload function a bit cleaer, and is more logical IMO

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Missed dropped VMA conversion

This belonged in
commit 07fe0b12800d4752d729d4122c01f41f80a5ba5a
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Wed Jul 31 17:00:10 2013 -0700

    drm/i915: plumb VM into bind/unbind code

But it was somehow missed along the way.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove defunct ctx switch comments

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Removed unused vm args

i915_gem_execbuffer_relocate became defunct in:
commit 27173f1f95db5e74ceb35fe9a2f2f348ea11bac9
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Wed Aug 14 11:38:36 2013 +0200

    drm/i915: Convert execbuf code to use vmas

eb_create: never used?

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: The lingering vm parameter to eb_create might have been back
from the days where we didn't yet keep both vmas and obj lists in the
eb struct. But I didn't check really.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Demote drop_caches_set print

Many tests call this ad naseum now (in an infinite loop, very often).
It clutters the logs. Actually, I'd rather drop it completely...

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Disallow dynamic ppgtt param modification

This would have never worked.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add a few missed bits to the mm

This should really have been added in BDW integration, as well as:

commit 93bd8649dba3155d1a0ba2a902d9c49f1c75a1da
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Tue Jul 16 16:50:06 2013 -0700

    drm/i915: Put the mm in the parent address space

It didn't really matter before, but it will in the future.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix BDW PPGTT error path

When we fail for some reason on loading the PDPs, it would be wise to
disable the PPGTT in the ring registers. If we do not do this, we have
undefined results.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't set the fence number in DPFC_CTL on SNB

SNB has another register where the actual FBC CPU fence number is
stored. The documenation explicitly states that the fence number
in DPFC_CTL must be 0 on SNB. And in fact when it's not zero,
the GTT tracking simply doesn't work.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix module unloading with DRM_I915_UMS=n

Oops, makes testing early boot failures in i915.ko a bit more pain, so
let's fix it.

v2: We already have a bit of static storage to track this (Chris).

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

i915, fbdev: Fix Kconfig typo

Too many t's.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

i915, debugfs: Fix uninitialized warning

gcc complains that:

drivers/gpu/drm/i915/i915_debugfs.c: In function ‘display_crc_ctl_write’:
drivers/gpu/drm/i915/i915_debugfs.c:2393:2: warning: ‘val’ may be used uninitialized in this function [-Wuninitialized]
drivers/gpu/drm/i915/i915_debugfs.c:2350:6: note: ‘val’ was declared here

but it can't see that we're going to use val only in the success case.
So shut it up.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Hold pc8 lock around toggling pc8.gpu_idle

We need to hold the pc8 lock around toggling the value of gpu_idle.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Enable pipe gamma for sprites

We send the primary and cursor plane data through the gamma unit.
In order to get matching output from sprites, also send the sprite
data through the gamma unit.

In the future we should add some properties to control this
explicitly, and also add properties for the per-sprite gamma ramps
what have you, but for now this seems like a reasonable thing to do.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use plane_name() in gen7_enable_fbc()

All the other .enable_fbc() funcs use plane_name(). Make
gen7_enable_fbc() do the same.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Set has_fbc=true for all SNB+, except VLV

At least since SNB (perhaps even earlier) even the desktop parts
should have FBC.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Emit SRM after the MSG_FBC_REND_STATE LRI

The spec tells us that we need to emit an SRM after the LRI
to MSG_FBC_REND_STATE.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Limit FBC flush to post batch flush

Don't issue the FBC nuke/cache clean command when invalidate_domains!=0.
That would indicate that we're not being called for the post-batch
flush.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remove intel_uncore_clear_errors

This was forgotten in

commit 9d1cb9147dbe45f6e94dc796518ecf67cb64b359
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Nov 1 13:32:08 2013 -0200

    drm/i915: avoid unclaimed registers when capturing the error state

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: reuse WRPLL when possible

It seems we do have machines with 3 HDMI/DVI outputs, so sharing
WRPLLs is the only way to get 3 pipes working.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68485
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: dp aux irq support for g4x/vlv

Now we have this everywhere. Next up would be to wire up the DP
hotplug pin to speed up panel power sequencing for eDP panels ...

I've decided to leave the has_aux_irq logic in the code, it should
come handy for hw bringup.

For testing/fail-safety the dp aux code already has a timeout when
waiting for interrupts to signal completion and screams rather loud if
they don't arrive in time. Given that we need a real piece of hw to
talk to anyway this is probably as good as it gets.

v2: Don't check the dp aux channel bits on i965 machines, they have a
different meaning there. Yay for reusing bits at will! Spotted by
Jani.

Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Merge branch 'backlight-rework' into drm-intel-next-queued

Pull in Jani's backlight rework branch. This was merged through a
separate branch to be able to sort out the Broadwell conflicts
properly before pulling it into the main development branch.

Conflicts:
drivers/gpu/drm/i915/intel_display.c

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Merge branch 'bdw-fixes' into backlight-rework

Merge the bdw changes into the backlight rework branch so that we can
adapt the new code for bdw, too.  This is a bit a mess, but doing this
another way would have delayed the merging of the backlight
refactoring. Mea culpa.

As discussed with Jani on irc only do bdw-specific callbacks for the
set/get methods and bake in the only other special-case into the pch
enable function.

Conflicts:
drivers/gpu/drm/i915/intel_panel.c

v2: Don't enable the PWM too early for bdw (Jani).

v3: Create new bdw_ functions for setup and enable - the rules change
sufficiently imo with the switch from controlling the pwm from the cpu
to controlling it completel from the pch to warrant this.

v4: Rip out unused pipe variable in bdw_enable_backlight (0-day
builder).

Tested-by: Ben Widawsky <ben@bwidawsk.net> (on bdw)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Reject opening of pipe crc files for invalid pipes

We don't init the lock nor set up all the other state. And it doesn't
make sense anyway.

This appeases lockdep when running the igt/drv_debugfs_reader test.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use for_each_pipe in intel_display_crc_init

We have a nice macro, so use it.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: do not save/restore backlight registers in KMS

The backlight enable code now has the smarts to do the right thing. Only
do backlight register save/restore in UMS.

Some VLV specific code gets dropped as UMS is not supported on VLV.

v2: Move save/restore to UMS instead of removing completely (Daniel).

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: nuke get max backlight functions

No longer needed. We now have fully cached max backlight values.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE

The quirk was added as what I'd say was a stopgap measure in

commit e85843bec6c2ea7c10ec61238396891cc2b753a9
Author: Kamal Mostafa <kamal@canonical.com>
Date:   Fri Jul 19 15:02:01 2013 -0700

    drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight

without really digging into what was going on.

Also, as mentioned in the related bug [1], having the quirk regressed
some of the machines it was supposed to fix to begin with, and there
were patches posted to disable the quirk on such machines [2]!

The fact is, we do need the BLM_PCH_PWM_ENABLE bit set to have
backlight. With the quirk, we've relied on BIOS to have set it, and our
save/restore code to retain it. With the full backlight setup at enable,
we have no place for things that rely on previous state.

With the per platform hooks, we've also made a change in the PCH
platform enable order: setting the backlight duty cycle between CPU and
PCH PWM enable. Some experimenting and

commit 770c12312ad617172b1a65b911d3e6564fc5aca8
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sat Aug 11 08:56:42 2012 +0200

    drm/i915: Fix blank panel at reopening lid

indicate that we can't set the backlight before enabling CPU PWM; the
value just won't stick. But AFAICT we should do it before enabling the
PCH PWM.

Finally, any fallout we should fix properly, preferrably without quirks,
and absolutely without quirks that rely on existing state. With the per
platform hooks have much more flexibility to adjust the sequence as
required by platforms.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=47941
[2] http://lkml.kernel.org/r/1378229848-29113-1-git-send-email-kamal@canonical.com

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: do full backlight setup at enable time

We should now have all the information we need to do a full
initialization of the backlight registers.

v2: Keep QUIRK_NO_PCH_PWM_ENABLE for now (Imre).

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bdw: PIPE_[BC] I[ME]R moved to powerwell

The pipe B and pipe C interrupt mask and enable registers are now part
of the pipe, so disabling the pipe power wells will lost the contests of
the registers.

Art totally debugged this one!

v2: Use the irq_lock to clarify code, and prevent future bugs (Daniel)

Cc: Art Runyan <arthur.j.runyan@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Make sparse happy.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bdw: Limit GTT to 2GB

Because of the way in which we're allocating the pages for the Aliasing
PPGTT, we cannot actually successfully alloc enough space for anything
greater than 2GB.

Instead of a quick hack to fix this, we should defer until we have the
real solution in place (allocating much less contiguous space).

This wasn't found sooner because we didn't not have any systems
supporting more than a 2GB GTT.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bdw: Add comment about gen8 HWS PGA

This confused me some many times that I think it is appropriate to add a
small comment to instruct the reader of the code that it is indeed doing
what it is supposed to do.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bdw: Free correct number of ppgtt pages

I am unclear how this got messed up in the shuffle, but it did.

Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bdw: Do gen6 style reset for gen8

This patch existed before, but was lost over time.

Note that reset is still somewhat problematic in my limited testing (ie.
module_reload will not pass) but it can be disabled with a module
parameter, and support should be considered preliminary anyway.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bdw: GEN8 backlight support

Prior to Haswell the CPU control register for backlight
(BLC_PWM_CPU_CTL) toggled the PCH baclight pin for us. This made some
sense as there was no pin on the CPU. With Haswell came the introduction
of a CPU backlight pin, but the interface was still controlled by
software with the same mechnism. Behind the scenes, hardware did all the
dirty work for us.

Broadwell no longer provides this for free. If we want to use the PCH
backlight pin [1] then we have to set the override bit BLC_PWM_PCH_CTL1
and program BLC_PWM_PCH_CTL2 for the PWM values.

This patch implements that. This patch is compile tested only, and given
that I rarely if ever touch this code, careful review is welcome.

[1] According to Art, we know of no devices that exist which use the CPU
pin (and remember it has existed already on HSW). If such a device does
exist, we'll have to handle it properly - this is left as TODO until
then.

v2: Drop the abstraction prep patch, as a bigger backlight overhaul is
    in the works, and do just the mimimal bdw enabling now. (by Jani)

CC: Art Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bdw: Add BDW to ULT macro

For what we care about ULT and ULX are interchangeable. We know of 3
types of pciids for these cases. I am not sure if at some point we will
need to distinguish ULT and ULX.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: gather backlight information at setup

Prepare for being able to use the information at enable.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Deprecated UMS support

It's been 5 years since kms support was merged and roughly 4 years
since UMS support was ripped out from userspace drivers.

Thus far it's not been a big burden to keep the ums paths alive, and
we've made some good progress in better separating it from the kms
code by sprinkling DRIVER_MODESET checks all over the place.

But now that the drm demidlayering is within reach this changes. I
want to make the driver loading code more robust using devres.c and
other cool tricks. But that doesn't work with ums due to the
shadow-attach trick. Which means we either
a) need to split out a complete ums codebase like radeon has
b) kill it for good.

The 2nd option is obviously much less work than the first, so I think
it's time to test the waters and see how many people out there still
use ums.

I've decided that silently failing to initialize the driver (and not
e.g. failing to load the module) is the right thing. That way we
should only get reports from users that actually care about some ums
features (like accelerated gl or support for secondary outputs).
Everyone else will just fall back to the vesa X driver.

For developers there's a small info level dmesg output.

The plan is to drop this Kconfig option after 3.16 (so gives us 2 full
releases) and then start killing code for real 2-3 releases
afterwards. That should be more than enough time for users to pipe up.

Of course if anyone does we need to revisit this plan and maybe go
with option a) above.

Also enable the KMS support by default in Kconfig and polish the help
texts a bit.

v2: Add the missing hunk of actual code changes. Oops. (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dave Airlie <airlied@gmail.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Kill legeacy AGP for gen3 kms

Thus far we've tried to carefully work around the fact that old
userspace relied on the AGP-backed legacy buffer mapping ioctls for a
bit too long. But it's really horribly, and now some new users for it
started to show up again:

http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg45547.html

This uses drmAgpSize to figure out the GTT size, which is both the
wrong thing to inquire and also might force us to keep this crap
around for another few years.

So I want to stop this particular zombie from raising ever again. Now
it's only been 4 years since XvMC was fixed for gen3, so a bit early
by the usual rules. But since Linus explicitly said that an ABI
breakage only counts if someone actually observes it I want to tempt
fate an accelarate the demise of AGP.

We probably need to wait 2-3 kernel releases with this shipping until
we go on a killing spree code-wise.

v2: Remove intel_agp_enabled since it's unused (Ville).

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dave Airlie <airlied@gmail.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Make AGP=n work even on gen3

Most platforms din't hit this condition, but if we want to allow
building without agp we should also make this allowed on gen3.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Merge branch 'drm-next-3.13' of git://people.freedesktop.org/~agd5f/linux into drm-next

One last patch I keep forgetting to include.  Fix for EDID quirk
handling.  Been on the list and reviewed for several months now,
I just keep forgetting about it.

* 'drm-next-3.13' of git://people.freedesktop.org/~agd5f/linux:
  drm/edid: compare actual vrefresh for all modes for quirks

Merge tag 'drm-intel-fixes-2013-11-12' of git://people.freedesktop.org/~danvet/drm-intel into drm-next

Just one patch to fix compile fail for CONFIG_ACPI=n. Figured I better
send this out quickly to minimize the broken build span. Otherwise no
bugfixes (besides some bdw stuff) anywhere in sight.

* tag 'drm-intel-fixes-2013-11-12' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915/opregion: fix build error on CONFIG_ACPI=n

Merge branch 'ttm-next-3.13' of git://people.freedesktop.org/~thomash/linux into drm-next

The page-prot bit fix.

* 'ttm-next-3.13' of git://people.freedesktop.org/~thomash/linux:
  drm/ttm: Fix vma page_prot bit manipulation

Merge branch 'vmwgfx-next-3.13' of git://people.freedesktop.org/~thomash/linux into drm-next

A resource eviction fix, and a fix for compilation / sparse problems
from the previous pull.

* 'vmwgfx-next-3.13' of git://people.freedesktop.org/~thomash/linux:
  drm/vmwgfx: Fix a couple of compile / sparse warnings and errors
  drm/vmwgfx: Resource evict fixes

drm/i915: check i915_get_reset_stats_ioctl args

Insist that flags and pad fields are zero, so that
we can safely extend the interface in future.

Testcase: igt/gem_reset_stats/params

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: debug print on backlight register

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use the initialized backlight max value instead of reading it

We now have the max backlight value cached. Use it.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move backlight level setting in enable/disable to hooks

This allows more flexibility in the ordering of the register writes, and
lets us drop level setting altogether as necessary on a per platform
basis.

For gen2-gen3, this is the only thing that happens in enable/disable.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: vlv does not have pipe field in backlight registers

It has per pipe registers.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix gen2-gen3 backlight set

Citing Jani's response to Imre's question in the review discussion:

> According to the gen2/3 bspec I have, the correct mask is
> BACKLIGHT_DUTY_CYCLE_MASK_PNV only in case of IS_PINEVIEW(dev), for
> everything else it's BACKLIGHT_DUTY_CYCLE_MASK.

What you say is correct, but we've treated all gen2/3 similar to PNV
since

commit ca88479c1c3b7b1a9f94320745f5331e1de77f80
Author: Keith Packard <keithp@keithp.com>
Date:   Fri Nov 18 11:09:24 2011 -0800

    drm/i915: Treat pre-gen4 backlight duty cycle value consistently

i.e. we only use the high 15 bits for all gen2/3. For non-PNV this just
means the lowest bit is always zero. For PNV the lowest bit has a
different meaning in both the PWM freq and duty cycle fields.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Make the commit message less empty.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/ttm: Fix vma page_prot bit manipulation

Fix a long-standing TTM issue where we manipulated the vma page_prot
bits while mmap_sem was taken in read mode only. We now make a local
copy of the vma structure which we pass when we set the ptes.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>

drm/vmwgfx: Fix a couple of compile / sparse warnings and errors

Fixes
 *) an implicit function declaration on mips,
 *) a defined but not used label on !CONFIG_INTEL_IOMMU
 *) Hopefully a couple of sparse warnings where we implicitly typecast
    integer to __le32 and vice versa.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

drm/vmwgfx: Resource evict fixes

Fix an error message that was incorrectly blaming device resource id
shortage.

Also make sure we correctly catch resource eviction errors, that
could otherwise lead to evictable resources temporarily not being on the
LRU list.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Cc: stable@vger.kernel.org

drm/i915: drop duplicate ggtt vma list add in setup_global_gtt

Preallocated objects will already have been added to the vma_list when
creating their ggtt vma entry, and coincidentally also marked as holding
a ggtt mapping. Repeating the vma_list manipulation when setting up the
ggtt after preallocation is a recipe for an unhappy kernel.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Use the improve commit message suggest by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: handle backlight through chip specific functions

The backlight code has grown rather hairy, not least because the
hardware registers and bits have repeatedly been shuffled around. And
this isn't expected to get any easier with new hardware. Make things
easier for our (read: my) poor brains, and split the code up into chip
specific functions.

There should be no functional changes.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: make asle notifications update backlight on all connectors

ALthough usually there's only one connector that supports backlight,
this also finds the correct connector. Before, we only updated the
connector on pipe A, which might not be the one with backlight. (This
only made a difference on BYT.)

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: make backlight info per-connector

Move from dev_priv to connector->panel. We still don't allow multiple
sysfs interfaces, though.

There should be no functional changes, except for a slight reordering of
connector backlight and sysfs destroy calls. (This change happens now
that the backlight device is actually per-connector, even though the
destroy calls became per-connector earlier.)

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: clean up backlight conditional build

I've always felt the backlight device conditional build has been all
backwards. Make it feel right.

Gently move things towards connector based stuff while at it.

There should be no functional changes.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add i915_get_reset_stats_ioctl

This ioctl returns reset stats for specified context.

The struct returned contains context loss counters.

reset_count:    all resets across all contexts
batch_active:   active batches lost on resets
batch_pending:  pending batches lost on resets

v2: get rid of state tracking completely and deliver only counts. Idea
    from Chris Wilson.

v3: fix commit message

v4: default context handled inside i915_gem_context_get_hang_stats

v5: reset_count only for priviledged process

v6: ctx=0 needs CAP_SYS_ADMIN for batch_* counters (Chris Wilson)

v7: context hang stats never returns NULL

v8: rebased on top of reworked context hang stats
    DRM_RENDER_ALLOW for ioctl

v9: use DEFAULT_CONTEXT_ID. Improve comments for ioctl struct members

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Ian Romanick <idr@freedesktop.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add i915_reset_count

reset_counter will be incremented twice per successful
reset. Odd values mean reset is in progress and even values
mean that reset has completed.

Reset status ioctl introduced in following commit
needs to deliver global reset count to userspace so
use reset_counter to derive the actual reset count
for the gpu

Note that reset in progress is enough to increment
the counter.

v2: wedged equals reset in progress (Daniel Vetter)

v3: Fixed stale comments (Damien Lespiau)

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: tune reset dmesg output a bit

We don't want any ERROR for simulated gpu hangs, otoh printing the
error code when the reset failed for real should be interesting.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71333
lu hua <huax.lu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/edid: compare actual vrefresh for all modes for quirks

The vrefresh field of the mode is 0 for most modes
fetched from the EDID (e.g., established timings).
When dealing with monitors that have a bogus preferred
mode, we may not always select the mode we want because
we compare the target refresh to the mode's vrefresh which
is 0 in a lot of cases.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915/vlv: Make the vlv_dpio_read/vlv_dpio_write more PHY centric

vlv_dpio_read/write should be describe more in PHY centric instead of
display controller centric.
Create a enum dpio_channel for channel index and enum dpio_phy for PHY
index.  This should better to gather for upcoming platform.

v2: Rebase the code based on
drm/i915/vlv: Fix typo in the DPIO register define.

v3: Rename vlv_phy to dpio_phy_iosf_port and define additional macro
DPIO_PHY, and remove unrelated change. (Ville)

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Merge branch 'gma500-next' of git://github.com/patjak/drm-gma500 into drm-next

SDVO support for minnowboard

* 'gma500-next' of git://github.com/patjak/drm-gma500:
  drm/gma500/mrst: Add SDVO to output init
  drm/gma500/mrst: Don't blindly guess a mode for LVDS
  drm/gma500/mrst: Setup GMBUS for oaktrail/mrst
  drm/gma500/mrst: Replace WMs and chickenbits with values from EMGD
  drm/gma500/mrst: Add aux register writes to SDVO
  drm/gma500/mrst: Properly route oaktrail hdmi hooks
  drm/gma500/mrst: Add aux register writes when programming pipe
  drm/gma500/mrst: Add SDVO clock calculation
  drm/gma500: Add aux device support for gmbus
  drm/gma500: Add support for aux pci vdc device
  drm/gma500: Add chip specific sdvo masks
  drm/gma500: Add Minnowboard to the IS_MRST() macro

drm: shmob_drm: Convert to clk_prepare/unprepare

Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and
clk_disable_unprepare() to get ready for the migration to the common
clock framework.

Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge tag 'bdw-stage1-2013-11-08-v2' of git://people.freedesktop.org/~danvet/drm-intel into drm-next

So here's the Broadwell pull request. From a kernel driver pov there's
two areas with big changes in Broadwell:
- Completely new enumerated interrupt bits. On the plus side it now looks
  fairly unform and sane.
- Completely new pagetable layout.

To ensure minimal impact on existing platforms we've refactored both the
irq and low-level gtt handling code a lot in anticipation of the bdw push.
So now bdw enabling in these areas just plugs in a bunch of vfuncs.

Otherwise it's all fairly harmless adjusting of switch cases and
if-ladders to shovel bdw into the right blocks. So minimized impact on
existing platforms. I've also merged the bdw-stage1 branch into our
-nightly integration branch for the past week to make sure we don't break
anything.

Note that there's still quite a flurry or patches floating around, but
I've figured I'll push this out. I plan to keep the bdw fixes separate
from my usual -fixes stream so that you can reject them easily in case it
still looks like too much churn. Also, bdw is for now hidden behind the
preliminary hw enabling module option. So there's no real pressure to get
follow-up patches all into 3.13.

* tag 'bdw-stage1-2013-11-08-v2' of git://people.freedesktop.org/~danvet/drm-intel: (75 commits)
  drm/i915: Mask the vblank interrupt on bdw by default
  drm/i915: Wire up cpu fifo underrun reporting support for bdw
  drm/i915: Optimize gen8_enable|disable_vblank functions
  drm/i915: Wire up pipe CRC support for bdw
  drm/i915: Wire up PCH interrupts for bdw
  drm/i915: Wire up port A aux channel
  drm/i915: Fix up the bdw pipe interrupt enable lists
  drm/i915: Optimize pipe irq handling on bdw
  drm/i915/bdw: Take render error interrupt out of the mask
  drm/i915/bdw: Add BDW PCH check first
  drm/i915: Use hsw_crt_get_config on BDW
  drm/i915/bdw: Change dp aux timeout to 600us on DDIA
  drm/i915/bdw: Enable trickle feed on Broadwell
  drm/i915/bdw: WaSingleSubspanDispatchOnAALinesAndPoints
  drm/i915/bdw: conservative SBE VUE cache mode
  drm/i915/bdw: Limit SDE poly depth FIFO to 2
  drm/i915/bdw: Sampler power bypass disable
  ddrm/i915/bdw: Disable centroid pixel perf optimization
  drm/i915/bdw: BWGTLB clock gate disable
  drm/i915/bdw: Implement edp PSR workarounds
  ...

Merge branch 'drm-next-3.13' of git://people.freedesktop.org/~agd5f/linux into drm-next

A few more patches for 3.13.  The big one here is Hawaii support.
I wanted to get that out sooner, but was sick earlier this week.  That
said, it's mostly self contained, so it shouldn't impact other asics.
The rest are just bug fixes and a merge fix.

* 'drm-next-3.13' of git://people.freedesktop.org/~agd5f/linux: (23 commits)
  Revert "drm/radeon/audio: don't set speaker allocation on DCE4+"
  drm/radeon/audio: improve ACR calculation
  drm/radeon/audio: correct ACR table
  drm/radeon: fix mismerge of drm-next with 3.12
  drm/radeon: add pci ids for hawaii
  drm/radeon: fill in radeon_asic_init for hawaii
  drm/radeon: modesetting updates for hawaii
  drm/radeon: atombios.h updates for hawaii
  drm/radeon: update cik_get_csb_buffer for hawaii
  drm/radeon: add hawaii dpm support
  drm/radeon/cik: add hawaii UVD support
  drm/radeon: update firmware loading for hawaii
  drm/radeon: update rb setup for hawaii
  drm/radeon: add golden register settings for hawaii
  drm/radeon: update cik_tiling_mode_table_init() for hawaii
  drm/radeon: minor updates to cik.c for hawaii
  drm/radeon: update cik_gpu_init() for hawaii
  drm/radeon: add Hawaii chip family
  drm/radeon: fix-up some float to fixed conversion thinkos
  drm/radeon: use HDP_MEM_COHERENCY_FLUSH_CNTL for sdma as well
  ...

Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into drm-next

prime support, inactive rework, render nodes
* 'msm-next' of git://people.freedesktop.org/~robclark/linux:
  drm/msm/mdp4: page_flip cleanups/fixes
  drm/msm: EBUSY status handling in msm_gem_fault()
  drm/msm: rework inactive-work
  drm/msm: add plane support
  drm/msm: resync generated headers
  drm/msm: support render nodes
  drm/msm: prime support

drm/nouveau: fix 32-bit build

This uses the proper div macro.

Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/i915/opregion: fix build error on CONFIG_ACPI=n

Fix CONFIG_ACPI=n build fail

  CC      drivers/gpu/drm/i915/intel_opregion.o
drivers/gpu/drm/i915/intel_opregion.c: In function ‘intel_opregion_setup’:
drivers/gpu/drm/i915/intel_opregion.c:879:2: error: ‘asle_work’ undeclared (first use in this function)
drivers/gpu/drm/i915/intel_opregion.c:879:2: note: each undeclared identifier is reported only once for each function it appears in
make[4]: *** [drivers/gpu/drm/i915/intel_opregion.o] Error 1

introduced in
commit 91a60f20712179e56b7a6c3d332a5f6f9a54aa11
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Thu Oct 31 18:55:48 2013 +0200

    drm/i915: move opregion asle request handling to a work queue

Reported-by: Jim Davis <jim.epost@gmail.com>
Reference: http://lkml.kernel.org/r/CA+r1ZhjcFpr5KKVX0pLCOP8cAyZoiYO=UyqYMJtNSV-Kt_p7xQ@mail.gmail.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Revert "drm/radeon/audio: don't set speaker allocation on DCE4+"

This reverts commit 555b1b651acf44bf27ebbb04235d38a8fd2d58dc.

Let's try this again for 3.13.  It's required for proper
interaction with alsa.  Was disabled previously in 3.12
to be on the safe side since it caused problems on older
asics.

drm/radeon/audio: improve ACR calculation

In order to have any realistic chance of calculating proper
ACR values, we need to be able to calculate both N and CTS,
not just CTS. We still aim for the ideal N as specified in
the HDMI spec though.

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

Signed-off-by: Pierre Ossman <pierre@ossman.eu>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/audio: correct ACR table

The values were taken from the HDMI spec, but they assumed
exact x/1.001 clocks. Since we round the clocks, we also need
to calculate different N and CTS values.

Note that the N for 25.2/1.001 MHz at 44.1 kHz audio is out of
spec. Hopefully this mode is rarely used and/or HDMI sinks
tolerate overly large values of N.

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

Signed-off-by: Pierre Ossman <pierre@ossman.eu>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix mismerge of drm-next with 3.12

Audio is enabled by default now.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/i915: Make AGP support optional

We only depend on the intel-gtt module for GTT frobbign on older gens.
The intel_agp module is optional, except for UMS and some old XvMC
userland on gen3. So make AGP support optional. As before, we will
fail the i915 init for UMS and gen3 KMS the same as before if
intel_agp isn't around.

intel-gtt.c is left with a somewhat ugly ifdef mess, but I'm going
to save that for a later cleaning.

At least my gen2 still works with the patch and CONFIG_AGP=n.

v2: Make i915 depend on X86 and PCI, and intel-gtt depend on PCI

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>