drm/i915: Parametrize LRC registers

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

drm/i915: Don't pass sdvo_reg to intel_sdvo_select_{ddc, i2c}_bus()

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Ignore "digital output" and "not HDMI output" bits for eDP detection

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Make sure we don't detect eDP on g4x

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt, v2

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: Egbert Eich <eich@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Do not hardcode s_max, ss_max and eu_mask for BXT

We can calculate BXT values correctly from GFX fuse values without
hardcoding special limits.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Matthew D Roper <matthew.d.roper@intel.com>
Signed-off-by: Dongwon Kim <dongwon.kim@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

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

It would be initialized just moments later by i915_init_vm.

Rearrange the code such that i915_init_vm() is next to its callers
inside i915_gem_gtt (and so we can make it static). After removing the
dance around the files, it is clear that we are repeating some work
inside the initializers (such as calling drm_mm_init() multiple times),
so take advantage of the refactor to also remove some redundant code and
clean up the interface.

v2: Commit msg update,
    s/i915_init_vm/i915_address_space_init, move to i915_gem_gtt.c,
    init address_space during i915_gem_setup_global_gtt for ggtt.
v3: Do not init global_link - we are adding it to vm_list moments later,
    make i915_address_space_init static, use OOP style parameter order.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Implement stolen reserved detection for ctg/elk

Finally managed to dig up enough hints as to where the stolen
reserved stuff lives on ctg/elk. So add the code to decode it.
This was a combination of old chipset specs, diggin up an old
elk grits release with an ctg/elk AubLoad etc.

This was only tested on an elk as I don't have a ctg here
unfortunately.

This leaves ilk as the only platform that doesn't have a way
to detect this stuff. Looking at the register contents on my
ilk, it might be that the elk way works there too, but I
can't be sure since I can't affect the amount of reserved
memory on that machine, and if I am to trust the register
contents, by default it would reserve 0 bytes.

v2: s/WARN_ON_ONCE/WARN_ON/ since it's in one time init code
    anyway (Paulo)

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix FBC for cases where crtc->base.y is non-zero

I only tested this on BDW and SKL, but since the register description
is the same ever since gen4, let's assume that all gens take the same
register format. If that's not true, then hopefully someone will
bisect a bug to this patch and we'll fix it.

Notice that the wrong fence offset register just means that the
hardware tracking will be wrong.

Testcases:
 - igt/kms_frontbuffer_tracking/fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt
 - igt/kms_frontbuffer_tracking/fbc-2p-primscrn-pri-shrfb-draw-mmap-gtt

v2:
  - Add intel_crtc->adjusted_{x,y} so this code can work independently
    of intel_gen4_compute_page_offset(). (Ville).
  - This version also works on SKL.

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

drm/i915: reject invalid formats for FBC

This commit is essentially a rewrite of "drm/i915: Check pixel format
for fbc" from Ville Syrjälä. The idea is the same, but the code is
different due to all the changes that happened since his original
patch. So any bugs are due to my bad rewrite.

v2:
  - Drop the alpha formats (Ville).
v3:
  - Drop the stale comment (Ville).

Testcases: igt/kms_frontbuffer_tracking/*fbc*-${format_name}-draw-*
Credits-to: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't apply WaFbcAsynchFlipDisableFbcQueue on SKL

This WA is only for HSW/BDW.

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

drm/i915: apply WaFbcAsynchFlipDisableFbcQueue earlier

The spec says the register should have that value for the entire time
that FBC is enabled, so apply the WA before we enable FBC.

Notice that we also have this WA for ILK/SNB, but it is implemented at
init_clock_gating(). I could move the IVB/HSW/BDW WA code to
init_clock_gating() too, but since we recently had some complaints
about WAs not staying after being set, I'm going to play safe and keep
this here for now.

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

drm/i915: don't enable FBC when pixel rate exceeds 95% on HSW/BDW

BSpec says we shouldn't enable FBC on HSW/BDW when the pipe pixel rate
exceeds 95% of the core display clock.

v2:
  - HSW also needs the WA (Ville).
  - Add the WA name (Ville).
  - Use the current cdclk (Ville).

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

drm/i915: print the correct amount of bytes allocated for the CFB

And also print the threshold. I was surprised to see a log message
claiming the CFB size was 32mb when there was less than 24mb available
for it.

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

drm/i915: avoid the last 8mb of stolen on BDW/SKL

The FBC hardware for these platforms doesn't have access to the
bios_reserved range, so it always assumes the maximum (8mb) is used.
So avoid this range while allocating.

This solves a bunch of FIFO underruns that happen if you end up
putting the CFB in that memory range. On my machine, with 32mb of
stolen, I need a 2560x1440 mode for that.

Testcase: igt/kms_frontbuffer_tracking/fbc-* (given the right setup)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: check for the supported strides on HSW+ FBC

Don't allow FBC for cases where the spec says we can't FBC.

v2:
  - Just WARN_ON() the strides that should have been caught earlier
    (Daniel)
  - Make it a new function since I expect this to grow more.
v3:
  - Document which IGT test is exercised by this.
v4:
  - Implement the restrictions for gens 2-6 too (Ville).
  - Fix off-by-one mistake (Ville).

Testcase: igt/kms_frontbuffer_tracking/fbc-badstride
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix the FBC work allocation failure path

Always update the currrent crtc, fb and vertical offset after calling
enable_fbc. We were forgetting to do so along the failure paths when
enabling fbc synchronously. Fix this with a new helper to enable_fbc()
and update the state simultaneously.

v2: Improve commit message (Chris).
v3: Constify struct drm_framebuffer (Ville).

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

drm/i915: Fix fastboot scalers for skylake.

The scaler_id in intel_pipe_config_compare should not be checked
when adjusting in intel_pipe_config_compare. The hw scaler id may
be changed in intel_update_pipe_config.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Program GuC MAX IDLE Count

Cc: Alex Dai <yu.dai@intel.com>
Cc: Tom O'Rourke <Tom.O'Rourke@intel.com>
Cc: Akash Goel <akash.goel@intel.com>
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: WaRsDoubleRc6WrlWithCoarsePowerGating

Cc: Tom O'Rourke <Tom.O'Rourke@intel.com>
Cc: Akash Goel <akash.goel@intel.com>
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Alex Dai <yu.dai@intel.com>
[danvet: Fix continuation alignment.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: WaRsUseTimeoutMode

Enable TO mode for RC6 for SKL till D0 and BXT till A0.

Cc: Tom O'Rourke <Tom.O'Rourke@intel.com>
Cc: Akash Goel <akash.goel@intel.com>
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Alex Dai <yu.dai@intel.com>
[danvet: Fixup line continuation alignment.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: WaRsDisableCoarsePowerGating

WaRsDisableCoarsePowerGating: Coarse Power Gating (CPG) needs to be
disabled for platforms prior to BXT B0 and SKL GT3/GT4 till E0.

v2: Added GT3/GT4 Check.

Change-Id: Ia3c4c16e050c88d3e259f601054875c812d69c3a
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Alex Dai <yu.dai@intel.com>
[danvet: Align continuation properly.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add IS_SKL_GT3 and IS_SKL_GT4 macro.

It will be usefull to specify w/a that affects only SKL GT3 and GT4.

Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix crash in error state readout on non-execlist platforms v2

Looks like this was introduced in:
commit d1675198ed1f21aec6e036336e4340c40b726497
Author: Alex Dai <yu.dai@intel.com>
Date:   Wed Aug 12 15:43:43 2015 +0100

    drm/i915: Integrate GuC-based command submission

This patch assumed LRC contexts and HWS layout, which is incorrect on
platforms without execlists.  This can lead to a crash in GPU error
state readout on those platforms.

I don't see a bug filed for this, but there may be one that I haven't
found.

v2: fixup offset handling for error capture fix (Dave)

Cc: Alex Dai <yu.dai@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Move scanline_offset and timestamping constant setup to intel_modeset_readout_hw_state()

intel_modeset_readout_hw_state() seems like the more appropriate place
for populating the scanline_offset and timestamping constants than
intel_sanitize_crtc() since they are basically part of the state we
read out.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Move sprite/cursor plane disable to intel_sanitize_crtc()

Move the sprite/cursor plane disabling to occur in intel_sanitize_crtc()
where it belongs instead of doing it in intel_modeset_readout_hw_state().

The plane disabling was first added in
4cf0ebbd4fafbdf8e6431dbb315e5511c3efdc3b drm/i915: Rework plane readout.

I got the idea from some patches from Partik and/or Maarten but those
moved also the plane state readout to intel_sanitize_crtc() which isn't
quite right in my opinion.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=91910
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Assign hwmode after encoder state readout

The dotclock is often calculated in encoder .get_config(), so we
shouldn't copy the adjusted_mode to hwmode until we have read out the
dotclock.

Gets rid of some warnings like these:
[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0!
[drm:i915_get_vblank_timestamp] crtc 0 is disabled

v2: Steal Maarten's idea to move crtc->mode etc. assignment too

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91428
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Check live status before reading edid

The Bspec is very clear that Live status must be checked about before
trying to read EDID over DDC channel. This patch makes sure that HDMI
EDID is read only when live status is up.

The live status doesn't seem to perform very consistent across various
platforms when tested with different monitors. The reason behind that is
some monitors are late to provide right voltage to set live_status up.
So, after getting the interrupt, for a small duration, live status reg
fluctuates, and then settles down showing the correct staus.

This is explained here in, in a rough way:
HPD line  ________________
 |\ T1 = Monitor Hotplug causing IRQ
 | \______________________________________
 | |
                         | |
 | |   T2 = Live status is stable
 | |  _____________________________________
 | | /|
Live status _____________|_|/ |
 | |  |
 | |  |
 | |  |
T0 T1  T2

(Between T1 and T2 Live status fluctuates or can be even low, depending on
 the monitor)

After several experiments, we have concluded that a max delay
of 30ms is enough to allow the live status to settle down with
most of the monitors. This total delay of 30ms has been split into
a resolution of 3 retries of 10ms each, for the better cases.

This delay is kept at 30ms, keeping in consideration that, HDCP compliance
expect the HPD handler to respond a plug out in 100ms, by disabling port.

v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)
v3: Using intel_encoder->hpd_pin to check the live status (Siva)
Moving the live status read to intel_hdmi_probe and passing parameter
to read/not to read the edid. (me)
v4:
* Added live status check for all platforms using
intel_digital_port_connected.
* Rebased on top of Jani's DP cleanup series
* Some monitors take time in setting the live status. So retry for few
times if this is a connect HPD
v5: Removed extra "drm/i915" from commit message. Adding Shashank's sob
    which was missed.
v6: Drop the (!detect_edid && !live_status check) check because for DDI
ports which are enumerated as hdmi as well as DP, we don't have a
mechanism to differentiate between DP and hdmi inside the encoder's
hot_plug. This leads to call to the hdmi's hot_plug hook for DP as well
as hdmi which leads to issues during unplug because of the above check.
v7: Make intel_digital_port_connected global in this patch, some
reformatting of while loop, adding a print when live status is not
up. (Rodrigo)
v8: Rebase it on nightly which involved skipping the hot_plug hook for now
and letting the live_status check happen in detect until the hpd handling
part is finalized (Daniel)

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bxt: DSI prepare changes for BXT

This patch modifies dsi_prepare() function to support the same
modeset prepare sequence for BXT also. Main changes are:
1. BXT port control register is different than VLV.
2. BXT modeset sequence needs vdisplay and hdisplay programmed
   for transcoder.
3. BXT can select PIPE for MIPI transcoders.
4. BXT needs to program register MIPI_INIT_COUNT for both the ports,
   even if only one is being used.

v2: Fixed Jani's review comments. Rectified the DSI Macros to get
    proper register offsets using _MIPI_PORT instead of _TRANSCODER

v3: Rebased on latest drm-nightly branch. Fixed Jani's review comments.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bxt: Disable DSI PLL for BXT

This patch adds two new functions:
- disable_dsi_pll.
  BXT DSI disable sequence and registers are
  different from previous platforms.
- intel_disable_dsi_pll
  wrapper function to re-use the same code for
  multiple platforms. It checks platform type and
  calls appropriate core pll disable function.

v2: Fixed Jani's review comments.

v3: Rebased on latest drm-nightly branch.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bxt: Enable BXT DSI PLL

This patch adds new functions for BXT clock and PLL programming.
They are:
1. configure_dsi_pll for BXT.
   This function does the basic math and generates the divider ratio
   based on requested pixclock, and program clock registers.
2. enable_dsi_pll function.
   This function programs the calculated clock values on the PLL.
3. intel_enable_dsi_pll
   Wrapper function to use same code for multiple platforms. It checks the
   platform and calls appropriate core pll enable function.

v2: Fixed Jani's review comments. Macros are adjusted as per convention.

v3: Removed a redundant change wrt code comment.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Increase maximum polling time to 50ms for forcewake request/clear ack

On BXT, We Observe timeout for forcewake request completion with 2ms polling period as given here:
[drm:fw_domains_get] ERROR render: timed out waiting for forcewake ack request.
Polling for 50ms is recommended to avoid these timeouts.

Change-Id: Ie715b0069a3049606e9602bc5e97a6511890864d
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bxt: WaGsvDisableTurbo

Disable Turbo on steppings prior to B0 on BXT due to hangs seen during GT CPD exit.

Change-Id: I50c5c03f59f5ba092db19e17234951d89db42c6c
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed by: Alex Dai <yu.dai@intel.com>.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bxt: Modified HAS_CSR, added support for BXT

Modified HAS_CSR macro defination which earlier only supported
for skl, now added support for BXT.

v1: Initial version.

v2: Instaed of skylake/broxton check added gen9 check alone based
on review comment from Sunil.

Cc: Vetter, Daniel <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: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bxt: Stepping info added for bxt.

Added stepping info in intel_csr.c which is required to extract
specific firmware from packaged dmc firmware.

Stepping info is aligned with current bspec info.

Cc: Vetter, Daniel <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: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bxt: Path added of dmc firmware ver1 for BXT.

Broxton also has dmc to manage low-power display engine state.
Path of the firmware added in intel_csr.c.

Naming convention followed as <platform>_dmc_<api-version>.bin

v1: Initial version.

v2: Commit description added based on review comment from Sunil.

Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/skl: Don't clear all watermarks when updating. (v2)

Clearing the watermarks for all pipes/planes when updating the
watermarks for a single CRTC change seems like the wrong thing to
do here. As is, this code will ony update any pipe/plane watermarks
that need updating and leave the remaining set to zero.  Later, the
watermark checks in check_wm_state() will flag these zero'd out pipe/plane
watermarks and throw errors.

By clearing only the watermark values associated with the specific crtc
the other watermark values may remain unchanged.

v2: Make sure all the dirty flags are cleared. Damien
    Clear all values assoicated with crtc/pipe being updated.  Damien

Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Mark debug mod options as _unsafe

We don't want random people to touch these.

Especially true since we've just screwed up SKL by holding it way too
long under the preliminary flag because of some ABI issues. And now
there's howtos all over the internets about how to set this. Same
pretty much for anything else.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: drop fastboot changes, that option is gone.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix handling gen8_emit_flush_coherentl3_wa result

The function can return negative value.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Spell vga_switcheroo consistently

Currently everyone and their dog has their own favourite spelling
for vga_switcheroo. This makes it hard to grep dmesg for log entries
relating to vga_switcheroo. It also makes it hard to find related
source files in the tree.

vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere.

Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Merge remote-tracking branch 'drm-intel/drm-intel-next-queued' into drm-intel-next-queued

Pull in patches Jani merged while I was at XDC.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm/i915/skl: handle port E in cpt_digital_port_connected

SKL port E handling was added in

commit 26951caf55d73ceb1967b0bf12f6d0b96853508e
Author: Xiong Zhang <xiong.y.zhang@intel.com>
Date:   Mon Aug 17 15:55:50 2015 +0800

    drm/i915/skl: enable DDI-E hotplug

but the whole function was moved in a another branch in

commit b93433ccf64846820b9448f5ff5dd4348b58a8ed
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Thu Aug 20 10:47:36 2015 +0300

    drm/i915: move ibx_digital_port_connected to intel_dp.c

and the addition was lost at some backmerge that I was unable to
identify. Put it back in.

Tested-by: Tomi Sarvela <tomix.p.sarvela@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bxt: Fix wrongly placed ')' in I915_READ()

Not the first time! not the last time?

There is a possibility to use gcc 5's -Wbool-compare to try and compare
(reg) in those macros to a constant and gcc will warn that the
comparison between a boolean expression and a constant is always either
true or false. Maybe.

Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Don't leak VBT mode data

We allocate memory for LVDS modes while parsing the VBT at startup, but
never free this memory when the driver is unloaded, causing a small
leak.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: cleanup pipe_update trace functions with new crtc debug info v3

Use the new debug info in the intel_crtc struct in these functions
rather than passing them as args.

v2: move min/max assignment back above first trace call (Ville)
    use scanline from crtc->debug rather than fetching a new one (Ville)
v3: fix up trace_i915_pipe_update_end, needs end scanline (Ville)

Requested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: add more debug info for when atomic updates fail v3

I used these additional fields to track down the issue I saw on HSW.

v2: move debug fields into a substruct (Ville)
v3: clean up debug code more (Ville)

References: https://bugs.freedesktop.org/show_bug.cgi?id=91579
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: fix kernel-doc warnings in i915_gem.c

Fix the following 'make htmldocs' warnings:

  .//drivers/gpu/drm/i915/i915_gem.c:1729: warning: No description found for parameter 'vma'
  .//drivers/gpu/drm/i915/i915_gem.c:1729: warning: No description found for parameter 'vmf'

  .//drivers/gpu/drm/i915/i915_gem.c:4962: warning: No description found for parameter 'old'
  .//drivers/gpu/drm/i915/i915_gem.c:4962: warning: No description found for parameter 'new'
  .//drivers/gpu/drm/i915/i915_gem.c:4962: warning: No description found for parameter 'frontbuffer_bits'

Signed-off-by: Geliang Tang <geliangtang@163.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Fix fb object's frontbuffer-bits

Shared frontbuffer bits are causing warnings when same FB is displayed
in another plane without clearing the bits from previous plane.

v2: Removing coversion of fb bits to 64 bit as it is not needed for now. (Daniel)

Change-Id: Ic2df80747f314b82afd22f8326297c57d1e652c6
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Kumar, Mahesh <mahesh1.kumar@intel.com>
[danvet: Drop INTEL_FRONTBUFFER_SPRITE_MASK since unused.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/gen9: WA ST Unit Power Optimization Disable

WaDisableSTUnitPowerOptimization:skl,bxt

Signed-off-by: Robert Beckett <robert.beckett@intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Set stolen reserved to 0 for pre-g4x platforms

This stolen reserved stuff was introduced on g4x, so no need to waste
stolen on older platforms. Unfortunately configdb is no more so I can't
look up the right way to detect this stuff. I do have one hint as to
where the register might be on ctg, but I don't have a ctg to test it,
and on the elk I have here it doesn't contain sensible looking data.
For ilk grits suggegsts it might be in the same place as on snb (the
original PCI reg, not the mirror) but I can't be entirely sure about it
The register shows a round zero on my ilk.

So when there's no really good data for any of these platforms leave the
current "assume 1MiB" approach in place.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix warnings while make xmldocs caused by intel_lrc.c

This patch fix following warnings while "make xmldocs".
.//drivers/gpu/drm/i915/intel_lrc.c:780: warning: No description
found for parameter 'req'
.//drivers/gpu/drm/i915/intel_lrc.c:780: warning: Excess function
 parameter 'request' description in 'intel_logical_ring_begin'
.//drivers/gpu/drm/i915/intel_lrc.c:780: warning: Excess function
 parameter 'ctx' description in 'intel_logical_ring_begin'

Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Split alloc from init for lrc

Extend init/init_hw split to context init.
   - Move context initialisation in to i915_gem_init_hw
   - Move one off initialisation for render ring to
        i915_gem_validate_context
   - Move default context initialisation to logical_ring_init

Rename intel_lr_context_deferred_create to
intel_lr_context_deferred_alloc, to reflect reduced functionality &
alloc/init split.

This patch is intended to split out the allocation of resources &
initialisation to allow easier reuse of code for resume/gpu reset.

v2: Removed function ptr wrapping of do_switch_context (Daniel Vetter)
    Left ->init_context int intel_lr_context_deferred_alloc
    (Daniel Vetter)
    Remove unnecessary init flag & ring type test. (Daniel Vetter)
    Improve commit message (Daniel Vetter)
v3: On init/reinit, set the hw next sequence number to the sw next
    sequence number. This is set to 1 at driver load time. This prevents
    the seqno being reset on reinit (Chris Wilson)
v4: Set seqno back to ~0 - 0x1000 at start-of-day, and increment by 0x100
    on reset.
    This makes it obvious which bbs are which after a reset. (David Gordon
    & John Harrison)
    Rebase.
v5: Rebase. Fixed rebase breakage. Put context pinning in separate
    function. Removed code churn. (Thomas Daniel)
v6: Cleanup up issues introduced in v2 & v5 (Thomas Daniel)

Issue: VIZ-4798
Signed-off-by: Nick Hoath <nicholas.hoath@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: John Harrison <john.c.harrison@intel.com>
Cc: David Gordon <david.s.gordon@intel.com>
Cc: Thomas Daniel <thomas.daniel@intel.com>
Reviewed-by: Thomas Daniel <thomas.daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't try to load GuC fw on pre-gen9

This avoids some bad register writes and generally feels more correct
than unconditionally trying to redirect interrupts and such.

References: https://bugs.freedesktop.org/show_bug.cgi?id=91777
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: make CSR firmware messages less verbose

Use WARN_ONCE in a bunch of places and demote a message that would
continually spam us.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/gen9: Add WaDisableMinuteIaClockGating

Signed-off-by: Nick Hoath <nicholas.hoath@intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bxt: Add WaSetClckGatingDisableMedia

Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/gen9: Add WaDisableSamplerPowerBypassForSOPingPong

Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bxt: Use intel_encoder->hpd_pin to check live status

Using intel_encoder's hpd_pin to check the live status
because of BXT A0/A1 WA for HPD pins and hpd_pin contains the
updated pin for the corresponding port.

Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/lrc: Prevent preemption when lite-restore is disabled

When WaEnableForceRestoreInCtxtDescForVCS is required, it is only
safe to send new contexts if the last reported event is "active to
idle". Otherwise the same context can fully preempt itself because
lite-restore is disabled.

Testcase: igt/gem_concurrent_blit
Reported-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Tested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: WaEnableForceRestoreInCtxtDescForVCS is for video engines only

Also check for correct revision id in each Gen9 platform (SKL until B0
and BXT until A0).

Cc: Nick Hoath <nicholas.hoath@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Tested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: skip modeset if compatible for everyone.

This is done as a separate commit, to make it easier to revert
when things break.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Make updating pipe without modeset atomic.

Instead of doing a hack during primary plane commit the state
is updated during atomic evasion. It handles differences in
pipe size and the panel fitter.

This is continuing on top of Daniel's work to make faster
modesets atomic, and not yet enabled by default.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet:
- simplify/future-proof if ladder that Jesse spotted
- resolve conflict in pipe_config_check and don't spuriously move the
  code.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Always try to inherit the initial fb.

The initial state is read out correctly and the state is atomic,
so it's safe to preserve the fb without any hacks if it's suitable.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove references to crtc->active from intel_fbdev.c

It should really use the atomic state.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Set csc coefficients in update_pipe_size.

This might not have been set during boot, and when we preserve
the initial mode this can result in a black screen.

Cc: Daniel Stone <daniels@collabora.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Update DRIVER_DATE to 20150911

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

drm/i915: Remove one very outdated comment

Comment disagrees with the code which has changed a lot since
it was documented.

Note that the logic to remove -EIO handling was dropped in

commit 1488fc08c1706288616c602416654fd38c773deb
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Apr 24 15:47:31 2012 +0100

    drm/i915: Remove the deferred-free list

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use crtc->state for duplication.

In async mode crtc->config can be updated after the locks are released,
resulting in the wrong state being duplicated.

Note that this also removes a spurious assignment of crtc_state->crtc
introduced in

commit f0c60574eb1216b0904c0d696c64d5096d6e4913
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date:   Tue Apr 21 17:12:58 2015 +0300

    drm/i915: Call drm helpers when duplicating crtc and plane states

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Do not handle a null plane state.

With the conversion to atomic this cannot happen any more.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove legacy plane updates for cursor and sprite planes.

Unfortunately fbc still depends on legacy primary state, so
it can't be killed off completely yet.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use atomic state when changing cursor visibility.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use the atomic state in intel_update_primary_planes.

This function was still using the legacy state, convert it to atomic.
While we're at it, fix the FIXME too and disable the primary plane.

v2 (Daniel):
- Add FIXME explaining that update_primary_planes should soon get
  removed anyway.
- Don't call ->disable_plane since we can't disable the primary plane
  with a CS flip (noticed by Ville).

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use the plane state in intel_crtc_info.

Legacy state might not be updated any more.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use atomic plane state in the primary plane update.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add attached connector to hdmi container

This patch adds the intel_connector initialized to intel_hdmi
display, during the init phase, just like the other encoders do.
This attachment is very useful when we need to extract the connector
pointer during the hotplug handler function

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't hard code vlv backlight frequency if unset

Fall back to VBT based backlight modulation frequency if it's not
set. Do not hard code.

This could be a problem if there is no VBT.

Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: initialize backlight max from VBT

Normally we determine the backlight PWM modulation frequency (which we
also use as backlight max value) from the backlight registers at module
load time, expecting the registers have been initialized by the BIOS. If
this is not the case, we fail.

The VBT contains the backlight modulation frequency in Hz. Add platform
specific functions to convert the frequency in Hz to backlight PWM
modulation frequency, and use them to initialize the backlight when the
registers are not initialized by the BIOS.

v2: Fix SPT and VLV. Thanks to Clint for the VLV code.

Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use pch backlight override on hsw too

Currently the difference between backlight control on HSW vs. BDW/SKL is
that on HSW we modify the duty cycle on the CPU register, and have the
hardware pass the changes on to the PCH registers. We still drive the
PCH PWM on both. While HSW and BDW use the same LPT PCH, BDW does not
pass these messages on to the PCH. Therefore on BDW we need to enable
the PCH override bit, and program the PCH directly. (On SPT PCH, this
mode is the default.) We could as well do this on HSW too, and in fact
I've been told this is what a certain other operating system does. So
use PCH backlight override on HSW too.

This simplifies some follow-up code, but it does have the danger of
breaking backlight on HSW machines. It should work, but mysterious are
the ways of backlight.

While at it, name the related backlight hooks according to the PCH
rather than the CPU for clarity.

Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bxt: Clean up bxt_init_clock_gating

Add stepping check for A0 workarounds, and remove the associated
FIXME tags.
Split out unrelated WAs for later condition checking.

v2: Fixed format (PeterL)
v3: Corrected stepping check for WaDisableSDEUnitClockGating
    - Ignoring comment, following hardware spec instead. (ChrisH)
    Added description for TILECTL setting (JonB)

Cc: Peter Lawthers <peter.lawthers@intel.com>
Cc: Chris Harris <chris.harris@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Nick Hoath <nicholas.hoath@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix cmdparser STORE/LOAD command descriptors

Fixes regression from
commit f1afe24f0e736b9d7f2275e2b1504af3fe612f2a
Author: Arun Siluvery <arun.siluvery@linux.intel.com>
Date:   Tue Aug 4 16:22:20 2015 +0100

    drm/i915: Change SRM, LRM instructions to use correct length

which forgot to account for the length bias when declaring the fixed
length.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91844
Reported-by: Andreas Reis <andreas.reis@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Dump pfit state as hex

The pfit state is stored as register values, so dump them as hex instead
of decimal to make some sense of the error messages.

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

drm/i915: access the PP_ON_DELAYS/PP_OFF_DELAYS regs only pre GEN5

These registers exist only before GEN5, so currently we may access
undefined registers on VLV/CHV and BXT. Apply the workaround only pre
GEN5.

Since the workaround is relevant only when LVDS is present, for clarity
apply it only if this is the case.

This triggered an unclaimed register access warning on BXT.

v2: (Ville)
- move the workaround to the LVDS init code
- print a debug note about the workaround

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

drm/i915: access the PP_CONTROL reg only pre GEN5

This register exists only pre GEN5, but atm we also access it on
VLV/BXT/CHV. Prevent accessing it on these latter platforms.

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

drm/i915: Refactor common ringbuffer allocation code

A small, very small, step to sharing the duplicate code between
execlists and legacy submission engines, starting with the ringbuffer
allocation code.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use the yesno helper for logging

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

drm/i915: ignore link rate in TPS3 selection

TPS3 is mandatory for downstream devices that support HBR2, and Intel
platforms that support HBR2 also support TPS3. Whenever TPS3 is
supported by both the source and sink, it should be used. In other
words, whenever the source and sink are capable of 5.4 Gbps link, we
should anyway go for TPS3, regardless of the link rate being selected.

Log an error if the sink has advertized HBR2 capability without TPS3
capability.

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

drm/i915/dp: move TPS3 logic to where it's used

There is no need to have a separate flag for tps3 as the information is
only used at one location. Move the logic there to make it easier to
follow.

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

drm/i915: Future proof panel fitter.

This is another case where we can consider the default is the
newest available and not actually a missed case.

No functional change.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Future proof uncore_init.

Unless future specs tells otherwise we can assume future gens
inherit some stuff from the previous so let's handle
missed cases when we know tehy should't be there and assume
default equals newest one.

No functional changes.

v2: Remove useless case as pointed out by Ville.

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

drm/i915: Future proof interrupt handler.

These functions are already being called for gen >= 9,
so let's be sure when this happens we use whatever is
there already for the latest platform.

No functional change.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/gtt: Avoid calling kcalloc in a loop when allocating temp bitmaps

On each call to gen8_alloc_va_range_3lvl we're allocating temporary
bitmaps needed for error handling. Unfortunately, when we increase
address space size (48b ppgtt) we do additional (512 - 4) calls to
kcalloc, increasing latency between exec and actual start of execution
on the GPU. Let's just do a single kcalloc, we can also drop the size
from free_gen8_temp_bitmaps since it's no longer used.

v2: Use GFP_TEMPORARY to make the allocations reclaimable.
v3: Drop the 2D array, just allocate a single block.
v4: Rebase to handle gen8_preallocate_top_level_pdps.
v5: Align misaligned bracket.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Correct kcalloc arguments as suggested by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/skl+: Add YUV pixel format in Capability list

GEN >= 9 supports YUV format for all planes, but it's not exported in
Capability list of primary plane. Add YUV formats in skl_primary_formats
list.

Testcase: igt/kms_universal_plane.c

Signed-off-by: Kumar, Mahesh <mahesh1.kumar@intel.com>
Cc: Konduru, Chandra <chandra.konduru@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/skl: Avoid using un-initialized bits_per_pixel

Don't rely on fb->bits_per_pixel as intel_framebuffer_init is not
filling bits_per_pixel field of fb-struct for YUV pixel format.
This leads to divide by zero error during watermark calculation.

Signed-off-by: Kumar, Mahesh <mahesh1.kumar@intel.com>
Cc: Konduru, Chandra <chandra.konduru@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't call intel_get_hpd_pins() when there's no hotplug interrupt

On GMCH plaforms we are now getting the following spew on aux
interrupts:
[drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000
[drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000
[drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000
[drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000
[drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000
[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x71450064

Prevent it by not calling intel_get_hpd_pins() unless one of the HPD
interrupt bits are actually set.

I already fixed similar annoyance once with
4bca26d0a6518d51a9abe64fbde4b12f04c74053 drm/i915: Use HOTPLUG_INT_STATUS_G4X on VLV/CHV

but another source for it got added in
fd63e2a972c670887e5e8a08440111d3812c0996 drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins

due to pch_get_hpd_pins() being chosen over i9xx_get_hpd_pins() to
serve as the new unified piece of code. pch_get_hpd_pins() had the debug
print, and i9xx_get_hpd_pins() didn't.

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

drm/i915: Rewrite BXT HPD code to conform to pre-existing style

Rewrite the BXT hpd setup to match the way we do it on other platforms:
- Throw out BXT_HOTPLUG_CTL since it's the same as PCH_PORT_HOTPLUG
- Enable the HPD bits in the DE port IER in gen8_de_irq_postinstall()
- Update DE port IMR using bdw_update_port_irq()

Also throw out port D from bxt_port_hotplug_long_detect() since BXT only
goes up to C.

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

drm/i915: Refactor the hpd irq handling functions

A lot of the hpd irq handling is duplicated code, so refactor it a bit
by observing that in several places the only difference is the hpd[]
array. So pull the code to a few functions and pass in the hpd[] array
from the caller. Another option would be to determine the correct array
to use within the functions themselves, but somehow passing it in felt
nicer.

Further code reduction could be achieved by passing in the hotplug
register offset, and the long pulse detection function pointer. But that
didn't feel as good for some reason, so I left it at the middle ground.

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

drm/i915: Rewrite bxt_hpd_handler() to look like everyone else

bxt_hpd_handler() looks different to everyone else for no good reason.
Rewrite it to use the standard variable namees etc.

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

drm/i915: Reinitialize HPD after runtime D3

Runtime suspends disabled all interrupts, so in order to get them back
fully we need to also do the HPD irq setup on runtime resume. Except
on VLV/CHV where the display interrupt initialization is part of the
display power well powerup.

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

drm/i915: Add port A HPD support for SPT

On SKL the port A HPD has moved to the PCH. Hook it up.

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

drm/i915: Add port A HPD support for BDW

Wire up the port A HPD for BDW. Compared to earlier platforms the
interrupt setup is a bit different, but basically everything else
looks the same.

v2: 0 initialize pin_mask/long_mask due to intel_get_hpd_pins() changes
    Check for BDW before processing the HPD to not break BXT
    Set found=true when processing port A HPD
    Sort out the mess I made of the irq setup in v1
    Warn about bad irq mask vs. enable bits in bdw_update_port_irq()  (Paulo)

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