Description:
intel_gmbus_is_forced_bit is no extern as its body is right below.
Likewise for intel_gmbus_is_port_valid.

This fixes a compilation issue with clang. An initial version of this patch
was developed by PaX Team <pageexec at freemail.hu>.
This is respin of this patch.

20130509: v2: (re-)add inline upon request.
Signed-off-by: NJan-Simon Möller <dl9pf@gmx.de>
CC: pageexec@freemail.hu
CC: daniel.vetter@ffwll.ch
CC: airlied@linux.ie
CC: intel-gfx@lists.freedesktop.org
CC: dri-devel@lists.freedesktop.org
CC: linux-kernel@vger.kernel.org
[danvet: Bikeshed commit message.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It also makes some sense IMO to have these two functions separate
irrespective of the number of callers.

Only the single caller for now, but that will change as we add more
PPGTTs.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Resolve conflict.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Because PPGTT PDEs within the GTT are calculated in cachelines
(HW guys consistency ftw) we do a divide which will wreak havoc if this
is wrong, and I know that from experience).

If/when we move to multiple PPGTTs this will have to become a WARN, and
return an error. For now however it should always be considered fatal,
and only a developer could hit it.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: s/BUG/WARN]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Because our context refcounting doesn't grab a ref at lookup time, it is
unsafe to do so without the lock.

NOTE: We don't have an easy way to put the assertion in the lookup
function which is where this really belongs. Context switching is good
enough because it actually asserts even more correctness by protecting
the default_context.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: s/BUG/WARN/]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Only one caller. Also drop the intel_ prefix as is now customary for
platform specific and static functions.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

- PCH_ prefix for pch registers on ibx/cpt/ppt.
- Drop the DP_ from the link defines, redundant.
- Drop the GMCH from the data defines and instead give the special g4x
  registers a consistent _G4X postfix.

v2:
- Realign #defines and use tabs (Paulo).
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is possible thanks to moving the m/n stuff into pipe_config.

Unfortunately we need to move them a bit to avoid forward
declarations.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

While at it, also extract a common helper to copy the timings from the
cpu transcoder to the pch transcoder. That way it's really explicit
how the lpt transcoder is hardcoded.

v2:
- Re-align #defines properly (Paulo).
- Use cpu_transcoder when copying pipe timings (Paulo).
- s/intel_pch_transcoder_enable/intel_pch_transcoder_set_timings/
  since we already have a pch transcoder enable function, and this is
  clearer, too.
- Fixup 80 char line overflow in intel_display.c. I've opted to ignore
  this in i915_reg.h and i915_ums.c since meh.

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

Every time I read hsw code I get completely confused about this. So
call it what it is more explicitly.

Also, add an LPT_TRANSCONF for the pch transcoder A and use it in
lpt-only code, to really unconfuse me.

v2: s/plane/pipe/ in the TRANSCONF #define (Paulo).
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the hw state readout&check code it's important that the values we
keep around are the canonical ones. Unfortunately when adding the pipe
timings readout support I've missed that the write side adjusts the
timings in the pipe config.

Fix this up and so prevent the unsightly WARN noise in dmesg. This
regression has been introduced in

commit 1bd1bd80
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Apr 29 21:56:12 2013 +0200

    drm/i915: hw state readout support for pipe timings
Reported-by: NPaulo Zanoni <przanoni@gmail.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Storing context reference into request struct
allows us to inspect context and its associated
objects when requests are retired.

Both ppgtt and arb robustness work will need
this.
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In order to be notified of when the context and all of its associated
objects is idle (for if the context maps to a ppgtt) we need a callback
from the retire handler. We can arrange this by using the kref_get/put
of the context for request tracking and by inserting a request to
demarque the switch away from the old context.

[Ben: fixed minor error to patch compile, AND s/last_context/from/]
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

dp_init_connector adjusts the encoder type if it is a eDP panel. Use
that to decide whether we should set up a hdmi connector or not.

To do so reorder the hdmi connector setup sequence in ddi_init a bit.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We can't read the pfit regs if the power well is off, so use the cached
value.

v2: re-add lost comment (Jesse)
    make sure the crtc using the fitter is actually enabled (Jesse)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Drop now unused dev_priv, as spotted by Mika.]
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Before module unload is called, gpu_idle() will switch
to default context. This will increment ref count of base
object as the default context is 'running' on module unload
time. Unreference the drm object so that when context
is freed, base object is freed as well.

v2: added comment to explain the refcounts (Ben Widawsky)
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If we ever leak a non-DP compliant port width through here, we have a
pretty serious issue. So just rip out all these WARNs - if we need
them it's probably better to have them at a central place where we
compute the dp lane count.

Also use the new DDI width macro for FDI mode.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: fixup the embarrassing s/intel_dp->DP/temp/ mistake Paulo
spotted.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Enabling PPGTT and also the need to track which context was guilty of
gpu hang (arb robustness enabling) have put pressure for struct i915_hw_context
to be more than just a placeholder for hw context state.

In order to track object lifetime properly in a multi peer usage, add reference
counting for i915_hw_context.

v2: track i915_hw_context pointers instead of using ctx_ids
(from Chris Wilson)

v3 (Ben): Get rid of do_release() and handle refcounting more compactly.
(recommended by Chis)

v4: kref_* put inside static inlines (Daniel Vetter)
remove code duplication on freeing context (Chris Wilson)

v5: idr_remove and ctx->file_priv = NULL in destroy ioctl (Chris)
This actually will cause a problem if one destroys a context and later
refers to the idea of the context (multiple contexts may have the same
id, but only 1 will exist in the idr).

v6: Strip out the request related stuff. Reworded commit message.
Got rid of do_destroy and introduced i915_gem_context_release_handle,
suggested by Chris Wilson.

v7: idr_remove can't be called inside idr_for_each (Chris Wilson)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net> (v5)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> (v7)
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Squash sob lines, the patch ping-ponged between Ben and Mika
a bit ...]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Reduce the size of the the src/dst viewport to keep the scalign ratios
in check.

v2: Below min size sprite handling squashed to previous patch
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Properly clip the source when the destination gets clipped
by the pipe dimensions.

Sadly the video sprite hardware is rather limited so it can't do proper
sub-pixel postitioning. Resort to truncating the source coordinates to
(macro)pixel boundary.

The scaling checks are done using the strict drm_region functions.
Which means that an error is returned when the min/max scaling
ratios are exceeded.

Also do some additional checking against various hardware limits.

v2: Truncate src coords instead of rounding to avoid increasing src
    viewport size, and adapt to changes in drm_calc_{h,v}scale().
v3: Adapt to drm_region->drm_rect rename. Fix misaligned crtc_w for
    packed YUV formats when scaling isn't supported.
v4: Use stricter scaling checks, use drm_rect_equals()
v5: If sprite is below min size, make it invisible instead returning
    an error.
    Use WARN_ON() instead if BUG_ON(), and add one to sanity check the
    src viewport size.
v6: Add comments to remind about src and dst coordinate types
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drm_rect_equals() tells whether two drm_rects are equal.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Move near other defines, add TCHE in the name. No functional changes.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Spotted while changing related code.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Switch dotclock limit check to <= as suggested by Ville.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Again in preparation to move the configuration checks into the
pipe_config computation stage of the modeset sequence.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>