Commit Graph

38348 Commits

Author SHA1 Message Date
Chris Wilson
d2dc94bce2 drm/i915: Skip unused fw_domains
Use find-first-set bitop to quickly scan through the fw_domains mask and
skip iterating over unused domains.

v2: Move the WARN into the caller, to prevent compiler warnings in
normal builds.

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/20170323101944.21627-4-chris@chris-wilson.co.uk
2017-03-23 10:22:02 +00:00
Chris Wilson
cb3600db6e drm/i915: Use correct fw_domains during reset
In the next patch we will begin to sanity check that we do not attempt
to obtain the forcewake on an unsupport domain. However, that is exactly
what we do during reset of the fw_domains - rectify it before it explodes.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170323101944.21627-3-chris@chris-wilson.co.uk
2017-03-23 10:22:01 +00:00
Chris Wilson
bd52750485 drm/i915: Use correct fw_domains during initialisation
In the next patch we will begin to sanity check that we do not attempt
to obtain the forcewake on an unsupport domain. However, that is exactly
what we do during our actual initialisation of fw_domains - rectify it
before it explodes.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170323101944.21627-2-chris@chris-wilson.co.uk
2017-03-23 10:22:00 +00:00
Chris Wilson
577ac4bd4c drm/i915: Eliminate per-fw_domain i915 backpointer
Pass along the drm_i915_private pointer from the caller, rather than
looking it up from each fw_domain during fw_domains_get/_put. This
allows us to then eliminate the backpointer, in exchange for a more
complicated unwrapping procedure in the rare
intel_uncore_fw_release_timer().

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/20170323101944.21627-1-chris@chris-wilson.co.uk
2017-03-23 10:21:59 +00:00
Chris Wilson
5d4bac5503 drm/i915: Restore marking context objects as dirty on pinning
Commit e8a9c58fcd ("drm/i915: Unify active context tracking between
legacy/execlists/guc") converted the legacy intel_ringbuffer submission
to the same context pinning mechanism as execlists - that is to pin the
context until the subsequent request is retired. Previously it used the
vma retirement of the context object to keep itself pinned until the
next request (after i915_vma_move_to_active()). In the conversion, I
missed that the vma retirement was also responsible for marking the
object as dirty. Mark the context object as dirty when pinning
(equivalent to execlists) which ensures that if the context is swapped
out due to mempressure or suspend/hibernation, when it is loaded back in
it does so with the previous state (and not all zero).

Fixes: e8a9c58fcd ("drm/i915: Unify active context tracking between legacy/execlists/guc")
Reported-by: Dennis Gilmore <dennis@ausil.us>
Reported-by: Mathieu Marquer <mathieu.marquer@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99993
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100181
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.11-rc1
Link: http://patchwork.freedesktop.org/patch/msgid/20170322205930.12762-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2017-03-23 09:55:57 +00:00
Chris Wilson
e555e32645 drm/i915: Remove superfluous hw_flags from mi_set_context()
Why have both hw_flags and flags, when just one will do?

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170322210350.6208-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2017-03-23 09:43:14 +00:00
Chris Wilson
40149f00fb drm/i915: Actually pass the reclaim gfp_t along to shmemfs!
Words cannot describe the embarrassment at creating a new gfp_t relaim to
only prevent the oomkiller but allow direct|kswapd reclaim, and then not
use it in the shmem_read_mapping_page_gfp().

Fixes: 24f8e00a8a ("drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx allocations")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170322223447.7493-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-03-23 09:30:20 +00:00
Daniel Vetter
628d4c46ee Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux into drm-misc-next
Resync with drm-next, I have a patch which currently can't be applied
because drm-misc-next lacked the latest drm/i915 code.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2017-03-23 08:15:55 +01:00
Daniel Vetter
aa18bc8ddc Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queued
Backmerge drm-next to get at the hdmi2.0 helper functions.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2017-03-23 08:15:18 +01:00
Dave Airlie
65d1086c44 BackMerge tag 'v4.11-rc3' into drm-next
Linux 4.11-rc3 as requested by Daniel
2017-03-23 12:05:13 +10:00
Dave Airlie
d08997cb41 Merge tag 'drm-intel-fixes-2017-03-22' of git://anongit.freedesktop.org/git/drm-intel into drm-fixes
drm/i915 fixes for v4.11-rc4

* tag 'drm-intel-fixes-2017-03-22' of git://anongit.freedesktop.org/git/drm-intel:
  drm/i915: make context status notifier head be per engine
  drm/i915: Avoid rcu_barrier() from reclaim paths (shrinker)
  drm/i915/gvt: Fix gvt scheduler interval time
  drm/i915/gvt: GVT pin/unpin shadow context
  drm/i915/gvt: scan shadow indirect context image when valid
  drm/i915/kvmgt: fix suspicious rcu dereference usage
  drm/i915/gvt: add enable_execlists check before enable gvt
  drm/i915/gvt: Remove bogus retry around i915_wait_request
  drm/i915/gvt: correct the ggtt valid bit check in pipe control command
  drm/i915/gvt: replace the gvt_err with gvt_vgpu_err
  drm/i915/gvt: handle force-nonpriv registers, cmd parser part
  drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks
  drm/i915/glk: Remove MODULE_FIRMWARE() tag from Geminilake's DMC
  drm/i915: Reject HDMI 12bpc if the sink doesn't indicate support
  drm/i915: Always call i915_gem_reset_finish() following i915_gem_reset_prepare()
  drm/i915: Stop using RP_DOWN_EI on Baytrail
  drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters.
  drm/i915: Only enable hotplug interrupts if the display interrupts are enabled
  drm/i915: Disable engine->irq_tasklet around resets
  drm/i915: Split GEM resetting into 3 phases
2017-03-23 11:47:17 +10:00
Dave Airlie
edd849e544 Merge tag 'drm-misc-next-2017-03-21' of git://anongit.freedesktop.org/git/drm-misc into drm-next
drm-misc for 4.12, 2nd attempt this week:

- topic branch from Jon Corbet for the new graph kerneldoc support
- lots of graphs for kms/atomic things using the above
- some vblank query tuning from Chris
- gem/cma_fops macros
- moar docs

Driver stuff:
- vc4 hdmi audio, yay (Eric)
- dw-hdmi polish from a bunch of people
- some rockchip dp updates that didn't make last week (Chris Zhong)
- misc bridge&driver updates

* tag 'drm-misc-next-2017-03-21' of git://anongit.freedesktop.org/git/drm-misc: (37 commits)
  drm/edid: detect SCDC support in HF-VSDB
  drm/edid: detect SCDC support in HF-VSDB
  drm/edid: check for HF-VSDB block
  drm: Add SCDC helpers
  drm: bridge: dw-hdmi: add HDMI vendor specific infoframe config
  drm/bridge: dw_hdmi: support i2c extended read mode
  drm/msm: add stubs for msm_{perf,rd}_debugfs_cleanup
  drm: bochs: Don't remove uninitialized fbdev framebuffer
  drm: vc4: remove redundant check of plane being non-null
  drm/vc4: use platform_register_drivers
  dma-fence: add dma_fence_match_context helper
  drm/vc4: Add HDMI audio support
  dt-bindings: Document the dmas and dma-names properties for VC4 HDMI
  drm/atmel-hlcdc: Fix suspend/resume implementation
  drm: Skip the waitqueue setup for vblank queries
  drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)
  drm/doc: atomic overview, with graph
  drm/doc: diagram for mode objects and properties
  drm/doc: Consistent kerneldoc include order
  drm/doc: Add KMS overview graphs
  ...
2017-03-23 08:53:41 +10:00
Dave Airlie
be5df20a34 Merge tag 'drm-intel-next-2017-03-20' of git://anongit.freedesktop.org/git/drm-intel into drm-next
More in i915 for 4.12:

- designware i2c fixes from Hans de Goede, in a topic branch shared
  with other subsystems (maybe, they didn't confirm, but requested the
  pull)
- drop drm_panel usage from the intel dsi vbt panel (Jani)
- vblank evasion improvements and tracing (Maarten and Ville)
- clarify spinlock irq semantics again a bit (Tvrtko)
- new ->pwrite backend hook (right now just for shmem pageche writes),
  from Chris
- more planar/ccs work from Ville
- hotplug safe connector iterators everywhere
- userptr fixes (Chris)
- selftests for cache coloring eviction (Matthew Auld)
- extend debugfs drop_caches interface for shrinker testing (Chris)
- baytrail "the rps kills the machine" fix (Chris)
- use new atomic state iterators, a lot (Maarten)
- refactor guc/huc code some (Arkadiusz Hiler)
- tighten breadcrumbs rbtree a bit (Chris)
- improve wrap-around and time handling in rps residency counters
  (Mika)
- split reset-in-progress in two flags, backoff and handoff (Chris)
- other misc reset improvements from a few people
- bunch of vgpu interaction fixes with recent code changes
- misc stuff all over, as usual

* tag 'drm-intel-next-2017-03-20' of git://anongit.freedesktop.org/git/drm-intel: (144 commits)
  drm/i915: Update DRIVER_DATE to 20170320
  drm/i915: Initialise i915_gem_object_create_from_data() directly
  drm/i915: Correct error handling for i915_gem_object_create_from_data()
  drm/i915: i915_gem_object_create_from_data() doesn't require struct_mutex
  drm/i915: Retire an active batch pool object rather than allocate new
  drm/i915: Add i810/i815 pci-ids for completeness
  drm/i915: Skip execlists_dequeue() early if the list is empty
  drm/i915: Stop using obj->obj_exec_link outside of execbuf
  drm/i915: Squelch WARN for VLV_COUNTER_CONTROL
  drm/i915/glk: Enable pooled EUs for Geminilake
  drm/i915: Remove superfluous i915_add_request_no_flush() helper
  drm/i915/vgpu: Neuter forcewakes for VGPU more thoroughly
  drm/i915: Fix vGPU balloon for ggtt guard page
  drm/i915: Avoid use-after-free of ctx in request tracepoints
  drm/i915: Assert that the context pin_counts do not overflow
  drm/i915: Wait for reset to complete before returning from debugfs/i915_wedged
  drm/i915: Restore engine->submit_request before unwedging
  drm/i915: Move engine->submit_request selection to a vfunc
  drm/i915: Split I915_RESET_IN_PROGRESS into two flags
  drm/i915: make context status notifier head be per engine
  ...
2017-03-23 08:47:23 +10:00
Pandiyan, Dhinakaran
1e797f556c drm/dp: Split drm_dp_mst_allocate_vcpi
drm_dp_mst_allocate_vcpi() apart from setting up the vcpi structure,
also finds if there are enough slots available. This check is a duplicate
of that implemented in drm_dp_mst_find_vcpi_slots(). Let's move this check
out and reuse the existing drm_dp_mst_find_vcpi_slots() function to check
if there are enough vcpi slots before allocating them.

This brings the check to one place. Additionally drivers that will use MST
state tracking for atomic modesets can use the atomic version of
find_vcpi_slots() and reuse drm_dp_mst_allocate_vcpi()

Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1489648231-30700-4-git-send-email-dhinakaran.pandiyan@intel.com
2017-03-22 21:47:44 +01:00
Pandiyan, Dhinakaran
feb2c3bc33 drm/dp: Kill unused MST vcpi slot availability tracking
The avail_slots member in the MST topology manager is never updated to
reflect the available vcpi slots. The check is effectively against
total slots, 63. So, let's make that check obvious and remove
avail_slots. While at it, make debug messages more descriptive.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Harry Wentland <Harry.wentland@amd.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1489648231-30700-3-git-send-email-dhinakaran.pandiyan@intel.com
2017-03-22 21:46:41 +01:00
Pandiyan, Dhinakaran
a538d6137d drm/dp: Kill total_pbn and total_slots in struct drm_dp_mst_topology_mgr
The total vcpi time slots is always 63 and does not depend on the link BW,
remove total_slots from MST topology manager struct. The next change is to
remove total_pbn which is hardcoded to 2560. The total PBN that the
topology manager allocates from depends on the link rate and is not a
constant. So, fix this by removing the total_pbn member itself.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Harry Wentland <Harry.wentland@amd.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1489648231-30700-2-git-send-email-dhinakaran.pandiyan@intel.com
2017-03-22 21:46:21 +01:00
Ville Syrjälä
93aa2a1c25 drm/i915: Fix SKL cursor watermarks
Use intel_wm_plane_visible() to determine cursor visibility for SKL+
also. Previously SKL+ would check the actual visibility which now
conflicts with the assumptions in intel_legacy_cursor_update().

We also change SKL+ to compute the cursor watermarks based on the
unclipped cursor size, just as we do on all the other platforms.
Using the clipped size could now result in garbage results.

Testcase: igt/kms_chv_cursor_fail
Fixes: a5509abda4 ("drm/i915: Fix legacy cursor vs. watermarks for ILK-BDW")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100195
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170314151050.12194-2-ville.syrjala@linux.intel.com
Tested-by: Dorota Czaplejewicz <dorota.czaplejewicz@collabora.co.uk>
Tested-by: Jari Tahvanainen <jari.tahvanainen@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
2017-03-22 22:04:50 +02:00
Ville Syrjälä
24304d8193 drm/i915: Extract intel_wm_plane_visible()
All platforms that lack double buffered watermarks will need to
handle the legacy cursor updates in the same way. So let's extract the
logic to determine the plane visibility into a small helper. For
simplicity we'll make the function DTRT for any plane, but only apply
the special sauce for cursor planes.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170314151050.12194-1-ville.syrjala@linux.intel.com
Tested-by: Dorota Czaplejewicz <dorota.czaplejewicz@collabora.co.uk>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-03-22 22:04:50 +02:00
Chris Wilson
24f8e00a8a drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx allocations
Since gfx allocations tend to be large, unmovable and disposable, report
the allocation failure back to userspace as an ENOMEM rather than incur
the oomkiller. We have already tried to make room by purging our own
cached gfx objects, and the oomkiller doesn't attribute ownership of gfx
objects so will likely pick the wrong candidate. Instead, let userspace
see the ENOMEM.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170322110521.29930-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-03-22 19:26:46 +00:00
Paulo Zanoni
396a1200d8 drm/i915: simplify intel_ddi_pll_select()
Because {hsw,skl,bxt}_ddi_pll_select all pretty much do the same thing
in slightly different ways. Replace everything with a simple copy of
the function and inline it inside intle_ddi_pll_select().

v2: s/return pll/return pll != NULL/ (Ville)

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1490209125-20046-1-git-send-email-paulo.r.zanoni@intel.com
2017-03-22 16:08:54 -03:00
Pandiyan, Dhinakaran
8cbeb06dc6 drm/i915: Implement cdclk restrictions based on Azalia BCLK
According to BSpec, "The CD clock frequency must be at least twice the
frequency of the Azalia BCLK." and BCLK is configured to 96 MHz by
default. This check is needed because BXT and GLK support cdclk
frequencies less than 192 MHz.

v2: Include other Gen9 platforms too for completeness.(Paulo)

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489531556-2926-1-git-send-email-dhinakaran.pandiyan@intel.com
2017-03-22 16:05:11 -03:00
Pandiyan, Dhinakaran
78cfa580f8 drm/i915/glk: Apply cdclk workaround for DP audio
Implement the DP-Audio cdclk restriction for GLK, similar to what is
implemented for BDW and other GEN9 platforms. The max. pixel clock
adjustment for GLK, however factors in the 2 pixels per clock output that
GLK generates.

Separating min. cdclk and max. pixel_rate would be nicer, but let's
defer that to future and fix the GLK bug for now.

Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488931972-2865-1-git-send-email-dhinakaran.pandiyan@intel.com
2017-03-22 16:04:33 -03:00
Ville Syrjälä
6a0f9ebfc5 drm: Add mode_config .get_format_info() hook
Allow drivers to return a custom drm_format_info structure for special
fb layouts. We'll use this for the compression control surface in i915.

v2: Fix drm_get_format_info() kernel doc (Laurent)
    Don't pass 'dev' to the new hook (Laurent)
v3: s/compresssion/compression/ (Ben)

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Link: http://patchwork.freedesktop.org/patch/msgid/20170321181218.10042-4-ville.syrjala@linux.intel.com
2017-03-22 19:45:00 +02:00
Ville Syrjälä
33f673aa55 drm: Remove fb hsub/vsub alignment requirement
Allow framebuffers dimesions to be misaligned w.r.t. the subsampling
factors. No real reason the core should have to enforce this, and
it definitely starts to cause us issues with the i915 CCS support.
So let's just lift the restriction.

Let's start to round up when computing the color plane dimesions
so that we'll not end up with too low an estimate for the memory
requirements and whatnot.

Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170321181218.10042-3-ville.syrjala@linux.intel.com
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
2017-03-22 19:44:15 +02:00
Ville Syrjälä
568c5e4536 drm: Share the code to compute color plane dimesions
framebuffer_check() has some hand rolled code to compute the color plane
dimensions based on the subsampled information. Let's share the code
between framebuffer_check() and drm_framebuffer_plane_{width,height}().

Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170321181218.10042-2-ville.syrjala@linux.intel.com
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
2017-03-22 19:37:17 +02:00
Shawn Guo
eea54ed46e drm: zte: remove leftover 'inf' from struct zx_hdmi
There is a leftover 'inf' field in struct zx_hdmi from commit
'831a8d5e0bef ("drm: zte: move struct vou_inf into zx_vou driver")'.
Remove it.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1490086795-17925-1-git-send-email-shawnguo@kernel.org
2017-03-22 13:44:42 +08:00
Changbin Du
bc2d4b62db drm/i915/gvt: Use force single submit flag to distinguish gvt request from i915 request
In my previous Commit ab9da627906a ("drm/i915: make context status
notifier head be per engine") rely on scheduler->current_workload[x]
to distinguish gvt spacial request from i915 request. But this is
not always true since no synchronization between workload_thread and
lrc irq handler.

    lrc irq handler               workload_thread
         ----                          ----
  pick i915 requests;
                                intel_vgpu_submit_execlist();
                                current_workload[x] = xxx;
  shadow_context_status_change();

Then current_workload[x] is not null but current request is of i915 self.
So instead we check ctx flag CONTEXT_FORCE_SINGLE_SUBMISSION. Only gvt
request set this flag and always set.

v2: Reverse the order of multi-condition 'if' statement.

Fixes: ab9da6279 ("drm/i915: make context status notifier head be per engine")
Signed-off-by: Changbin Du <changbin.du@intel.com>
Reviewed-by: Yulei Zhang <yulei.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-03-22 13:18:56 +08:00
Tvrtko Ursulin
9f7886d07f drm/i915: Spinlocks in tasklets can use spin_(un)lock_irq
The tasklets callbacks are only called from tasklet context so
it is safe do to this.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170321105511.18269-1-tvrtko.ursulin@linux.intel.com
2017-03-21 15:04:55 +00:00
Changbin Du
590379aef2 drm/i915: make context status notifier head be per engine
GVTg has introduced the context status notifier to schedule the GVTg
workload. At that time, the notifier is bound to GVTg context only,
so GVTg is not aware of host workloads.

Now we are going to improve GVTg's guest workload scheduler policy,
and add Guc emulation support for new Gen graphics. Both these two
features require acknowledgment for all contexts running on hardware.
(But will not alter host workload.) So here try to make some change.

The change is simple:
  1. Move the context status notifier head from i915_gem_context to
     intel_engine_cs. Which means there is a notifier head per engine
     instead of per context. Execlist driver still call notifier for
     each context sched-in/out events of current engine.
  2. At GVTg side, it binds a notifier_block for each physical engine
     at GVTg initialization period. Then GVTg can hear all context
     status events.

In this patch, GVTg do nothing for host context event, but later
will add a function there. But in any case, the notifier callback is
a noop if this is no active vGPU.

Since intel_gvt_init() is called at early initialization stage and
require the status notifier head has been initiated, I initiate it in
intel_engine_setup().

v2: remove a redundant newline. (chris)

Fixes: 3c7ba6359d ("drm/i915: Introduce execlist context status change notification")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100232
Signed-off-by: Changbin Du <changbin.du@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170313024711.28591-1-changbin.du@intel.com
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 3fc03069bc)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170321144720.17020-1-chris@chris-wilson.co.uk
2017-03-21 16:51:47 +02:00
Chris Wilson
3d3d18f086 drm/i915: Avoid rcu_barrier() from reclaim paths (shrinker)
The rcu_barrier() takes the cpu_hotplug mutex which itself is not
reclaim-safe, and so rcu_barrier() is illegal from inside the shrinker.

[  309.661373] =========================================================
[  309.661376] [ INFO: possible irq lock inversion dependency detected ]
[  309.661380] 4.11.0-rc1-CI-CI_DRM_2333+ #1 Tainted: G        W
[  309.661383] ---------------------------------------------------------
[  309.661386] gem_exec_gttfil/6435 just changed the state of lock:
[  309.661389]  (rcu_preempt_state.barrier_mutex){+.+.-.}, at: [<ffffffff81100731>] _rcu_barrier+0x31/0x160
[  309.661399] but this lock took another, RECLAIM_FS-unsafe lock in the past:
[  309.661402]  (cpu_hotplug.lock){+.+.+.}
[  309.661404]

               and interrupts could create inverse lock ordering between them.

[  309.661410]
               other info that might help us debug this:
[  309.661414]  Possible interrupt unsafe locking scenario:

[  309.661417]        CPU0                    CPU1
[  309.661419]        ----                    ----
[  309.661421]   lock(cpu_hotplug.lock);
[  309.661425]                                local_irq_disable();
[  309.661432]                                lock(rcu_preempt_state.barrier_mutex);
[  309.661441]                                lock(cpu_hotplug.lock);
[  309.661446]   <Interrupt>
[  309.661448]     lock(rcu_preempt_state.barrier_mutex);
[  309.661453]
                *** DEADLOCK ***

[  309.661460] 4 locks held by gem_exec_gttfil/6435:
[  309.661464]  #0:  (sb_writers#10){.+.+.+}, at: [<ffffffff8120d83d>] vfs_write+0x17d/0x1f0
[  309.661475]  #1:  (debugfs_srcu){......}, at: [<ffffffff81320491>] debugfs_use_file_start+0x41/0xa0
[  309.661486]  #2:  (&attr->mutex){+.+.+.}, at: [<ffffffff8123a3e7>] simple_attr_write+0x37/0xe0
[  309.661495]  #3:  (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0091b4a>] i915_drop_caches_set+0x3a/0x150 [i915]
[  309.661540]
               the shortest dependencies between 2nd lock and 1st lock:
[  309.661547]  -> (cpu_hotplug.lock){+.+.+.} ops: 829 {
[  309.661553]     HARDIRQ-ON-W at:
[  309.661560]                       __lock_acquire+0x5e5/0x1b50
[  309.661565]                       lock_acquire+0xc9/0x220
[  309.661572]                       __mutex_lock+0x6e/0x990
[  309.661576]                       mutex_lock_nested+0x16/0x20
[  309.661583]                       get_online_cpus+0x61/0x80
[  309.661590]                       kmem_cache_create+0x25/0x1d0
[  309.661596]                       debug_objects_mem_init+0x30/0x249
[  309.661602]                       start_kernel+0x341/0x3fe
[  309.661607]                       x86_64_start_reservations+0x2a/0x2c
[  309.661612]                       x86_64_start_kernel+0x173/0x186
[  309.661619]                       verify_cpu+0x0/0xfc
[  309.661622]     SOFTIRQ-ON-W at:
[  309.661627]                       __lock_acquire+0x611/0x1b50
[  309.661632]                       lock_acquire+0xc9/0x220
[  309.661636]                       __mutex_lock+0x6e/0x990
[  309.661641]                       mutex_lock_nested+0x16/0x20
[  309.661646]                       get_online_cpus+0x61/0x80
[  309.661650]                       kmem_cache_create+0x25/0x1d0
[  309.661655]                       debug_objects_mem_init+0x30/0x249
[  309.661660]                       start_kernel+0x341/0x3fe
[  309.661664]                       x86_64_start_reservations+0x2a/0x2c
[  309.661669]                       x86_64_start_kernel+0x173/0x186
[  309.661674]                       verify_cpu+0x0/0xfc
[  309.661677]     RECLAIM_FS-ON-W at:
[  309.661682]                          mark_held_locks+0x6f/0xa0
[  309.661687]                          lockdep_trace_alloc+0xb3/0x100
[  309.661693]                          kmem_cache_alloc_trace+0x31/0x2e0
[  309.661699]                          __smpboot_create_thread.part.1+0x27/0xe0
[  309.661704]                          smpboot_create_threads+0x61/0x90
[  309.661709]                          cpuhp_invoke_callback+0x9c/0x8a0
[  309.661713]                          cpuhp_up_callbacks+0x31/0xb0
[  309.661718]                          _cpu_up+0x7a/0xc0
[  309.661723]                          do_cpu_up+0x5f/0x80
[  309.661727]                          cpu_up+0xe/0x10
[  309.661734]                          smp_init+0x71/0xb3
[  309.661738]                          kernel_init_freeable+0x94/0x19e
[  309.661743]                          kernel_init+0x9/0xf0
[  309.661748]                          ret_from_fork+0x2e/0x40
[  309.661752]     INITIAL USE at:
[  309.661757]                      __lock_acquire+0x234/0x1b50
[  309.661761]                      lock_acquire+0xc9/0x220
[  309.661766]                      __mutex_lock+0x6e/0x990
[  309.661771]                      mutex_lock_nested+0x16/0x20
[  309.661775]                      get_online_cpus+0x61/0x80
[  309.661780]                      __cpuhp_setup_state+0x44/0x170
[  309.661785]                      page_alloc_init+0x23/0x3a
[  309.661790]                      start_kernel+0x124/0x3fe
[  309.661794]                      x86_64_start_reservations+0x2a/0x2c
[  309.661799]                      x86_64_start_kernel+0x173/0x186
[  309.661804]                      verify_cpu+0x0/0xfc
[  309.661807]   }
[  309.661813]   ... key      at: [<ffffffff81e37690>] cpu_hotplug+0xb0/0x100
[  309.661817]   ... acquired at:
[  309.661821]    lock_acquire+0xc9/0x220
[  309.661825]    __mutex_lock+0x6e/0x990
[  309.661829]    mutex_lock_nested+0x16/0x20
[  309.661833]    get_online_cpus+0x61/0x80
[  309.661837]    _rcu_barrier+0x9f/0x160
[  309.661841]    rcu_barrier+0x10/0x20
[  309.661847]    netdev_run_todo+0x5f/0x310
[  309.661852]    rtnl_unlock+0x9/0x10
[  309.661856]    default_device_exit_batch+0x133/0x150
[  309.661862]    ops_exit_list.isra.0+0x4d/0x60
[  309.661866]    cleanup_net+0x1d8/0x2c0
[  309.661872]    process_one_work+0x1f4/0x6d0
[  309.661876]    worker_thread+0x49/0x4a0
[  309.661881]    kthread+0x107/0x140
[  309.661884]    ret_from_fork+0x2e/0x40

[  309.661890] -> (rcu_preempt_state.barrier_mutex){+.+.-.} ops: 179 {
[  309.661896]    HARDIRQ-ON-W at:
[  309.661901]                     __lock_acquire+0x5e5/0x1b50
[  309.661905]                     lock_acquire+0xc9/0x220
[  309.661910]                     __mutex_lock+0x6e/0x990
[  309.661914]                     mutex_lock_nested+0x16/0x20
[  309.661919]                     _rcu_barrier+0x31/0x160
[  309.661923]                     rcu_barrier+0x10/0x20
[  309.661928]                     netdev_run_todo+0x5f/0x310
[  309.661932]                     rtnl_unlock+0x9/0x10
[  309.661936]                     default_device_exit_batch+0x133/0x150
[  309.661941]                     ops_exit_list.isra.0+0x4d/0x60
[  309.661946]                     cleanup_net+0x1d8/0x2c0
[  309.661951]                     process_one_work+0x1f4/0x6d0
[  309.661955]                     worker_thread+0x49/0x4a0
[  309.661960]                     kthread+0x107/0x140
[  309.661964]                     ret_from_fork+0x2e/0x40
[  309.661968]    SOFTIRQ-ON-W at:
[  309.661972]                     __lock_acquire+0x611/0x1b50
[  309.661977]                     lock_acquire+0xc9/0x220
[  309.661981]                     __mutex_lock+0x6e/0x990
[  309.661986]                     mutex_lock_nested+0x16/0x20
[  309.661990]                     _rcu_barrier+0x31/0x160
[  309.661995]                     rcu_barrier+0x10/0x20
[  309.661999]                     netdev_run_todo+0x5f/0x310
[  309.662003]                     rtnl_unlock+0x9/0x10
[  309.662008]                     default_device_exit_batch+0x133/0x150
[  309.662013]                     ops_exit_list.isra.0+0x4d/0x60
[  309.662017]                     cleanup_net+0x1d8/0x2c0
[  309.662022]                     process_one_work+0x1f4/0x6d0
[  309.662027]                     worker_thread+0x49/0x4a0
[  309.662031]                     kthread+0x107/0x140
[  309.662035]                     ret_from_fork+0x2e/0x40
[  309.662039]    IN-RECLAIM_FS-W at:
[  309.662043]                        __lock_acquire+0x638/0x1b50
[  309.662048]                        lock_acquire+0xc9/0x220
[  309.662053]                        __mutex_lock+0x6e/0x990
[  309.662058]                        mutex_lock_nested+0x16/0x20
[  309.662062]                        _rcu_barrier+0x31/0x160
[  309.662067]                        rcu_barrier+0x10/0x20
[  309.662089]                        i915_gem_shrink_all+0x33/0x40 [i915]
[  309.662109]                        i915_drop_caches_set+0x141/0x150 [i915]
[  309.662114]                        simple_attr_write+0xc7/0xe0
[  309.662119]                        full_proxy_write+0x4f/0x70
[  309.662124]                        __vfs_write+0x23/0x120
[  309.662128]                        vfs_write+0xc6/0x1f0
[  309.662133]                        SyS_write+0x44/0xb0
[  309.662138]                        entry_SYSCALL_64_fastpath+0x1c/0xb1
[  309.662142]    INITIAL USE at:
[  309.662147]                    __lock_acquire+0x234/0x1b50
[  309.662151]                    lock_acquire+0xc9/0x220
[  309.662156]                    __mutex_lock+0x6e/0x990
[  309.662160]                    mutex_lock_nested+0x16/0x20
[  309.662165]                    _rcu_barrier+0x31/0x160
[  309.662169]                    rcu_barrier+0x10/0x20
[  309.662174]                    netdev_run_todo+0x5f/0x310
[  309.662178]                    rtnl_unlock+0x9/0x10
[  309.662183]                    default_device_exit_batch+0x133/0x150
[  309.662188]                    ops_exit_list.isra.0+0x4d/0x60
[  309.662192]                    cleanup_net+0x1d8/0x2c0
[  309.662197]                    process_one_work+0x1f4/0x6d0
[  309.662202]                    worker_thread+0x49/0x4a0
[  309.662206]                    kthread+0x107/0x140
[  309.662210]                    ret_from_fork+0x2e/0x40
[  309.662214]  }
[  309.662220]  ... key      at: [<ffffffff81e4e1c8>] rcu_preempt_state+0x508/0x780
[  309.662225]  ... acquired at:
[  309.662229]    check_usage_forwards+0x12b/0x130
[  309.662233]    mark_lock+0x360/0x6f0
[  309.662237]    __lock_acquire+0x638/0x1b50
[  309.662241]    lock_acquire+0xc9/0x220
[  309.662245]    __mutex_lock+0x6e/0x990
[  309.662249]    mutex_lock_nested+0x16/0x20
[  309.662253]    _rcu_barrier+0x31/0x160
[  309.662257]    rcu_barrier+0x10/0x20
[  309.662279]    i915_gem_shrink_all+0x33/0x40 [i915]
[  309.662298]    i915_drop_caches_set+0x141/0x150 [i915]
[  309.662303]    simple_attr_write+0xc7/0xe0
[  309.662307]    full_proxy_write+0x4f/0x70
[  309.662311]    __vfs_write+0x23/0x120
[  309.662315]    vfs_write+0xc6/0x1f0
[  309.662319]    SyS_write+0x44/0xb0
[  309.662323]    entry_SYSCALL_64_fastpath+0x1c/0xb1

[  309.662329]
               stack backtrace:
[  309.662335] CPU: 1 PID: 6435 Comm: gem_exec_gttfil Tainted: G        W       4.11.0-rc1-CI-CI_DRM_2333+ #1
[  309.662342] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011
[  309.662348] Call Trace:
[  309.662354]  dump_stack+0x67/0x92
[  309.662359]  print_irq_inversion_bug.part.19+0x1a4/0x1b0
[  309.662365]  check_usage_forwards+0x12b/0x130
[  309.662369]  mark_lock+0x360/0x6f0
[  309.662374]  ? print_shortest_lock_dependencies+0x1a0/0x1a0
[  309.662379]  __lock_acquire+0x638/0x1b50
[  309.662383]  ? __mutex_unlock_slowpath+0x3e/0x2e0
[  309.662388]  ? trace_hardirqs_on+0xd/0x10
[  309.662392]  ? _rcu_barrier+0x31/0x160
[  309.662396]  lock_acquire+0xc9/0x220
[  309.662400]  ? _rcu_barrier+0x31/0x160
[  309.662404]  ? _rcu_barrier+0x31/0x160
[  309.662409]  __mutex_lock+0x6e/0x990
[  309.662412]  ? _rcu_barrier+0x31/0x160
[  309.662416]  ? _rcu_barrier+0x31/0x160
[  309.662421]  ? synchronize_rcu_expedited+0x35/0xb0
[  309.662426]  ? _raw_spin_unlock_irqrestore+0x52/0x60
[  309.662434]  mutex_lock_nested+0x16/0x20
[  309.662438]  _rcu_barrier+0x31/0x160
[  309.662442]  rcu_barrier+0x10/0x20
[  309.662464]  i915_gem_shrink_all+0x33/0x40 [i915]
[  309.662484]  i915_drop_caches_set+0x141/0x150 [i915]
[  309.662489]  simple_attr_write+0xc7/0xe0
[  309.662494]  full_proxy_write+0x4f/0x70
[  309.662498]  __vfs_write+0x23/0x120
[  309.662503]  ? rcu_read_lock_sched_held+0x75/0x80
[  309.662507]  ? rcu_sync_lockdep_assert+0x2a/0x50
[  309.662512]  ? __sb_start_write+0x102/0x210
[  309.662516]  ? vfs_write+0x17d/0x1f0
[  309.662520]  vfs_write+0xc6/0x1f0
[  309.662524]  ? trace_hardirqs_on_caller+0xe7/0x200
[  309.662529]  SyS_write+0x44/0xb0
[  309.662533]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[  309.662537] RIP: 0033:0x7f507eac24a0
[  309.662541] RSP: 002b:00007fffda8720e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[  309.662548] RAX: ffffffffffffffda RBX: ffffffff81482bd3 RCX: 00007f507eac24a0
[  309.662552] RDX: 0000000000000005 RSI: 00007fffda8720f0 RDI: 0000000000000005
[  309.662557] RBP: ffffc9000048bf88 R08: 0000000000000000 R09: 000000000000002c
[  309.662561] R10: 0000000000000014 R11: 0000000000000246 R12: 00007fffda872230
[  309.662566] R13: 00007fffda872228 R14: 0000000000000201 R15: 00007fffda8720f0
[  309.662572]  ? __this_cpu_preempt_check+0x13/0x20

Fixes: 0eafec6d32 ("drm/i915: Enable lockless lookup of request tracking via RCU")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100192
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org> # v4.9+
Link: http://patchwork.freedesktop.org/patch/msgid/20170314115019.18127-1-chris@chris-wilson.co.uk
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit bd784b7cc4)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170321144531.12344-1-chris@chris-wilson.co.uk
2017-03-21 16:50:19 +02:00
Chris Wilson
fe085f13c7 drm/i915: Remove intel_ring.last_retired_head
Storing the position of the breadcrumb of the last retired request as
a separate last_retired_head is superfluous as we always copy that into
head prior to recalculation of the intel_ring.space.

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/20170321102552.24357-1-chris@chris-wilson.co.uk
2017-03-21 14:21:50 +00:00
Chris Wilson
899f6204c0 drm/i915/execlists: Split the atomic test_and_clear_bit for irq handler
Rather than impose the cost of a locked test before queuing a new
request, reduce it to a simple test_bit() with a following clear_bit()
prior to doing the CSB check. This ensure that if an interrupt does
occur whilst reading from the CSB, we still detect it (the interrupt
would trigger a rescheduling of the tasklet anyway).

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170321113320.2603-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2017-03-21 14:14:55 +00:00
Arnd Bergmann
272bce17cc drm/i915: split out check for noncontiguous pfn range
We get a warning with gcc-7 about a pointless comparison when
using a linear memmap:

drivers/gpu/drm/i915/selftests/scatterlist.c: In function 'alloc_table':
drivers/gpu/drm/i915/selftests/scatterlist.c:219:66: error: self-comparison always evaluates to false [-Werror=tautological-compare]

Splitting out the comparison into a separate function avoids the warning
and makes it slightly more obvious what happens.

Fixes: 935a2f776a ("drm/i915: Add some selftests for sg_table manipulation")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20170320094335.1266306-2-arnd@arndb.de
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-03-21 10:22:42 +00:00
Chris Wilson
24caf65593 drm/i915: intel_engine_init_global_seqno() requires atomic kmap
As intel_engine_init_global_seqno() may be called by
nop_submit_request() from inside irq context, we have to use atomic
versions of kmap/kunmap. This is rare as this requires using gen8 legacy
ringbuffer submission.

Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170320145609.4898-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2017-03-21 09:21:14 +00:00
Chris Wilson
467221bc60 drm/i915: Protect intel_engine_wakeup() for call from irq context
intel_engine_wakeup() is called by nop_request_submit() which is
installed to handle third party fences completed from within irq
context. As such, it needs the full irqsave/irqrestore and not the
partial spin_irq_lock handling.

[18942.714467] =================================
[18942.719076] [ INFO: inconsistent lock state ]
[18942.723522] 4.11.0-rc2-CI-CI_DRM_2368+ #1 Tainted: G     U  W
[18942.729970] ---------------------------------
[18942.734466] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
[18942.740594] gem_eio/1275 [HC0[0]:SC0[0]:HE1:SE1] takes:
[18942.745932]  (&(&fence->lock)->rlock){+.?...}, at: [<ffffffff815ec100>] dma_fence_signal+0x100/0x
230
[18942.755331] {IN-SOFTIRQ-W} state was registered at:
[18942.760356]   __lock_acquire+0x5d0/0x1bb0
[18942.764444]   lock_acquire+0xc9/0x220
[18942.768196]   _raw_spin_lock_irqsave+0x41/0x60
[18942.772747]   dma_fence_signal+0x100/0x230
[18942.776927]   vgem_fence_timeout+0x9/0x10 [vgem]
[18942.781701]   call_timer_fn+0x92/0x380
[18942.785557]   expire_timers+0x150/0x1f0
[18942.789491]   run_timer_softirq+0x7c/0x160
[18942.793705]   __do_softirq+0x116/0x4c0
[18942.797560]   irq_exit+0xa9/0xc0
[18942.800873]   smp_apic_timer_interrupt+0x38/0x50
[18942.805611]   apic_timer_interrupt+0x90/0xa0
[18942.810008]   cpuidle_enter_state+0x135/0x380
[18942.814503]   cpuidle_enter+0x12/0x20
[18942.818250]   call_cpuidle+0x1e/0x40
[18942.821906]   do_idle+0x17e/0x1f0
[18942.825333]   cpu_startup_entry+0x18/0x20
[18942.829463]   rest_init+0x127/0x130
[18942.833025]   start_kernel+0x3f1/0x3fe
[18942.836908]   x86_64_start_reservations+0x2a/0x2c
[18942.841733]   x86_64_start_kernel+0x173/0x186
[18942.846234]   verify_cpu+0x0/0xfc
[18942.849604] irq event stamp: 30568
[18942.853140] hardirqs last  enabled at (30567): [<ffffffff8110b81f>] ktime_get+0xef/0x120
[18942.861468] hardirqs last disabled at (30568): [<ffffffff81876377>] _raw_spin_lock_irqsave+0x17/0
x60
[18942.870812] softirqs last  enabled at (30462): [<ffffffff81085cd9>] __do_softirq+0x1d9/0x4c0
[18942.879443] softirqs last disabled at (30439): [<ffffffff81086139>] irq_exit+0xa9/0xc0
[18942.887616]
[18942.887616] other info that might help us debug this:
[18942.894279]  Possible unsafe locking scenario:
[18942.894279]
[18942.900336]        CPU0
[18942.902851]        ----
[18942.905362]   lock(&(&fence->lock)->rlock);
[18942.909647]   <Interrupt>
[18942.912330]     lock(&(&fence->lock)->rlock);
[18942.916821]
[18942.916821]  *** DEADLOCK ***
[18942.916821]
[18942.922862] 1 lock held by gem_eio/1275:
[18942.926859]  #0:  (&(&fence->lock)->rlock){+.?...}, at: [<ffffffff815ec100>] dma_fence_signal+0x1
00/0x230
[18942.936651]
[18942.936651] stack backtrace:
[18942.941142] CPU: 3 PID: 1275 Comm: gem_eio Tainted: G     U  W       4.11.0-rc2-CI-CI_DRM_2368+ #
1
[18942.950367] Hardware name: Gigabyte Technology Co., Ltd. Z170X-UD5/Z170X-UD5-CF, BIOS F21 01/06/2
017
[18942.959756] Call Trace:
[18942.962244]  dump_stack+0x67/0x92
[18942.965626]  print_usage_bug.part.23+0x259/0x268
[18942.970362]  mark_lock+0x12c/0x6f0
[18942.973851]  ? check_usage_forwards+0x130/0x130
[18942.978487]  mark_held_locks+0x6f/0xa0
[18942.982329]  ? _raw_spin_unlock_irq+0x27/0x50
[18942.986797]  trace_hardirqs_on_caller+0x150/0x200
[18942.991599]  trace_hardirqs_on+0xd/0x10
[18942.995515]  _raw_spin_unlock_irq+0x27/0x50
[18942.999796]  intel_engine_wakeup+0x26/0x30 [i915]
[18943.004670]  intel_engine_init_global_seqno+0x131/0x1a0 [i915]
[18943.010745]  nop_submit_request+0x2e/0x40 [i915]
[18943.015476]  submit_notify+0x3f/0x5c [i915]
[18943.019763]  __i915_sw_fence_complete+0x176/0x220 [i915]
[18943.025234]  ? try_to_del_timer_sync+0x4d/0x60
[18943.029825]  i915_sw_fence_complete+0x25/0x40 [i915]
[18943.034887]  dma_i915_sw_fence_wake+0x26/0x60 [i915]
[18943.039959]  dma_fence_signal+0x146/0x230
[18943.044109]  vgem_fence_signal_ioctl+0x6c/0xc0 [vgem]
[18943.049275]  drm_ioctl+0x200/0x450
[18943.052758]  ? vgem_fence_attach_ioctl+0x270/0x270 [vgem]
[18943.058334]  do_vfs_ioctl+0x90/0x6e0
[18943.061991]  ? entry_SYSCALL_64_fastpath+0x5/0xb1
[18943.066843]  ? __this_cpu_preempt_check+0x13/0x20
[18943.071643]  ? trace_hardirqs_on_caller+0xe7/0x200
[18943.076532]  SyS_ioctl+0x3c/0x70
[18943.079842]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[18943.084558] RIP: 0033:0x7f0dfcc14357
[18943.088240] RSP: 002b:00007ffeb4628da8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[18943.095996] RAX: ffffffffffffffda RBX: ffffffff8147eb93 RCX: 00007f0dfcc14357
[18943.103311] RDX: 00007ffeb4628de0 RSI: 0000000040086442 RDI: 0000000000000005
[18943.110574] RBP: ffffc9000176ff88 R08: 0000000000000004 R09: 0000000000000000
[18943.117845] R10: 0000000000000029 R11: 0000000000000246 R12: 0000000000000001
[18943.125168] R13: 0000000000000005 R14: 0000000040086442 R15: 0000000000000000
[18943.132520]  ? __this_cpu_preempt_check+0x13/0x20

Fixes: cdc3a45390 ("drm/i915: No need to save/restore irq status in intel_engine_wakeup")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170320143133.1507-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2017-03-21 09:20:07 +00:00
Tvrtko Ursulin
66e303e988 drm/i915/guc: Correct the request_in tracepoint position
It has to be called after the global seqno has been assigned.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: 31de73501a ("drm/i915/scheduler: emulate a scheduler for guc")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170320132556.29286-1-tvrtko.ursulin@linux.intel.com
2017-03-21 08:16:57 +00:00
Shashank Sharma
62c58af32c drm/edid: detect SCDC support in HF-VSDB
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
  This structure will be used to save and indicate if sink
  supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
  reflect scdc support and capabilities in connected HDMI 2.0 sink.
- Checks the HF-VSDB block for presence of SCDC, and marks it
  in scdc structure
- If SCDC is present, checks if sink is capable of generating
  SCDC read request, and marks it in scdc structure.

V2: Addressed review comments
  Thierry:
  - Fix typos in commit message and make abbreviation consistent
    across the commit message.
  - Change structure object name from hdmi_info -> hdmi
  - Fix typos and abbreviations in description of structure drm_hdmi_info
    end the description with a full stop.
  - Create a structure drm_scdc, and keep all information related to SCDC
    register set (supported, read request supported) etc in it.

  Ville:
  - Change rr -> read_request
  - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
    of HF-VSDB parsing can be kept in same function, in incremental
    patches.

V3: Rebase.
V4: Rebase.
V5: Rebase.
V6: Addressed review comments from Ville
  - Add clock rate calculations for 1/10 and 1/40 ratios
  - Remove leftovers from old patchset
V7: Added R-B from Jose.
V8: Rebase.
V9: Rebase.
V10: Rebase.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Jose Abreu <joabreu@synopsys.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-5-git-send-email-shashank.sharma@intel.com
2017-03-21 10:15:56 +02:00
Shashank Sharma
afa1c76365 drm/edid: detect SCDC support in HF-VSDB
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
  This structure will be used to save and indicate if sink
  supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
  reflect scdc support and capabilities in connected HDMI 2.0 sink.
- Checks the HF-VSDB block for presence of SCDC, and marks it
  in scdc structure
- If SCDC is present, checks if sink is capable of generating
  SCDC read request, and marks it in scdc structure.

V2: Addressed review comments
 Thierry:
 - Fix typos in commit message and make abbreviation consistent
   across the commit message.
 - Change structure object name from hdmi_info -> hdmi
 - Fix typos and abbreviations in description of structure drm_hdmi_info
   end the description with a full stop.
 - Create a structure drm_scdc, and keep all information related to SCDC
   register set (supported, read request supported) etc in it.

Ville:
 - Change rr -> read_request
 - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
   of HF-VSDB parsing can be kept in same function, in incremental
   patches.

V3: Rebase.
V4: Rebase.
V5: Rebase.
V6: Rebase.
V7: Added R-B from Jose.
V8: Rebase.
V9: Rebase.
V10: Rebase.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Jose Abreu <joabreu@synopsys.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-4-git-send-email-shashank.sharma@intel.com
2017-03-21 10:15:51 +02:00
Thierry Reding
50dd1bd1e2 drm/edid: check for HF-VSDB block
This patch implements a small function that finds if a
given CEA db is hdmi-forum vendor specific data block
or not.

V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
V5: Rebase
V6: Rebase
V7: Rebase
V8: Rebase
V9: Rebase
V10: Rebase

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Jose Abreu <joabreu@synopsys.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-3-git-send-email-shashank.sharma@intel.com
2017-03-21 10:15:47 +02:00
Thierry Reding
3ad33ae2bc drm: Add SCDC helpers
SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.

This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.

V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
V5: Addressed review comments from Ville
 - Handle the I2c return values in a better way (dp_dual_mode)
 - Make the macros for SCDC Major/Minor more readable, by adding
   a 'GET' in the macro names
V6: Rebase
V7: Rebase
V8: Rebase
V9: Rebase
V10: Rebase

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Jose Abreu <joabreu@synopsys.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-2-git-send-email-shashank.sharma@intel.com
2017-03-21 10:15:39 +02:00
Nickey Yang
9aa1eca095 drm: bridge: dw-hdmi: add HDMI vendor specific infoframe config
Vendor specific infoframe is mandatory for 4K2K resolution.
Without this, the HDMI protocol compliance fails.

Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Reviewed-by: Jose Abreu <joabreu@synopsys.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1490081777-2232-1-git-send-email-nickey.yang@rock-chips.com
2017-03-21 13:16:32 +05:30
Nickey Yang
94bb4dc132 drm/bridge: dw_hdmi: support i2c extended read mode
"I2C Master Interface Extended Read Mode" implements a segment
pointer-based read operation using the Special Register configuration.

This patch fix https://patchwork.kernel.org/patch/7098101/ mentioned
"The current implementation does not support "I2C Master Interface
Extended Read Mode" to read data addressed by non-zero segment
pointer, this means that if EDID has more than 1 extension blocks,
EDID reading operation won't succeed"

With this patch, dw-hdmi can read EDID data with 1/2/4 blocks.

Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1489978651-16647-1-git-send-email-nickey.yang@rock-chips.com
2017-03-21 13:15:32 +05:30
Andrzej Hajda
22e098daae drm/exynos/dsi: make te-gpios optional
DSI forwards te-gpios interrupts to display controller, but if display
controller works in HW-TRIGGER mode this interrupt is not necessary.
Making te-gpios property optional allows to avoid generating spare
interrupts.
And also if panel device node of command mode panel device doesn't provide
te-gpios property then the panel driver failed to probe. This was a critial
issue.

With this patch we can not only get rid of 60 interrupt callbacks per second
but also fix the critial issues.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-03-21 14:30:18 +09:00
Krzysztof Kozlowski
9cdf0ed25a drm/exynos: Print kernel pointers in a restricted form
Printing raw kernel pointers might reveal information which sometimes we
try to hide (e.g. with Kernel Address Space Layout Randomization).  Use
the "%pK" format so these pointers will be hidden for unprivileged
users.

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-03-21 13:17:22 +09:00
Andrzej Hajda
f07d9c2864 drm/exynos/decon5433: fix software trigger mask
The patch fixes copy/paste bug introduced during code refactoring.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: b93c2e8b5d ("drm/exynos/decon5433: configure sysreg in case of hardware trigger")Fixes:
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-03-21 13:17:22 +09:00
Andrzej Hajda
82a0178325 drm/exynos/fimd: signal frame done interrupt at front porch
VBLANK interrupt should be signalled as soon as scanout ends, front porch
is the best moment.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-03-21 13:17:22 +09:00
Andrzej Hajda
f3cce673e1 drm/exynos/decon5433: signal frame done interrupt at front porch
DECON in case of video mode generates interrupt by default at start
of vertical back porch. As this interrupt is used to generate VBLANK
events more optimal point is start of vertical front porch.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-03-21 13:17:22 +09:00
Andrzej Hajda
73488331eb drm/exynos/decon5433: fix vblank event handling
Current implementation of event handling assumes that vblank interrupt is
always called at the right time. It is not true, it can be delayed due to
various reasons. As a result different races can happen. The patch fixes
the issue by using hardware frame counter present in DECON to serialize
vblank and commit completion events.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-03-21 13:17:21 +09:00
Andrzej Hajda
a392276d1d drm/exynos: move crtc event handling to drivers callbacks
CRTC event is currently send with next vblank, or instantly in case crtc
is being disabled. This approach usually works, but in corner cases it can
result in premature event generation. Only device driver is able to verify
if the event can be sent. This patch is a first step in that direction - it
moves event handling to the drivers.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-03-21 13:17:21 +09:00
Krzysztof Kozlowski
6bdc92ee49 drm/exynos: Remove support for Exynos4415 (SoC not supported anymore)
Support for Exynos4415 is going away because there are no internal nor
external users.

Since commit 46dcf0ff0d ("ARM: dts: exynos: Remove exynos4415.dtsi"),
the platform cannot be instantiated so remove also the drivers.

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Kukjin Kim <kgene@kernel.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-03-21 13:17:21 +09:00