drm: Add drm_rect_equals()

drm_rect_equals() tells whether two drm_rects are equal.

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

drm: Add drm_rect_debug_print()

Add a debug function to print the rectangle in a human readable format.

v2: Renamed drm_region to drm_rect, the function from drm_region_debug
    to drm_rect_debug_print(), and use %+d instead of +%d in the format.
v3: Use %d format for width/height in the non fixed point case as well

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

drm: Add drm_rect_calc_{hscale, vscale}() utility functions

These functions calculate the scaling factor based on the source and
destination rectangles.

There are two version of the functions, the strict ones that will
return an error if the min/max scaling factor is exceeded, and the
relaxed versions that will adjust the src/dst rectangles in order to
keep the scaling factor withing the limits.

v2: Return error instead of adjusting regions, refactor common parts
    into one function, and split into strict and relaxed versions.
v3: Renamed drm_region to drm_rect, add "_rect_" to the function
    names.
v4: Fix "calculcate" typos

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

drm: Add struct drm_rect and assorted utility functions

struct drm_rect represents a simple rectangle. The utility
functions are there to help driver writers.

v2: Moved the region stuff into its own file, made the smaller funcs
    static inline, used 64bit maths in the scaled clipping function to
    avoid overflows (instead it will saturate to INT_MIN or INT_MAX).
v3: Renamed drm_region to drm_rect, drm_region_clip to
    drm_rect_intersect, and drm_region_subsample to drm_rect_downscale.
v4: Renamed some function parameters, improve kernel-doc comments a bit,
    and actually generate documentation for drm_rect.[ch].
v5: s/RETUTRNS/RETURNS/

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move border color writes to pfit_enable

Writing hw registers from compute_config?
Just say no!

In this case not too horrible since we write a constant 0, and only
debugging would put something else in there. But while checking that
code I've noticed that this register disappeared on pch platforms, so
fix that up, too.

And adjust the comment a bit, it's outdated.

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

drm/i915: rip out indirection for pfit pipe_config assignment

This was still required a bit (on the cargo-cult side though) when the
state was stored in dev_priv, and when the enable/disable sequence was
botched a bit (to avoid too many updates).

But with pipeconfig we always get a clean slate, so this is pointless.
Rip it out.

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

drm/i915: move lvds_border_bits to pipe_config

pipe_config is the new dev_priv!

More seriously, this is actually better since a pipe_config can be
thrown away if the modeset compute config stage fails. Whereas any
state stored in dev_prive needs to be painstakingly restored, since
otherwise a dpms off/on will wreak massive havoc. Yes, that even
applies to state only used in ->mode_set callbacks, since we need to
call those even for dpms on when the Haswell power well cleared
everything out.

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

drm/i915: cleanup opregion asle pipestat enable

Both intel_opregion_enable_asle() and intel_enable_asle() have shrunk
considerably. Merge them together into a static function in i915_irq.c,
and rename to better reflect the purpose and the related platforms.

No functional changes.

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

drm/i915: cleanup redundant checks from intel_enable_asle

Realize that intel_enable_asle() is never called on PCH-split platforms
or on VLV. Rip out the GSE irq enable for PCH-split platforms, which
also happens to be incorrect for IVB+.

This should not cause any functional changes.

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

drm/i915: untie opregion init and asle irq/pipestat enable

Stop calling intel_opregion_enable_asle() and consequently
intel_enable_asle() on opregion init. It should not be necessary for
these reasons:

1) On PCH split platforms, it only enables GSE interrupt, which is
   enabled in irq postinstall anyway. Moreover, the irq enable uses the
   wrong bit on IVB+.

2) On gen 2, it would enable a reserved pipestat bit. If there were gen
   2 systems with opregion asle support, that is. And the gen 2 irq
   handler won't handle it anyway.

3) On gen 3-4, the irq postinstall will call
   intel_opregion_enable_asle() to enable the pipestat.

In short, move the asle irq/pipestat enable responsibility to irq
postinstall, which already happens to be in place.

This should not cause any functional changes, but only do the one line
change here for easier bisectability, just in case, and leave all the
cleanups this allows to followup patches.

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

drm/i915: manage opregion asle driver readiness properly

Only set ASLE driver readiness (ARDY) and technology enabled indicator
(TCHE) once per opregion init. There should be no need to do that at irq
postinstall time. Also clear driver readiness at fini.

While at it, add defines for driver readiness.

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

drm/i915: cleanup opregion technology enabled indicator defines

Move near other defines, add TCHE in the name. No functional changes.

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

drm/i915: hw state readout support for pipe timings

This does duplicate the logic in intel_crtc_mode_get a bit, but the
issue is that we also should handle interlace modes and other insanity
correctly.

Hence I've opted for a sligthly more elaborate route where we first
read out the crtc timings for the adjusted mode, and then optionally
(not sure if we really need it) compute the modeline from that.

v2: Also read out the pipe source dimensions into the requested mode.

v3: Rebase on top of the moved cpu_transcoder.

v4: Simplify CHECK_FLAGS logic as suggested by Chris Wilson. Also
properly #undef that macro again.

Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> (v3)
[danvet: Use the existing mask for interlaced bits, spotted by Mika.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: hw state readout support for fdi m/n

We want to use the fdi m/n values to easily compute the adjusted mode
dotclock on pch ports. Hence make sure the values stored in the pipe
config are always reliable.

v2: Fixup FDI TU readout.

v3: Rebase on top of moved cpu_transcoder.

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

drm/i915: introduce macros to check pipe config properties

This code will get _really_ repetive, and we'll end up with tons more
of this kind. So extract the common patterns.

This should also help when we add a lazy pipe_config compare mode for
fastboot.

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

drm/i915: stop for_each_intel_crtc_masked macro from leaking

Spotted while changing related code.

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

drm/i915: implement fdi auto-dithering

So on a bunch of setups we only have 2 fdi lanes available, e.g. hsw
VGA or 3 pipes on ivb. And seemingly a lot of modes don't quite fit
into this, among them the default 1080p mode.

The solution is to dither down the pipe a bit so that everything fits,
which this patch implements.

But ports compute their state under the assumption that the bpp they
pick will be the one selected, e.g. the display port bw computations
won't work otherwise. Now we could adjust our code to again up-dither
to the computed DP link parameters, but that's pointless.

So instead when the pipe needs to adjust parameters we need to retry
the pipe_config computation at the encoder stage. Furthermore we need
to inform encoders that they should not increase bandwidth
requirements if possible. This is required for the hdmi code, which
prefers the pipe to up-dither to either of the two possible hdmi bpc
values.

LVDS has a similar requirement, although that's probably only
theoretical in nature: It's unlikely that we'll ever see an 8bpc
high-res lvds panel (which is required to hit the 2 fdi lane limit).

eDP is the only thing which could increase the pipe_bpp setting again,
even when in the retry-loop. This could hit the WARN. Two reasons for
not bothering:
- On many eDP panels we'll get a black screen if the bpp settings
  don't match vbt. So failing the modeset is the right thing to do.
  But since that also means it's the only way to light up the panel,
  it should work. So we shouldn't be able to hit this WARN.
- There are still opens around the eDP panel handling, and maybe we
  need additional tricks. Before that happens it's imo no use trying
  to be too clever.
Worst case we just need to kill that WARN or maybe fail the compute
config stage if the eDP connector can't get the bpp setting it wants.
And since this can only happen with an fdi link in between and so for
pch eDP panels it's rather unlikely to blow up, if ever.

v2: Rebased on top of a bikeshed from Paulo.

v3: Improve commit message around eDP handling with the stuff
things with Imre.

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

drm/i915: fixup 12bpc hdmi dotclock handling

We need to multiply the hdmi port dotclock by 1.5x since it's not
really a dotclock, but the 10/8 encoding bitclock divided by 10.

Also add correct limit checks for the dotclock and reject modes which
don't fit. HDMI 1.4 would allow more, but our hw doesn't support that
unfortunately :(

Somehow I suspect 12bpc hdmi output never really worked - we really
need an i-g-t testcase to check all the different pixel modes and
outputs.

v2: Fixup the adjusted port clock handling - we need to make sure that
the fdi link code still gets the real pixelclock.

v3: g4x/vlv don't support 12bpc hdmi output so drop the bogus comment.

Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Switch dotclock limit check to <= as suggested by Ville.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't count cpu ports for fdi B/C lane sharing

This allows us to use all 4 fdi lanes on fdi B when the cpu eDP is
running on pipe C. Yay!

v2: Encapsulate test into a little helper function, as suggested by
Chris Wilson.

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

drm/i915: move fdi lane configuration checks ahead

This nicely allows us to drop some hacks which have only been used
to work around modeset failures due to lack of fdi lanes.

v2: Implement proper checking for Haswell platforms - the fdi link to
the LPT PCH has only 2 lanes. Note that we already filter out
impossible modes in intel_crt_mode_valid. Unfortunately LPT does not
support 6bpc on the fdi rx, so we can't pull clever tricks to squeeze
in a few more modes.

v2: Rebased on top of Ben Widawsky's num_pipes reorg.

v3: Rebase on top of Ville's pipe debug output ocd rampage.

v4: Fixup rebase fail spotted by Ville.

v5: Fixup rebase fail spotted by Imre Deak. I suck.

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

drm/i915: Split up ironlake_check_fdi_lanes

Again in preparation to move the configuration checks into the
pipe_config computation stage of the modeset sequence.

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

drm/i915: compute fdi lane config earlier

Now that it's split up, we can easily move it around and precompute
the fdi lane configuration.

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

drm/i915: split up fdi_set_m_n into computation and hw setup

And also move the computed m_n values into the pipe_config. This is a
prep step to move the fdi state computation completely into the
prepare phase of the modeset sequence. Which will allow us to handle
fdi link bw constraints in a better way.

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

drm/i915: hw state readout support for pipe_config->fdi_lanes

v2: Introduce some nice #defines for the FDI lane width fields and put
them to good use. Suggested by Ville.

v3: Fixup the mask vs. shift copy&pasta fail Imre Deak spotted, and
use the shift #define also in the mask.

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

drm/i915: move intel_crtc->fdi_lanes to pipe_config

We need this for two reasons:
- Correct handling of shared fdi lanes on ivb with fastboot.
- Handling fdi link bw limits when we only have two fdi lanes by
  dithering down a bit.

Just search&replace in this patch, no functional change at all.

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

drm/i915: allow high-bpc modes on DP

Totally untested due to lack of screens supporting more than 8bpc. But
now we should have closed all holes in our bpp handling, so this
should be safe. The last missing piece was 10bpc support for g4x/vlv,
since we directly use the pipe bpp to feed the display link (and
anyway, only the cpt has any means to have a pipe bpp != the display
link bpp).

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

drm/i915: implement high-bpc + pipeconf-dither support for g4x/vlv

The current code is rather ... ugly. The only thing it managed to pull
off is getting 6bpc on DP working on g4x. Then someone added another
custom hack for 6bpc eDP on vlv. Fix up this entire mess by properly
implementing the PIPECONF-based dither/bpc controls on g4x/vlv.

Note that compared to pch based platforms g4x/vlv don't support 12bpc
modes. g4x is already caught, extend the check for vlv.

The other fixup is to restrict the lvds-specific dithering to early
gen4 devices - g4x should use the pipeconf dither controls. Note that
on gen2/3 the dither control is in the panel fitter even.

v2: Don't enable dithering when the pipe is in 10 bpc mode. Quoting
from Bspec "PIPEACONF - Pipe A Configuration Register, bit 4":

"Programming note: Dithering should only be enabled for 8 bpc or 6
bpc."

v3: Actually drop the old ugly dither code.

v4: Explain in a short comment why g4x/vlv shouldn't dither for 30 bpp
pipes (Jesse).

v5: Also clear the dither type correctly as spotted by Ville.

v6: As Ville pointed out we need to indeed set the dithering both in
the pipeconf register (for DP outputs) and in the LVDS port register
(for LVDS ouputs). Otherwise LVDS panel will not get properly
dithered. The old patch got away with this since it forgot to clear
the LVDS dither bit ...

v7: Remove redundant BPC_MASK clearing, spotted by Ville.

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>

drm/i915: drop adjusted_mode from *_set_pipeconf functions

They can get at the adjusted mode through intel_crtc->config.

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

drm/i915: force bpp for eDP panels

We've had our fair share of woes already which showed that we can't
rely on the bpc limits in the EDID for eDP panels without risking
black screens. So now we limit the depth by what the BIOS recommends
in the VBT:

commit 2f4f649a69a9eb51f6e98130e19dd90a260a4145
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Mon Nov 12 14:33:44 2012 +0200

    drm/i915: do not ignore eDP bpc settings from vbt

But that's not enough, since at least the panel on my ASUS Zenbook
Prime here is also unhappy if the bpc is too low. Hence just take the
firmware value and dither to get what flimsy panels want.

Like before we ensure that we don't change the bpp if the firmware
doesn't provide a value, see

commit 9a30a61f3516871c5c638fd7c025fbaa11ddf7fe
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Mon Nov 12 14:33:45 2012 +0200

    drm/i915: do not default to 18 bpp for eDP if missing from VBT

v2: Apparently there are some horribly broken eDP panels around which
only work if the DP link is set up as if we want to driver a 24bpp
mode, but still only work if the data is feed at 18bpp. See

commit 57c219633275c7e7413f8bc7be250dc092887458
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Apr 4 17:19:37 2013 +0200

    drm/i915: revert eDP bpp clamping code changes

for the gory details.

Adjust the patch accordingly and update all the relevant comments.

v3: Give up on the cargo-culting v2 attempt and just enfore the edp
bpp value if it's there. Broken panels be damned!

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

drm/i915: put the right cpu_transcoder into pipe_config for hw state readout

This hack is getting a bit messy, but this plugs the leak for now
until we have the cpu_transcoder properly pipe_config'ed.

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

drm/i915: Only print the info message about incresing stolen size for FBC once

Instead of repeatedly bombarding the user with a request to reboot and
increase the stolen size with every fb refresh, just inform them the
first time only.

v2: Rearrange code so the hint to increase the amount of memory stolen
by the BIOS is only emitted if we fail to find sufficient stolen memory
for FBC.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Fixup formatting code mismatch that gcc spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remove VLV MSI IRQ hack

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

drm/i915: warn about invalid pfit modes

We prevent invalid ones from getting here in the first place, but it
doesn't hurt to have an extra sanity check.

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

drm/i915: move PCH pfit controls into pipe_config

And put the pfit stuff into substructs while we're at it.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: factor out GMCH panel fitting code and use for eDP v3

This gets the panel fitter working on eDP on VLV, and should also apply
to eDP panels on G4x chipsets (if we ever detect and mark an all-in-one
panel as eDP anyway).

A few cleanups are still possible on top of this, for example the LVDS
border control could be placed in the LVDS encoder structure and updated
based on the result of the panel fitter calculation.

Multi-pipe fitting isn't handled correctly either if we ever get a config
that wants to try the panel fitter on more than one output at a time.

v2: use pipe_config for storing pfit values (Daniel)
    add i9xx_pfit_enable function for use by 9xx and VLV (Daniel)
v3: fixup conflicts and lvds_dither check

Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: fix up botched conflict resolution from Jesse:
- border = LVDS_BORDER_ENABLE was lost for CENTER scaling
- comment about gen2/3 panel fitter scaling was lost
- dev_priv->lvds_dither reintroduced.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: simplify config->pixel_multiplier handling

We only ever check whether it's strictly bigger than one, so all the
is_sdvo/is_hdmi checks are redundant. Flatten the code a bit.

Also, s/temp/dpll_md/

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

drm/i915: remove redundant has_pch_encoder check

If we compute the pch pll state, we _have_ a pch encoder.

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

drm/i915: don't force matching p1 for g4x/ilk+ reduced pll settings

g4x dplls and ilk+ pch plls have a separate field for the reduced p1
setting, so this restriction does not apply. Only older platforms have
the restriction that the p1 divisors must match.

This unnecessary restriction has been introduced in

commit cec2f356d59d9e070413e5966a3c5a1af136d948
Author: Sean Paul <seanpaul@chromium.org>
Date:   Tue Jan 10 15:09:36 2012 -0800

    drm/i915: Only look for matching clocks for LVDS downcloc

Note that with lvds the p2 divisors _always_ match for LVDS, and we
don't support auto-downclocking anywhere else. On eDP downclocking
works with separate data m/n settings, using the same link clock.

Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use pipe_config for lvds dithering

Up to now we've relied on the bios to get this right for us. Let's try
out whether our code has improved a bit, since we should dither
always when the output bpp doesn't match the plane bpp.
- gen5+ should be fine, since we only use the bios hint as an upgrade.
- gen4 changes, since here dithering is still controlled in the lvds
  register.
- gen2/3 has implicit dithering depeding upon whether you use 2 or 3
  lvds pairs (which makes sense, since it only supports 8bpc pipe
  outpu configurations).
- hsw doesn't support lvds.

v2: Remove redudant dither setting.

v3: Completly drop reliance on dev_priv->lvds_dither.

v4: Enable dithering on gen2/3 only when we have a 18bpp panel, since
up-dithering to a 24bpp panel is not supported by the hw. Spotted by
Ville.

v5: Also only enable lvds port dithering on gen4 for 18bpp modes. In
practice this only excludes dithering a 10bpc plane down for a 24bpp
lvds panel. Not something we truly care about. Again noticed by Ville.

v6: Actually git add.

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>

drm/i915: move dp clock computations to encoder->compute_config

With the exception of hsw, which has dedicated DP clocks which run at
the fixed frequency already, and vlv, which doesn't have optmized
pre-defined dp clock parameters (yet).

v2: Ville asked me to elaborate a bit more on the longer-term goals
wrt dpll settings computation:

So ultimately my idea is that in the compute config stage first the crtc
code puts the default platform pll limits into the pipe_config. Then
encoders can either overwrite that limit structure with their own special
stuff (mostly for lvds madness). Or they can pick some or all of the
parameters (e.g. just the p2 switchover on hdmi, or all the clock
parameters for dp/sdvo tv).

Once that's done then the generic crtc code can fill out any missing bits
(using the find_best_pll code) and then try to assign which pll to use (if
it's a platform with shared plls). In the end the modeset could should
simply write the computed stuff into registers and never be able to fail.

Of course there's still a lot of data to be moved into pipe_config to make
this all happen, hence some of the temporary ugliness.

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

drm/i915: shovel compute clock into crtc->config.dpll on ilk

This was somehow lost in the pipe_config->dpll introduction in

commit f47709a9502f3715cc488b788ca91cf0c142b1b1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Mar 28 10:42:02 2013 +0100

    drm/i915: create pipe_config->dpll for clock state

While at it, extract a few small helpers for common computations.

v2: Use the newly added helpers more thanks to Ville's trick to
typedef the legacy intel_clock_t as the new-world struct dpll.

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>

drm/i915: consolidate pch pll computations a bit

We need the dpll/fp/fp2 values only when we need a pch pll. So move
them together with the code to acquire such a pll.

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

drm/i915: Ivybridge is the odd one when it comes to pipe scalers

Between ivb, hsw and vlv, only Ivybridge has sprites with scaling
capabilities.

Also make max_downscale coherent with that.

v2: Rebase on top of the recent ivb/vlv/hsw sprite scaling fixes.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v1)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: hsw backlight registers need transcoder instead of pipe

v2: Make TRANSCODER_EDP handling more explicit. (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: drop code duplication in favor of asle interrupt handler

With the previous work asle and gse interrupt handlers should now be
functionally the same. Drop the duplicated code.

v2: Drop intel_opregion_gse_intr() also in the !CONFIG_ACPI path. (Damien)

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

drm/i915/opregion: don't pretend we did something when we didn't

In theory, the BIOS should not even request these from us now that we
aren't claiming we support these, but when it does anyway, don't pretend it
succeeded. It should be the right thing to do, but might confuse the BIOS.

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

drm/i915: don't pretend we support ASLE ALS, PFIT, or PFMB

In theory, this should prevent the BIOS from requesting them from us, and
this should be the right thing.

In practice, this is not always the case, and might surprise the BIOS.

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

drm/i915: protect backlight registers and data with a spinlock

Backlight data and registers are fiddled through LVDS/eDP modeset
enable/disable hooks, backlight sysfs files, asle interrupts, and register
save/restore. Protect the backlight related registers and driver private
fields using a spinlock.

The locking in register save/restore covers a little more than is strictly
necessary, including non-modeset case, for simplicity.

v2: Cover register access, save/restore, i915_read_blc_pwm_ctl() and code
    paths leading there.

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

drm/i915: keep max backlight internal to intel_panel.c

In preparation of adding locking to backlight, make max backlight value
(the modulation frequency the PWM duty cycle value must not exceed)
internal to intel_panel.c.

Have intel_panel_set_backlight() accept a caller defined range for level,
and scale input to max backlight value internally.

Clean up intel_panel_get_max_backlight() and usage internally.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fixup non-24bpp support for VGA screens on Haswell

The LPT PCH only supports 8bpc, so we need to force the pipe bpp
to the right value.

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

drm/i915: Disable high-bpc on pre-1.4 EDID screens

Prevents black screens when using 30bpp framebuffers on my
HDMI screens here. The DP input on the same screen though reports a
1.4 EDID with the correct 8bpc limit set.

v2: Actually check for the right thing!

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

drm/i915: disable interrupts earlier in the driver unload code

Our rps code relies on the interrupts being off to prevent re-arming
of the work items at inopportune moments.

Also drop the redundant cancel_work for the main rps work,
disable_gt_powersave already takes care of that.

Finally add a WARN_ON to ensure we obey that piece of ordering
constraint. Long term I want to lock down the setup/teardown code in a
similar way to how we painstakingly check modeset sequence constraints
already.

v2: Disable polling after hpd handling is shut down - since Egbert's
hpd irq storm handling the hotplug work can re-arm the polling
handler. Spotted by Jani Nikula.

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

drm/i915: create spearate VLV disable_rps function

We don't want to write reserved regs here, and may want to do other bits
in the future, so split it out.

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

drm/i915: cancel RPS work before disabling RPS

Ville noticed this while doing another review; we may as well cancel
this work just to make sure we don't try anything fancy after disabling
the RPS interfaces.

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

drm/i915: make sure GPU freq drops to minimum after entering RC6 v4

On VLV, the Punit doesn't automatically drop the GPU to it's minimum
voltage level when entering RC6, so we arm a timer to do it for us from
the RPS interrupt handler.  It'll generally only fire when we go idle
(or if for some reason there's a long delay between RPS interrupts), but
won't be re-armed again until the next RPS event, so shouldn't affect
power consumption after we go idle and it triggers.

v2: use delayed work instead of timer + work queue combo (Ville)
v3: fix up delayed work cancel (must be outside lock) (Daniel)
    fix up delayed work handling func for delayed work (Jesse)
v4: cancel delayed work before RPS shutdown (Jani)
    pass delay not absolute time to mod_delayed_work (Jani)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Turn HAS_FPGA_DBG_UNCLAIMED into a device_info flag

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

drm/i915: Introduce HAS_FPGA_DBG_UNCLAIMED()

Let's introduce one more of those orthogonal feature macros. This should
hopefully make the code more readable and make things easier for new platform
enabling.

This time, HAS_FPGA_DBG_UNCLAIMED() is true for platforms that have bit
31 of FPGA_DBG able to signal unclaimed writes.

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

drm/i915: Turn HAS_DDI() into a device_info flag

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

drm/i915: Use DEV_INFO_FOR_EACH_FLAG() to declare flags as well

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

drm/i915: Replace the line of %s by a DEV_INFO_FOR_EACH_FLAG() invocation

This way, when adding a device flag we don't have to manually maintain
that list.

v2: undefine the helper macros (Jani Nikula, Daniel Vetter)

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

drm/i915: Turn DEV_INFO_FLAGS into a foreach style macro

DEV_INFO_FOR_FLAG() now takes 2 parameters:
  • A function to apply to the flag
  • A separator

This will allow us to use the macro twice in the DRM_DEBUG_DRIVER() call
of i915_dump_device_info().

v2: Fix a typo in the subject (Jani Nikula)
v3: Undef the helper macros (Jani Nikula, Daniel vetter)

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

drm/i915: Only reprobe display on encoder which has received an HPD event (v2)

Instead of calling into the DRM helper layer to poll all connectors for
changes in connected displays probe only those connectors which have
received a hotplug event.

v2: Resolved conflicts with changes in previous commits.
    Renamed function and and added a WARN_ON() to warn of
    intel_hpd_irq_event() from being called without
    mode_config.mutex held - suggested by Jani Nikula.

Signed-off-by: Egbert Eich <eich@suse.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add bit field to record which pins have received HPD events (v3)

This way it is possible to limit 're'-detect() of displays to connectors
which have received an HPD event.

v2: Reordered drm_i915_private: Move hpd_event_bits to hpd state tracking.
v3: Fixed merge conflicts with previous patches.

Signed-off-by: Egbert Eich <eich@suse.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix locking around punit access in cur_delayinfo for VLV

We need to hold the rps lock around punit access.

Reported-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Split out Haswell code from gen6_pte_encode.

Now that we have function pointers, it's cleaner to just create a new
per-platform PTE encoding function.

This should be identical in behavior to the previous code.

v2: Drop accidental inline keyword on hsw_pte_encode.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Daniel Leung <daniel.leung@linux.intel.com> [v1]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix page table entries for Bay Trail.

On Bay Trail, bit 1 means "writeable by the GPU."  Failing to set that
means basically anything using the GPU will cause hangs.

v2: Drop accidental inline keyword on byt_pte_encode.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Daniel Leung <daniel.leung@linux.intel.com> [v1]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add PTE encoding function to the gtt/ppgtt vtables.

Sandybridge/Ivybridge, Bay Trail, and Haswell all have slightly
different page table entry formats.  Rather than polluting one function
with generation checks, simply use a function pointer and set up the
correct PTE encoding function at startup.

v2: Move the gen6_gtt_pte_t typedef to i915_drv.h so that the function
    pointers and implementations have identical signatures.  Also remove
    inline keyword on gen6_pte_encode.  Both suggested by Jani Nikula.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Tested-by: Daniel Leung <daniel.leung@linux.intel.com> [v1]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Make struct dpll == intel_clock_t

This allows unifying a bunch of the PLL calculations and whatnot.

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

drm/i915: use vlv_dport_to_channel in vlv_signal_levels

Minor cleanup.  Would be nice to use an enum for channel in the DPIO
macros so we don't mix up pipes and channels, but that's for another
patch.

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

drm/i915: Remove mention of Haswell in DDI code

We are trying to have more platform-orthogonal pieces of code. The DDI
code shouldn't mention Haswell.

v2: Fix the email address

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

drm/i915: Move the CSC_MODE bits next to the register

Shame on me for not putting the bit definitions next to the register
definition in the first place.

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

drm/i915: use cpu_transcoder for TRANS_DDI_FUNC_CTL

... inside haswell_get_pipe_config. Because there's one TRANS_DDI_FUNC_CTL
register per CPU transcoder, not per pipe. This solves "unclaimed register"
messages when booting with eDP only and using the i915.disable_power_well=1.

Also fix a comment and remove an useless empty line.

The error messages were caused by:

  commit 88adfff1ad5019f65b9d0b4e1a4ac900fb065183
  Author: Daniel Vetter <daniel.vetter@ffwll.ch>
  Date:   Thu Mar 28 10:42:01 2013 +0100
      drm/i915: hw readout support for ->has_pch_encoders

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: check the power well inside haswell_get_pipe_config

This fixes "unclaimed register" messages when booting with eDP only
and i915.disable_power_well=1.

The error messages were caused by:

  commit 0e8ffe1bf81b0780cc6229cb38664754dffe8776
  Author: Daniel Vetter <daniel.vetter@ffwll.ch>
  Date:   Thu Mar 28 10:42:00 2013 +0100
      drm/i915: add hw state readout/checking for pipe_config

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: print Gen5+ CPU/PCH poison interrupts

This is bad news and shouldn't be happening.

V2: Rebase.

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

drm/i915: report Gen5+ CPU and PCH FIFO underruns

In this commit we enable both CPU and PCH FIFO underrun reporting and
start reporting them. We follow a few rules:
  - after we receive one of these errors, we mask the interrupt, so
    we won't get an "interrupt storm" and we also won't flood dmesg;
  - at each mode set we enable the interrupts again, so we'll see each
    message at most once per mode set;
  - in the specific places where we need to ignore the errors, we
    completely mask the interrupts.

The downside of this patch is that since we're completely disabling
(masking) the interrupts instead of just not printing error messages,
we will mask more than just what we want on IVB/HSW CPU interrupts
(due to GEN7_ERR_INT) and on CPT/PPT/LPT PCHs (due to SERR_INT). So
when we decide to mask PCH FIFO underruns for pipe A on CPT, we'll
also be masking PCH FIFO underruns for pipe B, because both are
reported by SERR_INT, which has to be either completely enabled or
completely disabled (in othe words, there's no way to disable/enable
specific bits of GEN7_ERR_INT and SERR_INT).

V2: Rename some functions and variables, downgrade messages to
DRM_DEBUG_DRIVER and rebase.

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

drm/i915: update VLV PLL and DPIO code v11

In Valleyview voltage swing, pre-emphasis and lane control registers can
be programmed only through the h/w side band fabric.  Update
vlv_update_pll, i9xx_crtc_enable, and intel_enable_pll with the
appropriate programming.

We need to make sure that the tx lane reset occurs in both the full mode
set and DPMS paths, so factor things out to allow that.

v2: use different DPIO_DIVISOR values for VGA and DisplayPort
v3: Fix update pll logic to use same DPIO_DIVISOR & DPIO_REFSFR values
        for all display interfaces
v4: collapse with various updates
v5: squash with crtc enable/pll enable bits
v6: split out DP code (jbarnes)
    put phyready check under IS_VALLEYVIEW (jbarnes)
    remove unneeded check in 9xx pll div update (Jani)
    wrap VLV pll update call in IS_VALLEYVIEW (Jani)
    move port enable back to end of crtc enable (jbarnes)
    put phyready check under IS_VALLEYVIEW (jbarnes)
v7: fix up conflicts against latest drm-intel-next-queued
v8: use DPIO reg names, fix pipes (Jani)
    from mPhy_registers_VLV2_ww20p5 doc
v9: update to latest info from driver enabling notes doc
    driver_vbios_notes_9
v10: fixup a bit of pipe/port confusion to allow eDP and HDMI to work
     simultaneously (Jesse)
v11: use pll/port callbacks for DPIO port activity (Daniel)
     use separate VLV CRTC enable function (Daniel)
     move around port ready checks (Jesse)

Signed-off-by: Pallavi G <pallavi.g@intel.com>
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com>
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Drop pfit changes and add a little comment explaining that
vlv has a different enable sequence and so needs it's own crtc_enable
callback. Also apply a fixup patch from Wu Fengguang to shut up some
compiler warnings.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: drop init_dpio, shouldn't be needed

This is a reset feature we don't actually need.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Make it compile.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/dp: program VSwing and Preemphasis control settings on VLV v2

Program few Tx buffer Swing control settings through DPIO.

v2: fix up codingstyle (Daniel)
    call from set_signal_levels (Ville, Daniel)
    use proper port numbers (Jesse)

Signed-off-by: Pallavi G <pallavi.g@intel.com>
Signed-off-by: Yogesh M <yogesh.mohan.marimuthu@intel.com>
Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2 changes)
[danvet: Reorder if-ladder to avoid two IS_VLV checks.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: magic VLV PLL registers in the dpio sideband

Stolen from a patch with the below impressive sob-section.

Signed-off-by: Pallavi G <pallavi.g@intel.com>
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com>
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Drop everything but the header #defines.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix VLV limits

Magic updates.

v2: use 64 bit types and math (Ville)

v3: Trim out all the m/n/p calculation changes since they are still
under discussion. Instead squash in a fixup for hdmi limits which
slipped into a different patch.

Signed-off-by: Pallavi G <pallavi.g@intel.com>
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Yogesh M <yogesh.mohan.marimuthu@intel.com>
Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: turbo & RC6 support for VLV v7

Uses slightly different interfaces than other platforms.

v2: track actual set freq, not requested (Rohit)
    fix debug prints in init code (Jesse)
v3: don't write sleep reg (Jesse)
    re-add RC6 wake limit write (Ben)
    fixup thresholds to match other platforms (Ben)
    clean up mem freq calculation (Ben)
    clean up debug prints (Ben)
v4: move defines from punit patch (Ville)
v5: remove writes to nonexistent regs (Jesse)
    put RP and RC regs together (Jesse)
    fix RC6 enable (Jesse)
v6: use correct fuse reads from NC (Jesse)
    split out min/max funcs for use in sysfs (Jesse)
    add debugfs & sysfs freq controls (Jesse)
v7: update with Ben's hw_max changes (Jesse)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v6)
[danvet: Follow checkpatch sugggestion to use min_t to avoid casting
fun.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: VLV GPU frequency to opcode functions

When requesting frequency changes or querying status from the Punit, we
need to use an opcode that corresponds to the frequency, taking into
account the memory frequency.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use alphabetical names for sprites

Add sprite_name() macro which should be used with the kind of sprites
that are fixed to pipes (gen4.5+).

Also use dev_priv->num_plane to calculate the sprite index insted
assuming two sprites per pipe. This should make it print the right
name.

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

drm/i915: Use alphabetical names for transcoders too

Print the alphabetical name for transcoders. The code already used the
pipe_name() macro for transcoders, so I did the same. But we do have the
(unused) transcoder_name() macro which could be used instead.

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

drm/i915: Print plane, pipe, port names as alphabetical insted of decimal

Alway use the alphabetical names in debug/error messages for planes,
pipes and ports, instead of using decimal numbers occasionally.

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

drm/i915: Use port_name() in PCH port audio power change message

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

drm/i915: Use pipe_name() and port_name() where appropriate

Get rid of the few remaining open coded copies of
pipe_name() and port_name().

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

drm/i915: move debug output back to the right place

When adding the pipe config computation step I've accidentally moved
this a bit away. Which momentarily confused me since the pipe config
step rejected some modesetting operations I expected and so left me
looking in vain for that debug output.

v2: Move the debug output into the right function to prevent this from
happening again.

v3: Make it compile (Ville). Also reorder the patch so that the two
bugfixes are first.

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

drm/i915: add i9xx pfit pipe asserts

We can only enable the pfit if the pipe is disabled. Ensure that this
is obeyed with a neat assert.

Also check whether the pfit is off before enabling it - if not we've
lost track of things somewhere since the pfit is only ever used by the
lvds output.

v2: Fix spell fail in the commit message pointed out by Ville&Jani.

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

drm/i915: add pipe asserts for the crtc enable sequence

The i9xx modeset sequence is currently pretty fishy, so tight it all
up with some good assert-sprinkling.

We already have good coverage on the disable side, but the enable side
is spotty (since until recently it was wrong).

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

drm/i915: drop redundant vblank waits

Just blows through 50ms for naught, since the pipe is off.

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

drm/i915: don't enable the plane too early in i9xx_crtc_mode_set

This is horrible lore and we should be able to get rid of it now
that the lvds/pfit handling code actually does the right thing.

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

drm/i915: fix bpc vs. bpp confusion in intel_crtc_compute_config

Oops.

This regression has been introduced in

commit 5d2d38ddcac991f71c19d03d95bde8e14abc0352
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 27 00:45:01 2013 +0100

    drm/i915: clean up pipe bpp confusion

Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move cpu_transcoder to the pipe configuration

For a bunch of reason we need to more accurately track this:
- hw pipe state readout for Haswell needs the cpu transcoder.
- We need to know the right cpu transcoder in a bunch of places in
  ->disable and other modeset callbacks.

In the future we need to add hw state readout&check support, too. But
to avoid ugly merge conflicts do the rote sed job now without any
functional changes.

v2: Preserve the cpu_transcoder value when overwriting crtc->config.
Reported by Paulo.

Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
[danvet: Removed rough whitespace that Chris spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: preserve the PBC bits of TRANS_CHICKEN2

Bits 30 and 24:0 are PBC, so don't zero them. Some of the other bits
are being zeroed, but I couldn't find a reason for this, so leave them
as they are for now to avoid regressions.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Delete the redudant #define that Imre spotted in his review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: set CPT FDI RX polarity bits based on VBT

Check the VBT to see if the machine has inverted FDI RX polarity on
CPT. Based on this bit, set the appropriate bit on the TRANS_CHICKEN2
registers.

This should fix some machines that were showing black screens on all
outputs.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60029
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add Reenable Timer to turn Hotplug Detection back on (v4)

We disable hoptplug detection when we encounter a hotplug event
storm. Still hotplug detection is required on some outputs (like
Display Port). The interrupt storm may be only temporary (on certain
Dell Laptops for instance it happens at certain charging states of
the system). Thus we enable it after a certain grace period (2 minutes).
Should the interrupt storm persist it will be detected immediately
and it will be disabled again.

v2: Reordered drm_i915_private: moved hotplug_reenable_timer to hpd state tracker.
v3: Clarified loop start value,
    Removed superfluous test for Ivybridge and Haswell,
    Restructured loop to avoid deep nesting (all suggested by Ville Syrjälä)
v4: Fixed two bugs pointed out by Jani Nikula.

Signed-off-by: Egbert Eich <eich@suse.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Disable HPD interrupt on pin when irq storm is detected (v3)

This patch disables hotplug interrupts if an 'interrupt storm'
has been detected.
Noise on the interrupt line renders the hotplug interrupt useless:
each hotplug event causes the devices to be rescanned which will
will only increase the system load.
Thus disable the hotplug interrupts and fall back to periodic
device polling.

v2: Fixed cleanup typo.
v3: Fixed format issues, clarified a variable name,
    changed pr_warn() to DRM_INFO() as suggested by
    Jani Nikula <jani.nikula@linux.intel.com>.

Signed-off-by: Egbert Eich <eich@suse.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Mask out the HPD irq bits before setting them individually.

To disable previously enabled HPD IRQs we need to reset them and
set the enabled ones individually.

Signed-off-by: Egbert Eich <eich@suse.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: (re)init HPD interrupt storm statistics

When an encoder is shared on several connectors there is only
one hotplug line, thus this line needs to be shared among these
connectors.
If HPD detect only works reliably on a subset of those connectors,
we want to poll the others. Thus we need to make sure that storm
detection doesn't mess up the settings for those connectors.
Therefore we store the settings in the intel_connector struct and
restore them from there.
If nothing is set but the encoder has a hpd_pin set we assume this
connector is hotplug capable.
On init/reset we make sure the polled state of the connectors
is (re)set to the default value, the HPD interrupts are marked
enabled.

Signed-off-by: Egbert Eich <eich@suse.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>