There is currently conflicting documentation on which steppings the
workaround is needed, up to C vs. forever. However there is post-C
stepping hardware that doesn't report port presence on DDI A, leading to
black screen on eDP. Assume the strap isn't connected, and try to enable
DDI A on these machines. (We'll still check the VBT for the info in DDI
init.)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Mika Westerberg <mika.westerberg@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

DP spec requires the checksum of the last block read to be written
when replying to TEST_EDID_READ. This patch fixes the current code
to do the same.

v2: removed loop for jumping blocks and performed direct addition
as recommended by Daniel
Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Reviewed-by: NSonika Jindal <sonika.jindal@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Prevent leaking the if scoping by containing the WA_REG
macro inside its own scope.
Reported-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NDave Gordon <david.s.gordon@intel.com>
[danvet: Appease checkpatch.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If we encounter an allocation failure during ppggt creation (trivial
even with 16Gib+ RAM!), we need to remove the dead context from the
fpriv->context_idr along with the references.

gem_exec_ctx: page allocation failure: order:0, mode:0x8004
CPU: 3 PID: 27272 Comm: gem_exec_ctx Tainted: G        W       4.2.0-rc5+ #37
 0000000000000000 ffff880086ff7a78 ffffffff816b947a ffff88041ed90038
 0000000000008004 ffff880086ff7b08 ffffffff8114b1a5 ffff880086ff7ac8
 ffffffff8108d848 0000000000000000 ffffffff81ce84b8 0000000000000000
Call Trace:
 [<ffffffff816b947a>] dump_stack+0x45/0x57
 [<ffffffff8114b1a5>] warn_alloc_failed+0xd5/0x120
 [<ffffffff8108d848>] ? __wake_up+0x48/0x60
 [<ffffffff8114e0ed>] __alloc_pages_nodemask+0x73d/0x8e0
 [<ffffffffc0472238>] ? i915_gem_execbuffer2+0x148/0x240 [i915]
 [<ffffffffc0474240>] __setup_page_dma+0x30/0x110 [i915]
 [<ffffffffc0477f61>] gen8_ppgtt_init+0x31/0x2f0 [i915]
 [<ffffffffc04785e0>] i915_ppgtt_init+0x30/0x80 [i915]
 [<ffffffffc0478928>] i915_ppgtt_create+0x48/0xc0 [i915]
 [<ffffffffc046c9c2>] i915_gem_create_context+0x1c2/0x390 [i915]
 [<ffffffffc046d9cb>] i915_gem_context_create_ioctl+0x5b/0xa0 [i915]

leading to an oops in i915_gem_context_close. Also note that this
benchmark should not be running out of memory in the first place...

Testcase: igt/benchmark/gem_exec_ctx -b create # ppgtt >= 2
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The IOMMU for Intel graphics has historically had many issues resulting
in random GPU hangs. Lets include its status when capturing the GPU hang
error state for post-mortem analysis.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If idle to active bit is set, the rest of the fields
in CSQ are not valid.

Bail out early if this is the case in order to prevent
rest of the loop inspecting stale values.

This was found by Bspec/code inspection. Doesn't seem to fix any of
the known issues.
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NArun Siluvery <arun.siluvery@linux.intel.com>
[danvet: Add note about how this was found.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There is no correspondent Aux channel for DDI-E.

So we need to rely on VBT to let us know witch one
is being used instead.

v2: Removing some trailing spaces and giving proper
credit to Xiong that added a nice way to avoid port
conflicts by setting supports_dp = 0 when using
equivalent aux for DDI-E.

Credits-to: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NXiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

DDI-E and DDI-A share 4 the same DDI-A lanes.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NXiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I started digging this when I noticed that the BDW code was just
reserving 1mb by coincidence since it was reading reserved fields.
Then I noticed we didn't have any values set for SNB and earlier, and
that the HSW sizes were wrong. After that, I noticed that the reserved
area has a specific start, and may not exactly end where the stolen
memory ends. I also noticed the base pointer can be zero. So I decided
to just write a single patch fixing everything instead of 20 patches
that would be much harder to review.

This patch may solve random stolen memory corruption/problems on
almost all platforms. Notice that since this is always dealing with
the top of the stolen memory, the problems are not so easy to
reproduce - especially since FBC is still disabled by default.

One of the major differences of this patch is that we now look at both
the size and base address. By only looking at the size we were
assuming that the reserved area was always at the very top of
stolen, which is not always true.

After we merge the patch series that allows user space to allocate
stolen memory we'll be able to write IGT tests that maybe catch the
bugs fixed by this patch.

v2:
  - s/BIOS reserved/stolen reserved/g (Chris)
  - Don't DRM_ERROR if we can't do anything about it (Chris)
  - Improve debug messages (Chris).
  - Use the gen7 version instead of gen6 on HSW. Tom found some
    documentation problems, so I think with gen7 we're on the safer
    side (Tom).
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>

This register needs to be updated with masked writes.

This was found by code inspection and comparison with Bspec and
doesn't seem to fix any known issue.
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
[danvet: Add note about impact.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add WaDisableSbeCacheDispatchPortSharing:skl

Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If we encounter frequent problems with dp aux channel
communications, we end up spamming the dmesg with the
exact similar trace and status.

Inject a new backtrace only if we have new information
to share as otherwise we flush out all other important
stuff.
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

-EDEADLK has special meaning in atomic, but get_fence may call
i915_find_fence_reg which can return -EDEADLK.

This has special meaning in the atomic world, so convert the error
to -EBUSY for this case.

Changes since v1:
- Add comment in the code.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The rest will be a noop anyway, since without modeset there will be
no updated dplls and no modeset state to update.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There are no more users, byebye!
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that everything's atomic, checking encoder->base.crtc is enough.
This function doesn't have the locks to dereference crtc->state, but
stealing an encoder bound to any crtc is probably enough reason to warn.

Changes since v1:
- Commit message.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

connectors_active will be removed, so just calculate this instead.

Changes since v1:
- Look for the right pointer in intel_sanitize_encoder.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is now done completely atomically.
Keep connectors_active for now, but make it mirror crtc_state->active.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Instead of allocating pipe_config on the stack use the old
crtc_state, it's only going to freed from this point on.

All crtc' are now only checked once during modeset,
because false positives can happen with encoders after
dpms changes and to limit the amount of errors for 1 failure.

Changes since v1:
- crtc_state -> old_crtc_state
- state -> old_state
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Connectors are updated atomically now, so the only interaction
with the encoder is through base.crtc.

If it's NULL the encoder's not part of any crtc, and if it's
not NULL then active should be equal to crtc_state->active.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is handled by the atomic core now, no need to check this for ourself.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Right now dpms callbacks can still fiddle with the connector state,
but it can only turn connectors off.

This is remediated by only checking crtc->state->active when the
connector is active, and ignore crtc->state->active when the
connector is off.

connectors_active is no longer checked, and will be removed later
in this series together with dpms.

Another check for !encoder->crtc is performed by check_encoder_state
too, so it can be removed.

Changes since v1:
- Add commit message.
- rename state to old_state.
- Move deletion of mst_port check to mst patch.
Changes since v2:
- Fix a null pointer dereference on MST now hw readout is fixed.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Fully remove the MST connector from the atomic state, and remove the
early returns in check_*_state for MST connectors.

With atomic the state can be made consistent all the time.

Thanks to Sivakumar Thulasimani for the idea of using
drm_atomic_helper_set_config.

Changes since v1:
- Remove the MST check in intel_connector_check_state too.
Changes since v2:
- Use drm_atomic_helper_set_config.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

First step in removing dpms and validating atomic state.

There can still be a mismatch in the connector state because the dpms
callbacks are still used, but this can not happen immediately after a modeset.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Set connectors_changed to force a modeset if the panel fitter's force
enabled on eDP.

Changes since v1:
- Use connectors_changed instead of active_changed because it's a
  routing update.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need a few core drm patches to be able to merge Maarten's series to
convert DPMS over to atomic.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Looks like

commit eddfcbcd
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Mon Jun 15 12:33:53 2015 +0200
    drm/i915: Update less state during modeset.

introduced the unconditional calling of disable_shared_dpll, but didn't
fix up pre-gen5 to avoid the BUG_ON at the top of the function.

So change the BUG_ON into a gen check (alternately we could move the
BUG_ON until later, since we shouldn't have a pll struct here either,
but this seems clearer to read).

This fixes a crash on load on my x200s platform.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Tested-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90854Tested-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch contains the changes to remove the byte
swapping logic introduced with old dmc firmware.
While debugging PC10 entry issue for skylake found
with latest dmc firmware version 1.18 without byte
swapping dmc is working fine and able to enter PC10.

Note that apparently this was changed with dmc version 1.0 and earlier
ones indeed are byteswapped like this ...

v1: Initial version.

v2: Corrected firmware size during memcpy(). (Suggested by Sunil)

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: Add note that this only holds for released dmc firmware.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

BPP bits defined in VBT should be used only on panels whose
edid version is 1.3 or older. EDID version 1.4 introduced offsets
where bpp is defined and read into display_info, hence bpp from
VBT will be used only when bpc in display_info is zero.

v2: use display_info.bpc for deciding when to use vbt_bpp (Jani)
Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I was told that the "repurposed D1 definition" is still valid for SKL.
It is BDW that is special due to its hotplug bug, so let's
special-case BDW instead of HSW.

Cc: Kristen Carlson Accardi <kristen@linux.intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Similar to the ->enable vfunc in patch "drm/i915: Extract a
intel_power_well_enable() function".

v2 (from Paulo):
  - Same s/i915_/intel_/ bikeshed as the previous patch.
  - Update the commit hash.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need a bit book keeping around power wells' ops->enable(), namely a
nice debug message and updating hw_enabled. Let's introduce a
intel_power_well_enable() function to make sure all the callers do the
same things.

v2 (from Paulo):
  - s/i915_power_well_enable/intel_power_well_enable/ since everything
    else on this file uses intel_ instead of i915_.
  - Fix typo in commit message.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With this simple git diff command one can see that skl_init_workarounds()
got two copies of WaBarrierPerformanceFixDisable:skl:

 git diff -U21 ca6e4405^1 ca6e4405 drivers/gpu/drm/i915/intel_ringbuffer.c

This happened when the backmerge of drm-intel-fixes-2015-07-15
Merged the same fix on both sides. Same fix but not identical enough for
git: with a different surrounding context; hence the code duplication.

This commit merely reverts the output of the git command above
 = the duplication introduced in the backmerge.

(This duplication was found while running git sanity checks on a
_linearized_ i915 forklift for ChromeOS.)
Signed-off-by: NMarc Herbert <marc.herbert@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since active function on VLV immediately activate PSR let's give more
time for idleness. Different from core platforms where we have idle_frames
count.

Also kms_psr_sink_crc now is automated and always get this:

[drm:intel_enable_pipe] enabling pipe A
[drm:intel_edp_backlight_on]
[drm:intel_panel_enable_backlight] pipe
[drm:intel_panel_enable_backlight] pipe A
[drm:intel_panel_actually_set_backlight] set backlight PWM = 7812

PSR gets enabled somewhere here after backlight.

[drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x0
[drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511
[drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, cursor=63, sp

PSR gets flushed around here by intel_atomic_commit

[drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511
[drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, cursor=63, sp
[drm:intel_set_memory_cxsr] memory self-refresh is enabled
[drm:intel_connector_check_state] [CONNECTOR:39:eDP-1]
[drm:check_encoder_state] [ENCODER:30:DAC-30]
[drm:check_encoder_state] [ENCODER:31:TMDS-31]
[drm:check_encoder_state] [ENCODER:36:TMDS-36]
[drm:check_encoder_state] [ENCODER:38:TMDS-38]
[drm:check_crtc_state] [CRTC:21]
[drm:check_crtc_state] [CRTC:26]
[drm:intel_psr_activate [i915]] *ERROR* PSR Active
[drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x
[drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO
Underrun.

It is true that in a product we won't keep disabling and enabling planes so
frequently, but for safeness let's stay conservative.

It is also true that 500ms is an etternity. But PSR is anyway a power saving
feature for idle scenario. So if it is idle feature stays on and 500ms to get
it reanabled is not that insane.

v2: Rebase over intel_psr.c and fix typo.
v3: Revival: Manual tests indicated that this is needed. With a short delay
    there is a huge risk of getting blank screens when planes are being enabled.
v4: Revival 2 with reasonable delay. 1/2 sec instead of 5. VBT is 10 sec but
    actually time for link training what we aren't doing, but with only 100 sec
    in some cases kms_psr_sink_crc manual was showing blank screen,
    so let's use this for now. Also changed comment by a FIXME.
v5: Rebase after a long time, remove FIXME and update comment above.
v6: msecs_to_jiffies is already on delay. remove duplication.
v7: use msecs_to_jiffies on schedule_delayed_work call.

Reviewed-by: Durgadoss R <durgadoss.r@intel.com> (v4)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is just a preparation patch to make clear what operation we
are performing. There is no functional change on the sink crc
logic.

hsw_disable_ips has been moved a bit further in the start function
to avoid disabling ips when sink crc is not going to be started.
and to avoid goto on this function.

v2: explain why hsw_disable_ips() call place has changed.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NRafael Antognolli <rafael.antognolli@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

First, an introduction. We currently have two types of GTT mmaps: the
"normal" old mmap, and the WC mmap. For frontbuffer-related features
that have automatic hardware tracking, only the non-WC mmap writes are
detected by the hardware. Since inside the Kernel both are treated as
ORIGIN_GTT, any features ignoring ORIGIN_GTT because of the hardware
tracking are destined to fail.

One of the special rules defined for the WC mmaps is that the user
should call the dirtyfb IOCTL after he is done using the pointers, so
that results in an intel_fb_obj_flush() call. The problem is that the
dirtyfb is passing ORIGIN_GTT, so it is being ignored by FBC - even
though the hardware tracking is not detecing the WC mmap operations.
So in order to fix that without having to give up the automatic
hardware tracking for GTT mmaps we transform the flush operation from
dirtyfb into a special operation: ORIGIN_DIRTYFB.

This commit fixes all the kms_frontbuffer_tracking subtests that
contain "fbc" and "mmap-wc" in their names and are currently failing
(for a total of 16 subtests).
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use the appropriate call.

I know there's a discussion about whether we need this call here at
all, but removing the call means we'll only update FBC after we get
the page flip IRQ. So the user may only see the new frame a little
after it should. Let's wait just a little bit more before removing
this call since we can rely in the HW tracking for accurate flips.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Because intel_unpin_work_fn() already calls
intel_frontbuffer_flip_complete() which will call intel_fbc_flush()
which will call intel_fbc_update() when needed.

We couldn't fix this previously due to the fact that FBC was not
properly behaving as intended on frontbuffer flushes, but now that
this is fixed, we can remove the additional call.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Due to the way busy_bits was handled, we were not doing any flushes if
we didn't previously get an invalidate. Since it's possible to get
flushes without an invalidate first, remove the busy_bits early
return.

So now that we don't have the busy_bits guard anymore we'll need the
origin check for the GTT tracking (we were not doing anything on GTT
flushes due to the GTT check at invalidate()).

As a last detail, since we can get multiple consecutive flushes,
disable FBC before updating it, otherwise intel_fbc_update() will just
keep FBC enabled instead of restarting it.

Notice that this does not fix any of the current IGT tests due to the
fact that we still have a few intel_fbc() calls at points where we
also have the frontbuffer tracking calls: we didn't fully convert to
frontbuffer tracking yet. Once we remove those calls and start relying
only on the frontbuffer tracking infrastructure we'll need this patch.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>