summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2021-02-02drm/vc4: hvs: Fix buffer overflow with the dlist handlingMaxime Ripard
Commit 0a038c1c29a7 ("drm/vc4: Move LBM creation out of vc4_plane_mode_set()") changed the LBM allocation logic from first allocating the LBM memory for the plane to running mode_set, adding a gap in the LBM, and then running the dlist allocation filling that gap. The gap was introduced by incrementing the dlist array index, but was never checking whether or not we were over the array length, leading eventually to memory corruptions if we ever crossed this limit. vc4_dlist_write had that logic though, and was reallocating a larger dlist array when reaching the end of the buffer. Let's share the logic between both functions. Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Eric Anholt <eric@anholt.net> Fixes: 0a038c1c29a7 ("drm/vc4: Move LBM creation out of vc4_plane_mode_set()") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210129160647.128373-1-maxime@cerno.tech
2021-02-02drm/amdkfd: fix null pointer panic while free buffer in kfdHuang Rui
In drm_gem_object_free, it will call funcs of drm buffer obj. So kfd_alloc should use amdgpu_gem_object_create instead of amdgpu_bo_create to initialize the funcs as amdgpu_gem_object_funcs. [ 396.231390] amdgpu: Release VA 0x7f76b4ada000 - 0x7f76b4add000 [ 396.231394] amdgpu: remove VA 0x7f76b4ada000 - 0x7f76b4add000 in entry 0000000085c24a47 [ 396.231408] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 396.231445] #PF: supervisor read access in kernel mode [ 396.231466] #PF: error_code(0x0000) - not-present page [ 396.231484] PGD 0 P4D 0 [ 396.231495] Oops: 0000 [#1] SMP NOPTI [ 396.231509] CPU: 7 PID: 1352 Comm: clinfo Tainted: G OE 5.11.0-rc2-custom #1 [ 396.231537] Hardware name: AMD Celadon-RN/Celadon-RN, BIOS WCD0401N_Weekly_20_04_0 04/01/2020 [ 396.231563] RIP: 0010:drm_gem_object_free+0xc/0x22 [drm] [ 396.231606] Code: eb ec 48 89 c3 eb e7 0f 1f 44 00 00 55 48 89 e5 48 8b bf 00 06 00 00 e8 72 0d 01 00 5d c3 0f 1f 44 00 00 48 8b 87 40 01 00 00 <48> 8b 00 48 85 c0 74 0b 55 48 89 e5 e8 54 37 7c db 5d c3 0f 0b c3 [ 396.231666] RSP: 0018:ffffb4704177fcf8 EFLAGS: 00010246 [ 396.231686] RAX: 0000000000000000 RBX: ffff993a0d0cc400 RCX: 0000000000003113 [ 396.231711] RDX: 0000000000000001 RSI: e9cda7a5d0791c6d RDI: ffff993a333a9058 [ 396.231736] RBP: ffffb4704177fdd0 R08: ffff993a03855858 R09: 0000000000000000 [ 396.231761] R10: ffff993a0d1f7158 R11: 0000000000000001 R12: 0000000000000000 [ 396.231785] R13: ffff993a0d0cc428 R14: 0000000000003000 R15: ffffb4704177fde0 [ 396.231811] FS: 00007f76b5730740(0000) GS:ffff993b275c0000(0000) knlGS:0000000000000000 [ 396.231840] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 396.231860] CR2: 0000000000000000 CR3: 000000016d2e2000 CR4: 0000000000350ee0 [ 396.231885] Call Trace: [ 396.231897] ? amdgpu_amdkfd_gpuvm_free_memory_of_gpu+0x24c/0x25f [amdgpu] [ 396.232056] ? __dynamic_dev_dbg+0xcd/0x100 [ 396.232076] kfd_ioctl_free_memory_of_gpu+0x91/0x102 [amdgpu] [ 396.232214] kfd_ioctl+0x211/0x35b [amdgpu] [ 396.232341] ? kfd_ioctl_get_queue_wave_state+0x52/0x52 [amdgpu] Fixes: 246cb7e49a70 ("drm/amdgpu: Introduce GEM object functions") Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Tested-by: Changfeng <changzhu@amd.com> Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-02-02drm/amdgpu: fix the issue that retry constantly once the buffer is oversizeHuang Rui
We cannot modify initial_domain every time while the retry starts. That will cause the busy waiting that unable to switch to GTT while the vram is not enough. Fixes: f8aab60422c3 ("drm/amdgpu: Initialise drm_gem_object_funcs for imported BOs") Signed-off-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-02-02drm/i915/dp: Fix LTTPR vswing/pre-emp setting in non-transparent modeImre Deak
The DP PHY vswing/pre-emphasis level programming the driver does is related to the DPTX -> first LTTPR link segment only. Accordingly it should be only programmed when link training the first LTTPR and kept as-is when training subsequent LTTPRs and the DPRX. For these latter PHYs the vs/pe levels will be set in response to writing the DP_TRAINING_LANEx_SET_PHY_REPEATERy DPCD registers (by an upstream LTTPR TX PHY snooping this write access of its downstream LTTPR/DPRX RX PHY). The above is also described in DP Standard v2.0 under 3.6.6.1. While at it simplify and add the LTTPR that is link trained to the debug message in intel_dp_set_signal_levels(). Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201229172201.4155327-2-imre.deak@intel.com (cherry picked from commit 67fba3f1c73b83569d171ae1fa463a537bbfe0a8) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-02-02drm/i915/dp: Move intel_dp_set_signal_levels() to intel_dp_link_training.cImre Deak
intel_dp_set_signal_levels() is needed for link training, so move it to intel_dp_link_training.c. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201229172201.4155327-1-imre.deak@intel.com (cherry picked from commit 1c6e527d6947ea77bebabe15bbeaa765a87b70ca) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-02-02drm/i915: Fix the MST PBN divider calculationImre Deak
Atm the driver will calculate a wrong MST timeslots/MTP (aka time unit) value for MST streams if the link parameters (link rate or lane count) are limited in a way independent of the sink capabilities (reported by DPCD). One example of such a limitation is when a MUX between the sink and source connects only a limited number of lanes to the display and connects the rest of the lanes to other peripherals (USB). Another issue is that atm MST core calculates the divider based on the backwards compatible DPCD (at address 0x0000) vs. the extended capability info (at address 0x2200). This can result in leaving some part of the MST BW unused (For instance in case of the WD19TB dock). Fix the above two issues by calculating the PBN divider value based on the rate and lane count link parameters that the driver uses for all other computation. Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/2977 Cc: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjala <ville.syrjala@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210125173636.1733812-2-imre.deak@intel.com (cherry picked from commit b59c27cab257cfbff939615a87b72bce83925710) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-02-02drm/dp/mst: Export drm_dp_get_vc_payload_bw()Imre Deak
This function will be needed by the next patch where the driver calculates the BW based on driver specific parameters, so export it. At the same time sanitize the function params, passing the more natural link rate instead of the encoding of the same rate. v2: - Fix function documentation. (Lyude) Cc: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjala <ville.syrjala@intel.com> Cc: <stable@vger.kernel.org> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210125173636.1733812-1-imre.deak@intel.com (cherry picked from commit a321fc2b4e60fc1b39517d26c8104351636a6062) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-02-02amba: Make the remove callback return voidUwe Kleine-König
All amba drivers return 0 in their remove callback. Together with the driver core ignoring the return value anyhow, it doesn't make sense to return a value here. Change the remove prototype to return void, which makes it explicit that returning an error value doesn't work as expected. This simplifies changing the core remove callback to return void, too. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> # for drivers/memory Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> # for hwtracing/coresight Acked-By: Vinod Koul <vkoul@kernel.org> # for dmaengine Acked-by: Guenter Roeck <linux@roeck-us.net> # for watchdog Acked-by: Wolfram Sang <wsa@kernel.org> # for I2C Acked-by: Takashi Iwai <tiwai@suse.de> # for sound Acked-by: Vladimir Zapolskiy <vz@mleia.com> # for memory/pl172 Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20210126165835.687514-5-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2021-02-02Merge tag 'topic/drm-device-pdev-2021-02-02' of ↵Jani Nikula
git://anongit.freedesktop.org/drm/drm-intel into drm-intel-next Driver Changes: - drm/i915: Remove references to struct drm_device.pdev Signed-off-by: Jani Nikula <jani.nikula@intel.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87y2g6fxxv.fsf@intel.com
2021-02-02drm/i915/gvt: Remove references to struct drm_device.pdevThomas Zimmermann
Using struct drm_device.pdev is deprecated. Convert i915 to struct drm_device.dev. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210128133127.2311-4-tzimmermann@suse.de
2021-02-02drm/i915/gt: Remove references to struct drm_device.pdevThomas Zimmermann
Using struct drm_device.pdev is deprecated. Convert i915 to struct drm_device.dev. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210128133127.2311-3-tzimmermann@suse.de
2021-02-02drm/i915: Remove references to struct drm_device.pdevThomas Zimmermann
Using struct drm_device.pdev is deprecated. Convert i915 to struct drm_device.dev. No functional changes. v6: * also remove assignment in selftests/ in a later patch (Chris) v5: * remove assignment in later patch (Chris) v3: * rebased v2: * move gt/ and gvt/ changes into separate patches Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210128133127.2311-2-tzimmermann@suse.de
2021-02-02drm/i915/gem: Drop lru bumping on display unpinningChris Wilson
Simplify the frontbuffer unpin by removing the lock requirement. The LRU bumping was primarily to protect the GTT from being evicted and from frontbuffers being eagerly shrunk. Now we protect frontbuffers from the shrinker, and we avoid accidentally evicting from the GTT, so the benefit from bumping LRU is no more, and we can save more time by not. Reported-and-tested-by: Matti Hämäläinen <ccr@tnsp.org> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2905 Fixes: c1793ba86a41 ("drm/i915: Add ww locking to pin_to_display_plane, v2.") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210119214336.1463-6-chris@chris-wilson.co.uk (cherry picked from commit 14ca83eece9565a2d2177291ceb122982dc38420) Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: <stable@vger.kernel.org> # v5.10+ Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-02-02drm/i915/gt: Close race between enable_breadcrumbs and cancel_breadcrumbsChris Wilson
If we enable_breadcrumbs for a request while that request is being removed from HW; we may see that the request is active as we take the ce->signal_lock and proceed to attach the request to ce->signals. However, during unsubmission after marking the request as inactive, we see that the request has not yet been added to ce->signals and so skip the removal. Pull the check during cancel_breadcrumbs under the same spinlock as enabling so that we the two tests are consistent in enable/cancel. Otherwise, we may insert a request onto ce->signals that we expect should not be there: intel_context_remove_breadcrumbs:488 GEM_BUG_ON(!__i915_request_is_complete(rq)) While updating, we can note that we are always called with irqs-disabled, due to the engine->active.lock being held at the single caller, and so remove the irqsave/restore making it symmetric to enable_breadcrumbs. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2931 Fixes: c18636f76344 ("drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Cc: <stable@vger.kernel.org> # v5.10+ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210119162057.31097-1-chris@chris-wilson.co.uk (cherry picked from commit e7004ea4f5f528f5a5018f0b70cab36d25315498) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-02-02drm/i915/gt: Move the breadcrumb to the signaler if completed upon cancelChris Wilson
If while we are cancelling the breadcrumb signaling, we find that the request is already completed, move it to the irq signaler and let it be signaled. v2: Tweak reference counting so that we only acquire a new reference on adding to a signal list, as opposed to a hidden i915_request_put of the caller's reference. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201126140407.31952-5-chris@chris-wilson.co.uk (cherry picked from commit 85cc2917a3965a3a747a6407d6e3028cfeb1534e) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-02-02Merge tag 'topic/adl-s-enabling-2021-02-01-1' of ↵Jani Nikula
git://anongit.freedesktop.org/drm/drm-intel into drm-intel-next Driver Changes: - Add basic support for Alder Lake S, to be shared between drm-intel-next and drm-intel-gt-next Signed-off-by: Jani Nikula <jani.nikula@intel.com> # Conflicts: # drivers/gpu/drm/i915/i915_drv.h From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210202025620.2212559-1-lucas.demarchi@intel.com
2021-02-02drm/i915/display: Prevent double YUV range correction on HDR planesAndres Calderon Jaramillo
Prevent the ICL HDR plane pipeline from performing YUV color range correction twice when the input is in limited range. This is done by removing the limited-range code from icl_program_input_csc(). Before this patch the following could happen: user space gives us a YUV buffer in limited range; per the pipeline in [1], the plane would first go through a "YUV Range correct" stage that expands the range; the plane would then go through the "Input CSC" stage which would also expand the range because icl_program_input_csc() would use a matrix and an offset that assume limited-range input; this would ultimately cause dark and light colors to appear darker and lighter than they should respectively. This is an issue because if a buffer switches between being scanned out and being composited with the GPU, the user will see a color difference. If this switching happens quickly and frequently, the user will perceive this as a flickering. [1] https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-icllp-vol12-displayengine_0.pdf#page=281 Cc: stable@vger.kernel.org Signed-off-by: Andres Calderon Jaramillo <andrescj@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215224219.3896256-1-andrescj@google.com (cherry picked from commit fed387572040e84ead53852a7820e30a30e515d0) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210202084553.30691-1-ville.syrjala@linux.intel.com
2021-02-02drm/i915: Power up combo PHY lanes for for HDMI as wellVille Syrjälä
Currently we only explicitly power up the combo PHY lanes for DP. The spec says we should do it for HDMI as well. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210128155948.13678-3-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com> (cherry picked from commit 1e0cb7bef35f0d1aed383bf69a209df218b807c9) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-02-02drm/i915: Extract intel_ddi_power_up_lanes()Ville Syrjälä
Reduce the copypasta by pulling the combo PHY lane power up stuff into a helper. We'll have a third user soon. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210128155948.13678-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com> (cherry picked from commit 5cdf706fb91a6e4e6af799bb957c4d598e6a067b) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-02-02drm/i915: Skip vswing programming for TBTVille Syrjälä
In thunderbolt mode the PHY is owned by the thunderbolt controller. We are not supposed to touch it. So skip the vswing programming as well (we already skipped the other steps not applicable to TBT). Touching this stuff could supposedly interfere with the PHY programming done by the thunderbolt controller. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210128155948.13678-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com> (cherry picked from commit f8c6b615b921d8a1bcd74870f9105e62b0bceff3) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-02-02drm: msm: Migrate to dev_pm_opp_set_opp()Viresh Kumar
dev_pm_opp_set_bw() is getting removed and dev_pm_opp_set_opp() should be used instead. Migrate to the new API. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-02-01drm/msm/dsi_pll_10nm: Convert pr_err prints to DRM_DEV_ERRORAngeloGioacchino Del Regno
DRM_DEV_ERROR should be used across this entire source: convert the pr_err prints to the first as a cleanup. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-02-01drm/msm/dsi_pll_10nm: Fix variable usage for pll_lockdet_rateAngeloGioacchino Del Regno
The PLL_LOCKDET_RATE_1 was being programmed with a hardcoded value directly, but the same value was also being specified in the dsi_pll_regs struct pll_lockdet_rate variable: let's use it! Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-02-01drm/amdgpu/swsmu: use percent rather than rpm for manual fan control (v2)Alex Deucher
On some boards the rpm interface apparently does not work at all leading to the fan not spinning or spinning at strange speeds. Both interfaces work properly on the boards I have. Let's try and use the percent interface instead. v2: rebase on revert Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1408 Reviewed-by: Evan Quan <evan.quan@amd.com> (v1) Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-02-01Revert "drm/amdgpu/swsmu: drop set_fan_speed_percent (v2)"Alex Deucher
On some boards the rpm interface apparently does not work at all leading to the fan not spinning or spinning at strange speeds. Revert this for now to fix 5.10, 5.11. The follow on patch fixes this properly for 5.12. This reverts commit 8d6e65adc25e23fabbc5293b6cd320195c708dca. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1408 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-02-01drm/amd/display: Simplify bool conversionAbaci Team
Fix the following coccicheck warning: ./drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:3137:35-40: WARNING: conversion to bool not needed here Reported-by: Abaci Robot <abaci@linux.alibaba.com> Suggested-by: Yang Li <oswb@linux.alibaba.com> Signed-off-by: Abaci Team <abaci-bugfix@linux.alibaba.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-02-01amdgpu: Add Missing Sienna Cichlid DIDOri Messinger
The purpose of this patch is to add a missing device ID for Sienna Cichlid. The missing ID "0x73A1" is now added to the "amdgpu_drv.c" file. Signed-off-by: Ori Messinger <Ori.Messinger@amd.com> Reviewed-by: Kent Russell <kent.russell@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-02-01drm/amd/pm: correct string parsing for extra separator characters caseEvan Quan
Supplement of previous fix. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-02-01drm/amdgpu/pm: Account for extra separator characters in sysfs interfaceMatt Coffin
Currently, the the input to the pp_od_clk_voltage sysfs interface has two adjacent separator characters, i.e. "\n\0", then we try to parse an argument out of the empty string, whereas we really should just ignore this case, and treat any number of adjacent separators as one separator for arguments. We do this here by simply skipping the argument parsing for all empy-string arguments. An example test case would be `echo 's 1 900' > pp_od_clk_voltage` (note the two spaces after the 's'. This also solves the issue where the written string ends with both a newline, and a nul-terminator, '\n\0', as is the case for `echo 's 1 900' > pp_od_clk_voltage` since the recent rebase. Got lost during code rebase/merge. No need to port this to other branches. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Matt Coffin <mcoffin13@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-02-01Revert "Revert "drm/amdgpu: Fix NULL dereference in dpm sysfs handlers""Evan Quan
This reverts commit 2456c290a7889be492cb96092b62d16c11176f72. Got lost during code rebase/merge. No need to port this to other branches. Signed-off-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-02-01drm/msm/dsi_pll_10nm: Solve TODO for multiplier frac_bits assignmentAngeloGioacchino Del Regno
The number of fractional registers bits is known and already set in the frac_bits variable of the dsi_pll_config struct here in 10nm: remove the TODO by simply using that variable. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-02-01drm/msm/dsi_pll_10nm: Fix dividing the same numbers twiceAngeloGioacchino Del Regno
In function dsi_pll_calc_dec_frac we are calculating the decimal div start parameter by dividing the decimal multiple by the fractional multiplier: the remainder of that operation is stored to then get programmed to the fractional divider registers of the PLL. It's useless to call div_u64_rem to get the remainder and *then* call div_u64 to get the division result, as the first is already giving that result: let's fix it by just caring about the result of div_u64_rem. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-02-01drm/i915/adl_s: Add GT and CTX WAs for ADL-SAditya Swarup
- Extend Wa_1606931601 and Wa_1409804808 to ADL-S. - Extend Wa_14010919138 and Wa_14010229206 to ADL-S (Madhumitha) - Extend Wa_22010271021 to ADLS (cyokoyam) v2: - Extend Wa_1409804808 and remove unnecessary branching/redundant adls workaround placeholder functions. - Split WAs properly based on previous platforms and applicable ADLS WA. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210129182945.217078-9-aditya.swarup@intel.com
2021-02-01drm/i915/adl_s: Add display WAs for ADL-SAditya Swarup
- Extend permanent driver WA Wa_1409767108, Wa_14010685332 and Wa_14011294188 to adl-s. - Extend permanent driver WA Wa_1606054188 to adl-s. - Add Wa_14011765242 for adl-s A0 stepping. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210129182945.217078-8-aditya.swarup@intel.com
2021-02-01drm/i915/adl_s: Update memory bandwidth parametersTejas Upadhyay
Just like RKL, the ADL_S platform also has different memory characteristics from past platforms. Update the values used by our memory bandwidth calculations accordingly. v2: Fix minor nitpick for shifting ADLS case above RKL(based on platform order).(mdroper) Bspec: 64631 Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210129182945.217078-7-aditya.swarup@intel.com
2021-02-01drm/i915/adl_s: Load DMCAnusha Srivatsa
Load DMC on ADL_S v2.01. This is the first offcial release of DMC for ADL_S. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Reviewed-by: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210129182945.217078-6-aditya.swarup@intel.com
2021-02-01drm/i915/display: Add HAS_D12_PLANE_MINIMIZATIONJosé Roberto de Souza
- As RKL and ADL-S only have 5 planes, primary and 4 sprites and the cursor plane, let's group the handling together under HAS_D12_PLANE_MINIMIZATION. - Also use macro to select pipe irq fault error mask. BSpec: 49251 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210129182945.217078-5-aditya.swarup@intel.com
2021-02-01drm/i915/adl_s: Re-use TGL GuC/HuC firmwareMatt Roper
ADL-S, like RKL, uses the same internal device ID for the GuC and HuC as TGL did, making them all firmware-compatible. Let's re-use TGL's firmware for ADL-S. Bspec: 50668 Cc: John Harrison <John.C.Harrison@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210129182945.217078-4-aditya.swarup@intel.com
2021-02-01drm/i915/adl_s: Add power wellsLucas De Marchi
TGL power wells can be re-used for ADL-S with the exception of the fake power well for TC_COLD, just like DG-1. BSpec: 53597 Bspec: 49231 Cc: Imre Deak <imre.deak@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210129182945.217078-3-aditya.swarup@intel.com
2021-02-01drm/i915/adl_s: Update PHY_MISC programmingMatt Roper
ADL-S switches up which PHYs are considered a master to other PHYs; PHY-C is no longer a master, but PHY-D is now. Bspec: 49291 Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Reviewed-by: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210129182945.217078-2-aditya.swarup@intel.com
2021-02-01drm/i915/bios: tidy up child device debug loggingJani Nikula
Make the child device details easier to read by turning this: [drm:parse_ddi_port [i915]] Port B VBT info: CRT:0 DVI:1 HDMI:1 DP:0 eDP:0 LSPCON:0 USB-Type-C:0 TBT:0 DSC:0 [drm:parse_ddi_port [i915]] VBT HDMI level shift for port B: 8 [drm:parse_ddi_port [i915]] VBT DP max link rate for port B: 810000 [drm:parse_ddi_port [i915]] Port C VBT info: CRT:0 DVI:1 HDMI:1 DP:1 eDP:0 LSPCON:0 USB-Type-C:0 TBT:0 DSC:0 [drm:parse_ddi_port [i915]] VBT HDMI level shift for port C: 8 [drm:parse_ddi_port [i915]] VBT (e)DP boost level for port C: 3 [drm:parse_ddi_port [i915]] VBT HDMI boost level for port C: 1 [drm:parse_ddi_port [i915]] VBT DP max link rate for port C: 810000 into this: [drm:parse_ddi_port [i915]] Port B VBT info: CRT:0 DVI:1 HDMI:1 DP:0 eDP:0 LSPCON:0 USB-Type-C:0 TBT:0 DSC:0 [drm:parse_ddi_port [i915]] Port B VBT HDMI level shift: 8 [drm:parse_ddi_port [i915]] Port B VBT DP max link rate: 810000 [drm:parse_ddi_port [i915]] Port C VBT info: CRT:0 DVI:1 HDMI:1 DP:1 eDP:0 LSPCON:0 USB-Type-C:0 TBT:0 DSC:0 [drm:parse_ddi_port [i915]] Port C VBT HDMI level shift: 8 [drm:parse_ddi_port [i915]] Port C VBT (e)DP boost level: 3 [drm:parse_ddi_port [i915]] Port C VBT HDMI boost level: 1 [drm:parse_ddi_port [i915]] Port C VBT DP max link rate: 810000 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210127084534.24406-1-jani.nikula@intel.com
2021-02-01drm/i915/hdcp: disable the QSES check for HDCP2.2 over MSTJuston Li
Like the patch to disable QSES for HDCP 1.4 over MST https://patchwork.freedesktop.org/patch/415297/ the HDCP2.2 spec doesn't require QSES as well and we've seen QSES not supported on a couple HDCP2.2 docks so far (Dell WD19 and Lenovo LDC-G2) Remove it for now until we get a better idea of how widely supported QSES is and how to support it optionally. Signed-off-by: Juston Li <juston.li@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210127065034.2501119-4-juston.li@intel.com
2021-02-01Merge branch 'linux-5.12' of git://github.com/skeggsb/linux into drm-nextDave Airlie
Nothing too major here, I actually thought I'd sent most of these right before the new year, but that apparently got lost in the bustle: - Turing MMU fault recovery fixes - Fix mDP connectors being reported as eDP to userspace - Fixes for audio locking, and other bit-rot from DRM changes since atomic support was written - Misc other minor fixes. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Ben Skeggs <skeggsb@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv7yLfhuVbYa-4g0vxVt93OaC7Sodiz2R-TDHu-MoofEdw@mail.gmail.com
2021-01-31drm/msm/dp: trigger unplug event in msm_dp_display_disableJudy Hsiao
1. Trigger the unplug event in msm_dp_display_disable() to shutdown audio properly. 2. Reset the completion before signal the disconnect event. Fixes: 158b9aa74479 ("drm/msm/dp: wait for audio notification before disabling clocks") Reviewed-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Judy Hsiao <judyhsiao@chromium.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-01-31drm/msm/dp/dp_ctrl: Remove unneeded semicolonXu Wang
fix semicolon.cocci warnings: drivers/gpu/drm/msm/dp/dp_ctrl.c:1161:2-3: Unneeded semicolon Signed-off-by: Xu Wang <vulab@iscas.ac.cn> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-01-31drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c: Remove unneeded semicolonXu Wang
fix semicolon.cocci warnings: drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:752:2-3: Unneeded semicolon Signed-off-by: Xu Wang <vulab@iscas.ac.cn> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-01-31drm/msm: remove redundant NULL checkJiapeng Zhong
Fix below warnings reported by coccicheck: ./drivers/gpu/drm/msm/msm_gem.c:991:3-9: WARNING: NULL check before some freeing functions is not needed. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Zhong <abaci-bugfix@linux.alibaba.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-01-31drm/msm/kms: Make a lock_class_key for each crtc mutexStephen Boyd
Lockdep complains about an AA deadlock when rebooting the device. base-commit: 19c329f6808995b142b3966301f217c831e7cf31 ============================================ WARNING: possible recursive locking detected 5.4.91 #1 Not tainted -------------------------------------------- reboot/5213 is trying to acquire lock: ffffff80d13391b0 (&kms->commit_lock[i]){+.+.}, at: lock_crtcs+0x60/0xa4 but task is already holding lock: ffffff80d1339110 (&kms->commit_lock[i]){+.+.}, at: lock_crtcs+0x60/0xa4 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&kms->commit_lock[i]); lock(&kms->commit_lock[i]); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by reboot/5213: __arm64_sys_reboot+0x148/0x2a0 device_shutdown+0x10c/0x2c4 drm_atomic_helper_shutdown+0x48/0xfc modeset_lock+0x120/0x24c lock_crtcs+0x60/0xa4 stack backtrace: CPU: 4 PID: 5213 Comm: reboot Not tainted 5.4.91 #1 Hardware name: Google Pompom (rev1) with LTE (DT) Call trace: dump_backtrace+0x0/0x1dc show_stack+0x24/0x30 dump_stack+0xfc/0x1a8 __lock_acquire+0xcd0/0x22b8 lock_acquire+0x1ec/0x240 __mutex_lock_common+0xe0/0xc84 mutex_lock_nested+0x48/0x58 lock_crtcs+0x60/0xa4 msm_atomic_commit_tail+0x348/0x570 commit_tail+0xdc/0x178 drm_atomic_helper_commit+0x160/0x168 drm_atomic_commit+0x68/0x80 This is because lockdep thinks all the locks taken in lock_crtcs() are the same lock, when they actually aren't. That's because we call mutex_init() in msm_kms_init() and that assigns one static key for every lock initialized in this loop. Let's allocate a dynamic number of lock_class_keys and assign them to each lock so that lockdep can figure out an AA deadlock isn't possible here. Fixes: b3d91800d9ac ("drm/msm: Fix race condition in msm driver with async layer updates") Cc: Krishna Manikandan <mkrishn@codeaurora.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-01-31drm/msm: Clean up GMU OOB set/clear handling.Eric Anholt
Now that the bug is fixed in the minimal way for stable, go make the code table-driven. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-01-31drm/msm: Fix races managing the OOB state for timestamp vs timestamps.Eric Anholt
Now that we're not racing with GPU setup, also fix races of timestamps against other timestamps. In freedreno CI, we were seeing this path trigger timeouts on setting the GMU bit, producing: [drm:_a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set GPU_SET: 0x0 and this triggered especially on the first set of tests right after boot (it's probably easier to lose the race than one might think, given that we start many tests in parallel, and waiting for NFS to page in code probably means that lots of tests hit the same point of screen init at the same time). As of this patch, the message seems to have completely gone away. Signed-off-by: Eric Anholt <eric@anholt.net> Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support") Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>