aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2017-07-17drm/imx: parallel-display: Accept drm_of_find_panel_or_bridge failurePhilipp Zabel1-1/+1
The parallel panel driver should continue to work without having an endpoint linking to an panel in DT for backwards compatibility. With the recent switch to drm_of_find_panel_or_bridge, an absent panel results in a failure with -ENODEV error return code. To restore the old behaviour, ignore the -ENODEV return code. Reported-by: Nikita Yushchenko <[email protected]> Fixes: ebc944613567 ("drm: convert drivers to use drm_of_find_panel_or_bridge") Tested-by: Chris Healy <[email protected]> Cc: [email protected] Signed-off-by: Philipp Zabel <[email protected]>
2017-07-17drm/imx: fix typo in ipu_plane_formats[]Laurentiu Palcu1-1/+1
The BGRA8888 appears twice in the ipu_plane_formats[] list. The duplicate should be BGRX8888. The original commit is: commit 59d6b7189a96 ("drm/imx: ipuv3-plane: enable support for RGBX8888 and RGBA8888 pixel formats") Signed-off-by: Laurentiu Palcu <[email protected]> Fixes: 59d6b7189a96 ("drm/imx: ipuv3-plane: enable support for RGBX8888 and RGBA8888 pixel") Signed-off-by: Philipp Zabel <[email protected]>
2017-07-17drm/i915: Fix user ptr check size in eb_relocate_vma()Imre Deak1-1/+1
Fix the sizeof(ptr) vs. sizeof(*ptr) typo. Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array") Cc: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-07-17drm/i915: Fix error checking/locking in perf/lookup_context()Imre Deak1-27/+5
1acfc104cdf8 missed to convert this one caller to be lockless. The side effect of that was that the error check in lookup_context() became incorrect. Convert now this caller too. Fixes: 1acfc104cdf ("drm/i915: Enable rcu-only context lookups") Cc: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-07-17drm/imx: lock scanout transfers for consecutive burstsPhilipp Zabel1-3/+35
Because of its shallow queues and limited reordering ability, the i.MX6Q memory controller likes AXI bursts of consecutive addresses a lot. To optimize memory access performance, lock the IPU scanout channels for a number of burst accesses each, before switching to the next channel. The burst size and length of a locked burst chain are chosen not to overshoot the stride. Enabling the 8-burst channel lock on a single 1920x1080@60Hz RGBx scanout (474 MiB/s of 64-byte IPU memory read accesses) reduces the reported memory controller busy cycles from 46% to below 28% on an otherwise idle i.MX6Q. Tested-by: Lucas Stach <[email protected]> Signed-off-by: Philipp Zabel <[email protected]>
2017-07-17drm/imx: ipuv3-plane: use fb local variable instead of state->fbPhilipp Zabel1-8/+7
We already have a local variable assigned to state->fb, use it. Signed-off-by: Philipp Zabel <[email protected]>
2017-07-17drm/i915/gvt: Fix the vblank timer close issue after shutdown VMs in reversefred gao1-11/+11
Once the Windows guest is shutdown, the display pipe will be disabled and intel_gvt_check_vblank_emulation will be called to check if the vblank timer is turned off. Given the scenario of creating VM1 ,VM2, destoying VM2 in current code, VM1 has pipe enabled and continues to check VM2, the flag have_enabled_pipe is always false since all the VM2 pipes are disabled, so the vblank timer will be canceled and TDR happens in Windows VM1 guest due to the vsync timeout. In this patch the vblank timer will be never canceled once one pipe is enabled. v2: - remove have_enabled_pipe flag and check pipe enabled directly. (Zhenyu) Cc: Wang Hongbo <[email protected]> Signed-off-by: fred gao <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]>
2017-07-17drm/i915: Update DRIVER_DATE to 20170717Daniel Vetter1-2/+2
Signed-off-by: Daniel Vetter <[email protected]>
2017-07-17drm/sun4i: Implement drm_driver lastclose to restore fbdev consoleJonathan Liu1-0/+8
The drm_driver lastclose callback is called when the last userspace DRM client has closed. Call drm_fbdev_cma_restore_mode to restore the fbdev console otherwise the fbdev console will stop working. Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support") Cc: [email protected] Tested-by: Olliver Schinagl <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Jonathan Liu <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>
2017-07-17drm/sun4i: hdmi: Implement I2C adapter for A10s DDC busJonathan Liu4-90/+256
The documentation for drm_do_get_edid in drivers/gpu/drm/drm_edid.c states: "As in the general case the DDC bus is accessible by the kernel at the I2C level, drivers must make all reasonable efforts to expose it as an I2C adapter and use drm_get_edid() instead of abusing this function." Exposing the DDC bus as an I2C adapter is more beneficial as it can be used for purposes other than reading the EDID such as modifying the EDID or using the HDMI DDC pins as an I2C bus through the I2C dev interface from userspace (e.g. i2c-tools). Implement this for A10s. Signed-off-by: Jonathan Liu <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>
2017-07-17drm/sun4i: constify drm_plane_helper_funcsArvind Yadav1-1/+1
drm_plane_helper_funcs are not supposed to change at runtime. All functions working with drm_plane_helper_funcs provided by <drm/drm_plane_helper.h> work with const drm_plane_helper_funcs. So mark the non-const structs as const. File size before: text data bss dec hex filename 981 40 0 1021 3fd drivers/gpu/drm/sun4i/sun4i_layer.o File size After adding 'const': text data bss dec hex filename 1021 0 0 1021 3fd drivers/gpu/drm/sun4i/sun4i_layer.o Signed-off-by: Arvind Yadav <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>
2017-07-15Merge branch 'work.__copy_to_user' of ↵Linus Torvalds1-63/+46
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull more __copy_.._user elimination from Al Viro. * 'work.__copy_to_user' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: drm_dp_aux_dev: switch to read_iter/write_iter
2017-07-14drm/vc4: Fix misleading name of the continuous flag.Eric Anholt1-4/+4
The logic was all right in the end, the name was just backwards. Signed-off-by: Eric Anholt <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Andrzej Hajda <[email protected]>
2017-07-14drm/vc4: Fix DSI T_INIT timing.Eric Anholt1-1/+11
The DPHY spec requires a much larger T_INIT than I was specifying before. In the absence of clear specs from the slave of what their timing is, just use the value that the firmware was using. Signed-off-by: Eric Anholt <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Andrzej Hajda <[email protected]>
2017-07-14drm/vc4: Fix VBLANK handling in crtc->enable() pathBoris Brezillon1-23/+43
When we are enabling a CRTC, drm_crtc_vblank_get() is called before drm_crtc_vblank_on(), which is not supposed to happen (hence the WARN_ON() in the code). To solve the problem, we delay the 'update display list' operation after the CRTC is actually enabled. Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1498163126-26678-1-git-send-email-boris.brezillon@free-electrons.com Fixes: 34c8ea400ff6 ("drm/vc4: Mimic drm_atomic_helper_commit() behavior")
2017-07-14drm: add helper functions for YCBCR420 handlingShashank Sharma1-0/+58
This patch adds helper functions for YCBCR 420 handling. These functions do: - check if a given video mode is YCBCR 420 only mode. - check if a given video mode is YCBCR 420 also mode. V2: Added YCBCR functions as helpers in DRM layer, instead of keeping it in I915 layer. V3: Added handling for YCBCR-420 only modes too. V4: EXPORT_SYMBOL(drm_find_hdmi_output_type) V5: Addressed review comments from Danvet: - %s/drm_find_hdmi_output_type/drm_display_info_hdmi_output_type - %s/drm_can_support_ycbcr_output/drm_display_supports_ycbcr_output - %s/drm_can_support_this_ycbcr_output/ drm_display_supports_this_ycbcr_output - pass drm_display_info instead of drm_connector for consistency - For drm_get_highest_quality_ycbcr_supported doc, move the variable description above, and then the function description. V6: Add only YCBCR420 helpers (Ville) V7: Addressed review comments from Ville - Remove cea_vic_valid() check. - Fix indentation. - Make input parameters to helpers, const. Cc: Ville Syrjala <[email protected]> Cc: Jose Abreu <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] [vsyrjala: Fix sparse indentation warn] Signed-off-by: Ville Syrjälä <[email protected]>
2017-07-14drm/edid: parse ycbcr 420 deep color informationShashank Sharma1-0/+12
CEA-861-F spec adds ycbcr420 deep color support information in hf-vsdb block. This patch extends the existing hf-vsdb parsing function by adding parsing of ycbcr420 deep color support from the EDID and adding it into display information stored. V2: Rebase V3: Rebase V4: Moved definition of y420_dc_modes into this patch, where its used (Ville) V5: Optimize function, if(conditions) not reqd (Ville) V6: Rebase V7: Rebase Cc: Ville Syrjälä <[email protected]> Cc: Jose Abreu <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] [vsyrjala: Fix sparse indentation warn] Signed-off-by: Ville Syrjälä <[email protected]>
2017-07-14drm/edid: parse YCBCR420 videomodes from EDIDShashank Sharma1-2/+150
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output. CEA-861-F adds two new blocks in EDID's CEA extension blocks, to provide information about sink's YCBCR420 output capabilities. These blocks are: - YCBCR420vdb(YCBCR 420 video data block): This block contains VICs of video modes, which can be sopported only in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal SVD block, valid for YCBCR420 modes only. - YCBCR420cmdb(YCBCR 420 capability map data block): This block gives information about video modes which can support YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This block contains a bitmap index of normal svd videomodes, which can support YCBCR420 output too. So if bit 0 from first vcb byte is set, first video mode in the svd list can support YCBCR420 output too. Bit 1 means second video mode from svd list can support YCBCR420 output too, and so on. This patch adds two bitmaps in display's hdmi_info structure, one each for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch adds: - VDB modes (YCBCR 420 only modes) in connector's mode list, also makes an entry in the vdb_bitmap per vic. - VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap. Cc: Ville Syrjala <[email protected]> Cc: Jose Abreu <[email protected]> Cc: Emil Velikov <[email protected]> V2: Addressed Review comments from Emil: - Use 1ULL<<i instead of 1<<i to make sure the output is 64bit. - Use the suggested method for updating dbmap. - Add documentation for YCBCR420_vcb_map to fix kbuild warning. Review comments from Ville: - Do not expose the YCBCR420 flags in uabi layer, keep it internal. - Save a map of YCBCR420 modes for future reference. - Check db length before trying to parse extended tag. - Add a warning if there are > 64 modes in capability map block. - Use y420cmdb in function names and macros while dealing with vcb to be aligned with spec. - Move the display information parsing block ahead of mode parsing blocks. V3: Addressed design/review comments from Ville - Do not add flags in video modes, else we have to expose them to user - There should not be a UABI change, and kernel should detect the choice of the output based on type of mode, and the bitmaps. - Use standard bitops from kernel bitmap header, instead of calculating bit positions manually. V4: Addressed review comments from Ville: - s/ycbcr_420_vdb/y420vdb - s/ycbcr_420_vcb/y420cmdb - Be less verbose on description of do_y420vdb_modes - Move newmode variable in the loop scope. - Use svd_to_vic() to get a VIC, instead of 0x7f - Remove bitmap description for CMDB modes & VDB modes - Dont add connector->ycbcr_420_allowed check for cmdb modes - Remove 'len' variable, in is_y420cmdb function, which is used only once - Add length check in is_y420vdb function - Remove unnecessary if (!db) check in function parse_y420cmdb_bitmap - Do not add print about YCBCR 420 modes - Fix indentation in few places - Move ycbcr420_dc_modes in next patch, where its used - Add a separate patch for movement of drm_add_display_info() V5: Addressed review comments from Ville: - Add the patch which cleans up the current EXTENDED_TAG usage - Make y420_cmdb_map u64 - Do not block ycbcr420 modes while parsing the EDID, rather add a separate helper function to prune ycbcr420-only modes from connector's probed modes. V6: Rebase V7: Move this patch after the 420_only validation patch (Ville) V8: Addressed review comments from Ville - use cea_vic_valid check before adding cmdb/vdb modes - add check for i < 64 while adding cmdb modes - use 1ULL while checking bitmap Signed-off-by: Shashank Sharma <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] [vsyrjala: Fix checkpatch complaints and indentation] Signed-off-by: Ville Syrjälä <[email protected]>
2017-07-14drm: add helper to validate YCBCR420 modesShashank Sharma2-0/+33
YCBCR420 modes are supported only on HDMI 2.0 capable sources. This patch adds: - A drm helper to validate YCBCR420-only mode on a particular connector. This function will help pruning the YCBCR420-only modes from the connector's modelist. - A bool variable (ycbcr_420_allowed) in the drm connector structure. While handling the EDID from HDMI 2.0 sinks, its important to know if the source is capable of handling YCBCR420 output, so that no YCBCR 420 modes will be listed for sources which can't handle it. A driver should set this variable if it wants to see YCBCR420 modes in the modedb. V5: Introduced the patch in series. V6: Squashed two patches (validate YCBCR420 and add YCBCR420 identifier) V7: Addressed review comments from Vile: - Move this patch before we add 420 modes from EDID. - No need for drm_valid_cea_vic() check, function back to non-static. - Update MODE_STATUS with NO_420 condition. - Introduce y420_vdb_modes variable in this patch Cc: Ville Syrjala <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] [vsyrjala: Drop the now bogus EXPORT_SYMBOL(drm_valid_cea_vic)] Signed-off-by: Ville Syrjälä <[email protected]>
2017-07-14drm/edid: cleanup patch for CEA extended-tag macroShashank Sharma1-3/+12
CEA-861-F introduces extended tag codes for EDID extension blocks, which indicates the actual type of the data block. The code for using exteded tag is 0x7, whereas in the existing code, the corresponding macro is named as "VIDEO_CAPABILITY_BLOCK" This patch renames the macro and usages from "VIDEO_CAPABILITY_BLOCK" to "USE_EXTENDED_TAG" V2: Add extended tag code check for video capabilitiy block (ville) V3: Ville: - Use suggested names for macros - Check the block length first, before checking the extended tag V4: Fix commit message (David) V5: Introduced this patch into HDMI-YCBCR-output series V6: Rebase V7: Rebase Cc: Ville Syrjala <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]>
2017-07-14drm/edid: parse sink information before CEA blocksShashank Sharma1-2/+7
CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks. This block contains a map of indexes of CEA modes, which can support YCBCR 420 output also. To avoid multiple parsing of same CEA block, let's parse the sink information and get this map, before parsing CEA modes. This patch moves the call to drm_add_display_info function, before the mode parsing block. V4: Introduced new patch in the series V5: Move this patch before 4:2:0 parsing patch (ville) Added r-b from Ville V6: Rebase V7: Rebase Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]>
2017-07-14drm/edid: complete CEA modedb(VIC 1-107)Shashank Sharma1-1/+225
CEA-861-F specs defines new video modes to be used with HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to 1-107. Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now to be able to parse new CEA modes using the existing methods, we have to complete the modedb (VIC=65 onwards). This patch adds: - Timings for existing CEA video modes (from VIC=65 till VIC=92) - Newly added 4k modes (from VIC=93 to VIC=107). The patch was originaly discussed and reviewed here: https://patchwork.freedesktop.org/patch/135810/ Cc: Ville Syrjala <[email protected]> Cc: Jose Abreu <[email protected]> Cc: Andrzej Hajda <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Harry Wentland <[email protected]> V2: Rebase V3: Rebase V4: Added native bit handling as per CEA-861-F spec (Ville) V5: Fix timings for VIC 77:1920x1080 and 104:3840x2160p (Ville) Remove unnecessary paranthesis from function svd_to_vic (Ville) Added r-b (Neil) V6: Rebase V7: Fix indentation for modes from VIC 80 Reviewed-by: Jose Abreu <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Acked-by: Harry Wentland <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] [vsyrjala: Fix up remaining formatting/indentation issues] Signed-off-by: Ville Syrjälä <[email protected]>
2017-07-14drm: handle HDMI 2.0 VICs in AVI info-framesShashank Sharma24-24/+55
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in AVI infoframes should be 0. HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is extended to (VIC 1-107). This patch adds a bool input variable, which indicates if the connected sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a HDMI 2.0 VIC to a HDMI 1.4 sink. This patch touches all drm drivers, who are callers of this function drm_hdmi_avi_infoframe_from_display_mode but to make sure there is no change in current behavior, is_hdmi2 is kept as false. In case of I915 driver, this patch: - checks if the connected display is HDMI 2.0. - HDMI infoframes carry one of this two type of information: - VIC for 4K modes for HDMI 1.4 sinks - S3D information for S3D modes As CEA-861-F has already defined VICs for 4K videomodes, this patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks, until the mode is 3D. Cc: Ville Syrjala <[email protected]> Cc: Jose Abreu <[email protected]> Cc: Andrzej Hajda <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Daniel Vetter <[email protected]> PS: This patch touches a few lines in few files, which were already above 80 char, so checkpatch gives 80 char warning again. - gpu/drm/omapdrm/omap_encoder.c - gpu/drm/i915/intel_sdvo.c V2: Rebase, Added r-b from Andrzej V3: Addressed review comment from Ville: - Do not send VICs in both AVI-IF and HDMI-IF send only one of it. V4: Rebase V5: Added r-b from Neil. Addressed review comments from Ville - Do not block HDMI vendor IF, instead check for VIC while handling AVI infoframes V6: Rebase V7: Rebase Reviewed-by: Andrzej Hajda <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]>
2017-07-14drm/tinydrm: Add RePaper e-ink driverNoralf Trønnes3-0/+1108
This adds support for the Pervasive Displays RePaper branded displays. The controller code is taken from the userspace driver available through repaper.org. Only the V231 film is supported since the others are EOL. Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Noralf Trønnes <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-07-14drm/tinydrm: Add tinydrm_xrgb8888_to_gray8() helperNoralf Trønnes1-2/+72
Drm has no monochrome or greyscale support so add a conversion from the common format XR24. Also reorder includes into the common order. Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Noralf Trønnes <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-07-14drm/amd/powerplay: add profile mode for vega10.Rex Zhu2-25/+109
Signed-off-by: Rex Zhu <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: fix amdgpu_bo_gpu_accessible()Christian König1-1/+5
The test was relaxed a bit to much. Signed-off-by: Christian König <[email protected]> Acked-by: Tom St Denis <[email protected]> Reviewed-and-Tested-by: Roger He <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: map VM BOs for CPU based updates only onceChristian König1-36/+51
No need to try to map them every time. Signed-off-by: Christian König <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: make sure BOs are always kunmappedChristian König1-0/+3
When a BO is moved or destroyed it shouldn't be kmapped any more. Signed-off-by: Christian König <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: flush the HDP only once for CPU based VM updatesChristian König1-4/+12
No need to do this after every single update. Signed-off-by: Christian König <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: trace setting VM page tables with the CPU as wellChristian König1-0/+2
Handy for debugging. Signed-off-by: Christian König <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: remove VM shadow WARN_ONsAlex Deucher1-5/+1
Printing a warning into the logs that we will certainly run into a BUG() is completely nonsense, the BUG() is more than noisy enough. Signed-off-by: Christian König <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: fix amdgpu_vm_bo_waitChristian König1-8/+9
We need to wait with the correct owner on unmap operations or otherwise can run into VM faults. Also always wait for the page directory since this is where the reservation object comes from. So rename the function to amdgpu_vm_wait_pd instead as well. Signed-off-by: Christian König <[email protected]> Acked-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: fix VM flush for CPU based updatesChristian König1-3/+3
We don't have any update fence in that case, so the need for flushing isn't detected automatically. Signed-off-by: Christian König <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu/gfx: keep all compute queues on the same pipeAlex Deucher1-1/+2
Spreading them causes performance regressions using compute queues on Polaris 11. Cc: Jim Qu <[email protected]> Acked-by: Jim Qu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amd/amdgpu: fix si_enable_smc_cac() failed issueJim Qu1-0/+1
Signed-off-by: Jim Qu <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: Off by one sanity checksDan Carpenter3-3/+3
This is just future proofing code, not something that can be triggered in real life. We're testing to make sure we don't shift wrap when we do "1ull << i" so "i" has to be in the 0-63 range. If it's 64 then we have gone too far. Acked-by: Christian König <[email protected]> Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: implement si_read_bios_from_romAlex Deucher1-0/+28
This allows us to read the vbios image directly from ROM. This is already implemented for other asics, but was not yet available for SI. Acked-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu/soc15: drop dead functionAlex Deucher1-7/+0
Maybe a leftover from bringup? Reviewed-by: Chunming Zhou <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: call atomfirmware get_clock_info for atomfirmware systemsAlex Deucher1-1/+9
Rather than the legacy atombios version. Acked-by: Chunming Zhou <[email protected]> Acked-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: add get_clock_info for atomfirmwareAlex Deucher2-0/+94
The information has moved to different tables, notably smu_info for core refclk and umc_info for mem refclk. Acked-by: Chunming Zhou <[email protected]> Acked-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: Send no-retry XNACK for all fault typesJay Cornwall2-0/+6
A subset of VM fault types currently send retry XNACK to the client. This causes a storm of interrupts from the VM to the host. Until the storm is throttled by other means send no-retry XNACK for all fault types instead. No change in behavior to the client which will stall indefinitely with the current configuration in any case. Improves system stability under GC or MMHUB faults. Signed-off-by: Jay Cornwall <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Reviewed-by: John Bridgman <[email protected]> Acked-by: Alex Deucher <[email protected]> Acked-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: Correctly establish the suspend/resume hook for amdkfdYong Zhao2-8/+8
Signed-off-by: Yong Zhao <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: Make SDMA phase quantum configurableFelix Kuehling5-3/+100
Set a configurable SDMA phase quantum when enabling SDMA context switching. The default value significantly reduces SDMA latency in page table updates when user-mode SDMA queues have concurrent activity, compared to the initial HW setting. Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Andres Rodriguez <[email protected]> Reviewed-by: Shaoyun Liu <[email protected]> Acked-by: Chunming Zhou <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: Enable SDMA context switching for CIKFelix Kuehling1-0/+30
Enable SDMA context switching on CIK (copied from sdma_v3_0.c). Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Chunming Zhou <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: Enable SDMA_CNTL.ATC_L1_ENABLE for SDMA on CZshaoyunl1-2/+8
For GFX context, the ATC bit in SDMA*_GFX_VIRTUAL_ADDRESS can be cleared to perform in VM mode. For RLC context, to support ATC mode , ATC bit in SDMA*_RLC*_VIRTUAL_ADDRESS should be set. SDMA_CNTL.ATC_L1_ENABLE bit is global setting that enables the L1-L2 translation for ATC address. Signed-off-by: shaoyun liu <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: Try evicting from CPU visible to invisible VRAM firstMichel Dänzer1-0/+28
This gives BOs which haven't been accessed by the CPU since they were moved to visible VRAM another chance to stay in VRAM when another BO needs to go to visible VRAM. This should allow BOs to stay in VRAM longer in some cases. v2: * Only do this for BOs which don't have the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag set. Reviewed-by: Christian König <[email protected]> Signed-off-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: Don't force BOs into visible VRAM for page faultsJohn Brooks1-7/+10
There is no need for page faults to force BOs into visible VRAM if it's full, and the time it takes to do so is great enough to cause noticeable stuttering. Add GTT as a possible placement so that if visible VRAM is full, page faults move BOs to GTT instead of evicting other BOs from VRAM. Suggested-by: Michel Dänzer <[email protected]> Signed-off-by: John Brooks <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: Set/clear CPU_ACCESS flag on page fault and move to VRAMJohn Brooks2-10/+19
When a BO is moved to VRAM, clear AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED. This allows it to potentially later move to invisible VRAM if the CPU does not access it again. Setting the CPU_ACCESS flag in amdgpu_bo_fault_reserve_notify() also means that we can remove the loop to restrict lpfn to the end of visible VRAM, because amdgpu_ttm_placement_init() will do it for us. v3 [Michel Dänzer] * Use AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED instead of a new flag (Christian König) * Clear flag in amdgpu_bo_move instead of amdgpu_move_ram_vram (Christian) * Explicitly mention amdgpu_bo_fault_reserve_notify in amdgpu_bo_move * Also clear flag in amdgpu_bo_create_restricted Suggested-by: Michel Dänzer <[email protected]> Signed-off-by: John Brooks <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-07-14drm/amdgpu: Throttle visible VRAM moves separatelyJohn Brooks3-23/+87
The BO move throttling code is designed to allow VRAM to fill quickly if it is relatively empty. However, this does not take into account situations where the visible VRAM is smaller than total VRAM, and total VRAM may not be close to full but the visible VRAM segment is under pressure. In such situations, visible VRAM would experience unrestricted swapping and performance would drop. Add a separate counter specifically for moves involving visible VRAM, and check it before moving BOs there. v2: Only perform calculations for separate counter if visible VRAM is smaller than total VRAM. (Michel Dänzer) v3: [Michel Dänzer] * Use BO's location rather than the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag to determine whether to account a move for visible VRAM in most cases. * Use a single if (adev->mc.visible_vram_size < adev->mc.real_vram_size) { block in amdgpu_cs_get_threshold_for_moves. Fixes: 95844d20ae02 (drm/amdgpu: throttle buffer migrations at CS using a fixed MBps limit (v2)) Signed-off-by: John Brooks <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.