aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2020-02-06drm/amd/display: Add sysfs interface for set/get srmBhawanpreet Lakha2-3/+185
[Why] PSP doesn't have the ability to store SRM in a non-volatile memory. And since the kernel cannot write to the storage directly, we need usermode to facilitate this As per spec the SRM needs to be persistent so this interface is to be called by the usermode anytime the system goes down/powers on *boot/resume: load from storage *shutdown/suspend: save to storage [How] Provide a sysfs interface so that the usermode can set/get srm at the right times save to storage: call "cat /sys/class/drm/card0/device/hdcp_srm > file" after boot and resume -driver calls psp_get_srm() to get the stored srm and outputs it load from storage: call "cat file > /sys/class/drm/card0/device/hdcp_srm" before shutdown and suspend -driver reads the file from sysfs and calls psp_set_srm() to send the SRM to PSP v2: -update commit description -add comment about sysfs file handling in the code v3: - squash in use after free fix (Dan Carpenter) Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-02-06drm/edid: fix building errorMauro Rossi1-1/+1
Fixes the following building error: CC [M]  drivers/gpu/drm/drm_edid.o ~/pie-x86_kernel/kernel/drivers/gpu/drm/drm_edid.c: In function 'cea_mode_alternate_timings': ~/pie-x86_kernel/kernel/drivers/gpu/drm/drm_edid.c:3275:2: error: call to '__compiletime_assert_3282' declared with attribute error: BUILD_BUG_ON failed: cea_mode_for_vic(8)->vtotal != 262 || cea_mode_for_vic(9)->vtotal != 262 || cea_mode_for_vic(12)->vtotal != 262 || cea_mode_for_vic(13)->vtotal != 262 || cea_mode_for_vic(23)->vtotal != 312 || cea_mode_for_vic(24)->vtotal != 312 || cea_mode_for_vic(27)->vtotal != 312 || cea_mode_for_vic(28)->vtotal != 312 make[4]: *** [~/pie-x86_kernel/kernel/scripts/Makefile.build:265: drivers/gpu/drm/drm_edid.o] Error 1 Fixes: 7befe621ff81 ("drm/edid: Abstract away cea_edid_modes[]") Signed-off-by: Mauro Rossi <issor.oruam@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200203213113.28183-1-issor.oruam@gmail.com
2020-02-06drm/vgem: Close use-after-free race in vgem_gem_createDaniel Vetter1-3/+6
There's two references floating around here (for the object reference, not the handle_count reference, that's a different thing): - The temporary reference held by vgem_gem_create, acquired by creating the object and released by calling drm_gem_object_put_unlocked. - The reference held by the object handle, created by drm_gem_handle_create. This one generally outlives the function, except if a 2nd thread races with a GEM_CLOSE ioctl call. So usually everything is correct, except in that race case, where the access to gem_object->size could be looking at freed data already. Which again isn't a real problem (userspace shot its feet off already with the race, we could return garbage), but maybe someone can exploit this as an information leak. Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Hillf Danton <hdanton@sina.com> Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <seanpaul@chromium.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Eric Anholt <eric@anholt.net> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Rob Clark <robdclark@chromium.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200202132133.1891846-1-daniel.vetter@ffwll.ch
2020-02-06gpu: host1x: Set DMA direction only for DMA-mapped buffer objectsThierry Reding1-1/+1
The DMA direction is only used by the DMA API, so there is no use in setting it when a buffer object isn't mapped with the DMA API. Signed-off-by: Thierry Reding <treding@nvidia.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
2020-02-06drm/tegra: Reuse IOVA mapping where possibleThierry Reding3-23/+63
This partially reverts the DMA API support that was recently merged because it was causing performance regressions on older Tegra devices. Unfortunately, the cache maintenance performed by dma_map_sg() and dma_unmap_sg() causes performance to drop by a factor of 10. The right solution for this would be to cache mappings for buffers per consumer device, but that's a bit involved. Instead, we simply revert to the old behaviour of sharing IOVA mappings when we know that devices can do so (i.e. they share the same IOMMU domain). Cc: <stable@vger.kernel.org> # v5.5 Reported-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
2020-02-06drm/tegra: Relax IOMMU usage criteria on old TegraThierry Reding1-17/+32
Older Tegra devices only allow addressing 32 bits of memory, so whether or not the host1x is attached to an IOMMU doesn't matter. host1x IOMMU attachment is only needed on devices that can address memory beyond the 32-bit boundary and where the host1x doesn't support the wide GATHER opcode that allows it to access buffers at higher addresses. Cc: <stable@vger.kernel.org> # v5.5 Signed-off-by: Thierry Reding <treding@nvidia.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
2020-02-06drm/virtio: move virtqueue_notify into virtio_gpu_queue_ctrl_sgsChia-I Wu1-12/+10
It becomes clear that virtio_gpu_queue_fenced_ctrl_buffer should be responsible for setting up sgs and virtio_gpu_queue_ctrl_sgs should be responsible for queuing sgs. Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200205181955.202485-11-olvaffe@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-02-06drm/virtio: move the check for vqs_ready earlierChia-I Wu1-5/+8
When vqs_ready is false, vq should be considered invalid and we should not check vq->num_free. After this change, a fenced command queued before the vqs are ready will have fence id 0 and will be considered done. Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200205181955.202485-9-olvaffe@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-02-06drm/virtio: move locking into virtio_gpu_queue_ctrl_sgsChia-I Wu1-35/+35
Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200205181955.202485-8-olvaffe@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-02-06drm/virtio: set up virtqueue sgs before lockingChia-I Wu1-31/+35
sgs setup does not need to be in the critical section. Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200205181955.202485-7-olvaffe@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-02-06drm/virtio: unlock object array on errorsChia-I Wu1-1/+4
We don't propagate erros to the callers. We have to unlock object arrays on errors. Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200205181955.202485-6-olvaffe@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-02-06drm/virtio: no need to pass virtio_gpu_ctrl_hdrChia-I Wu1-12/+12
We can get it from vbuf. Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200205181955.202485-5-olvaffe@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-02-06drm/virtio: add virtio_gpu_vbuf_ctrl_hdrChia-I Wu1-5/+15
It is a helper to return the virtio_gpu_ctrl_hdr in a vbuf. Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200205181955.202485-4-olvaffe@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-02-06drm/virtio: remove incorrect ENOSPC checkChia-I Wu1-13/+6
The handling of virtqueue_add_sgs ENOSPC error is incorrect because it can result in out-of-order virtqueue_add_sgs and break fences. We never get ENOSPC anyway because the caller waits until there is enough space (the other caller that did not wait was removed in commit 32d6c2c5b522 ("drm/virtio: Rewrite virtio_gpu_queue_ctrl_buffer using fenced version.")). Remove the incorrect and unnecessary error path. This also adds a WARN_ON(ret) until we properly handle errors. Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Cc: David Riley <davidriley@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20200205181955.202485-3-olvaffe@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-02-06drm/virtio: fix a wait_event conditionChia-I Wu1-1/+2
outcnt may be greater than 1 since commit e1218b8c0cc1 ("drm/virtio: Use vmalloc for command buffer allocations."). Fixes: e1218b8c0cc1 ("drm/virtio: Use vmalloc for command buffer allocations.") Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Cc: David Riley <davidriley@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20200205181955.202485-2-olvaffe@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-02-06drm/virtio: ratelimit error loggingGerd Hoffmann1-3/+3
Avoid flooding the log in case we screw up badly. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200205102552.21409-1-kraxel@redhat.com
2020-02-06drm/vboxvideo: Implement struct drm_mode_config_funcs.mode_validThomas Zimmermann1-0/+1
The implementation of struct drm_mode_config_funcs.mode_valid verifies that enough video memory is available for a given display mode. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200203155258.9346-5-tzimmermann@suse.de
2020-02-06drm/hibmc: Implement struct drm_mode_config_funcs.mode_validThomas Zimmermann1-0/+1
The implementation of struct drm_mode_config_funcs.mode_valid verifies that enough video memory is available for a given display mode. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200203155258.9346-4-tzimmermann@suse.de
2020-02-06drm/bochs: Implement struct drm_mode_config_funcs.mode_validThomas Zimmermann1-20/+1
The implementation of struct drm_mode_config_funcs.mode_valid verifies that enough video memory is available for a given display mode. This replaces similar functionality in bochs_connector_mode_valid(). v2: * remove bochs_connector_mode_valid(), which now serves no purpose Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200203155258.9346-3-tzimmermann@suse.de
2020-02-06drm/vram: Add helpers to validate a display mode's memory requirementsThomas Zimmermann2-23/+62
Devices with low amount of dedicated video memory may not be able to use all possible display modes, as the framebuffers may not fit into VRAM. The new helper function drm_vram_helper_mode_valid() implements a simple test to sort out all display modes that can not be used in any case. Drivers should call this function from struct drm_mode_config_funcs.mode_valid. The functionality was originally implemented by the ast driver, which is being converted as well. v2: * WARN_ON if VRAM memory manager has not been initialized * documentation fixes * unexported drm_vram_helper_mode_valid_internal() Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200203155258.9346-2-tzimmermann@suse.de
2020-02-05drm/i915: Flush execution tasklets before checking request statusChris Wilson1-1/+2
Rather than flushing the submission tasklets just before we sleep, flush before we check the request status. Ideally this gives us a moment to process the tasklets after sleeping just before we timeout. v2: Compromise by pushing the flush prior to the timeout, but after the check on completion so that we do not further delay the ready client. 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/20200205095441.1769599-1-chris@chris-wilson.co.uk
2020-02-05drm/i915: Mark i915.reset as unsignedChris Wilson1-1/+1
We have been using '-1' to mean the maximum i915.reset level in the belief that it was unsigned... This turns out to have been a grave error, and instead of setting the default reset mechanism in igt, we have been disabling reset! 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/20200205123757.1834947-1-chris@chris-wilson.co.uk
2020-02-05drm/i915: Correctly map DBUF slices to pipesStanislav Lisovskiy1-19/+366
Added proper DBuf slice mapping to correspondent pipes, depending on pipe configuration as stated in BSpec. v2: - Remove unneeded braces - Stop using macro for DBuf assignments as it seems to reduce readability. v3: Start using enabled slices mask in dev_priv v4: Renamed "enabled_slices" used in dev_priv to "enabled_dbuf_slices_mask"(Matt Roper) v5: - Removed redundant parameters from intel_get_ddb_size function.(Matt Roper) - Made i915_possible_dbuf_slices static(Matt Roper) - Renamed total_width into total_width_in_range so that it now reflects that this is not a total pipe width but the one in current dbuf slice allowed range for pipe.(Matt Roper) - Removed 4th pipe for ICL in DBuf assignment table(Matt Roper) - Fixed wrong DBuf slice in DBuf table for TGL (Matt Roper) - Added comment regarding why we currently not using pipe ratio for DBuf assignment for ICL v6: - Changed u32 to unsigned int in icl_get_first_dbuf_slice_offset function signature (Ville Syrjälä) - Changed also u32 to u8 in dbuf slice mask structure (Ville Syrjälä) - Switched from DBUF_S1_BIT to enum + explicit BIT(DBUF_S1) access(Ville Syrjälä) - Switched to named initializers in DBuf assignment arrays(Ville Syrjälä) - DBuf assignment arrays now use autogeneration tool from https://patchwork.freedesktop.org/series/70493/ to avoid typos. - Renamed i915_find_pipe_conf to *_compute_dbuf_slices (Ville Syrjälä) - Changed platforms ordering in skl_compute_dbuf_slices to be from newest to oldest(Ville Syrjälä) v7: - Now ORing assigned DBuf slice config always with DBUF_S1 because slice 1 has to be constantly powered on. (Ville Syrjälä) v8: - Added pipe_name for neater printing(Ville Syrjälä) - Renamed width_before_pipe to width_before_pipe_in_range, to better reflect that now all the calculations are happening inside DBuf range allowed by current pipe configuration mask (Ville Syrjälä) - Shortened FIXME comment message, regarding constant ORing with DBUF_S1(Ville Syrjälä) - Added .dbuf_mask named initializer to pipe assignment array (Ville Syrjälä) - Edited pipe assignment array to use only single DBuf slice for gen11 single pipe configurations, until "pipe ratio" thing is finally sorted out(Ville Syrjälä) - Removed unused parameter crtc_state for now(Ville Syrjälä) from icl/tgl_compute_dbuf_slices function Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200202230630.8975-7-stanislav.lisovskiy@intel.com
2020-02-05drm/i915: Manipulate DBuf slices properlyStanislav Lisovskiy8-118/+72
Start manipulating DBuf slices as a mask, but not as a total number, as current approach doesn't give us full control on all combinations of slices, which we might need(like enabling S2 only can't enabled by setting enabled_slices=1). Removed wrong code from intel_get_ddb_size as it doesn't match to BSpec. For now still just use DBuf slice until proper algorithm is implemented. Other minor code refactoring to get prepared for major DBuf assignment changes landed: - As now enabled slices contain a mask we still need some value which should reflect how much DBuf slices are supported by the platform, now device info contains num_supported_dbuf_slices. - Removed unneeded assertion as we are now manipulating slices in a more proper way. v2: Start using enabled_slices in dev_priv v3: "enabled_slices" is now "enabled_dbuf_slices_mask", as this now sits in dev_priv independently. v4: - Fixed debug print formatting to hex(Matt Roper) - Optimized dbuf slice updates to be used only if slice union is different from current conf(Matt Roper) - Fixed some functions to be static(Matt Roper) - Created a parameterized version for DBUF_CTL to simplify DBuf programming cycle(Matt Roper) - Removed unrequred field from GEN10_FEATURES(Matt Roper) v5: - Removed redundant programming dbuf slices helper(Ville Syrjälä) - Started to use parameterized loop for hw readout to get slices (Ville Syrjälä) - Added back assertion checking amount of DBUF slices enabled after DC states 5/6 transition, also added new assertion as starting from ICL DMC seems to restore the last DBuf power state set, rather than power up all dbuf slices as assertion was previously expecting(Ville Syrjälä) v6: - Now using enum for DBuf slices in this patch (Ville Syrjälä) - Removed gen11_assert_dbuf_enabled and put gen9_assert_dbuf_enabled back, as we really need to have a single unified assert here however currently enabling always slice 1 is enforced by BSpec, so we will have to OR enabled slices mask with 1 in order to be consistent with BSpec, that way we can unify that assertion and against the actual state from the driver, but not some hardcoded value.(concluded with Ville) - Remove parameterized DBUF_CTL version, to extract it to another patch.(Ville Syrjälä) v7: - Removed unneeded hardcoded return value for older gens from intel_enabled_dbuf_slices_mask - this now is handled in a unified manner since device info anyway returns max dbuf slices as 1 for older platforms(Matthew Roper) - Now using INTEL_INFO(dev_priv)->num_supported_dbuf_slices instead of intel_dbuf_max_slices function as it is trivial(Matthew Roper) v8: - Fixed icl_dbuf_disable to disable all dbufs still(Ville Syrjälä) v9: - Renamed _DBUF_CTL_S to DBUF_CTL_S(Ville Syrjälä) - Now using power_domain mutex to protect from race condition, which can occur because intel_dbuf_slices_update might be running in parallel to gen9_dc_off_power_well_enable being called from intel_dp_detect for instance, which causes assertion triggered by race condition, as gen9_assert_dbuf_enabled might preempt this when registers were already updated, while dev_priv was not. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200202230630.8975-6-stanislav.lisovskiy@intel.com
2020-02-05drm/i915: Introduce parameterized DBUF_CTLStanislav Lisovskiy5-24/+31
Now start using parameterized DBUF_CTL instead of hardcoded, this would allow shorter access functions when reading or storing entire state. Tried to implement it in a MMIO_PIPE manner, however DBUF_CTL1 address is higher than DBUF_CTL2, which implies that we have to now subtract from base rather than add. v2: - Removed unneeded DBUF_CTL_DIST and DBUF_CTL_ADDR macros. Started to use _PICK construct as suggested by Matt Roper. v3: - _DBUF_CTL_S* to DBUF_CTL_S*, changed X to "slice" in macro(Ville Syrjälä) - Introduced enum for enumerating DBUF slices(Ville Syrjälä) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200202230630.8975-5-stanislav.lisovskiy@intel.com
2020-02-05drm/i915: Update dbuf slices only with full modesetStanislav Lisovskiy1-2/+4
During full modeset, global state(i.e dev_priv) is protected by locking the crtcs in state, otherwise global state is not serialized. Also if it is not a full modeset, we anyway don't need to change DBuf slice configuration as Pipe configuration doesn't change. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200202230630.8975-4-stanislav.lisovskiy@intel.com
2020-02-05drm/i915: Move dbuf slice update to proper placeStanislav Lisovskiy1-9/+28
Current DBuf slices update wasn't done in proper place, especially its "post" part, which should disable those only once vblank had passed and all other changes are committed. v2: Fix to use dev_priv and intel_atomic_state instead of skl_ddb_values (to be nuked in Villes patch) v3: Renamed "enabled_slices" to "enabled_dbuf_slices_num" (Matt Roper) v4: - Rebase against drm-tip. - Move post_update closer to optimize_watermarks, to prevent unneeded noise from underrun reporting (Ville Syrjälä) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200202230630.8975-3-stanislav.lisovskiy@intel.com
2020-02-05drm/i915: Remove skl_ddl_allocation structStanislav Lisovskiy6-51/+38
Current consensus that it is redundant as we already have skl_ddb_values struct out there, also this struct contains only single member which makes it unnecessary. v2: As dirty_pipes soon going to be nuked away from skl_ddb_values, evacuating enabled_slices to safer in dev_priv. v3: Changed "enabled_slices" to be "enabled_dbuf_slices_num" (Matt Roper) v4: - Wrapped the line getting number of dbuf slices(Matt Roper) - Removed indeed redundant skl_ddb_values declaration(Matt Roper) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200202230630.8975-2-stanislav.lisovskiy@intel.com
2020-02-05drm/virtio: fix vblank handlingGerd Hoffmann1-0/+1
virtio has its own commit fail function. Add the drm_atomic_helper_fake_vblank() call there. Fixes: 2a735ad3d211 ("drm/virtio: Remove sending of vblank event") Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: http://patchwork.freedesktop.org/patch/msgid/20200205065312.15790-1-kraxel@redhat.com
2020-02-05drm/i915/display: Be explicit in handling the preallocated vmaChris Wilson5-124/+101
As only the display codes tries to pin its preallocated framebuffer into an exact location in the GGTT, remove the convenience function and make the pin management explicit in the display code. Then throughout the display management, we track the framebuffer and its plane->vma; with less single purpose code and ready for first class i915_vma. In doing so, this should fix the BUG_ON(vma->pages) on fi-kbl-soraka. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200204094801.877288-2-chris@chris-wilson.co.uk
2020-02-05drm/i915/display: Explicitly cleanup initial_plane_configChris Wilson1-4/+17
I am about to stuff more objects into the plane_config and would like to have it clean up after itself. Move the current framebuffer release into a common function so it can be extended with the new object with relative ease. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200204094801.877288-1-chris@chris-wilson.co.uk
2020-02-05drm/i915/hdcp: move update pipe code to hdcpJani Nikula3-33/+46
The DDI encoder code shouln't have to know about the guts of HDCP. Abstract the pipe update code to a new intel_hdcp_update_pipe() in intel_hdcp.c. No functional changes. Cc: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128163803.5954-1-jani.nikula@intel.com
2020-02-04drm/amd/display: update psp interface headerBhawanpreet Lakha1-1/+25
[Why] We need to support SRM(System Renewability Message) As per hdcp spec (5.Renewability) SRM needs to be storage in a non-volatile memory. PSP owns the checking of SRM but doesn't have the ability to store it in a non-volatile memory. So we need the kernel driver to facilitate it using the interface provided by PSP [How] Add the interface to the header file, so the driver can use them v2: update commit description Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-02-04drm/amd/display: Pass amdgpu_device instead of psp_contextBhawanpreet Lakha3-4/+5
[Why] We need this to create sysfs (followup patch) [How] Change the parameter Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-02-04drm/amd/dm/mst: Ignore payload update failuresLyude Paul1-9/+4
Disabling a display on MST can potentially happen after the entire MST topology has been removed, which means that we can't communicate with the topology at all in this scenario. Likewise, this also means that we can't properly update payloads on the topology and as such, it's a good idea to ignore payload update failures when disabling displays. Currently, amdgpu makes the mistake of halting the payload update process when any payload update failures occur, resulting in leaving DC's local copies of the payload tables out of date. This ends up causing problems with hotplugging MST topologies, and causes modesets on the second hotplug to fail like so: [drm] Failed to updateMST allocation table forpipe idx:1 ------------[ cut here ]------------ WARNING: CPU: 5 PID: 1511 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2677 update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] Modules linked in: cdc_ether usbnet fuse xt_conntrack nf_conntrack nf_defrag_ipv6 libcrc32c nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 nft_counter nft_compat nf_tables nfnetlink tun bridge stp llc sunrpc vfat fat wmi_bmof uvcvideo snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi videobuf2_vmalloc snd_hda_intel videobuf2_memops videobuf2_v4l2 snd_intel_dspcfg videobuf2_common crct10dif_pclmul snd_hda_codec videodev crc32_pclmul snd_hwdep snd_hda_core ghash_clmulni_intel snd_seq mc joydev pcspkr snd_seq_device snd_pcm sp5100_tco k10temp i2c_piix4 snd_timer thinkpad_acpi ledtrig_audio snd wmi soundcore video i2c_scmi acpi_cpufreq ip_tables amdgpu(O) rtsx_pci_sdmmc amd_iommu_v2 gpu_sched mmc_core i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm crc32c_intel serio_raw hid_multitouch r8152 mii nvme r8169 nvme_core rtsx_pci pinctrl_amd CPU: 5 PID: 1511 Comm: gnome-shell Tainted: G O 5.5.0-rc7Lyude-Test+ #4 Hardware name: LENOVO FA495SIT26/FA495SIT26, BIOS R12ET22W(0.22 ) 01/31/2019 RIP: 0010:update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] Code: 28 00 00 00 75 2b 48 8d 65 e0 5b 41 5c 41 5d 41 5e 5d c3 0f b6 06 49 89 1c 24 41 88 44 24 08 0f b6 46 01 41 88 44 24 09 eb 93 <0f> 0b e9 2f ff ff ff e8 a6 82 a3 c2 66 0f 1f 44 00 00 0f 1f 44 00 RSP: 0018:ffffac428127f5b0 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff8d1e166eee80 RCX: 0000000000000000 RDX: ffffac428127f668 RSI: ffff8d1e166eee80 RDI: ffffac428127f610 RBP: ffffac428127f640 R08: ffffffffc03d94a8 R09: 0000000000000000 R10: ffff8d1e24b02000 R11: ffffac428127f5b0 R12: ffff8d1e1b83d000 R13: ffff8d1e1bea0b08 R14: 0000000000000002 R15: 0000000000000002 FS: 00007fab23ffcd80(0000) GS:ffff8d1e28b40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f151f1711e8 CR3: 00000005997c0000 CR4: 00000000003406e0 Call Trace: ? mutex_lock+0xe/0x30 dc_link_allocate_mst_payload+0x9a/0x210 [amdgpu] ? dm_read_reg_func+0x39/0xb0 [amdgpu] ? core_link_enable_stream+0x656/0x730 [amdgpu] core_link_enable_stream+0x656/0x730 [amdgpu] dce110_apply_ctx_to_hw+0x58e/0x5d0 [amdgpu] ? dcn10_verify_allow_pstate_change_high+0x1d/0x280 [amdgpu] ? dcn10_wait_for_mpcc_disconnect+0x3c/0x130 [amdgpu] dc_commit_state+0x292/0x770 [amdgpu] ? add_timer+0x101/0x1f0 ? ttm_bo_put+0x1a1/0x2f0 [ttm] amdgpu_dm_atomic_commit_tail+0xb59/0x1ff0 [amdgpu] ? amdgpu_move_blit.constprop.0+0xb8/0x1f0 [amdgpu] ? amdgpu_bo_move+0x16d/0x2b0 [amdgpu] ? ttm_bo_handle_move_mem+0x118/0x570 [ttm] ? ttm_bo_validate+0x134/0x150 [ttm] ? dm_plane_helper_prepare_fb+0x1b9/0x2a0 [amdgpu] ? _cond_resched+0x15/0x30 ? wait_for_completion_timeout+0x38/0x160 ? _cond_resched+0x15/0x30 ? wait_for_completion_interruptible+0x33/0x190 commit_tail+0x94/0x130 [drm_kms_helper] drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper] drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper] drm_mode_setcrtc+0x194/0x6a0 [drm] ? _cond_resched+0x15/0x30 ? mutex_lock+0xe/0x30 ? drm_mode_getcrtc+0x180/0x180 [drm] drm_ioctl_kernel+0xaa/0xf0 [drm] drm_ioctl+0x208/0x390 [drm] ? drm_mode_getcrtc+0x180/0x180 [drm] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] do_vfs_ioctl+0x458/0x6d0 ksys_ioctl+0x5e/0x90 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x55/0x1b0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fab2121f87b Code: 0f 1e fa 48 8b 05 0d 96 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 95 2c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffd045f9068 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffd045f90a0 RCX: 00007fab2121f87b RDX: 00007ffd045f90a0 RSI: 00000000c06864a2 RDI: 000000000000000b RBP: 00007ffd045f90a0 R08: 0000000000000000 R09: 000055dbd2985d10 R10: 000055dbd2196280 R11: 0000000000000246 R12: 00000000c06864a2 R13: 000000000000000b R14: 0000000000000000 R15: 000055dbd2196280 ---[ end trace 6ea888c24d2059cd ]--- Note as well, I have only been able to reproduce this on setups with 2 MST displays. Changes since v1: * Don't return false when part 1 or part 2 of updating the payloads fails, we don't want to abort at any step of the process even if things fail Reviewed-by: Mikita Lipski <Mikita.Lipski@amd.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-02-04drm/amdgpu: rework synchronization of VM updates v4Christian König7-61/+66
If provided we only sync to the BOs reservation object and no longer to the root PD. v2: update comment, cleanup amdgpu_bo_sync_wait_resv v3: use correct reservation object while clearing v4: fix typo in amdgpu_bo_sync_wait_resv Signed-off-by: Christian König <christian.koenig@amd.com> Tested-by: Tom St Denis <tom.stdenis@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-02-04drm/amdgpu: simplify and fix amdgpu_sync_resvChristian König1-4/+11
No matter what we always need to sync to moves. Signed-off-by: Christian König <christian.koenig@amd.com> Tested-by: Tom St Denis <tom.stdenis@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-02-04drm/amdgpu: allow higher level PD invalidationsChristian König1-5/+20
Allow partial invalidation on unallocated PDs. This is useful when we need to silence faults to stop interrupt floods on Vega. Signed-off-by: Christian König <christian.koenig@amd.com> Tested-by: Tom St Denis <tom.stdenis@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-02-04drm/amdgpu: return EINVAL instead of ENOENT in the VM codeChristian König1-1/+1
That we can't find a PD above the root is expected can only happen if we try to update a larger range than actually managed by the VM. Signed-off-by: Christian König <christian.koenig@amd.com> Tested-by: Tom St Denis <tom.stdenis@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-02-04drm/amdgpu: fix parentheses in amdgpu_vm_update_ptesChristian König1-1/+1
For the root PD mask can be 0xffffffff as well which would overrun to 0 if we don't cast it before we add one. Signed-off-by: Christian König <christian.koenig@amd.com> Tested-by: Tom St Denis <tom.stdenis@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-02-04drm/amdgpu: make sure to never allocate PDs/PTs for invalidationsChristian König1-9/+13
Make sure that we never allocate a page table for an invalidation operation. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-02-04drm/amdgpu: drop unnecessary restriction for huge root PDEsChristian König1-20/+5
The root PD can also contain huge PDEs. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-02-04drm/amdgpu: stop using amdgpu_bo_gpu_offset in the VM backendChristian König1-2/+2
We need to update page tables without any lock held. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-02-04drm/amdgpu: rework job synchronization v2Christian König8-34/+59
For unlocked page table updates we need to be able to sync to fences of a specific VM. v2: use SYNC_ALWAYS in the UVD code Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-02-04drm/amdgpu: use the VM as job ownerChristian König1-2/+3
For HMM we need to rework how VM synchronization works, so instead of the filp use VM as job owner. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-02-04drm/amdgpu: explicitly sync VM update to PDs/PTsChristian König2-0/+12
Explicitly sync VM updates to the moving fence in PDs and PTs. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-02-04drm/amdgpu: update default voltage for boot od table for navi1xAlex Deucher1-1/+8
It needed to be updated as well so it will show the proper values if you reset to the defaults. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-02-04drm: Remove the dma_alloc_coherent wrapper for internal usageChris Wilson3-30/+15
Internally for "consistent" maps, we create a temporary struct drm_dma_handle in order to use our own dma_alloc_coherent wrapper then destroy the temporary wrap. Simplify our logic by removing the temporary wrapper! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200202171635.4039044-2-chris@chris-wilson.co.uk
2020-02-04drm: Remove PageReserved manipulation from drm_pci_allocChris Wilson1-21/+2
drm_pci_alloc/drm_pci_free are very thin wrappers around the core dma facilities, and we have no special reason within the drm layer to behave differently. In particular, since commit de09d31dd38a50fdce106c15abd68432eebbd014 Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Date: Fri Jan 15 16:51:42 2016 -0800 page-flags: define PG_reserved behavior on compound pages As far as I can see there's no users of PG_reserved on compound pages. Let's use PF_NO_COMPOUND here. it has been illegal to combine GFP_COMP with SetPageReserved, so lets stop doing both and leave the dma layer to its own devices. Reported-by: Taketo Kabe Bug: https://gitlab.freedesktop.org/drm/intel/issues/1027 Fixes: de09d31dd38a ("page-flags: define PG_reserved behavior on compound pages") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: <stable@vger.kernel.org> # v4.5+ Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200202171635.4039044-1-chris@chris-wilson.co.uk
2020-02-04drm/i915/gt: Fix rc6 on IvybridgeChris Wilson1-4/+1
The current rc6 threshold is larger than the evaluation interval on Ivybridge; it never enters rc6. Remove the special casing so it behaves like the other gen6/gen7, and we see rc6 residencies before we manually park the system. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1114 Testcase: igt/i915_pm_rc6_residency/rc6-idle #ivb Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200203202110.670209-1-chris@chris-wilson.co.uk
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.