aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-05-03drm/i915: Replace tmds_clock_speed and link_rate with just ls_clockVille Syrjälä5-30/+21
There's no need to distinguish between the DP link rate and HDMI TMDS clock for the purposes of the LPE audio. Both are actually the same thing more or less, which is the link symbol clock. So let's just call the thing ls_clock and simplify the code. Cc: Takashi Iwai <[email protected]> Cc: Pierre-Louis Bossart <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Takashi Iwai <[email protected]>
2017-05-03drm/i915: Remove the unused pending_notify from LPE platform dataVille Syrjälä3-4/+0
The pending_notify flag in the LPE audio platform data is pointless, actually unused. So let's kill it off. v2: Fix typo in patch subject Cc: Takashi Iwai <[email protected]> Cc: Pierre-Louis Bossart <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Takashi Iwai <[email protected]>
2017-05-03drm/i915: Stop pretending to mask/unmask LPE audio interruptsVille Syrjälä2-45/+6
vlv_display_irq_postinstall() enables the LPE audio interrupts regardless of whether the LPE audio irq chip has masked/unmasked them. Also the irqchip masking/unmasking doesn't consider the state of the display power well or the device, and hence just leads to dmesg spew when it tries to access the hardware while it's powered down. If the current way works, then we don't need to do anything in the mask/unmask hooks. If it doesn't work, well, then we'd need to properly track whether the irqchip has masked/unmasked the interrupts when we enable display interrupts. And the mask/unmask hooks would need to check whether display interrupts are even enabled before frobbing with he registers. So let's just assume the current way works and neuter the mask/unmask hooks. Also clean up vlv_display_irq_postinstall() a bit and stop it from trying to unmask/enable the LPE C interrupt on VLV since it doesn't exist. Cc: Takashi Iwai <[email protected]> Cc: Pierre-Louis Bossart <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Takashi Iwai <[email protected]>
2017-05-03ALSA: x86: Clear the pdata.notify_lpe_audio pointer before teardownVille Syrjälä1-0/+5
Clear the notify function pointer in the platform data before we tear down the driver. Otherwise i915 would end up calling a stale function pointer and possibly explode. Cc: [email protected] Cc: Takashi Iwai <[email protected]> Cc: Pierre-Louis Bossart <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Takashi Iwai <[email protected]>
2017-05-03drm/i915: Fix runtime PM for LPE audioVille Syrjälä2-4/+5
Not calling pm_runtime_enable() means that runtime PM can't be enabled at all via sysfs. So we definitely need to call it from somewhere. Calling it from the driver seems like a bad idea because it would have to be paired with a pm_runtime_disable() at driver unload time, otherwise the core gets upset. Also if there's no LPE audio driver loaded then we couldn't runtime suspend i915 either. So it looks like a better plan is to call it from i915 when we register the platform device. That seems to match how pci generally does things. I cargo culted the pm_runtime_forbid() and pm_runtime_set_active() calls from pci as well. The exposed runtime PM API is massive an thorougly misleading, so I don't actually know if this is how you're supposed to use the API or not. But it seems to work. I can now runtime suspend i915 again with or without the LPE audio driver loaded, and reloading the LPE audio driver also seems to work. Note that powertop won't auto-tune runtime PM for platform devices, which is a little annoying. So I'm not sure that leaving runtime PM in "on" mode by default is the best choice here. But I've left it like that for now at least. Also remove the comment about there not being much benefit from LPE audio runtime PM. Not allowing runtime PM blocks i915 runtime PM, which will also block s0ix, and that could have a measurable impact on power consumption. Cc: [email protected] Cc: Takashi Iwai <[email protected]> Cc: Pierre-Louis Bossart <[email protected]> Fixes: 0b6b524f3915 ("ALSA: x86: Don't enable runtime PM as default") Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Takashi Iwai <[email protected]>
2017-05-03drm/i915: Switch the global i915.semaphores check to a local predicateChris Wilson1-1/+3
Rather than use a global modparam, we can just check to see if the engine has semaphores configured upon it. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-05-03drm/i915: Do not record a successful syncpoint for a dma-awaitChris Wilson1-18/+19
As we may unwind the requests, even though the request we are awaiting has a global_seqno that seqno may be revoked during the await and so we can not reliably use it as a barrier for all future awaits on the same timeline. Signed-off-by: Chris Wilson <[email protected]> Cc: Michał Winiarski <[email protected]> Reviewed-by: Michał Winiarski <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-05-03drm/i915: Rename intel_timeline.sync_seqno[] to .global_sync[]Chris Wilson2-5/+12
With the addition of the inter-context intel_time.sync map, having a very similar sync_seqno[] is confusing. Aide the reader by denoting that this is a pre-allocated array for storing semaphore sync points wrt to the global seqno. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-05-03drm/i915: Squash repeated awaits on the same fenceChris Wilson15-18/+1588
Track the latest fence waited upon on each context, and only add a new asynchronous wait if the new fence is more recent than the recorded fence for that context. This requires us to filter out unordered timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the absence of a universal identifier, we have to use our own i915->mm.unordered_timeline token. v2: Throw around the debug crutches v3: Inline the likely case of the pre-allocation cache being full. v4: Drop the pre-allocation support, we can lose the most recent fence in case of allocation failure -- it just means we may emit more awaits than strictly necessary but will not break. v5: Trim allocation size for leaf nodes, they only need an array of u32 not pointers. v6: Create mock_timeline to tidy selftest writing v7: s/intel_timeline_sync_get/intel_timeline_sync_is_later/ (Tvrtko) v8: Prune the stale sync points when we idle. v9: Include a small benchmark in the kselftests v10: Separate the idr implementation into its own compartment. (Tvrkto) v11: Refactor igt_sync kselftests to avoid deep nesting (Tvrkto) v12: __sync_leaf_idx() to assert that p->height is 0 when checking leaves v13: kselftests to investigate struct i915_syncmap itself (Tvrtko) v14: Foray into ascii art graphs v15: Take into account that the random lookup/insert does 2 prng calls, not 1, when benchmarking, and use for_each_set_bit() (Tvrtko) v16: Improved ascii art Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Joonas Lahtinen <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-05-03drm/i915: Lift timeline ordering to await_dma_fenceChris Wilson1-3/+9
Currently we filter out repeated use of the same timeline in the low level i915_gem_request_await_request(), after having added the dependency on the old request. However, we can lift this to i915_gem_request_await_dma_fence() (before the dependency is added) using the observation that requests along the same timeline are explicitly ordered via i915_add_request (along with the dependencies). Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-05-03drm/i915: Unwrap top level fence-arrayChris Wilson1-23/+18
By first unwrapping an incoming fence-array into its child fences, we can simplify the internal branching, and so avoid triggering a potential bug in the next patch when not squashing the child fences on the same timeline. It will also have the advantage of keeping the (top-level) fence arrays out of any fence/timeline caching since these are unordered timelines but with a random context id. Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-05-03drm/i915: Mark up clflushes as belonging to an unordered timelineChris Wilson4-9/+4
2 clflushes on two different objects are not ordered, and so do not belong to the same timeline (context). Either we use a unique context for each, or we reserve a special global context to mean unordered. Ideally, we would reserve 0 to mean unordered (DMA_FENCE_NO_CONTEXT) to have the same semantics everywhere. Signed-off-by: Chris Wilson <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Joonas Lahtinen <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-05-03drm/i915: Use wait_for_atomic_us when waiting for gt fifoMika Kuoppala1-16/+14
Replace the handcrafter loop when checking for fifo slots with atomic wait for. This brings this wait in line with the other waits on register access. We also get a readable timeout constraint, so make it to fail after 10ms. Chris suggested that we should fail silently as the fifo debug handler, now attached to unclaimed mmio handling, will take care of the possible errors at later stage. Note that the decision to wait was changed so that we avoid allocating the first reserved entry. Nor do we reduce the count if we fail the wait, removing the possiblity to wrap the count if the hw fifo returned zero. v2: remove unclaimed check on timeout (Chris) v3: use void return (Chris) References: https://bugs.freedesktop.org/show_bug.cgi?id=100247 Signed-off-by: Mika Kuoppala <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-05-03drm/i915: Move the GTFIFODBG to the common mmio dbg frameworkMika Kuoppala1-46/+30
Remove the per-mmio checking of the FIFO debug register into the common conditional mmio debug handling. Based on patch from Chris Wilson. v2: postpone warn on fifodbg for unclaimed reg debugs Signed-off-by: Mika Kuoppala <[email protected]> Reviewed-by: Chris Wilson <[email protected]>
2017-05-02drm/i915/guc: Enable send function only after successful initMichal Wajdeczko2-1/+27
It is safer to setup valid send function after successful GuC hardware initialization. In addition we prepare placeholder where we can setup any alternate GuC communication mechanism. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] [ickle: Fixup ENODEV for an impossible error path] Signed-off-by: Chris Wilson <[email protected]>
2017-05-02drm/i915: Do not leak dev_priv->l3_parity.remap_info[]Joonas Lahtinen4-14/+36
Add intel_irq_fini() for placing the deinitialization code, starting with freeing dev_priv->l3_parity.remap_info[]. Signed-off-by: Joonas Lahtinen <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1493366319-18515-1-git-send-email-joonas.lahtinen@linux.intel.com
2017-05-02drm/i915: Update DRIVER_DATE to 20170502Daniel Vetter1-2/+2
Signed-off-by: Daniel Vetter <[email protected]>
2017-05-02Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-nextDave Airlie9-8/+10
Some nouveau regression fixes. * 'linux-4.12' of git://github.com/skeggsb/linux: drm/nouveau/fb/gf100-: Fix 32 bit wraparound in new ram detection drm/nouveau/secboot/gm20b: fix the error return code in gm20b_secboot_tegra_read_wpr() drm/nouveau/kms: Increase max retries in scanout position queries. drm/nouveau/bios/bitP: check that table is long enough for optional pointers drm/nouveau/fifo/nv40: no ctxsw for pre-nv44 mpeg engine
2017-04-29drm/nouveau/fb/gf100-: Fix 32 bit wraparound in new ram detectionMario Kleiner1-1/+1
A missing u64 cast causes a 32-Bit wraparound from 4096 MiB to 0 MiB and therefore total 0 MiB VRAM detected if card has 4096 Mib per FBP. Signed-off-by: Mario Kleiner <[email protected]> Reviewed-by: Karol Herbst <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2017-04-29drm/nouveau/secboot/gm20b: fix the error return code in ↵Wei Yongjun1-1/+1
gm20b_secboot_tegra_read_wpr() The error return code PTR_ERR(mc) is always 0 since mc is equal to 0 in this error handling case. Signed-off-by: Wei Yongjun <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2017-04-29drm/nouveau/kms: Increase max retries in scanout position queries.Mario Kleiner1-1/+1
So far we only allowed for 1 retry and just failed the query - and thereby high precision vblank timestamping - if we did not get a reasonable result, as such a failure wasn't considered all too horrible. There are a few NVidia gpu models out there which may need a bit more than 1 retry to get a successful query result under some conditions. Since Linux 4.4 the update code for vblank counter and timestamp in drm_update_vblank_count() changed so that the implementation assumes that high precision vblank timestamping of a kms driver either consistently succeeds or consistently fails for a given video mode and encoder/connector combo. Iow. switching from success to fail or vice versa on a modeset or connector change is ok, but spurious temporary failure for a given setup can confuse the core code and potentially cause bad miscounting of vblanks and confusion or hangs in userspace clients which rely on vblank stuff, e.g., desktop compositors. Therefore change the max retry count to a larger number - more than any gpu so far is known to need to succeed, but still low enough so that these queries which do also happen in vblank interrupt are still fast enough to be not disastrously long if something would go badly wrong with them. As such sporadic retries only happen seldom even on affected gpu's, this could mean a vblank irq could take a few dozen microseconds longer every few hours of uptime -- better than a desktop compositor randomly hanging every couple of hours or days of uptime in a hard to reproduce manner. Signed-off-by: Mario Kleiner <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2017-04-29drm/nouveau/bios/bitP: check that table is long enough for optional pointersBen Skeggs5-5/+5
Fixes OOB VBIOS accesses on some boards. Signed-off-by: Ben Skeggs <[email protected]>
2017-04-29drm/nouveau/fifo/nv40: no ctxsw for pre-nv44 mpeg engineIlia Mirkin1-0/+2
Signed-off-by: Ilia Mirkin <[email protected]>
2017-04-29Merge tag 'drm-intel-next-fixes-2017-04-27' of ↵Dave Airlie17-97/+163
git://anongit.freedesktop.org/git/drm-intel into drm-next drm/i915 and gvt fixes for drm-next/v4.12 * tag 'drm-intel-next-fixes-2017-04-27' of git://anongit.freedesktop.org/git/drm-intel: drm/i915: Confirm the request is still active before adding it to the await drm/i915: Avoid busy-spinning on VLV_GLTC_PW_STATUS mmio drm/i915/selftests: Allocate inode/file dynamically drm/i915: Fix system hang with EI UP masked on Haswell drm/i915: checking for NULL instead of IS_ERR() in mock selftests drm/i915: Perform link quality check unconditionally during long pulse drm/i915: Fix use after free in lpe_audio_platdev_destroy() drm/i915: Use the right mapping_gfp_mask for final shmem allocation drm/i915: Make legacy cursor updates more unsynced drm/i915: Apply a cond_resched() to the saturated signaler drm/i915: Park the signaler before sleeping drm/i915/gvt: fix a bounds check in ring_id_to_context_switch_event() drm/i915/gvt: Fix PTE write flush for taking runtime pm properly drm/i915/gvt: remove some debug messages in scheduler timer handler drm/i915/gvt: add mmio init for virtual display drm/i915/gvt: use directly assignment for structure copying drm/i915/gvt: remove redundant ring id check which cause significant CPU misprediction drm/i915/gvt: remove redundant platform check for mocs load/restore drm/i915/gvt: Align render mmio list to cacheline drm/i915/gvt: cleanup some too chatty scheduler message
2017-04-29Merge branch 'drm-vmwgfx-next' of ↵Dave Airlie1-1/+1
git://people.freedesktop.org/~syeh/repos_linux into drm-next trivial patch. * 'drm-vmwgfx-next' of git://people.freedesktop.org/~syeh/repos_linux: drm/vmwgfx: Convert macro to octal representation
2017-04-29Merge branch 'for-upstream/mali-dp' of git://linux-arm.org/linux-ld into ↵Dave Airlie7-62/+1073
drm-next Latest updates on Mali DP, adding support for colour management, plane scaling and power management. (these have been in -next for a while). * 'for-upstream/mali-dp' of git://linux-arm.org/linux-ld: drm: mali-dp: use div_u64 for expensive 64-bit divisions drm: mali-dp: Check the mclk rate and allow up/down scaling drm: mali-dp: Enable image enhancement when scaling drm: mali-dp: Add plane upscaling support drm/mali-dp: Add core_id file to the sysfs interface drm: mali-dp: Add CTM support drm: mali-dp: enable gamma support drm: mali-dp: add malidp_crtc_state struct drm: mali-dp: add custom reset hook for planes drm: mali-dp: remove unused variable drm: mali-dp: add atomic_print_state for planes drm: mali-dp: Enable power management for the device. drm: mali-dp: Update the state of all planes before re-enabling active CRTCs.
2017-04-28drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messagesAnder Conselvan de Oliveira1-4/+3
The sequence in glk_dsi_device_ready() enters ULPS then waits until it is *not* active to then disable it. The correct sequence according to the spec is to enter ULPS then wait until the GLK_ULPS_NOT_ACTIVE bit is zero, i.e., ULPS is active, and then disable ULPS. Fixing the condition gets rid of the following spurious error messages: [drm:glk_dsi_device_ready [i915]] *ERROR* ULPS is still active Fixes: 4644848369c0 ("drm/i915/glk: Add MIPIIO Enable/disable sequence") Cc: Deepak M <[email protected]> Cc: Madhav Chauhan <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jani Nikula <[email protected]> Cc: [email protected] Cc: <[email protected]> Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Madhav Chauhan <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-04-28drm/i915: Capture CCID on ILKJoonas Lahtinen1-1/+1
CCID register existed already on ILK according to the PRM (Chris verified the address to match too). Signed-off-by: Joonas Lahtinen <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1493366019-18380-1-git-send-email-joonas.lahtinen@linux.intel.com
2017-04-28drm/i915: Reset ILK during GEM sanitizationJoonas Lahtinen1-3/+2
ILK should survive a reset without display corruption. Suggested-by: Chris Wilson <[email protected]> Signed-off-by: Joonas Lahtinen <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Reviewed-by: Chris Wilson <[email protected]>
2017-04-28drm/i915: Eliminate HAS_HW_CONTEXTSJoonas Lahtinen5-14/+4
HAS_HW_CONTEXTS is misleading condition for GPU reset and CCID, replace it with Gen specific (to be updated in next patches). HAS_HW_CONTEXTS in i915_l3_write is bogus because each HAS_L3_DPF match also has .has_hw_contexts = 1 set. This leads to us being able to get rid of the property completely. v2: - Keep the checks at Gen6 for no functional change (Ville) Signed-off-by: Joonas Lahtinen <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]>
2017-04-28drm/i915: Sanitize engine context sizesJoonas Lahtinen11-138/+112
Pre-calculate engine context size based on engine class and device generation and store it in the engine instance. v2: - Squash and get rid of hw_context_size (Chris) v3: - Move after MMIO init for probing on Gen7 and 8 (Chris) - Retained rounding (Tvrtko) v4: - Rebase for deferred legacy context allocation Signed-off-by: Joonas Lahtinen <[email protected]> Cc: Paulo Zanoni <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Oscar Mateo <[email protected]> Cc: Zhenyu Wang <[email protected]> Cc: [email protected] Acked-by: Tvrtko Ursulin <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Chris Wilson <[email protected]>
2017-04-28drm/i915/guc: Fix sleep under spinlock during resetTvrtko Ursulin1-6/+1
Looks like intel_guc_reset had the ability to sleep under the uncore spinlock since forever but it wasn't detected until the recent changes annotated the wait for register with might_sleep. I have fixed it by removing holding of the uncore spinlock over the call to gen6_hw_domain_reset, since I do not see that is really needed. But there is always a possibility I am missing some nasty detail so please double check. Signed-off-by: Tvrtko Ursulin <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Michal Wajdeczko <[email protected]> Cc: Arkadiusz Hiler <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Oscar Mateo <[email protected]> Acked-by: Michel Thierry <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]>
2017-04-27drm/i915: Defer context state allocation for legacy ring submissionChris Wilson2-59/+50
Almost from the outset for execlists, we used deferred allocation of the logical context and rings. Then we ported the infrastructure for pinning contexts back to legacy, and so now we are able to also implement deferred allocation for context objects prior to first use on the legacy submission. v2: We still need to differentiate between legacy engines, Joonas is fixing that but I want this first ;) (Joonas) Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Joonas Lahtinen <[email protected]>
2017-04-27drm/i915: Rename gen8_(un)request_engine_reset to gen8_reset_engine_start/cancelMichel Thierry1-4/+4
As all other functions related to resetting engines are using reset_engine. v2: remove _request_ and use start/cancel instead (Chris) Cc: Chris Wilson <[email protected]> Signed-off-by: Michel Thierry <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]>
2017-04-27drm/i915: Fix stale comment about I915_RESET_IN_PROGRESS flagMichel Thierry1-1/+1
It has been replaced by I915_RESET_BACKOFF / I915_RESET_HANDOFF. Signed-off-by: Michel Thierry <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]>
2017-04-26drm: mali-dp: use div_u64 for expensive 64-bit divisionsArnd Bergmann1-5/+4
On 32-bit machines, we can't divide 64-bit integers: drivers/gpu/drm/arm/malidp_crtc.o: In function `malidp_crtc_atomic_check': malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3c0): undefined reference to `__aeabi_uldivmod' malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3dc): undefined reference to `__aeabi_uldivmod' This calls the div_u64 function explicitly instead. Fixes: 4cea4e9f6690 ("drm: mali-dp: Add plane upscaling support") Signed-off-by: Arnd Bergmann <[email protected]>
2017-04-26drm/i915/glk: Don't allow 12 bpc when htotal is too bigAnder Conselvan de Oliveira1-0/+5
Display workaround #1139 for Geminilake instructs us to restrict HDMI to 8 bpc when htotal is greater than 5460. Otherwise, the pipe is unable to generate a proper signal and is left in a state where corruption is seen with other modes. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100440 Cc: Shashank Sharma <[email protected]> Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Shashank Sharma <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-04-26drm/i915: Confirm the request is still active before adding it to the awaitChris Wilson1-0/+3
Although we do check the completion-status of the request before actually adding a wait on it (either to its submit fence or its completion dma-fence), we currently do not check before adding it to the dependency lists. In fact, without checking for a completed request we may try to use the signaler after it has been retired and its dependency tree freed: [ 60.044057] BUG: KASAN: use-after-free in __list_add_valid+0x1d/0xd0 at addr ffff880348c9e6a0 [ 60.044118] Read of size 8 by task gem_exec_fence/530 [ 60.044164] CPU: 1 PID: 530 Comm: gem_exec_fence Tainted: G E 4.11.0-rc7+ #46 [ 60.044226] Hardware name: ��������������������������������� ���������������������������������/���������������������������������, BIOS RYBDWi35.86A.0246.2 [ 60.044290] Call Trace: [ 60.044337] dump_stack+0x4d/0x6a [ 60.044383] kasan_object_err+0x21/0x70 [ 60.044435] kasan_report+0x225/0x4e0 [ 60.044488] ? __list_add_valid+0x1d/0xd0 [ 60.044534] ? kasan_kmalloc+0xad/0xe0 [ 60.044587] __asan_load8+0x5e/0x70 [ 60.044639] __list_add_valid+0x1d/0xd0 [ 60.044788] __i915_priotree_add_dependency+0x67/0x130 [i915] [ 60.044895] i915_gem_request_await_request+0xa8/0x370 [i915] [ 60.044974] i915_gem_request_await_dma_fence+0x129/0x140 [i915] [ 60.045049] i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915] [ 60.045077] ? save_stack+0xb1/0xd0 [ 60.045105] ? save_stack_trace+0x1b/0x20 [ 60.045132] ? save_stack+0x46/0xd0 [ 60.045158] ? kasan_kmalloc+0xad/0xe0 [ 60.045184] ? __kmalloc+0xd8/0x670 [ 60.045229] ? drm_ioctl+0x359/0x640 [drm] [ 60.045256] ? SyS_ioctl+0x41/0x70 [ 60.045330] ? i915_vma_move_to_active+0x540/0x540 [i915] [ 60.045360] ? tty_insert_flip_string_flags+0xa1/0xf0 [ 60.045387] ? tty_flip_buffer_push+0x63/0x70 [ 60.045414] ? remove_wait_queue+0xa9/0xc0 [ 60.045441] ? kasan_unpoison_shadow+0x35/0x50 [ 60.045467] ? kasan_kmalloc+0xad/0xe0 [ 60.045494] ? kasan_check_write+0x14/0x20 [ 60.045568] i915_gem_execbuffer2+0xdb/0x2a0 [i915] [ 60.045616] drm_ioctl+0x359/0x640 [drm] [ 60.045705] ? i915_gem_execbuffer+0x5a0/0x5a0 [i915] [ 60.045751] ? drm_version+0x150/0x150 [drm] [ 60.045778] ? compat_start_thread+0x60/0x60 [ 60.045805] ? plist_del+0xda/0x1a0 [ 60.045833] do_vfs_ioctl+0x12e/0x910 [ 60.045860] ? ioctl_preallocate+0x130/0x130 [ 60.045886] ? pci_mmcfg_check_reserved+0xc0/0xc0 [ 60.045913] ? vfs_write+0x196/0x240 [ 60.045939] ? __fget_light+0xa7/0xc0 [ 60.045965] SyS_ioctl+0x41/0x70 [ 60.045991] entry_SYSCALL_64_fastpath+0x17/0x98 [ 60.046017] RIP: 0033:0x7feb2baefc47 [ 60.046042] RSP: 002b:00007fff56d28e58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 60.046075] RAX: ffffffffffffffda RBX: 00007fff56d290a8 RCX: 00007feb2baefc47 [ 60.046102] RDX: 00007fff56d29050 RSI: 00000000c0406469 RDI: 0000000000000003 [ 60.046129] RBP: 00007fff56d29050 R08: 000055ecc4cd27d0 R09: 00007feb2bda8600 [ 60.046154] R10: 0000000000000073 R11: 0000000000000246 R12: 00000000c0406469 [ 60.046177] R13: 0000000000000003 R14: 000000000000000f R15: 0000000000000099 [ 60.046203] Object at ffff880348c9e680, in cache i915_dependency size: 64 [ 60.046225] Allocated: [ 60.046246] PID = 530 [ 60.046269] save_stack_trace+0x1b/0x20 [ 60.046292] save_stack+0x46/0xd0 [ 60.046318] kasan_kmalloc+0xad/0xe0 [ 60.046343] kasan_slab_alloc+0x12/0x20 [ 60.046368] kmem_cache_alloc+0xab/0x650 [ 60.046445] i915_gem_request_await_request+0x88/0x370 [i915] [ 60.046559] i915_gem_request_await_dma_fence+0x129/0x140 [i915] [ 60.046705] i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915] [ 60.046849] i915_gem_execbuffer2+0xdb/0x2a0 [i915] [ 60.046936] drm_ioctl+0x359/0x640 [drm] [ 60.046987] do_vfs_ioctl+0x12e/0x910 [ 60.047038] SyS_ioctl+0x41/0x70 [ 60.047090] entry_SYSCALL_64_fastpath+0x17/0x98 [ 60.047139] Freed: [ 60.047179] PID = 530 [ 60.047223] save_stack_trace+0x1b/0x20 [ 60.047269] save_stack+0x46/0xd0 [ 60.047317] kasan_slab_free+0x72/0xc0 [ 60.047366] kmem_cache_free+0x39/0x160 [ 60.047512] i915_gem_request_retire+0x83f/0x930 [i915] [ 60.047657] i915_gem_request_alloc+0x166/0x600 [i915] [ 60.047799] i915_gem_do_execbuffer.isra.37+0xad8/0x26b0 [i915] [ 60.047897] i915_gem_execbuffer2+0xdb/0x2a0 [i915] [ 60.047942] drm_ioctl+0x359/0x640 [drm] [ 60.047968] do_vfs_ioctl+0x12e/0x910 [ 60.047993] SyS_ioctl+0x41/0x70 [ 60.048019] entry_SYSCALL_64_fastpath+0x17/0x98 [ 60.048044] Memory state around the buggy address: [ 60.048066] ffff880348c9e580: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc [ 60.048105] ffff880348c9e600: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc [ 60.048138] >ffff880348c9e680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ 60.048170] ^ [ 60.048191] ffff880348c9e700: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc [ 60.048225] ffff880348c9e780: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc Note to hit the use-after-free requires us to be passed back a request via a fence-array, that is from explicit fencing accumulated into a sync-file fence-array. Fixes: 52e542090701 ("drm/i915/scheduler: Record all dependencies upon request construction") Testcase: igt/gem_exec_fence/expired-history Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Michał Winiarski <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit ade0b0c965f59176daddbef9c4717354034f9bce) Signed-off-by: Jani Nikula <[email protected]>
2017-04-26drm/i915: Avoid busy-spinning on VLV_GLTC_PW_STATUS mmioChris Wilson1-22/+24
The busy-spin, as the first stage of intel_wait_for_register(), is currently under suspicion for causing: [ 62.034926] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1 [ 62.034928] Modules linked in: i2c_dev i915 intel_gtt drm_kms_helper prime_numbers [ 62.034932] CPU: 1 PID: 183 Comm: kworker/1:2 Not tainted 4.11.0-rc7+ #471 [ 62.034933] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [ 62.034934] Workqueue: pm pm_runtime_work [ 62.034936] task: ffff880275a04ec0 task.stack: ffffc900002d8000 [ 62.034936] RIP: 0010:__intel_wait_for_register_fw+0x77/0x1a0 [i915] [ 62.034937] RSP: 0018:ffffc900002dbc38 EFLAGS: 00000082 [ 62.034939] RAX: ffffc90003530094 RBX: 0000000000130094 RCX: 0000000000000001 [ 62.034940] RDX: 00000000000000a1 RSI: ffff88027fd15e58 RDI: 0000000000000000 [ 62.034941] RBP: ffffc900002dbc78 R08: 0000000000000002 R09: 0000000000000000 [ 62.034942] R10: ffffc900002dbc18 R11: ffff880276429dd0 R12: ffff8802707c0000 [ 62.034943] R13: 00000000000000a0 R14: 0000000000000000 R15: 00000000fffefc10 [ 62.034945] FS: 0000000000000000(0000) GS:ffff88027fd00000(0000) knlGS:0000000000000000 [ 62.034945] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 62.034947] CR2: 00007ffd3cd98ff8 CR3: 0000000274c19000 CR4: 00000000001006e0 [ 62.034947] Call Trace: [ 62.034948] intel_wait_for_register+0x77/0x140 [i915] [ 62.034949] vlv_suspend_complete+0x23/0x5b0 [i915] [ 62.034950] intel_runtime_suspend+0x16c/0x2a0 [i915] [ 62.034950] pci_pm_runtime_suspend+0x50/0x180 [ 62.034951] ? pci_pm_runtime_resume+0xa0/0xa0 [ 62.034952] __rpm_callback+0xc5/0x210 [ 62.034953] rpm_callback+0x1f/0x80 [ 62.034953] ? pci_pm_runtime_resume+0xa0/0xa0 [ 62.034954] rpm_suspend+0x118/0x580 [ 62.034955] pm_runtime_work+0x64/0x90 [ 62.034956] process_one_work+0x1bb/0x3e0 [ 62.034956] worker_thread+0x46/0x4f0 [ 62.034957] ? __schedule+0x18b/0x610 [ 62.034958] kthread+0xff/0x140 [ 62.034958] ? process_one_work+0x3e0/0x3e0 [ 62.034959] ? kthread_create_on_node+ and related hard lockups in CI for byt and bsw. Note this effectively reverts commits 41ce405e6894 and b27366958869 ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()") v2: Convert bool allow into a u32 mask for clarity and repeat the comment on vlv rc6 timing to justify the 3ms timeout used for the wait (Ville) Fixes: 41ce405e6894 ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()") Fixes: b27366958869 ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100718 Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Tomi Sarvela <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Tested-by: Tomi Sarvela <[email protected]> (cherry picked from commit 3dd14c04d77d7d702de5aa7157df4cc9417329f3) Signed-off-by: Jani Nikula <[email protected]>
2017-04-26drm/i915/selftests: Allocate inode/file dynamicallyChris Wilson1-13/+32
Avoid having too large a stack by creating the fake struct inode/file on the heap instead. drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file': drivers/gpu/drm/i915/selftests/mock_drm.c:46:1: error: the frame size of 1328 bytes is larger than 1280 bytes [-Werror=frame-larger-than=] drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file_free': drivers/gpu/drm/i915/selftests/mock_drm.c:54:1: error: the frame size of 1312 bytes is larger than 1280 bytes [-Werror=frame-larger-than=] Reported-by: Arnd Bergmann <[email protected]> Fixes: 66d9cb5d805a ("drm/i915: Mock the GEM device for self-testing") Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Matthew Auld <[email protected]> Cc: Arnd Bergmann <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Joonas Lahtinen <[email protected]> (cherry picked from commit 2310b3c952c5dc56c2e08f71b907b8e23ab3270d) Signed-off-by: Jani Nikula <[email protected]>
2017-04-26drm/i915: Fix system hang with EI UP masked on HaswellMika Kuoppala1-2/+2
Previously with commit a9c1f90c8e17 ("drm/i915: Don't mask EI UP interrupt on IVB|SNB") certain, seemingly unrelated bit (GEN6_PM_RP_UP_EI_EXPIRED) was needed to be unmasked for IVB and SNB in order to prevent system hang with chained batchbuffers. Our CI was seeing incomplete results with tests that used chained batches and it was found out that HSW needs to have this same bit unmasked to reliably survive chained batches. Always unmask GEN6_PM_RP_UP_EI_EXPIRED on Haswell to prevent system hang with batch chaining. Testcase: igt/gem_exec_fence/nb-await-default Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100672 Cc: Chris Wilson <[email protected]> Cc: [email protected] Signed-off-by: Mika Kuoppala <[email protected]> Acked-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 3396a273851c14634b98bb27be37508b06df94f4) Signed-off-by: Jani Nikula <[email protected]>
2017-04-26drm/i915: checking for NULL instead of IS_ERR() in mock selftestsDan Carpenter1-1/+1
i915_gem_request_alloc() uses error pointers. It never returns NULLs. Fixes: 0daf0113cff6 ("drm/i915: Mock infrastructure for request emission") Signed-off-by: Dan Carpenter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/20170413195217.GA26108@mwanda Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> (cherry picked from commit be02f7556447a0dee672acb5e462f03377b98ae8) Signed-off-by: Jani Nikula <[email protected]>
2017-04-26drm/i915: Perform link quality check unconditionally during long pulseVille Syrjälä1-2/+13
Apparently some DP sinks are a little nuts and cause HPD to drop intermittently during modesets. This happens eg. on an ASUS PB287Q. In oder to recover from this we can't really use the previous connector status to determine if the link needs retraining, so let's just ignore that piece of information and do the retrain unconditionally. We do of course still check whether the link is supposed to be running or not. To actually get read out the EDID and update things properly we also need to nuke the goto out added by commit 7d23e3c37bb3 ("drm/i915: Cleaning up intel_dp_hpd_pulse"). I'm actually not sure why that was there. Perhaps to avoid an EDID read if the connector status didn't appear to change, but that sort of thing is quite racy and would have failed anyway if we failed to keep up with the hotplugs (if we missed the HPD down in between two HPD ups). And now that we take this codepath unconditionally we definitely need to drop the goto as otherwise we would never do the EDID read. v2: Drop the goto that made us skip EDID reads entirely. Doh! v3: Rebase due to locking changes s/apparely/apparently/ in the comment (Chris) Cc: [email protected] Cc: Manasi Navare <[email protected]> Cc: Palmer Dabbelt <[email protected]> Reported-by: Palmer Dabbelt <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99766 References: https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.html Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 1a36147bb93921651f7fbd7a6e522da6c349081b) Signed-off-by: Jani Nikula <[email protected]>
2017-04-26drm/i915: Fix use after free in lpe_audio_platdev_destroy()Chris Wilson1-1/+8
[31908.547136] BUG: KASAN: use-after-free in intel_lpe_audio_teardown+0x78/0xb0 [i915] at addr ffff8801f7788358 [31908.547297] Read of size 8 by task drv_selftest/3781 [31908.547405] CPU: 0 PID: 3781 Comm: drv_selftest Tainted: G BU W 4.10.0+ #451 [31908.547553] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [31908.547682] Call Trace: [31908.547772] dump_stack+0x68/0x9f [31908.547857] kasan_object_err+0x1c/0x70 [31908.547947] kasan_report_error+0x1f1/0x4f0 [31908.548038] ? kfree+0xaa/0x170 [31908.548121] kasan_report+0x34/0x40 [31908.548211] ? klist_children_get+0x20/0x30 [31908.548472] ? intel_lpe_audio_teardown+0x78/0xb0 [i915] [31908.548567] __asan_load8+0x5e/0x70 [31908.548824] intel_lpe_audio_teardown+0x78/0xb0 [i915] [31908.549080] intel_audio_deinit+0x28/0x80 [i915] [31908.549315] i915_driver_unload+0xe4/0x360 [i915] [31908.549551] ? i915_driver_load+0x1d70/0x1d70 [i915] [31908.549651] ? trace_hardirqs_on+0xd/0x10 [31908.549885] i915_pci_remove+0x23/0x30 [i915] [31908.549978] pci_device_remove+0x5c/0x100 [31908.550069] device_release_driver_internal+0x1db/0x2e0 [31908.550165] driver_detach+0x68/0xc0 [31908.550256] bus_remove_driver+0x8b/0x150 [31908.550346] driver_unregister+0x3e/0x60 [31908.550439] pci_unregister_driver+0x1d/0x110 [31908.550531] ? find_module_all+0x7a/0xa0 [31908.550791] i915_exit+0x1a/0x87 [i915] [31908.550881] SyS_delete_module+0x264/0x2c0 [31908.550971] ? free_module+0x430/0x430 [31908.551064] ? trace_hardirqs_off_caller+0x16/0x110 [31908.551159] ? trace_hardirqs_on_caller+0x16/0x280 [31908.551256] ? trace_hardirqs_on_thunk+0x1a/0x1c [31908.551350] entry_SYSCALL_64_fastpath+0x1c/0xb1 [31908.551440] RIP: 0033:0x7f1d67312ec7 [31908.551520] RSP: 002b:00007ffebe34e888 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [31908.551650] RAX: ffffffffffffffda RBX: ffffffff811123f6 RCX: 00007f1d67312ec7 [31908.551743] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000560d0af476b8 [31908.551837] RBP: ffff880233d87f98 R08: 0000000000000000 R09: 00007ffebe34e8b8 [31908.551930] R10: 00007f1d68adf8c0 R11: 0000000000000206 R12: 0000000000000000 [31908.552023] R13: 0000560d0af46440 R14: 0000000000000034 R15: 00007ffebe34d860 [31908.552121] ? trace_hardirqs_off_caller+0x16/0x110 [31908.552217] Object at ffff8801f7788000, in cache kmalloc-2048 size: 2048 [31908.552306] Allocated: [31908.552377] PID = 3781 [31908.552456] save_stack_trace+0x16/0x20 [31908.552539] kasan_kmalloc+0xee/0x190 [31908.552627] __kmalloc+0xdb/0x1b0 [31908.552713] platform_device_alloc+0x27/0x90 [31908.552804] platform_device_register_full+0x36/0x220 [31908.553066] intel_lpe_audio_init+0x41e/0x570 [i915] [31908.553320] intel_audio_init+0xd/0x40 [i915] [31908.553552] i915_driver_load+0x13f5/0x1d70 [i915] [31908.553788] i915_pci_probe+0x65/0xe0 [i915] [31908.553881] pci_device_probe+0xda/0x140 [31908.553969] driver_probe_device+0x400/0x660 [31908.554058] __driver_attach+0x11c/0x120 [31908.554147] bus_for_each_dev+0xe6/0x150 [31908.554237] driver_attach+0x26/0x30 [31908.554325] bus_add_driver+0x26b/0x3b0 [31908.554412] driver_register+0xce/0x190 [31908.554502] __pci_register_driver+0xaf/0xc0 [31908.554589] 0xffffffffa0550063 [31908.554675] do_one_initcall+0x8b/0x1e0 [31908.554764] do_init_module+0x102/0x325 [31908.554852] load_module+0x3aad/0x45e0 [31908.554944] SyS_finit_module+0x169/0x1a0 [31908.555033] entry_SYSCALL_64_fastpath+0x1c/0xb1 [31908.555119] Freed: [31908.555188] PID = 3781 [31908.555266] save_stack_trace+0x16/0x20 [31908.555349] kasan_slab_free+0xb0/0x180 [31908.555436] kfree+0xaa/0x170 [31908.555520] platform_device_release+0x76/0x80 [31908.555610] device_release+0x45/0xe0 [31908.555698] kobject_put+0x11f/0x260 [31908.555785] put_device+0x12/0x20 [31908.555871] platform_device_unregister+0x1b/0x20 [31908.556135] intel_lpe_audio_teardown+0x5c/0xb0 [i915] [31908.556390] intel_audio_deinit+0x28/0x80 [i915] [31908.556622] i915_driver_unload+0xe4/0x360 [i915] [31908.556858] i915_pci_remove+0x23/0x30 [i915] [31908.556948] pci_device_remove+0x5c/0x100 [31908.557037] device_release_driver_internal+0x1db/0x2e0 [31908.557129] driver_detach+0x68/0xc0 [31908.557217] bus_remove_driver+0x8b/0x150 [31908.557304] driver_unregister+0x3e/0x60 [31908.557394] pci_unregister_driver+0x1d/0x110 [31908.557653] i915_exit+0x1a/0x87 [i915] [31908.557741] SyS_delete_module+0x264/0x2c0 [31908.557834] entry_SYSCALL_64_fastpath+0x1c/0xb1 [31908.557919] Memory state around the buggy address: [31908.558005] ffff8801f7788200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [31908.558127] ffff8801f7788280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [31908.558255] >ffff8801f7788300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [31908.558374] ^ [31908.558467] ffff8801f7788380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [31908.558595] ffff8801f7788400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb v2: Just leak the memory (8 bytes) as freeing it ourselves is not safe, and we need to coordinate a proper fix in platform_device itself. Fixes: eef57324d926 ("drm/i915: setup bridge for HDMI LPE audio driver") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99952 Signed-off-by: Chris Wilson <[email protected]> Cc: Pierre-Louis Bossart <[email protected]> Cc: Jerome Anand <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Takashi Iwai <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Takashi Iwai <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> (cherry picked from commit 48ae80741da4b8a26b6df0f765713912bc7cc480) Signed-off-by: Jani Nikula <[email protected]>
2017-04-26drm/i915: Use the right mapping_gfp_mask for final shmem allocationChris Wilson1-1/+1
Many sightings report the greater prevalence of allocation failures. This is all due to the incorrect use of mapping_gfp_constraint(), so remove it in favour of just querying the mapping_gfp_mask() which are the exact gfp_t we wanted in the first place. We still do expect a higher chance of reporting ENOMEM, as that is the intention of using __GFP_NORETRY -- to fail rather than oom after having reclaimed from our bo caches, and having done a direct|kswapd reclaim pass. Reported-by: Jason Ekstrand <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100594 Fixes: 24f8e00a8a2e ("drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx allocations") Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Joonas Lahtinen <[email protected]> (cherry picked from commit b268d9fe0f10544f5f7a1b7015e2b97075e6215d) Signed-off-by: Jani Nikula <[email protected]>
2017-04-26drm/i915: Make legacy cursor updates more unsyncedVille Syrjälä1-11/+20
We're clearing the legacy_cursor_update flag before calling drm_atomic_helper_setup_commit() which means the helper will wait for the flip to complete before cleaning up the framebuffers. That's not what we want for the legacy cursor, so let's clear the flag after setting up the commit. Also toss in a FIXME about solving these problems in a nicer way using the fabled vblank workers. v2: Also unsync with legacy page flips Cc: Maarten Lankhorst <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Uwe Kleine-König <[email protected]> Cc: Rafael Ristovski <[email protected]> Fixes: a5509abda48e ("drm/i915: Fix legacy cursor vs. watermarks for ILK-BDW") Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Maarten Lankhorst <[email protected]> (cherry picked from commit 895203044067af64400cedbc055898bcec98d102) Signed-off-by: Jani Nikula <[email protected]>
2017-04-26drm/i915: Apply a cond_resched() to the saturated signalerChris Wilson1-1/+14
If the engine is continually completing nops, we can saturate the signaler and keep it working indefinitely. This angers the NMI watchdog! A good example is to disable semaphores on snb and run igt/gem_exec_nop - the parallel, multi-engine workloads are more than sufficient to hog the CPU, preventing the system from even processing ICMP echo replies. v2: Tvrtko dug into cond_resched() on x86 and found that it only depended upon preempt_count and not tif_need_resched() - which means that we would always call schedule() at that point. Fixes: c81d46138da6 ("drm/i915: Convert trace-irq to the breadcrumb waiter") Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Tvrtko Ursulin <[email protected]> (cherry picked from commit a7980a640cbd339aa80f406d1786a275a2c320bc) Signed-off-by: Jani Nikula <[email protected]>
2017-04-26drm/i915: Park the signaler before sleepingChris Wilson1-3/+3
If the signal to park arrives before we sleep, then we need to check kthread_should_park() before sleeping to avoid missing the signal. Otherwise, if the signal arrives whilst we are processing completed requests, we will reset the current->state back to TASK_INTERRUPTIBLE and so miss the wakeup. Fixes: fe3288b5da2c ("drm/i915: Park the breadcrumbs signaler across a GPU reset") Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Tvrtko Ursulin <[email protected]> (cherry picked from commit b1becb88268beb72df6495e35d3d76c138d215bb) Signed-off-by: Jani Nikula <[email protected]>
2017-04-26drm/i915: Skip waking the signaler when enabling before request submissionChris Wilson4-7/+9
If we are enabling the breadcrumbs signaling prior to submitting the request, we know that we cannot have missed the interrupt and can therefore skip immediately waking the signaler to check. This reduces a significant chunk of the __i915_gem_request_submit() overhead for inter-engine synchronisation, for example in gem_exec_whisper. Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Tvrtko Ursulin <[email protected]>
2017-04-26Merge tag 'gvt-next-fixes-2017-04-20' of https://github.com/01org/gvt-linux ↵Jani Nikula7-40/+42
into drm-intel-next-fixes gvt-next-fixes-2017-04-20 - some code optimization from Changbin - debug message cleanup after QoS merge - misc fixes for display mmio init, reset vgpu warning, etc. Signed-off-by: Jani Nikula <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.