summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-10-09drm/i915/gt: execlists->active is serialised by the taskletChris Wilson3-9/+27
The active/pending execlists is no longer protected by the engine->active.lock, but is serialised by the tasklet instead. Update the locking around the debug and stats to follow suit. v2: local_bh_disable() to prevent recursing into the tasklet in case we trigger a softirq (Tvrtko) Fixes: df403069029d ("drm/i915/execlists: Lift process_csb() out of the irq-off spinlock") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191009160906.16195-1-chris@chris-wilson.co.uk
2019-10-09drm/i915/execlists: Protect peeking at execlists->activeChris Wilson1-2/+5
Now that we dropped the engine->active.lock serialisation from around process_csb(), direct submission can run concurrently to the interrupt handler. As such execlists->active may be advanced as we dequeue, dropping the reference to the request. We need to employ our RCU request protection to ensure that the request is not freed too early. Fixes: df403069029d ("drm/i915/execlists: Lift process_csb() out of the irq-off spinlock") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191009100955.21477-1-chris@chris-wilson.co.uk
2019-10-09drm/i915: Select DPLL's via maskMatt Roper1-22/+26
This slightly simplifies the EHL DPLL4 handling and also gives us more flexibility in the future in case we need to skip the use of specific PLL's (e.g., due to hardware workarounds and such). v2: - Replace GENMASK() with or'd BIT()'s to make the specific DPLLs more explicit. (Ville) - s/unsigned/unsigned long/. (Lucas) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191008172920.11362-1-matthew.d.roper@intel.com
2019-10-09drm/i915/color: move check of gamma_enable to specific func/platformSwati Sharma1-3/+9
Moved common code to check gamma_enable to specific funcs per platform in bit_precision func. icl doesn't support that and chv has separate enable knob for CGM LUT. v2: -Simplified chv_gamma_precision() [Ville] Signed-off-by: Swati Sharma <swati2.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191009065542.27415-3-swati2.sharma@intel.com
2019-10-09drm/i915/color: fix broken gamma state-checker during bootSwati Sharma1-3/+18
Premature gamma lut prepration and loading which was getting reflected in first modeset causing different colors on screen during boot. Issue: In BIOS, gamma is disabled by default. However, legacy read_luts() was setting crtc_state->base.gamma_lut and gamma_lut was programmed with junk values which led to visual artifacts (different colored screens instead of usual black during boot). Fix: Calling read_luts() only when gamma is enabled which will happen after first modeset. This fix is independent from the revert 1b8588741fdc ("Revert "drm/i915/color: Extract icl_read_luts()"") and should fix different colors on screen in legacy platforms too. v2: -Added gamma_enable checks inside read_luts() [Ville/Jani N] -Corrected gamma enable check for CHV [Ville] v3: -Added check in ilk_read_luts() [Ville] -Simplified gamma enable check for CHV [Ville] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111809 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111885 Tested-by: Jani Saarinen <jani.saarinen@intel.com> Signed-off-by: Swati Sharma <swati2.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191009065542.27415-2-swati2.sharma@intel.com
2019-10-09drm/i915/selftests: fix null pointer dereference on pointer dataColin Ian King1-1/+1
In the case where data fails to be allocated the error exit path is via label 'out' where data is dereferenced in a for-loop. Fix this by exiting via the label 'out_file' instead to avoid the null pointer dereference. Addresses-Coverity: ("Dereference after null check") Fixes: 50d16d44cce4 ("drm/i915/selftests: Exercise context switching in parallel") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191009100024.23077-1-colin.king@canonical.com
2019-10-09drm/i915/selftests: Hold request reference over waitsChris Wilson1-39/+34
Take a reference on the request before submitting it to the HW and then waiting on it for selftest_workarounds. Once submitted, the request may be freed by a background worker, unless we take an extra reference for ourselves. References: https://bugs.freedesktop.org/show_bug.cgi?id=111926 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/20191009061759.3189-1-chris@chris-wilson.co.uk
2019-10-09drm/i915/gt: Give engine->kernel_context distinct timeline lock classesChris Wilson1-0/+9
Assign a separate lockclass to the perma-pinned timelines of the kernel_context, such that we can use them from within the user timelines should we ever need to inject GPU operations to fixup faults during request construction. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191008185941.15228-1-chris@chris-wilson.co.uk
2019-10-08drm/i915/region: support volatile objectsMatthew Auld9-21/+68
Volatile objects are marked as DONTNEED while pinned, therefore once unpinned the backing store can be discarded. This is limited to kernel internal objects. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: CQ Tang <cq.tang@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191008160116.18379-4-matthew.auld@intel.com
2019-10-08drm/i915/region: support contiguous allocationsMatthew Auld9-39/+239
Some kernel internal objects may need to be allocated as a contiguous block, also thinking ahead the various kernel io_mapping interfaces seem to expect it, although this is purely a limitation in the kernel API...so perhaps something to be improved. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: Michael J Ruhl <michael.j.ruhl@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191008160116.18379-3-matthew.auld@intel.com
2019-10-08drm/i915: introduce intel_memory_regionMatthew Auld13-0/+729
Support memory regions, as defined by a given (start, end), and allow creating GEM objects which are backed by said region. The immediate goal here is to have something to represent our device memory, but later on we also want to represent every memory domain with a region, so stolen, shmem, and of course device. At some point we are probably going to want use a common struct here, such that we are better aligned with say TTM. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191008160116.18379-2-matthew.auld@intel.com
2019-10-08drm/i915/gt: Flush submission tasklet before waiting/retiringChris Wilson3-14/+34
A common bane of ours is arbitrary delays in ksoftirqd processing our submission tasklet. Give the submission tasklet a kick before we wait to avoid those delays eating into a tight timeout. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191008105655.13256-1-chris@chris-wilson.co.uk
2019-10-08drm/i915/perf: drop list of streamsLionel Landwerlin2-21/+1
At some point in time there was the idea that we could have multiple stream from the same piece of HW but that never materialized and given the hard time we already have making everything work with the submission side, there is no real point having this list of 1 element around. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191008140111.5437-1-chris@chris-wilson.co.uk
2019-10-08drm/i915/selftests: Assign the intel_runtime_pm pointer for mock_uncoreChris Wilson4-3/+8
Couple up our mock_uncore to know about the fake global device and its runtime powermanagement. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191008145045.23157-1-chris@chris-wilson.co.uk
2019-10-08drm: damage_helper: Fix race checking plane->state->fbSean Paul1-1/+7
Since the dirtyfb ioctl doesn't give us any hints as to which plane is scanning out the fb it's marking as damaged, we need to loop through planes to find it. Currently we just reach into plane state and check, but that can race with another commit changing the fb out from under us. This patch locks the plane before checking the fb and will release the lock if the plane is not displaying the dirty fb. Fixes: b9fc5e01d1ce ("drm: Add helper to implement legacy dirtyfb") Cc: Rob Clark <robdclark@gmail.com> Cc: Deepak Rawat <drawat@vmware.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.0+ Reported-by: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190904202938.110207-1-sean@poorly.run
2019-10-08drm/i915/selftests: Assign the mock_engine->uncore shortcutChris Wilson1-0/+1
Set up the engine->uncore shortcut on mock_engine creation. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191008071121.25088-1-chris@chris-wilson.co.uk
2019-10-08drm/i915/execlists: Assign virtual_engine->uncore from first siblingChris Wilson1-0/+1
Copy across the engine->uncore shortcut to the virtual_engine from its first physical engine, similar to the handling of the engine->gt backpointer. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191008070342.4045-1-chris@chris-wilson.co.uk
2019-10-08drm/i915/tgl: Add DC3CO counter in i915_dmc_infoAnshuman Gupta2-0/+9
Adding DC3CO counter in i915_dmc_info debugfs will be useful for DC3CO validation. DMC firmware uses DMC_DEBUG3 register as DC3CO counter register on TGL, as per B.Specs DMC_DEBUG3 is general purpose register. v1: comment modification for DMC_DBUG3. using GEN >= 12 check instead of IS_TIGERLAKE() to print DMC_DEBUG3 counter value. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191003081738.22101-7-anshuman.gupta@intel.com
2019-10-08drm/i915/tgl: Switch between dc3co and dc5 based on display idlenessAnshuman Gupta4-1/+163
DC3CO is useful power state, when DMC detects PSR2 idle frame while an active video playback, playing 30fps video on 60hz panel is the classic example of this use case. B.Specs:49196 has a restriction to enable DC3CO only for Video Playback. It will be worthy to enable DC3CO after completion of each pageflip and switch back to DC5 when display is idle because driver doesn't differentiate between video playback and a normal pageflip. We will use Frontbuffer flush call tgl_dc3co_flush() to enable DC3CO state only for ORIGIN_FLIP flush call, because DC3CO state has primarily targeted for VPB use case. We are not interested here for frontbuffer invalidates calls because that triggers PSR2 exit, which will explicitly disable DC3CO. DC5 and DC6 saves more power, but can't be entered during video playback because there are not enough idle frames in a row to meet most PSR2 panel deep sleep entry requirement typically 4 frames. As PSR2 existing implementation is using minimum 6 idle frames for deep sleep, it is safer to enable DC5/6 after 6 idle frames (By scheduling a delayed work of 6 idle frames, once DC3CO has been enabled after a pageflip). After manually waiting for 6 idle frames DC5/6 will be enabled and PSR2 deep sleep idle frames will be restored to 6 idle frames, at this point DMC will triggers DC5/6 once PSR2 enters to deep sleep after 6 idle frames. In future when we will enable S/W PSR2 tracking, we can change the PSR2 required deep sleep idle frames to 1 so DMC can trigger the DC5/6 immediately after S/W manual waiting of 6 idle frames get complete. v2: calculated s/w state to switch over dc3co when there is an update. [Imre] Used cancel_delayed_work_sync() in order to avoid any race with already scheduled delayed work. [Imre] v3: Cancel_delayed_work_sync() may blocked the commit work. hence dropping it, dc5_idle_thread() checks the valid wakeref before putting the reference count, which avoids any chances of dropping a zero wakeref. [Imre (IRC)] v4: Used frontbuffer flush mechanism. [Imre] v5: Used psr.pipe to extract frontbuffer busy bits. [Imre] Used cancel_delayed_work_sync() in encoder disable path. [Imre] Used mod_delayed_work() instead of cancelling and scheduling a delayed work. [Imre] Used psr.lock in tgl_dc5_idle_thread() to enable psr2 deep sleep. [Imre] Removed DC5_REQ_IDLE_FRAMES macro. [Imre] v6: Used dc3co_exitline check instead of TGL and dc3co allowed_dc_mask checks, used delayed_work_pending with the psr lock and removed the psr2_deep_slp_disabled flag. [Imre] v7: Code refactoring, moved most of functional code to inte_psr.c [Imre] Using frontbuffer_bits on psr.pipe check instead of busy_frontbuffer_bits. [Imre] Calculating dc3co_exit_delay in intel_psr_enable_locked. [Imre] Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191003081738.22101-6-anshuman.gupta@intel.com
2019-10-08drm/i915/tgl: Do modeset to enable and configure DC3CO exitlineAnshuman Gupta3-2/+93
DC3CO enabling B.Specs sequence requires to enable end configure exit scanlines to TRANS_EXITLINE register, programming this register has to be part of modeset sequence as this can't be change when transcoder or port is enabled. When system boots with only eDP panel there may not be real modeset as BIOS has already programmed the necessary registers, therefore it needs to force a modeset to enable and configure DC3CO exitline. v1: Computing dc3co_exitline crtc state from a DP encoder compute config. [Imre] Enabling and disabling DC3CO PSR2 transcoder exitline from encoder pre_enable and post_disable hooks. [Imre] Computing dc3co_exitline instead of has_dc3co_exitline bool. [Imre] v2: Code refactoring for symmetry and to avoid exported function. [Imre] Removing IS_TIGERLAKE check from compute_config, adding PIPE_A restriction and clearing dc3co_exitline state if crtc is not active or it is not PSR2 capable in dc3co exitline compute_config. [Imre] Using GEN >= 12 check in dc3co exitline get_config. [Imre] Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191003081738.22101-5-anshuman.gupta@intel.com
2019-10-08drm/i915/tgl: Enable DC3CO state in "DC Off" power wellAnshuman Gupta3-9/+73
Add target_dc_state and used by set_target_dc_state API in order to enable DC3CO state with existing DC states. target_dc_state will enable/disable the desired DC state in DC_STATE_EN reg when "DC Off" power well gets disable/enable. v2: commit log improvement. v3: Used intel_wait_for_register to wait for DC3CO exit. [Imre] Used gen9_set_dc_state() to allow/disallow DC3CO. [Imre] Moved transcoder psr2 exit line enablement from tgl_allow_dc3co() to a appropriate place haswell_crtc_enable(). [Imre] Changed the DC3CO power well enabled call back logic as recommended in review comments. [Imre] v4: Used wait_for_us() instead of intel_wait_for_reg(). [Imre (IRC)] v5: using udelay() instead of waiting for DC3CO exit status. v6: Fixed minor unwanted change. v7: Removed DC3CO powerwell and POWER_DOMAIN_VIDEO. v8: Uniform checks by using only target_dc_state instead of allowed_dc_mask in "DC off" power well callback. [Imre] Adding "DC off" power well id to older platforms. [Imre] Removed psr2_deep_sleep flag from tgl_set_target_dc_state. [Imre] v9: Used switch case for target DC state in gen9_dc_off_power_well_disable(), checking DC3CO state against allowed DC mask, using WARN_ON() in tgl_set_target_dc_state(). [Imre] v10: Code refactoring and using sanitize_target_dc_state(). [Imre] Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191003081738.22101-4-anshuman.gupta@intel.com
2019-10-08drm/i915/tgl: Add DC3CO mask to allowed_dc_mask and gen9_dc_maskAnshuman Gupta2-7/+25
Enable dc3co state in enable_dc module param and add dc3co enable mask to allowed_dc_mask and gen9_dc_mask. v1: Adding enable_dc=3,4 options to enable DC3CO with DC5 and DC6 independently. [Animesh] v2: Using a switch statement for cleaner code. [Animesh] Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191003081738.22101-3-anshuman.gupta@intel.com
2019-10-08drm/i915/tgl: Add DC3CO required register and bitsAnshuman Gupta1-0/+8
Adding following definition to i915_reg.h 1. DC_STATE_EN register DC3CO bit fields and masks. DC3CO enable bit will be used by driver to make DC3CO ready for DMC f/w and status bit will be used as DC3CO entry status. 2. Transcoder EXITLINE register and its bit fields and mask. Transcoder EXITLINE enable bit represents PSR2 idle frame reset should be applied at exit line and exitlines mask represent required number of scanlines at which DC3CO exit happens. B.Specs:49196 v1: Use of REG_BIT and using extra space for EXITLINE_ macro definition. [Animesh] v2: Grouping EXITLINE reg bits with EXITLINE(trans) define, no functional change. [Ville] Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191007094607.2111-1-anshuman.gupta@intel.com
2019-10-08drm/i915/perf: Set the exclusive stream under perf->lockChris Wilson1-11/+1
The BKL struct_mutex is no more, the only serialisation we required for setting the exclusive stream is already managed by ce->pin_mutex in gen8_configure_all_contexts(). As such, we can manipulate i915_perf.exclusive_stream underneath our own (already held) perf->lock. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191007140812.10963-2-chris@chris-wilson.co.uk Link: https://patchwork.freedesktop.org/patch/msgid/20191007210942.18145-2-chris@chris-wilson.co.uk
2019-10-08drm/i915/perf: Wean ourselves off dev_privChris Wilson3-428/+422
Use the local uncore accessors for the GT rather than using the [not-so] magic global dev_priv mmio routines. In the process, we also teach the perf stream to use backpointers to the i915_perf rather than digging it out of dev_priv. v2: Rebase onto i915_perf_types.h Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20191007140812.10963-1-chris@chris-wilson.co.uk Link: https://patchwork.freedesktop.org/patch/msgid/20191007210942.18145-1-chris@chris-wilson.co.uk
2019-10-08drm/i915: Fix Kconfig indentationKrzysztof Kozlowski2-78/+78
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191007173346.9379-1-krzk@kernel.org
2019-10-08drm/sun4i: dsi: Fix video start delay computationJagan Teki1-1/+1
The LCD timing definitions between Linux DRM vs Allwinner are different, below diagram shows this clear differences. Active Front Sync Back Region Porch Porch <-----------------------><----------------><--------------><--------------> //////////////////////| ////////////////////// | ////////////////////// |.................. ................ ________________ <----- [hv]display -----> <------------- [hv]sync_start ------------> <--------------------- [hv]sync_end ----------------------> <-------------------------------- [hv]total ------------------------------> <----- lcd_[xy] --------> <- lcd_[hv]spw -> <---------- lcd_[hv]bp ---------> <-------------------------------- lcd_[hv]t ------------------------------> The DSI driver misinterpreted the vbp term from the BSP code to refer only to the backporch, when in fact it was backporch + sync. Thus the driver incorrectly used the vertical front porch plus sync in its calculation of the DRQ set bit value, when it should not have included the sync timing. Including additional sync timings leads to flip_done timed out as: WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 [CRTC:46:crtc-0] vblank wait timed out Modules linked in: CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted 5.1.0-next-20190514-00029-g09e5b0ed0a58 #18 Hardware name: Allwinner sun8i Family Workqueue: events deferred_probe_work_func [<c010ed54>] (unwind_backtrace) from [<c010b76c>] (show_stack+0x10/0x14) [<c010b76c>] (show_stack) from [<c0688c70>] (dump_stack+0x84/0x98) [<c0688c70>] (dump_stack) from [<c011d9e4>] (__warn+0xfc/0x114) [<c011d9e4>] (__warn) from [<c011da40>] (warn_slowpath_fmt+0x44/0x68) [<c011da40>] (warn_slowpath_fmt) from [<c040cd50>] (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) [<c040cd50>] (drm_atomic_helper_wait_for_vblanks.part.1) from [<c040e694>] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) [<c040e694>] (drm_atomic_helper_commit_tail_rpm) from [<c040e4dc>] (commit_tail+0x40/0x6c) [<c040e4dc>] (commit_tail) from [<c040e5cc>] (drm_atomic_helper_commit+0xbc/0x128) [<c040e5cc>] (drm_atomic_helper_commit) from [<c0411b64>] (restore_fbdev_mode_atomic+0x1cc/0x1dc) [<c0411b64>] (restore_fbdev_mode_atomic) from [<c04156f8>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) [<c04156f8>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c0415774>] (drm_fb_helper_set_par+0x30/0x54) [<c0415774>] (drm_fb_helper_set_par) from [<c03ad450>] (fbcon_init+0x560/0x5ac) [<c03ad450>] (fbcon_init) from [<c03eb8a0>] (visual_init+0xbc/0x104) [<c03eb8a0>] (visual_init) from [<c03ed1b8>] (do_bind_con_driver+0x1b0/0x390) [<c03ed1b8>] (do_bind_con_driver) from [<c03ed780>] (do_take_over_console+0x13c/0x1c4) [<c03ed780>] (do_take_over_console) from [<c03ad800>] (do_fbcon_takeover+0x74/0xcc) [<c03ad800>] (do_fbcon_takeover) from [<c013c9c8>] (notifier_call_chain+0x44/0x84) [<c013c9c8>] (notifier_call_chain) from [<c013cd20>] (__blocking_notifier_call_chain+0x48/0x60) [<c013cd20>] (__blocking_notifier_call_chain) from [<c013cd50>] (blocking_notifier_call_chain+0x18/0x20) [<c013cd50>] (blocking_notifier_call_chain) from [<c03a6e44>] (register_framebuffer+0x1e0/0x2f8) [<c03a6e44>] (register_framebuffer) from [<c04153c0>] (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) [<c04153c0>] (__drm_fb_helper_initial_config_and_unlock) from [<c04158c8>] (drm_fbdev_client_hotplug+0xe8/0x1b8) [<c04158c8>] (drm_fbdev_client_hotplug) from [<c0415a20>] (drm_fbdev_generic_setup+0x88/0x118) [<c0415a20>] (drm_fbdev_generic_setup) from [<c043f060>] (sun4i_drv_bind+0x128/0x160) [<c043f060>] (sun4i_drv_bind) from [<c044b598>] (try_to_bring_up_master+0x164/0x1a0) [<c044b598>] (try_to_bring_up_master) from [<c044b668>] (__component_add+0x94/0x140) [<c044b668>] (__component_add) from [<c0445e1c>] (sun6i_dsi_probe+0x144/0x234) [<c0445e1c>] (sun6i_dsi_probe) from [<c0452ef4>] (platform_drv_probe+0x48/0x9c) [<c0452ef4>] (platform_drv_probe) from [<c04512cc>] (really_probe+0x1dc/0x2c8) [<c04512cc>] (really_probe) from [<c0451518>] (driver_probe_device+0x60/0x160) [<c0451518>] (driver_probe_device) from [<c044f7a4>] (bus_for_each_drv+0x74/0xb8) [<c044f7a4>] (bus_for_each_drv) from [<c045107c>] (__device_attach+0xd0/0x13c) [<c045107c>] (__device_attach) from [<c0450474>] (bus_probe_device+0x84/0x8c) [<c0450474>] (bus_probe_device) from [<c0450900>] (deferred_probe_work_func+0x64/0x90) [<c0450900>] (deferred_probe_work_func) from [<c0135970>] (process_one_work+0x204/0x420) [<c0135970>] (process_one_work) from [<c013690c>] (worker_thread+0x274/0x5a0) [<c013690c>] (worker_thread) from [<c013b3d8>] (kthread+0x11c/0x14c) [<c013b3d8>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) Exception stack(0xde539fb0 to 0xde539ff8) 9fa0: 00000000 00000000 00000000 00000000 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ---[ end trace 495200a78b24980e ]--- random: fast init done [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:48:DSI-1] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] flip_done timed out With the terms(as described in above diagram) fixed, the panel displays correctly without any timeouts. Tested-by: Merlijn Wajer <merlijn@wizzup.org> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191006160303.24413-2-icenowy@aosc.io
2019-10-08Merge tag 'drm-intel-next-2019-10-07' of ↵Dave Airlie196-8011/+11822
git://anongit.freedesktop.org/drm/drm-intel into drm-next UAPI Changes: - Never allow userptr into the mappable GGTT (Chris) No existing users. Avoid anyone from even trying to spare a deadlock scenario. Cross-subsystem Changes: Core Changes: Driver Changes: - Eliminate struct_mutex use as BKL! (Chris) Only used for execbuf serialisation. - Initialize DDI TC and TBT ports (D-I) on Tigerlake (Lucas) - Fix DKL link training for 2.7GHz and 1.62GHz (Jose) - Add Tigerlake DKL PHY programming sequences (Clinton) - Add Tigerlake Thunderbolt PLL divider values (Imre) - drm/i915: Use helpers for drm_mm_node booleans (Chris) - Restrict L3 remapping sysfs interface to dwords (Chris) - Fix audio power up sequence for gen10+ display (Kai) - Skip redundant execlist resubmission (Chris) - Only unwedge if we can reset GPU first (Chris) - Initialise breadcrumb lists on the virtual engine (Chris) - Don't rely on kernel context existing during early errors (Matt A) - Update Icelake+ MG_DP_MODE programming table (Clinton) - Update DMC firmware for Icelake (Anusha) - Downgrade DP MST error after unplugging TypeC cable (Srinivasan) - Limit MST modes based on plane size too (Ville) - Polish intel_tv_mode_valid() (Ville) - Fix g4x sprite scaling stride check with GTT remapping (Ville) - Don't advertize non-exisiting crtcs (Ville) - Clean up encoder->crtc_mask setup (Ville) - Use tc_port instead of port parameter to MG registers (Jose) - Remove static variable for aux last status (Jani) - Implement a better i945gm vblank irq vs. C-states workaround (Ville) - Make the object creation interface consistent (CQ) - Rename intel_vga_msr_write() to intel_vga_reset_io_mem() (Jani, Ville) - Eliminate previous drm_dbg/drm_err usage (Jani) - Move gmbus setup down to intel_modeset_init() (Jani) - Abstract all vgaarb access to intel_vga.[ch] (Jani) - Split out i915_switcheroo.[ch] from i915_drv.c (Jani) - Use intel_gt in has_reset* (Chris) - Eliminate return value for i915_gem_init_early (Matt A) - Selftest improvements (Chris) - Update HuC firmware header version number format (Daniele) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191007134801.GA24313@jlahtine-desk.ger.corp.intel.com
2019-10-07drm/i915/gt: Treat a busy timeline as 'active' while waitingChris Wilson1-1/+3
If we cannot claim the timeline->mutex while preparing for a wait on it, we have to skip the timeline. In doing so, treat it as active so that under a intel_gt_wait_for_idle() loop, we repeat the wait after scheduling away. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191006165002.30312-4-chris@chris-wilson.co.uk
2019-10-07drm/i915/selftests: Appease lockdepChris Wilson1-2/+2
Disable irqs around updating the context image to keep lockdep happy: <4>[ 673.483340] WARNING: possible irq lock inversion dependency detected <4>[ 673.483342] 5.4.0-rc1-CI-Trybot_5118+ #1 Tainted: G U <4>[ 673.483342] -------------------------------------------------------- <4>[ 673.483343] swapper/2/0 just changed the state of lock: <4>[ 673.483344] ffff88845db885a0 (&i915_request_get(rq)->submit/1){-...}, at: __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.483387] but this lock took another, HARDIRQ-unsafe lock in the past: <4>[ 673.483388] (&ce->pin_mutex/2){+...} <4>[ 673.483389] and interrupts could create inverse lock ordering between them. <4>[ 673.483390] other info that might help us debug this: <4>[ 673.483390] Chain exists of: &i915_request_get(rq)->submit/1 --> &engine->active.lock --> &ce->pin_mutex/2 <4>[ 673.483392] Possible interrupt unsafe locking scenario: <4>[ 673.483392] CPU0 CPU1 <4>[ 673.483393] ---- ---- <4>[ 673.483393] lock(&ce->pin_mutex/2); <4>[ 673.483394] local_irq_disable(); <4>[ 673.483395] lock(&i915_request_get(rq)->submit/1); <4>[ 673.483396] lock(&engine->active.lock); <4>[ 673.483396] <Interrupt> <4>[ 673.483397] lock(&i915_request_get(rq)->submit/1); <4>[ 673.483398] *** DEADLOCK *** <4>[ 673.483398] 2 locks held by swapper/2/0: <4>[ 673.483399] #0: ffff8883f61ac9b0 (&(&gt->irq_lock)->rlock){-.-.}, at: gen11_gt_irq_handler+0x42/0x280 [i915] <4>[ 673.483433] #1: ffff88845db8c418 (&(&rq->lock)->rlock){-.-.}, at: intel_engine_breadcrumbs_irq+0x34a/0x5a0 [i915] <4>[ 673.483463] the shortest dependencies between 2nd lock and 1st lock: <4>[ 673.483466] -> (&ce->pin_mutex/2){+...} ops: 614520 { <4>[ 673.483468] HARDIRQ-ON-W at: <4>[ 673.483471] lock_acquire+0xa7/0x1c0 <4>[ 673.483501] live_unlite_restore+0x1d8/0x6c0 [i915] <4>[ 673.483543] __i915_subtests+0xb8/0x210 [i915] <4>[ 673.483581] __run_selftests+0x112/0x170 [i915] <4>[ 673.483615] i915_live_selftests+0x2c/0x60 [i915] <4>[ 673.483644] i915_pci_probe+0x93/0x1b0 [i915] <4>[ 673.483646] pci_device_probe+0x9e/0x120 <4>[ 673.483648] really_probe+0xea/0x420 <4>[ 673.483649] driver_probe_device+0x10b/0x120 <4>[ 673.483651] device_driver_attach+0x4a/0x50 <4>[ 673.483652] __driver_attach+0x97/0x130 <4>[ 673.483653] bus_for_each_dev+0x74/0xc0 <4>[ 673.483654] bus_add_driver+0x142/0x220 <4>[ 673.483655] driver_register+0x56/0xf0 <4>[ 673.483657] do_one_initcall+0x58/0x2ff <4>[ 673.483659] do_init_module+0x56/0x1f8 <4>[ 673.483660] load_module+0x243e/0x29f0 <4>[ 673.483661] __do_sys_finit_module+0xe9/0x110 <4>[ 673.483662] do_syscall_64+0x4f/0x210 <4>[ 673.483665] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 673.483665] INITIAL USE at: <4>[ 673.483667] lock_acquire+0xa7/0x1c0 <4>[ 673.483698] live_unlite_restore+0x1d8/0x6c0 [i915] <4>[ 673.483733] __i915_subtests+0xb8/0x210 [i915] <4>[ 673.483764] __run_selftests+0x112/0x170 [i915] <4>[ 673.483793] i915_live_selftests+0x2c/0x60 [i915] <4>[ 673.483821] i915_pci_probe+0x93/0x1b0 [i915] <4>[ 673.483822] pci_device_probe+0x9e/0x120 <4>[ 673.483824] really_probe+0xea/0x420 <4>[ 673.483825] driver_probe_device+0x10b/0x120 <4>[ 673.483826] device_driver_attach+0x4a/0x50 <4>[ 673.483827] __driver_attach+0x97/0x130 <4>[ 673.483828] bus_for_each_dev+0x74/0xc0 <4>[ 673.483829] bus_add_driver+0x142/0x220 <4>[ 673.483830] driver_register+0x56/0xf0 <4>[ 673.483831] do_one_initcall+0x58/0x2ff <4>[ 673.483833] do_init_module+0x56/0x1f8 <4>[ 673.483834] load_module+0x243e/0x29f0 <4>[ 673.483835] __do_sys_finit_module+0xe9/0x110 <4>[ 673.483836] do_syscall_64+0x4f/0x210 <4>[ 673.483837] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 673.483838] } <4>[ 673.483868] ... key at: [<ffffffffa0a8f132>] __key.70113+0x2/0xffffffffffef2ed0 [i915] <4>[ 673.483869] ... acquired at: <4>[ 673.483935] __execlists_reset+0xfb/0xc20 [i915] <4>[ 673.483965] execlists_reset+0x3d/0x50 [i915] <4>[ 673.483995] intel_engine_reset+0xdf/0x230 [i915] <4>[ 673.484022] live_preempt_hang+0x1d7/0x2e0 [i915] <4>[ 673.484064] __i915_subtests+0xb8/0x210 [i915] <4>[ 673.484130] __run_selftests+0x112/0x170 [i915] <4>[ 673.484163] i915_live_selftests+0x2c/0x60 [i915] <4>[ 673.484193] i915_pci_probe+0x93/0x1b0 [i915] <4>[ 673.484194] pci_device_probe+0x9e/0x120 <4>[ 673.484195] really_probe+0xea/0x420 <4>[ 673.484196] driver_probe_device+0x10b/0x120 <4>[ 673.484197] device_driver_attach+0x4a/0x50 <4>[ 673.484198] __driver_attach+0x97/0x130 <4>[ 673.484199] bus_for_each_dev+0x74/0xc0 <4>[ 673.484200] bus_add_driver+0x142/0x220 <4>[ 673.484202] driver_register+0x56/0xf0 <4>[ 673.484203] do_one_initcall+0x58/0x2ff <4>[ 673.484204] do_init_module+0x56/0x1f8 <4>[ 673.484205] load_module+0x243e/0x29f0 <4>[ 673.484206] __do_sys_finit_module+0xe9/0x110 <4>[ 673.484207] do_syscall_64+0x4f/0x210 <4>[ 673.484208] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 673.484209] -> (&engine->active.lock){..-.} ops: 972791 { <4>[ 673.484211] IN-SOFTIRQ-W at: <4>[ 673.484213] lock_acquire+0xa7/0x1c0 <4>[ 673.484214] _raw_spin_lock_irqsave+0x33/0x50 <4>[ 673.484244] execlists_submission_tasklet+0xaf/0x100 [i915] <4>[ 673.484246] tasklet_action_common.isra.18+0x6c/0x1c0 <4>[ 673.484247] __do_softirq+0xdf/0x47f <4>[ 673.484248] irq_exit+0xba/0xc0 <4>[ 673.484249] do_IRQ+0x83/0x160 <4>[ 673.484250] ret_from_intr+0x0/0x1d <4>[ 673.484252] cpuidle_enter_state+0xb2/0x450 <4>[ 673.484253] cpuidle_enter+0x24/0x40 <4>[ 673.484254] do_idle+0x1e7/0x250 <4>[ 673.484256] cpu_startup_entry+0x14/0x20 <4>[ 673.484257] start_secondary+0x15f/0x1b0 <4>[ 673.484258] secondary_startup_64+0xa4/0xb0 <4>[ 673.484259] INITIAL USE at: <4>[ 673.484261] lock_acquire+0xa7/0x1c0 <4>[ 673.484290] intel_engine_init_active+0x7e/0xb0 [i915] <4>[ 673.484305] intel_engines_setup+0x1cd/0x3b0 [i915] <4>[ 673.484305] i915_gem_init+0x12d/0x900 [i915] <4>[ 673.484305] i915_driver_probe+0xb70/0x15d0 [i915] <4>[ 673.484305] i915_pci_probe+0x43/0x1b0 [i915] <4>[ 673.484305] pci_device_probe+0x9e/0x120 <4>[ 673.484305] really_probe+0xea/0x420 <4>[ 673.484305] driver_probe_device+0x10b/0x120 <4>[ 673.484305] device_driver_attach+0x4a/0x50 <4>[ 673.484305] __driver_attach+0x97/0x130 <4>[ 673.484305] bus_for_each_dev+0x74/0xc0 <4>[ 673.484305] bus_add_driver+0x142/0x220 <4>[ 673.484305] driver_register+0x56/0xf0 <4>[ 673.484305] do_one_initcall+0x58/0x2ff <4>[ 673.484305] do_init_module+0x56/0x1f8 <4>[ 673.484305] load_module+0x243e/0x29f0 <4>[ 673.484305] __do_sys_finit_module+0xe9/0x110 <4>[ 673.484305] do_syscall_64+0x4f/0x210 <4>[ 673.484305] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 673.484305] } <4>[ 673.484305] ... key at: [<ffffffffa0a8f160>] __key.70307+0x0/0xffffffffffef2ea0 [i915] <4>[ 673.484305] ... acquired at: <4>[ 673.484305] _raw_spin_lock_irqsave+0x33/0x50 <4>[ 673.484305] execlists_submit_request+0x2b/0x1e0 [i915] <4>[ 673.484305] submit_notify+0xa8/0x13c [i915] <4>[ 673.484305] __i915_sw_fence_complete+0x81/0x250 [i915] <4>[ 673.484305] i915_sw_fence_wake+0x51/0x70 [i915] <4>[ 673.484305] __i915_sw_fence_complete+0x1ee/0x250 [i915] <4>[ 673.484305] dma_i915_sw_fence_wake+0x1b/0x30 [i915] <4>[ 673.484305] dma_fence_signal_locked+0x9e/0x1b0 <4>[ 673.484305] dma_fence_signal+0x1f/0x40 <4>[ 673.484305] fence_work+0x28/0x80 [i915] <4>[ 673.484305] process_one_work+0x26a/0x620 <4>[ 673.484305] worker_thread+0x37/0x380 <4>[ 673.484305] kthread+0x119/0x130 <4>[ 673.484305] ret_from_fork+0x24/0x50 <4>[ 673.484305] -> (&i915_request_get(rq)->submit/1){-...} ops: 857694 { <4>[ 673.484305] IN-HARDIRQ-W at: <4>[ 673.484305] lock_acquire+0xa7/0x1c0 <4>[ 673.484305] _raw_spin_lock_irqsave_nested+0x39/0x50 <4>[ 673.484305] __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.484305] intel_engine_breadcrumbs_irq+0x3d0/0x5a0 [i915] <4>[ 673.484305] cs_irq_handler+0x39/0x50 [i915] <4>[ 673.484305] gen11_gt_irq_handler+0x17b/0x280 [i915] <4>[ 673.484305] gen11_irq_handler+0x54/0xf0 [i915] <4>[ 673.484305] __handle_irq_event_percpu+0x41/0x2c0 <4>[ 673.484305] handle_irq_event_percpu+0x2b/0x70 <4>[ 673.484305] handle_irq_event+0x2f/0x50 <4>[ 673.484305] handle_edge_irq+0x99/0x1b0 <4>[ 673.484305] do_IRQ+0x7e/0x160 <4>[ 673.484305] ret_from_intr+0x0/0x1d <4>[ 673.484305] cpuidle_enter_state+0xb2/0x450 <4>[ 673.484305] cpuidle_enter+0x24/0x40 <4>[ 673.484305] do_idle+0x1e7/0x250 <4>[ 673.484305] cpu_startup_entry+0x14/0x20 <4>[ 673.484305] start_secondary+0x15f/0x1b0 <4>[ 673.484305] secondary_startup_64+0xa4/0xb0 <4>[ 673.484305] INITIAL USE at: <4>[ 673.484305] lock_acquire+0xa7/0x1c0 <4>[ 673.484305] _raw_spin_lock_irqsave_nested+0x39/0x50 <4>[ 673.484305] __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.484305] __engine_park+0x233/0x420 [i915] <4>[ 673.484305] ____intel_wakeref_put_last+0x1c/0x70 [i915] <4>[ 673.484305] intel_gt_resume+0x202/0x2c0 [i915] <4>[ 673.484305] i915_gem_init+0x36e/0x900 [i915] <4>[ 673.484305] i915_driver_probe+0xb70/0x15d0 [i915] <4>[ 673.484305] i915_pci_probe+0x43/0x1b0 [i915] <4>[ 673.484305] pci_device_probe+0x9e/0x120 <4>[ 673.484305] really_probe+0xea/0x420 <4>[ 673.484305] driver_probe_device+0x10b/0x120 <4>[ 673.484305] device_driver_attach+0x4a/0x50 <4>[ 673.484305] __driver_attach+0x97/0x130 <4>[ 673.484305] bus_for_each_dev+0x74/0xc0 <4>[ 673.484305] bus_add_driver+0x142/0x220 <4>[ 673.484305] driver_register+0x56/0xf0 <4>[ 673.484305] do_one_initcall+0x58/0x2ff <4>[ 673.484305] do_init_module+0x56/0x1f8 <4>[ 673.484305] load_module+0x243e/0x29f0 <4>[ 673.484305] __do_sys_finit_module+0xe9/0x110 <4>[ 673.484305] do_syscall_64+0x4f/0x210 <4>[ 673.484305] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 673.484305] } <4>[ 673.484305] ... key at: [<ffffffffa0a8f6a1>] __key.80173+0x1/0xffffffffffef2960 [i915] <4>[ 673.484305] ... acquired at: <4>[ 673.484305] mark_lock+0x382/0x500 <4>[ 673.484305] __lock_acquire+0x7e1/0x15d0 <4>[ 673.484305] lock_acquire+0xa7/0x1c0 <4>[ 673.484305] _raw_spin_lock_irqsave_nested+0x39/0x50 <4>[ 673.484305] __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.484305] intel_engine_breadcrumbs_irq+0x3d0/0x5a0 [i915] <4>[ 673.484305] cs_irq_handler+0x39/0x50 [i915] <4>[ 673.484305] gen11_gt_irq_handler+0x17b/0x280 [i915] <4>[ 673.484305] gen11_irq_handler+0x54/0xf0 [i915] <4>[ 673.484305] __handle_irq_event_percpu+0x41/0x2c0 <4>[ 673.484305] handle_irq_event_percpu+0x2b/0x70 <4>[ 673.484305] handle_irq_event+0x2f/0x50 <4>[ 673.484305] handle_edge_irq+0x99/0x1b0 <4>[ 673.484305] do_IRQ+0x7e/0x160 <4>[ 673.484305] ret_from_intr+0x0/0x1d <4>[ 673.484305] cpuidle_enter_state+0xb2/0x450 <4>[ 673.484305] cpuidle_enter+0x24/0x40 <4>[ 673.484305] do_idle+0x1e7/0x250 <4>[ 673.484305] cpu_startup_entry+0x14/0x20 <4>[ 673.484305] start_secondary+0x15f/0x1b0 <4>[ 673.484305] secondary_startup_64+0xa4/0xb0 <4>[ 673.484305] stack backtrace: <4>[ 673.484305] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G U 5.4.0-rc1-CI-Trybot_5118+ #1 <4>[ 673.484305] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3183.A00.1905020411 05/02/2019 <4>[ 673.484305] Call Trace: <4>[ 673.484305] <IRQ> <4>[ 673.484305] dump_stack+0x67/0x9b <4>[ 673.484305] check_usage_forwards+0x13c/0x150 <4>[ 673.484305] ? mark_lock+0x382/0x500 <4>[ 673.484305] mark_lock+0x382/0x500 <4>[ 673.484305] ? check_usage_backwards+0x140/0x140 <4>[ 673.484305] __lock_acquire+0x7e1/0x15d0 <4>[ 673.484305] ? debug_object_deactivate+0x17e/0x190 <4>[ 673.484305] lock_acquire+0xa7/0x1c0 <4>[ 673.484305] ? __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.484305] _raw_spin_lock_irqsave_nested+0x39/0x50 <4>[ 673.484305] ? __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.484305] __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.484305] intel_engine_breadcrumbs_irq+0x3d0/0x5a0 [i915] <4>[ 673.484305] cs_irq_handler+0x39/0x50 [i915] <4>[ 673.484305] gen11_gt_irq_handler+0x17b/0x280 [i915] <4>[ 673.484305] gen11_irq_handler+0x54/0xf0 [i915] <4>[ 673.484305] __handle_irq_event_percpu+0x41/0x2c0 <4>[ 673.484305] handle_irq_event_percpu+0x2b/0x70 <4>[ 673.484305] handle_irq_event+0x2f/0x50 <4>[ 673.484305] handle_edge_irq+0x99/0x1b0 <4>[ 673.484305] do_IRQ+0x7e/0x160 <4>[ 673.484305] common_interrupt+0xf/0xf <4>[ 673.484305] </IRQ> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191004203121.31138-1-chris@chris-wilson.co.uk
2019-10-07drm/i915/execlists: Fix annotation for decoupling virtual requestChris Wilson1-1/+2
As we may signal a request and take the engine->active.lock within the signaler, the engine submission paths have to use a nested annotation on their requests -- but we guarantee that we can never submit on the same engine as the signaling fence. <4>[ 723.763281] WARNING: possible circular locking dependency detected <4>[ 723.763285] 5.3.0-g80fa0e042cdb-drmtip_379+ #1 Tainted: G U <4>[ 723.763288] ------------------------------------------------------ <4>[ 723.763291] gem_exec_await/1388 is trying to acquire lock: <4>[ 723.763294] ffff93a7b53221d8 (&engine->active.lock){..-.}, at: execlists_submit_request+0x2b/0x1e0 [i915] <4>[ 723.763378] but task is already holding lock: <4>[ 723.763381] ffff93a7c25f6d20 (&i915_request_get(rq)->submit/1){-.-.}, at: __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 723.763420] which lock already depends on the new lock. <4>[ 723.763423] the existing dependency chain (in reverse order) is: <4>[ 723.763427] -> #2 (&i915_request_get(rq)->submit/1){-.-.}: <4>[ 723.763434] _raw_spin_lock_irqsave_nested+0x39/0x50 <4>[ 723.763478] __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 723.763513] intel_engine_breadcrumbs_irq+0x3aa/0x5e0 [i915] <4>[ 723.763600] cs_irq_handler+0x49/0x50 [i915] <4>[ 723.763659] gen11_gt_irq_handler+0x17b/0x280 [i915] <4>[ 723.763690] gen11_irq_handler+0x54/0xf0 [i915] <4>[ 723.763695] __handle_irq_event_percpu+0x41/0x2d0 <4>[ 723.763699] handle_irq_event_percpu+0x2b/0x70 <4>[ 723.763702] handle_irq_event+0x2f/0x50 <4>[ 723.763706] handle_edge_irq+0xee/0x1a0 <4>[ 723.763709] do_IRQ+0x7e/0x160 <4>[ 723.763712] ret_from_intr+0x0/0x1d <4>[ 723.763717] __slab_alloc.isra.28.constprop.33+0x4f/0x70 <4>[ 723.763720] kmem_cache_alloc+0x28d/0x2f0 <4>[ 723.763724] vm_area_dup+0x15/0x40 <4>[ 723.763727] dup_mm+0x2dd/0x550 <4>[ 723.763730] copy_process+0xf21/0x1ef0 <4>[ 723.763734] _do_fork+0x71/0x670 <4>[ 723.763737] __se_sys_clone+0x6e/0xa0 <4>[ 723.763741] do_syscall_64+0x4f/0x210 <4>[ 723.763744] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 723.763747] -> #1 (&(&rq->lock)->rlock#2){-.-.}: <4>[ 723.763752] _raw_spin_lock+0x2a/0x40 <4>[ 723.763789] __unwind_incomplete_requests+0x3eb/0x450 [i915] <4>[ 723.763825] __execlists_submission_tasklet+0x9ec/0x1d60 [i915] <4>[ 723.763864] execlists_submission_tasklet+0x34/0x50 [i915] <4>[ 723.763874] tasklet_action_common.isra.5+0x47/0xb0 <4>[ 723.763878] __do_softirq+0xd8/0x4ae <4>[ 723.763881] irq_exit+0xa9/0xc0 <4>[ 723.763883] smp_apic_timer_interrupt+0xb7/0x280 <4>[ 723.763887] apic_timer_interrupt+0xf/0x20 <4>[ 723.763892] cpuidle_enter_state+0xae/0x450 <4>[ 723.763895] cpuidle_enter+0x24/0x40 <4>[ 723.763899] do_idle+0x1e7/0x250 <4>[ 723.763902] cpu_startup_entry+0x14/0x20 <4>[ 723.763905] start_secondary+0x15f/0x1b0 <4>[ 723.763908] secondary_startup_64+0xa4/0xb0 <4>[ 723.763911] -> #0 (&engine->active.lock){..-.}: <4>[ 723.763916] __lock_acquire+0x15d8/0x1ea0 <4>[ 723.763919] lock_acquire+0xa6/0x1c0 <4>[ 723.763922] _raw_spin_lock_irqsave+0x33/0x50 <4>[ 723.763956] execlists_submit_request+0x2b/0x1e0 [i915] <4>[ 723.764002] submit_notify+0xa8/0x13c [i915] <4>[ 723.764035] __i915_sw_fence_complete+0x81/0x250 [i915] <4>[ 723.764054] i915_sw_fence_wake+0x51/0x64 [i915] <4>[ 723.764054] __i915_sw_fence_complete+0x1ee/0x250 [i915] <4>[ 723.764054] dma_i915_sw_fence_wake_timer+0x14/0x20 [i915] <4>[ 723.764054] dma_fence_signal_locked+0x9e/0x1c0 <4>[ 723.764054] dma_fence_signal+0x1f/0x40 <4>[ 723.764054] vgem_fence_signal_ioctl+0x67/0xc0 [vgem] <4>[ 723.764054] drm_ioctl_kernel+0x83/0xf0 <4>[ 723.764054] drm_ioctl+0x2f3/0x3b0 <4>[ 723.764054] do_vfs_ioctl+0xa0/0x6f0 <4>[ 723.764054] ksys_ioctl+0x35/0x60 <4>[ 723.764054] __x64_sys_ioctl+0x11/0x20 <4>[ 723.764054] do_syscall_64+0x4f/0x210 <4>[ 723.764054] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 723.764054] other info that might help us debug this: <4>[ 723.764054] Chain exists of: &engine->active.lock --> &(&rq->lock)->rlock#2 --> &i915_request_get(rq)->submit/1 <4>[ 723.764054] Possible unsafe locking scenario: <4>[ 723.764054] CPU0 CPU1 <4>[ 723.764054] ---- ---- <4>[ 723.764054] lock(&i915_request_get(rq)->submit/1); <4>[ 723.764054] lock(&(&rq->lock)->rlock#2); <4>[ 723.764054] lock(&i915_request_get(rq)->submit/1); <4>[ 723.764054] lock(&engine->active.lock); <4>[ 723.764054] *** DEADLOCK *** Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111862 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191004194758.19679-1-chris@chris-wilson.co.uk
2019-10-07drm/i915/gt: Prefer local path to runtime powermanagementChris Wilson14-30/+28
Avoid going to the base i915 device when we already have a path from gt to the runtime powermanagement interface. The benefit is that it looks a bit more self-consistent to always be acquiring the gt->uncore->rpm for use with the gt->uncore. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191007154531.1750-1-chris@chris-wilson.co.uk
2019-10-07drm/i915: make array hw_engine_mask static, makes object smallerColin Ian King1-3/+3
Don't populate the array hw_engine_mask on the stack but instead make it static. Makes the object code smaller by 316 bytes. Before: text data bss dec hex filename 34004 4388 320 38712 9738 gpu/drm/i915/gt/intel_reset.o After: text data bss dec hex filename 33528 4548 320 38396 95fc gpu/drm/i915/gt/intel_reset.o (gcc version 9.2.1, amd64) Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191007154151.23245-1-colin.king@canonical.com
2019-10-07drm/tilcdc: plane: Make structure tilcdc_plane_funcs constantNishka Dasgupta1-1/+1
The static structure tilcdc_plane_funcs, of type drm_plane_funcs, is used only when passed the fourth argument to drm_plane_init(); however, this fourth parameter is declared as const in the function definition. Hence make tilcdc_plane_funcs constant as well. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Signed-off-by: Jyri Sarha <jsarha@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190813090503.9063-1-nishkadg.linux@gmail.com
2019-10-07drm/i915/vbt: Child device size remains unchanged through VBT 229Matt Roper1-1/+1
The latest documented version of the VBT is 229, but no further data has been added to the child device definition in block 2. Update the child device version test to eliminate the "Expected child device config size for VBT version XXX not known; assuming 39" debug messages from the logs. Bspec: 20124 Bspec: 20157 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191002192258.1013-1-matthew.d.roper@intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2019-10-07drm/i915/perf: move perf types to their own headerLionel Landwerlin3-299/+330
Following a pattern used throughout the driver. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190909093116.7747-7-lionel.g.landwerlin@intel.com
2019-10-07drm/i915/gt: Restore dropped 'interruptible' flagChris Wilson1-1/+1
Lost in the rebasing was Tvrtko's reminder that we need to keep an uninterruptible wait around for the Ironlake VT-d w/a Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191006165002.30312-3-chris@chris-wilson.co.uk
2019-10-07drm/bridge: dw-hdmi: Refuse DDC/CI transfers on the internal I2C controllerMatthias Kaehlcke1-0/+10
The DDC/CI protocol involves sending a multi-byte request to the display via I2C, which is typically followed by a multi-byte response. The internal I2C controller only allows single byte reads/writes or reads of 8 sequential bytes, hence DDC/CI is not supported when the internal I2C controller is used. The I2C transfers complete without errors, however the data in the response is garbage. Abort transfers to/from slave address 0x37 (DDC) with -EOPNOTSUPP, to make it evident that the communication is failing. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191002124354.v2.1.I709dfec496f5f0b44a7b61dcd4937924da8d8382@changeid
2019-10-07drm/i915: Update DRIVER_DATE to 20191007Joonas Lahtinen1-2/+2
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-10-07drm/sun4i: sun6i_mipi_dsi: fix DCS long write packet lengthIcenowy Zheng1-2/+2
The packet length of DCS long write packet should not be added with 1 when constructing long write packet. Fix this. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191006160303.24413-4-icenowy@aosc.io
2019-10-07drm/sun4i: dsi: fix the overhead of the horizontal front porchIcenowy Zheng1-4/+5
The formula in the BSP kernel indicates that a 16-byte overhead is used when sending the HFP. However, this value is currently set to 6 in the sun6i_mipi_dsi driver, which makes some panels flashing. Fix this overhead value. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191006160303.24413-3-icenowy@aosc.io
2019-10-07cec: add cec_adapter to cec_notifier_cec_adap_unregister()Hans Verkuil11-22/+28
It is possible for one HDMI connector to have multiple CEC adapters. The typical real-world scenario is that where one adapter is used when the device is in standby, and one that's better/smarter when the device is powered up. The cec-notifier changes were made with that in mind, but I missed that in order to support this you need to tell cec_notifier_cec_adap_unregister() which adapter you are unregistering from the notifier. Add this additional argument. It is currently unused, but once all drivers use this, the CEC core will be adapted for these use-cases. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/e9fc8740-6be6-43a7-beee-ce2d7b54936e@xs4all.nl
2019-10-07Linux 5.4-rc2Linus Torvalds1-2/+2
2019-10-06elf: don't use MAP_FIXED_NOREPLACE for elf executable mappingsLinus Torvalds1-10/+3
In commit 4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map") we changed elf to use MAP_FIXED_NOREPLACE instead of MAP_FIXED for the executable mappings. Then, people reported that it broke some binaries that had overlapping segments from the same file, and commit ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments") re-instated MAP_FIXED for some overlaying elf segment cases. But only some - despite the summary line of that commit, it only did it when it also does a temporary brk vma for one obvious overlapping case. Now Russell King reports another overlapping case with old 32-bit x86 binaries, which doesn't trigger that limited case. End result: we had better just drop MAP_FIXED_NOREPLACE entirely, and go back to MAP_FIXED. Yes, it's a sign of old binaries generated with old tool-chains, but we do pride ourselves on not breaking existing setups. This still leaves MAP_FIXED_NOREPLACE in place for the load_elf_interp() and the old load_elf_library() use-cases, because nobody has reported breakage for those. Yet. Note that in all the cases seen so far, the overlapping elf sections seem to be just re-mapping of the same executable with different section attributes. We could possibly introduce a new MAP_FIXED_NOFILECHANGE flag or similar, which acts like NOREPLACE, but allows just remapping the same executable file using different protection flags. It's not clear that would make a huge difference to anything, but if people really hate that "elf remaps over previous maps" behavior, maybe at least a more limited form of remapping would alleviate some concerns. Alternatively, we should take a look at our elf_map() logic to see if we end up not mapping things properly the first time. In the meantime, this is the minimal "don't do that then" patch while people hopefully think about it more. Reported-by: Russell King <linux@armlinux.org.uk> Fixes: 4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map") Fixes: ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments") Cc: Michal Hocko <mhocko@suse.com> Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-10-06Merge tag 'dma-mapping-5.4-1' of git://git.infradead.org/users/hch/dma-mappingLinus Torvalds1-2/+2
Pull dma-mapping regression fix from Christoph Hellwig: "Revert an incorret hunk from a patch that caused problems on various arm boards (Andrey Smirnov)" * tag 'dma-mapping-5.4-1' of git://git.infradead.org/users/hch/dma-mapping: dma-mapping: fix false positive warnings in dma_common_free_remap()
2019-10-06drm/i915: move gmbus setup down to intel_modeset_init()Jani Nikula2-4/+2
Pair the gmbus setup and teardown in the same layer. This also fixes the double gmbus teardown on the i915_driver_modeset_probe() error path. Move the gmbus setup a bit later in the sequence to make the follow-up refactoring easier, and to pinpoint any unexpected consequences of this change right here, instead of the later refactoring. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191004122019.12009-3-jani.nikula@intel.com
2019-10-06drm/i915: split out i915_switcheroo.[ch] from i915_drv.cJani Nikula5-56/+92
Split out code related to vga switcheroo register/unregister and state handling from i915_drv.c into new i915_switcheroo.[ch] files. It's a bit difficult to draw the line how much to move to the new file from i915_drv.c, but it seemed to me keeping i915_suspend_switcheroo() and i915_resume_switcheroo() in place was the cleanest. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191004122019.12009-2-jani.nikula@intel.com
2019-10-06drm/i915/vga: rename intel_vga_msr_write() to intel_vga_reset_io_mem()Jani Nikula3-3/+3
Rename the function per Ville's suggestion. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191004122019.12009-1-jani.nikula@intel.com
2019-10-06Merge tag 'armsoc-fixes' of ↵Linus Torvalds14-144/+53
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Olof Johansson: "A few fixes this time around: - Fixup of some clock specifications for DRA7 (device-tree fix) - Removal of some dead/legacy CPU OPP/PM code for OMAP that throws warnings at boot - A few more minor fixups for OMAPs, most around display - Enable STM32 QSPI as =y since their rootfs sometimes comes from there - Switch CONFIG_REMOTEPROC to =y since it went from tristate to bool - Fix of thermal zone definition for ux500 (5.4 regression)" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: multi_v7_defconfig: Fix SPI_STM32_QSPI support ARM: dts: ux500: Fix up the CPU thermal zone arm64/ARM: configs: Change CONFIG_REMOTEPROC from m to y ARM: dts: am4372: Set memory bandwidth limit for DISPC ARM: OMAP2+: Fix warnings with broken omap2_set_init_voltage() ARM: OMAP2+: Add missing LCDC midlemode for am335x ARM: OMAP2+: Fix missing reset done flag for am3 and am43 ARM: dts: Fix gpio0 flags for am335x-icev2 ARM: omap2plus_defconfig: Enable more droid4 devices as loadable modules ARM: omap2plus_defconfig: Enable DRM_TI_TFP410 DTS: ARM: gta04: introduce legacy spi-cs-high to make display work again ARM: dts: Fix wrong clocks for dra7 mcasp clk: ti: dra7: Fix mcasp8 clock bits
2019-10-05Merge tag 'kbuild-fixes-v5.4' of ↵Linus Torvalds15-86/+41
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - remove unneeded ar-option and KBUILD_ARFLAGS - remove long-deprecated SUBDIRS - fix modpost to suppress false-positive warnings for UML builds - fix namespace.pl to handle relative paths to ${objtree}, ${srctree} - make setlocalversion work for /bin/sh - make header archive reproducible - fix some Makefiles and documents * tag 'kbuild-fixes-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kheaders: make headers archive reproducible kbuild: update compile-test header list for v5.4-rc2 kbuild: two minor updates for Documentation/kbuild/modules.rst scripts/setlocalversion: clear local variable to make it work for sh namespace: fix namespace.pl script to support relative paths video/logo: do not generate unneeded logo C files video/logo: remove unneeded *.o pattern from clean-files integrity: remove pointless subdir-$(CONFIG_...) integrity: remove unneeded, broken attempt to add -fshort-wchar modpost: fix static EXPORT_SYMBOL warnings for UML build kbuild: correct formatting of header in kbuild module docs kbuild: remove SUBDIRS support kbuild: remove ar-option and KBUILD_ARFLAGS
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-27 15:51:46 +0300