Commit Graph

738346 Commits

Author SHA1 Message Date
Ville Syrjälä
81af63a4af drm: Don't pass clip to drm_atomic_helper_check_plane_state()
Move the plane clip rectangle handling into
drm_atomic_helper_check_plane_state(). Drivers no longer
have to worry about such mundane details.

v2: Convert armada, rcar, and sun4i as well
v3: Resolve simple_kms_helper conflict

Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>
Cc: Mali DP Maintainers <malidp@foss.arm.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: CK Hu <ck.hu@mediatek.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Sandy Huang <hjc@rock-chips.com>
Cc: "Heiko Stübner" <heiko@sntech.de>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-tegra@vger.kernel.org
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Archit Taneja <architt@codeaurora.org> #msm
Link: https://patchwork.freedesktop.org/patch/msgid/20180123170857.13818-5-ville.syrjala@linux.intel.com
Acked-by: Liviu Dudau <liviu.dudau@arm.com> #hdlcd,malidp
Acked-by: Philipp Zabel <p.zabel@pengutronix.de> #imx,mtk
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com> #vmwgfx
Acked-by: Neil Armstrong <narmstrong@baylibre.com> #meson
Acked-by: Shawn Guo <shawnguo@kernel.org> #zte
2018-03-05 20:48:25 +02:00
Ville Syrjälä
bf817d0cf7 drm/armada: Use drm_mode_get_hv_timing() to populate plane clip rectangle
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Since armada isn't atomic we'll use crtc->enabled and crtc->mode instead
of the stuff under crtc_state.

Once everyone agrees on how the clip rectangle gets set up we can
move the code into drm_atomic_helper_check_plane_state().

Cc: Dave Airlie <airlied@redhat.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180123170857.13818-4-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Dave Airlie <airlied@redhat.com>
2018-03-05 20:41:00 +02:00
Ville Syrjälä
57270b8191 drm/armada: Construct a temporary crtc state for plane checks
As armada isn't an atomic driver trying to pass a non-populated
crtc->state to drm_atomic_helper_check_plane_state() will end in tears.
Construct a temporary crtc state a la drm_plane_helper_check_update()
and pass that instead. For now we just really need crtc_state->enable
to be there.

Cc: Dave Airlie <airlied@redhat.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180123170857.13818-3-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Dave Airlie <airlied@redhat.com>
2018-03-05 20:35:14 +02:00
Matthias Kaehlcke
3126bf7958 drm/radeon/mkregtable: Delete unused list functions and macros
The util mkregtable includes a copy of the kernel API for linked lists,
only a small subset of it is used. Delete the unused functions and macros.

Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-05 13:31:11 -05:00
Alex Deucher
0bf6718537 drm/amdgpu: used cached pcie gen info for SI (v2)
Rather than querying it every time we need it.
Also fixes a crash in VM pass through if there is no
root bridge because the cached value fetch already checks
this properly.

v2: fix includes

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=105244
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Rex Zhu<rezhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2018-03-05 13:30:55 -05:00
Stefan Wahren
d8eb9de423 drm/vc4: Replace long HDMI udelay with usleep_range
Since we aren't in atomic context replace this long udelay with a
usleep_range.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/1519475894-11701-1-git-send-email-stefan.wahren@i2se.com
2018-03-05 10:19:21 -08:00
Daniel Stone
423ad7b3cb drm/vc4: Advertise supported modifiers for planes
The IN_FORMATS blob allows the kernel to advertise to userspace which
format/modifier combinations are supported, per plane. Use this to
advertise that we support both T_TILED and linear.

v2:
  - Only advertise T_TILED for RGB (Eric)
  - Actually turn on allow_fb_modifiers (Eric)

Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/170828/
2018-03-05 10:18:30 -08:00
Tvrtko Ursulin
d4ccceb055 drm/i915/icl: Ringbuffer interrupt handling
On Gen11 interrupt masks need to be clear to allow C6 entry.
We keep them all enabled knowing that we generate extra
interrupts.

v2: Rebase.
v3: Remove gen 11 extra check in logical_render_ring_init.
v4: Rebase fixes.
v5: Rebase/refactor.
v6: Rebase.
v7: Rebase.
v8: Update comment and commit message (Daniele)

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180302161501.28594-1-mika.kuoppala@linux.intel.com
2018-03-05 16:26:28 +02:00
Philippe CORNU
669b710e5e drm/bridge/synopsys: dsi: readl_poll_timeout return value clean up
The readl_poll_timeout() return value is 0 in case of success
so it is better to detect errors without taking care of the
return value sign.

Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180204213624.18288-1-philippe.cornu@st.com
2018-03-05 14:08:16 +01:00
Chris Wilson
7509702bd8 drm/i915: Unwind vma pinning for intel_pin_and_fence_fb_obj error path
If we fail to acquire a fence when we must, we must unwind before
reporting the error. Otherwise, we lose tracking of the vma pinning and
eventually hit a bug like

<3>[   46.163202] i915_vma_unpin:333 GEM_BUG_ON(!i915_vma_is_pinned(vma))
<4>[   46.163424] ------------[ cut here ]------------
<2>[   46.163429] kernel BUG at drivers/gpu/drm/i915/i915_vma.h:333!
<4>[   46.163444] invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
<0>[   46.163451] Dumping ftrace buffer:
<0>[   46.163457] ---------------------------------
<0>[   46.163630]    <...>-84      1.... 46260767us : i915_gem_object_unpin_from_display_plane: i915_vma_unpin:333 GEM_BUG_ON(!i915_vma_is_pinned(vma))
<0>[   46.163635] ---------------------------------
<4>[   46.163638] Modules linked in: vgem i915 snd_hda_codec_analog snd_hda_codec_generic coretemp snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm lpc_ich mei_me e1000e mei prime_numbers
<4>[   46.163667] CPU: 1 PID: 84 Comm: kworker/u16:1 Tainted: G     U           4.16.0-rc3-gc07ef2c77d14-kasan_18+ #1
<4>[   46.163671] Hardware name: Dell Inc. OptiPlex 755                 /0PU052, BIOS A08 02/19/2008
<4>[   46.163743] Workqueue: events_unbound intel_atomic_commit_work [i915]
<4>[   46.163809] RIP: 0010:i915_gem_object_unpin_from_display_plane+0x253/0x2f0 [i915]
<4>[   46.163813] RSP: 0018:ffff8800624cfb48 EFLAGS: 00010286
<4>[   46.163818] RAX: 000000000000000c RBX: ffff880064446c40 RCX: ffff8800653135b8
<4>[   46.163822] RDX: dffffc0000000000 RSI: 0000000000000054 RDI: ffff8800651e30d0
<4>[   46.163825] RBP: 00000000000003d0 R08: 0000000000000001 R09: ffff8800651e3158
<4>[   46.163829] R10: 0000000000000000 R11: ffff8800651e30f0 R12: 0000000000000001
<4>[   46.163832] R13: ffff880054c58620 R14: 0000000000000000 R15: dffffc0000000000
<4>[   46.163836] FS:  0000000000000000(0000) GS:ffff880066040000(0000) knlGS:0000000000000000
<4>[   46.163840] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[   46.163843] CR2: 00007f1fc6fb0000 CR3: 00000000526fe000 CR4: 00000000000006e0
<4>[   46.163846] Call Trace:
<4>[   46.163918]  intel_unpin_fb_vma+0xbd/0x300 [i915]
<4>[   46.163990]  intel_cleanup_plane_fb+0x99/0xc0 [i915]
<4>[   46.163998]  drm_atomic_helper_cleanup_planes+0x166/0x280
<4>[   46.164071]  intel_atomic_commit_tail+0x1594/0x33a0 [i915]
<4>[   46.164081]  ? process_one_work+0x66e/0x1460
<4>[   46.164151]  ? skl_update_crtcs+0x9c0/0x9c0 [i915]
<4>[   46.164157]  ? lock_acquire+0x13d/0x390
<4>[   46.164161]  ? lock_acquire+0x13d/0x390
<4>[   46.164169]  process_one_work+0x71a/0x1460
<4>[   46.164175]  ? __schedule+0x838/0x1e50
<4>[   46.164182]  ? pwq_dec_nr_in_flight+0x2b0/0x2b0
<4>[   46.164188]  ? _raw_spin_lock_irq+0xa/0x40
<4>[   46.164194]  worker_thread+0xdf/0xf60
<4>[   46.164204]  ? process_one_work+0x1460/0x1460
<4>[   46.164209]  kthread+0x2cf/0x3c0
<4>[   46.164213]  ? _kthread_create_on_node+0xa0/0xa0
<4>[   46.164218]  ret_from_fork+0x3a/0x50
<4>[   46.164227] Code: e8 78 d9 cd e8 48 8b 35 cc 9e 47 00 49 c7 c0 c0 31 84 c0 b9 4d 01 00 00 48 c7 c2 e0 80 84 c0 48 c7 c7 0e bb 57 c0 e8 5d 4b df e8 <0f> 0b 48 c7 c1 c0 30 84 c0 ba 4e 01 00 00 48 c7 c6 e0 80 84 c0
<1>[   46.164368] RIP: i915_gem_object_unpin_from_display_plane+0x253/0x2f0 [i915] RSP: ffff8800624cfb48

Fixes: 85798ac9b3 ("drm/i915: Fail if we can't get a fence for gen2/3 tiled scanout")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180305103312.29492-1-chris@chris-wilson.co.uk
2018-03-05 12:15:28 +00:00
Mahesh Kumar
3d2011cfa4 drm/i915/icl: remove port A/E lane sharing limitation.
Platforms before Gen11 were sharing lanes between port-A & port-E.
This limitation is no more there.

Changes since V1:
 - optimize the code (Shashank/Jani)
 - create helper function to get max lanes (ville)
Changes since V2:
 - Include BIOS fail fix-up in same helper function (ville)
Changes since V3:
 - remove confusing if/else (jani)
 - group intel_encoder initialization

Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180206060855.30026-1-mahesh1.kumar@intel.com
2018-03-05 12:27:19 +02:00
Joonas Lahtinen
1f267a572b drm/i915: Update DRIVER_DATE to 20180305
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-03-05 11:56:15 +02:00
Maarten Lankhorst
5fcdc9d981 drm/atomic: Call ww_acquire_done after drm_modeset_lock_all
After we acquired all generic modeset locks in drm_modeset_lock_all, it's
unsafe acquire any other so just mark acquisition as done.

Atomic drivers shouldn't use drm_modeset_lock_all.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180221152331.9212-1-maarten.lankhorst@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Harry Wentland <harry.wentland@amd.com>
2018-03-05 10:35:32 +01:00
Frank Rowand
e547c00316 of: improve reporting invalid overlay target path
Errors while developing the patch to create of_overlay_fdt_apply()
exposed inadequate error messages to debug problems when overlay
devicetree fragment nodes contain an invalid target path.  Improve
the messages in find_target_node() to remedy this.

Signed-off-by: Frank Rowand <frank.rowand@sony.com>
2018-03-04 00:29:40 -08:00
Frank Rowand
db2f3762d6 of: convert unittest overlay devicetree source to sugar syntax
The unittest-data overlays have been pulled into proper overlay
devicetree source files without changing their format.  The
next step is to convert them to use sugar syntax instead of
hand coding overlay fragments structure.

A few of the overlays can not be converted because they test
absolute target paths in the overlay fragment.  dtc does not
generate this type of target:
  overlay_0.dts
  overlay_1.dts
  overlay_12.dts
  overlay_13.dts

Two pre-existing unittest overlay devicetree source files are
also converted:
  overlay_bad_phandle.dts
  overlay_bad_symbol.dts

Signed-off-by: Frank Rowand <frank.rowand@sony.com>
2018-03-04 00:29:34 -08:00
Frank Rowand
93a6039000 of: Documentation: of_overlay_apply() replaced by of_overlay_fdt_apply()
Signed-off-by: Frank Rowand <frank.rowand@sony.com>
2018-03-04 00:29:29 -08:00
Frank Rowand
39a751a4cb of: change overlay apply input data from unflattened to FDT
Move duplicating and unflattening of an overlay flattened devicetree
(FDT) into the overlay application code.  To accomplish this,
of_overlay_apply() is replaced by of_overlay_fdt_apply().

The copy of the FDT (aka "duplicate FDT") now belongs to devicetree
code, which is thus responsible for freeing the duplicate FDT.  The
caller of of_overlay_fdt_apply() remains responsible for freeing the
original FDT.

The unflattened devicetree now belongs to devicetree code, which is
thus responsible for freeing the unflattened devicetree.

These ownership changes prevent early freeing of the duplicated FDT
or the unflattened devicetree, which could result in use after free
errors.

of_overlay_fdt_apply() is a private function for the anticipated
overlay loader.

Update unittest.c to use of_overlay_fdt_apply() instead of
of_overlay_apply().

Move overlay fragments from artificial locations in
drivers/of/unittest-data/tests-overlay.dtsi into one devicetree
source file per overlay.  This led to changes in
drivers/of/unitest-data/Makefile and drivers/of/unitest.c.

  - Add overlay directives to the overlay devicetree source files so
    that dtc will compile them as true overlays into one FDT data
    chunk per overlay.

  - Set CFLAGS for drivers/of/unittest-data/testcases.dts so that
    symbols will be generated for overlay resolution of overlays
    that are no longer artificially contained in testcases.dts

  - Unflatten and apply each unittest overlay FDT using
    of_overlay_fdt_apply().

  - Enable the of_resolve_phandles() check for whether the unflattened
    overlay is detached.  This check was previously disabled because the
    overlays from tests-overlay.dtsi were not unflattened into detached
    trees.

  - Other changes to unittest.c infrastructure to manage multiple test
    FDTs built into the kernel image (access by name instead of
    arbitrary number).

  - of_unittest_overlay_high_level(): previously unused code to add
    properties from the overlay_base devicetree to the live tree
    was triggered by the restructuring of tests-overlay.dtsi and thus
    testcases.dts.  This exposed two bugs: (1) the need to dup a
    property before adding it, and (2) property 'name' is
    auto-generated in the unflatten code and thus will be a duplicate
    in the __symbols__ node - do not treat this duplicate as an error.

Signed-off-by: Frank Rowand <frank.rowand@sony.com>
2018-03-04 00:29:24 -08:00
Frank Rowand
581e929018 x86: devicetree: fix config option around x86_flattree_get_config()
x86_flattree_get_config() is incorrectly protected by
ifdef CONFIG_OF_FLATTREE.  It uses of_get_flat_dt_size(), which
only exists if CONFIG_OF_EARLY_FLATTREE.  This issue has not
been exposed previously because OF_FLATTREE did not occur unless
it was selected by OF_EARLY_FLATTREE.  A devicetree overlay change
is selecting OF_FLATTREE directly instead of indirectly enabling
it by selecting OF_EARLY_FLATTREE.

This problem was exposed by a randconfig generated by the kbuild
test robot, where Platform OLPC was enabled.  OLPC selects
OF_PROMTREE instead of OF_EARLY_FLATREE.  The only other x86
platform that selects OF is X86_INTEL_CE, which does select
OF_EARLY_FLATTREE.

Signed-off-by: Frank Rowand <frank.rowand@sony.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
2018-03-04 00:28:55 -08:00
Michal Wajdeczko
7b026763cf drm/i915/huc: Mark firmware as failed on auth failure
If we fail to authenticate HuC firmware, we should change
its load status to FAIL. While around, print HUC_STATUS
on firmware verification failure.

v2: keep the variables sorted by length (Chris)

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180302133718.1260-1-michal.wajdeczko@intel.com
2018-03-02 23:11:13 +00:00
Michal Wajdeczko
7cfca4afd6 drm/i915/uc: Introduce intel_uc_suspend|resume
We want to use higher level 'uc' functions as the main entry points to
the GuC/HuC code to hide some details and keep code layered.

While here, move call to disable_guc_interrupts after sending suspend
action to the GuC to allow it work also with CTB as comm mechanism.

v2: update commit msg (Sagar)

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180302111550.21328-1-michal.wajdeczko@intel.com
2018-03-02 23:11:12 +00:00
Chris Wilson
a3e3883646 drm/i915/execlists: Split spinlock from its irq disabling side-effect
During reset/wedging, we have to clean up the requests on the timeline
and flush the pending interrupt state. Currently, we are abusing the irq
disabling of the timeline spinlock to protect the irq state in
conjunction to the engine's timeline requests, but this is accidental
and conflates the spinlock with the irq state. A baffling state of
affairs for the reader.

Instead, explicitly disable irqs over the critical section, and separate
modifying the irq state from the timeline's requests.

Suggested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180302143246.2579-4-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
2018-03-02 23:11:12 +00:00
Chris Wilson
aebbc2d7b3 drm/i915/execlists: Move irq state manipulation inside irq disabled region
Although this state (execlists->active and engine->irq_posted) itself is
not protected by the engine->timeline spinlock, it does conveniently
ensure that irqs are disabled. We can use this to protect our
manipulation of the state and so ensure that the next IRQ to arrive sees
consistent state and (hopefully) ignores the reset engine.

Suggested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180302131246.22036-1-chris@chris-wilson.co.uk
2018-03-02 23:11:11 +00:00
Chris Wilson
963ddd63c3 drm/i915: Suspend submission tasklets around wedging
After staring hard at sequences like

[   28.199013]  systemd-1       2..s. 26062228us : execlists_submission_tasklet: rcs0 cs-irq head=0 [0?], tail=1 [1?]
[   28.199095]  systemd-1       2..s. 26062229us : execlists_submission_tasklet: rcs0 csb[1]: status=0x00000018:0x00000000, active=0x1
[   28.199177]  systemd-1       2..s. 26062230us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.1, seqno=3, prio=-1024
[   28.199258]  systemd-1       2..s. 26062231us : execlists_submission_tasklet: rcs0 completed ctx=0
[   28.199340]  gem_eio-829     1..s1 26066853us : execlists_submission_tasklet: rcs0 in[0]:  ctx=1.1, seqno=1, prio=0
[   28.199421]   <idle>-0       2..s. 26066863us : execlists_submission_tasklet: rcs0 cs-irq head=1 [1?], tail=2 [2?]
[   28.199503]   <idle>-0       2..s. 26066865us : execlists_submission_tasklet: rcs0 csb[2]: status=0x00000001:0x00000000, active=0x1
[   28.199585]  gem_eio-829     1..s1 26067077us : execlists_submission_tasklet: rcs0 in[1]:  ctx=3.1, seqno=2, prio=0
[   28.199667]  gem_eio-829     1..s1 26067078us : execlists_submission_tasklet: rcs0 in[0]:  ctx=1.2, seqno=1, prio=0
[   28.199749]   <idle>-0       2..s. 26067084us : execlists_submission_tasklet: rcs0 cs-irq head=2 [2?], tail=3 [3?]
[   28.199830]   <idle>-0       2..s. 26067085us : execlists_submission_tasklet: rcs0 csb[3]: status=0x00008002:0x00000001, active=0x1
[   28.199912]   <idle>-0       2..s. 26067086us : execlists_submission_tasklet: rcs0 out[0]: ctx=1.2, seqno=1, prio=0
[   28.199994]  gem_eio-829     2..s. 28246084us : execlists_submission_tasklet: rcs0 cs-irq head=3 [3?], tail=4 [4?]
[   28.200096]  gem_eio-829     2..s. 28246088us : execlists_submission_tasklet: rcs0 csb[4]: status=0x00000014:0x00000001, active=0x5
[   28.200178]  gem_eio-829     2..s. 28246089us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0, prio=0
[   28.200260]  gem_eio-829     2..s. 28246127us : execlists_submission_tasklet: execlists_submission_tasklet:886 GEM_BUG_ON(buf[2 * head + 1] != port->context_id)

the conclusion is that the only place where the ports are reset to zero,
is from engine->cancel_requests called during i915_gem_set_wedged().

The race is horrible as it results from calling set-wedged on active HW
(the GPU reset failed) and as such we need to be careful as the HW state
changes beneath us. Fortunately, it's the same scary conditions as
affect normal reset, so we can reuse the same machinery to disable state
tracking as we clobber it.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104945
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Fixes: af7a8ffad9 ("drm/i915: Use rcu instead of stop_machine in set_wedged")
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180302113324.23189-2-chris@chris-wilson.co.uk
2018-03-02 23:11:11 +00:00
Ville Syrjälä
32078b727d drm/i915: Deduplicate the code to fill the aux message header
We have two instances of the code to fill out the header for the aux
message. Pull it into a small helper.

v2: Rebase due to txbuf[] changes

Cc: Sean Paul <seanpaul@chromium.org>
Cc: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180222212802.4826-1-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
2018-03-02 18:26:52 +02:00
Ville Syrjälä
8159c796b6 drm/i915: Keep the AKSV details in intel_dp_hdcp_write_an_aksv()
Let's try to keep the details on the AKSV stuff concentrated
in one place. So move the control bit and +5 data size handling
there.

v2: Increase txbuf[] to include the payload which intel_dp_aux_xfer()
    will still load into the registers even though the hardware
    will ignore it

Cc: Sean Paul <seanpaul@chromium.org>
Cc: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180222212732.4665-1-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
2018-03-02 18:26:52 +02:00
Ville Syrjälä
f760626518 drm/i915: s/intel_dp_aux_ch/intel_dp_aux_xfer/
Rename intel_dp_aux_ch() to intel_dp_aux_xfer() to better convey
what it actually does.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180222181036.15251-6-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #irc
2018-03-02 18:26:52 +02:00
Imre Deak
fee0fddc1d drm/i915/gen9, gen10: Disable FBC on planes with a misaligned Y-offset
Enabling FBC on a plane having a Y-offset that isn't divisible by 4 may
cause pipe FIFO underruns and flickers, so disable FBC on such a config.

I tried the followings to work around the issue:
- enable each HW work around in ILK_DPFC_CHICKEN
- disable each compression algorithm in ILK_DPFC_CONTROL
- disable low-power watermarks
None of the above got rid of the problem. I haven't found this issue in
the Bspec/WA database either.

Besides the igt testcase below (yet to be merged) an easy way to
reproduce the issue is to enable a plane with FBC and a plane Y-offset
not aligned to 4 and then just enable/disable FBC in a loop, keeping the
plane enabled.

I could trigger the problem on BXT/GLK/SKL/CNL, so assume for now that it's
only present on GEN9 and GEN10.

v2: (Ville)
- Run the test/apply the WA on CNL as well.
- Use IS_GEN() instead of INTEL_GEN().
- Fix spelling.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Testcase: igt/kms_plane/plane-clipping-pipe-A-planes
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180301134457.13974-1-imre.deak@intel.com
2018-03-02 17:33:19 +02:00
Ville Syrjälä
c8624ede3e drm/i915: Add support for the YCbCr COLOR_RANGE property
Add support for the COLOR_RANGE property on planes. This property
selects whether the input YCbCr data is to treated as limited range
or full range.

On most platforms this is a matter of setting the "YUV range correction
disable" bit, and on VLV/CHV we'll just have to program the color
correction logic to pass the data through unmodified.

v2: Rebase

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-9-ville.syrjala@linux.intel.com
2018-03-02 14:49:10 +02:00
Ville Syrjälä
23b280890a drm/i915: Change the COLOR_ENCODING prop default value to BT.709
Bring us forward from the stone age and switch our default YCbCr->RGB
conversion matrix to BT.709 from BT.601. I would expect most matrial
to be BT.709 these days.

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Jyri Sarha <jsarha@ti.com>
Acked-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-8-ville.syrjala@linux.intel.com
2018-03-02 14:48:23 +02:00
Ville Syrjälä
b0f5c0badc drm/i915: Add support for the YCbCr COLOR_ENCODING property
Add support for the COLOR_ENCODING plane property which selects
the matrix coefficients used for the YCbCr->RGB conversion. Our
hardware can generally handle BT.601 and BT.709.

CHV pipe B sprites have a fully programmable matrix, so in theory
we could handle anything, but it doesn't seem all that useful to
expose anything beyond BT.601 and BT.709 at this time.

GLK can supposedly do BT.2020, but let's leave enabling that for
the future as well.

v2: Rename bit defines to match the spec more closely (Shashank)

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-7-ville.syrjala@linux.intel.com
2018-03-02 14:46:18 +02:00
Ville Syrjälä
38f24f21ae drm/i915: Fix plane YCbCr->RGB conversion for GLK
On GLK the plane CSC controls moved into the COLOR_CTL register.
Update the code to progam the YCbCr->RGB CSC mode correctly when
faced with an YCbCr framebuffer.

The spec is rather confusing as it calls the mode "YUV601 to RGB709".
I'm going to assume that just means it's going to use the YCbCr->RGB
matrix as specified in BT.601 and doesn't actually change the gamut.

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-6-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
2018-03-02 14:44:27 +02:00
Ville Syrjälä
5deae91911 drm/i915: Correctly handle limited range YCbCr data on VLV/CHV
Turns out the VLV/CHV fixed function sprite CSC expects full range
data as input. We've been feeding it limited range data to it all
along. To expand the data out to full range we'll use the color
correction registers (brightness, contrast, and saturation).

On CHV pipe B we were actually doing the right thing already because we
progammed the custom CSC matrix to do expect limited range input. Now
that well pre-expand the data out with the color correction unit, we
need to change the CSC matrix to operate with full range input instead.

This should make the sprite output of the other pipes match the sprite
output of pipe B reasonably well. Looking at the resulting pipe CRCs,
there can be a slight difference in the output, but as I don't know
the formula used by the fixed function CSC of the other pipes, I don't
think it's worth the effort to try to match the output exactly. It
might not even be possible due to difference in internal precision etc.

One slight caveat here is that the color correction registers are single
bufferred, so we should really be updating them during vblank, but we
still don't have a mechanism for that, so just toss in another FIXME.

v2: Rebase
v3: s/bri/brightness/ s/con/contrast/ (Shashank)
v4: Clarify the constants and math (Shashank)

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Jyri Sarha <jsarha@ti.com>
Cc: "Tang, Jun" <jun.tang@intel.com>
Reported-by: "Tang, Jun" <jun.tang@intel.com>
Cc: stable@vger.kernel.org
Fixes: 7f1f3851fe ("drm/i915: sprite support for ValleyView v4")
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-5-ville.syrjala@linux.intel.com
2018-03-02 14:42:27 +02:00
Ville Syrjälä
56dbbaff0f drm/atomic: Include color encoding/range in plane state dump
Include color_enconding and color_range in the plane state dump.

v2: Add kerneldoc (danvet)

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180219202846.10628-1-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Harry Wentland <harry.wentland@amd.com>
2018-03-02 14:41:21 +02:00
Jyri Sarha
80f690e9e3 drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane
Add a standard optional properties to support different non RGB color
encodings in DRM planes. COLOR_ENCODING select the supported non RGB
color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects
the value ranges within the selected color encoding. The properties
are stored to drm_plane object to allow different set of supported
encoding for different planes on the device.

v2: Add/fix kerneldocs, verify bitmasks (danvet)

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
[vsyrjala v2: Add/fix kerneldocs, verify bitmasks]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180219202823.10508-1-ville.syrjala@linux.intel.com
Acked-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2018-03-02 14:23:26 +02:00
Tvrtko Ursulin
c27557ab56 drm/i915: Wedged engine mask makes more sense in hex
In decimal its just a weird big number, while in hex can actually log
which engines were requested to be wedged.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180228171844.20006-1-tvrtko.ursulin@linux.intel.com
2018-03-02 11:56:47 +00:00
Sagar Arun Kamble
57312eaacd drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric
GuC load function is named intel_guc_fw_upload() and HuC load function is
named intel_huc_init_hw(). Make them consistent intel_*_fw_upload. Also
move HuC fw loading functions and declarations to separate files
intel_huc_fw.c|h like GuC.

While at this, do below changes
1. Update kernel-doc comment for intel_*_fw_upload() functions
2. s/huc_ucode_xfer/huc_fw_xfer
3. Introduce intel_huc_fw_init_early()

v2: Changed patch to update HuC functions instead of changing
    guc_fw_upload and update file structure. (Michal Wajdeczko)

v3: Added SPDX License identifier to huc_fw.c|h. (Michal Wajdeczko)

Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/1519922745-25441-1-git-send-email-sagar.a.kamble@intel.com
2018-03-02 09:04:45 +00:00
Jernej Skrabec
9ffef62f22
drm/sun4i: Allow building on arm64
64-bit ARM SoCs from Allwinner have DE2/TCON/HDMI periphery which
is compatible to 32-bit SoCs, so allow building DRM driver for
arm64 architecture.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180301213442.16677-14-jernej.skrabec@siol.net
2018-03-02 08:46:14 +01:00
Jernej Skrabec
4f86e81748
drm/sun4i: Add support for H3 HDMI PHY variant
While A83T HDMI PHY seems to be just customized Synopsys HDMI PHY, H3
HDMI PHY is completely custom PHY.

However, they still have many things in common like clock and reset
setup, setting sync polarity and more.

Add support for H3 HDMI PHY variant.

While documentation exists for this PHY variant, it doesn't go in great
details. Because of that, almost all settings are copied from BSP linux
4.4. Interestingly, those settings are slightly different to those found
in a older BSP with Linux 3.4. For now, no user visible difference was
found between them.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180301213442.16677-13-jernej.skrabec@siol.net
2018-03-02 08:45:49 +01:00
Jernej Skrabec
6876b160b7
drm/sun4i: Move and expand DW HDMI PHY register macros
DW HDMI PHY macros are moved to header file and expanded with the
registers present on newer SoCs like H3 and H5.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180301213442.16677-12-jernej.skrabec@siol.net
2018-03-02 08:45:40 +01:00
Jernej Skrabec
6fd903102c
drm/sun4i: Add support for variants to DW HDMI PHY
There are multiple variants of DW HDMI PHYs in Allwinner SoCs. While
some things like clock and reset setup are the same, PHY configuration
differs a lot.

Split out code which is PHY specific to separate functions and create
a structure which holds pointers to those functions.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180301213442.16677-11-jernej.skrabec@siol.net
2018-03-02 08:45:29 +01:00
Jernej Skrabec
e420ccd66d
drm/sun4i: Fix polarity configuration for DW HDMI PHY
Current polarity configuration code is cleary wrong since it compares
same flag two times. However, even if flag name is fixed, it won't work
well for resolutions which have one polarity positive and another
negative.

Fix that by properly set each bit according to each polarity. Since
those two bits are not described in any documentation, relationships
were obtained by experimentation.

Fixes: b7c7436a5f ("drm/sun4i: Implement A83T HDMI driver")

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180301213442.16677-10-jernej.skrabec@siol.net
2018-03-02 08:45:22 +01:00
Jernej Skrabec
e679f4a13f
drm/sun4i: Add support for H3 mixer 0
This mixer supports 1 VI plane, 3 UI plane and HW scaling on all planes.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180301213442.16677-9-jernej.skrabec@siol.net
2018-03-02 08:45:14 +01:00
Jernej Skrabec
1ceb5f1b7d
drm/sun4i: Add support for H3 display engine
H3 display engine has two mixers which are connected to HDMI and TV
output.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180301213442.16677-8-jernej.skrabec@siol.net
2018-03-02 08:45:05 +01:00
Jernej Skrabec
ea750c4146
dt-bindings: display: sun4i-drm: Add compatibles for H3 HDMI pipeline
Add missing compatibles for H3 HDMI pipeline. These compatibles can also
be used with H5 SoC.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180301213442.16677-6-jernej.skrabec@siol.net
2018-03-02 08:44:52 +01:00
Maarten Lankhorst
8c58f73c48 drm/i915: Check for I915_MODE_FLAG_INHERITED before drm_atomic_helper_check_modeset
Moving the check upwards will mean we we no longer have to add planes
and connectors manually, because everything is handled correctly by
drm_atomic_helper_check_modeset() as intended.

[applied with whitespace changes to make sparse happy]
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180221092808.30060-1-maarten.lankhorst@linux.intel.com
2018-03-01 20:54:35 -05:00
Chris Wilson
ffed7bd236 drm/i915: Replace open-coded wait-for loop
Now that we can pass arbitrary commands into the base __wait_for()
macro, we can reimplement the open-coded wait-for inside
i915_gem_idle_work_handler() using the new macro. This means that instead
of using ktime, we now use jiffies, and benefit from the exponential sleep
backoff that allows a fast response if the HW settles quickly.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180301103338.5380-1-chris@chris-wilson.co.uk
2018-03-01 17:42:58 +00:00
Tom St Denis
9c5c71bbed drm/amd/amdgpu: Mask rptr as well in ring debugfs
The read/write pointers on sdma4 devices increment
beyond the ring size and should be masked.  Tested
on my Ryzen 2400G.

Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-01 12:04:17 -05:00
Monk Liu
a22144a58f drm/amdgpu: try again kiq access if not in IRQ(v4)
sometimes GPU is switched to other VFs and won't swich
back soon, so the kiq reg access will not signal within
a short period, instead of busy waiting a long time(MAX_KEQ_REG_WAIT)
and returning TMO we can istead sleep 5ms and try again
later (non irq context)

And since the waiting in kiq_r/weg is busy wait, so MAX_KIQ_REG_WAIT
shouldn't set to a long time, set it to 10ms is more appropriate.

if gpu already in reset state, don't retry the KIQ reg access
otherwise it would always hang because KIQ was already die usually.

v2:
replace schedule() with msleep() for the wait

v3:
use while loop for the wait repeating
use macros for the sleep period
more description for it

v4:
drop unused variable

Signed-off-by: Monk Liu <Monk.Liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com
Reviewed-by: Pixel Ding <Pixel.Ding@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-01 12:04:17 -05:00
Monk Liu
c41d1cf62d drm/amdgpu: cleanups for vram lost handling
1)create a routine "handle_vram_lost" to do the vram
recovery, and put it into amdgpu_device_reset/reset_sriov,
this way no need of the extra paramter to hold the
VRAM LOST information and the related macros can be removed.

3)show vram_recover failure if time out, and set TMO equal to
lockup_timeout if vram_recover is under SRIOV runtime mode.

4)report error if any ip reset failed for SR-IOV

Signed-off-by: Monk Liu <Monk.Liu@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-01 11:52:41 -05:00
Monk Liu
711826656b drm/amdgpu: stop all rings before doing gpu recover
found recover_vram_from_shadow sometimes get executed
in paralle with SDMA scheduler, should stop all
schedulers before doing gpu reset/recover

Signed-off-by: Monk Liu <Monk.Liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Tested-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-01 11:52:23 -05:00