summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2020-03-05drm/amdgpu: stop using sratch_reg in IB testMonk Liu
scratch_reg0 is used by RLCG for register access usage in SRIOV case. both CP firmware and driver can invoke RLCG to do certain register access (through scratch_reg0/1/2/3) but rlcg now dosen't have race concern so if two clients are in parallel doing the RLCG reg access then we are colliding, GFX IB test is a runtime work, so it is forbidden to use scrach_reg0/1/2/3 during IB test period note: Although we can only have this change for SRIOV, but looks it doesn't worth the effort to differentiate bare-metal with SRIOV on the GFX ib test Signed-off-by: Monk Liu <Monk.Liu@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-05drm/amdgpu: fix IB test MCBP bugMonk Liu
1)for gfx IB test we shouldn't insert DE meta data 2)we should make sure IB test finished before we send event 3 to hypervisor otherwise the IDLE from event 3 will preempt IB test, which is not designed as a compatible structure for MCBP Signed-off-by: Monk Liu <Monk.Liu@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-05drm/amdgpu: disable 3D pipe 1 on Navi1xTianci.Yin
[why] CP firmware decide to skip setting the state for 3D pipe 1 for Navi1x as there is no use case. [how] Disable 3D pipe 1 on Navi1x. Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Reviewed-by: Monk Liu <monk.liu@amd.com> Signed-off-by: Tianci.Yin <tianci.yin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-05drm/amdgpu: Add debugfs interface to set arbitrary sclk for navi14 (v2)Chengming Gui
add debugfs interface amdgpu_force_sclk to set arbitrary sclk for navi14 v2: Add lock Signed-off-by: Chengming Gui <Jack.Gui@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-05drm/amdgpu: add lock option for smu_set_soft_freq_range()Chengming Gui
Add lock_needed param for smu_set_soft_freq_range() Signed-off-by: Chengming Gui <Jack.Gui@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-05drm/amd/display: dc_link: code clean up on detect_dp functionMelissa Wen
Removes codestyle issues on detect_dp function as suggested by checkpatch.pl. CHECK: Lines should not end with a '(' WARNING: Missing a blank line after declarations WARNING: line over 80 characters CHECK: Alignment should match open parenthesis Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Reviewed-by: Zhan Liu <zhan.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-05drm/amd/display: dc_link: code clean up on enable_link_dp functionMelissa Wen
Coding style clean up on enable_link_dp function as suggested by checkpatch.pl: CHECK: Lines should not end with a '(' WARNING: line over 80 characters WARNING: suspect code indent for conditional statements (8, 24) CHECK: braces {} should be used on all arms of this statement ERROR: else should follow close brace '}' CHECK: Comparison to NULL could be written "link->preferred_training_settings.fec_enable" Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-05drm/amd/display: Fix dmub_psr_destroy()Dan Carpenter
This is freeing the wrong variable so it will crash. It should be freeing "*dmub" instead of "dmub". Fixes: 4c1a1335dfe0 ("drm/amd/display: Driverside changes to support PSR in DMCUB") Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-05drm/amd/display: fix indentation issue on a hunk of codeColin Ian King
There are multiple statements that are indented incorrectly. Add in the missing tabs. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-05drm/amdkfd: fix indentation issueColin Ian King
There is a statement that is indented with spaces instead of a tab. Replace spaces with a tab. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-05drm/amdgpu: Write blocked CP registers using RLC on VFRohit Khaire
This change programs CP_ME_CNTL and RLC_CSIB_* through RLC Signed-off-by: Rohit Khaire <Rohit.Khaire@amd.com> Reviewed-by: Monk Liu <monk.liu@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-05drm/amdgpu: clean wptr on wb when gpu recoveryYintian Tao
The TDR will be randomly failed due to compute ring test failure. If the compute ring wptr & 0x7ff(ring_buf_mask) is 0x100 then after map mqd the compute ring rptr will be synced with 0x100. And the ring test packet size is also 0x100. Then after invocation of amdgpu_ring_commit, the cp will not really handle the packet on the ring buffer because rptr is equal to wptr. Signed-off-by: Yintian Tao <yttao@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Monk Liu <Monk.Liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-05Merge tag 'mediatek-drm-fixes-5.6' of ↵Dave Airlie
https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes Mediatek DRM Fixes for Linux 5.6 Signed-off-by: Dave Airlie <airlied@redhat.com> From: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.freedesktop.org/patch/msgid/1583373069.364.4.camel@mtksdaap41
2020-03-04drm/i915/gt: Cancel banned contexts after GT resetChris Wilson
As we started marking the ce->gem_context as NULL on closure, we can no longer use that to carry closure information. Instead, we can look at whether the context was killed on closure instead. Fixes: 130a95e9098e ("drm/i915/gem: Consolidate ctx->engines[] release") Closes: https://gitlab.freedesktop.org/drm/intel/issues/1379 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/20200304165113.2449213-1-chris@chris-wilson.co.uk
2020-03-04drm/i915: Add invert-brightness quirk for Thundersoft TST178 tabletHans de Goede
The Thundersoft TST178 tablet uses a DSI panel with an external PWM controller (as all DSI panels do). But unlike other DSI panels a duty-cycle of 100% turns the backlight off and 0% sets it to maximum brightness. I've checked the VBT and there is a BDB_LVDS_BACKLIGHT section, but it does not set the active_low_pwm flag. This tablet re-uses the main PCI vendor and product ids for the subsystem ids, so I see no other option then to add a DMI based quirk to fix this. Note that the PWM backlight code in intel_panel.c currently does not honor the vbt.active_low_pwm flag, but that does not matter in this case. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200221172927.510027-2-hdegoede@redhat.com
2020-03-04drm/i915: panel: Use intel_panel_compute_brightness() from pwm_setup_backlight()Hans de Goede
Use intel_panel_compute_brightness() from pwm_setup_backlight() so that we correctly take i915_modparams.invert_brightness and/or QUIRK_INVERT_BRIGHTNESS into account when setting + getting the initial brightness value. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200221172927.510027-1-hdegoede@redhat.com
2020-03-04drm/i915/gt: Propagate change in error status to children on unholdChris Wilson
As we release the head requests back into the queue, propagate any change in error status that may have occurred while the requests were temporarily suspended. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1277 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/20200304121849.2448028-2-chris@chris-wilson.co.uk
2020-03-04drm/i915: Apply i915_request_skip() on submissionChris Wilson
Trying to use i915_request_skip() prior to i915_request_add() causes us to try and fill the ring upto request->postfix, which has not yet been set, and so may cause us to memset() past the end of the ring. Instead of skipping the request immediately, just flag the error on the request (only accepting the first fatal error we see) and then clear the request upon submission. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200304121849.2448028-1-chris@chris-wilson.co.uk
2020-03-04drm/i915/ehl: Check PHY type before reading DPLL frequencyMatt Roper
intel_ddi_clock_get() tests the DPLL ID against DPLL_ID_ICL_TBTPLL (2) to determine whether to try to descend into a TBT-specific handler. However this test will also be true when DPLL4 on EHL is used since that shares the same DPLL ID (2). Add an extra check to ensure the PHY is actually a Type-C PHY before descending into the TBT handling. This should ensure EHL still takes the correct code path and somewhat future-proof the code as well. v2: Drop the gen+ check since only gen11+ platforms can have Type-C outputs. (Imre) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Imre Deak <imre.deak@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/issues/1369 Fixes: 45e4728b87ad ("drm/i915: Move DPLL frequency calculation to intel_dpll_mgr.c") Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303195043.959913-1-matthew.d.roper@intel.com
2020-03-04drm: kirin: Revert "Fix for hikey620 display offset problem"John Stultz
This reverts commit ff57c6513820efe945b61863cf4a51b79f18b592. With the commit ff57c6513820 ("drm: kirin: Fix for hikey620 display offset problem") we added support for handling LDI overflows by resetting the hardware. However, its been observed that when we do hit the LDI overflow condition, the irq seems to be screaming, and we do nothing but stream: [drm:ade_irq_handler [kirin_drm]] *ERROR* LDI underflow! over and over to the screen I've tried a few appraoches to avoid this, but none has yet been successful and the cure here is worse then the original disease, so revert this for now. Cc: Xinliang Liu <xinliang.liu@linaro.org> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> Cc: Chen Feng <puck.chen@hisilicon.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel <dri-devel@lists.freedesktop.org> Fixes: ff57c6513820 ("drm: kirin: Fix for hikey620 display offset problem") Signed-off-by: John Stultz <john.stultz@linaro.org> Acked-by: Xinliang Liu <xinliang.liu@linaro.org> Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200303163228.52741-1-john.stultz@linaro.org
2020-03-04drm/i915/gt: Drop the timeline->mutex as we wait for retirementChris Wilson
As we have pinned the timeline (using tl->active_count), we can safely drop the tl->mutex as we wait for what we believe to be the final request on that timeline. This is useful for ensuring that we do not block the engine heartbeat by hogging the kernel_context's timeline on a dead GPU. References: https://gitlab.freedesktop.org/drm/intel/issues/1364 Fixes: 058179e72e09 ("drm/i915/gt: Replace hangcheck by heartbeats") Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with retire_request") 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/20200303140009.1494819-1-chris@chris-wilson.co.uk (cherry picked from commit 82126e596d8519baac416aee83cad938f1d23cf8) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-03-04drm/i915/perf: Reintroduce wait on OA configuration completionChris Wilson
We still need to wait for the initial OA configuration to happen before we enable OA report writes to the OA buffer. Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 15d0ace1f876 ("drm/i915/perf: execute OA configuration from command stream") Closes: https://gitlab.freedesktop.org/drm/intel/issues/1356 Testcase: igt/perf/stream-open-close Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302085812.4172450-7-chris@chris-wilson.co.uk (cherry picked from commit 4b4e973d5eb89244b67d3223b60f752d0479f253) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-03-04drm/i915/gvt: Inlcude intel_gvt.h where neededChris Wilson
drivers/gpu/drm/i915/gvt/gvt.c:264:6: error: no previous prototype for ‘intel_gvt_clean_device’ [-Werror=missing-prototypes] drivers/gpu/drm/i915/gvt/gvt.c:301:5: error: no previous prototype for ‘intel_gvt_init_device’ [-Werror=missing-prototypes] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200304002331.2126072-1-chris@chris-wilson.co.uk
2020-03-04Merge drm/drm-next into drm-misc-nextMaxime Ripard
Daniel needs a few commits from drm-next. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2020-03-03drm/i915: Force DPCD backlight mode for some Dell CML 2020 panelsLyude Paul
According to Dell, trying to match their panels via OUI is not reliable enough and we've been told that we should check against the EDID instead. As well, Dell seems to have some panels that are actually intended to switch between using PWM for backlight controls and DPCD for backlight controls depending on whether or not the panel is in HDR or SDR mode. Yikes. Regardless, we need to add quirks for these so that DPCD backlight controls get enabled by default, since without additional driver support that's the only form of brightness control that will work. Hopefully in the future we can remove these quirks once we have a better way of probing for this. Changes since v1: * Add one more EDID per Dell's request * Remove model number (which is possibly wrong) and replace with Dell CML 2020 systems Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211183358.157448-4-lyude@redhat.com Reviewed-by: Adam Jackson <ajax@redhat.com>
2020-03-03drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED panelLyude Paul
The X1 Extreme is one of the systems that lies about which backlight interface that it uses in its VBIOS as PWM backlight controls don't work at all on this machine. It's possible that this panel could be one of the infamous ones that can switch between PWM mode and DPCD backlight control mode, but we haven't gotten any more details on this from Lenovo just yet. For the time being though, making sure the backlight 'just works' is a bit more important. So, add a quirk to force DPCD backlight controls on for these systems based on EDID (since this panel doesn't appear to fill in the device ID). Hopefully in the future we'll figure out a better way of probing this. Changes since v2: * The bugzilla URL is deprecated, bug reporting happens on gitlab now. Update the messages we print to reflect this * Also, take the opportunity to move FDO_BUG_URL out of i915_utils.c and into i915_utils.h so that other places which print things that aren't traditional errors but are worth filing bugs about, can actually use it. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303215320.93491-1-lyude@redhat.com
2020-03-03drm/dp: Introduce EDID-based quirksLyude Paul
The whole point of using OUIs is so that we can recognize certain devices and potentially apply quirks for them. Normally this should work quite well, but there appears to be quite a number of laptop panels out there that will fill the OUI but not the device ID. As such, for devices like this I can't imagine it's a very good idea to try relying on OUIs for applying quirks. As well, some laptop vendors have confirmed to us that their panels have this exact issue. So, let's introduce the ability to apply DP quirks based on EDID identification. We reuse the same quirk bits for OUI-based quirks, so that callers can simply check all possible quirks using drm_dp_has_quirk(). Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211183358.157448-2-lyude@redhat.com
2020-03-04drm/i915/hdcp: Fix config_stream_type() ret valueAnshuman Gupta
DP shim's config_stream_type considered to be succeeded when return value of intel_dp_hdcp2_write_msg() equals to size of message to be written, it makes config_stream_type to return a zero success value in order to succeed the HDCP auth. v2: - config_stream_type() returns 0 on success. [Ram] CC: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303073838.25871-1-anshuman.gupta@intel.com
2020-03-04drm/i915/hdcp: Mandate (seq_num_V==0) at first RecvId msgAnshuman Gupta
HDCP Repeater initializes seq_num_V to 0 at the beginning of hdcp Session i.e. after AKE_init received, refer HDCP 2.2 Spec HDMI PAGE 19, DP PAGE 20. HDCP 2.2 Comp specs 1B-06 test verifies that whether DUT considers failure of authentication if the repeater provides a non-zero value in seq_num_V in the first, RepeaterAuth_Send_ReceiverID_List message. Make sure that HDCP repeater initializes seq_num_V to zero at beginning of session i.e. after AKE_Init, fail the Auth if there is non zero seq_num_V. v2: - Used existing hdcp2_encrypted flag instead of declaring new flag. [Ram] Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200220123217.23635-2-anshuman.gupta@intel.com
2020-03-04drm/hdcp: optimizing the srm handlingRamalingam C
As we are not using the sysfs infrastructure anymore, link to it is removed. And global srm data and mutex to protect it are removed, with required handling at revocation check function. v2: srm_data is dropped and few more comments are addressed. v3: ptr passing around is fixed with functional testing. v4: fix htmldoc [lkp] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Suggested-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200212102942.26568-2-ramalingam.c@intel.com
2020-03-03gpu/trace: add a gpu total memory usage tracepointYiwei Zhang
This change adds the below gpu memory tracepoint: gpu_mem/gpu_mem_total: track global or proc gpu memory total usages Per process tracking of total gpu memory usage in the gem layer is not appropriate and hard to implement with trivial overhead. So for the gfx device driver layer to track total gpu memory usage both globally and per process in an easy and uniform way is to integrate the tracepoint in this patch to the underlying varied implementations of gpu memory tracking system from vendors. Putting this tracepoint in the common trace events can not only help wean the gfx drivers off of debugfs but also greatly help the downstream Android gpu vendors because debugfs is to be deprecated in the upcoming Android release. Then the gpu memory tracking of both Android kernel and the upstream linux kernel can stay closely, which can benefit the whole kernel eco-system in the long term. Link: http://lkml.kernel.org/r/20200302235044.59163-1-zzyiwei@google.com Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Yiwei Zhang <zzyiwei@google.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2020-03-03drm/i915/gem: Only call eb_lookup_vma once during execbuf ioctlChris Wilson
As we no longer stash anything inside i915_vma under the exclusive protection of struct_mutex, we do not need to revoke the i915_vma stashes before dropping struct_mutex to handle pagefaults. Knowing that we must drop the struct_mutex while keeping the eb->vma around, means that we are required to hold onto to the object reference until we have marked the vma as active. Fixes: 155ab8836caa ("drm/i915: Move object close under its own lock") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303204345.1859734-3-chris@chris-wilson.co.uk
2020-03-03drm/i915/gem: Extract transient execbuf flags from i915_vmaChris Wilson
For our convenience, and to avoid frequent allocations, we placed some lists we use for execbuf inside the common i915_vma struct. As we look to parallelise execbuf, such fields guarded by the struct_mutex BKL must be pulled under local control. Instead of using the i915_vma as our primary means of tracking the user's list of objects and their virtual mappings, we use a local eb_vma with the same lists as before (just now local not global). This should allow us to only perform the lookup of vma used for execution once during the execbuf ioctl, as currently we need to remove our secrets from inside i915_vma everytime we drop the struct_mutex as another execbuf may use the shared locations. Once potential user visible consequence is that we can remove the requirement that the execobj[] be unique, and only require that they do not conflict (i.e. you cannot softpin the same object into two locations. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303204345.1859734-2-chris@chris-wilson.co.uk
2020-03-03drm/i915: Drop inspection of execbuf flags during evictChris Wilson
With the goal of removing the serialisation from around execbuf, we will no longer have the privilege of there being a single execbuf in flight at any time and so will only be able to inspect the user's flags within the carefully controlled execbuf context. i915_gem_evict_for_node() is the only user outside of execbuf that currently peeks at the flag to convert an overlapping softpinned request from ENOSPC to EINVAL. Retract this nicety and only report ENOSPC if the location is in current use, either due to this execbuf or another. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303204345.1859734-1-chris@chris-wilson.co.uk
2020-03-03drm/sun4i: Fix DE2 VI layer format supportJernej Skrabec
DE2 VI layer doesn't support blending which means alpha channel is ignored. Replace all formats with alpha with "don't care" (X) channel. Fixes: 7480ba4d7571 ("drm/sun4i: Add support for DE2 VI planes") Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200224173901.174016-4-jernej.skrabec@siol.net
2020-03-03drm/sun4i: Add separate DE3 VI layer formatsJernej Skrabec
DE3 VI layers support alpha blending, but DE2 VI layers do not. Additionally, DE3 VI layers support 10-bit RGB and YUV formats. Make a separate list for DE3. Fixes: c50519e6db4d ("drm/sun4i: Add basic support for DE3") Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200224173901.174016-3-jernej.skrabec@siol.net
2020-03-03drm/sun4i: de2/de3: Remove unsupported VI layer formatsJernej Skrabec
YUV444 and YVU444 are planar formats, but HW format RGB888 is packed. This means that those two mappings were never correct. Remove them. Fixes: 60a3dcf96aa8 ("drm/sun4i: Add DE2 definitions for YUV formats") Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200224173901.174016-2-jernej.skrabec@siol.net
2020-03-03drm/i915/tgl: Move and restrict Wa_1408615072José Roberto de Souza
Following the changes in the previous patch "drm/i915/gen11: Moving WAs to rcs_engine_wa_init()" also moving TGL Wa_1408615072 to rcs_engine_wa_init() this way after a engine reset it will be reapplied also restricting it to A0 as it is fixed in B0 stepping. BSpec: 52890 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302231421.224322-2-jose.souza@intel.com
2020-03-03drm/i915/gen11: Moving WAs to rcs_engine_wa_init()José Roberto de Souza
This are register of render engine, so after a render reset those would return to the default value and init_clock_gating() is not called for single engine reset. So here moving it rcs_engine_wa_init() that will guarantee that this WAs will not be lost. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302231421.224322-1-jose.souza@intel.com
2020-03-03drm/i915/selftests: Fix uninitialized variableAditya Swarup
Static code analysis tool identified struct lrc_timestamp data as being uninitialized and then data.ce[] is being checked for NULL/negative value in the error path. Initializing data variable fixes the issue. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Aditya Swarup <aditya.swarup@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/20200303142347.15696-1-aditya.swarup@intel.com
2020-03-03drm/i915/gt: Drop the timeline->mutex as we wait for retirementChris Wilson
As we have pinned the timeline (using tl->active_count), we can safely drop the tl->mutex as we wait for what we believe to be the final request on that timeline. This is useful for ensuring that we do not block the engine heartbeat by hogging the kernel_context's timeline on a dead GPU. References: https://gitlab.freedesktop.org/drm/intel/issues/1364 Fixes: 058179e72e09 ("drm/i915/gt: Replace hangcheck by heartbeats") Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with retire_request") 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/20200303140009.1494819-1-chris@chris-wilson.co.uk
2020-03-03drm/i915: Drop vma is-closed assertion on insertChris Wilson
The is-closed flag may be added after we have acquired the vma under the ctx->mutex, but will not take effect until after we release the vm->mutex. i.e. the flag may be set on the vma as attempt to bind it and that will cause the vma to be unbound later after we unpin it. 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/20200303093157.1153887-1-chris@chris-wilson.co.uk
2020-03-03drm/i915/gem: Check that the context wasn't closed during setupChris Wilson
As setup takes a long time, the user may close the context during the construction of the execbuf. In order to make sure we correctly track all outstanding work with non-persistent contexts, we need to serialise the submission with the context closure and mop up any leaks. 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/20200303080546.1140508-3-chris@chris-wilson.co.uk
2020-03-03drm/i915/gt: Prevent allocation on a banned contextChris Wilson
If a context is banned even before we submit our first request to it, report the failure before we attempt to allocate any resources for the context. 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/20200303080546.1140508-2-chris@chris-wilson.co.uk
2020-03-03drm/i915/gem: Consolidate ctx->engines[] releaseChris Wilson
Use the same engine_idle_release() routine for cleaning all old ctx->engine[] state, closing any potential races with concurrent execbuf submission. v2ish: Use the ce->pin_count to close the execbuf gap. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1241 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/20200303080546.1140508-1-chris@chris-wilson.co.uk
2020-03-03drm/i915: Polish CHV .load_luts() a bitVille Syrjälä
It irks me to use crtc_state_is_legacy_gamma() inside the guts of the CHV color management code. Let's get rid of it and instead just consult cgm_mode to figure out if we want to enable the pipe gamma or the CGM gamma. Also CHV display engine is based on i965/g4x so we should fall back to the i965 path when the CGM gamma is not used. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191107151725.10507-3-ville.syrjala@linux.intel.com Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
2020-03-03drm/i915/gvt: only include intel_gvt.h where neededJani Nikula
i915_drv.c is the only caller. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227144408.24345-3-jani.nikula@intel.com
2020-03-03drm/i915/gvt: make intel_gvt_active internal to intel_gvtJani Nikula
Nobody else uses it. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200227144408.24345-2-jani.nikula@intel.com
2020-03-03drm/i915/vgpu: improve vgpu abstractionsJani Nikula
Add intel_vgpu_register() abstraction, rename i915_detect_vgpu() to intel_vgpu_detect() to match other function naming, un-inline intel_vgpu_active(), intel_vgpu_has_full_ppgtt() and intel_vgpu_has_huge_gtt() to reduce header interdependencies. The i915_vgpu.[ch] filename and intel_vgpu_ prefix discrepancy remains. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227144408.24345-1-jani.nikula@intel.com
2020-03-03drm/i915: Fix kbuild test robot build errorAnshuman Gupta
has_transcoder() was unused because function which was using it, intel_display_capture_error_state() defined under CONFIG_DRM_I915_CAPTURE_ERROR. Moving has_transcoder() to under CONFIG_DRM_I915_CAPTURE_ERROR. No functional change. Fixes: d54c1a513c48 ("drm/i915: Fix broken transcoder err state") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reported-by: kbuild test robot <lkp@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227175147.11362-1-anshuman.gupta@intel.com
generated by cgit (git 2.34.1) at 2025-09-12 18:28:19 +0000