We have a slightly different way of readoing out the cdclk in
gmbus_set_freq(). Kill that and just call .get_display_clock_speed().

Also need to remove the GMBUSFREQ update from intel_i2c_reset() since
that gets called way too early. Let's do it in intel_modeset_init_hw()
instead, and also pull the initial vlv_cdclk_freq update there from
init_clock gating.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If someone is interested in the current cdclk frquency it should
be stable and not in process of changing frquency. Warn if the current
and requested cdclk don't match in .get_display_clock_spee() on vlv.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

VLV Punit doesn't support the 400MHz cdclk option, so we bypass the
Punit and poke at CCK directly. However we forgot to wait for the
frequeency change to complete. Poll the CCK clock status to make sure
the clock has changed before we fire up any pipes.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Drop the cdclk frequency to 200MHz on vlv when all pipes are off. In
theory we should be able to use 200MHz also when the pixel clock is at
most 90% of 200MHz. However in practice all we seem to get is a solid
color picture or an otherwise corrupted display.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Depending on the HPLL frequency one of the supported cdclk frquencies is
either 320MHz or 333MHz. Figure out which one it is to accurately pick
the minimal required cdclk. This would also avoid a warning from the
cdclk code where it compares the actual cdclk read out from the hardware
with a value that was calculated using valleyview_calc_cdclk().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have a standard hook for reading out the current cdclk. Move the VLV
code from valleyview_cur_cdclk() to .get_display_clock_speed().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Avoid using magic values for CCK frequency bits. Also the mask we were
using for the requested frequency was one bit too short. Fix it up.

Note: This also fixes the #define for a mask (spotted by Jesse in his
review).
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add note about mask change.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use kHz units in vlv cdclk code since that's more customary.

Also replace the precomputed 90% values with *9/10 computation
for extra clarity.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Inlcude the pipe-size and cursor-size in debugfs.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

For Haswell and Broadwell, if the display power well has been disabled,
the display audio controller divider values EM4 M VALUE and EM5 N VALUE
will have been lost. The CDCLK frequency is required for reprogramming them
to generate 24MHz HD-A link BCLK. So provide a private interface for the
audio driver to query CDCLK.

This is a stopgap solution until a more generic interface between audio
and display drivers has been implemented.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a
vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register:
SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to
SVGA_REG_PITCHLOCK.

This patch is Cc'd stable because of the unknown effects writing to this
register might have, particularly on older device versions.

v2: Updated log message.

Cc: stable@vger.kernel.org
Cc: Christopher Friedt <chrisfriedt@gmail.com>
Tested-by: NChristopher Friedt <chrisfriedt@gmail.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>

The GEN FBC unit provides the ability to set a low pass on frames it
attempts to compress. If a frame is less than a certain amount
compressibility (2:1, 4:1) it will not bother. This allows the driver to
reduce the size it requests out of stolen memory.

Unluckily, a few months ago, Ville actually began using this feature for
framebuffers that are 16bpp (not sure why not 8bpp). In those cases, we
are already using this mechanism for a different purpose, and so we can
only achieve one further level of compression (2:1 -> 4:1)

FBC GEN1, ie. pre-G45 is ignored.

The cleverness of the patch is Art's. The bugs are mine.

v2: Update message and including missing threshold case 3 (Spotted by Arthur).

Cc: Art Runyan <arthur.j.runyan@intel.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Right now, there is no threshold (0 means fail, 1 means 1:1 compression
limit). This is to split the function/non-functional change of the next
patch.

The next patch will start to attempt to reduce the amount of CFB space
we need for dire situations. It will be contained within this function.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

We are already using the size to determine whether or not to free the
object, so there is no functional change there. Almost everything else
has changed to static allocations of the drm_mm_node too.

Aside from bringing this inline with much of our other code, this makes
error paths slightly simpler, which benefits the look of an upcoming
patch.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

1539fb9b managed to somehow +x
drm_drv.c undo it.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Userspace shouldn't be able to access them.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Volatile bit was in the wrong location.  This bit is
not used at the moment.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

use mm.h definition

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NFabian Frederick <fabf@skynet.be>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Higher RC6 residency is observed using timeout mode
instead of EI mode.  This applies to Broadwell only.
The difference is particularly noticeable with video
playback.
Signed-off-by: NTom O'Rourke <Tom.O'Rourke@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This prevents a panic: radeon_crtc_handle_page_flip() could run before
radeon_flip_work_func(), triggering the BUG_ON() in drm_vblank_put().
Tested-by: NDieter Nützel <Dieter@nuetzel-hh.de>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We were using the vddc mask rather than the vddci mask.

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

May also fix:
https://bugs.freedesktop.org/show_bug.cgi?id=69723

Noticed by: Dieter Nützel <Dieter@nuetzel-hh.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

We were using the vddc mask rather than the vddci mask.

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

Possibly also fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=68571Noticed-by: NJonathan Howard <jonathan@unbiased.name>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

v2: agd5f: compile fix
Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Some monitors seem to have problems with deep color enabled, even
though they claim to support it.  I'm not sure if the monitor
need a quirk or if the driver is doing something the monitor doesn't
like.  At this point lets just disable deep color by default like
we did for hdmi audio and work through the bugs so we can eventually
enable it by default.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=80531Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

bapm enabled the GPU and CPU to share TDP headroom.  It was
disabled by default since some laptops hung when it was enabled
in conjunction with dpm.  It seems to be stable on desktop
boards and fixes hangs on boot with dpm enabled on certain
boards, so enable it by default on desktop boards.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=72921Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

bapm allows the GPU and CPU to share TDP.  This allows
for additional performance out of the GPU and CPU when
the headroom is available.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Newer asics shouldn't need any manual adjustment.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Set the default to 600Mhz if it's not set in the bios,
and bump the default to 600Mhz if it's lower than that.

This fixes display issues with certain 4k DP monitors when
using 5.4 Ghz DP clocks.

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

It is possible that, by the time we run i915_drm_freeze(),
delayed_resume_work was already queued but did not run yet. If it
still didn't run after intel_runtime_pm_disable_interrupts(), by the
time it runs it will try to change the interrupt registers with the
interrupts already disabled, which will trigger a WARN. We can
reliably reproduce this with the pm_rpm system-suspend test case.

In order to avoid the problem, we have to flush the work before
disabling the interrupts. We could also cancel the work instead of
flushing it, but that would require us to put a runtime PM reference -
and any other resource we may need in the future - in case the work
was already queued, so I believe flushing the work is more
future-proof, although less efficient. But I can also change this part
if someone requests.

Another thing I tried was to move the intel_suspend_gt_powersave()
call to before intel_runtime_pm_disable_interrupts(), but since that
function needs to be called after the interrupts are already disabled,
due to dev_priv->rps.work, this strategy didn't work.

Testcase: igt/pm_rpm/system-suspend
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80517Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Drop WA to fix Voltage not getting dropped to Vmin when Gfx is power
gated for latest VLV revision.

Workaround fixed in Latest VLV revision. Forcing Gfx clk up not needed,
and Requesting the min freq should bring bring the voltage Vnn.

v2: Drop WA for Latest VLV revision (Ville)
Signed-off-by: NDeepak S <deepak.s@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[Jani: modified code comment, reformatted the commit message a bit.]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Apparently we can't trust this field on other platforms and need to find
some other way.

This fixes a regression introduced in
commit 27da3bdf
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Apr 4 16:12:07 2014 -0700

    drm/i915: use VBT to determine whether to enumerate the VGA port
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

BDW signals the flip done interrupt immediately after the DSPSURF write
when the plane is disabled. This is true even if we've already armed
DSPCNTR to enable the plane at the next vblank. This causes major
problems for our page flip code which relies on the flip done interrupts
happening at vblank time.

So what happens is that we enable the plane, and immediately allow
userspace to submit a page flip. If the plane is still in the process
of being enabled when the page flip is issued, the flip done gets
signalled immediately. Our DSPSURFLIVE check catches this to prevent
premature flip completion, but it also means that we don't get a flip
done interrupt when the plane actually gets enabled, and so the page
flip is never completed.

Work around this by re-introducing blocking vblank waits on BDW
whenever we enable the primary plane.

I removed some of the vblank waits here:
 commit 6304cd91
 Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
 Date:   Fri Apr 25 13:30:12 2014 +0300

    drm/i915: Drop the excessive vblank waits from modeset codepaths

To avoid these blocking vblank waits we should start using the vblank
interrupt instead of the flip done interrupt to complete page flips.
But that's material for another patch.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79354Tested-by: NGuo Jinxian <jinxianx.guo@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The TDA998x can't handle modes with clocks above 150MHz, or resolutions
larger than 8192x2048.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

One of Jean-Francois patches changed the EDID polling to once every
10ms for 10 interations, whereas the original code did 1ms for 100
interations.  This appears to cause boot-time detection to take
noticably longer.  Revert this change.
Acked-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Currently tda998x_encoder_destroy() calls cec_write() and reg_clear(),
as part of the release procedure. Such calls need to access the I2C bus
and therefore, we need to call them before drm_i2c_encoder_destroy()
which unregisters the I2C device.

This commit moves the latter so it's done afterwards.
Signed-off-by: NGuido Martínez <guido@vanguardiasur.com.ar>
Signed-off-by: NEzequiel García <ezequiel@vanguardiasur.com.ar>
Cc: <stable@vger.kernel.org> #v3.9+
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

crtc->primary->fb may be NULL upon entry to intel_pipe_set_base() if the
primary plane has previously been disabled via the universal plane
interface.  We need to check for NULL before trying to reference
old_fb's obj.

This fixes a regression introduced in

        commit a071fa00
        Author: Daniel Vetter <daniel.vetter@ffwll.ch>
        Date:   Wed Jun 18 23:28:09 2014 +0200

        drm/i915: Introduce accurate frontbuffer tracking

Testcase: igt/kms_universal_plane
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

For MIPI, DSI PLL is configured separately in vlv_configure_dsi_pll
during the DSI enable sequence

Causing WARN dump otherwise in dpio_reads

v2: Add IS_CHERRYVIEW check as suggested by Ville
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

If user uses wrong ioctl command with _IOC_NONE and argument size
greater than 0, it can cause NULL pointer access from memset of line
463. If _IOC_NONE, don't memset to 0 for kdata.
Signed-off-by: NZhaowei Yuan <zhaowei.yuan@samsung.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

mixer_wait_for_vblank function expects that the upcoming
vsync interrupt handler routine will clear the
wait_vsync_event atomic variable.

For this to happen, interrupts should be enabled and
disabled properly.
Signed-off-by: NRahul Sharma <rahul.sharma@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>