Make the giant function a little less giant.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Add pipe_ prefix as suggested by Chris.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Make it clear that we're checking whether FBC is supported or not. The
fact that the vfunc is not NULL is just a consequence.

Another name option would have been fbc_initialized().
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The spec says we just can't use it.

v2:
  - Add WA name (Ville).
  - Add a big comment explaining that we still didn't fix the problem
    where we inherit a framebuffer on the first page (Chris, Ville).
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This fixes the warnings like

"plane A assertion failure, should be disabled but not"

that on the initial modeset during boot. This can happen if
the primary plane is enabled by the firmware, but inheriting
it fails because the DMAR is active or for other reasons.

Most likely caused by

commit 36750f28
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Mon Jun 1 12:49:54 2015 +0200

    drm/i915: update plane state during init

This is the 4.4 version of

commit 721a09f7
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Tue Sep 15 14:28:54 2015 +0200

    drm/i915: Add primary plane to mask if it's visible
Reported-by: NAndreas Reis <andreas.reis@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91429Reported-and-tested-by: NEmil Renner Berthing <kernel@esmil.dk>
Tested-by: NAndreas Reis <andreas.reis@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Hide the 945 vs. rest of gen2/3 difference in the macro
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Bspec update tells that we have to enable oscaledcompmethod instead of
ouniqetrangenmethod for enabling scale value during swing programming.

v2: Adding back 'don't care' values to bxt_ddi_translations_dp and add
error message if ouniquetrangemethod was set (Imre)
Signed-off-by: NSonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>(v1)
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Adding voltage swing table for edp to support low vswings.

v2: Rebased.
Signed-off-by: NSonika Jindal <sonika.jindal@intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

According to the PCI docs and Rafael, we don't need to be doing explicit
enables and disables in our init and teardown routines, as they're taken
care of by the PCI core.  So drop the pm_runtime_disable() at teardown
and pm_runtime_set_active() at init.

This fixes one failure of the basic-pci-d3-state test on my BYT.

v2: drop extra get_noresume() and put_noidle() (Rafael)

Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Acked-by: N"Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Bit 16 of GuC status indicates resuming from RC6. The LAPIC_DONE
status is a reliable readiness flag only when resuming from RC6.
This fix a racing issue that allocation of doorbell fails whilst
GuC init is not finished.
Signed-off-by: NAlex Dai <yu.dai@intel.com>
Reviewed-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Always name any variable pointing at the adjusted mode as
'adjustead_mode'. This will make it much easier to identify
when we should use the crtc_ timings and when we shoudln't.

Conversion was performed with coccinelle:
@@
expression E;
identifier I;
@@
- struct drm_display_mode *I = &E.adjusted_mode;
+ struct drm_display_mode *adjusted_mode = &E.adjusted_mode;
<...
- I
+ adjusted_mode
...>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>
[danvet: Fixup conflicts.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Replace intel_dvo->panel_fixed_mode with the appropriate intel_panel
stuff. Now all connectors that have a fixed mode use intel_panel.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Another interesting criteria to work dmc as expected is pw1 to be
enabled by driver and dmc will shut it off in its execution
sequence. If already disabled by driver dmc will get confuse and
behave differently than expected found during pc10 entry issue
for skl.

So berfore we disable power-well 1, added check if dmc firmware is
present and driver will not disable power well 1, but for any reason
if firmware is not present of failed to load we can shut off the
power well 1 which will save some power.

As skl is currently fully dependent on dmc to go in lowest possible
power state (dc6) but the same is not applicable for bxt. Display
engine can enter into dc9 without dmc, hence unblocking disable call.

v1: Initial version.

v2: Rebased as per current patch series.

Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Signed-off-by: NVathsala Nagaraju <vathsala.nagaraju@intel.com>
Reviewed-by: NA.Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

While display engine entering into low power state no need to disable
cdclk pll as CSR firmware of dmc will take care. If pll is already
enabled firmware execution sequence will be blocked. This is one
of the criteria for dmc to work properly.

v1: Initial version.

v2: Based on review comment from Daniel added code commnent.

Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Signed-off-bt: Vathsala Nagaraju <vathsala.nagaraju@intel.com>
Signed-off-by: NRajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
Reviewed-by: NA.Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch remove the function call to set the firmware
loading status as uninitialized during suspend.

Dmc firmware will restore the firmware in normal suspend. In previous
patch added a check to directly read the hardware status and load
the firmware if got reset during resume from suspend-hibernation.

Cc: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Signed-off-by: NVathsala Nagaraju <vathsala.nagaraju@intel.com>
Reviewed-by: NA.Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Dmc will restore the csr program except DC9, cold boot,
warm reset, PCI function level reset, and hibernate/suspend.

intel_csr_load_program() function is used to load the firmware
data from kernel memory to csr address space.

All values of csr address space will be zero if it got reset and
the first byte of csr program is always a non-zero if firmware
is loaded successfuly. Based on hardware status will load the
firmware.

Without this condition check if we overwrite the firmware data the
counters exposed for dc5/dc6 (help for debugging) will be nullified.

Note: Above commit message seems to be confused and the real problem
apparently going on is that for suspend-to-idle and system standby the
firmware survives (it's like runtime pm), but it doesn't for
suspend-to-mem and hibernate-to-disk. All the other talking about DC9
and pci reset are irrelevant for the path touched here (only driver
load and system resume functions) and might not be true statements.

v1: Initial version.

v2: Based on review comments from Daniel,
- Added a check to know hardware status and load the firmware if not loaded.

Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Signed-off-by: NVathsala Nagaraju <vathsala.nagaraju@intel.com>
Reviewed-by: NA.Sunil Kamath <sunil.kamath@intel.com>
[danvet: Explain clearly in the code comment when we need to reload
and when not and make it a FIXME. Also deconfuse the commit message
with a note. Also: Make. it. compile.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Virtualized systems often use a virtual P2X4 south bridge.
Detect this in intel_detect_pch and make a best guess as to which PCH
we should be using.

This was seen on vmware esxi hypervisor. When passing the graphics device
through to a guest, it can not pass through the PCH. Instead it simulates
a P2X4 southbridge.
Signed-off-by: NRobert Beckett <robert.beckett@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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

Leak a task reference in i915_ppgtt_info(), add put_task_struct()
to fix it.

Introduced by

commit 1c60fef5
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Fri Dec 6 14:11:30 2013 -0800

    drm/i915: Dump all ppgtt
Signed-off-by: NGeliang Tang <geliangtang@163.com>
[danvet: Add note provided by Jani about which commit introduced this
issue.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The vblank counts are u32 so make flip_queued_vblank and
flip_ready_vblank u32 as well.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

linedur_ns, and especially pixeldur_ns are becoming rather inaccurate
to be used for the vblank timestamp correction. With 4k@60 the pixel
duration is already below 2ns, so the amount of error due to the
truncation to nanoseconds is introducing quite a bit of error.

We can avoid such problems if we instead calculate the timestamp
delta_ns directly from the dislay timings, avoiding the use of
these intermediate truncated values.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
[danvet: Squash in fixup from Thierry Reding for amdgpu.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Collect the timestamping constants alongside the rest of the relevant
stuff under drm_vblank_crtc.

We can now get rid of the 'refcrtc' parameter to
drm_calc_vbltimestamp_from_scanoutpos().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When preallocating a stolen object during early initialisation, we may
be running before we have setup the the global GTT VM state, in
particular before we have initialised the range manager and associated
lists. As this is the case, we defer binding the stolen object until we
call i915_gem_setup_global_gtt(). Not only should we defer the binding,
but we should also defer the VM list manipulation.

Fixes regression uncovered by commit a2cad9df
Author: Michał Winiarski <michal.winiarski@intel.com>
Date:   Wed Sep 16 11:49:00 2015 +0200

    drm/i915/gtt: Do not initialize drm_mm twice.

Whilst I am here remove the duplicate work leaving dangling pointers
from the error path...

v2: Typos galore before coffee.
Reported-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92099Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
Tested-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Remove extraneous request cancel in request allocation failure path
in intel_lr_context_deferred_alloc (Tvrtko Ursulin)

Regression from:

  commit e84fe803
  Author: Nick Hoath <nicholas.hoath@intel.com>
  Date:   Fri Sep 11 12:53:46 2015 +0100

      drm/i915: Split alloc from init for lrc
Signed-off-by: NNick Hoath <nicholas.hoath@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Rebase.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Just adding the rotated UV plane at the end of the rotated Y plane.

v2: Rebase.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

By providing a start offset into the source array of pages, and returning the
end position in the scatter-gather table, we will be able to append the UV
plane to the rotated mapping in later patches.

v2: Rebase.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This will be needed for NV12 support.

v2: Rebase.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Cc: Nick Hoath <nicholas.hoath@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

FIXME: Should there be a WARN(i != 9) or something, or what does the
entry 9 comment mean?
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

intel_sdvo_select_ddc_bus() and intel_sdvo_select_i2c_bus() have no used
for the passed in 'reg', so just drop it.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Ignore DEVICE_TYPE_NOT_HDMI_OUTPUT and DEVICE_TYPE_DIGITAL_OUTPUT when
trying to determine the presence of eDP based on the VBT child device
type. Apparently a significant portion of VLV systems have these bits
set incorrectly, and so we currently fail to detect eDP on said systems.

This is based on an earlier patch [1] from Andreas Lampersperger.
Instead of ignoring the bits just on VLV as was done in the orignal
patch, we now ignore them for all platforms. We should still have
enough bits in there to avoid false positives (unless the VBT is totally
bonkers).

Quoting the orignal patch:
> When the i915.ko identify an eDP output on a valleyview
> board, it should be more slackly. The reason for that is,
> that BIOS DATA TABLES generated with intel BMP (Binary
> Modification Program) do not set bits for NOT_HDMI or
> DIGITAL_OUTPUT on the device type. Due to Adolfo
> Sanchez from Intel EMGD, this is not possible.
> To solve this problem and enable i915.ko on embedded
> vlv boards with eDP, we ignore this two bits.

[1] http://lists.freedesktop.org/archives/intel-gfx/2015-June/069416.html

Cc: Andreas Lampersperger <lampersperger.andreas@heidenhain.de>
Cc: "Sanchez, AdolfoX" <adolfox.sanchez@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We don't support eDP on g4x, so let's not even look at the VBT
to determine the port type, just in case the VBT is bonkers
on some g4x machines and indicates the precense of eDP.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

An HPD interrupt may fire while we are in a function that changes
the PORT_HOTPLUG_EN register - especially when an HPD interrupt
storm occurs.
Since the interrupt handler changes the enabled HPD lines when it
detects such a storm the read-modify-write cycles may interfere.
To avoid this, shiled the rmw cycles with IRQ save spinlocks.

Changes since v1:
- Implement a function which takes care of accessing PORT_HOTPLUG_EN.
Signed-off-by: NEgbert Eich <eich@suse.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>