drm/i915: invert the verbosity of intel_enable_fbc

We currently print a DRM_DEBUG_KMS message on the happy path and don't
print anything on the "failed to allocate" path. On some desktop
environments (e.g., Unity) I see the "scheduling delayed FBC enable"
thousands and thousands of times on my dmesg.

So kill the useless message for the happy case, saving a lot of dmesg
space, and properly signal the "kzalloc fail" case.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Make intel_enable_fbc() static

This function has no user outside of intel_pm.c.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Fix reason for per-chip disabling of FBC

When running on my snb machine, recent kernels display successively:

[drm:intel_update_fbc], fbc set to per-chip default
[drm:intel_update_fbc], fbc disabled per module param

But no module param is set. This happens because the check for the
module parameter uses a variable that has been overridden inside the
"per-chip default" code.

Fix up the logic and add another reason for the FBC to the be disabled.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Use seq_puts/seq_putc when possible

Caught with checkpatch.pl.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Fix a few style issues found by checkpatch.pl

Missing spaces and misplaced '*'.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Fix a couple of "should it be static?" sparse warnings

A genuine 'static' omission and 2 other warnings triggered by not
including the header where those functions where defined.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Bail out once we've found the context object

Once we've found the the context object programmed in CCID, there's no
need to look the other objects in the list.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: consolidate pch pll enable sequence

It's been splattered over 3 different places all doing random things.
Now we have (mostly) the same sequence as i8xx/i9xx, but all called
from the crtc_enable hook (through the pll->enable function):
- write new dividers
- enable vco and wait for stable clocks
- write again for the pixel mutliplier

I've left the seemingly random 200 usec delay in there, just in case.

Also move the encoder->pre_pll_enable hook into the crtc_enable
function, at the same spot we currently have a hack to enable the lvds
port. Since that hack is now redundant, kill it.

While doing this patch I've learned the hard way that we can only fire
up the LVDS port if both the pch dpll _and_ the fdi rc pll are not yet
enabled. Otherwise things go haywire, at least on cpt.

v2: It is paramount to write the FPx divisors before we enable the
the vco by writing to the DPLL registers, for otherwise the divisors
won't get updated. This is in line with the i8xx/i9xx dpll.

v3: To keep the nice abstraction add a ->mode_set callback to set the
divisors. Also streamline the enabling/disabling code a bit by
removing some cargo-cult duplication and clearing registers where
possible in the ->disable hook.

v4: Remove now unused local variable.

Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: use sw tracked state to select shared dplls

Just yet another prep step to be able to do all this up-front, before
we've set up any of the shared dplls in the new state. This will
eventually be useful for atomic modesetting.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: duplicate intel_enable_pll into i9xx and vlv versions

Mostly since I _really_ don't want to touch the vlv hell.

No code change, just duplication. Also kill a now seriously outdated
code comment - the remark about the dvo encoder is now handled with
the pipe A quirk.

v2: Update the BUG_ONs as suggested by Jani (both in vlv_ and i9xx_
functions, since the split happens here).

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: asserts for lvds pre_enable

Lots of bangin my head against the wall^UExperiments have shown that
we really need to enable the lvds port before we enable plls. Strangely
that seems to include the fdi rx pll on the pch.

Note that the pch pll assert can fire since the lvds port has it's own
special clock source settings in the DPLL register, which means it
will never have a shared dpll (since there's only one LVDS port).

Anyway, encode this new evidence with a few nice WARNs.

v2: Incorporate review comments from Imre.
- Explain why lvds can't have a shared dpll.
- Update the WARN output.

Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: move encoder pre enable hooks togther on ilk+

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: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: hw state readout for i9xx dplls

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: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: move i9xx dpll enabling into crtc enable function

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: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: s/pre_pll/pre/ on the lvds port enable function

i9xx doesn't use pre_enable at all, so we can fold this in now.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Mask out hardware status bits from VLV DPLL register

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuosugeek.org>
[danvet: Jesse asked for a code comment and I wholeheartly agree, so
added one.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Remove extra error state NULL

Not only was there an extra, but since we now kzalloc the error state,
we don't need either.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Extract error buffer capture

This helps when we have per VM buffer capturing.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: make PDE|PTE platform specific

Nothing outside of i915_gem_gtt.c and more specifically, the relevant
gen specific init function should need to know about number of PDEs, or
PTEs per PD. Exposing this will only lead to circumventing using the
upcoming VM abstraction.

To accomplish this, move the defines into the .c file, rename the PDE
define to be GEN6, and make the PTE count less of a magic number.

The remaining code in the global gtt setup is a bit messy, but an
upcoming patch will clean that one up.

v2: Don't hardcode number of PDEs (Daniel + Jesse)
Reworded commit message to reflect change.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Really share scratch page

A previous patch had set up the ppgtt and ggtt to use the same scratch
page, but still kept around both pointers. Kill it, it's not needed and
gets in our way for upcoming cleanups.

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