Chris Wilson [Tue, 14 Nov 2017 19:18:42 +0000 (19:18 +0000)]
drm/i915/selftests: Markup __iomem for igt_gem_coherency
Silence sparse warnings by using __iomem markup and io accessors.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114191842.19063-1-chris@chris-wilson.co.uk
Ville Syrjälä [Thu, 2 Nov 2017 15:17:37 +0000 (17:17 +0200)]
drm/i915: Use ELK stolen memory reserved detection for ILK
While I have no solid proof that ILK follows the ELK path when it
comes to the stolen memory reserved area, there are some hints that
it might be the case. Unfortunately my ILK doesn't have this enabled,
and no way to enable it via the BIOS it seems.
So let's have ILK use the ELK code path, and let's toss in a WARN
into the code to see if we catch anyone with an ILK that has this
enabled to further analyze the situation.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171102151737.23336-3-ville.syrjala@linux.intel.com
Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Ville Syrjälä [Thu, 2 Nov 2017 15:17:36 +0000 (17:17 +0200)]
drm/i915: Make the report about a bogus stolen reserved area an error
Now that we should be properly filtering out the cases when the stolen
reserved area is disabled, let's convert the debug message about a
misplaced reserved area into an error.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171102151737.23336-2-ville.syrjala@linux.intel.com
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Ville Syrjälä [Thu, 2 Nov 2017 15:17:35 +0000 (17:17 +0200)]
drm/i915: Check if the stolen memory "reserved" area is enabled or not
Apparently there are some machines that put semi-sensible looking values
into the stolen "reserved" base and size, except those values are actually
outside the stolen memory. There is a bit in the register which
supposedly could tell us whether the reserved area is even enabled or
not. Let's check for that before we go trusting the base and size.
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171102151737.23336-1-ville.syrjala@linux.intel.com
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Ville Syrjälä [Tue, 14 Nov 2017 19:11:27 +0000 (21:11 +0200)]
drm/i915: Fix kerneldocs for intel_audio.c
Fix copy/paste fail in kerneldocs for intel_audio_codec_disable().
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114191127.16188-1-ville.syrjala@linux.intel.com
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Hans de Goede [Tue, 14 Nov 2017 13:55:18 +0000 (14:55 +0100)]
drm/i915: Call uncore_suspend before platform suspend handlers
Quoting Ville: "the forcewake timer might still be active until the uncore
suspend, and having active forcewakes while we've already told the GT wake
stuff to stop acting normally doesn't seem quite right to me."
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114135518.15981-3-hdegoede@redhat.com
Hans de Goede [Tue, 14 Nov 2017 13:55:17 +0000 (14:55 +0100)]
drm/i915: Re-register PMIC bus access notifier on runtime resume
intel_uncore_suspend() unregisters the uncore code's PMIC bus access
notifier and gets called on both normal and runtime suspend.
intel_uncore_resume_early() re-registers the notifier, but only on
normal resume. Add a new intel_uncore_runtime_resume() function which
only re-registers the notifier and call that on runtime resume.
Cc: stable@vger.kernel.org
Reported-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114135518.15981-2-hdegoede@redhat.com
Hans de Goede [Fri, 10 Nov 2017 15:03:01 +0000 (16:03 +0100)]
drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2
assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier
even though it gets unregistered on (runtime) suspend, this is caused
by a race happening under the following circumstances:
intel_runtime_pm_put does:
atomic_dec(&dev_priv->pm.wakeref_count);
pm_runtime_mark_last_busy(kdev);
pm_runtime_put_autosuspend(kdev);
And pm_runtime_put_autosuspend calls intel_runtime_suspend from
a workqueue, so there is ample of time between the atomic_dec() and
intel_runtime_suspend() unregistering the notifier. If the notifier
gets called in this windowd assert_rpm_wakelock_held falsely triggers
(at this point we're not runtime-suspended yet).
This commit adds disable_rpm_wakeref_asserts and
enable_rpm_wakeref_asserts calls around the
intel_uncore_forcewake_get(FORCEWAKE_ALL) call in
i915_pmic_bus_access_notifier fixing the false-positive WARN_ON.
Changes in v2:
-Reword comment explaining why disabling the wakeref asserts is
ok and necessary
Cc: stable@vger.kernel.org
Reported-by: FKr <bugs-freedesktop@ubermail.me>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110150301.9601-2-hdegoede@redhat.com
Chris Wilson [Tue, 14 Nov 2017 22:33:46 +0000 (22:33 +0000)]
drm/i915/selftests: Always initialise err
smatch does not track initialised values as well as gcc, and this
triggers many warnings by smatch not presented by gcc. Silence smatch by
initialising the error values to -ENODEV, which we use to denote
internal errors. (If we see a selftest fail with a silent -ENODEV, we
know smatch was right!)
v2: smatch was right about igt_create_vma(), it may unlikely fail on the
first object allocation which we want to be loud about.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114223346.25958-1-chris@chris-wilson.co.uk
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Chris Wilson [Tue, 14 Nov 2017 13:03:00 +0000 (13:03 +0000)]
drm/i915: Resume GuC before using GEM
Resuming GEM presumes it can talk to hw, in particular to ensure the
kernel context is loaded upon resume for powersaving. If the GuC is
still asleep at this point, we upset the HW. Rearrange the resume such
that we restore the original order of init-hw, resume-guc, use-gem.
Fixes: 37cd33006d02 ("drm/i915: Remove redundant intel_autoenable_gt_powersave()")
References:
a1c419941453 ("drm/i915/guc: Add host2guc notification for suspend and resume")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Alex Dai <yu.dai@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114130300.25677-2-chris@chris-wilson.co.uk
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Rodrigo Vivi [Sat, 11 Nov 2017 00:03:19 +0000 (16:03 -0800)]
drm/i915: Display WA #1185 WaDisableDARBFClkGating:cnl, glk
Display is not sending a PMRsp when a PMReq is received
at the same time that all planes are turned off.
State machine in the dcprunit is stuck in the WAIT4DONE
state which means that there is no fill_done.
WA: disable arbiter clock gating, set bit [27] of 0x46530
v2: As Ville pointed out, based on the description the issue
can happen when disabling the planes, similar to
WaRsPkgCStateDisplayPMReq:hsw
Also description of the issue was updated on commit
message to make it more clear that we need this
earlier.
v3: Restore comment about possibility to system hang
to where we are sure about it, without speculation. (Ville).
v4: Remove doubled sob. Actually do v3 changes :/
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171111000319.5040-1-rodrigo.vivi@intel.com
Rodrigo Vivi [Tue, 14 Nov 2017 15:43:00 +0000 (07:43 -0800)]
Merge airlied/drm-next into drm-intel-next-queued
Catchup with upstream.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Chris Wilson [Tue, 14 Nov 2017 13:43:40 +0000 (13:43 +0000)]
drm/i915: Unconditionally apply the Broxton register workaround set
Having removed the preproduction Broxton support (see commit
0102ba1fd8af
("drm/i915: Add early BXT sdv to the list of preproduction machines")),
we know we then always need the production Broxton workaround set and do
not need a predicate upon revision.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114134340.5439-2-chris@chris-wilson.co.uk
Chris Wilson [Tue, 14 Nov 2017 13:43:39 +0000 (13:43 +0000)]
drm/i915: Remove pre-production Broxton register workarounds
We've begun excluding pre-production Broxton machines since commit
0102ba1fd8af ("drm/i915: Add early BXT sdv to the list of preproduction
machines"), now remove the list of workaround register values for those
early machines.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20170927093325.24206-1-chris@chris-wilson.co.uk
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114134340.5439-1-chris@chris-wilson.co.uk
Chris Wilson [Sat, 11 Nov 2017 10:03:36 +0000 (10:03 +0000)]
drm/i915: Unify SLICE_UNIT_LEVEL_CLKGATE w/a for cnl
gem_workarounds reports that the SLICE_UNIT_LEVEL_CLKGATE write isn't
sticking. Commit
0a60797a0efb ("drm/i915: Implement
ReadHitWriteOnlyDisable.") presumes that SLICE_UNIT_LEVEL_CLKGATE is a
masked register in the context image, but commit
90007bca6162
("drm/i915/cnl: Introduce initial Cannonlake Workarounds.") lists it as
an ordering unmasked register. The masked write will be losing the
default settings if we trust the original commit. That gem_workarounds
reports the value is lost entirely is more worrying though -- but it
clearly suggests that it is not a masked register in the context image,
so unify both w/a to use the original rmw.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103705
Fixes: 0a60797a0efb ("drm/i915: Implement ReadHitWriteOnlyDisable.")
References:
90007bca6162 ("drm/i915/cnl: Introduce initial Cannonlake Workarounds.")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rafael Antognolli <rafael.antognolli@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171111100336.11020-1-chris@chris-wilson.co.uk
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
Lionel Landwerlin [Mon, 13 Nov 2017 23:34:53 +0000 (23:34 +0000)]
drm/i915: fix 64bit divide
ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/i915/i915.ko] undefined!
Store the frequency in kHz and drop 64bit divisions.
v2: Use div64_u64 (Matthew)
v3: store frequency in kHz to avoid 64bit divs (Chris/Ville)
Fixes: dab9178333 ("drm/i915: expose command stream timestamp frequency to userspace")
Reported-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171113233455.12085-3-lionel.g.landwerlin@intel.com
Reviewed-by: Ewelina Musial <ewelina.musial@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Mika Kahola [Thu, 9 Nov 2017 08:37:50 +0000 (10:37 +0200)]
drm/i915: Generalize transcoder looping
To make looping through transcoders in intel_ddi.c more generic, let's switch
to use 'for_each_pipe()' macro to do this.
v2: Add a notion that we are dealing with transcoders instead of pipes (Jani)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510216670-16848-1-git-send-email-mika.kahola@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
James Ausmus [Mon, 13 Nov 2017 18:11:28 +0000 (10:11 -0800)]
drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+
Since GLK, some plane configuration settings have moved to the
PLANE_COLOR_CTL register. Refactor handling of the register to work like
PLANE_CTL. This also allows us to fix the set/read of the plane Alpha
Mode for GLK+.
v2: Adjust ordering of platform checks to be newest->oldest, drop
redundant comment about alpha blending. (Ville)
v3: Move Alpha Mode bits out of skl_plane_ctl_format into
skl_plane_ctl_alpha, and drop glk_plane_ctl_format, drop initialization
of state->color_ctl on platforms that don't use it, and drop color_ctl
local var. (Ville)
v4: Consolidate skl_plane_ctl_format switch statement on formats that
return the same settings. (Ville)
Signed-off-by: James Ausmus <james.ausmus@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
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/20171113181128.2926-1-james.ausmus@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tina Zhang [Tue, 14 Nov 2017 10:25:13 +0000 (10:25 +0000)]
drm/i915: Introduce GEM proxy
GEM proxy is a kind of GEM, whose backing physical memory is pinned
and produced by guest VM and is used by host as read only. With GEM
proxy, host is able to access guest physical memory through GEM object
interface. As GEM proxy is such a special kind of GEM, a new flag
I915_GEM_OBJECT_IS_PROXY is introduced to ban host from changing the
backing storage of GEM proxy.
v3:
- update "Reviewed-by". (Joonas)
v2:
- return -ENXIO when pin and map pages of GEM proxy to kernel space.
(Chris)
Here are the histories of this patch in "Dma-buf support for Gvt-g"
patch-set:
v14:
- return -ENXIO when gem proxy object is banned by ioctl.
(Chris) (Daniel)
v13:
- add comments to GEM proxy. (Chris)
- don't ban GEM proxy in i915_gem_sw_finish_ioctl. (Chris)
- check GEM proxy bar after finishing i915_gem_object_wait. (Chris)
- remove GEM proxy bar in i915_gem_madvise_ioctl.
v6:
- add gem proxy barrier in the following ioctls. (Chris)
i915_gem_set_caching_ioctl
i915_gem_set_domain_ioctl
i915_gem_sw_finish_ioctl
i915_gem_set_tiling_ioctl
i915_gem_madvise_ioctl
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> #v1
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1510555798-21079-2-git-send-email-tina.zhang@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114102513.22269-2-chris@chris-wilson.co.uk
Tina Zhang [Tue, 14 Nov 2017 10:25:12 +0000 (10:25 +0000)]
drm/i915: Object w/o backing storage is banned by -ENXIO
-ENXIO should be returned when operations are banned from changing
backing storage of objects without backing storage.
v4:
- update "Reviewed-by". (Joonas)
v3:
- separate this patch from "Introduce GEM proxy" patch-set. (Joonas)
v2:
- update the patch description and subject to just mention objects w/o
backing storage, instead of "GEM proxy". (Joonas)
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/1510555798-21079-1-git-send-email-tina.zhang@intel.com
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114102513.22269-1-chris@chris-wilson.co.uk
Lucas De Marchi [Tue, 14 Nov 2017 00:46:38 +0000 (16:46 -0800)]
drm/i915: Fix function name in comment
Commit
78597996370c (drm/i915/bxt: Fix PPS lost state after suspend
breaking eDP link training) renamed the function to
intel_power_sequencer_reset() but forgot to update comment.
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114004638.5186-1-lucas.demarchi@intel.com
Dave Airlie [Tue, 14 Nov 2017 04:12:43 +0000 (14:12 +1000)]
Merge tag 'exynos-drm-next-for-v4.15' of git://git./linux/kernel/git/daeinki/drm-exynos into drm-next
- Improved HDMI and Mixer drivers
. It moves mode setup and plane update code to commit
like other CRTC drivers
. It makes mode commit to be called in enable callback only one time
. some cleanup and fixup to HDMI and Mixer drivers.
. It adds 1024x768, 1280x1024 and 1366x768 modes support
- Added HDMI audio interface driver
. As of now, HDMI audio worked on boards with external audio codec connected
in parallel with the HDMI audio transmitter's I2S interface.
This patch is required to support HDMI audio properly.
* tag 'exynos-drm-next-for-v4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
drm: exynos: Add driver for HDMI audio interface
drm/exynos/hdmi: add 85.5MHz pixel clock for v14 HDMI PHY
drm/exynos/mixer: enable support for 1024x768 and 1280x1024 modes
drm/exynos/hdmi: quirk for support mode timings conversion
drm/exynos/mixer: pass actual mode on MIXER to encoder
drm/exynos: add mode_fixup callback to exynos_drm_crtc_ops
drm/exynos/hdmi: remove redundant mode field
drm/exynos/mixer: remove mixer_resources sub-structure
drm/exynos/mixer: fix mode validation code
drm/exynos/mixer: move resolution configuration to single function
drm/exynos/mixer: move mode commit to enable callback
drm/exynos/mixer: abstract out output mode setup code
Dave Airlie [Mon, 13 Nov 2017 19:53:39 +0000 (05:53 +1000)]
Merge branch 'linus-4.14-rc4-acp-prereq' of git://people.freedesktop.org/~agd5f/linux into drm-next
This is a shared tree between drm and audio for some amd bits.
* 'linus-4.14-rc4-acp-prereq' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu Moving amdgpu asic types to a separate file
ASoC: AMD: Added asic_type as ACP DMA driver platform data
drm/amd/amdgpu: Added asic_type as ACP DMA driver platform data
Dave Airlie [Mon, 13 Nov 2017 19:29:34 +0000 (05:29 +1000)]
Merge tag 'drm-misc-fixes-2017-11-13' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
Driver Changes:
- qxl: Use a shadow bo as primary and blit to it to fix flicker (Gerd)
- rockchip: Convert psr spinlock to mutex (Emil)
Cc: Emil Renner Berthing <kernel@esmil.dk>
Cc: Gerd Hoffmann <kraxel@redhat.com>
* tag 'drm-misc-fixes-2017-11-13' of git://anongit.freedesktop.org/drm/drm-misc:
drm/rockchip: analogix_dp: Use mutex rather than spinlock
Dave Airlie [Mon, 13 Nov 2017 19:18:21 +0000 (05:18 +1000)]
Merge tag 'drm-intel-next-fixes-2017-11-10' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
drm/i915 fixes for v4.15
* tag 'drm-intel-next-fixes-2017-11-10' of git://anongit.freedesktop.org/drm/drm-intel:
drm/i915: Reorder context-close to avoid calling i915_vma_close() under RCU
drm/i915: Move init_clock_gating() back to where it was
drm/i915: Prune the reservation shared fence array
drm/i915: Idle the GPU before shinking everything
drm/i915: Lock llist_del_first() vs llist_del_all()
drm/i915: Calculate ironlake intermediate watermarks correctly, v2.
drm/i915: Disable lazy PPGTT page table optimization for vGPU
drm/i915/execlists: Remove the priority "optimisation"
drm/i915: Filter out spurious execlists context-switch interrupts
Dave Airlie [Mon, 13 Nov 2017 19:17:23 +0000 (05:17 +1000)]
Merge tag 'drm-misc-fixes-2017-11-02' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
Driver Changes:
- qxl: Use a shadow bo as primary and blit to it to fix flicker (Gerd)
* tag 'drm-misc-fixes-2017-11-02' of git://anongit.freedesktop.org/drm/drm-misc:
qxl: alloc & use shadow for dumb buffers
drm/qxl: replace QXL_INFO with DRM_DEBUG_DRIVER
Michel Thierry [Mon, 13 Nov 2017 17:36:28 +0000 (09:36 -0800)]
drm/i915: There is only one fault register from GEN8 onwards
Until Haswell/Baytrail, the hardware used to have a per engine fault
register (e.g. 0x4094 - render fault register, 0x4194 - media fault
register and so on). But since Broadwell, all these registers were
combined into a singe one and the engine id stored in bits 14:12.
Not only we should not been reading (and writing to) registers that do
not exist, in platforms with VCS2 (SKL), the address that would belong
this engine (0x4494, VCS2_HW = 4) is already assigned to other register.
v2: use less controversial function names (Chris).
v3: make non-exported functions static, remove now obsolete check for
engine presence before posting_read (Chris).
References: IHD-OS-BDW-Vol 2c-11.15, page 75.
References: IHD-OS-SKL-Vol 2c-05.16, page 350.
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171113173628.11689-1-michel.thierry@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Michel Thierry [Sat, 11 Nov 2017 00:44:47 +0000 (16:44 -0800)]
drm/i915: Clear per-engine fault register as early as possible
From gen6, the hardware tracks address lookup failures and we should
clear those registers upon startup to prevent false positives. However,
this was happening before we have the engines defined (intel_uncore_init())
and the for_each_engine loop was just a nop. The earliest we can call
this is inside intel_engines_init_mmio().
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171111004448.12360-1-michel.thierry@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Lionel Landwerlin [Fri, 10 Nov 2017 19:08:44 +0000 (19:08 +0000)]
drm/i915: expose command stream timestamp frequency to userspace
We use to have this fixed per generation, but starting with CNL userspace
cannot tell just off the PCI ID. Let's make this information available. This
is particularly useful for performance monitoring where much of the
normalization work is done using those timestamps (this include pipeline
statistics in both GL & Vulkan as well as OA reports).
v2: Use variables for 24MHz/19.2MHz values (Ewelina)
Renamed function & coding style (Sagar)
v3: Fix frequency read on Broadwell (Sagar)
Fix missing divide by 4 on <= gen4 (Sagar)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110190845.32574-7-lionel.g.landwerlin@intel.com
Lionel Landwerlin [Fri, 10 Nov 2017 19:08:43 +0000 (19:08 +0000)]
drm/i915/perf: enable perf support on CNL
This adds new registers to the whitelist to configs emitted from userspace.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110190845.32574-6-lionel.g.landwerlin@intel.com
Lionel Landwerlin [Fri, 10 Nov 2017 19:08:42 +0000 (19:08 +0000)]
drm/i915: fix register naming
This name was added with the whitelisting of registers for building up OA
configs. It is contained in a range gen8 whitelist :
addr >= RPM_CONFIG0.reg && addr <= NOA_CONFIG(8).reg
Hence why the name isn't used anywhere.
v2: Fix register name again RPC->RCP (Matthew)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110190845.32574-5-lionel.g.landwerlin@intel.com
Lionel Landwerlin [Fri, 10 Nov 2017 19:08:41 +0000 (19:08 +0000)]
drm/i915/perf: refactor perf setup
Gen8/9 aren't very different and we can merge some of this code.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110190845.32574-4-lionel.g.landwerlin@intel.com
Lionel Landwerlin [Fri, 10 Nov 2017 19:08:40 +0000 (19:08 +0000)]
drm/i915/perf: add support for Coffeelake GT3
We can enable GT3 as well as GT2.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110190845.32574-3-lionel.g.landwerlin@intel.com
Lionel Landwerlin [Fri, 10 Nov 2017 19:08:39 +0000 (19:08 +0000)]
drm/i915/perf: complete whitelisting for OA programming on HSW
We were missing some registers and also can name one for which we only had
the offset.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110190845.32574-2-lionel.g.landwerlin@intel.com
Maarten Lankhorst [Fri, 10 Nov 2017 11:34:58 +0000 (12:34 +0100)]
drm/i915: Handle locking better in i915_sink_crc.
Lock the bare minimum, instead of the entire world, and
use interruptible locking because we can.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110113503.16253-6-maarten.lankhorst@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Maarten Lankhorst [Fri, 10 Nov 2017 11:34:56 +0000 (12:34 +0100)]
drm/i915: Handle adjust better in intel_pipe_config_compare
Some parameters use CHECK_BOOL, but should really use
CHECK_BOOL_INCOMPLETE. We cannot currently check whether
the inherited infoframes and audio are set up correctly.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110113503.16253-4-maarten.lankhorst@linux.intel.com
[mlankhorst: Add danvet's comment about why this is needed.]
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Maarten Lankhorst [Fri, 10 Nov 2017 11:34:55 +0000 (12:34 +0100)]
drm/i915: Check boolean options in intel_pipe_config_compare with its own macro
Add PIPE_CONF_CHECK_BOOL for boolean options, which are printed with yesno.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110113503.16253-3-maarten.lankhorst@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Maarten Lankhorst [Fri, 10 Nov 2017 11:34:54 +0000 (12:34 +0100)]
drm/i915: Remove bogus ips_enabled check.
The flag just tells us IPS can be enabled, if the primary plane
is not enabled it means IPS might not be. This never triggered
in CI because we don't have a haswell ULT there, but can be
reproduced easily with kms_atomic_transitions.plane-all-modeset-transition
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110113503.16253-2-maarten.lankhorst@linux.intel.com
[mlankhorst: Remove from haswell_get_pipe_config too. (danvet)]
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Emil Renner Berthing [Wed, 4 Oct 2017 17:53:46 +0000 (19:53 +0200)]
drm/rockchip: analogix_dp: Use mutex rather than spinlock
On the Samsung Chromebook Plus I get this error with 4.14-rc3:
BUG: scheduling while atomic: kworker/3:1/50/0x00000002
Modules linked in:
CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 4.14.0-0.rc3-kevin #2
Hardware name: Google Kevin (DT)
Workqueue: events analogix_dp_psr_work
Call trace:
[<
ffffff80080873b0>] dump_backtrace+0x0/0x320
[<
ffffff80080876e4>] show_stack+0x14/0x20
[<
ffffff8008606d38>] dump_stack+0x9c/0xbc
[<
ffffff80080c6b5c>] __schedule_bug+0x4c/0x70
[<
ffffff80086188c0>] __schedule+0x3f0/0x458
[<
ffffff8008618960>] schedule+0x38/0xa0
[<
ffffff800861c20c>] schedule_hrtimeout_range_clock+0x84/0xe8
[<
ffffff800861c2a0>] schedule_hrtimeout_range+0x10/0x18
[<
ffffff800861bcec>] usleep_range+0x64/0x78
[<
ffffff8008415a6c>] analogix_dp_transfer+0x16c/0x340
[<
ffffff8008412550>] analogix_dpaux_transfer+0x10/0x18
[<
ffffff80083ceb14>] drm_dp_dpcd_access+0x4c/0xf0
[<
ffffff80083cf614>] drm_dp_dpcd_write+0x1c/0x28
[<
ffffff8008413b98>] analogix_dp_disable_psr+0x60/0xa8
[<
ffffff800840da3c>] analogix_dp_psr_work+0x4c/0x90
[<
ffffff80080bb09c>] process_one_work+0x1d4/0x348
[<
ffffff80080bb258>] worker_thread+0x48/0x478
[<
ffffff80080c11fc>] kthread+0x12c/0x130
[<
ffffff8008084290>] ret_from_fork+0x10/0x18
Changing rockchip_dp_device::psr_lock to a mutex rather
than spinlock seems to fix the issue.
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171004175346.11956-1-kernel@esmil.dk
Oscar Mateo [Wed, 8 Nov 2017 23:59:44 +0000 (15:59 -0800)]
drm/i915: Remove Gen9 WAs with no effect
GEN8_CONFIG0 (0xD00) is a protected by a lock (bit 31) which is set by
the BIOS, so there is no way we can enable the three chicken bits
mandated by the WA (the BIOS should be doing it instead).
v2: Rebased
v3: Standalone patch
References:
b033bb6d5d3a ("drm/i915/gen9: Enable must set chicken bits in config0 reg")
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510185589-9100-2-git-send-email-oscar.mateo@intel.com
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Sun, 12 Nov 2017 11:27:38 +0000 (11:27 +0000)]
drm/i915: Remove redundant intel_autoenable_gt_powersave()
Now that we always execute a context switch upon module load, there is
no need to queue a delayed task for doing so. The purpose of the delayed
task is to enable GT powersaving, for which we need the HW state to be
valid (i.e. having loaded a context and initialised basic state). We
used to defer this operation as historically it was slow (due to slow
register polling, fixed with commit
1758b90e38f5 ("drm/i915: Use a hybrid
scheme for fast register waits")) but now we have a requirement to save
the default HW state.
v2: Load the kernel context (to provide the power context) upon resume.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171112112738.1463-3-chris@chris-wilson.co.uk
Maarten Lankhorst [Fri, 10 Nov 2017 11:34:53 +0000 (12:34 +0100)]
drm/i915: Update watermark state correctly in sanitize_watermarks
We no longer use intel_crtc->wm.active for watermarks any more,
which was incorrect. But this uncovered a bug in sanitize_watermarks(),
which meant that we wrote the correct watermarks, but the next
update would still use the wrong hw watermarks for calculating.
This caused all further updates to fail with -EINVAL and the
log would reveal an error like the one below:
[ 10.043902] [drm:ilk_validate_wm_level.part.8 [i915]] Sprite WM0 too large 56 (max 0)
[ 10.043960] [drm:ilk_validate_pipe_wm [i915]] LP0 watermark invalid
[ 10.044030] [drm:intel_crtc_atomic_check [i915]] No valid intermediate pipe watermarks are possible
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: b6b178a77210 ("drm/i915: Calculate ironlake intermediate watermarks correctly, v2.")
Cc: stable@vger.kernel.org #v4.8+
Link: https://patchwork.freedesktop.org/patch/msgid/20171110113503.16253-1-maarten.lankhorst@linux.intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Chris Wilson [Fri, 10 Nov 2017 23:24:47 +0000 (23:24 +0000)]
drm/i915/selftests: Yet another forgotten mock_i915->mm initialiser
Move all of the i915->mm initialisation to a private function that can
be reused by the mock i915 device to save forgetting any more steps.
For example,
<7>[ 1542.046332] [IGT] drv_selftest: starting subtest mock_objects
<4>[ 1542.123924] Setting dangerous option mock_selftests - tainting kernel
<6>[ 1542.167941] i915: Performing mock selftests with st_random_seed=0x246f5ab5 st_timeout=1000
<4>[ 1542.178012] INFO: trying to register non-static key.
<4>[ 1542.178027] the code is fine but needs lockdep annotation.
<4>[ 1542.178032] turning off the locking correctness validator.
<4>[ 1542.178041] CPU: 3 PID: 6008 Comm: kworker/3:7 Tainted: G U 4.14.0-rc8-CI-CI_DRM_3332+ #1
<4>[ 1542.178049] Hardware name: /NUC6CAYB, BIOS AYAPLCEL.86A.0040.2017.0619.1722 06/19/2017
<4>[ 1542.178144] Workqueue: events __i915_gem_free_work [i915]
<4>[ 1542.178152] Call Trace:
<4>[ 1542.178163] dump_stack+0x68/0x9f
<4>[ 1542.178170] register_lock_class+0x3fd/0x580
<4>[ 1542.178177] ? unwind_next_frame+0x14/0x20
<4>[ 1542.178184] ? __save_stack_trace+0x73/0xd0
<4>[ 1542.178191] __lock_acquire+0xa4/0x1b00
<4>[ 1542.178254] ? __i915_gem_free_work+0x28/0xa0 [i915]
<4>[ 1542.178261] ? __lock_acquire+0x4ab/0x1b00
<4>[ 1542.178268] lock_acquire+0xb0/0x200
<4>[ 1542.178273] ? lock_acquire+0xb0/0x200
<4>[ 1542.178336] ? __i915_gem_free_work+0x28/0xa0 [i915]
<4>[ 1542.178344] _raw_spin_lock+0x32/0x50
<4>[ 1542.178405] ? __i915_gem_free_work+0x28/0xa0 [i915]
<4>[ 1542.178468] __i915_gem_free_work+0x28/0xa0 [i915]
<4>[ 1542.178476] process_one_work+0x221/0x650
<4>[ 1542.178483] worker_thread+0x4e/0x3c0
<4>[ 1542.178489] kthread+0x114/0x150
<4>[ 1542.178494] ? process_one_work+0x650/0x650
<4>[ 1542.178499] ? kthread_create_on_node+0x40/0x40
<4>[ 1542.178506] ret_from_fork+0x27/0x40
v2: Fish out i915->mm.object_stat_lock which was being inited over in
i915_drv.c (Matthew)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110232447.21618-1-chris@chris-wilson.co.uk
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Chris Wilson [Thu, 9 Nov 2017 14:06:44 +0000 (14:06 +0000)]
drm/i915: Kerneldoc typo s/rps/rps_client/
Update the kerneldoc parameter name to match the real parameter name.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171109140644.10805-1-chris@chris-wilson.co.uk
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Chris Wilson [Fri, 10 Nov 2017 14:26:34 +0000 (14:26 +0000)]
drm/i915: Stop caching the "golden" renderstate
As we now record the default HW state and so only emit the "golden"
renderstate once to prepare the HW, there is no advantage in keeping the
renderstate batch around as it will never be used again.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110142634.10551-8-chris@chris-wilson.co.uk
Chris Wilson [Fri, 10 Nov 2017 14:26:33 +0000 (14:26 +0000)]
drm/i915: Record the default hw state after reset upon load
Take a copy of the HW state after a reset upon module loading by
executing a context switch from a blank context to the kernel context,
thus saving the default hw state over the blank context image.
We can then use the default hw state to initialise any future context,
ensuring that each starts with the default view of hw state.
v2: Unmap our default state from the GTT after stealing it from the
context. This should stop us from accidentally overwriting it via the
GTT (and frees up some precious GTT space).
Testcase: igt/gem_ctx_isolation
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110142634.10551-7-chris@chris-wilson.co.uk
Chris Wilson [Fri, 10 Nov 2017 14:26:32 +0000 (14:26 +0000)]
drm/i915: Mark the context state as dirty/written
In the next few patches, we will want to both copy out of the context
image and write a valid image into a new context. To be completely safe,
we should then couple in our domain tracking to ensure that we don't
have any issues with stale data remaining in unwanted cachelines.
Historically, we omitted the .write=true from the call to set-gtt-domain
in i915_switch_context() in order to avoid a stall between every request
as we would want to wait for the previous context write from the gpu.
Since then, we limit the set-gtt-domain to only occur when we first bind
the vma, so once in use we will never stall, and we are sure to flush
the context following a load from swap.
Equally we never applied the lessons learnt from ringbuffer submission
to execlists; so time to apply the flush of the lrc after load as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110142634.10551-6-chris@chris-wilson.co.uk
Chris Wilson [Fri, 10 Nov 2017 14:26:31 +0000 (14:26 +0000)]
drm/i915: Inline intel_modeset_gem_init()
intel_modeset_gem_init() now only sets up the legacy overlay, so let's
remove the function and call the setup directly during driver load. This
should help us find a better point in the initialisation sequence for it
later.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110142634.10551-5-chris@chris-wilson.co.uk
Chris Wilson [Fri, 10 Nov 2017 14:26:30 +0000 (14:26 +0000)]
drm/i915: Move intel_init_clock_gating() to i915_gem_init()
Despite its name intel_init_clock_gating applies both display clock gating
workarounds; GT mmio workarounds and the occasional GT power context
workaround. Worse, sometimes it includes a context register workaround
which we need to apply before we record the default HW state for all
contexts.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110142634.10551-4-chris@chris-wilson.co.uk
Chris Wilson [Fri, 10 Nov 2017 14:26:29 +0000 (14:26 +0000)]
drm/i915: Move GT powersaving init to i915_gem_init()
GT powersaving is tightly coupled to the request infrastructure. To
avoid complications with the order of initialisation in the next patch
(where we want to send requests to hw during GEM init) move the
powersaving initialisation into the purview of i915_gem_init().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110142634.10551-3-chris@chris-wilson.co.uk
Chris Wilson [Fri, 10 Nov 2017 14:26:28 +0000 (14:26 +0000)]
drm/i915: Force the switch to the i915->kernel_context
In the next few patches, we will have a hard requirement that we emit a
context-switch to the perma-pinned i915->kernel_context (so that we can
save the HW state using that context-switch). As the first context
itself may be classed as a kernel context, we want to be explicit in our
comparison. For an extra-layer of finesse, we can check the last
unretired context on the engine; as well as the last retired context
when idle.
v2: verbose verbosity
v3: Always force the switch, even when the engine is idle, and update
the assert that this happens before suspend.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> #v1
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110142634.10551-2-chris@chris-wilson.co.uk
Tvrtko Ursulin [Fri, 10 Nov 2017 14:26:27 +0000 (14:26 +0000)]
drm/i915: Define an engine class enum for the uABI
We want to be able to report back to userspace details about an engine's
class, and in return for userspace to be able to request actions
regarding certain classes of engines. To isolate the uABI from any
variations between hw generations, we define an abstract class for the
engines and internally map onto the hw.
v2: Remove MAX from the uABI; keep it internal if we need it, but don't
let userspace make the mistake of using it themselves.
v3: s/OTHER/INVALID/
The use of OTHER is ill-defined, so remove it from the uABI as any
future new type of engine can define a class to suit it. But keep a
reserved value for an invalid class, so that we can always
unambiguously express when something doesn't belong to the
classification.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> #v2
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110142634.10551-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 10 Nov 2017 15:19:19 +0000 (15:19 +0000)]
drm/i915/selftests: Initialise mock_i915->mm.obj_lock
lockdep spotted that the mock tests were using the i915->mm.obj_lock
without first initialiasing it:
>[ 1303.217043] [IGT] drv_selftest: starting subtest mock_objects
<4>[ 1303.240898] Setting dangerous option mock_selftests - tainting kernel
<6>[ 1303.253665] i915: Performing mock selftests with st_random_seed=0xd87ea6c6 st_timeout=1000
<4>[ 1303.254812] INFO: trying to register non-static key.
<4>[ 1303.254816] the code is fine but needs lockdep annotation.
<4>[ 1303.254818] turning off the locking correctness validator.
<4>[ 1303.254820] CPU: 4 PID: 13112 Comm: drv_selftest Tainted: G U W 4.14.0-rc8-CI-Patchwork_7058+ #1
<4>[ 1303.254823] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12 02/15/2016
<4>[ 1303.254825] Call Trace:
<4>[ 1303.254829] dump_stack+0x68/0x9f
<4>[ 1303.254832] register_lock_class+0x3fd/0x580
<4>[ 1303.254835] ? ___slab_alloc.constprop.29+0x157/0x3d0
<4>[ 1303.254837] ? ___slab_alloc.constprop.29+0x157/0x3d0
<4>[ 1303.254840] ? sg_kmalloc+0x1e/0x50
<4>[ 1303.254842] ? debug_smp_processor_id+0x17/0x20
<4>[ 1303.254845] __lock_acquire+0xa4/0x1b00
<4>[ 1303.254884] ? __i915_gem_object_set_pages+0x116/0x1f0 [i915]
<4>[ 1303.254887] ? __this_cpu_preempt_check+0x13/0x20
<4>[ 1303.254889] ? sg_kmalloc+0x1e/0x50
<4>[ 1303.254891] lock_acquire+0xb0/0x200
<4>[ 1303.254893] ? lock_acquire+0xb0/0x200
<4>[ 1303.254917] ? __i915_gem_object_set_pages+0x116/0x1f0 [i915]
<4>[ 1303.254920] _raw_spin_lock+0x32/0x50
<4>[ 1303.254944] ? __i915_gem_object_set_pages+0x116/0x1f0 [i915]
<4>[ 1303.254967] __i915_gem_object_set_pages+0x116/0x1f0 [i915]
<4>[ 1303.254991] i915_gem_object_get_pages_phys+0x286/0x2b0 [i915]
<4>[ 1303.255015] ____i915_gem_object_get_pages+0x20/0x60 [i915]
<4>[ 1303.255039] i915_gem_object_attach_phys+0x137/0x1a0 [i915]
<4>[ 1303.255063] igt_phys_object+0x45/0x120 [i915]
<4>[ 1303.255094] __i915_subtests+0x40/0xd0 [i915]
<4>[ 1303.255099] ? work_on_cpu_safe+0x60/0x60
<4>[ 1303.255131] i915_gem_object_mock_selftests+0x34/0x50 [i915]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110151919.18451-1-chris@chris-wilson.co.uk
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Chris Wilson [Fri, 10 Nov 2017 11:25:50 +0000 (11:25 +0000)]
drm/i915: Restore the wait for idle engine after flushing interrupts
So it appears that commit
5427f207852d ("drm/i915: Bump wait-times for
the final CS interrupt before parking") was a little over optimistic in
its belief that it had successfully waited for all residual activity on
the engines before parking. Numerous sightings in CI since then of
<7>[ 52.542886] [IGT] core_auth: executing
<3>[ 52.561013] [drm:intel_engines_park [i915]] *ERROR* vcs0 is not idle before parking
<7>[ 52.561215] intel_engines_park vcs0
<7>[ 52.561229] intel_engines_park current seqno 98, last 98, hangcheck 0 [-247449 ms], inflight 0
<7>[ 52.561238] intel_engines_park Reset count: 0
<7>[ 52.561266] intel_engines_park Requests:
<7>[ 52.561363] intel_engines_park RING_START: 0x00000000 [0x00000000]
<7>[ 52.561377] intel_engines_park RING_HEAD: 0x00000000 [0x00000000]
<7>[ 52.561390] intel_engines_park RING_TAIL: 0x00000000 [0x00000000]
<7>[ 52.561406] intel_engines_park RING_CTL: 0x00000000
<7>[ 52.561422] intel_engines_park RING_MODE: 0x00000200 [idle]
<7>[ 52.561442] intel_engines_park ACTHD: 0x00000000_00000000
<7>[ 52.561459] intel_engines_park BBADDR: 0x00000000_00000000
<7>[ 52.561474] intel_engines_park Execlist status: 0x00000301
00000000
<7>[ 52.561489] intel_engines_park Execlist CSB read 5 [5 cached], write 5 [5 from hws], interrupt posted? no
<7>[ 52.561500] intel_engines_park ELSP[0] idle
<7>[ 52.561510] intel_engines_park ELSP[1] idle
<7>[ 52.561519] intel_engines_park HW active? 0x0
<7>[ 52.561608] intel_engines_park Idle? yes
<7>[ 52.561617] intel_engines_park
on Braswell, which indicates that the engine just needs that little bit
longer after flushing the tasklet to settle. So give it a few more
milliseconds before declaring an err and applying the emergency brake.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103479
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110112550.28909-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Hans de Goede [Thu, 19 Oct 2017 11:16:20 +0000 (13:16 +0200)]
drm/i915: Acquire PUNIT->PMIC bus for intel_uncore_forcewake_reset()
intel_uncore_forcewake_reset() does forcewake puts and gets as such
we need to make sure that no-one tries to access the PUNIT->PMIC bus
(on systems where this bus is shared) while it runs, otherwise bad
things happen.
Normally this is taken care of by the i915_pmic_bus_access_notifier()
which does an intel_uncore_forcewake_get(FORCEWAKE_ALL) when some other
driver tries to access the PMIC bus, so that later forcewake gets are
no-ops (for the duration of the bus access).
But intel_uncore_forcewake_reset gets called in 3 cases:
1) Before registering the pmic_bus_access_notifier
2) After unregistering the pmic_bus_access_notifier
3) To reset forcewake state on a GPU reset
In all 3 cases the i915_pmic_bus_access_notifier() protection is
insufficient.
This commit fixes this race by calling iosf_mbi_punit_acquire() before
calling intel_uncore_forcewake_reset(). In the case where it is called
directly after unregistering the pmic_bus_access_notifier, we need to
hold the punit-lock over both calls to avoid a race where
intel_uncore_fw_release_timer() may execute between the 2 calls.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171019111620.26761-3-hdegoede@redhat.com
Hans de Goede [Thu, 19 Oct 2017 11:16:19 +0000 (13:16 +0200)]
x86/platform/intel/iosf_mbi: Add unlocked PMIC bus access notifier unregister
For race free unregistration drivers may need to acquire PMIC bus access
through iosf_mbi_punit_acquire() and then (un)register the notifier without
dropping the lock.
This commit adds an unlocked variant of
iosf_mbi_unregister_pmic_bus_access_notifier for this use case.
Acked-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171019111620.26761-2-hdegoede@redhat.com
Chris Wilson [Tue, 7 Nov 2017 10:20:03 +0000 (10:20 +0000)]
drm/i915: Move irqs enabled assertion deeper for mock breadcrumbs
In order to allow the mock breadcrumbs tests to run without device irqs
being enabled, move the intel_irqs_enabled() assert deeper to just
before we commit to enabling the HW irq.
v2: Add a FIXME explaining that placing the assertion so deep is not
ideal, but a compromise for mock breadcrumbs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107102003.1802-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Fri, 10 Nov 2017 10:11:10 +0000 (10:11 +0000)]
drm/i915/selftests: Reduce the volume of the timeout message
Originally it was anticipated that timeouts would be a rare event, and
so merit a warning that the test was incomplete. However, for igt we
keep the timeout low, and hitting the timeout is intentional. It no
longer necessitates a warning, but to be expected.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110101110.12042-1-chris@chris-wilson.co.uk
Reviwed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Dave Airlie [Wed, 8 Nov 2017 23:35:04 +0000 (09:35 +1000)]
drm/mode_object: fix documentation for object lookups.
The lease updates missed a few bits of docs, fixed up
the wrong name on the property lookup fn as well.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Rodrigo Vivi [Thu, 9 Nov 2017 23:30:06 +0000 (15:30 -0800)]
drm/i915: Update DRIVER_DATE to
20171109
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Rodrigo Vivi [Thu, 9 Nov 2017 23:18:04 +0000 (15:18 -0800)]
drm/i915: Update DRIVER_DATE to
20171109
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Chris Wilson [Thu, 9 Nov 2017 21:34:50 +0000 (21:34 +0000)]
drm/i915: Mark up i915_vma_unbind() as a potential sleeper
Whenever we want to unbind a vma, we must wait on all GPU activity to
complete first. (This is what gives us the ability to do fine grained
eviction and purging by only having to wait on the VMA that we need to
unbind to proceed; though if pushed we can make it a rule that we are
only allowed to unbind already idle VMA and move the burden of the work
and organising the sleep onto the caller.) Currently, we might only
sleep if the vma is still active on the GPU, but in principle
i915_vma_unbind() always implies a sleep, so mark it up with a
might_sleep().
Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=103638
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171109213450.13875-2-chris@chris-wilson.co.uk
Chris Wilson [Thu, 9 Nov 2017 21:34:49 +0000 (21:34 +0000)]
drm/i915: Mark vm_free_page() as a potential sleeper agent
vm_free_page() may call down into set_pages_array_wb() (which itself
sleeps, on x86 at least) but only if on !llc and the caches overflow.
Since this is unlikely, we only rarely trigger the error in practice,
and so to make CI detection of this sleeping bug possible we want to
mark the common vm_free_page() as a potential sleep.
Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=103638
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171109213450.13875-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 9 Nov 2017 14:30:19 +0000 (14:30 +0000)]
drm/i915: Use trace_printk to provide a death rattle for GEM
Trying to enable printk debugging for GEM is fraught with the issue of
spam; interactions with HW are very frequent and often boring. However,
one instance where they are not so boring is just before a BUG; here
ftrace provides a facility to dump its ringbuffer on an oops. So for CI
let's enable trace_printk() to capture the last exchanges with HW as a
death rattle.
For example,
[ 79.234110] ------------[ cut here ]------------
[ 79.234137] kernel BUG at drivers/gpu/drm/i915/intel_lrc.c:907!
[ 79.234145] invalid opcode: 0000 [#1] SMP
[ 79.234153] Dumping ftrace buffer:
[ 79.234158] ---------------------------------
...
[ 79.314044] gem_conc-1059 1..s1 79203443us : intel_lrc_irq_handler: bcs0 out[0]: ctx=5.2, seqno=145
[ 79.314089] gem_conc-1059 1..s. 79220800us : intel_lrc_irq_handler: bcs0 csb[1/1]: status=0x00000018:0x00000005
[ 79.314133] gem_conc-1059 1..s. 79220803us : intel_lrc_irq_handler: bcs0 out[0]: ctx=5.1, seqno=145
[ 79.314177] gem_conc-1062 2..s1 79230458us : intel_lrc_irq_handler: bcs0 in[0]: ctx=8.1, seqno=146
[ 79.314220] gem_conc-1062 2..s1 79230515us : intel_lrc_irq_handler: bcs0 in[0]: ctx=8.2, seqno=147
[ 79.314265] gem_conc-1059 1..s1 79230951us : intel_lrc_irq_handler: bcs0 csb[2/3]: status=0x00000012:0x00000008
[ 79.314309] gem_conc-1059 1..s1 79230954us : intel_lrc_irq_handler: bcs0 out[0]: ctx=8.2, seqno=147
[ 79.314353] gem_conc-1059 1..s1 79230954us : intel_lrc_irq_handler: bcs0 csb[3/3]: status=0x00008002:0x00000008
[ 79.314396] gem_conc-1059 1..s1 79230955us : intel_lrc_irq_handler: bcs0 out[0]: ctx=8.1, seqno=147
[ 79.314402] ---------------------------------
v2: Tweak the formatting to be more consistent between in/out.
v3: do {} while (0) stub macro protection
Suggested-by: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171109143019.16568-1-chris@chris-wilson.co.uk
Ville Syrjälä [Thu, 9 Nov 2017 15:27:58 +0000 (17:27 +0200)]
drm/i915: Clean up DP code local variables and calling conventions
Eliminate a ton of pointless 'dev' variables in the DP code, and pass
around 'dev_priv' instead of 'dev'.
v2: Rebase
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171109152758.32257-1-ville.syrjala@linux.intel.com
Ville Syrjälä [Tue, 31 Oct 2017 20:51:22 +0000 (22:51 +0200)]
drm/i915: Clean up PPS code calling conventions
No need to pass 'dev' or 'dev_priv' when the function already takes
'intel_dp'. Also let's prefer passing 'dev_priv' instead of 'dev'
when we have to pass one or the other.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-10-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Ville Syrjälä [Thu, 9 Nov 2017 15:24:34 +0000 (17:24 +0200)]
drm/i915: Nuke intel_digital_port->port
Remove intel_digital_port->port and replace its users with
intel_encoder->port. intel_encoder->port is a superset of
intel_digital_port->port, and it works correctly even for
MST encoders.
v2: Eliminate a few dp_to_dig_port()->base.port cases too (DK)
Performed with cocci:
@@
@@
struct intel_digital_port {
...
- enum port port;
...
}
@@
struct intel_digital_port *D;
expression E;
@@
- D->port = E;
@@
struct intel_digital_port *D;
@@
- D->port
+ D->base.port
@
expression E;
@@
(
- dp_to_dig_port(E)->port
+ dp_to_dig_port(E)->base.port
|
- enc_to_dig_port(E)->port
+ to_intel_encoder(E)->port
)
@@
expression E;
@@
- to_intel_encoder(&E->base)
+ E
@@
struct intel_digital_port *D;
identifier I, M;
@@
I = &D->base
<...
(
- D->base.M
+ I->M
|
- &D->base
+ I
)
...>
@@
identifier D;
expression E;
identifier M;
@@
D = enc_to_dig_port(&E->base)
<...
(
- D->base.M
+ E->M
|
- &D->base
+ E
)
...>
@@
identifier D, DP;
expression E;
identifier M;
@@
DP = enc_to_intel_dp(&E->base)
<...
(
- dp_to_dig_port(DP)->base.M
+ E->M
|
- &dp_to_dig_port(DP)->base
+ E
)
...>
@@
expression E;
identifier M;
@@
(
- enc_to_dig_port(&E->base)->base.M
+ E->M
|
- enc_to_dig_port(&E->base)->base
+ E
|
- enc_to_mst(&E->base)->primary->base.port
+ E->port
)
@@
expression E;
identifier D;
@@
- struct intel_digital_port *D = E;
... when != D
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171109152434.32074-1-ville.syrjala@linux.intel.com
Ville Syrjälä [Tue, 31 Oct 2017 20:51:20 +0000 (22:51 +0200)]
drm/i915: Replace dig_port->port with encoder port for BXT DPLL selection
Replace dig_port->port with encoder->port in the BXT DPLL selection.
We can do this because both the master encoder and the fake MST encoders
have the same encoder->port value, whereas using dig_port->port only
worked for the master encoder since the fake encoders were't derived
from intel_digital_port. This eliminates the DP MST special case.
Do this by hand because spatch is having problems with the control
flow due to the dig_port assignment happening in two different
branches.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-8-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Ville Syrjälä [Tue, 31 Oct 2017 20:51:19 +0000 (22:51 +0200)]
drm/i915: Eliminate crtc->config usage from CRT code
Replace crtc->config usage with the passed down crtc state.
Also take the opportunity for some s/pipe_config/crtc_state/ while at it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-7-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Ville Syrjälä [Tue, 31 Oct 2017 20:51:18 +0000 (22:51 +0200)]
drm/i915: Pass crtc state to DPIO PHY functions
Rather than digging through encoder->crtc and crtc->config in the
DPIO PHY functions, pass down the correct crtc state from the caller.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-6-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Ville Syrjälä [Tue, 31 Oct 2017 20:51:17 +0000 (22:51 +0200)]
drm/i915: Eliminate some encoder->crtc usage from TV code
Extract the current crtc from the crtc state rather than via
the legacy encoder->crtc pointer whenever possible.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-5-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Ville Syrjälä [Tue, 31 Oct 2017 20:51:16 +0000 (22:51 +0200)]
drm/i915: Eliminate some encoder->crtc usage from SDVO code
Extract the current crtc from the crtc state rather than via
the legacy encoder->crtc pointer whenever possible.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-4-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Ville Syrjälä [Tue, 31 Oct 2017 20:51:15 +0000 (22:51 +0200)]
drm/i915: Eliminate some encoder->crtc usage from DSI code
Extract the current crtc from the crtc state rather than via
the legacy encoder->crtc pointer whenever possible.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-3-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Ville Syrjälä [Tue, 31 Oct 2017 20:51:14 +0000 (22:51 +0200)]
drm/i915: Eliminate some encoder->crtc usage from DP code
Extract the current crtc from the crtc state rather than via
the legacy encoder->crtc pointer whenever possible.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-2-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Chris Wilson [Thu, 9 Nov 2017 08:55:40 +0000 (08:55 +0000)]
drm/i915: Reorder context-close to avoid calling i915_vma_close() under RCU
When we close the VMA, we unbind it from the ppgtt and tear down the
page directory pointing at it. That may trigger us to return WC pages
back to the system, requiring conversion back to WB which itself may
sleep. That makes i915_vma_close() unsuitable for use inside the RCU
read lock, which we need to hold to iterate the radixtree.
The fix is quite simple, we can close all the VMA as we close the ppgtt,
we only need to do that instead of closing them during destruction of
the LUT.
v2: Order between closing the LUT and the ppgtt is important; we use the
vma inside the LUT as a means of retrieving the object, and so we must
clear the LUT before freeing the VMA when closing the ppgtt.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103638
Fixes: 547da76b5777 ("drm/i915: Hold rcu_read_lock when iterating over the radixtree (vma idr)")
Fixes: d1b48c1e7184 ("drm/i915: Replace execbuf vma ht with an idr")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171109085540.32264-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
(cherry picked from commit
94dec87159af6f3dcc0b78d3f909aefa9e29c01a)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Wed, 8 Nov 2017 13:35:55 +0000 (15:35 +0200)]
drm/i915: Move init_clock_gating() back to where it was
Apparently setting up a bunch of GT registers before we've properly
initialized the rest of the GT hardware leads to these setting being
lost. So looks like I broke HSW with commit
b7048ea12fbb ("drm/i915:
Do .init_clock_gating() earlier to avoid it clobbering watermarks")
by doing init_clock_gating() too early. This should actually affect
other platforms as well, but apparently not to such a great degree.
What I was ultimately after in that commit was to move the
ilk_init_lp_watermarks() call earlier. So let's undo the damage and
move init_clock_gating() back to where it was, and call
ilk_init_lp_watermarks() just before the watermark state readout.
This highlights how fragile and messed up our init order really is.
I wonder why we even initialize the display before gem. The opposite
order would make much more sense to me...
v2: Keep WaRsPkgCStateDisplayPMReq:hsw early as it really must
be done before all planes might get disabled.
Cc: stable@vger.kernel.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mark Janes <mark.a.janes@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reported-by: Mark Janes <mark.a.janes@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103549
Fixes: b7048ea12fbb ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks")
References: https://lists.freedesktop.org/archives/intel-gfx/2017-November/145432.html
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171108133555.14091-1-ville.syrjala@linux.intel.com
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit
f72b84c677d61f201b869223a8d6e389c7bb7d3d)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Tue, 7 Nov 2017 22:06:56 +0000 (22:06 +0000)]
drm/i915: Prune the reservation shared fence array
The shared fence array is not autopruning and may continue to grow as an
object is shared between new timelines. Take the opportunity when we
think the object is idle (we have to confirm that any external fence is
also signaled) to decouple all the fences.
We apply a similar trick after waiting on an object, see commit
e54ca9774777 ("drm/i915: Remove completed fences after a wait")
v2: No longer need to handle the batch pool as a special case.
v3: Need to trylock from within i915_vma_retire as this may be called
form the shrinker - and we may later try to allocate underneath the
reservation lock, so a deadlock is possible.
References: https://bugs.freedesktop.org/show_bug.cgi?id=102936
Fixes: d07f0e59b2c7 ("drm/i915: Move GEM activity tracking into a common struct reservation_object")
Fixes: 80b204bce8f2 ("drm/i915: Enable multiple timelines")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107220656.5020-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit
1ab22356b37ab08a391d6f007fda4c822bef9fb5)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Wed, 8 Nov 2017 09:44:00 +0000 (09:44 +0000)]
drm/i915: Idle the GPU before shinking everything
The handling of contexts are peculiar. Instead of tieing their vma to
activity, we pin the context. This means that we cannot simply unbind
the context object itself at will (which would normally cause us to wait
for the vma to be idle), but must manually idle the GPU and retire
requests first.
A consequence of this peculiarity is when doing a last desperate attempt
to recover memory. If the memory is tied up inside active context
objects, we will fail to recover any memory simply by trying to unbind
the objects without first doing a wait-for-idle.
A side-effect of removing the call to shrinker_lock_uninterruptible()
from i915_gem_shrinker_oom() was that we removed an unlocked
wait-for-idle, and so lost the "natural" shrinkage of context objects.
By replacing that with a locked wait from inside i915_gem_shrink(), we
not only replace it with the ability to recover all context objects, but
do so for all i915_gem_shrink_all() callers.
v2: Switching requires request allocation, which is not permitted from
inside the shrinker as it only uses ordinary allocations.
References: https://bugs.freedesktop.org/show_bug.cgi?id=102936
Fixes: f2123818ffad ("drm/i915: Move dev_priv->mm.[un]bound_list to its own lock")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171108094400.1386-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit
2f6a3783833dde63f1c08982943a8b2229b97afb)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Mon, 6 Nov 2017 11:15:08 +0000 (11:15 +0000)]
drm/i915: Lock llist_del_first() vs llist_del_all()
An oversight in commit
87701b4b5593 ("drm/i915: Only free the oldest
stale object before a fresh allocation") was that not only do we have to
serialise concurrent users of llist_del_first(), but we also have to
lock llist_del_first() vs llist_del_all().
From llist.h,
* This can be summarized as follows:
*
* | add | del_first | del_all
* add | - | - | -
* del_first | | L | L
* del_all | | | -
*
* Where, a particular row's operation can happen concurrently with a column's
* operation, with "-" being no lock needed, while "L" being lock is needed.
This should hopefully explain:
<4>[ 89.287106] general protection fault: 0000 [#1] PREEMPT SMP
<4>[ 89.287126] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp i915 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core r8169 mii mei_me mei snd_pcm prime_numbers i2c_hid pinctrl_geminilake pinctrl_intel
<4>[ 89.287226] CPU: 2 PID: 23 Comm: ksoftirqd/2 Tainted: G U 4.14.0-rc8-CI-CI_DRM_3315+ #1
<4>[ 89.287247] Hardware name: Intel Corp. Geminilake/GLK RVP2 LP4SD (07), BIOS GELKRVPA.X64.0062.B30.
1708222146 08/22/2017
<4>[ 89.287270] task:
ffff88017ab34ec0 task.stack:
ffffc90000128000
<4>[ 89.287290] RIP: 0010:llist_add_batch+0x4/0x20
<4>[ 89.287301] RSP: 0018:
ffffc9000012bdb8 EFLAGS:
00010296
<4>[ 89.287314] RAX:
ffffffff811017ad RBX:
6e468801a1560000 RCX:
ef3e53fceecdeb81
<4>[ 89.287330] RDX:
6e468801a1566130 RSI:
ffff880103d73d98 RDI:
ffff880103d73d98
<4>[ 89.287346] RBP:
ffffc9000012bdb8 R08:
ffff88017ab35780 R09:
0000000000000000
<4>[ 89.287361] R10:
ffffc9000012bd68 R11:
00000000abb18c3d R12:
ffffffffa01369e0
<4>[ 89.287377] R13:
ffff88017fd1b8f8 R14:
ffff88017ab34ec0 R15:
000000000000000a
<4>[ 89.287393] FS:
0000000000000000(0000) GS:
ffff88017fd00000(0000) knlGS:
0000000000000000
<4>[ 89.287411] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
<4>[ 89.287424] CR2:
00007ff0c0755018 CR3:
000000016df9b000 CR4:
00000000003406e0
<4>[ 89.287440] Call Trace:
<4>[ 89.287511] __i915_gem_free_object_rcu+0x20/0x40 [i915]
<4>[ 89.287527] rcu_process_callbacks+0x27a/0x730
<4>[ 89.287544] __do_softirq+0xc0/0x4ae
<4>[ 89.287559] ? smpboot_thread_fn+0x2d/0x280
<4>[ 89.287571] run_ksoftirqd+0x1f/0x70
<4>[ 89.287582] smpboot_thread_fn+0x18a/0x280
<4>[ 89.287595] kthread+0x114/0x150
<4>[ 89.287605] ? sort_range+0x30/0x30
<4>[ 89.287615] ? kthread_create_on_node+0x40/0x40
<4>[ 89.287628] ret_from_fork+0x27/0x40
<4>[ 89.287641] Code: 0d 48 83 ea 01 4c 89 c1 48 83 fa ff 74 12 48 23 0c d7 74 ed 48 c1 e2 06 48 0f bd c9 48 8d 04 0a 5d c3 90 90 90 90 90 55 48 89 e5 <48> 8b 0a 48 89 0e 48 89 c8 f0 48 0f b1 3a 48 39 c1 75 ed 48 85
<1>[ 89.287774] RIP: llist_add_batch+0x4/0x20 RSP:
ffffc9000012bdb8
<4>[ 89.287826] ---[ end trace
e775d15174d8ae02 ]---
(Lockless lists are only easy (and lockless) when only using
llist_add/llist_del_all!)
Fixes: 87701b4b5593 ("drm/i915: Only free the oldest stale object before
a fresh allocation")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171106111508.11941-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
(cherry picked from commit
f991c492aa55fb1c6834882c5d786d5bb3b25f07)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Maarten Lankhorst [Thu, 19 Oct 2017 15:13:41 +0000 (17:13 +0200)]
drm/i915: Calculate ironlake intermediate watermarks correctly, v2.
The watermarks it should calculate against are the old optimal watermarks.
The currently active crtc watermarks are pure fiction, and are invalid in
case of a nonblocking modeset, page flip enabling/disabling planes or any
other reason.
When the crtc is disabled or during a modeset the intermediate watermarks
don't need to be programmed separately, and could be directly assigned
to the optimal watermarks.
Changes since v1:
- Use intel_atomic_get_old_crtc_state. (ville)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171019151341.4579-2-maarten.lankhorst@linux.intel.com
[mlankhorst: Add cc stable and bugzilla link, since previous patch doesn't fix issue by itself]
Cc: stable@vger.kernel.org #v4.8+
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102373
(cherry picked from commit
b6b178a77210055b153dbc175e4468bd3c7122df)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Joonas Lahtinen [Mon, 23 Oct 2017 15:32:09 +0000 (18:32 +0300)]
drm/i915: Disable lazy PPGTT page table optimization for vGPU
When running under virtualization (vGPU active), we must disable
the lazy PPGTT page table initialization optimization introduced by
commit
14826673247e ("drm/i915: Only initialize partially filled
pagetables").
We must do this because GVT-g makes unduly assumptions about guest
behaviour, which this optimization breaks. This results in following
looking errors in the host:
ERROR gvt: guest page write error -22, gfn 0x7ada8, pa 0x7ada89a8, var 0x6, len 1
The real fix is to not to depend on i915 driver behaviour, but instead
either rely on only the contracts that i915 has with the hardware, or
add some paravirtualization. While the real fix is en route, it won't
be finished in time for 4.15, so the best option is to disable the
optimization for now when vGPU is active to avoid breaking 4.15 guests
in existing VM environments.
Fixes: 14826673247e ("drm/i915: Only initialize partially filled pagetables")
Suggested-by: Xiaolin Zhang <xiaolin.zhang@intel.com>
Signed-off-by: Xiaolin Zhang <xiaolin.zhang@intel.com>
[Joonas: Rewrote the commit message and added tags.]
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171023153209.10527-1-joonas.lahtinen@linux.intel.com
(cherry picked from commit
22a8a4fc93b14b5a8cfc785edbdc6f7bd98bffb6)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Tue, 24 Oct 2017 11:55:01 +0000 (12:55 +0100)]
drm/i915/execlists: Remove the priority "optimisation"
Originally we set the priority to max upon inserting the request into
the execlists queue (and removing it from the scheduler lists). We could
then use the prio==INT_MAX as a shortcut within execlists_schedule() to
detect the end of the dependency chain. Since commit
1f181225f8ec
("drm/i915/execlists: Keep request->priority for its lifetime") this is
no longer true as we use the request completion as an indicator the
schedule dependency chain is complete instead. (This allows us to then
reschedule requests even when its context is in flight.) However, this
makes the GEM_BUG_ON() inside execlists_schedule() racy as we may change
the rq->prio at the same time. As the assertion is useful, let's keep
the assertion and remove the micro-optimisation.
Fixes: 1f181225f8ec ("drm/i915/execlists: Keep request->priority for its lifetime")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171024115501.21033-1-chris@chris-wilson.co.uk
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
(cherry picked from commit
64b80085dd3603d401fc05879f700b86a3a5c8e8)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Mon, 23 Oct 2017 21:32:36 +0000 (22:32 +0100)]
drm/i915: Filter out spurious execlists context-switch interrupts
Back in commit
a4b2b01523a8 ("drm/i915: Don't mark an execlists
context-switch when idle") we noticed the presence of late
context-switch interrupts. We were able to filter those out by looking
at whether the ELSP remained active, but in commit
beecec901790
("drm/i915/execlists: Preemption!") that became problematic as we now
anticipate receiving a context-switch event for preemption while ELSP
may be empty. To restore the spurious interrupt suppression, add a
counter for the expected number of pending context-switches and skip if
we do not need to handle this interrupt to make forward progress.
v2: Don't forget to switch on for preempt.
v3: Reduce the counter to a on/off boolean tracker. Declare the HW as
active when we first submit, and idle after the final completion event
(with which we confirm the HW says it is idle), and track each source
of activity separately. With a finite number of sources, it should aide
us in debugging which gets stuck.
Fixes: beecec901790 ("drm/i915/execlists: Preemption!")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171023213237.26536-3-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
(cherry picked from commit
4a118ecbe99c93cf9f9582e83a88d03f18d6cb84)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Thu, 9 Nov 2017 08:55:40 +0000 (08:55 +0000)]
drm/i915: Reorder context-close to avoid calling i915_vma_close() under RCU
When we close the VMA, we unbind it from the ppgtt and tear down the
page directory pointing at it. That may trigger us to return WC pages
back to the system, requiring conversion back to WB which itself may
sleep. That makes i915_vma_close() unsuitable for use inside the RCU
read lock, which we need to hold to iterate the radixtree.
The fix is quite simple, we can close all the VMA as we close the ppgtt,
we only need to do that instead of closing them during destruction of
the LUT.
v2: Order between closing the LUT and the ppgtt is important; we use the
vma inside the LUT as a means of retrieving the object, and so we must
clear the LUT before freeing the VMA when closing the ppgtt.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103638
Fixes: 547da76b5777 ("drm/i915: Hold rcu_read_lock when iterating over the radixtree (vma idr)")
Fixes: d1b48c1e7184 ("drm/i915: Replace execbuf vma ht with an idr")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171109085540.32264-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Dave Airlie [Thu, 9 Nov 2017 01:59:30 +0000 (11:59 +1000)]
Merge tag 'drm-misc-next-fixes-2017-11-08' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
4.15 merge window fixes, round 2:
randconfig fix from Arnd, plus the vblank WARN_ON fix from Ville.
* tag 'drm-misc-next-fixes-2017-11-08' of git://anongit.freedesktop.org/drm/drm-misc:
drm/vblank: Tune drm_crtc_accurate_vblank_count() WARN down to a debug
drm/rockchip: add CONFIG_OF dependency for lvds
Dave Airlie [Thu, 9 Nov 2017 01:14:47 +0000 (11:14 +1000)]
Merge branch 'drm-next-4.15' of git://people.freedesktop.org/~agd5f/linux into drm-next
A few more fixes for 4.15.
* 'drm-next-4.15' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: use irq-safe lock for kiq->ring_lock
drm/amdgpu: bypass lru touch for KIQ ring submission
drm/amdgpu: Potential uninitialized variable in amdgpu_vm_update_directories()
drm/amdgpu: potential uninitialized variable in amdgpu_vce_ring_parse_cs()
drm/amd/powerplay: initialize a variable before using it
drm/amd/powerplay: suppress KASAN out of bounds warning in vega10_populate_all_memory_levels
drm/amd/amdgpu: fix evicted VRAM bo adjudgement condition
pding [Tue, 7 Nov 2017 06:32:36 +0000 (14:32 +0800)]
drm/amdgpu: use irq-safe lock for kiq->ring_lock
This lock is used during register accessing in SRIOV guest.
The register accessing could happen both in irq enabled and
irq disabled cases. Always use irq-safe lock.
Signed-off-by: Pixel Ding <Pixel.Ding@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Pixel Ding [Wed, 8 Nov 2017 02:20:01 +0000 (10:20 +0800)]
drm/amdgpu: bypass lru touch for KIQ ring submission
KIQ ring submission is used for register accessing on SRIOV
VF that could happen both in irq enabled and irq disabled cases.
Inversion lock could happen on adev->ring_lru_list_lock, while
this operation is useless and just adds overhead in this use
case.
Signed-off-by: Pixel Ding <Pixel.Ding@amd.com>
Reviewed-by: Monk Liu <Monk.Liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dan Carpenter [Sat, 30 Sep 2017 08:14:13 +0000 (11:14 +0300)]
drm/amdgpu: Potential uninitialized variable in amdgpu_vm_update_directories()
After commit
ea09729c9302 ("drm/amdgpu: rework page directory filling
v2") then it becomes a lot harder to verify that "r" is initialized. My
static checker complains and so I've reviewed the code. It does look
like it might be buggy... Anyway, it doesn't hurt to set "r" to zero
at the start.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Dan Carpenter [Sat, 30 Sep 2017 08:13:28 +0000 (11:13 +0300)]
drm/amdgpu: potential uninitialized variable in amdgpu_vce_ring_parse_cs()
We shifted some code around in commit
9cca0b8e5df0 ("drm/amdgpu: move
amdgpu_cs_sysvm_access_required into find_mapping") and now my static
checker complains that "r" might not be initialized at the end of the
function. I've reviewed the code, and that seems possible, but it's
also possible I may have missed something.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Michal Wajdeczko [Fri, 3 Nov 2017 15:18:15 +0000 (15:18 +0000)]
drm/i915/guc: Simplify programming of GUC_SHIM_CONTROL
We can program GUC_SHIM_CONTROL register with all expected
bits without use of extra macro defined in fwif.h
v2: rebased without pre-prod code
v3: fixed typo
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171103151816.62048-4-michal.wajdeczko@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Michal Wajdeczko [Fri, 3 Nov 2017 15:18:14 +0000 (15:18 +0000)]
drm/i915/guc: Drop legacy workarounds from guc_prepare_xfer
We don't keep the workarounds for pre-production hardware
(see intel_detect_preproduction_hw) thus we can drop some
extra steps during firmware upload needed only for unsupported
platforms.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171103151816.62048-3-michal.wajdeczko@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Michal Wajdeczko [Fri, 3 Nov 2017 15:18:13 +0000 (15:18 +0000)]
drm/i915/guc: Wait for ucode DMA transfer completion
We silently assumed that DMA transfer will be completed
within assumed timeout and thus we were waiting only at
last step for GuC to become ready. Add intermediate wait
to catch unexpected delays in DMA transfer.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171103151816.62048-2-michal.wajdeczko@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Michal Wajdeczko [Fri, 3 Nov 2017 15:18:12 +0000 (15:18 +0000)]
drm/i915/guc: Split GuC firmware xfer function into clear steps
Transfer of GuC firmware requires few steps that currently
are implemented in two large functions. Split this code into
smaller functions to make these steps small and clear.
Also be prepared for potential DMA xfer step failure.
v2: rename function steps (Sagar)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171103151816.62048-1-michal.wajdeczko@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rafael Antognolli [Fri, 3 Nov 2017 18:30:27 +0000 (11:30 -0700)]
drm/i915: Implement ReadHitWriteOnlyDisable.
The workaround for this is described as:
"if RenderSurfaceState.Num_Multisamples > 1, disable RCC clock gating if
RenderSurfaceState.Num_Multisamples == 1, set 0x7010[14] = 1"
Further documentation in the internal bug referenced by the bspec
suggest that any of the above suggestions should suffice to fix the
issue. We are going with disabling RCC clock gating.
Unfortunately, what we are doing doesn't match the name of the
workaround, but at least it matches its description.
This change improves CNL stability by avoiding some of the hangs seen in
the platform.
v2: Only disable RCC clock gating.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171103183027.5051-1-rafael.antognolli@intel.com
Ville Syrjälä [Wed, 8 Nov 2017 13:35:55 +0000 (15:35 +0200)]
drm/i915: Move init_clock_gating() back to where it was
Apparently setting up a bunch of GT registers before we've properly
initialized the rest of the GT hardware leads to these setting being
lost. So looks like I broke HSW with commit
b7048ea12fbb ("drm/i915:
Do .init_clock_gating() earlier to avoid it clobbering watermarks")
by doing init_clock_gating() too early. This should actually affect
other platforms as well, but apparently not to such a great degree.
What I was ultimately after in that commit was to move the
ilk_init_lp_watermarks() call earlier. So let's undo the damage and
move init_clock_gating() back to where it was, and call
ilk_init_lp_watermarks() just before the watermark state readout.
This highlights how fragile and messed up our init order really is.
I wonder why we even initialize the display before gem. The opposite
order would make much more sense to me...
v2: Keep WaRsPkgCStateDisplayPMReq:hsw early as it really must
be done before all planes might get disabled.
Cc: stable@vger.kernel.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mark Janes <mark.a.janes@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reported-by: Mark Janes <mark.a.janes@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103549
Fixes: b7048ea12fbb ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks")
References: https://lists.freedesktop.org/archives/intel-gfx/2017-November/145432.html
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171108133555.14091-1-ville.syrjala@linux.intel.com
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Tue, 7 Nov 2017 22:06:56 +0000 (22:06 +0000)]
drm/i915: Prune the reservation shared fence array
The shared fence array is not autopruning and may continue to grow as an
object is shared between new timelines. Take the opportunity when we
think the object is idle (we have to confirm that any external fence is
also signaled) to decouple all the fences.
We apply a similar trick after waiting on an object, see commit
e54ca9774777 ("drm/i915: Remove completed fences after a wait")
v2: No longer need to handle the batch pool as a special case.
v3: Need to trylock from within i915_vma_retire as this may be called
form the shrinker - and we may later try to allocate underneath the
reservation lock, so a deadlock is possible.
References: https://bugs.freedesktop.org/show_bug.cgi?id=102936
Fixes: d07f0e59b2c7 ("drm/i915: Move GEM activity tracking into a common struct reservation_object")
Fixes: 80b204bce8f2 ("drm/i915: Enable multiple timelines")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107220656.5020-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Wed, 8 Nov 2017 09:44:00 +0000 (09:44 +0000)]
drm/i915: Idle the GPU before shinking everything
The handling of contexts are peculiar. Instead of tieing their vma to
activity, we pin the context. This means that we cannot simply unbind
the context object itself at will (which would normally cause us to wait
for the vma to be idle), but must manually idle the GPU and retire
requests first.
A consequence of this peculiarity is when doing a last desperate attempt
to recover memory. If the memory is tied up inside active context
objects, we will fail to recover any memory simply by trying to unbind
the objects without first doing a wait-for-idle.
A side-effect of removing the call to shrinker_lock_uninterruptible()
from i915_gem_shrinker_oom() was that we removed an unlocked
wait-for-idle, and so lost the "natural" shrinkage of context objects.
By replacing that with a locked wait from inside i915_gem_shrink(), we
not only replace it with the ability to recover all context objects, but
do so for all i915_gem_shrink_all() callers.
v2: Switching requires request allocation, which is not permitted from
inside the shrinker as it only uses ordinary allocations.
References: https://bugs.freedesktop.org/show_bug.cgi?id=102936
Fixes: f2123818ffad ("drm/i915: Move dev_priv->mm.[un]bound_list to its own lock")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171108094400.1386-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Tue, 7 Nov 2017 15:22:11 +0000 (15:22 +0000)]
drm/i915: Include intel_engine_is_idle() status in engine pretty-printer
Upon parking, if we discover an active engine we dump its state. Follow
that state with an indication of whether the engine was idle.
References: https://bugs.freedesktop.org/show_bug.cgi?id=103479
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107152211.19930-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Sun, 5 Nov 2017 13:49:05 +0000 (13:49 +0000)]
drm/i915: Read ilk FDI PLL frequency once during initialisation
During intel_atomic_check(), we do not take the intel_runtime_pm_get()
wakeref and so should do the atomic modeset precalculations without
referring to the HW. However, on Ironlake we see
<7>[ 23.487557] [drm:intel_atomic_check [i915]] [CONNECTOR:47:VGA-1] checking for sink bpp constrains
<7>[ 23.487615] [drm:intel_atomic_check [i915]] clamping display bpp (was 36) to default limit of 24
<4>[ 23.487621] RPM wakelock ref not held during HW access
<4>[ 23.487652] ------------[ cut here ]------------
<4>[ 23.487697] WARNING: CPU: 0 PID: 1343 at drivers/gpu/drm/i915/intel_drv.h:1813 gen5_read32+0x183/0x200 [i915]
<4>[ 23.487701] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul snd_hda_intel ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm lpc_ich e1000e mei_me ptp mei pps_core prime_numbers
<4>[ 23.487784] CPU: 0 PID: 1343 Comm: debugfs_test Tainted: G W 4.14.0-rc7-CI-Trybot_1378+ #1
<4>[ 23.487788] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011
<4>[ 23.487793] task:
ffff8801f90aa6c0 task.stack:
ffffc900013ec000
<4>[ 23.487838] RIP: 0010:gen5_read32+0x183/0x200 [i915]
<4>[ 23.487842] RSP: 0018:
ffffc900013efb58 EFLAGS:
00010292
<4>[ 23.487849] RAX:
000000000000002a RBX:
ffff880205c00000 RCX:
0000000000000006
<4>[ 23.487854] RDX:
000000000000140a RSI:
ffffffff81d0eb14 RDI:
ffffffff81cc26f6
<4>[ 23.487857] RBP:
ffffc900013efb80 R08:
ffff8801f90aaff8 R09:
0000000000000000
<4>[ 23.487861] R10:
0000000000000000 R11:
0000000000000000 R12:
0000000000000001
<4>[ 23.487865] R13:
0000000000046000 R14:
ffff88020ffaba78 R15:
ffff88020b109bf8
<4>[ 23.487870] FS:
00007f53b5e40a40(0000) GS:
ffff88021bc00000(0000) knlGS:
0000000000000000
<4>[ 23.487874] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
<4>[ 23.487878] CR2:
000055e41900c0e8 CR3:
00000001fa0d6005 CR4:
00000000000206f0
<4>[ 23.487882] Call Trace:
<4>[ 23.487931] intel_atomic_check+0x745/0x1290 [i915]
<4>[ 23.487948] drm_atomic_check_only+0x459/0x560
<4>[ 23.487956] ? drm_atomic_set_crtc_for_connector+0xc9/0x100
<4>[ 23.488025] drm_atomic_commit+0x18/0x50
<4>[ 23.488035] restore_fbdev_mode_atomic+0x190/0x1f0
<4>[ 23.488059] restore_fbdev_mode+0x32/0x120
<4>[ 23.488072] drm_fb_helper_restore_fbdev_mode_unlocked+0x50/0xa0
<4>[ 23.488139] intel_fbdev_restore_mode+0x34/0x90 [i915]
<4>[ 23.488194] i915_driver_lastclose+0xe/0x10 [i915]
<4>[ 23.488208] drm_lastclose+0x39/0xf0
<4>[ 23.488219] drm_release+0x30c/0x3c0
<4>[ 23.488236] __fput+0xb9/0x200
<4>[ 23.488252] ____fput+0xe/0x10
<4>[ 23.488264] task_work_run+0x89/0xc0
<4>[ 23.488278] exit_to_usermode_loop+0x83/0x90
<4>[ 23.488290] syscall_return_slowpath+0xd0/0x110
<4>[ 23.488304] entry_SYSCALL_64_fastpath+0xaf/0xb1
<4>[ 23.488312] RIP: 0033:0x7f53b4317560
<4>[ 23.488320] RSP: 002b:
00007ffca7e70748 EFLAGS:
00000246 ORIG_RAX:
0000000000000003
<4>[ 23.488333] RAX:
0000000000000000 RBX:
0000000000000001 RCX:
00007f53b4317560
<4>[ 23.488340] RDX:
0000000000000005 RSI:
00007ffca7e70640 RDI:
0000000000000004
<4>[ 23.488347] RBP:
000055e417783900 R08:
000055e418f9e290 R09:
0000000000000000
<4>[ 23.488356] R10:
0000000000000000 R11:
0000000000000246 R12:
0000000000000001
<4>[ 23.488363] R13:
00007f53b4302c40 R14:
0000000000000000 R15:
0000000000000000
<4>[ 23.488384] Code: b5 f2 f2 e0 0f ff e9 c5 fe ff ff 80 3d 0e 4b 10 00 00 0f 85 c6 fe ff ff 48 c7 c7 30 73 29 a0 c6 05 fa 4a 10 00 01 e8 8e f2 f2 e0 <0f> ff e9 ac fe ff ff e8 51 9d f3 e0 85 c0 0f 85 01 ff ff ff 48
<4>[ 23.488780] ---[ end trace
6bc72ce7f1596190 ]---
<7>[ 23.488844] [drm:intel_atomic_check [i915]] checking fdi config on pipe A, lanes 1
<7>[ 23.488911] [drm:intel_atomic_check [i915]] hw max bpp: 36, pipe bpp: 24, dithering: 0
due to intel_fdi_link_freq() poking at FDI_PLL_BIOS_0. Avoid this by
recording the fdi pll frequency during device initiailisation.
v2: Also extract the static FDI PLL frequencies for Sandybridge and
Ivybridge.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107214713.18704-1-chris@chris-wilson.co.uk
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
projects / openwrt / staging / blogic.git / log