summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-08-18drm/i915: Propagate fence errorsChris Wilson
Errors spread like wildfire, and must eventually be returned to the user. They need to be captured and passed along the flow of fences, infecting each in turn with the existing error, until finally they fall out of a user visible result. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190817232511.11391-1-chris@chris-wilson.co.uk
2019-08-18drm/i915/uc: Never fail on HuC firmware errorsMichal Wajdeczko
There is no need to mark whole GPU as wedged just because of the custom HuC fw failure as users can always verify actual HuC firmware status using existing HUC_STATUS ioctl. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190818095204.31568-4-michal.wajdeczko@intel.com
2019-08-18drm/i915/uc: Don't always fail on unavailable GuC firmwareMichal Wajdeczko
If we failed to fetch default GuC firmware and we didn't plan to use it for the submission and we never have used GuC before then we may continue normal driver load, no need to declare GPU wedged (we can use execlist for submission) and it is safe to run without the HuC (users will check HuC status anyway). Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190818095204.31568-3-michal.wajdeczko@intel.com
2019-08-18drm/i915/guc: Don't open log relay if GuC is not runningMichal Wajdeczko
As we plan to continue driver load after GuC initialization failure, we can't assume that GuC log data will be available just because GuC was initially enabled. We must check that GuC is still running instead. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190818095204.31568-2-michal.wajdeczko@intel.com
2019-08-18drm/vboxvideo: Make structure vbox_fb_helper_funcs constantNishka Dasgupta
The static structure vbox_fb_helper_funcs, of type drm_fb_helper_funcs, is used only when it is passed as the third argument to drm_fb_helper_fbdev_setup(), which does not modify it. Hence make it constant to protect it from unintended modifications. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190813062548.24770-1-nishkadg.linux@gmail.com
2019-08-17dma-fence: Store the timestamp in the same union as the cb_listChris Wilson
The timestamp and the cb_list are mutually exclusive, the cb_list can only be added to prior to being signaled (and once signaled we drain), while the timestamp is only valid upon being signaled. Both the timestamp and the cb_list are only valid while the fence is alive, and as soon as no references are held can be replaced by the rcu_head. By reusing the union for the timestamp, we squeeze the base dma_fence struct to 64 bytes on x86-64. v2: Sort the union chronologically Suggested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Christian König <christian.koenig@amd.com> Acked-by: Christian König <christian.koenig@amd.com>. Link: https://patchwork.freedesktop.org/patch/msgid/20190817153022.5749-1-chris@chris-wilson.co.uk
2019-08-17dma-fence: Simply wrap dma_fence_signal_locked with dma_fence_signalChris Wilson
Currently dma_fence_signal() tries to avoid the spinlock and only takes it if absolutely required to walk the callback list. However, to allow for some users to surreptitiously insert lazy signal callbacks that do not depend on enabling the signaling mechanism around every fence, we always need to notify the callbacks on signaling. As such, we will always need to take the spinlock and dma_fence_signal() effectively becomes a clone of dma_fence_signal_locked(). v2: Update the test_and_set_bit() before entering the spinlock. v3: Drop the test_[and_set]_bit() before the spinlock, it's a caller error so expected to be very unlikely. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Christian König <christian.koenig@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190817152300.5370-1-chris@chris-wilson.co.uk
2019-08-17dma-fence: Avoid list_del during fence->cb_list iterationChris Wilson
Before we notify the fence signal callback, we remove the cb from the list. However, since we are processing the entire list from underneath the spinlock, we do not need to individual delete each element, but can simply reset the link and the entire list. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190817144736.7826-4-chris@chris-wilson.co.uk
2019-08-17dma-fence: Shrink size of struct dma_fenceChris Wilson
Rearrange the couple of 32-bit atomics hidden amongst the field of pointers that unnecessarily caused the compiler to insert some padding, shrinks the size of the base struct dma_fence from 80 to 72 bytes on x86-64. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190817144736.7826-3-chris@chris-wilson.co.uk
2019-08-17drm/panel: tpo-td043mtea1: remove redundant assignmentColin Ian King
Variable val is initialized to a value in a for-loop that is never read and hence it is redundant. Remove it. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190817122124.29650-1-colin.king@canonical.com
2019-08-17drm/i915/uc: Never fail on uC preparation stepMichal Wajdeczko
Let's wait with decision about importance of uC failure to hardware initialization step. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190817131144.26884-4-michal.wajdeczko@intel.com
2019-08-17drm/i915/uc: Cleanup fw fetch on every GuC/HuC init failureMichal Wajdeczko
Be consistent and always perform fw fetch cleanup in GuC/HuC specific init functions on every failure. Also while converting firmware status to error, stop treating SELECTED as non-error, as long term we should not see it. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190817131144.26884-3-michal.wajdeczko@intel.com
2019-08-17drm/i915/uc: Cleanup fw fetch only if it was successfulMichal Wajdeczko
We can rely on firmware status AVAILABLE to determine if any firmware cleanup is required. Also don't unconditionally reset fw status to SELECTED as we will loose MISSING/ERROR codes. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190817131144.26884-2-michal.wajdeczko@intel.com
2019-08-17drm/i915/selftests: Check the context sizeChris Wilson
Add a redzone to our context image and check the HW does not write into after a context save, to verify that we have the correct context size. (This does vary with feature bits, so test with a live setup that should match how we run userspace.) v2: Check the redzone on every context unpin v3: Use a kernel context to prevent loading garbage for ringbuffer submission Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190817073711.5897-1-chris@chris-wilson.co.uk
2019-08-17drm/i915/gtt: Fold gen8 insertions into oneMika Kuoppala
As we give page directory pointer (lvl 3) structure for pte insertion, we can fold both versions into one function by teaching it to get pdp regardless of top level. v2: naming and asserts (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@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/20190816094754.26492-1-mika.kuoppala@linux.intel.com
2019-08-16drm/i915/uc: Add explicit DISABLED state for firmwareMichal Wajdeczko
We really need to have separate NOT_SUPPORTED state (for lack of hardware support) and DISABLED state (to indicate user decision) as we will have to take special steps even if GuC firmware is now disabled but hardware exists and could have been previously used. v2: fix logic (Chris/CI) v3: use proper check to avoid probe failure (CI) v4: explain status transitions (Chris) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190816205658.15020-1-michal.wajdeczko@intel.com
2019-08-16drm/i915: Wrappers for display register waitsDaniele Ceraolo Spurio
To reduce the number of explicit dev_priv->uncore calls in the display code ahead of the introduction of dev_priv->de_uncore, this patch introduces a wrapper for one of the main usages of it, the register waits. When we transition to the new uncore, we can just update the wrapper to point to the appropriate structure. Since the vast majority of waits are on a set or clear of a bit or mask, add set & clear flavours of the wrapper to simplify the code. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@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/20190816012343.36433-7-daniele.ceraolospurio@intel.com
2019-08-16drm/i915: Move gmbus definitions out of i915_reg.hDaniele Ceraolo Spurio
They're not related to registers, so move them to the more appropriate intel_gmbus.h Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190816012343.36433-4-daniele.ceraolospurio@intel.com
2019-08-16drm/i915: Move engine IDs out of i915_reg.hDaniele Ceraolo Spurio
To remove the dependency between the GT headers and i915_reg.h, move the definition of the engine IDs/classes to intel_engine_types.h Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190816012343.36433-3-daniele.ceraolospurio@intel.com
2019-08-16drm/i915: Move i915_power_well_id out of i915_reg.hDaniele Ceraolo Spurio
It has nothing to do with registers, so move it to the more appropriate intel_display_power.h Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190816012343.36433-2-daniele.ceraolospurio@intel.com
2019-08-16drm/i915/execlists: Lift process_csb() out of the irq-off spinlockChris Wilson
If we only call process_csb() from the tasklet, though we lose the ability to bypass ksoftirqd interrupt processing on direct submission paths, we can push it out of the irq-off spinlock. The penalty is that we then allow schedule_out to be called concurrently with schedule_in requiring us to handle the usage count (baked into the pointer itself) atomically. As we do kick the tasklets (via local_bh_enable()) after our submission, there is a possibility there to see if we can pull the local softirq processing back from the ksoftirqd. v2: Store the 'switch_priority_hint' on submission, so that we can safely check during process_csb(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190816171608.11760-1-chris@chris-wilson.co.uk
2019-08-16drm/omap: displays: Remove unused panel driversLaurent Pinchart
drm_panel-based drivers for the ACX565AKM, LB035Q02, LS037V7DW01, NL8048HL11, TD028TTEC1 and TD043MTEA1 are available, remove the omapdrm-specific drivers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190816122228.9475-3-laurent.pinchart@ideasonboard.com
2019-08-16video: omapfb2: Make standard and custom panel drivers mutually exclusiveLaurent Pinchart
Standard DRM panel drivers for several panels used by omapfb2 are now available. Their module name clashes with the modules from drivers/video/fbdev/omap2/omapfb/displays, part of the deprecated omapfb2 fbdev driver. As omapfb2 can only be compiled when the omapdrm driver is disabled, and the DRM panel drivers are useless in that case, make the omapfb2 panels depend on the standard DRM panels being disabled to fix the name clash. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: dc2e1e5b279966 ("drm/panel: Add driver for the Toppoly TD043MTEA1 panel") Fixes: 415b8dd0871188 ("drm/panel: Add driver for the Toppoly TD028TTEC1 panel") Fixes: 1c8fc3f0c5d280 ("drm/panel: Add driver for the Sony ACX565AKM panel") Fixes: c9cf4c2a3bd35f ("drm/panel: Add driver for the Sharp LS037V7DW01 panel") Fixes: df439abe650177 ("drm/panel: Add driver for the NEC NL8048HL11 panel") Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> [added tags] Link: https://patchwork.freedesktop.org/patch/msgid/20190816122228.9475-2-laurent.pinchart@ideasonboard.com
2019-08-16drm/i915: Markup expected timeline locks for i915_activeChris Wilson
As every i915_active_request should be serialised by a dedicated lock, i915_active consists of a tree of locks; one for each node. Markup up the i915_active_request with what lock is supposed to be guarding it so that we can verify that the serialised updated are indeed serialised. 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/20190816121000.8507-2-chris@chris-wilson.co.uk
2019-08-16drm/i915/gt: Mark context->active_count as protected by timeline->mutexChris Wilson
We use timeline->mutex to protect modifications to context->active_count, and the associated enable/disable callbacks. Due to complications with engine-pm barrier there is a path where we used a "superlock" to provide serialised protect and so could not unconditionally assert with lockdep that it was always held. However, we can mark the mutex as taken (noting that we may be nested underneath ourselves) which means we can be reassured the right timeline->mutex is always treated as held and let lockdep roam free. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190816121000.8507-1-chris@chris-wilson.co.uk
2019-08-16drm/i915/wopcm: Fix SPDX tag locationMichal Wajdeczko
Move SPDX tag to first line, and update year to 2019. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190816105501.31020-6-michal.wajdeczko@intel.com
2019-08-16drm/i915/wopcm: Update error messagesMichal Wajdeczko
All WOPCM error messages are device specific, so use device specific error functions. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190816105501.31020-5-michal.wajdeczko@intel.com
2019-08-16drm/i915/wopcm: Try to use already locked WOPCM layoutMichal Wajdeczko
If WOPCM layout is already locked in HW we shouldn't continue with our own partitioning as it could be likely different and we will be unable to enforce it and fail. Instead we should try to reuse what is already programmed, maybe there will be a fit. This should enable us to reload driver with slightly different HuC firmware (or even without HuC) without need to reboot. v2: reordered/rebased Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Winiarski <michal.winiarski@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190816105501.31020-4-michal.wajdeczko@intel.com
2019-08-16drm/i915/wopcm: Check WOPCM layout separately from calculationsMichal Wajdeczko
We can do WOPCM partitioning using rough estimates and limits and perform detailed check as separate step. v2: oops! s/max/min v3: consolidate overflow checks (Daniele) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190816105501.31020-3-michal.wajdeczko@intel.com
2019-08-16drm/i915/uc: Move FW size sanity check back to fetchMichał Winiarski
While we need to know WOPCM size to do this sanity check, it has more to do with FW than with WOPCM. Let's move the check to fetch phase, it's not like WOPCM is going to grow in the meantime. v2: rebased v3: use __intel_uc_fw_get_upload_size (Daniele) Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jackie Li <yaodong.li@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190816105501.31020-2-michal.wajdeczko@intel.com
2019-08-16drm/i915/buddy: use kmemleak_update_traceMatthew Auld
Since nodes are cached in a free-list, and potentially marked as free without actually being destroyed, thus allowing them to be opportunistically re-allocated, we should apply kmemleak_update_trace every time a node is given a new owner and marked as allocated, to aid in debugging. Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190816105357.14340-2-matthew.auld@intel.com
2019-08-16drm/i915/buddy: tidy up i915_buddy_finiMatthew Auld
If we are leaking nodes don't hide it. Also stop trying to be "defensive" and instead embrace Kasan et al. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190816105357.14340-1-matthew.auld@intel.com
2019-08-16drm: rcar-du: lvds: Fix bridge_to_rcar_lvdsFabrizio Castro
Using name "bridge" for macro bridge_to_rcar_lvds argument doesn't work when the pointer name used by the caller is not "bridge". Rename the argument to "b" to allow for any pointer name. While at it, fix the connector_to_rcar_lvds macro similarly. Fixes: c6a27fa41fab ("drm: rcar-du: Convert LVDS encoder code to bridge driver") Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> [Fix connector_to_rcar_lvds] Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2019-08-16drm: Remove bridge support from legacy helpersLaurent Pinchart
DRM bridges are only used by atomic drivers, and none of them use the legacy helpers. Drop bridge support from those helpers to prepare for making the bridge operations atomic-aware. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2019-08-16drm: Don't include drm/drm_encoder_slave.h when not neededLaurent Pinchart
The dw-hdmi, kirin and imx drivers include the drm/drm_encoder_slave.h header but don't use the encoder slave API. Remove it or replace it with drm/drm_encoder.h as needed. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2019-08-16dma-buf: Restore seqlock around dma_resv updatesChris Wilson
This reverts 67c97fb79a7f ("dma-buf: add reservation_object_fences helper") dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper") 0e1d8083bddb ("dma-buf: further relax reservation_object_add_shared_fence") 5d344f58da76 ("dma-buf: nuke reservation_object seq number") The scenario that defeats simply grabbing a set of shared/exclusive fences and using them blissfully under RCU is that any of those fences may be reallocated by a SLAB_TYPESAFE_BY_RCU fence slab cache. In this scenario, while keeping the rcu_read_lock we need to establish that no fence was changed in the dma_resv after a read (or full) memory barrier. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190814182401.25009-1-chris@chris-wilson.co.uk
2019-08-16drm/i915: Use the associated uncore for the vmChris Wilson
We store the gt&uncore to use in the i915_address_space, so use it! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190816083143.23558-1-chris@chris-wilson.co.uk
2019-08-16drm/i915: Extract intel_frontbuffer active trackingChris Wilson
Move the active tracking for the frontbuffer operations out of the i915_gem_object and into its own first class (refcounted) object. In the process of detangling, we switch from low level request tracking to the easier i915_active -- with the plan that this avoids any potential atomic callbacks as the frontbuffer tracking wishes to sleep as it flushes. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190816074635.26062-1-chris@chris-wilson.co.uk
2019-08-16Merge branch 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux ↵Dave Airlie
into drm-next A couple of independent patches extracted from the 5.3 pull request, fixed for merge conflicts and a single unused variable warning. And the drmP.h removal from Sam. Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-08-15drm/i915: Protect request retirement with timeline->mutexChris Wilson
Forgo the struct_mutex requirement for request retirement as we have been transitioning over to only using the timeline->mutex for controlling the lifetime of a request on that timeline. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190815205709.24285-4-chris@chris-wilson.co.uk
2019-08-15drm/i915/gt: Guard timeline pinning without relying on struct_mutexChris Wilson
In preparation for removing struct_mutex from around context retirement, we need to make timeline pinning and unpinning safe. Since multiple engines/contexts can share a single timeline, we cannot rely on borrowing the context mutex (otherwise we could state that the timeline is only pinned/unpinned inside the context pin/unpin and so guarded by it). However, we only perform a sequence of atomic operations inside the timeline pin/unpin and the sequence of those operations is safe for a concurrent unpin / pin, so we can relax the struct_mutex requirement. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190815205709.24285-3-chris@chris-wilson.co.uk
2019-08-15drm/i915/gt: Convert timeline tracking to spinlockChris Wilson
Convert the active_list manipulation of timelines to use spinlocks so that we can perform the updates from underneath a quick interrupt callback, if need be. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190815205709.24285-2-chris@chris-wilson.co.uk
2019-08-15drm/i915/gt: Track timeline activeness in enter/exitChris Wilson
Lift moving the timeline to/from the active_list on enter/exit in order to shorten the active tracking span in comparison to the existing pin/unpin. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190815205709.24285-1-chris@chris-wilson.co.uk
2019-08-15drm/i915/cml: Add Missing PCI IDsAnusha Srivatsa
The BSpec has added three new IDS for CML. Update the IDs in accordance to the Spec. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190812222737.29356-1-anusha.srivatsa@intel.com
2019-08-15drm/i915: Move tasklet kicking to __i915_request_queue callerChris Wilson
Since __i915_request_queue() may be called from hardirq (timer) context, we cannot use local_bh_disable/enable at the lower level. As we do want to kick the tasklet to speed up initial submission or preemption for normal client submission, lift it to the normal process context callpath. 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/20190815042031.27750-1-chris@chris-wilson.co.uk
2019-08-15drm/i915/icl: Add gen11 specific render breadcrumbsMika Kuoppala
Flush according to what gen11 expects when writing breadcrumbs. As only the seqnowrite + flush differs between engine and gens, enclose the footer to helper. v2: avoid problem of sane local naming by not using them Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@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/20190815094929.358-1-mika.kuoppala@linux.intel.com
2019-08-15drm/i915/icl: Add command cache invalidateMika Kuoppala
On the set of invalidations, we need to add command cache invalidate as a new domain. Signed-off-by: Mika Kuoppala <mika.kuoppala@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/20190815083055.14132-2-mika.kuoppala@linux.intel.com
2019-08-15drm/i915/icl: Implement gen11 flush including tile cacheMika Kuoppala
Add tile cache flushing for gen11. To relive us from the burden of previous obsolete workarounds, make a dedicated flush/invalidate callback for gen11. To fortify an independent single flush, do post sync op as there are indications that without it we don't flush everything. This should also make this callback more readily usable in tgl (see l3 fabric flush). v2: whitespacing Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@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/20190815083055.14132-1-mika.kuoppala@linux.intel.com
2019-08-15drm/i915/selftest/buddy: fixup igt_buddy_alloc_rangeMatthew Auld
Dan reported the following static checker warning: drivers/gpu/drm/i915/selftests/i915_buddy.c:670 igt_buddy_alloc_range() error: we previously assumed 'block' could be null (see line 665) Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190815103210.11802-1-matthew.auld@intel.com
2019-08-15drm/i915: Convert a few more bland dmesg info to be device specificChris Wilson
Looking around the GT initialisation, we have a few log messages we think are interesting enough present to the user (such as the amount of L4 cache) and a few to inform them of the result of actions or conflicting HW restrictions (i.e. quirks). These are device specific messages, so use the dev family of printk. v2: shave off a few bytes of .rodata! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190815093604.3618-1-chris@chris-wilson.co.uk
generated by cgit (git 2.34.1) at 2025-09-11 05:40:47 +0000