Avoids 2 forward declarations.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently we have the problem that the decision whether ptes need to
be (re)written is splattered all over the codebase. Move all that into
i915_vma_bind. This needs a few changes:
- Just reuse the PIN_* flags for i915_vma_bind and do the conversion
  to vma->bound in there to avoid duplicating the conversion code all
  over.
- We need to make binding for EXECBUF (i.e. pick aliasing ppgtt if
  around) explicit, add PIN_USER for that.
- Two callers want to update ptes, give them a PIN_UPDATE for that.

Of course we still want to avoid double-binding, but that should be
taken care of:
- A ppgtt vma will only ever see PIN_USER, so no issue with
  double-binding.
- A ggtt vma with aliasing ppgtt needs both types of binding, and we
  track that properly now.
- A ggtt vma without aliasing ppgtt could be bound twice. In the
  lower-level ->bind_vma functions hence unconditionally set
  GLOBAL_BIND when writing the ggtt ptes.

There's still a bit room for cleanup, but that's for follow-up
patches.

v2: Fixup fumbles.

v3: s/PIN_EXECBUF/PIN_USER/ for clearer meaning, suggested by Chris.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

It's true that we might need to context switch, but both the signalling
and implementation of the same are a few source files away. Remove it.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It's already protected by the bkl^Wdev->struct_mutex. While at it
realign some related code.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

We load the ppgtt ptes once per gpu reset/driver load/resume and
that's all that's needed. Note that this only blows up when we're
using the allocate_va_range funcs and not the special-purpose ones
used. With this change we can get rid of that duplication.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Add Y tiling support to skl_do_mmio_flip.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

   commit ae6c4806
   Author: Daniel Vetter <daniel.vetter@ffwll.ch>
   Date:   Wed Aug 6 15:04:53 2014 +0200

       drm/i915: Only track real ppgtt for a context

Changed the code but didn't update kerneldoc.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: "Thierry, Michel" <michel.thierry@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since

commit bf3d149b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Feb 14 14:01:12 2014 +0100

    drm/i915: split PIN_GLOBAL out from PIN_MAPPABLE

i915_gem_obj_ggtt_pin always binds into the ggtt, but I've forgotten
to remove the now redundant additional bind call later on. Fix this
up.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

PIN_GLOBAL is set only when userspace asked for it, and that
is only the case for the gen6 PIPE_CONTROL workaround. We're not
allowed to just clear this.

The important part of the fallback is to drop the restriction to
the mappable range.

This issue has been introduced in

commit edf4427b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jan 14 11:20:56 2015 +0000

    drm/i915: Fallback to using CPU relocations for large batch buffers

v2: Chris pointed out that we also miss to set PIN_GLOBAL when the
buffer is already bound. Fix this up too.

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

It's only used as a flag there, so unconfuse things a bit.
Also separate the bind_vma flag space from the pte_encode flag
space in the code.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the dynamic pagetable alloc code aliasing ppgtt special-cases
where again mixed in all over the place with the low-level init code.

Extract the va preallocation and clearing again into the common code
where aliasing ppgtt gets set up.

Note that with this we don't set the size of the aliasing ppgtt to the
size of the parent ggtt address space. Which isn't required at all
since except for the ppgtt setup/cleanup code no one ever looks at
this.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

While at it inline the free functions - they don't actually free the
ppgtt, just clean up the allocations done for it.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

They change with the address space and not with each vma, so move them
into the right pile of vfuncs. Save 2 pointers per vma and clarifies
the code.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Purpose of this tracking is to know when to flush the cache between
the CPU and the non-coherent display engine. Prior to:

   commit 121920fa
   Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
   Date:   Mon Mar 23 11:10:37 2015 +0000

       drm/i915/skl: Query display address through a wrapper

This worked by a mix of direct flag manipulation and checking for
existence of a pinned GGTT VMA.

With the introduction of rotated display mappings this approach is
no longer correct.

New simpler approach is to just keep this count over calls which pin
and unpin objects to and from display, at the slight cost of extra
space in every bo.

(Inspired and extracted code from a larger rework by Chris Wilson.)

v2: Remove the limit since it is not well defined. (Chris Wilson, Ville Syrjälä)
v3: Commit message corrections. (Chris Wilson)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Remove duplicated include.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

After feedback from the hardware team we are changing the RC6
promotional timer to increase the power saving without
changing performance.
Signed-off-by: NDeepak S <deepak.s@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The Displayport Link Layer Compliance Testing Specification 1.2 rev 1.1
specifies that repeated AUX transactions after a failure (no response /
invalid response) must have a minimum delay of 400us before the resend can
occur. Tests 4.2.1.1 and 4.2.1.2 are two tests that require this specifically.

Also, the check for DP_AUX_CH_CTL_TIME_OUT_ERROR has been moved out into a
separate case. This case just continues with the next iteration of the loop
as the HW has already waited the required amount of time.

V2:
- Changed udelay() to usleep_range()
V3:
- Removed extraneous check for timeout
- Updated comment to reflect this change
V4:
- Reformatted a comment
V5:
- Added separate check for HW timeout on AUX transactions. A message
  is logged upon detection of this case.
V6:
- Add continue statement to HW timeout detect case
- Remove the log message indicating a timeout has been
  detected (review feedback)
V7:
- Updated the commit message to remove verbage about the HW timeout
  case that is no longer valid.
Signed-off-by: NTodd Previte <tprevite@gmail.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add the skeleton framework for supporting automation for Displayport compliance
testing. This patch adds the necessary framework for the source device to
appropriately respond to test automation requests from a sink device.

V2:
- Addressed previous mailing list feedback
- Fixed compilation issue (struct members declared in a later patch)
- Updated debug messages to be more accurate
- Added status checks for the DPCD read/write calls
- Removed excess comments and debug messages
- Fixed debug message compilation warnings
- Fixed compilation issue with missing variables
- Updated link training autotest to ACK

V3:
- Fixed the checks on the DPCD return code to be <= 0
  rather than != 0
- Removed extraneous assignment of a NAK return code in the
  DPCD read failure case
- Changed the return in the DPCD read failure case to a goto
  to the exit point where the status code is written to the sink
- Removed FAUX test case since it's deprecated now
- Removed the compliance flag assignment in handle_test_request

V4:
- Moved declaration of type_type here
- Removed declaration of test_data (moved to a later patch)
- Added reset to 0 for compliance test variables

V5:
- Moved test_active variable declaration and initialization out of
  this patch and into the patch where it's used
- Changed variable name compliance_testing_active to
  compliance_test_active to unify the naming convention
- Added initialization for compliance_test_type variable
Signed-off-by: NTodd Previte <tprevite@gmail.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drivers/gpu/drm/i915/i915_debugfs.c:4850:2-3: Unneeded semicolon

 Removes unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

intel_ is for generic code bxt_ and friends for platform specific
functions. Remove the intel_ prefix to be consistent with our naming.

Random OCD bikeshed I've spotted while merging bxt patches.

v2: Oops, git add fail.

Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Broxton supports 3 voltage swing levels on all DP ports.
Max level of pre-emphasis will be taken care with the existing code.

v2: Patch rebased

v3: (imre)
- keep existing behavior for other platforms
- clarify commit message

Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> (v2)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

VSwing programming sequence as specified in the updated BXT BSpec

v2: Satheesh's review comments addressed.
- clear value before setting into registers
- move print statement to bxt function
Other changes
- since signal level will not be set into DDI_BUF_CTL, the value need
  not be returned to intel_dp_set_signal_levels(). Making the bxt
  specific function to return void and setting signal_levels = 0 for
  bxt inside intel_dp_set_signal_levels()
- instead of signal levels, printing vswing level and pre-emphasis
  level
- in case none of the pre-emphasis levels or vswing levels are set,
  setting default of 400mV + 0dB

v3: Satheesh's review comments
- Check for mask before printing signal_levels.
- Removing redundant register writes
- Call intel_prepare_ddi_buffers only for HAS_PCH_SPLIT
- Making register write part generic as it will be required for HDMI as
  well.

Re-structure the code to include an array for vswing related values, set
signal levels

v4: Satheesh's review comments
- Rebase over latest renaming patches
- use hsw_signal_levels for HAS_DDI
Other changes
- Modified vswing_sequence() func definition
- Rebased on top of register macro definitions

v5: Satheesh's review comments
- Check ddi translation table size

v6: Imre's review comments
- removed comments in vswing sequence
- added vswing, pre-emphasis prints in intel_dp_set_signal_levels
- added comment explaining use of DP vswing values for eDP
- initialize n_entries and ddi_transaltion table based on encoder type
- create bxt_ddi_buf_trans structure and use decimal values
- adding a flag in bxt buffer translation table to indicate def entry

v7: (imre)
- squash in Vandana's "VSwing register definition",
  "HDMI VSwing programming", "Re-enable vswing programming",
  "Fix vswing sequence" patches
- use BXT_PORT_* regs directly instead of via a temp var
- simplify BXT_PORT_* macro definitions
- add code comment why we read lane while write group registers
- fix readout of DP_TRAIN_PRE_EMPHASIS in debug message

Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> (v6)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We don't actually need to write the HDMI entry on DDIs that have no
chance to be used as HDMI ports.

While this patch shouldn't change the current behaviour, it makes
further enabling work easier as we'll have an eDP table filling the full
10 entries.

v2: Rely on the logic from intel_ddi_init() to figure out if the DDI port
    supports HDMI or not (Paulo).
Suggested-by: NSatheeshakrishna M <satheeshakrishna.m@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Not every DDIs is necessarily connected can be strapped off and, in the
future, we'll have platforms with a different number of default DDI
ports. So, let's only call intel_prepare_ddi_buffers() on DDI ports that
are actually detected.

We also use the opportunity to give a struct intel_digital_port to
intel_prepare_ddi_buffers() as we'll need it in a following patch to
query if the port supports HMDI or not.

On my HSW machine this removes the initialization of a couple of
(unused) DDIs.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The checks for PLL enabled state on CPU ports are valid only on GMCH
platforms but atm we'd also call them on non-PCH-split/non-GMCH
platforms like BXT, triggering false warnings. Until the proper check is
implented for these platforms simply disable the check.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add placeholder function for calculating programmed pixel clock.
Note: Formula to back calculate link clock from dividers not
available currently.

v2:
- rebased on upstream s/crtc_config/crtc_state/ change (imre)

Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v1)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Determine PLL attached to pipe (which is same as DDI PLL)

v2:
- rebased on upstream s/crtc_config/crtc_state/ (imre)

Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v1)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Assign PLL for pipe (dependent on port attached to the pipe)

v2:
- fix incorrect encoder vs. new_encoder check for crtc (imre)

v3:
- warn and return error if no encoder is attached (imre)

Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v2)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Don't move intel_ddi_get_crtc_new_encoder around.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Calculate and cache clock parameters. Follow bspec algorithm for HDMI.
Use precalculated values for DisplayPort linkrates.

v2: (imre)
- rebase against upstream crtc_state change
- use the existing CHV based helper instead of handrolling the same

Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v1)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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

Plug bxt PLL code into existing shared DPLL framework.

v2: (imre)
- squash in Satheeshakrishna's "Define BXT clock registers" and
  "Add state variables for bxt clock registers" patches
- squash in Vandanas's "Change grp access to lane access for PLL"
- fix group vs. lane access in bxt_ddi_pll_get_hw_state
- add code comment why we read from lane registers while writing to
  group registers
- clean up register macros
- use BXT_PORT_PLL_* macros instead of open-coding the same
- check if BXT_PORT_PCS_DW12_LN01 matches BXT_PORT_PCS_DW12_LN23
  during hardware state readout
- add missing LANESTAGGER_STRAP_OVRD masking
- add note about missing step according to the latest BUN for
  PORT_PLL_9/lockthresh

Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v1)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Broxton has the same panel fitter registers as Skylake.

v2:
- add MISSING_CASE for future platforms (daniel)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NSagar Kamble <sagar.a.kamble@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

PORT_CLK_SEL programming is needed only on HSW/BDW.

v2:
- don't program PORT_CLK_SEL from mst encoders either (imre)
v3:
- fix the check for GEN9+ in intel_mst_pre_enable_dp() (damien)
Signed-off-by: NSatheeshakrishna M <satheeshakrishna.m@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NSagar Kamble <sagar.a.kamble@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Same as IBX and G4x, they all share the same genetic material.

v2: we all need a bit more port in our lives
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since the pin_ioctl is defunct, we only care about whether an object is
pinned into the display for debug purposes.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since the removal of the user pin_ioctl, the only means for pinning an
object is either through binding to the scanout or during execbuf
reservation. As the later prevents a call to set-tiling, we need only
check if the obj is pinned into the display plane to see if we need
reject the set-tiling ioctl.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The HDMI translation table is added back to bspec, so adding it,
and defaulting the 800mV+0dB entry.

The HDMI translation table was removed by following commit as per HW team's
recommendation:
commit 7ff44670 ("drm/i915/skl: Only use the 800mV+2bB HDMI translation entry")

v2: Adding reference to commit which removed this table (Jani)

Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NSonika Jindal <sonika.jindal@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is a separate patch to simplify conflict handling with other
ongoing atomic work.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since universal planes the primary plane might not be around, and it's
kinda silly to restrict the pipe bpp to the primary plane if we might
end up displaying a 10bpc video overlay. And with atomic we might very
well enable a pipe without a primary plane. So just use the platform
max as a starting point and then restrict appropriately.

Of course this is all still a bit moot as long as we artificially
compress everything to max 8bpc because we don't use the hi-bpc gamma
tables.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>