aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2019-03-28drm/i915: Extract i9xx_color_check()Ville Syrjälä1-5/+28
Apart from CHV the other gmch platforms don't currently require much work in .color_check(). So let's start by extracting i9xx_color_check(). Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-03-28drm/i915: Turn intel_color_check() into a vfuncVille Syrjälä2-10/+21
The current intel_color_check() is a mess, and worse yet it is in fact incorrect for several platforms. The hardware has evolved quite a bit over the years, so let's just go for a clean split between the platforms by turning this into a vfunc. The actual work to split it up will follow. v2: Assign the vfuncs in the order they appear in the struct (Matt) Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-03-28drm/i915: Extract check_luts()Ville Syrjälä1-28/+40
In prepartion for per-platform color_check() functions extract the common code into a separate function. v2: Improve the C8 comment (Matt) Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-03-28Revert "drm/amdgpu: use HMM callback to replace mmu notifier"Alex Deucher4-72/+98
This reverts commit 57731a07795ae80790c6ae7d8e7001cdbd6d14c0. This depends on an HMM fix which is not upstream yet. Signed-off-by: Alex Deucher <[email protected]>
2019-03-28Revert "drm/amdkfd: avoid HMM change cause circular lock"Alex Deucher1-17/+15
This reverts commit 8dd69e69f42397c9b17764a951c44480b340858e. This depends on an HMM fix which is not upstream yet. Signed-off-by: Alex Deucher <[email protected]>
2019-03-28Revert "drm/amdgpu: replace get_user_pages with HMM mirror helpers"Alex Deucher9-182/+278
This reverts commit 915d3eecfa23693bac9e54cdacf84fb4efdcc5c4. This depends on an HMM fix which is not upstream yet. Signed-off-by: Alex Deucher <[email protected]>
2019-03-28Revert "drm/amdgpu: fix HMM config dependency issue"Alex Deucher3-19/+24
This reverts commit 6b8f7e3dee7883084932bbdfce471a2960c6db5d. This depends on an HMM fix which is not upstream yet. Signed-off-by: Alex Deucher <[email protected]>
2019-03-28Revert "drm/amdkfd: support concurrent userptr update for HMM"Alex Deucher1-19/+6
This reverts commit 386a68e78620c793ed1ba9bc5789b90c18be262a. This depends on an HMM fix which is not upstream yet. Signed-off-by: Alex Deucher <[email protected]>
2019-03-28Revert "drm/amdgpu: support userptr cross VMAs case with HMM"Alex Deucher1-91/+35
This reverts commit 5aeaccca30023c00d982dfa7bfd25b384523460a. This depends on an HMM fix which is not upstream yet. Signed-off-by: Alex Deucher <[email protected]>
2019-03-28Revert "drm/amdgpu: more descriptive message if HMM not enabled"Alex Deucher1-2/+0
This reverts commit 194f87ddffe26bbbd124c549a9bf12a96a7f2919. This depends on an HMM fix which is not upstream yet. Signed-off-by: Alex Deucher <[email protected]>
2019-03-28drm/i915/icl: Fix VEBOX mismatch BUG_ON()José Roberto de Souza1-1/+1
GT VEBOX DISABLE is only 4 bits wide but it was using a 8 bits wide mask, the remaning reserved bits is set to 0 causing 4 more nonexistent VEBOX engines being detected as enabled, triggering the BUG_ON() because of mismatch between vebox_mask and newly added VEBOX_MASK(). [ 64.081621] [drm:intel_device_info_init_mmio [i915]] vdbox enable: 0005, instances: 0005 [ 64.081763] [drm:intel_device_info_init_mmio [i915]] vebox enable: 00f1, instances: 0001 [ 64.081825] intel_device_info_init_mmio:925 GEM_BUG_ON(vebox_mask != ({ unsigned int first__ = (VECS0); unsigned int count__ = (2); ((&(dev_priv)->__info)->engine_mask & (((~0UL) - (1UL << (first__)) + 1) & (~0UL >> (64 - 1 - (first__ + count__ - 1))))) >> first__; })) [ 64.082047] ------------[ cut here ]------------ [ 64.082054] kernel BUG at drivers/gpu/drm/i915/intel_device_info.c:925! BSpec: 20680 Fixes: 26376a7e74d2 ("drm/i915/icl: Check for fused-off VDBOX and VEBOX instances") Cc: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Oscar Mateo <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 547fcf9b1c608cf5c43c156a8773a94c6a38dc44) Signed-off-by: Jani Nikula <[email protected]>
2019-03-28drm/i915: Update DRIVER_DATE to 20190328Joonas Lahtinen1-1/+1
Signed-off-by: Joonas Lahtinen <[email protected]>
2019-03-28drm/i915: Update DRIVER_DATE to 20190328Joonas Lahtinen1-1/+1
Signed-off-by: Joonas Lahtinen <[email protected]>
2019-03-28drm/i915: Update DRIVER_DATE to 20190328Joonas Lahtinen1-2/+2
Signed-off-by: Joonas Lahtinen <[email protected]>
2019-03-28drm/virtio: rework resource creation workflow.Gerd Hoffmann6-91/+83
This patch moves the virtio_gpu_cmd_create_resource() call (which notifies the host about the new resource created) into the virtio_gpu_object_create() function. That way we can call virtio_gpu_cmd_create_resource() before ttm_bo_init(), so the host already knows about the object when ttm initializes the object and calls our driver callbacks. Specifically the object is already created when the virtio_gpu_ttm_tt_bind() callback invokes virtio_gpu_object_attach(), so the extra virtio_gpu_object_attach() calls done after virtio_gpu_object_create() are not needed any more. The fence support for the create ioctl becomes a bit more tricky though. The code moved into virtio_gpu_object_create() too. We first submit the (fenced) virtio_gpu_cmd_create_resource() command, then initialize the ttm object, and finally attach just created object to the fence for the command in case it didn't finish yet. Signed-off-by: Gerd Hoffmann <[email protected]> Acked-by: Noralf Trønnes <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-03-28drm/virtio: params struct for virtio_gpu_cmd_create_resource_3d()Gerd Hoffmann3-19/+32
Add 3d resource parameters to virtio_gpu_object_params struct. With that in place we can use it for virtio_gpu_cmd_resource_create_3d() calls. Signed-off-by: Gerd Hoffmann <[email protected]> Acked-by: Noralf Trønnes <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-03-28drm/virtio: params struct for virtio_gpu_cmd_create_resource()Gerd Hoffmann4-15/+16
Add format, width and height fields to the virtio_gpu_object_params struct. With that in place we can use the parameter struct for virtio_gpu_cmd_create_resource() calls too. Signed-off-by: Gerd Hoffmann <[email protected]> Acked-by: Noralf Trønnes <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-03-28drm/virtio: use struct to pass params to virtio_gpu_object_create()Gerd Hoffmann4-34/+35
Create virtio_gpu_object_params, use that to pass object parameters to virtio_gpu_object_create. This is just the first step, followup patches will add more parameters to the struct. The plan is to use the struct for all object parameters. Drop unused "kernel" parameter for virtio_gpu_alloc_object(), it is unused and always false. Also drop "pinned" parameter. virtio-gpu doesn't shuffle around objects, so effecively they all are pinned anyway. Hardcode TTM_PL_FLAG_NO_EVICT so ttm knows. Doesn't change much for the moment as virtio-gpu supports TTM_PL_FLAG_TT only so there is no opportunity to move around objects. That'll probably change in the future though. Signed-off-by: Gerd Hoffmann <[email protected]> Acked-by: Noralf Trønnes <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-03-28drm/virtio: move virtio_gpu_object_{attach, detach} calls.Gerd Hoffmann1-68/+24
Drop the dummy ttm backend implementation, add a real one for TTM_PL_FLAG_TT objects. The bin/unbind callbacks will call virtio_gpu_object_{attach,detach}, to update the object state on the host side, instead of invoking those calls from the move_notify() callback. With that in place the move and move_notify callbacks are not needed any more, so drop them. Signed-off-by: Gerd Hoffmann <[email protected]> Acked-by: Noralf Trønnes <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-03-28drm/virtio: add virtio-gpu-features debugfs file.Gerd Hoffmann1-1/+26
This file prints which features the virtio-gpu device has. Also add "virtio-gpu-" prefix to the existing fence file, to make clear this is a driver-specific debugfs file. Signed-off-by: Gerd Hoffmann <[email protected]> Acked-by: Noralf Trønnes <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-03-28drm/virtio: remove set but not used variable 'vgdev'YueHaibing1-6/+0
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/virtio/virtgpu_ttm.c: In function 'virtio_gpu_init_mem_type': drivers/gpu/drm/virtio/virtgpu_ttm.c:117:28: warning: variable 'vgdev' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/virtio/virtgpu_ttm.c: In function 'virtio_gpu_bo_swap_notify': drivers/gpu/drm/virtio/virtgpu_ttm.c:300:28: warning: variable 'vgdev' set but not used [-Wunused-but-set-variable] It is never used since introduction in dc5698e80cf7 ("Add virtio gpu driver.") Signed-off-by: YueHaibing <[email protected]> Reviewed-by: Mukesh Ojha <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Gerd Hoffmann <[email protected]>
2019-03-28drm: rcar-du: lvds: Set LVEN and LVRES bits together on D3Laurent Pinchart1-2/+6
On the D3 SoC the LVDS PHY must be enabled in the same register write that enables the LVDS output. Skip writing the LVEN bit independently on that platform, it will be set by the write that sets LVRES. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]>
2019-03-28drm: rcar-du: lvds: Adjust operating frequency for D3 and E3Laurent Pinchart1-2/+7
The D3 and E3 SoCs have different pixel clock frequency limits for the LVDS encoder than the other SoCs in the Gen3 family. Adjust the mode fixup implementation accordingly. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]>
2019-03-28drm: rcar-du: Link CRTCs to the DU deviceKieran Bingham3-25/+27
The rcar_du_crtc functions have a heavy reliance on the rcar_du_group structure, in many cases just to access the DU device context. To better separate the groups out of the CRTC handling code, give the rcar_du_crtc its own pointer to the device and remove the indirection through the group pointers. Signed-off-by: Kieran Bingham <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]>
2019-03-28drm: rcar-du: lvds: Fix post-DLL divider calculationLaurent Pinchart1-1/+1
The PLL parameters are computed by looping over the range of acceptable M, N and E values, and selecting the combination that produces the output frequency closest to the target. The internal frequency constraints are taken into account by restricting the tested values for the PLL parameters, reducing the search space. The target frequency, however, is only taken into account when computing the post-PLL divider, which can result in a 0 value for the divider when the PLL output frequency being tested is lower than half of the target frequency. Subsequent loops will produce a better set of PLL parameters, but for some of the iterations this can result in a division by 0. Fix it by clamping the divider value. We could instead restrict the E values being tested in the inner loop, but that would require additional calculation that would likely be less efficient as the E parameter can only take three different values. Fixes: c25c01361199 ("drm: rcar-du: lvds: D3/E3 support") Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Kieran Bingham <[email protected]>
2019-03-28drm: rcar-du: Remove unused prototypesKieran Bingham1-2/+0
The CRTC suspend and resume functions have been replaced, but the prototypes were not removed. Remove the redundant definitions. Signed-off-by: Kieran Bingham <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]>
2019-03-28drm: rcar-du: crtc: Make local functions staticKieran Bingham1-4/+5
The rcar_du_crtc_mode_valid() and rcar_du_crtc_get_crc_sources() functions are accessed only through a function pointer table. Convert the function definitions to be static to the module. Signed-off-by: Kieran Bingham <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]>
2019-03-28drm: rcar-du: Support panels connected directly to the DPAD outputsLaurent Pinchart1-6/+48
The R-Car DU driver assumes that a bridge is always connected to the DU output. This is valid for the LVDS and HDMI outputs, but the DPAD outputs can be connected directly to a panel, in which case no bridge is available. To support this use case, detect whether the entities connected to the DU DPAD outputs are encoders or panels based on the number of ports of their DT node, and retrieve the corresponding type of DRM objects. For panels, additionally create panel bridge instances. Signed-off-by: Laurent Pinchart <[email protected]> Tested-by: Kevin Key <[email protected]> Reviewed-by: Kieran Bingham <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]>
2019-03-27drm/amd/powerplay: update current profile mode only when it's really appliedEvan Quan2-10/+12
No need to update current profile mode if the new profile mode does not take effect in fact. Signed-off-by: Evan Quan <[email protected]> Reviewed-by: Kent Russell <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amd/display: fix odm output gamma programmingDmytro Laktyushkin2-2/+3
Currently only top pipe gets output tf programmed. This change makes all odm head pipes get output tf programmed. Signed-off-by: Dmytro Laktyushkin <[email protected]> Reviewed-by: Nikola Cornij <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amd/display: Populate macro_tile_size field for dmlJoshua Aberback2-40/+50
Create a functions to return swizzle types for dml Signed-off-by: Joshua Aberback <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amd/display: use dc_is_virtual instead of ENUMEric Bernstein4-7/+7
Signed-off-by: Eric Bernstein <[email protected]> Reviewed-by: Dmytro Laktyushkin <[email protected]> Reviewed-by: Nevenko Stupar <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amd/display: 3.2.24Aric Cyr1-1/+1
Signed-off-by: Aric Cyr <[email protected]> Reviewed-by: Aric Cyr <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amd/display: Pass SDP spliting in parametersNikola Cornij6-6/+12
pass SDP splitting when setting stream attributes for future use Signed-off-by: Nikola Cornij <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amd/display: Create clock funcsEryk Brol2-0/+3
Create dccg_init and init_clocks for future use Signed-off-by: Eryk Brol <[email protected]> Reviewed-by: Jun Lei <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amd/display: Clean up old pplib interface functionsFatemeh Darbehani4-52/+0
[Why] set_display_requirement, dcn1_pplib_apply_display_requirements are no longer used and should be removed. Signed-off-by: Fatemeh Darbehani <[email protected]> Reviewed-by: Hersen Wu <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amd/display: Pass init_data into DCN resource creationHarry Wentland5-27/+19
[WHY] The resource constructor currently needs num_virtual_links from init_data but will need access to other items provided by DM. [HOW] Pass init_data into DCN create_resource_pool functions. Signed-off-by: Harry Wentland <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Acked-by: Hersen Wu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amd/display: Handle branch device with DFP count = 0 case.Hugo Hu3-8/+8
[Why] When you have a SST branch device the driver, Even no sink device connected, it also send HPD with a valid EDID. Driver will config it to DP sink. Therefore, there're two displays in display setting. DPCD 0x05, DFP_PRESENT = 1 (branch device), DFP_TYPE = 00 (Display Port) [How] Driver determine DPCD 0x05 DFP_PRESENT = 1(branch) as an active dongle And check DFP count. Signed-off-by: Hugo Hu <[email protected]> Reviewed-by: Hugo Hu <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amd/display: program default output gammahersen wu1-24/+29
program default output gamma if no user specific gamma parameters passed. Signed-off-by: hersen wu <[email protected]> Reviewed-by: Sun peng Li <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amd/display: add preferred pipe split logicJun Lei4-12/+49
[why] existing logic finds "first free pipe from 5 -> 0" to split this will cause certain sequences to require DC to move an MPCC from one tree to another, which is unsupported this leads to blackscreen to mitigate this problem, we will always try to acquire the "preferred" pipe, and each pipe has a unique preferred pipe this means we avoid most of the scenarios where pipe splitting leads to moving MPCC from one tree to another Signed-off-by: Jun Lei <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amdgpu: don't put the root PD into the relocated listChristian König1-10/+8
Instead of skipping the root PD while processing the relocated list just never put it on the list in the first place. This avoids walking the list all together when the root PD is the only entry and so also avoids trying to submit a zero sized IB to the SDMA. Signed-off-by: Christian König <[email protected]> Tested-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amdgpu: drop the ib from the VM update parametersChristian König2-16/+13
It is redundant with the job pointer. Signed-off-by: Christian König <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amdgpu: move VM table mapping into the backend as wellChristian König4-27/+37
Clean that up further and also fix another case where the BO wasn't kmapped for CPU based updates. Signed-off-by: Christian König <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amdgpu: XGMI pstate switch initial supportshaoyunl6-1/+56
Driver vote low to high pstate switch whenever there is an outstanding XGMI mapping request. Driver vote high to low pstate when all the outstanding XGMI mapping is terminated. Signed-off-by: shaoyunl <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amdgpu: use the new VM backend for clearsChristian König1-57/+32
And remove the existing code when it is unused. Signed-off-by: Christian König <[email protected]> Reviewed-by: Chunming Zhou <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amdgpu: defer cmd/fence/fw buffers destroy on hw_init failureEvan Quan1-19/+12
As the cleanup jobs performed in pre_fini may still need these buffers. NULL pointer dereference will be triggered without them. Signed-off-by: Evan Quan <[email protected]> Reviewed-by: Feifei Xu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amdgpu: add more debug friendly promptsEvan Quan1-10/+28
Large piece of codes share one error prompt. That is not friendly for debugging. Signed-off-by: Evan Quan <[email protected]> Reviewed-by: Feifei Xu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amdgpu: error out on mode1 reset failureEvan Quan1-2/+5
The error return value should be correctly reflected. Signed-off-by: Evan Quan <[email protected]> Reviewed-by: Feifei Xu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amdgpu: trivial typo fixEvan Quan1-2/+2
"error" was not correctly spelled. Signed-off-by: Evan Quan <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-03-27drm/amdgpu: remove per obj debugfs writexinhui pan1-41/+1
there is ras_control node which can do its job. Signed-off-by: xinhui pan <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>