summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
2021-08-02drm/i915: Correct SFC_DONE register offsetMatt Roper
The register offset for SFC_DONE was missing a '0' at the end, causing us to read from a non-existent register address. We only use this register in error state dumps so the mistake hasn't caused any real problems, but fixing it will hopefully make the error state dumps a bit more useful for debugging. Fixes: e50dbdbfd9fb ("drm/i915/tgl: Add SFC instdone to error state") Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728233411.2365788-1-matthew.d.roper@intel.com Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
2021-08-02drm/vkms: Map output framebuffer BOs with drm_gem_fb_vmap()Thomas Zimmermann
Abstract the framebuffer details by mappings its BOs with a call to drm_gem_fb_vmap(). Unmap with drm_gem_fb_vunamp(). Before, the output address with stored as raw pointer in the priv field of struct drm_writeback_job. Introduce the new type struct vkms_writeback_job, which holds the output mappings addresses while the writeback job is active. The patchset also cleans up some internal casting an setup of the output addresses. No functional changes. v3: * free instances of struct vkms_writeback_job on cleanup or errors Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210730183511.20080-6-tzimmermann@suse.de
2021-08-02drm/gud: Map framebuffer BOs with drm_gem_fb_vmap()Thomas Zimmermann
Abstract the framebuffer details by mapping its BOs with a call to drm_gem_fb_vmap(). Unmap with drm_gem_fb_vunmap(). The call to drm_gem_fb_vmap() ensures that all BOs are mapped correctly. Gud still only supports single-plane formats. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210730183511.20080-5-tzimmermann@suse.de
2021-08-02drm/gem: Clear mapping addresses for unused framebuffer planesThomas Zimmermann
Set the returned mapping address to NULL if a framebuffer plane does not have a BO associated with it. Likewise, ignore mappings of NULL during framebuffer unmap operations. Allows users of the functions to perform unmap operations of certain BOs by themselfes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210730183511.20080-4-tzimmermann@suse.de
2021-08-02drm/gem: Provide drm_gem_fb_{vmap,vunmap}()Thomas Zimmermann
Move framebuffer vmap code from shadow-buffered plane state into the new interfaces drm_gem_fb_vmap() and drm_gem_fb_vunmap(). These functions provide mappings of a framebuffer's BOs into kernel address space. No functional changes. v4: * remove duplicated blank line v2: * using [static N] for array parameters enables compile-time checks * include <drm/drm_fourcc.h> for DRM_FORMAT_MAX_PLANES (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210730183511.20080-3-tzimmermann@suse.de
2021-08-02drm: Define DRM_FORMAT_MAX_PLANESThomas Zimmermann
DRM uses a magic number of 4 for the maximum number of planes per color format. Declare this constant via DRM_FORMAT_MAX_PLANES and update the related code. Some code depends on the length of arrays that are now declared with DRM_FORMAT_MAX_PLANES. Convert it from '4' to ARRAY_SIZE. v2: * mention usage of ARRAY_SIZE() in the commit message (Maxime) * also fix error handling in drm_gem_fb_init_with_funcs() (kernel test robot) * include <drm/drm_fourcc.h> for DRM_FORMAT_MAX_PLANES Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210730183511.20080-2-tzimmermann@suse.de
2021-08-02drm/i915/dg1: Adjust the AUDIO power domainAnshuman Gupta
DG1 and XE_PLD platforms has Audio MMIO/VERBS lies in PG0 power well. Adjusting the power domain accordingly to POWER_DOMAIN_AUDIO_MMIO for audio detection and POWER_DOMAIN_AUDIO_PLAYBACK for audio playback. While doing this it requires to use POWER_DOMAIN_AUDIO_MMIO power domain instead of POWER_DOMAIN_AUDIO in crtc power domain mask and POWER_DOMAIN_AUDIO_PLAYBACK with intel_display_power_{get, put} to enable/disable display audio codec power. It will save the power in use cases when DP/HDMI connectors configured with PIPE_A without any audio playback. v1: Changes since RFC - changed power domain names. [Imre] - Removed TC{3,6}, AUX_USBC{3,6} and TBT from DG1 power well and PW_3 power domains. [Imre] - Fixed the order of powe wells , power domains and its registration. [Imre] v2: - Not allowe DC states when AUDIO_MMIO domain enabled. [Imre] v3: - Squashes the commits of series to avoid build failure. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> [Fix typo in commit message and in AUDIO_PLAYBACK domain name] Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210729121858.16897-2-anshuman.gupta@intel.com
2021-08-02drm: Fix oops in damage self-tests by mocking damage propertyDaniel Vetter
I've added a new check to make sure that drivers which insepct the damage property have it set up correctly, but somehow missed that this borke the damage selftest in the CI result noise. Fix it up by mocking enough of drm_device and drm_plane so we can call drm_plane_enable_fb_damage_clips() to make the new check happy. Since there's a lot of duplicated mock code already copy-pasted into each test I've also refactored this a bit to trim it down. v2: Squash in fixup from 0day for drivers/gpu/drm/selftests/test-drm_damage_helper.c:15:19: warning: symbol 'mock_device' was not declared. Should it be static? drivers/gpu/drm/selftests/test-drm_damage_helper.c:16:30: warning: symbol 'mock_obj_props' was not declared. Should it be static? drivers/gpu/drm/selftests/test-drm_damage_helper.c:17:18: warning: symbol 'mock_plane' was not declared. Should it be static? drivers/gpu/drm/selftests/test-drm_damage_helper.c:18:21: warning: symbol 'mock_prop' was not declared. Should it be static? Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: kernel test robot <lkp@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Fixes: c7fcbf251397 ("drm/plane: check that fb_damage is set up when used") Cc: José Roberto de Souza <jose.souza@intel.com> (v1) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210730095251.4343-1-daniel.vetter@ffwll.ch Link: https://patchwork.freedesktop.org/patch/msgid/20210730141948.GA11955@243d74413310
2021-08-02drm: Fix typo in commentsCai Huoqing
fix typo for drm v1->v2: respin with the change "iff ==> implies that" Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210730132729.376-1-caihuoqing@baidu.com
2021-08-01DRM: ast: Fixed coding style issues of ast_mode.cGregory Williams
Removed space before comma, fixed if statements by putting trailing statements on new line, fixed unsigned int declaration, and removed not needed else statement after return. Signed-off-by: Gregory Williams <gregwills85@gmail.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210731005328.GA19016@devbox
2021-08-01drm/panel: Add support for E Ink VB3300-KCAAlistair Francis
Add support for the 10.3" E Ink panel described at: https://www.eink.com/product.html?type=productdetail&id=7 Signed-off-by: Alistair Francis <alistair@alistair23.me> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210801004701.831-1-alistair@alistair23.me
2021-07-31drm/pl111: Remove unused including <linux/version.h>Cai Huoqing
Remove including <linux/version.h> that don't need it. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210727052107.659-1-caihuoqing@baidu.com
2021-07-31drm/panel: atna33xc20: Introduce the Samsung ATNA33XC20 panelDouglas Anderson
The Samsung ATNA33XC20 panel is an AMOLED eDP panel that has backlight control over the DP AUX channel. This panel is _almost_ able to be controlled in a "simple" way (and it originally was implemented in panel-simple.c), but it's really impossible to get the backlight semantics right there without adding wacky special-case code to panel-simple. Let's give up and clone the parts of panel-simple that we need and implement the power sequence that this panel needs. NOTE: we'll still leave the devicetree bindings alone. Even though the power-sequencing is non-standard the bindings are still "simple". Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210730084534.v2.6.I3a2900080f8749d2bb4baf49ca902db4b0e1df7d@changeid
2021-07-31Revert "drm/panel-simple: Support for delays between GPIO & regulator"Douglas Anderson
This reverts commit 18a1488bf1e13fc3fc96d7948466b2166067c6c8. Those delays were added to support the Samsung ATNA33XC20 panel. However, we've moving that to its own panel driver and out of panel-simple. That means we don't need the ability to specify this delay. NOTE: it's unlikely we want to keep this delay "just in case" some other panel needs it. The enable-gpio and the power supply are really supposed to be different ways to specify the same thing: the main enable of the panel. Supporting a delay between them doesn't really make sense. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210730084534.v2.5.Ie44e3e5b7a926392541d575ca84c56931596513f@changeid
2021-07-31Revert "drm/panel-simple: Add Samsung ATNA33XC20"Douglas Anderson
This reverts commit 4bfe6c8f7c23b01719671b69fd29b87a35ccd9d6. This panel's power sequencing really can't be handled properly by panel-simple because of the special sequencing needed for the EL_ON3 GPIO. The only way it was sorta working in the past was by trying to jam that signal into the "enable-gpio", but that really wasn't a good fit. We'll add a custom panel driver for this panel to do it right. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210730084534.v2.4.Id9f076ec5f35633f8ce931051af268a04c45c075@changeid
2021-07-31drm/bridge: ti-sn65dsi86: Add some 100 us delaysDouglas Anderson
The manual has always said that we need 100 us delays in a few places. Though it hasn't seemed to be a big deal to skip these, let's add them in case it makes something happier. NOTE: this fixes no known issues but it seems good to make it right. Fixes: a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver") Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Robert Foss <robert.foss@linaro.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210730084534.v2.3.I842d483139531aa4651da8338512fdf0171ff23c@changeid
2021-07-31drm/bridge: ti-sn65dsi86: Fix power off sequenceDouglas Anderson
When testing with a panel that's apparently a little more persnickety about the correct power sequence (specifically Samsung ATNA33XC20), we found that the ti-sn65dsi86 was doing things just slightly wrong. Looking closely at the ti-sn65dsi86's datasheet, the power off sequence is supposed to be: 1. Clear VSTREAM_ENABLE bit 2. Stop DSI stream from GPU. DSI lanes must be placed in LP11 state. 3. Program the ML_TX_MODE to 0x0 (OFF) 4. Program the DP_NUM_LANES register to 0x0 5. Clear the DP_PLL_EN bit. 6. Deassert the EN pin. 7. Remove power from supply pins Since we were doing the whole sequence in the "disable", I believe that step #2 (stopping the DSI stream from the GPU) wasn't happening. We also weren't setting DP_NUM_LANES to 0. Let's fix this. NOTE: things are a little asymmetric now. For instance, we turn the PLL on in "enable" but now we're not turning it off until "post_disable". It would seem to make sense to move the PLL turning on to "pre_enable" to match. Unfortunately, I don't believe that's allowed. It looks as if (in the non-refclk mode which probably nobody is using) we have to wait until the MIPI clock is there before we can enable the PLL. In any case, the way it is here won't really hurt--it'll just leave the PLL on a little longer. Fixes: a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver") Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Robert Foss <robert.foss@linaro.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210730084534.v2.2.If8a8ec3bf1855cf0dbb62c005a71d6698c99c125@changeid
2021-07-31drm/dp: Don't zero PWMGEN_BIT_COUNT when driver_pwm_freq_hz not specifiedDouglas Anderson
The function drm_edp_backlight_init() is defined such that the "driver_pwm_freq_hz" parameter is optional--it's 0 if you don't want to futz with it. If you follow this variable through, you'll find out that if it's 0 we won't ever set the "bl->pwmgen_bit_count", leaving it as 0. That means that before using it in drm_edp_backlight_enable() we need to check to see if it's non-zero. Programming this field to zero was confusing the panel I tested with (Samsung ATNA33XC20). The backlight still worked somewhat but the brightness values didn't correspond to what they should have been. Fixes: 867cf9cd73c3 ("drm/dp: Extract i915's eDP backlight code into DRM helpers") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210730084534.v2.1.If017efce7116ae8ba015ed7def840c390a0e0c77@changeid
2021-07-31drm/msm/a6xx: Add support for Adreno 7c Gen 3 gpuAkhil P Oommen
This patch adds support for the gpu found in the Snapdragon 7c Gen 3 compute platform. This gpu is similar to the exisiting a660 gpu with minor delta in the programing sequence. As the Adreno GPUs are moving away from a numeric chipid based naming scheme to a string, it was decided to use 0x06030500 as the chip id of this gpu to communicate to the userspace driver. Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org> Link: https://lore.kernel.org/r/20210730011945.v4.3.I610377db0934b6b7deda532ec2bf786a02c38c01@changeid Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-07-31drm/msm/a6xx: Use rev to identify SKUAkhil P Oommen
Use rev instead of revn to identify the SKU. This is in preparation to the introduction of 7c3 gpu which won't have a revn. Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org> Link: https://lore.kernel.org/r/20210730011945.v4.2.I286ef007fcadd9e6ee3b2c0ad948f990735f9610@changeid Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-07-31drm/msm/a6xx: Fix llcc configuration for a660 gpuAkhil P Oommen
Add the missing scache_cntl0 register programing which is required for a660 gpu. Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org> Link: https://lore.kernel.org/r/20210730011945.v4.1.I110b87677ef16d97397fb7c81c07a16e1f5d211e@changeid Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-07-30drm/i915/xehp: Fix missing sentinel on mcr_ranges_xehpLucas De Marchi
There's a missing sentinel since we are not using ARRAY_SIZE(), but rather checking that the .start is 0 to stop the iteration in mcr_range(). BUG: KASAN: global-out-of-bounds in mcr_range.isra.0+0x69/0xa0 [i915] Read of size 4 at addr ffffffffa0889928 by task modprobe/3881 Fixes: d8905ba705ab ("drm/i915/xehp: Define multicast register ranges") Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210730191115.2514581-1-lucas.demarchi@intel.com
2021-07-30drm/i915: finish removal of CNLLucas De Marchi
With all the users removed, finish removing the CNL platform definitions. We will leave the PCI IDs around as those are exposed to userspace. Even if mesa doesn't support CNL anymore, let's avoid build breakages due to changing the headers. Also, due to drm/i915/gt still using IS_CANNONLAKE() let's just redefine it instead of removing. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-26-lucas.demarchi@intel.com
2021-07-30drm/i915: rename/remove CNL registersLucas De Marchi
Remove registers that are not used anymore due to CNL removal and rename those that are. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-25-lucas.demarchi@intel.com
2021-07-30drm/i915: remove GRAPHICS_VER == 10Lucas De Marchi
Replace all remaining handling of GRAPHICS_VER {==,>=} 10 with {==,>=} 11. With the removal of CNL, there is no platform with graphics version equals 10. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-24-lucas.demarchi@intel.com
2021-07-30drm/i915: switch num_scalers/num_sprites to consider DISPLAY_VERLucas De Marchi
The numbers of scalers and sprites depend on the display version, so use it instead of GRAPHICS_VER. We were mixing both, which let me confused while removing CNL and GRAPHICS_VER == 10. v2 (Rodrigo): Switch IS_GEMINILAKE to DISPLAY_VER == 10 v3 (Lucas): Change check to DISPLAY_VER >= 9, to cover the GLK's num_scalers, otherwise it remains set to 0. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-23-lucas.demarchi@intel.com
2021-07-30drm/i915: replace random CNL commentsLucas De Marchi
Cleanup remaining cases that we find CNL in the codebase. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-22-lucas.demarchi@intel.com
2021-07-30drm/i915: rename CNL references in intel_dram.cLucas De Marchi
With the removal of CNL, let's consider ICL as the first platform using those constants. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-21-lucas.demarchi@intel.com
2021-07-30drm/i915: remove explicit CNL handling from intel_wopcm.cLucas De Marchi
Consider the new WOPCM size as starting in ICL rather than CNL since the latter is being removed from the driver. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-20-lucas.demarchi@intel.com
2021-07-30drm/i915: remove explicit CNL handling from intel_pch.cLucas De Marchi
Remove references for CNL from pch detection. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-19-lucas.demarchi@intel.com
2021-07-30drm/i915: remove explicit CNL handling from intel_pm.cLucas De Marchi
Remove support for CNL as it's highly untested, probably broken, and there is no real platform that requires this code. This is part of CNL removal from i915. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-18-lucas.demarchi@intel.com
2021-07-30drm/i915: remove explicit CNL handling from i915_irq.cLucas De Marchi
Remove special handling of PORT_F in i915_irq.c and only do it for DISPLAY_VER == 11. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-17-lucas.demarchi@intel.com
2021-07-30drm/i915/display: rename CNL references in skl_scaler.cLucas De Marchi
With the removal of CNL, let's consider GLK as the first platform using those constants since GLK has DISPLAY_VER == 10. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-16-lucas.demarchi@intel.com
2021-07-30drm/i915/display: remove CNL ddi buf translation tablesLucas De Marchi
The only real platform with DISPLAY_VER == 10 is GLK. We don't need to handle CNL explicitly. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210729162332.1774275-1-lucas.demarchi@intel.com
2021-07-30drm/i915/display: remove explicit CNL handling from intel_display_power.cLucas De Marchi
The only real platform with DISPLAY_VER == 10 is GLK. We don't need to handle CNL explicitly in intel_display_power.c. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-14-lucas.demarchi@intel.com
2021-07-30drm/i915/display: remove explicit CNL handling from skl_universal_plane.cLucas De Marchi
The only real platform with DISPLAY_VER == 10 is GLK. We don't need to handle CNL explicitly in skl_universal_plane.c. Remove code and rename functions/macros accordingly to use ICL prefix. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-13-lucas.demarchi@intel.com
2021-07-30drm/i915/display: remove explicit CNL handling from intel_vdsc.cLucas De Marchi
Only one reference to CNL that is not needed, but code is the same for DISPLAY_VER >= 11, so leave the code around and just remove the special case for CNL. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-12-lucas.demarchi@intel.com
2021-07-30drm/i915/display: remove explicit CNL handling from intel_dpll_mgr.cLucas De Marchi
The only real platform with DISPLAY_VER == 10 is GLK. We don't need to handle CNL explicitly in intel_ddi.c. A lot of special code for CNL can be removed. There were some __cnl.*() functions that were created to share the implementation between ICL and CNL. Those are now embedded in the only caller, in ICL. Remove code and rename functions/macros accordingly to use ICL prefix for those that are still needed. Verified with: make EXTRA_CFLAGS=-Wunused drivers/gpu/drm/i915/display/intel_dpll_mgr.o Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210729233934.2059489-1-lucas.demarchi@intel.com
2021-07-30drm/i915/display: remove explicit CNL handling from intel_dp.cLucas De Marchi
The only real platform with DISPLAY_VER == 10 is GLK. We don't need to handle CNL explicitly in intel_dp.c. Remove code and rename functions/macros accordingly to use ICL prefix. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-10-lucas.demarchi@intel.com
2021-07-30drm/i915/display: remove explicit CNL handling from intel_dmc.cLucas De Marchi
Remove DMC firmware for CNL. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-9-lucas.demarchi@intel.com
2021-07-30drm/i915/display: remove explicit CNL handling from intel_display_debugfs.cLucas De Marchi
Only one reference to CNL that is not needed, but code is the same for DISPLAY_VER >= 11, so leave the code around and just remove the special case for CNL. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-8-lucas.demarchi@intel.com
2021-07-30drm/i915/display: remove explicit CNL handling from intel_ddi.cLucas De Marchi
The only real platform with DISPLAY_VER == 10 is GLK. We don't need to handle CNL explicitly in intel_ddi.c. Remove code and rename functions/macros accordingly to use ICL prefix. There's one leftover reference to cnl that comes from the struct intel_ddi_buf_trans. This will be renamed later when we get rid of the additional CNL tables. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-7-lucas.demarchi@intel.com
2021-07-30drm/i915/display: remove explicit CNL handling from intel_crtc.cLucas De Marchi
No need for special CNL handling as there is no real platform with that configuration. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-6-lucas.demarchi@intel.com
2021-07-30drm/i915/display: remove explicit CNL handling from intel_combo_phy.cLucas De Marchi
The only real platform with DISPLAY_VER == 10 is GLK, that doesn't have combo phys. We don't need to handle CNL explicitly in intel_combo_phy.c. Remove code and rename functions/macros accordingly to use ICL prefix. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-5-lucas.demarchi@intel.com
2021-07-30drm/i915/display: remove explicit CNL handling from intel_color.cLucas De Marchi
The only real platform with DISPLAY_VER == 10 is GLK, so we don't need any checks and supporting code for CNL. For DISPLAY_VER >= 11, ilk_load_csc_matrix() is not used, so make it handle GLK only. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-4-lucas.demarchi@intel.com
2021-07-30drm/i915/display: remove explicit CNL handling from intel_cdclk.cLucas De Marchi
The only real platform with DISPLAY_VER == 10 is GLK, so we don't need any checks and supporting code for CNL. Remove code and rename functions/macros accordingly. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-3-lucas.demarchi@intel.com
2021-07-30drm/i915/display: remove PORT_F workaround for CNLLucas De Marchi
Explicit support for CNL is being removed from the driver as it's not expected to work. Remove the workaround for PORT_F from display/intel_bios.c so we can also remove the generic DISPLAY_VER == 10 calls to intel_ddi_init(): the only platform with that display version is already handled separately (GLK). Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-2-lucas.demarchi@intel.com
2021-07-30drm/amdgpu: fix the doorbell missing when in CGPG issue for renoir.Yifan Zhang
If GC has entered CGPG, ringing doorbell > first page doesn't wakeup GC. Enlarge CP_MEC_DOORBELL_RANGE_UPPER to workaround this issue. Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-30drm/amdgpu: Fix out-of-bounds read when update mappingxinhui pan
If one GTT BO has been evicted/swapped out, it should sit in CPU domain. TTM only alloc struct ttm_resource instead of struct ttm_range_mgr_node for sysMem. Now when we update mapping for such invalidated BOs, we might walk out of bounds of struct ttm_resource. Three possible fix: 1) Let sysMem manager alloc struct ttm_range_mgr_node, like ttm_range_manager does. 2) Pass pages_addr to update_mapping function too, but need memset pages_addr[] to zero when unpopulate. 3) Init amdgpu_res_cursor directly. bug is detected by kfence. ================================================================== BUG: KFENCE: out-of-bounds read in amdgpu_vm_bo_update_mapping+0x564/0x6e0 Out-of-bounds read at 0x000000008ea93fe9 (64B right of kfence-#167): amdgpu_vm_bo_update_mapping+0x564/0x6e0 [amdgpu] amdgpu_vm_bo_update+0x282/0xa40 [amdgpu] amdgpu_vm_handle_moved+0x19e/0x1f0 [amdgpu] amdgpu_cs_vm_handling+0x4e4/0x640 [amdgpu] amdgpu_cs_ioctl+0x19e7/0x23c0 [amdgpu] drm_ioctl_kernel+0xf3/0x180 [drm] drm_ioctl+0x2cb/0x550 [drm] amdgpu_drm_ioctl+0x5e/0xb0 [amdgpu] kfence-#167 [0x000000008e11c055-0x000000001f676b3e ttm_sys_man_alloc+0x35/0x80 [ttm] ttm_resource_alloc+0x39/0x50 [ttm] ttm_bo_swapout+0x252/0x5a0 [ttm] ttm_device_swapout+0x107/0x180 [ttm] ttm_global_swapout+0x6f/0x130 [ttm] ttm_tt_populate+0xb1/0x2a0 [ttm] ttm_bo_handle_move_mem+0x17e/0x1d0 [ttm] ttm_mem_evict_first+0x59d/0x9c0 [ttm] ttm_bo_mem_space+0x39f/0x400 [ttm] ttm_bo_validate+0x13c/0x340 [ttm] ttm_bo_init_reserved+0x269/0x540 [ttm] amdgpu_bo_create+0x1d1/0xa30 [amdgpu] amdgpu_bo_create_user+0x40/0x80 [amdgpu] amdgpu_gem_object_create+0x71/0xc0 [amdgpu] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x2f2/0xcd0 [amdgpu] kfd_ioctl_alloc_memory_of_gpu+0xe2/0x330 [amdgpu] kfd_ioctl+0x461/0x690 [amdgpu] Signed-off-by: xinhui pan <xinhui.pan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-30drm: clean up unused kerneldoc in drm_lease.cDesmond Cheong Zhi Xi
The kerneldoc in drm_lease.c is unused because none of the functions are driver interfaces as the symbols are not exported. Since they aren't used and much of the existing comments don't provide any insights (e.g. they just repeat the function name or list out the function parameters), they should be removed to make them easier to maintain and to make useful info more obvious. As a note, many of the comments mention whether idr_mutex should be held, but these are mostly redundant in cases where the function contains lockdep assertions or grabs the mutex. To simplify review, here's the reasoning behind each update. drm_lease_owner: function name is self-descriptive _drm_find_lessee: function name is self-descriptive _drm_lease_held_master: function name and signature are self-descriptive _drm_has_leased: kerneldoc is summarized into a comment because the function name could be interpreted ambiguously (check if the object has been leased VS check if the master has a lease on the object) _drm_lease_held: Retain the idr_mutex comment because the function does not directly grab the mutex or use a lockdep assertion. Otherwise, the function name is self-descriptive. drm_lease_held: function name is self-descriptive drm_lease_filter_crtcs: Kerneldoc is summarized into a comment because the function name could be interpreted ambiguously (filter leases based on crtcs mask VS filter crtcs mask based on leases) drm_lease_create: Kerneldoc removed. Useful function details such as atomic leasing are retained. Errno interpretations are useful and retained. drm_lease_destroy: function name is self-descriptive. Additional information is also removed as they're already present as comments inside the function. _drm_lease_revoke: function name is self-descriptive drm_lease_revoke: function name is self-descriptive drm_mode_create_lease_ioctl: Kerneldoc removed, but useful function details retained. drm_mode_list_lessees_ioctl: function name is self-descriptive. Additional details restate what the code does. drm_mode_get_lease_ioctl: Function summary retained to clarify that it's the leased objects that are returned, not the lease structure. drm_mode_revoke_lease_ioctl: Kerneldoc removed, but useful function details retained. Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210730051759.1570630-1-desmondcheongzx@gmail.com