summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2020-01-04drm: limit to INT_MAX in create_blob ioctlDaniel Vetter
commit 5bf8bec3f4ce044a223c40cbce92590d938f0e9c upstream. The hardened usercpy code is too paranoid ever since commit 6a30afa8c1fb ("uaccess: disallow > INT_MAX copy sizes") Code itself should have been fine as-is. Link: http://lkml.kernel.org/r/20191106164755.31478-1-daniel.vetter@ffwll.ch Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reported-by: syzbot+fb77e97ebf0612ee6914@syzkaller.appspotmail.com Fixes: 6a30afa8c1fb ("uaccess: disallow > INT_MAX copy sizes") Cc: Kees Cook <keescook@chromium.org> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-04drm/amdgpu: Call find_vma under mmap_semJason Gunthorpe
[ Upstream commit a9ae8731e6e52829a935d81a65d7f925cb95dbac ] find_vma() must be called under the mmap_sem, reorganize this code to do the vma check after entering the lock. Further, fix the unlocked use of struct task_struct's mm, instead use the mm from hmm_mirror which has an active mm_grab. Also the mm_grab must be converted to a mm_get before acquiring mmap_sem or calling find_vma(). Fixes: 66c45500bfdc ("drm/amdgpu: use new HMM APIs and helpers") Fixes: 0919195f2b0d ("drm/amdgpu: Enable amdgpu_ttm_tt_get_user_pages in worker threads") Link: https://lore.kernel.org/r/20191112202231.3856-11-jgg@ziepe.ca Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Philip Yang <Philip.Yang@amd.com> Tested-by: Philip Yang <Philip.Yang@amd.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amdgpu: fix uninitialized variable pasid_mapping_neededColin Ian King
[ Upstream commit 17cf678a33c6196a3df4531fe5aec91384c9eeb5 ] The boolean variable pasid_mapping_needed is not initialized and there are code paths that do not assign it any value before it is is read later. Fix this by initializing pasid_mapping_needed to false. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: 6817bf283b2b ("drm/amdgpu: grab the id mgr lock while accessing passid_mapping") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amdgpu: fix bad DMA from INTERRUPT_CNTL2Sam Bobroff
[ Upstream commit 3d0e3ce52ce3eb4b9de3caf9c38dbb5a4d3e13c3 ] The INTERRUPT_CNTL2 register expects a valid DMA address, but is currently set with a GPU MC address. This can cause problems on systems that detect the resulting DMA read from an invalid address (found on a Power8 guest). Instead, use the DMA address of the dummy page because it will always be safe. Fixes: 27ae10641e9c ("drm/amdgpu: add interupt handler implementation for si v3") Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amdgpu: Avoid accidental thread reactivation.Andrey Grodzovsky
[ Upstream commit a28fda312a9fabdf0e5f5652449d6197c9fb0a90 ] Problem: During GPU reset we call the GPU scheduler to suspend it's thread, those two functions in amdgpu also suspend and resume the sceduler for their needs but this can collide with GPU reset in progress and accidently restart a suspended thread before time. Fix: Serialize with GPU reset. Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amdgpu: fix potential double drop fence referencePan Bian
[ Upstream commit 946ab8db6953535a3a88c957db8328beacdfed9d ] The object fence is not set to NULL after its reference is dropped. As a result, its reference may be dropped again if error occurs after that, which may lead to a use after free bug. To avoid the issue, fence is explicitly set to NULL after dropping its reference. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Pan Bian <bianpan2016@163.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amd/powerplay: fix struct init in renoir_print_clk_levelsRaul E Rangel
[ Upstream commit d942070575910fdb687b9c8fd5467704b2f77c24 ] drivers/gpu/drm/amd/powerplay/renoir_ppt.c:186:2: error: missing braces around initializer [-Werror=missing-braces] SmuMetrics_t metrics = {0}; ^ Fixes: 8b8031703bd7 ("drm/amd/powerplay: implement sysfs for getting dpm clock") Signed-off-by: Raul E Rangel <rrangel@chromium.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amdgpu: disallow direct upload save restore list from gfx driverHawking Zhang
[ Upstream commit 58f46d4b65021083ef4b4d49c6e2c58e5783f626 ] Direct uploading save/restore list via mmio register writes breaks the security policy. Instead, the driver should pass s&r list to psp. For all the ASICs that use rlc v2_1 headers, the driver actually upload s&r list twice, in non-psp ucode front door loading phase and gfx pg initialization phase. The latter is not allowed. VG12 is the only exception where the driver still keeps legacy approach for S&R list uploading. In theory, this can be elimnated if we have valid srcntl ucode for VG12. Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Candice Li <Candice.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm: msm: a6xx: fix debug bus register configurationSharat Masetty
[ Upstream commit 7f4009c4bbea4438b50f3b12d1c57da3f5cd8db3 ] Fix the cx debugbus related register configuration, to collect accurate bus data during gpu snapshot. This helps with complete snapshot dump and also complete proper GPU recovery. Fixes: 1707add81551 ("drm/msm/a6xx: Add a6xx gpu state") Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Sharat Masetty <smasetty@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/339165 Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31gpu: host1x: Allocate gather copy for host1xThierry Reding
[ Upstream commit b78e70c04c149299bd210759d7c7af7c86b89ca8 ] Currently when the gather buffers are copied, they are copied to a buffer that is allocated for the host1x client that wants to execute the command streams in the buffers. However, the gather buffers will be read by the host1x device, which causes SMMU faults if the DMA API is backed by an IOMMU. Fix this by allocating the gather buffer copy for the host1x device, which makes sure that it will be mapped into the host1x's IOVA space if the DMA API is backed by an IOMMU. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/tegra: sor: Use correct SOR index on Tegra210Thierry Reding
[ Upstream commit 24e64f86da40e68c5f58af08796110f147b12193 ] The device tree bindings for the Tegra210 SOR don't require the controller instance to be defined, since the instance can be derived from the compatible string. The index is never used on Tegra210, so we got away with it not getting set. However, subsequent patches will change that, so make sure the proper index is used. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amd/display: correctly populate dpp refclk in fpgaAnthony Koo
[ Upstream commit 952f6c4b5d72d40f93f3deb61239290b357d434e ] [Why] In diags environment we are not programming the DPP DTO correctly. [How] Populate the dpp refclk in dccg so it can be used to correctly program DPP DTO. Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amd/display: setting the DIG_MODE to the correct value.Zhan liu
[ Upstream commit 967a3b85bac91c55eff740e61bf270c2732f48b2 ] [Why] This patch is for fixing Navi14 HDMI display pink screen issue. [How] Call stream->link->link_enc->funcs->setup twice. This is setting the DIG_MODE to the correct value after having been overridden by the call to transmitter control. Signed-off-by: Zhan Liu <zhan.liu@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm: Don't free jobs in wait_event_interruptible()Steven Price
[ Upstream commit 588b9828f0744ca13555c4a35cd0251ac8ad8ad2 ] drm_sched_cleanup_jobs() attempts to free finished jobs, however because it is called as the condition of wait_event_interruptible() it must not sleep. Unfortunately some free callbacks (notably for Panfrost) do sleep. Instead let's rename drm_sched_cleanup_jobs() to drm_sched_get_cleanup_job() and simply return a job for processing if there is one. The caller can then call the free_job() callback outside the wait_event_interruptible() where sleeping is possible before re-checking and returning to sleep if necessary. Tested-by: Christian Gmeiner <christian.gmeiner@gmail.com> Fixes: 5918045c4ed4 ("drm/scheduler: rework job destruction") Signed-off-by: Steven Price <steven.price@arm.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/337652/ Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/nouveau: Don't grab runtime PM refs for HPD IRQsLyude Paul
[ Upstream commit 09e530657e1c982d3dbc5e4302bf9207950c3d0a ] In order for suspend/resume reprobing to work, we need to be able to perform sideband communications during suspend/resume, along with runtime PM suspend/resume. In order to do so, we also need to make sure that nouveau doesn't bother grabbing a runtime PM reference to do so, since otherwise we'll start deadlocking runtime PM again. Note that we weren't able to do this before, because of the DP MST helpers processing UP requests from topologies in the same context as drm_dp_mst_hpd_irq() which would have caused us to open ourselves up to receiving hotplug events and deadlocking with runtime suspend/resume. Now that those requests are handled asynchronously, this change should be completely safe. Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191022023641.8026-10-lyude@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/gma500: fix memory disclosures due to uninitialized bytesKangjie Lu
[ Upstream commit ec3b7b6eb8c90b52f61adff11b6db7a8db34de19 ] "clock" may be copied to "best_clock". Initializing best_clock is not sufficient. The fix initializes clock as well to avoid memory disclosures and informaiton leaks. Signed-off-by: Kangjie Lu <kjlu@umn.edu> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191018044150.1899-1-kjlu@umn.edu Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amdgpu: fix amdgpu trace event print string format errorKevin Wang
[ Upstream commit 2c2fdb8bca290c439e383cfb6857b0c65e528964 ] the trace event print string format error. (use integer type to handle string) before: amdgpu_test_kev-1556 [002] 138.508781: amdgpu_cs_ioctl: sched_job=8, timeline=gfx_0.0.0, context=177, seqno=1, ring_name=ffff94d01c207bf0, num_ibs=2 after: amdgpu_test_kev-1506 [004] 370.703783: amdgpu_cs_ioctl: sched_job=12, timeline=gfx_0.0.0, context=234, seqno=2, ring_name=gfx_0.0.0, num_ibs=1 change trace event list: 1.amdgpu_cs_ioctl 2.amdgpu_sched_run_job 3.amdgpu_ib_pipe_sync Signed-off-by: Kevin Wang <kevin1.wang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amd/display: fix header for RN clk mgrjoseph gravenor
[ Upstream commit cd83fa1ea9b9431cf1d57ac4179a11bc4393a5b6 ] [why] Should always MP0_BASE for any register definition from MP per-IP header files. I belive the reason the linux version of MP1_BASE works is The 0th element of the 0th table of that is identical to the corrisponding value of MP0_BASE in the renoir offset header file. The reason we should only use MP0_BASE is There is only one set of per-IP headers MP that includes all register definitions related to SMU IP block. This IP includes MP0, MP1, MP2 and an ecryption engine that can be used only by MP0. As a result all register definitions from MP file should be based only on MP0_BASE data. [How] Change MP1_BASE to MP0_BASE Signed-off-by: joseph gravenor <joseph.gravenor@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amd/display: enable hostvm based on roimmu active for dcn2.1Dmytro Laktyushkin
[ Upstream commit 48d92e8eda3d9b61978377e7539bfc5958e850cf ] Enabling hostvm when ROIMMU is not active seems to break GPUVM. This fixes the issue by not enabling hostvm if ROIMMU is not activated. Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amd/powerplay: avoid disabling ECC if RAS is enabled for VEGA20Le Ma
[ Upstream commit df9331e561dab0a451cbd6a679ee88a95f306fd6 ] Program THM_BACO_CNTL.SOC_DOMAIN_IDLE=1 will tell VBIOS to disable ECC when BACO exit. This can save BACO exit time by PSP on none-ECC SKU. Drop the setting for ECC supported SKU. Signed-off-by: Le Ma <le.ma@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/bridge: dw-hdmi: Restore audio when setting a modeDaniel Kurtz
[ Upstream commit fadfee3f9d8f114435a8a3e9f83a227600d89de7 ] When setting a new display mode, dw_hdmi_setup() calls dw_hdmi_enable_video_path(), which disables all hdmi clocks, including the audio clock. We should only (re-)enable the audio clock if audio was already enabled when setting the new mode. Without this patch, on RK3288, there will be HDMI audio on some monitors if i2s was played to headphone when the monitor was plugged. ACER H277HU and ASUS PB278 are two of the monitors showing this issue. Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org> Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Yakir Yang <ykk@rock-chips.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191008102145.55134-1-cychiang@chromium.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amd/display: Program DWB watermarks from correct stateJulian Parkin
[ Upstream commit edb922b022c0c94805c4ffad202b3edff83d76f0 ] [Why] When diags adds a DWB via a stream update, we calculate MMHUBBUB paramaters, but dc->current_state has not yet been updated when the DWB programming happens. This leads to overflow on high bandwidth tests since the incorrect MMHUBBUB arbitration parameters are programmed. [How] Pass the updated context down to the (enable|update)_writeback functions so that they can use the correct watermarks when programming MMHUBBUB. Signed-off-by: Julian Parkin <julian.parkin@amd.com> Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amd/display: Fix dongle_caps containing stale information.David Galiffi
[ Upstream commit dd998291dbe92106d8c4a7581c409b356928d711 ] [WHY] During detection: function: get_active_converter_info populates link->dpcd_caps.dongle_caps only when dpcd_rev >= DPCD_REV_11 and DWN_STRM_PORTX_TYPE is DOWN_STREAM_DETAILED_HDMI or DOWN_STREAM_DETAILED_DP_PLUS_PLUS. Otherwise, it is not cleared, and stale information remains. During mode validation: function: dp_active_dongle_validate_timing reads link->dpcd_caps.dongle_caps->dongle_type to determine the maximum pixel clock to support. This information is now stale and no longer valid. [HOW] dp_active_dongle_validate_timing should be using link->dpcd_caps->dongle_type instead. Signed-off-by: David Galiffi <david.galiffi@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amd/display: add new active dongle to existent w/aVitaly Prosyak
[ Upstream commit 566b4252fe9da9582dde008c5e9c3eb7c136e348 ] [Why & How] Dongle 0x00E04C power down all internal circuits including AUX communication preventing reading DPCD table. Encoder will skip DP RX power down on disable output to keep receiver powered all the time. Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Reviewed-by: Charlene Liu <Charlene.Liu@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by: Vitaly Prosyak <Vitaly.Prosyak@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amd/display: wait for set pipe mcp command completionJosip Pavic
[ Upstream commit 15caeabc5787c15babad7ee444afe9c26df1c8b3 ] [Why] When the driver sends a pipe set command to the DMCU FW, it does not wait for the command to complete. This can lead to unpredictable behavior if, for example, the driver were to request a pipe disable to the FW via MCP, then power down some hardware before the firmware has completed processing the command. [How] Wait for the DMCU FW to finish processing set pipe commands Signed-off-by: Josip Pavic <Josip.Pavic@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amd/display: Properly round nominal frequency for SPDAric Cyr
[ Upstream commit c59802313e84bede954235b3a5dd0dd5325f49c5 ] [Why] Some displays rely on the SPD verticle frequency maximum value. Must round the calculated refresh rate to the nearest integer. [How] Round the nominal calculated refresh rate to the nearest whole integer. Signed-off-by: Aric Cyr <aric.cyr@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/drm_vblank: Change EINVAL by the correct errnoRodrigo Siqueira
[ Upstream commit aed6105b28b10613f16c0bfe97525fe5a23338df ] For historical reasons, the function drm_wait_vblank_ioctl always return -EINVAL if something gets wrong. This scenario limits the flexibility for the userspace to make detailed verification of any problem and take some action. In particular, the validation of “if (!dev->irq_enabled)” in the drm_wait_vblank_ioctl is responsible for checking if the driver support vblank or not. If the driver does not support VBlank, the function drm_wait_vblank_ioctl returns EINVAL, which does not represent the real issue; this patch changes this behavior by return EOPNOTSUPP. Additionally, drm_crtc_get_sequence_ioctl and drm_crtc_queue_sequence_ioctl, also returns EINVAL if vblank is not supported; this patch also changes the return value to EOPNOTSUPP in these functions. Lastly, these functions are invoked by libdrm, which is used by many compositors; because of this, it is important to check if this change breaks any compositor. In this sense, the following projects were examined: * Drm-hwcomposer * Kwin * Sway * Wlroots * Wayland * Weston * Mutter * Xorg (67 different drivers) For each repository the verification happened in three steps: * Update the main branch * Look for any occurrence of "drmCrtcQueueSequence", "drmCrtcGetSequence", and "drmWaitVBlank" with the command git grep -n "STRING". * Look in the git history of the project with the command git log -S<STRING> None of the above projects validate the use of EINVAL when using drmWaitVBlank(), which make safe, at least for these projects, to change the return values. On the other hand, mesa and xserver project uses drmCrtcQueueSequence() and drmCrtcGetSequence(); this change is harmless for both projects. Change since V5 (Pekka Paalanen): - Check if the change also affects Mutter Change since V4 (Daniel): - Also return EOPNOTSUPP in drm_crtc_[get|queue]_sequence_ioctl Change since V3: - Return EINVAL for _DRM_VBLANK_SIGNAL (Daniel) Change since V2: Daniel Vetter and Chris Wilson - Replace ENOTTY by EOPNOTSUPP - Return EINVAL if the parameters are wrong Cc: Keith Packard <keithp@keithp.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191002140516.adeyj3htylimmlmg@smtp.gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amdkfd: Fix MQD size calculationOak Zeng
[ Upstream commit 40a9592a26608e16f7545a068ea4165e1869f629 ] On device initialization, a chunk of GTT memory is pre-allocated for HIQ and all SDMA queues mqd. The size of this allocation was wrong. The correct sdma engine number should be PCIe-optimized SDMA engine number plus xgmi SDMA engine number. Reported-by: Jonathan Kim <Jonathan.Kim@amd.com> Signed-off-by: Jonathan Kim <Jonathan.Kim@amd.com> Signed-off-by: Oak Zeng <Oak.Zeng@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/bridge: dw-hdmi: Refuse DDC/CI transfers on the internal I2C controllerMatthias Kaehlcke
[ Upstream commit bee447e224b2645911c5d06e35dc90d8433fcef6 ] The DDC/CI protocol involves sending a multi-byte request to the display via I2C, which is typically followed by a multi-byte response. The internal I2C controller only allows single byte reads/writes or reads of 8 sequential bytes, hence DDC/CI is not supported when the internal I2C controller is used. The I2C transfers complete without errors, however the data in the response is garbage. Abort transfers to/from slave address 0x37 (DDC) with -EOPNOTSUPP, to make it evident that the communication is failing. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191002124354.v2.1.I709dfec496f5f0b44a7b61dcd4937924da8d8382@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amd/display: fix struct init in update_bounding_boxRaul E Rangel
[ Upstream commit 960b6f4f2d2e96d5f7ffe2854e0040b46cafbd36 ] dcn20_resource.c:2636:9: error: missing braces around initializer [-Werror=missing-braces] struct _vcs_dpi_voltage_scaling_st calculated_states[MAX_CLOCK_LIMIT_STATES] = {0}; ^ Fixes: 7ed4e6352c16f ("drm/amd/display: Add DCN2 HW Sequencer and Resource") Signed-off-by: Raul E Rangel <rrangel@chromium.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amd/display: set minimum abm backlight levelAnthony Koo
[ Upstream commit 2ad0cdf9e2e9e079af34af681863fa638f2ee212 ] [Why] A lot of the time, the backlight characteristic curve maps min backlight to a non-zero value. But there are cases where we want the curve to intersect at 0. In this scenario even if OS never asks to set 0% backlight, the ABM reduction can result in backlight being lowered close to 0. This particularly can cause problems in some LED drivers, and in general just looks like backlight is completely off. [How] Add default cap to disallow backlight from dropping below 1% even after ABM reduction is applied. Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amd/powerplay: A workaround to GPU RESET on APUchen gong
[ Upstream commit 068ad870bbd8f4f2c5b2fd4977a4f3330c9988f4 ] Changes to function "smu_suspend" in amdgpu_smu.c is a workaround. We should get real information about if baco is enabled or not, while we always consider APU SMU feature as enabled in current code. I know APU do not support baco mode for GPU reset, so I use "adev->flags" to skip function "smu_feature_is_enabled". Signed-off-by: chen gong <curry.gong@amd.com> Reviewed-by: Aaron Liu <aaron.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amdkfd: fix a potential NULL pointer dereference (v2)Allen Pais
[ Upstream commit 81de29d842ccb776c0f77aa3e2b11b07fff0c0e2 ] alloc_workqueue is not checked for errors and as a result, a potential NULL dereference could occur. v2 (Felix Kuehling): * Fix compile error (kfifo_free instead of fifo_free) * Return proper error code Signed-off-by: Allen Pais <allen.pais@oracle.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/sun4i: dsi: Fix TCON DRQ set bitsJagan Teki
[ Upstream commit 7ac6269968826f9cad61b501bb613cc5cadb7229 ] The LCD timing definitions between Linux DRM vs Allwinner are different, below diagram shows this clear differences. Active Front Sync Back Region Porch Porch <-----------------------><----------------><--------------><--------------> //////////////////////| ////////////////////// | ////////////////////// |.................. ................ ________________ <----- [hv]display -----> <------------- [hv]sync_start ------------> <--------------------- [hv]sync_end ----------------------> <-------------------------------- [hv]total ------------------------------> <----- lcd_[xy] --------> <- lcd_[hv]spw -> <---------- lcd_[hv]bp ---------> <-------------------------------- lcd_[hv]t ------------------------------> The DSI driver misinterpreted the hbp term from the BSP code to refer only to the backporch, when in fact it was backporch + sync. Thus the driver incorrectly used the horizontal front porch plus sync in its calculation of the DRQ set bit value, when it should not have included the sync timing. Including additional sync timings leads to flip_done timed out as: WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 [CRTC:46:crtc-0] vblank wait timed out Modules linked in: CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted 5.1.0-next-20190514-00026-g01f0c75b902d-dirty #13 Hardware name: Allwinner sun8i Family Workqueue: events deferred_probe_work_func [<c010ed54>] (unwind_backtrace) from [<c010b76c>] (show_stack+0x10/0x14) [<c010b76c>] (show_stack) from [<c0688c70>] (dump_stack+0x84/0x98) [<c0688c70>] (dump_stack) from [<c011d9e4>] (__warn+0xfc/0x114) [<c011d9e4>] (__warn) from [<c011da40>] (warn_slowpath_fmt+0x44/0x68) [<c011da40>] (warn_slowpath_fmt) from [<c040cd50>] (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) [<c040cd50>] (drm_atomic_helper_wait_for_vblanks.part.1) from [<c040e694>] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) [<c040e694>] (drm_atomic_helper_commit_tail_rpm) from [<c040e4dc>] (commit_tail+0x40/0x6c) [<c040e4dc>] (commit_tail) from [<c040e5cc>] (drm_atomic_helper_commit+0xbc/0x128) [<c040e5cc>] (drm_atomic_helper_commit) from [<c0411b64>] (restore_fbdev_mode_atomic+0x1cc/0x1dc) [<c0411b64>] (restore_fbdev_mode_atomic) from [<c04156f8>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) [<c04156f8>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c0415774>] (drm_fb_helper_set_par+0x30/0x54) [<c0415774>] (drm_fb_helper_set_par) from [<c03ad450>] (fbcon_init+0x560/0x5ac) [<c03ad450>] (fbcon_init) from [<c03eb8a0>] (visual_init+0xbc/0x104) [<c03eb8a0>] (visual_init) from [<c03ed1b8>] (do_bind_con_driver+0x1b0/0x390) [<c03ed1b8>] (do_bind_con_driver) from [<c03ed780>] (do_take_over_console+0x13c/0x1c4) [<c03ed780>] (do_take_over_console) from [<c03ad800>] (do_fbcon_takeover+0x74/0xcc) [<c03ad800>] (do_fbcon_takeover) from [<c013c9c8>] (notifier_call_chain+0x44/0x84) [<c013c9c8>] (notifier_call_chain) from [<c013cd20>] (__blocking_notifier_call_chain+0x48/0x60) [<c013cd20>] (__blocking_notifier_call_chain) from [<c013cd50>] (blocking_notifier_call_chain+0x18/0x20) [<c013cd50>] (blocking_notifier_call_chain) from [<c03a6e44>] (register_framebuffer+0x1e0/0x2f8) [<c03a6e44>] (register_framebuffer) from [<c04153c0>] (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) [<c04153c0>] (__drm_fb_helper_initial_config_and_unlock) from [<c04158c8>] (drm_fbdev_client_hotplug+0xe8/0x1b8) [<c04158c8>] (drm_fbdev_client_hotplug) from [<c0415a20>] (drm_fbdev_generic_setup+0x88/0x118) [<c0415a20>] (drm_fbdev_generic_setup) from [<c043f060>] (sun4i_drv_bind+0x128/0x160) [<c043f060>] (sun4i_drv_bind) from [<c044b598>] (try_to_bring_up_master+0x164/0x1a0) [<c044b598>] (try_to_bring_up_master) from [<c044b668>] (__component_add+0x94/0x140) [<c044b668>] (__component_add) from [<c0445e1c>] (sun6i_dsi_probe+0x144/0x234) [<c0445e1c>] (sun6i_dsi_probe) from [<c0452ef4>] (platform_drv_probe+0x48/0x9c) [<c0452ef4>] (platform_drv_probe) from [<c04512cc>] (really_probe+0x1dc/0x2c8) [<c04512cc>] (really_probe) from [<c0451518>] (driver_probe_device+0x60/0x160) [<c0451518>] (driver_probe_device) from [<c044f7a4>] (bus_for_each_drv+0x74/0xb8) [<c044f7a4>] (bus_for_each_drv) from [<c045107c>] (__device_attach+0xd0/0x13c) [<c045107c>] (__device_attach) from [<c0450474>] (bus_probe_device+0x84/0x8c) [<c0450474>] (bus_probe_device) from [<c0450900>] (deferred_probe_work_func+0x64/0x90) [<c0450900>] (deferred_probe_work_func) from [<c0135970>] (process_one_work+0x204/0x420) [<c0135970>] (process_one_work) from [<c013690c>] (worker_thread+0x274/0x5a0) [<c013690c>] (worker_thread) from [<c013b3d8>] (kthread+0x11c/0x14c) [<c013b3d8>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) Exception stack(0xde539fb0 to 0xde539ff8) 9fa0: 00000000 00000000 00000000 00000000 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ---[ end trace b57eb1e5c64c6b8b ]--- random: fast init done [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:48:DSI-1] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] flip_done timed out With the terms(as described in above diagram) fixed, the panel displays correctly without any timeouts. Tested-by: Merlijn Wajer <merlijn@wizzup.org> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191003064527.15128-2-jagan@amarulasolutions.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amd/display: Set number of pipes to 1 if the second pipe was disabledNikola Cornij
[ Upstream commit 2fef0faa1cdc5d41ce3ef83f7b8f7e7ecb02d700 ] [why] Some ODM-related register settings are inconsistently updated by VBIOS, causing the state in DC to be invalid, which would then end up crashing in certain use-cases (such as disable/enable device). [how] Check the enabled status of the second pipe when determining the number of OPTC sources. If the second pipe is disabled, set the number of sources to 1 regardless of other settings (that may not be updated correctly). Signed-off-by: Nikola Cornij <nikola.cornij@amd.com> Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/komeda: Workaround for broken FLIP_COMPLETE timestampsMihail Atanassov
[ Upstream commit f59769c52cd7d158df53487ec2936f5592073340 ] When initially turning a crtc on, drm_reset_vblank_timestamp will set the vblank timestamp to 0 for any driver that doesn't provide a ->get_vblank_timestamp() hook. Unfortunately, the FLIP_COMPLETE event depends on that timestamp, and the only way to regenerate a valid one is to have vblank interrupts enabled and have a valid in-ISR call to drm_crtc_handle_vblank. Additionally, if the user doesn't request vblanks but _does_ request FLIP_COMPLETE events, we still don't have a good timestamp: it'll be the same stamp as the last vblank one. Work around the issue by always enabling vblanks when the CRTC is on. Reducing the amount of time that PL0 has to be unmasked would be nice to fix at a later time. Changes since v1 [https://patchwork.freedesktop.org/patch/331727/]: - moved drm_crtc_vblank_put call to the ->atomic_disable() hook Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com> Reviewed-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com> Signed-off-by: Ayan kumar halder <ayan.halder@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191001142121.13939-1-mihail.atanassov@arm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/meson: vclk: use the correct G12A frac max valueNeil Armstrong
[ Upstream commit d56276a13c2b9ea287b9fc7cc78bed4c43b286f9 ] When calculating the HDMI PLL settings for a DMT mode PHY frequency, use the correct max fractional PLL value for G12A VPU. With this fix, we can finally setup the 1024x768-60 mode. Fixes: 202b9808f8ed ("drm/meson: Add G12A Video Clock setup") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190828132311.23881-1-narmstrong@baylibre.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amd/display: Handle virtual signal type in disable_link()Martin Tsai
[ Upstream commit 616f5b65f1c02d3d6ae370644670d14c57de2fd8 ] [Why] The new implementation changed the behavior to allow process setMode to DAL when DAL returns empty mode query for unplugged display. This will trigger additional disable_link(). When unplug HDMI from MST dock, driver will update stream->signal to "Virtual". disable_link() will call disable_output() if the signal type is not DP and induce other displays on MST dock show black screen. [How] Don't need to process disable_output() if the signal type is virtual. Signed-off-by: Martin Tsai <martin.tsai@amd.com> Reviewed-by: Charlene Liu <Charlene.Liu@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amd/display: Rebuild mapped resources after pipe splitMikita Lipski
[ Upstream commit 387596ef2859c37d564ce15abddbc9063a132e2c ] [why] The issue is specific for linux, as on timings such as 8K@60 or 4K@144 DSC should be working in combination with ODM Combine in order to ensure that we can run those timings. The validation for those timings was passing, but when pipe split was happening second pipe wasn't being programmed. [how] Rebuild mapped resources if we split stream for ODM. Signed-off-by: Mikita Lipski <mikita.lipski@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/ttm: return -EBUSY on pipelining with no_gpu_wait (v2)Christian König
[ Upstream commit 3084cf46cf8110826a42de8c8ef30e8fa48974c2 ] Setting the no_gpu_wait flag means that the allocate BO must be available immediately and we can't wait for any GPU operation to finish. v2: squash in mem leak fix, rebase Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amdgpu: grab the id mgr lock while accessing passid_mappingChristian König
[ Upstream commit 6817bf283b2b851095825ec7f0e9f10398e09125 ] Need to make sure that we actually dropping the right fence. Could be done with RCU as well, but to complicated for a fix. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amdgpu/sriov: add ring_stop before ring_create in psp v11 codeJack Zhang
[ Upstream commit 51c0f58e9f6af3a387d14608033e6796a7ad90ee ] psp v11 code missed ring stop in ring create function(VMR) while psp v3.1 code had the code. This will cause VM destroy1 fail and psp ring create fail. For SIOV-VF, ring_stop should not be deleted in ring_create function. Signed-off-by: Jack Zhang <Jack.Zhang1@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amd/display: OTC underflow fixJaehyun Chung
[ Upstream commit 785908cf19c9eb4803f6bf9c0a7447dc3661d5c3 ] [Why] Underflow occurs on some display setups(repro'd on 3x4K HDR) on boot, mode set, and hot-plugs with. Underflow occurs because mem clk is not set high after disabling pstate switching. This behaviour occurs because some calculations assumed displays were synchronized. [How] Add a condition to check if timing sync is disabled so that synchronized vblank can be set to false. Signed-off-by: Jaehyun Chung <jaehyun.chung@amd.com> Reviewed-by: Alvin Lee <Alvin.Lee2@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/bridge: analogix-anx78xx: silence -EPROBE_DEFER warningsBrian Masney
[ Upstream commit 2708e876272d89bbbff811d12834adbeef85f022 ] Silence two warning messages that occur due to -EPROBE_DEFER errors to help cleanup the system boot log. Signed-off-by: Brian Masney <masneyb@onstation.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190815004854.19860-4-masneyb@onstation.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/amd/display: verify stream link before link testJing Zhou
[ Upstream commit b131932215c993ea5adf8192d1de2e8d6b23048d ] [Why] DP1.2 LL CTS test failure. [How] The failure is caused by not verify stream link is equal to link, only check stream and link is not null. Signed-off-by: Jing Zhou <Jing.Zhou@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm: Use EOPNOTSUPP, not ENOTSUPPDaniel Vetter
[ Upstream commit c7581a414d28413c1dd6d116d44859b5a52e0950 ] - it's what we recommend in our docs: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values - it's the overwhelmingly used error code for "operation not supported", at least in drm core (slightly less so in drivers): $ git grep EOPNOTSUPP -- drivers/gpu/drm/*c | wc -l 83 $ git grep ENOTSUPP -- drivers/gpu/drm/*c | wc -l 5 - include/linux/errno.h makes it fairly clear that these are for nfsv3 (plus they also have error codes above 512, which is the block with some special behaviour ...) /* Defined for the NFSv3 protocol */ If the above isn't reflecting current practice, then I guess we should at least update the docs. Noralf commented: Ben Hutchings made this comment[1] in a thread about use of ENOTSUPP in drivers: glibc's strerror() returns these strings for ENOTSUPP and EOPNOTSUPP respectively: "Unknown error 524" "Operation not supported" So at least for errors returned to userspace EOPNOTSUPP makes sense. José asked: > Hopefully this will not break any userspace None of the functions in drm_edid.c affected by this reach userspace, it's all driver internal. Same for the mipi function, that error code should be handled by drivers. Drivers are supposed to remap "the hw is on fire" to EIO when reporting up to userspace, but I think if a driver sees this it would be a driver bug. v2: Augment commit message with comments from Noralf and José Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Noralf Trønnes <noralf@tronnes.org> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Sean Paul <sean@poorly.run> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Andres Rodriguez <andresx7@gmail.com> Cc: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190904143942.31756-1-daniel.vetter@ffwll.ch Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm: exynos: exynos_hdmi: use cec_notifier_conn_(un)registerDariusz Marcinkiewicz
[ Upstream commit 71137bfd98973efb7b762ba168df077b87b34311 ] Use the new cec_notifier_conn_(un)register() functions to (un)register the notifier for the HDMI connector, and fill in the cec_connector_info. Changes since v7: - err_runtime_disable -> err_rpm_disable Changes since v2: - removed unnecessary call to invalidate phys address before deregistering the notifier, - use cec_notifier_phys_addr_invalidate instead of setting invalid address on a notifier. Signed-off-by: Dariusz Marcinkiewicz <darekm@google.com> Tested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> [hverkuil-cisco@xs4all.nl: use 'if (!hdata->notifier)' instead of '== NULL'] Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Link: https://patchwork.freedesktop.org/patch/msgid/20190828123415.139441-1-darekm@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/panel: Add missing drm_panel_init() in panel driversLaurent Pinchart
[ Upstream commit 65abbda8ed7ca48c8807d6b04a77431b438fa659 ] Panels must be initialised with drm_panel_init(). Add the missing function call in the panel-raspberrypi-touchscreen.c and panel-sitronix-st7789v.c drivers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190823193245.23876-2-laurent.pinchart@ideasonboard.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/mipi-dbi: fix a loop in debugfs codeDan Carpenter
[ Upstream commit d72cf01f410aa09868d98b672f3f92328c96b32d ] This code will likely crash if we try to do a zero byte write. The code looks like this: /* strip trailing whitespace */ for (i = count - 1; i > 0; i--) if (isspace(buf[i])) ... We're writing zero bytes so count = 0. You would think that "count - 1" would be negative one, but because "i" is unsigned it is a large positive numer instead. The "i > 0" condition is true and the "buf[i]" access will be out of bounds. The fix is to make "i" signed and now everything works as expected. The upper bound of "count" is capped in __kernel_write() at MAX_RW_COUNT so we don't have to worry about it being higher than INT_MAX. Fixes: 02dd95fe3169 ("drm/tinydrm: Add MIPI DBI support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> [noralf: Adjust title] Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190821072456.GJ26957@mwanda Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31drm/virtio: switch virtio_gpu_wait_ioctl() to gem helper.Gerd Hoffmann
[ Upstream commit 29cf12394c0565d7eb1685bf0c1b4749aa6a8b66 ] Use drm_gem_reservation_object_wait() in virtio_gpu_wait_ioctl(). This also makes the ioctl run lockless. v9: fix return value. v5: handle lookup failure. v2: use reservation_object_test_signaled_rcu for VIRTGPU_WAIT_NOWAIT. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-3-kraxel@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-06-05 20:46:24 +0000