We already check if the CRTC is visible, and it shouldn't be possible
to have a visible CRTC without an FB.

This was noticed by both Chris and Ville on different ocasions.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-4-git-send-email-paulo.r.zanoni@intel.comSigned-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Make the code easier to read.
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-3-git-send-email-paulo.r.zanoni@intel.comSigned-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Although the term "nuke" is part of the FBC spec, it's not very
intuitive, so let's rename it to make it easier for people that are
not familiar with the spec.
Requested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-2-git-send-email-paulo.r.zanoni@intel.comSigned-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Newlines are not needed and they're not used by the other messages. I
added the newline by mistake.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-14-git-send-email-paulo.r.zanoni@intel.comSigned-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

The bspec indicates that DDI A using four lanes is the only valid
configuration for Broxton (Broxton doesn't have a DDI E to split these
lanes with); the DDI_A_4_LANES bit of port A's DDI_BUF_CTL should always
be set by the BIOS.  However some BIOS versions seem to only be setting
this bit if eDP is actually lit up at boot time; if the BIOS doesn't
turn on the eDP panel because an external display is plugged in, then
this bit is never properly initialized.  The end result of this is that
we wind up calculating a lower max data rate than we should and may wind
up rejecting the native mode for panels that we should be able to drive.

Let's workaround this BIOS bug by just turning the DDI_A_4_LANES bit on
in our driver's internal state if we recognize that we're running on BXT
where it should have been on anyway.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NBob Paauwe <bob.j.paauwe@intel.com>
Tested-by: NBob Paauwe <bob.j.paauwe@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446764012-27251-1-git-send-email-matthew.d.roper@intel.com

Currently there's no trace in dmesg when the gen2/3 dotclock checks
reject the modeset. Add some to avoid further head scratching.

While at it refactor the code a bit to look nicer.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446241178-432-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>

VMA offsets are 64 bits. Plane surface offsets are in ggtt and
the hardware register to set this is thus 32 bits. Be explicit
about these and convert carefully to from vma to final size.

This will make sparse happy by not creating 32bit pointers out
of 64bit vma offsets.

Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446204375-29831-1-git-send-email-mika.kuoppala@intel.comReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

We have had one case where buggy csr/dmc firmware version influenced
gt side and caused a hang. Add dmc firmware loading state and
version to error state.

v2: - Rebased on top of Damien's patches
    - included fw load state
v3: include dmc info only if platform supports it (Chris)
v4: move *csr to branch scope (Chris)
v5: remove dependency to csr_state

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v4)
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446124879-22240-1-git-send-email-mika.kuoppala@intel.com
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

We check these to determine firmware loading status. Include
them to help to debug causes of firmware loading fails.

v2: Move all CSR specific registers to i915_reg.h (Ville)
v3: Rebase
v4: Rebase (RPM ref)
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446220487-32691-1-git-send-email-mika.kuoppala@intel.com
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

For bxt CSR firmware exposes a count of dc5 entries. Expose
it through debugs
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

The CSR firmware expose two counters, handy to check if we are indeed
entering DC5/DC6.

v2: Rebase
v3: Take RPM ref before reading (Imre)
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v1)
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446220412-32574-1-git-send-email-mika.kuoppala@intel.com
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Create a new debufs file for it, we'll have a few more things to add
there.

v2: Fix checkpatch warning about static const array
v3: use named initializers (Ville)
v4: strip out csr_state as it will be removed in future (Ville, Imre)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v1)
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445950025-5793-3-git-send-email-mika.kuoppala@intel.comReviewed-by: NImre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

There is known issue on GT interrupt delivery with DC6 and
firmwares <1.21. There is a suspicion that this causes
spurious gpu hangs on driver init and with some workloads,
as upgrading the firmware to 1.21 makes these problems
disappear.

As of now the current version included in distribution
firmware packages is very like to be 1.19. Play it safe and
refuse to load a firmware version that may affect gpu
side stability.

With < 1.23 there is a palette and dmc ram corruption issue
so blacklist anything below that.

v2: Refuse to load fw instead of notifying the user
v3: Rebase on header version changes
v4: Refuse to load anything less than 1.23
v5: Give enough information for user for finding correct fw (Chris)
v6: better url and formatting (Chris)
v7: move error log for each fail path (Mika)
    bail out earlier in load path (Imre)
v8: Fix the version check (Imre)

Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
References: https://01.org/linuxgraphics/downloads/skldmcver121
References: https://01.org/linuxgraphics/downloads/skylake-dmc-1.23
Testcase: igt/gem_exec_nop
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446220336-32392-1-git-send-email-mika.kuoppala@intel.com
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

That can be handy later on to tell which DMC firmware version the user
has, by just looking at the dmesg.

v2: use DRM_DEBUG_DRIVER (Chris)
v3: use DRM_INFO (Marc Herbert)

Cc: Marc Herbert <marc.herbert@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v1)
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445950025-5793-1-git-send-email-mika.kuoppala@intel.comReviewed-by: NImre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

We had two failure modes here:

1.
Deadlock in intelfb_alloc failure path where it calls
drm_framebuffer_remove, which grabs the struct mutex and intelfb_create
(caller of intelfb_alloc) was already holding it.

2.
Deadlock in intelfb_create failure path where it calls
drm_framebuffer_unreference, which grabs the struct mutex and
intelfb_create was already holding it.

[Daniel Vetter on why struct_mutex needs to be locked in the second half
of intelfb_create: "The vma [for the fbdev] is pinned, the problem is
that we re-lookup it a few times, which is racy. We should instead track
the vma directly, but oh well we don't."]

v2:
   * Reformat commit msg to 72 chars. (Lukas Wunner)
   * Add third failure mode. (Lukas Wunner)

v5:
   * Rebase on drm-intel-nightly 2015y-09m-01d-09h-06m-08s UTC,
     rephrase commit message. (Jani Nicula)

v6:
   * In intelfb_alloc, if __intel_framebuffer_create failed,
     fb will be an ERR_PTR, thus not null. So in the failure
     path we need to check for IS_ERR_OR_NULL to avoid calling
     drm_framebuffer_remove on the ERR_PTR. (Lukas Wunner)
   * Since this is init code a drm_framebuffer_unreference should
     be all we need. drm_framebuffer_remove is for framebuffers
     that userspace has created - and is getting somewhat
     defeatured. (Daniel Vetter)

v7:
   * Clarify why struct_mutex needs to be locked in the second half
     of intelfb_create. (Daniel Vetter)

Fixes: 60a5ca01 ("drm/i915: Add locking around
    framebuffer_references--")
Reported-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
[Lukas: Create v3 + v4 + v5 + v6 + v7 based on Tvrtko's v2]
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/47d4e88c91b3bf0f7a280cabec54c8c8cf0cf6f2.1446892879.git.lukas@wunner.deSigned-off-by: NJani Nikula <jani.nikula@intel.com>

In intelfb_alloc(), if the call to intel_pin_and_fence_fb_obj() fails,
the bo is unrefed twice: By drm_framebuffer_remove() and once more by
drm_gem_object_unreference(). Fix it.
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/cd7b33330621a350b0159ec5e098297b139cfaf7.1446892879.git.lukas@wunner.deSigned-off-by: NJani Nikula <jani.nikula@intel.com>

Currently when allocating a framebuffer fails, the gem object gets
unrefed at the bottom of the call stack in __intel_framebuffer_create,
not where it gets refed, which is in intel_framebuffer_create_for_mode
(via i915_gem_alloc_object) and in intel_user_framebuffer_create
(via drm_gem_object_lookup).

This invites mistakes: __intel_framebuffer_create is also called from
intelfb_alloc, and as discovered by Tvrtko Ursulin, a double unref
was introduced there with a8bb6818 ("drm/i915: Fix error path leak
in fbdev fb allocation").

As suggested by Ville Syrjälä, fix the double unref and improve code
clarity by moving the unref away from __intel_framebuffer_create to
where the gem object gets refed.

Based on Tvrtko Ursulin's original v2.

v3: On fb alloc failure, unref gem object where it gets refed,
    fix double unref in separate commit (Ville Syrjälä)

v4: Lock struct_mutex on unref (Chris Wilson)

v5: Rebase on drm-intel-nightly 2015y-09m-01d-09h-06m-08s UTC,
    rephrase commit message (Jani Nicula)
Tested-by: NPierre Moreau <pierre.morrow@free.fr>
    [MBP  5,3 2009  nvidia MCP79 + G96        pre-retina]
Tested-by: NPaul Hordiienko <pvt.gord@gmail.com>
    [MBP  6,2 2010  intel ILK + nvidia GT216  pre-retina]
Tested-by: NWilliam Brown <william@blackhats.net.au>
    [MBP  8,2 2011  intel SNB + amd turks     pre-retina]
Tested-by: NLukas Wunner <lukas@wunner.de>
    [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina]
Tested-by: NBruno Bierbaumer <bruno@bierbaumer.net>
    [MBP 11,3 2013  intel HSW + nvidia GK107  retina]

Fixes: a8bb6818 ("drm/i915: Fix error path leak in fbdev fb
    allocation")
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/2161c5062ef5d6458f8ae14d924a26d4d1dba317.1446892879.git.lukas@wunner.deSigned-off-by: NJani Nikula <jani.nikula@intel.com>

The function name implies it should get intel_dp, and it mostly used
where there is an intel_dp in the context.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445594525-7174-8-git-send-email-ander.conselvan.de.oliveira@intel.com

In order to prepare for a link training with DDI, the state machine
would call intel_ddi_prepare_link_retrain(). To remove the dependency to
the hardware information, replace that direct call with a callback.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445594525-7174-7-git-send-email-ander.conselvan.de.oliveira@intel.com

No functional changes, just moving code around.

v2: Rebase
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445594525-7174-6-git-send-email-ander.conselvan.de.oliveira@intel.com

Move register write from intel_dp_update_link_train() into
intel_dp_set_signal_levels(). This creates a better split between the
i915 specific code and the generic link training part. Note that this
causes an extra register write in intel_dp_reset_link_train(), since
both intel_dp_set_signal_levels() and intel_dp_set_link_train() write
to the DP register.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445594525-7174-5-git-send-email-ander.conselvan.de.oliveira@intel.com

Move the call to intel_dp_get_adjust_train() out of
intel_dp_update_link_train() and call it instead from the clock recovery
and channel equalization features. A follow up patch will remove the DP
register write from that function, so that it handles only the DPCD
write.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445594525-7174-4-git-send-email-ander.conselvan.de.oliveira@intel.com

Split the register write with the new link training pattern out of
intel_dp_set_link_train(), so that the i915 specific code is in a
separate function.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445594525-7174-3-git-send-email-ander.conselvan.de.oliveira@intel.com

It just makes the code more confusing, so just reference intel_dp_>DP
directly.

Note that this also fix a bug where the value of intel_dp->DP could be
different than the last value written to the hw, due to an early return
that would skip the 'intel_dp->DP = DP' line.

v2: Don't preserve old DP value on failure. (Sivakumar)
  - Don't call drm_dp_clock_recovery_ok() twice. (Sivakumar)
  - Keep return type of clock recovery and channel equalization
    functions as void. (Ander)

v3: Remove DP parameter from intel_dp_set_signal_levels(). (Sivakumar)
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445594525-7174-2-git-send-email-ander.conselvan.de.oliveira@intel.com

SWF18 is set if the display has been initialized by the pre-os. It also
gives what configuration is enabled on which pipe. In skl_sanitize_cdclk,
the DPLL sanity check can pass even if GOP/VBIOS is not loaded as BIOS
enables DPLL for integrated audio codec related programming.
So fisrt check if SWF18 is set and then follow through with other DPLL
and CDCLK verification. If not set then for sure we need to sanitize the
cdclock.

v2: Update the commit message for clarity (Siva)
v3: Correct the mask to check for bits[23:0] instead of only bits[16:0].
    Had missed checking for PIPE C altogether. Remaining are reserved (Siva)
v4: Use ILK_SWF macro for SWF register definitions. Taken from Ville's patch
    http://lists.freedesktop.org/archives/intel-gfx/2015-November/079480.html

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446726932-14078-1-git-send-email-shobhit.kumar@intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>

BXT CRTC scaling uses the same gen9 codepaths as SKL; these codepaths
store panel fitter information in pipe_config->pch_pfit.  However since
HAS_PCH_SPLIT() is false for BXT we never actually wind up filling in
this structure (we wind up filling in pipe_config->gmch_pfit instead,
which is ignored when we go to program the hardware).  Make sure we
always take the PCH code path on gen9+ platforms.

v2: Use HAS_GMCH_DISPLAY() to more cleanly describe the platforms that
    actually want to use GMCH-style panel fitting.  (Ville)

Cc: Imre Deak <imre.deak@intel.com>
Cc: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446656727-3516-1-git-send-email-matthew.d.roper@intel.com

I wanted to add yet another check to intel_fbc_update() and realized
I would need to create yet another enum no_fbc_reason case. So I
remembered this patch series that Damien wrote a long time ago and
nobody ever reviewed, so I decided to reimplement it since the code
changed a lot since then.

Credits-to: Damien Lespiau <damien.lespiau@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445964628-30226-2-git-send-email-paulo.r.zanoni@intel.comSigned-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Make pinning and waiting a separate step, and wait for object idle
without struct_mutex held.

Changes since v1:
- Do not wait when a reset is in progress.
- Remove call to i915_gem_object_wait_rendering for
  intel_overlay_do_put_image (Chris Wilson)
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

struct_mutex is being locked for every plane in intel_prepare_plane_fb
and intel_cleanup_plane_fb.

Require the caller to hold the mutex, and only acquire the mutex for
each helper call. This way the lock only needs to be acquired
twice in ->atomic_commit(). Once for pinning new framebuffers at the
start, the second time for unpinning old framebuffer.

Changes since v1:
- Use mutex_lock_interruptible instead of i915 variant,
  to prevent a deadlock when called from the reset code.
Changes since v2:
- Clarify struct_mutex is locked by the caller.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com> #v1
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Move it from intel_crtc_atomic_commit to prepare_plane_fb.
Waiting is done before committing, otherwise it's too late
to undo the changes.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NAnder Conselvan De Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Extends i915_display_info so that for each active crtc also print
all planes associated with the pipe. This patch shows information
about each plane wrt format, size, position, rotation, and scaling.
This is very useful when debugging user space compositors that try
to utilize several planes for a commit.

V2: Fixed comments from Maarten, Ville, and Chris. Fixed printing of
16.16 fixpoint, better rotation bitmask management and some minor fixes

V3: Corrected state->src_x & 0x00ff to state->src_x & 0xffff...
Signed-off-by: NRobert Fekete <robert.fekete@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445961512-25317-1-git-send-email-robert.fekete@linux.intel.comSigned-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

One branch of the if clause uses pr_info, the other pr_err; change
the 'false' branch to also use pr_info. This minor oversight has gone
unfixed since the initial vga_switcheroo implementation in 6a9ee8af.
Signed-off-by: NIoan-Adrian Ratiu <adi@adirat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446246960-22620-1-git-send-email-adi@adirat.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>

Another CI fail we have for no reason. Totally unjustified since
nothing fails at all.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445590806-23886-1-git-send-email-daniel.vetter@ffwll.chAcked-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

DRM_ERROR an continue without any issues aren't allowed since that
causes noise in the CI system. But we absolutely want to have the
DRM_ERROR when we want to run with GuC.

For simplicity just short-circuit all the loader code when it's not
needed.

v2: Mika&Chris complained that I shouldn't hit send on patches written
before coffee kicks in.

v3: Make it compile at least ...

Cc: Alex Dai <yu.dai@intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445591459-4327-1-git-send-email-daniel.vetter@ffwll.chReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since A1 chips use the same GPU as A0, they need all the
same wa's in the i915 driver. Update some conditionals
to do this.
Signed-off-by: NTim Gore <tim.gore@intel.com>
Reviewed-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445856538-5417-1-git-send-email-tim.gore@intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>

v2: (Rodrigo) Rebase after commit 3cb27f38
    ("drm/i915: remove an extra level of indirection in PCI ID list")

Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDeepak S <deepak.s@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446060072-19489-1-git-send-email-rodrigo.vivi@intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>

v2: separate out device info into different GT (Damien)
v3: Add is_kabylake to the KBL gt3 structuer (Damien)
    Sort the platforms in older -> newer order (Damien)

v4: Split platform definition since is_skylake=1 on
    kabylake structure was Nacked. (Rodrigo)

v5: (Rodrigo) Rebase after commit 3cb27f38
("drm/i915: remove an extra level of indirection in PCI ID list")

Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDeepak S <deepak.s@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446059991-17033-1-git-send-email-rodrigo.vivi@intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>

Kabylake is a Intel® Processor containing Intel® HD Graphics
following Skylake.

It is Gen9p5, so it inherits everything from Skylake.

Let's start by adding the platform separated from Skylake
but reusing most of all features, functions etc. Later we
rebase the PCI-ID patch without is_skylake=1
so we don't replace what original Author did there.

Few IS_SKYLAKEs if statements are not being covered by this patch
on purpose:
   - Workarounds: Kabylake is derivated from Skylake H0 so no
     		  W/As apply here.
   - GuC: A following patch removes Kabylake support with an
     	  explanation: No firmware available yet.
   - DMC/CSR: Done in a separated patch since we need to be carefull
     	      and load the version for revision 7 since
	      Kabylake is Skylake H0.

v2: relative cleaner commit message and added the missed
    IS_KABYLAKE to intel_i2c.c as pointed out by Jani.

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Kabylake will also be defined as gen9 and !is_skylake.
So we need start by creating a proper Broxton
definition, otherwise we will break broxton with the
introduction of Kabylake.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445966099-1640-2-git-send-email-rodrigo.vivi@intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>

Add the PCI IDs directly in the pciidlist array instead of defining an
extra macro. The minor benefit from this is neater diffs when adding to
the end of the list.

v2: drop the "aka" comment (Ville)
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446053589-21283-1-git-send-email-jani.nikula@intel.com