The encoder->mode_set callback from the crtc helpers is now completely
unused in our driver. Good riddance!
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Everyone is now using our own ->compute_config callback, which means
we can now also make that callback mandatory.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need the correct clock to accurately assess whether we need to
enable the double wide pipe mode or not.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: Stuart Abercrombie <sabercrombie@google.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently, the register access code is split between i915_drv.c and
intel_pm.c. It only bares a superficial resemblance to the reset of the
powermanagement code, so move it all into its own file. This is to ease
further patches to enforce serialised register access.

v2: Scan for random abuse of I915_WRITE_NOTRACE
v3: Take the opportunity to rename the GT functions as uncore. Uncore is
the term used by the hardware design (and bspec) for all functions
outside of the GPU (and CPU) cores in what is also known as the System
Agent.
v4: Rebase onto SNB rc6 fixes
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: Wrestle patch into applying and inline
intel_uncore_early_sanitize (plus move the old comment to the new
function). Also keep the _santize postfix for intel_uncore_sanitize.]
[danvet: Squash in fixup spotted by Chris on irc: We need to call
intel_pm_init before intel_uncore_sanitize since the later will call
cancel_work on the delayed rps setup work the former initializes.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For now there are no callers, but these functions are going to be
needed for the code that allows Package C8+. Other future features may
also require this code.

Also merge the commit which introduced assert_can_disable_lcpll and
had the following commit message:

Most of the hardware needs to be disabled before LCPLL is disabled, so
let's add a function to assert some of items listed in the "Display
Sequences for LCPLL disabling" documentation.

The idea is that hsw_disable_lcpll should not disable the hardware,
the callers need to take care of calling hsw_disable_lcpll only once
everything is already disabled.

v2: - Rebase.
    - Fix D_COMP wait timeout.
v3: - Use wait_for_atomic_use (Ben)
    - Remove/add a useless/needed POSTING_READ (Ben)
    - Early return in case LCPLL is already restored (Ben)
    - Add ndelay(100) (Ben)
v4: - Merge the commit that added assert_can_disable_lcpll (Ben)
    - Add interrupt assertions (Ben)
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fix compile fail since there's no HAS_LP_PCH yet.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We currently don't support HDMI clock bending nor use SSC for DP or
HDMI on Haswell, so the only case where we need CLKOUT_DP is for VGA.

v2: - Replace the IS_ULT check for LPT-LP
    - Simplify GEN0/DBUFF0 check due to change on the previous patch
    - Also check for SBI_SSCCTL_DISABLE (Ben).
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now it implements 3 different sequences from BSpec and also has
support for ULT.

v2: - Change IS_ULT checks for LPT-LP checks
    - Add check for LPT-LP + with_fdi (Ben)
    - Merge DBUFF0/GEN0 bit definitions since they're the same
      register (Ben)
    - DBUFF0 (1<<0) is Disable, not Enable
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941
BugLink: https://bugs.launchpad.net/bugs/1163720
BugLink: https://bugs.launchpad.net/bugs/1162026

Some machines suffer from non-functional backlight controls if
BLM_PCH_PWM_ENABLE is set, so provide a quirk to avoid doing so.
Apply this quirk to Dell XPS 13 models.
Tested-by: NEric Griffith <EGriffith92@gmail.com>
Tested-by: NKent Baxley <kent.baxley@canonical.com>
Cc: <stable@vger.kernel.org> # v3.8+
Signed-off-by: NKamal Mostafa <kamal@canonical.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The next step is to modify lpt_enable_clkout_dp to enable support for
"Sequence to enable CLKOUT_DP" and "Sequence to enable CLKOUT_DP
without spread".
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Because lpt_init_pch_refclk implements the "Sequence to enable
CLKOUT_DP for FDI usage and configure PCH FDI I/O", which is very
similar to "Sequence to enable CLKOUT_DP" and "Sequence to enable
CLKOUT_DP without spread". With the extracted functions we can more
easily implement the two missing sequences.

v2: Rebase (WaMPhyProgramming:hsw comment).
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The machines that fall in the "is_sdv" case are some very early
pre-production steppings. This patch may break VGA output after
suspend/resume on these machines.

Even the documentation for the is_sdv cases was removed from BSpec.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

PSR must be enabled after transcoder and port are running.
And it is only available for HSW.

v2: move enable/disable to intel_ddi
v3: The spec suggests PSR should be disabled even before backlight (by pzanoni)
v4: also disabling and enabling whenever panel is disabled/enabled.
v5: make it last patch to avoid breaking whenever bisecting. So calling for
    update and force exit came to this patch along with enable/disable calls.
v6: Remove unused and unecessary psr_enable/disable calls, as notice by Paulo.

CC: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Drop the psr exit code in the busy ioctl since I didn't merge
that part of the infrastructure yet - it needs more thought.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In commit e3de42b6
Author: Imre Deak <imre.deak@intel.com>
Date:   Fri May 3 19:44:07 2013 +0200

    drm/i915: force full modeset if the connector is in DPMS OFF mode

a new function was added that walked over the set of connectors to see
if any of the currently associated CRTC was switched off. This function
walked an array of connectors, rather than the array of pointers to
connectors contained in the drm_mode_set - i.e. it was dereferencing far
past the end of the first connector. This only becomes an issue if we
attempt to use a clone mode (i.e. more than one connector per CRTC) such
that set->num_connectors > 1.
Reported-by: NTimo Aaltonen <tjaalton@ubuntu.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65927Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Egbert Eich <eich@suse.de>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There seems to be no limit to the amount of gunk the firmware can
leave behind. Some platforms leave pch dplls on which are not in
active use at all. The example in the bug report is a Apple Macbook
Pro.

Note that this escape scrunity of the hw state checker until we've
tried to use this enabled, but unused pll since we did only check for
the inverse case of a in-used, but disabled pll.

v2: Add a WARN in the pll state checker which would have caught this
case.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66952Reported-and-tested-by: Nshui yangwei <yangweix.shui@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Toghether with the hw state readout this should catch cases where we
don't properly updated the pll state (either in sw or hw). At least
for the shared dpll code the equivalent tricke helped a lot in
catching bugs.

Also rename the function prefix, it's not a generic piece of
infrastructure.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Bspec for the "DPLL HDMI multiplier" field says:

"Restriction : The DPLL must be enabled and stable before setting these bits.
These bits must be programmed after DPLL_SEL is programmed."

There is apparently no restriction on programming the DPLL_SEL
register wrt the DPLL. So let's just move that up before we enable the
pch dpll.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

No need to call the ->pre_pll_enable hook twice if we don't enable the
dpll too early. This should make Jani a bit less grumpy.

v2: Rebase on top of the newly-colored BUG_ONs.

v3: Reinstate the lost write of the DPLL_MD register, spotted by Imre.

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

Move error state generation and stringification to it's
own compilation unit. Sysfs also uses this so it can't be
under CONFIG_DEBUG_FS

This fixes a regression introduced in

commit ef86ddce
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Thu Jun 6 17:38:54 2013 +0300

    drm/i915: add error_state sysfs entry

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66814Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Came accross two open coding of for_each_pipe(), might as well use the
macro.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It's in the PFIT_CONTROL register, but very much associated with the
lvds encoder. So move the readout for it (in the case of an otherwise
disabled pfit) from the pipe to the lvds encoder's get_config
function.

Otherwise we get a pipe state mismatch if we use pipe B for a non-lvds
output and we've left the dither bit enabled behind us. This can
happen if the BIOS has set the bit (some seem to unconditionally do
that, even in the complete absence of an lvds port), but not enabled
pipe B at boot-up. Then we won't clear the pfit control register since
we can only touch that if the pfit is associated with our pipe in the
crtc configuration - we could trample over the pfit state of the other
pipe otherwise since it's shared. Once pipe B is enabled we notice
that the 6to8 dither bit is set and complain about the mismatch.

Note that testing indicates that we don't actually need to set this
bit when the pfit is disabled, dithering on 18bpp panels seems to work
regardless. But ripping that code out is not something for a bugfix
meant for -rc kernels.

v2: While at it clarify the logic in i9xx_get_pfit_config, spurred by
comments from Chris on irc.

v3: Use Chris suggestion to make the control flow in
i9xx_get_pfit_config easier to understand.

v4: Kill the extra line, spotted by Chris.
Reported-by: NKnut Petersen <Knut_Petersen@t-online.de>
Cc: Knut Petersen <Knut_Petersen@t-online.de>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
References: http://lists.freedesktop.org/archives/intel-gfx/2013-July/030092.htmlTested-by: NKnut Petersen <Knut_Petersen@t-online.de>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I just got confirmation that we're using some old values for the PLL
LPF coefficients for DP RBR/HDMI/DAC on VLV. The
VLV2A0_DP_eDP_HDMI_DPIO_driver_vbios_notes_9 document lists both values
by mistake, and apparently we had picked the wrong one. Change the
coefficients to the recommended values.

Changing the value doesn't appear to destabilize the VGA output picture
even with my sensitive HP ZR24w display. Also HDMI output to my TV still
works fine.
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>

Section 1.5.4, "DPLL A Control Register" from Bspec about bit 23
"FPA0/A1 P2 Clock Divide":

0 = Divide by 2
1 = Divide by 4. This bit must be set in DVO non-gang mode

So copy the current limits (which should be good for i8xx) and create
a new set for dvo encoders.
Reviewed-by: NChris Wilson <chris@chris-wilson.oc.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I've missed that intel_dvo_mode_set changes the dpll configuration.
Hence when I've reworked the sequence to only enable the dpll in the
crtc_enable callback in

commit 66e3d5c0
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Jun 16 21:24:16 2013 +0200

    drm/i915: move i9xx dpll enabling into crtc enable function

that special DVO bit was lost. Some BSpec reading confirms that it's
only needed for DVO encoders. Section 1.5.4, "DPLL A Control Register"
for bit 30:

"2X Clock Enable. When driving In non-gang DVO modes such as a
connected flat panel or TV, a 2X" version of the clock is needed. When
not using the 2X output it should be disabled. This bit cannot be set
when driving the integrated LVDS port on devices such as Montara-GM."

Fix this regression up.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66516
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Partially-tested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Soon we want to gut a lot of our existing assumptions how many address
spaces an object can live in, and in doing so, embed the drm_mm_node in
the object (and later the VMA).

It's possible in the future we'll want to add more getter/setter
methods, but for now this is enough to enable the VMAs.

v2: Reworked commit message (Ben)
Added comments to the main functions (Ben)
sed -i "s/i915_gem_obj_set_color/i915_gem_obj_ggtt_set_color/" drivers/gpu/drm/i915/*.[ch]
sed -i "s/i915_gem_obj_bound/i915_gem_obj_ggtt_bound/" drivers/gpu/drm/i915/*.[ch]
sed -i "s/i915_gem_obj_size/i915_gem_obj_ggtt_size/" drivers/gpu/drm/i915/*.[ch]
sed -i "s/i915_gem_obj_offset/i915_gem_obj_ggtt_offset/" drivers/gpu/drm/i915/*.[ch]
(Daniel)

v3: Rebased on new reserve_node patch
Changed DRM_DEBUG_KMS to actually work (will need fixing later)
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We only do this on IBX where there's a fixed pch dpll to pipe
assignment. Being explicit about it can't really hurt and makes
sparse happy.
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This makes sparse happy and also makes it a bit more obvious where we
pull off this trick - after all we're only allowed to do it eithe as a
default or on platforms where there is no disdinction between the pipe
and the cpu transcoder.
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This should help on HSW, where we don't currently have a get_clock call.
Reported-by: NPaulo Zanoni <przanoni@gmail.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Print out the flag that failed and fix up a mismatched paren.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If the crtc is active, we can simply flip a new fb onto it, provided the
other mode setting reqs are met.  Otherwise, we'll need to do a full
mode set to re-enable the crtc.

v2: check for crtc active and set mode_changed accordingly
v3: add module parameter, i915.fastboot, to control no fb -> fb flip behavior
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Need better pfit tracking to do this right.

v2: use fastboot param around this hack
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We already fetch and track other state into the main CRTC and encoder
structs, and for fastboot we need to do the same with the mode and clock
data we read out.

v2: fix debug print
v3: use fastboot param around state copy
v4: set clock and flags for crtc here instead of in setup_hw_state
v5: rename function to intel_crtc_mode_from_pipe_config for consistency (Chris)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need this for comparing modes between configuration changes.

The tricky part is to allow us to reuse the new get_clock stuff to
recover the lvds clock on gen2/3 when neither the vbt has an lvds mode
nor the panel a (useful) EDID.

v2: try harder to calulate non-simple pixel clocks (Daniel)
    call get_clock after getting the encoder config, needed for pixel multiply
    (Jesse)
v3: drop get_clock now that the pixel_multiply has been moved into
    get_pipe_config
v4: re-add get_clock; we need to get the pixel multiplier in the
    encoder, so need to calculate the clock value after the encoder's
    get_config is called
v5: drop hsw clock_get, still needs to be written
v6: add fuzzy clock check (Daniel)
v7: wrap fuzzy clock check under !IS_HASWELL
    use port_clock field rather than a new CPU eDP clock field in crtc_config
v8: remove stale pixel_multiplier sets (Daniel)
    multiply by pixel_multiplier in 9xx clock get too (Daniel)
v9: make sure we set pixel_multiplier before calling clock_get from mode_get
    for LVDS (Daniel)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add some explanation to the commit message about why we have
to jump through a few hoops. Also remove the rebase-fail hunk from
intel_sdvo.c]
[danvet: Squash in the fixup from Jesse to also call ->get_clock in
the modeset state checker.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that we painstakingly track the shared pch dplls we can finally
implement pixel mutliplier readout support for pch ports, too.

v2: Undo the temporary hack to disable the sdvo pixel multiplier
cross-checking.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: Resolve conflict with Damien's FBC_CHIP_DEFAULT no fbc
reason.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The DPLL lock bit, and the DPIO phy status bits are read-only and
controlled by the hardware, so they will never be set by the driver.
Mask them out when reading the hw state, so that the state
comparison won't fail.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuosugeek.org>
[danvet: Jesse asked for a code comment and I wholeheartly agree, so
added one.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

i9xx doesn't use pre_enable at all, so we can fold this in now.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that we have the proper pipe config to track this, we don't need
to write any registers any more.

Note that for platforms without DPLL_MD (pre-gen4) which store the
pixel mutliplier in the DPLL register I've decided to keep the
seemingly "redundant" write: The comment right below saying "do this
trice for luck" doesn't instill confidence ...

v2: Drop a few now unnecessary local variables and switch the enable
function to take a struct intel_crtc * to simply arguments.

v3: Rebase on top of the newly-colored BUG_ON.

v4: Amend commit message to alliviate Imre's comment about the
redudant DPLL write for the pixel mutliplier.

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

In addition to existing stuff we also need to track DPLL_MD on gen4
and vlv. This is prep work so that we can move the dpll enable
sequence out from the ->mode_set callback into the crtc enabling
functions.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The ->pre_enable hook is only used for the cpu edp port on ilk-ivb, so
we can safely move it up across the fdi pll enabling.

Unfortunately we can't (yet) merge in the pre_pll enable hook despite
that only lvds uses it on ilk-ivb: Since the same lvds hook is also
need on i9xx platforms we need to fix up the pll enabling sequence
there, too.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>