Commit Graph

12323 Commits

Author SHA1 Message Date
Dave Airlie
ca09fb9f60 Linux 4.8-rc8
-----BEGIN PGP SIGNATURE-----
 
 iQEcBAABAgAGBQJX6H4uAAoJEHm+PkMAQRiG5sMH/3yzrMiUCSokdS+cvY+jgKAG
 JS58JmRvBPz2mRaU3MRPBGRDeCz/Nc9LggL2ZcgM+E1ZYirlYyQfIED3lkqk5R07
 kIN1wmb+kQhXyU4IY3fEX7joqyKC6zOy4DUChPkBQU0/0+VUmdVmcJvsuPlnMZtf
 g95m0BdYTui+eDezASRqOEp3Lb5ONL4c3ao4yBP0LHF033ctj3VJQiyi5uERPZJ0
 5e6Mo7Wxn78t9WqJLQAiEH46kTwT2plNlxf3XXqTenfIdbWhqE873HPGeSMa3VQV
 VywXTpCpSPQsA8BYg66qIbebdKOhs9MOviHVfqDtwQlvwhjlBDya0gNHfI5fSy4=
 =Y/L5
 -----END PGP SIGNATURE-----

Merge tag 'v4.8-rc8' into drm-next

Linux 4.8-rc8

There was a lot of fallout in the imx/amdgpu/i915 drivers, so backmerge
it now to avoid troubles.

* tag 'v4.8-rc8': (1442 commits)
  Linux 4.8-rc8
  fault_in_multipages_readable() throws set-but-unused error
  mm: check VMA flags to avoid invalid PROT_NONE NUMA balancing
  radix tree: fix sibling entry handling in radix_tree_descend()
  radix tree test suite: Test radix_tree_replace_slot() for multiorder entries
  fix memory leaks in tracing_buffers_splice_read()
  tracing: Move mutex to protect against resetting of seq data
  MIPS: Fix delay slot emulation count in debugfs
  MIPS: SMP: Fix possibility of deadlock when bringing CPUs online
  mm: delete unnecessary and unsafe init_tlb_ubc()
  huge tmpfs: fix Committed_AS leak
  shmem: fix tmpfs to handle the huge= option properly
  blk-mq: skip unmapped queues in blk_mq_alloc_request_hctx
  MIPS: Fix pre-r6 emulation FPU initialisation
  arm64: kgdb: handle read-only text / modules
  arm64: Call numa_store_cpu_info() earlier.
  locking/hung_task: Fix typo in CONFIG_DETECT_HUNG_TASK help text
  nvme-rdma: only clear queue flags after successful connect
  i2c: qup: skip qup_i2c_suspend if the device is already runtime suspended
  perf/core: Limit matching exclusive events to one PMU
  ...
2016-09-28 12:08:49 +10:00
Dave Airlie
b81a6179b6 Merge tag 'drm-intel-next-2016-09-19' of git://anongit.freedesktop.org/drm-intel into drm-next
- refactor the sseu code (Imre)
- refine guc dmesg output (Dave Gordon)
- more vgpu work
- more skl wm fixes (Lyude)
- refactor dpll code in prep for upfront link training (Jim Bride et al)
- consolidate all platform feature checks into intel_device_info (Carlos Santa)
- refactor elsp/execlist submission as prep for re-submission after hang
  recovery and eventually scheduling (Chris Wilson)
- allow synchronous gpu reset handling, to remove tricky/impossible/fragile
  error recovery code (Chris Wilson)
- prep work for nonblocking (execlist) submission, using fences to track
  depencies and drive elsp submission (Chris Wilson)
- partial error recover/resubmission of non-guilty batches after hangs (Chris Wilson)
- full dma-buf implicit fencing support (Chris Wilson)
- dp link training fixes (Jim, Dhinkaran, Navare, ...)
- obey dp branch device pixel rate/bpc/clock limits (Mika Kahola), needed for
  many vga dongles
- bunch of small cleanups and polish all over, as usual

[airlied: printing macros collided]

* tag 'drm-intel-next-2016-09-19' of git://anongit.freedesktop.org/drm-intel: (163 commits)
  drm/i915: Update DRIVER_DATE to 20160919
  drm: Fix DisplayPort branch device ID kernel-doc
  drm/i915: use NULL for NULL pointers
  drm/i915: do not use 'false' as a NULL pointer
  drm/i915: make intel_dp_compute_bpp static
  drm: Add DP branch device info on debugfs
  drm/i915: Update bits per component for display info
  drm/i915: Check pixel rate for DP to VGA dongle
  drm/i915: Read DP branch device SW revision
  drm/i915: Read DP branch device HW revision
  drm/i915: Cleanup DisplayPort AUX channel initialization
  drm: Read DP branch device id
  drm: Helper to read max bits per component
  drm: Helper to read max clock rate
  drm: Drop VGA from bpc definitions
  drm: Add missing DP downstream port types
  drm/i915: Add ddb size field to device info structure
  drm/i915/guc: general tidying up (submission)
  drm/i915/guc: general tidying up (loader)
  drm/i915: clarify PMINTRMSK/pm_intr_keep usage
  ...
2016-09-20 06:23:22 +10:00
Daniel Vetter
6e05f3d3b9 drm/i915: Update DRIVER_DATE to 20160919
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-09-19 09:26:08 +02:00
Jani Nikula
911f4869eb drm/i915: use NULL for NULL pointers
Fix sparse warning:

drivers/gpu/drm/i915/i915_cmd_parser.c:987:72: warning: Using plain
integer as NULL pointer

Fixes: 52a42cec4b ("drm/i915/cmdparser: Accelerate copies from WC memory")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473946137-1931-4-git-send-email-jani.nikula@intel.com
2016-09-16 10:35:43 +03:00
Jani Nikula
bcbfcc37cd drm/i915: do not use 'false' as a NULL pointer
Fixes sparse warning:

drivers/gpu/drm/i915/intel_dpll_mgr.c:1712:24: warning: Using plain
integer as NULL pointer

Fixes: a277ca7dc0 ("drm/i915: Split bxt_ddi_pll_select()")
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Cc: Durgadoss R <durgadoss.r@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473946137-1931-2-git-send-email-jani.nikula@intel.com
2016-09-16 10:35:16 +03:00
Jani Nikula
f580bea97d drm/i915: make intel_dp_compute_bpp static
Fix sparse warning:

drivers/gpu/drm/i915/intel_dp.c:1527:5: warning: symbol
'intel_dp_compute_bpp' was not declared. Should it be static?

Fixes: f9bb705e65 ("drm/i915: Update bits per component for display info")
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Jim Bride <jim.bride@linux.intel.com>
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473946137-1931-1-git-send-email-jani.nikula@intel.com
2016-09-16 10:34:56 +03:00
Mika Kahola
80209e5f2c drm: Add DP branch device info on debugfs
Read DisplayPort branch device info from through debugfs
interface.

v2: use drm_dp_helper routines to collect data
v3: cleanup to match the drm_dp_helper.c patches introduced
    earlier in this series
v4: move DP branch device info to function 'intel_dp_branch_device_info()'
v5: initial step to move debugging info from intel_dp. to drm_dp_helper.c (Daniel)
v6: read hw and sw revision without using specific drm_dp_helper routines
v7: indentation fixes (Jim Bride)

Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473419458-17080-12-git-send-email-mika.kahola@intel.com
2016-09-15 14:51:07 +03:00
Mika Kahola
f9bb705e65 drm/i915: Update bits per component for display info
DisplayPort branch device may define max supported bits per
component. Update display info based on this value if bpc
is defined.

v2: cleanup to match the drm_dp_helper.c patches introduced
    earlier in this series
v3: Fill bpc for connector's display info in separate
    drm_dp_helper function (Daniel)
v4: remove updating bpc for display info as it may be overridden
    when parsing EDID. Instead, check bpc for DP branch device
    during compute_config
v5: Indentation fixes (Jim Bride)

Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473419458-17080-11-git-send-email-mika.kahola@intel.com
2016-09-15 14:51:00 +03:00
Mika Kahola
70ec064516 drm/i915: Check pixel rate for DP to VGA dongle
Filter out a mode that exceeds the max pixel rate setting
for DP to VGA dongle. This is defined in DPCD register 0x81
if detailed cap info i.e. info field is 4 bytes long and
it is available for DP downstream port.

The register defines the pixel rate divided by 8 in MP/s.

v2: DPCD read outs and computation moved to drm (Ville, Daniel)
v3: Sink pixel rate computation moved to drm_dp_max_sink_dotclock()
    function (Daniel)
v4: Use of drm_dp_helper.c routines to compute max pixel clock (Ville)
v5: Use of intel_dp->downstream_ports to read out port capabilities.
    Code restructuring (Ville)
v6: Move DP branch device check to drm_dp_helper.c (Daniel)
v7: Cleanup as suggested by Ville

Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473419458-17080-10-git-send-email-mika.kahola@intel.com
2016-09-15 14:50:55 +03:00
Mika Kahola
1a2724fa94 drm/i915: Read DP branch device SW revision
SW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register fields 0x50A
and 0x50B.

v2: move drm_dp_ds_revision structure to be part of
    drm_dp_link structure (Daniel)
v3: remove dependency to drm_dp_helper but instead parse
    DPCD and print SW revision info to dmesg (Ville)
v4: commit message fix (Jim Bride)

Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473419458-17080-9-git-send-email-mika.kahola@intel.com
2016-09-15 14:50:33 +03:00
Mika Kahola
0e390a33a6 drm/i915: Read DP branch device HW revision
HW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x509.

v2: move drm_dp_ds_revision structure to be part of
    drm_dp_link structure (Daniel)
v3: remove dependency to drm_dp_helper but instead parse
    DPCD and print HW revision info to dmesg (Ville)

Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473419458-17080-8-git-send-email-mika.kahola@intel.com
2016-09-15 14:50:27 +03:00
Mika Kahola
b633958587 drm/i915: Cleanup DisplayPort AUX channel initialization
Let's remove reference to "struct intel_connector *connector"
in intel_dp_aux_init() function as it is no longer required.

Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473419458-17080-7-git-send-email-mika.kahola@intel.com
2016-09-15 14:50:19 +03:00
Deepak M
6f3fff602e drm/i915: Add ddb size field to device info structure
Adding the ddb size into the devide info will avoid
platform checks while computing wm.

v2: Added comment and WARN_ON if ddb size is zero.(Jani)
v3: Added WARN_ON at the right place.(Jani)

Suggested-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Deepak M <m.deepak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473931870-7724-1-git-send-email-m.deepak@intel.com
2016-09-15 13:57:36 +03:00
Dave Gordon
7a9347f947 drm/i915/guc: general tidying up (submission)
Renaming to more consistent scheme, and updating comments, mostly
about i915_guc_wq_reserve(), aka i915_guc_wq_check_space().

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473711577-11454-4-git-send-email-david.s.gordon@intel.com
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-09-15 10:56:07 +01:00
Dave Gordon
0c5664e417 drm/i915/guc: general tidying up (loader)
Renaming to more consistent scheme, delete unused definitions

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473711577-11454-3-git-send-email-david.s.gordon@intel.com
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-09-15 10:56:02 +01:00
Dave Gordon
b20e3cfe4b drm/i915: clarify PMINTRMSK/pm_intr_keep usage
No functional changes; just renaming a bit, tweaking a datatype,
prettifying layout, and adding comments, in particular in the
GuC setup code that touches this data.

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473711577-11454-2-git-send-email-david.s.gordon@intel.com
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-09-15 10:55:43 +01:00
Dave Gordon
b0876afdff drm/i915: Only expand COND once in wait_for()
Commentary from Chris Wilson's original version:

> I was looking at some wait_for() timeouts on a slow system, with lots of
> debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were
> mishandling the timeout, I tried to ensure that we loop at least once
> after first testing COND. However, the double test of COND either side
> of the timeout check makes that unlikely. But we can do an equivalent
> loop, that keeps the COND check after testing for timeout (required so
> that we are not preempted between testing COND and then testing for a
> timeout) without expanding COND twice.
>
> The advantage of only expanding COND once is a dramatic reduction in
> code size:
>
>    text	   data	    bss	    dec	    hex
>    1308733	   5184	   1152	1315069	 1410fd	before
>    1305341	   5184	   1152	1311677	 1403bd	after

but it turned out that due to a missing iniitialiser, gcc had "gone
wild trimming undefined code" :( This version acheives a rather more
modest (but still worthwhile) gain of ~550 bytes.

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Original-idea-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Zanoni, Paulo R <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473855033-26980-1-git-send-email-david.s.gordon@intel.com
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-09-15 10:48:40 +01:00
Ville Syrjälä
ea54ff4008 drm/i915: Ignore OpRegion panel type except on select machines
Turns out
commit a05628195a ("drm/i915: Get panel_type from OpRegion panel
details") has regressed quite a few machines. So it looks like we
can't use the panel type from OpRegion on all systems, and yet we
absolutely must use it on some specific systems.

Despite trying, I was unable to find any automagic way to determine
if the OpRegion panel type is respectable or not. The only glimmer
of hope I had was bit 8 in the SCIC response, but that turned out to
not work either (it was always 0 on both types of systems).

So, to fix the regressions without breaking the machine we know to need
the OpRegion panel type, let's just add a quirk for this. Only specific
machines known to require the OpRegion panel type will therefore use
it. Everyone else will fall bck to the VBT panel type.

The only known machine so far is a "Conrac GmbH IX45GM2". The PCI
subsystem ID on this machine is just a generic 8086:2a42, so of no use.
Instead we'll go with a DMI match.

I suspect we can now also revert
commit aeddda06c1 ("drm/i915: Ignore panel type from OpRegion on SKL")
but let's leave that to a separate patch.

v2: Do the DMI match in the opregion code directly, as dev_priv->quirks
    gets populated too late

Cc: Rob Kramer <rob@solution-space.com>
Cc: Martin van Es <martin@mrvanes.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Marco Krüger <krgsch@gmail.com>
Cc: Sean Greenslade <sean@seangreenslade.com>
Cc: Trudy Tective <bertslany@gmail.com>
Cc: Robin Müller <rm1990@gmx.de>
Cc: Alexander Kobel <a-kobel@a-kobel.de>
Cc: Alexey Shumitsky <alexey.shumitsky@gmail.com>
Cc: Emil Andersen Lauridsen <mine809@gmail.com>
Cc: oceans112@gmail.com
Cc: James Hogan <james@albanarts.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: stable@vger.kernel.org
References: https://lists.freedesktop.org/archives/intel-gfx/2016-August/105545.html
References: https://lists.freedesktop.org/archives/dri-devel/2016-August/116888.html
References: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97060
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97443
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97363
Fixes: a05628195a ("drm/i915: Get panel_type from OpRegion panel details")
Tested-by: Marco Krüger <krgsch@gmail.com>
Tested-by: Alexey Shumitsky <alexey.shumitsky@gmail.com>
Tested-by: Sean Greenslade <sean@seangreenslade.com>
Tested-by: Emil Andersen Lauridsen <mine809@gmail.com>
Tested-by: Robin Müller <rm1990@gmx.de>
Tested-by: oceans112@gmail.com
Tested-by: Rob Kramer <rob@solution-space.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473758539-21565-1-git-send-email-ville.syrjala@linux.intel.com
References: http://patchwork.freedesktop.org/patch/msgid/1473602239-15855-1-git-send-email-adrienverge@gmail.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit c8ebfad7a0)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-09-14 11:25:05 +03:00
Rodrigo Vivi
86dfb76cba Revert "drm/i915/psr: Make idle_frames sensible again"
This reverts

commit 1c80c25fb6
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed May 18 18:47:12 2016 +0200

    drm/i915/psr: Make idle_frames sensible again

There are panels that needs 4 idle frames before entering PSR,
but VBT is unproperly set.

Also lately it was identified that idle frame count calculated at HW
can be off by 1, what makes the minimum of 2, at least.

Without the current vbt+1 we are with the risk of having HW calculating
0 idle frames and entering PSR when it shouldn't. Regardless the lack
of link training.

[Jani: there is some disagreement on the explanation, but the commit
regresses so revert it is.]

References: http://marc.info/?i=20160904191153.GA2328@light.dominikbrodowski.net
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Fixes: 1c80c25fb6 ("drm/i915/psr: Make idle_frames sensible again")
Cc: drm-intel-fixes@lists.freedesktop.org # v4.8-rc1+
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473295351-8766-1-git-send-email-rodrigo.vivi@intel.com
(cherry picked from commit 40918e0bb8)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-09-14 11:24:58 +03:00
Chris Wilson
74712339a4 drm/i915: Restore lost "Initialized i915" welcome message
A side effect of removing the midlayer from driver loading was the loss
of a useful message announcing to userspace that i915 had successfully
started, e.g.:

	[drm] Initialized i915 1.6.0 20160425 for 0000:00:02.0 on minor 0

Reported-by: Timo Aaltonen <tjaalton@ubuntu.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: 8f460e2c78 ("drm/i915: Demidlayer driver loading")
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Link: http://patchwork.freedesktop.org/patch/msgid/20160825072314.17402-1-chris@chris-wilson.co.uk
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit bc5ca47c0a)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-09-14 11:23:46 +03:00
Ville Syrjälä
c8ebfad7a0 drm/i915: Ignore OpRegion panel type except on select machines
Turns out
commit a05628195a ("drm/i915: Get panel_type from OpRegion panel
details") has regressed quite a few machines. So it looks like we
can't use the panel type from OpRegion on all systems, and yet we
absolutely must use it on some specific systems.

Despite trying, I was unable to find any automagic way to determine
if the OpRegion panel type is respectable or not. The only glimmer
of hope I had was bit 8 in the SCIC response, but that turned out to
not work either (it was always 0 on both types of systems).

So, to fix the regressions without breaking the machine we know to need
the OpRegion panel type, let's just add a quirk for this. Only specific
machines known to require the OpRegion panel type will therefore use
it. Everyone else will fall bck to the VBT panel type.

The only known machine so far is a "Conrac GmbH IX45GM2". The PCI
subsystem ID on this machine is just a generic 8086:2a42, so of no use.
Instead we'll go with a DMI match.

I suspect we can now also revert
commit aeddda06c1 ("drm/i915: Ignore panel type from OpRegion on SKL")
but let's leave that to a separate patch.

v2: Do the DMI match in the opregion code directly, as dev_priv->quirks
    gets populated too late

Cc: Rob Kramer <rob@solution-space.com>
Cc: Martin van Es <martin@mrvanes.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Marco Krüger <krgsch@gmail.com>
Cc: Sean Greenslade <sean@seangreenslade.com>
Cc: Trudy Tective <bertslany@gmail.com>
Cc: Robin Müller <rm1990@gmx.de>
Cc: Alexander Kobel <a-kobel@a-kobel.de>
Cc: Alexey Shumitsky <alexey.shumitsky@gmail.com>
Cc: Emil Andersen Lauridsen <mine809@gmail.com>
Cc: oceans112@gmail.com
Cc: James Hogan <james@albanarts.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: stable@vger.kernel.org
References: https://lists.freedesktop.org/archives/intel-gfx/2016-August/105545.html
References: https://lists.freedesktop.org/archives/dri-devel/2016-August/116888.html
References: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97060
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97443
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97363
Fixes: a05628195a ("drm/i915: Get panel_type from OpRegion panel details")
Tested-by: Marco Krüger <krgsch@gmail.com>
Tested-by: Alexey Shumitsky <alexey.shumitsky@gmail.com>
Tested-by: Sean Greenslade <sean@seangreenslade.com>
Tested-by: Emil Andersen Lauridsen <mine809@gmail.com>
Tested-by: Robin Müller <rm1990@gmx.de>
Tested-by: oceans112@gmail.com
Tested-by: Rob Kramer <rob@solution-space.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473758539-21565-1-git-send-email-ville.syrjala@linux.intel.com
References: http://patchwork.freedesktop.org/patch/msgid/1473602239-15855-1-git-send-email-adrienverge@gmail.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
2016-09-14 10:35:00 +03:00
Rodrigo Vivi
40918e0bb8 Revert "drm/i915/psr: Make idle_frames sensible again"
This reverts

commit 1c80c25fb6
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed May 18 18:47:12 2016 +0200

    drm/i915/psr: Make idle_frames sensible again

There are panels that needs 4 idle frames before entering PSR,
but VBT is unproperly set.

Also lately it was identified that idle frame count calculated at HW
can be off by 1, what makes the minimum of 2, at least.

Without the current vbt+1 we are with the risk of having HW calculating
0 idle frames and entering PSR when it shouldn't. Regardless the lack
of link training.

[Jani: there is some disagreement on the explanation, but the commit
regresses so revert it is.]

References: http://marc.info/?i=20160904191153.GA2328@light.dominikbrodowski.net
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Fixes: 1c80c25fb6 ("drm/i915/psr: Make idle_frames sensible again")
Cc: drm-intel-fixes@lists.freedesktop.org # v4.8-rc1+
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473295351-8766-1-git-send-email-rodrigo.vivi@intel.com
2016-09-13 11:57:53 +03:00
Navare, Manasi D
2686ebfdf7 drm/i915: Add support for Kabylake to function obtaining shared PLL
This adds support for KBL in the new function added in commit ID:
commit <f169660ed4e57a03e6f6ed07fe192dbcb7687a0d> that returns a
shared pll in case of DDI platforms.

Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473728663-14355-1-git-send-email-manasi.d.navare@intel.com
2016-09-12 22:06:08 -07:00
Matthew Auld
82daabae9e drm/i915: remove writeq ifdeffery
drm already provides fallback versions of readq and writeq.

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473451373-9852-1-git-send-email-matthew.auld@intel.com
2016-09-12 11:33:56 +03:00
Navare, Manasi D
c92bd2fa33 drm/i915: Make DP link training channel equalization DP 1.2 Spec compliant
Fix the number of tries in channel euqalization link training sequence
according to DP 1.2 Spec. It returns a boolean depending on channel
equalization pass or failure.

Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2016-09-09 14:53:18 -07:00
Dhinakaran Pandiyan
13b1996e84 drm/dp/i915: Make clock recovery in the link training compliant with DP Spec 1.2
This function cleans up clock recovery loop in link training compliant
tp Dp Spec 1.2. It tries the clock recovery 5 times for the same voltage
or until max voltage swing is reached and removes the additional non
compliant retries. This function now returns a boolean values based on
if clock recovery passed or failed.

v3:
* Better Debug prints in case of failures (Mika Kahola)
v2:
* Rebased on top of new revision of vswing patch (Manasi Navare)

Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2016-09-09 14:53:18 -07:00
Dhinakaran Pandiyan
7bfaddf057 drm/i915/dp: Move max. vswing check to it's own function
Wrap the max. vswing check in a separate function.
This makes the clock recovery phase of DP link training cleaner

v3:
Fixed the paranthesis warning (Mika Kahola)
v2:
Fixed the Compiler warning (Mika Kahola)

Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2016-09-09 14:53:18 -07:00
Jim Bride
f169660ed4 drm/i915/dp: Add a standalone function to obtain shared dpll for HSW/BDW/SKL/BXT
Add the PLL selection code for HSW/BDW/BXT/SKL into a stand-alone function
in order to allow for the implementation of a platform neutral upfront
link training function.

v4:
* Removed dereferencing NULL pointer in  case of failure (Dhinakaran Pandiyan)
v3:
* Add Hooks for all DDI platforms into this standalone function

v2:
* Change the macro to use dev_priv instead of dev (David Weinehall)

Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2016-09-09 14:53:18 -07:00
Chris Wilson
fbb30a5c46 drm/i915: Flush to GTT domain all GGTT bound objects after hibernation
Recently I have been applying an optimisation to avoid stalling and
clflushing GGTT objects based on their current binding. That is we only
set-to-gtt-domain upon first bind. However, on hibernation the objects
remain bound, but they are in the CPU domain. Currently (since commit
975f7ff42e ("drm/i915: Lazily migrate the objects after hibernation"))
we only flush scanout objects as all other objects are expected to be
flushed prior to use. That breaks down in the face of the runtime
optimisation above - and we need to flush all GGTT pinned objects
(essentially ringbuffers).

To reduce the burden of extra clflushes, we only flush those objects we
cannot discard from the GGTT. Everything pinned to the scanout, or
current contexts or ringbuffers will be flushed and rebound. Other
objects, such as inactive contexts, will be left unbound and in the CPU
domain until first use after resuming.

Fixes: 7abc98fadf ("drm/i915: Only change the context object's domain...")
Fixes: 57e8853181 ("drm/i915: Use VMA for ringbuffer tracking")
References: https://bugs.freedesktop.org/show_bug.cgi?id=94722
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: David Weinehall <david.weinehall@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909201957.2499-1-chris@chris-wilson.co.uk
2016-09-09 21:31:43 +01:00
Chris Wilson
7aab2d534e drm/i915: Shrink objects prior to hibernation
In an attempt to keep the hibernation image as same as possible, let's
try and discard any unwanted pages and our own page arrays.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909190218.16831-1-chris@chris-wilson.co.uk
2016-09-09 20:07:46 +01:00
Chris Wilson
851ba2d697 drm/i915: Serialise execbuf operation after a dma-buf reservation object
Now that we can wait upon fences before emitting the request, it becomes
trivial to wait upon any implicit fence provided by the dma-buf
reservation object.

To protect against failure, we force any asynchronous waits on a foreign
fence to timeout after 10s - so that a stall in another driver does not
permanently cripple ourselves. Still unpleasant though!

Testcase: igt/prime_vgem/fence-wait
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: John Harrison <john.c.harrison@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-21-chris@chris-wilson.co.uk
2016-09-09 14:23:08 +01:00
Chris Wilson
0a046a0e93 drm/i915: Nonblocking request submission
Now that we have fences in place to drive request submission, we can
employ those to queue requests after their dependencies as opposed to
stalling in the middle of an execbuf ioctl. (However, we still choose to
spin before enabling the IRQ as that is faster - though contentious.)

v2: Do the fence ordering first, where we can still fail.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-20-chris@chris-wilson.co.uk
2016-09-09 14:23:08 +01:00
Chris Wilson
32c2b4bda6 drm/i915: Avoid incrementing hangcheck whilst waiting for external fence
If we are waiting upon an external fence, from the pov of hangcheck the
engine is stuck on the last submitted seqno. Currently we give a small
increment to the hangcheck score in order to catch a stuck waiter /
driver. Now that we both have an independent wait hangcheck and may be
stuck waiting on an external fence, resetting the GPU has little effect
on that external fence. As we cannot advance by resetting, skip
incrementing the hangcheck score.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-19-chris@chris-wilson.co.uk
2016-09-09 14:23:07 +01:00
Chris Wilson
80b5bdbdcb drm/i915: Ignore valid but unknown semaphores
If we find a ring waiting on a semaphore for another assigned but not yet
emitted request, treat it as valid and waiting.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-18-chris@chris-wilson.co.uk
2016-09-09 14:23:07 +01:00
Chris Wilson
dadd481bfe drm/i915/guc: Prepare for nonblocking execbuf submission
Currently the presumption is that the request construction and its
submission to the GuC are all under the same holding of struct_mutex. We
wish to relax this to separate the request construction and the later
submission to the GuC. This requires us to reserve some space in the
GuC command queue for the future submission. For flexibility to handle
out-of-order request submission we do not preallocate the next slot in
the GuC command queue during request construction, just ensuring that
there is enough space later.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-17-chris@chris-wilson.co.uk
2016-09-09 14:23:06 +01:00
Chris Wilson
a2bc4695bb drm/i915: Prepare object synchronisation for asynchronicity
We are about to specialize object synchronisation to enable nonblocking
execbuf submission. First we make a copy of the current object
synchronisation for execbuffer. The general i915_gem_object_sync() will
be removed following the removal of CS flips in the near future.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: John Harrison <john.c.harrison@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-16-chris@chris-wilson.co.uk
2016-09-09 14:23:06 +01:00
Chris Wilson
0f25dff6e9 drm/i915: Reorder i915_add_request to separate the phases better
Let's avoid mixing sealing the hardware commands for the request and
adding the request to the software tracking.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-15-chris@chris-wilson.co.uk
2016-09-09 14:23:05 +01:00
Chris Wilson
5590af3e11 drm/i915: Drive request submission through fence callbacks
Drive final request submission from a callback from the fence. This way
the request is queued until all dependencies are resolved, at which
point it is handed to the backend for queueing to hardware. At this
point, no dependencies are set on the request, so the callback is
immediate.

A side-effect of imposing a heavier-irqsafe spinlock for execlist
submission is that we lose the softirq enabling after scheduling the
execlists tasklet. To compensate, we manually kickstart the softirq by
disabling and enabling the bh around the fence signaling.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: John Harrison <john.c.harrison@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-14-chris@chris-wilson.co.uk
2016-09-09 14:23:05 +01:00
Chris Wilson
821ed7df6e drm/i915: Update reset path to fix incomplete requests
Update reset path in preparation for engine reset which requires
identification of incomplete requests and associated context and fixing
their state so that engine can resume correctly after reset.

The request that caused the hang will be skipped and head is reset to the
start of breadcrumb. This allows us to resume from where we left-off.
Since this request didn't complete normally we also need to cleanup elsp
queue manually. This is vital if we employ nonblocking request
submission where we may have a web of dependencies upon the hung request
and so advancing the seqno manually is no longer trivial.

ABI: gem_reset_stats / DRM_IOCTL_I915_GET_RESET_STATS

We change the way we count pending batches. Only the active context
involved in the reset is marked as either innocent or guilty, and not
mark the entire world as pending. By inspection this only affects
igt/gem_reset_stats (which assumes implementation details) and not
piglit.

ARB_robustness gives this guide on how we expect the user of this
interface to behave:

 * Provide a mechanism for an OpenGL application to learn about
   graphics resets that affect the context.  When a graphics reset
   occurs, the OpenGL context becomes unusable and the application
   must create a new context to continue operation. Detecting a
   graphics reset happens through an inexpensive query.

And with regards to the actual meaning of the reset values:

   Certain events can result in a reset of the GL context. Such a reset
   causes all context state to be lost. Recovery from such events
   requires recreation of all objects in the affected context. The
   current status of the graphics reset state is returned by

	enum GetGraphicsResetStatusARB();

   The symbolic constant returned indicates if the GL context has been
   in a reset state at any point since the last call to
   GetGraphicsResetStatusARB. NO_ERROR indicates that the GL context
   has not been in a reset state since the last call.
   GUILTY_CONTEXT_RESET_ARB indicates that a reset has been detected
   that is attributable to the current GL context.
   INNOCENT_CONTEXT_RESET_ARB indicates a reset has been detected that
   is not attributable to the current GL context.
   UNKNOWN_CONTEXT_RESET_ARB indicates a detected graphics reset whose
   cause is unknown.

The language here is explicit in that we must mark up the guilty batch,
but is loose enough for us to relax the innocent (i.e. pending)
accounting as only the active batches are involved with the reset.

In the future, we are looking towards single engine resetting (with
minimal locking), where it seems inappropriate to mark the entire world
as innocent since the reset occurred on a different engine. Reducing the
information available means we only have to encounter the pain once, and
also reduces the information leaking from one context to another.

v2: Legacy ringbuffer submission required a reset following hibernation,
or else we restore stale values to the RING_HEAD and walked over
stolen garbage.

v3: GuC requires replaying the requests after a reset.

v4: Restore engine IRQ after reset (so waiters will be woken!)
    Rearm hangcheck if resetting with a waiter.

Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-13-chris@chris-wilson.co.uk
2016-09-09 14:23:05 +01:00
Chris Wilson
780f262a70 drm/i915: Replace wait-on-mutex with wait-on-bit in reset worker
Since we have a cooperative mode now with a direct reset, we can avoid
the contention on struct_mutex and instead try then sleep on the
I915_RESET_IN_PROGRESS bit. If the mutex is held and that bit is
cleared, all is fine. Otherwise, we sleep for a bit and try again. In
the worst case we sleep for an extra second waiting for the mutex to be
released (no one touching the GPU is allowed the struct_mutex whilst the
I915_RESET_IN_PROGRESS bit is set). But when we have a direct reset,
this allows us to clean up the reset worker faster.

v2: Remember to call wake_up_bit() after changing (for the faster wakeup
as promised)

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-12-chris@chris-wilson.co.uk
2016-09-09 14:23:04 +01:00
Chris Wilson
221fe79945 drm/i915: Perform a direct reset of the GPU from the waiter
If a waiter is holding the struct_mutex, then the reset worker cannot
reset the GPU until the waiter returns. We do not want to return -EAGAIN
form i915_wait_request as that breaks delicate operations like
i915_vma_unbind() which often cannot be restarted easily, and returning
-EIO is just as useless (and has in the past proven dangerous). The
remaining WARN_ON(i915_wait_request) serve as a valuable reminder that
handling errors from an indefinite wait are tricky.

We can keep the current semantic that knowing after a reset is complete,
so is the request, by performing the reset ourselves if we hold the
mutex.

uevent emission is still handled by the reset worker, so it may appear
slightly out of order with respect to the actual reset (and concurrent
use of the device).

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-11-chris@chris-wilson.co.uk
2016-09-09 14:23:04 +01:00
Chris Wilson
22dd3bb919 drm/i915: Mark up all locked waiters
In the next patch we want to handle reset directly by a locked waiter in
order to avoid issues with returning before the reset is handled. To
handle the reset, we must first know whether we hold the struct_mutex.
If we do not hold the struct_mtuex we can not perform the reset, but we do
not block the reset worker either (and so we can just continue to wait for
request completion) - otherwise we must relinquish the mutex.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-10-chris@chris-wilson.co.uk
2016-09-09 14:23:03 +01:00
Chris Wilson
ea746f3659 drm/i915: Expand bool interruptible to pass flags to i915_wait_request()
We need finer control over wakeup behaviour during i915_wait_request(),
so expand the current bool interruptible to a bitmask.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-9-chris@chris-wilson.co.uk
2016-09-09 14:23:03 +01:00
Chris Wilson
2c7487a524 drm/i915: Drop local struct_mutex around intel_init_emon[ilk]
Access to intel_init_emon() is strictly ordered by gt_powersave, using
struct_mutex around it is overkill (and will conflict with the caller
holding struct_mutex themselves).

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-8-chris@chris-wilson.co.uk
2016-09-09 14:23:02 +01:00
Chris Wilson
8af29b0c78 drm/i915: Separate out reset flags from the reset counter
In preparation for introducing a per-engine reset, we can first separate
the mixing of the reset state from the global reset counter.

The loss of atomicity in updating the reset state poses a small problem
for handling the waiters. For requests, this is solved by advancing the
seqno so that a waiter waking up after the reset knows the request is
complete. For pending flips, we still rely on the increment of the
global reset epoch (as well as the reset-in-progress flag) to signify
when the hardware was reset.

The advantage, now that we do not inspect the reset state during reset
itself i.e. we no longer emit requests during reset, is that we can use
the atomic updates of the state flags to ensure that only one reset
worker is active.

v2: Mika spotted that I transformed the i915_gem_wait_for_error() wakeup
into a waiter wakeup.

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>
Link: http://patchwork.freedesktop.org/patch/msgid/1470414607-32453-6-git-send-email-arun.siluvery@linux.intel.com
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-7-chris@chris-wilson.co.uk
2016-09-09 14:23:02 +01:00
Chris Wilson
70c2a24dbf drm/i915: Simplify ELSP queue request tracking
Emulate HW to track and manage ELSP queue. A set of SW ports are defined
and requests are assigned to these ports before submitting them to HW. This
helps in cleaning up incomplete requests during reset recovery easier
especially after engine reset by decoupling elsp queue management. This
will become more clear in the next patch.

In the engine reset case we want to resume where we left-off after skipping
the incomplete batch which requires checking the elsp queue, removing
element and fixing elsp_submitted counts in some cases. Instead of directly
manipulating the elsp queue from reset path we can examine these ports, fix
up ringbuffer pointers using the incomplete request and restart submissions
again after reset.

Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1470414607-32453-3-git-send-email-arun.siluvery@linux.intel.com
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-6-chris@chris-wilson.co.uk
2016-09-09 14:23:01 +01:00
Chris Wilson
bbd6c47e11 drm/i915: Reorder submitting the requests to ELSP
Just rearrange the code to reduce churn in the next patch.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-5-chris@chris-wilson.co.uk
2016-09-09 14:23:01 +01:00
Chris Wilson
8b38b3a167 drm/i915: Compute the ELSP register location once
Similar to the issue with reading from the context status buffer,
see commit 26720ab97f ("drm/i915: Move CSB MMIO reads out of the
execlists lock"), we frequently write to the ELSP register (4 writes per
interrupt) and know we hold the required spinlock and forcewake throughout.
We can further reduce the cost of writing these registers beyond the
I915_WRITE_FW() by precomputing the address of the ELSP register. We also
note that the subsequent read serves no purpose here, and are happy to
see it go.

v2: Address I915_WRITE mistakes in changelog

   text    data     bss     dec     hex filename
1259784    4581     576 1264941  134d2d drivers/gpu/drm/i915/i915.ko
1259720    4581     576 1264877  134ced drivers/gpu/drm/i915/i915.ko

Saves 64 bytes of address recomputation.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-4-chris@chris-wilson.co.uk
2016-09-09 14:23:01 +01:00
Chris Wilson
a52abd2fac drm/i915: Record the position of the workarounds in the tail of the request
Rather than blindly assuming we need to advance the tail for
resubmitting the request via the ELSP, record the position.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-3-chris@chris-wilson.co.uk
2016-09-09 14:23:00 +01:00
Chris Wilson
ba49b2f823 drm/i915: Only queue requests during execlists submission
Leave the more complicated request dequeueing to the tasklet and instead
just kick start the tasklet if we detect we are adding the first
request.

v2: Play around with list operators until we agree upon something

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-2-chris@chris-wilson.co.uk
2016-09-09 14:23:00 +01:00