summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2021-04-07drm/msm: Select CONFIG_NVMEMAkhil P Oommen1-0/+1
The speedbin support requires nvmem driver api. So lets explicitly enable CONFIG_NVMEM to have this support. Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org> Link: https://lore.kernel.org/r/1617630433-36506-2-git-send-email-akhilpo@codeaurora.org Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-04-07drm/msm/a6xx: Fix perfcounter oob timeoutAkhil P Oommen1-3/+9
We were not programing the correct bit while clearing the perfcounter oob. So, clear it correctly using the new 'clear' bit. This fixes the below error: [drm:a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set PERFCOUNTER: 0x80000000 Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org> Link: https://lore.kernel.org/r/1617630433-36506-1-git-send-email-akhilpo@codeaurora.org Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-04-07drm/msm: add compatibles for sm8150/sm8250 displayJonathan Marek2-0/+4
The driver already has support for sm8150/sm8250, but the compatibles were never added. Also inverse the non-mdp4 condition in add_display_components() to avoid having to check every new compatible in the condition. Signed-off-by: Jonathan Marek <jonathan@marek.ca> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210329120051.3401567-4-dmitry.baryshkov@linaro.org Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-04-07drm/msm: Remove need for reiterating the compatiblesBjorn Andersson1-6/+9
After spending a non-negligible time trying to figure out why dpu_kms_init() would dereference a NULL dpu_kms->pdev, it turns out that in addition to adding the new compatible to the msm_drv of_match_table one also need to teach add_display_components() to register the child nodes - which includes the DPU platform_device. Replace the open coded test for compatibles with a check against the match data of the mdss device to save others this trouble in the future. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210317025634.3987908-1-bjorn.andersson@linaro.org Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-04-07drm/msm: Fix spelling "purgable" -> "purgeable"Rob Clark3-15/+15
The previous patch fixes the user visible spelling. This one fixes the code. Oops. Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20210406151816.1515329-1-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-04-07drm/msm: Fix spelling mistake "Purgable" -> "Purgeable"Colin Ian King1-4/+4
There is a spelling mistake in debugfs gem stats. Fix it. Also re-align output to cater for the extra 1 character. Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20210406133939.425987-1-colin.king@canonical.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-04-07drm/msm: Drop mm_lock in scan loopRob Clark3-8/+45
lock_stat + mmm_donut[1] say that this reduces contention on mm_lock significantly (~350x lower waittime-max, and ~100x lower waittime-avg) [1] https://chromium.googlesource.com/chromiumos/platform/microbenchmarks/+/refs/heads/main/mmm_donut.py Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20210402211226.875726-1-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-04-07drm/msm: Improved debugfs gem statsRob Clark3-9/+36
The last patch lost the breakdown of active vs inactive GEM objects in $debugfs/gem. But we can add some better stats to summarize not just active vs inactive, but also purgable/purged to make up for that. Signed-off-by: Rob Clark <robdclark@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20210401012722.527712-5-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-04-07drm/msm: Fix debugfs deadlockRob Clark5-15/+35
In normal cases the gem obj lock is acquired first before mm_lock. The exception is iterating the various object lists. In the shrinker path, deadlock is avoided by using msm_gem_trylock() and skipping over objects that cannot be locked. But for debugfs the straightforward thing is to split things out into a separate list of all objects protected by it's own lock. Fixes: d984457b31c4 ("drm/msm: Add priv->mm_lock to protect active/inactive lists") Signed-off-by: Rob Clark <robdclark@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20210401012722.527712-4-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-04-07drm/msm: Avoid mutex in shrinker_count()Rob Clark5-27/+81
When the system is under heavy memory pressure, we can end up with lots of concurrent calls into the shrinker. Keeping a running tab on what we can shrink avoids grabbing a lock in shrinker->count(), and avoids shrinker->scan() getting called when not profitable. Also, we can keep purged objects in their own list to avoid re-traversing them to help cut down time in the critical section further. Signed-off-by: Rob Clark <robdclark@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20210401012722.527712-3-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-04-07drm/msm: Remove unused freed llist nodeRob Clark1-2/+0
Unused since commit c951a9b284b9 ("drm/msm: Remove msm_gem_free_work") Signed-off-by: Rob Clark <robdclark@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20210401012722.527712-2-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-04-07Merge tag 'drm-msm-fixes-2021-04-02' into msm-nextRob Clark14-60/+128
Pull in fixes from previous cycle
2021-04-07iommu/amd: Move a few prototypes to include/linux/amd-iommu.hChristoph Hellwig1-4/+0
A few functions that were intentended for the perf events support are currently declared in arch/x86/events/amd/iommu.h, which mens they are not in scope for the actual function definition. Also amdkfd has started using a few of them using externs in a .c file. End that misery by moving the prototypes to the proper header. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20210402143312.372386-5-hch@lst.de Signed-off-by: Joerg Roedel <jroedel@suse.de>
2021-04-07iommu: remove DOMAIN_ATTR_IO_PGTABLE_CFGChristoph Hellwig1-4/+1
Use an explicit set_pgtable_quirks method instead that just passes the actual quirk bitmask instead. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Will Deacon <will@kernel.org> Acked-by: Li Yang <leoyang.li@nxp.com> Link: https://lore.kernel.org/r/20210401155256.298656-20-hch@lst.de Signed-off-by: Joerg Roedel <jroedel@suse.de>
2021-04-07Merge tag 'drm-misc-next-2021-04-01' of ↵Dave Airlie67-505/+3894
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.13: UAPI Changes: Cross-subsystem Changes: Core Changes: - mst: Improve topology logging - edid: Rework and improvements for displayid Driver Changes: - anx7625: Regulators support - bridge: Support for the Chipone ICN6211, Lontium LT8912B - lt9611: Fix 4k panels handling Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210401110552.2b3yetlgsjtlotcn@gilmour
2021-04-06drm/panel: panel-dsi-cm: disable TE for nowSebastian Reichel1-3/+9
Disable TE for Droid 4 panel, since implementation is currently broken. Also disable it for N950 panel, which is untested. Reported-by: Tony Lindgren <tony@atomide.com> Reported-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Fixes: 4c1b935fea54 ("drm/omap: dsi: move TE GPIO handling into core") Signed-off-by: Sebastian Reichel <sre@kernel.org> Tested-by: Tony Lindgren <tony@atomide.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210227214542.99961-1-sebastian.reichel@collabora.com
2021-04-02drm/msm/disp/dpu1: program 3d_merge only if block is attachedKalyan Thota1-1/+3
Update the 3d merge as active in the data path only if the hw block is selected in the configuration. Reported-by: Stephen Boyd <swboyd@chromium.org> Fixes: 73bfb790ac78 ("msm:disp:dpu1: setup display datapath for SC7180 target") Signed-off-by: Kalyan Thota <kalyan_t@codeaurora.org> Message-Id: <1617364493-13518-1-git-send-email-kalyan_t@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-04-02drm/msm: a6xx: fix version check for the A650 SQE microcodeDmitry Baryshkov1-3/+3
I suppose the microcode version check for a650 is incorrect. It checks for the version 1.95, while the firmware released have major version of 0: 0.91 (vulnerable), 0.99 (fixing the issue). Lower version requirements to accept firmware 0.99. Fixes: 8490f02a3ca4 ("drm/msm: a6xx: Make sure the SQE microcode is safe") Cc: Akhil P Oommen <akhilpo@codeaurora.org> Cc: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Jordan Crouse <jordan@cosmicpenguin.net> Message-Id: <20210331140223.3771449-1-dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-04-02drm/msm: Fix a5xx/a6xx timestampsRob Clark2-4/+4
They were reading a counter that was configured to ALWAYS_COUNT (ie. cycles that the GPU is doing something) rather than ALWAYS_ON. This isn't the thing that userspace is looking for. Signed-off-by: Rob Clark <robdclark@chromium.org> Acked-by: Jordan Crouse <jordan@cosmicpenguin.net> Message-Id: <20210325012358.1759770-2-robdclark@gmail.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-04-02drm/msm: Fix removal of valid error case when checking speed_binJohn Stultz1-1/+7
Commit 7bf168c8fe8c ("drm/msm: Fix speed-bin support not to access outside valid memory"), reworked the nvmem reading of "speed_bin", but in doing so dropped handling of the -ENOENT case which was previously documented as "fine". That change resulted in the db845c board display to fail to start, with the following error: adreno 5000000.gpu: [drm:a6xx_gpu_init] *ERROR* failed to read speed-bin (-2). Some OPPs may not be supported by hardware Thus, this patch simply re-adds the ENOENT handling so the lack of the speed_bin entry isn't fatal for display, and gets things working on db845c. Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: Jordan Crouse <jcrouse@codeaurora.org> Cc: Eric Anholt <eric@anholt.net> Cc: Douglas Anderson <dianders@chromium.org> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: YongQin Liu <yongqin.liu@linaro.org> Reported-by: YongQin Liu <yongqin.liu@linaro.org> Fixes: 7bf168c8fe8c ("drm/msm: Fix speed-bin support not to access outside valid memory") Signed-off-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Akhil P Oommen <akhilpo@codeaurora.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Message-Id: <20210330013408.2532048-1-john.stultz@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-04-02drm/msm: Set drvdata to NULL when msm_drm_init() failsStephen Boyd1-0/+1
We should set the platform device's driver data to NULL here so that code doesn't assume the struct drm_device pointer is valid when it could have been destroyed. The lifetime of this pointer is managed by a kref but when msm_drm_init() fails we call drm_dev_put() on the pointer which will free the pointer's memory. This driver uses the component model, so there's sort of two "probes" in this file, one for the platform device i.e. msm_pdev_probe() and one for the component i.e. msm_drm_bind(). The msm_drm_bind() code is using the platform device's driver data to store struct drm_device so the two functions are intertwined. This relationship becomes a problem for msm_pdev_shutdown() when it tests the NULL-ness of the pointer to see if it should call drm_atomic_helper_shutdown(). The NULL test is a proxy check for if the pointer has been freed by kref_put(). If the drm_device has been destroyed, then we shouldn't call the shutdown helper, and we know that is the case if msm_drm_init() failed, therefore set the driver data to NULL so that this pointer liveness is tracked properly. Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display platform_driver") Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: Krishna Manikandan <mkrishn@codeaurora.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Message-Id: <20210325212822.3663144-1-swboyd@chromium.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-04-01Merge tag 'imx-drm-fixes-2021-04-01' of ↵Dave Airlie2-2/+12
git://git.pengutronix.de/git/pza/linux into drm-fixes drm/imx: imx-drm-core and imx-ldb fixes Fix a memory leak in an error path during DRM device initialization, fix the LDB driver to register channel 1 even if channel 0 is unused, and fix an out of bounds array access warning in the LDB driver. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Philipp Zabel <p.zabel@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210401092235.GA13586@pengutronix.de
2021-04-01Merge tag 'drm/tegra/for-5.12-rc6' of ↵Dave Airlie3-21/+26
ssh://git.freedesktop.org/git/tegra/linux into drm-fixes drm/tegra: Fixes for v5.12-rc6 This contains a couple of fixes for various issues such as lockdep warnings, runtime PM references, coupled display controllers and misconfigured PLLs. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thierry Reding <thierry.reding@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210401163352.3348296-1-thierry.reding@gmail.com
2021-04-01drm/vblank: Do not store a new vblank timestamp in drm_vblank_restore()Ville Syrjälä1-1/+2
drm_vblank_restore() exists because certain power saving states can clobber the hardware frame counter. The way it does this is by guesstimating how many frames were missed purely based on the difference between the last stored timestamp vs. a newly sampled timestamp. If we should call this function before a full frame has elapsed since we sampled the last timestamp we would end up with a possibly slightly different timestamp value for the same frame. Currently we will happily overwrite the already stored timestamp for the frame with the new value. This could cause userspace to observe two different timestamps for the same frame (and the timestamp could even go backwards depending on how much error we introduce when correcting the timestamp based on the scanout position). To avoid that let's not update the stored timestamp at all, and instead we just fix up the last recorded hw vblank counter value such that the already stored timestamp/seq number will match. Thus the next time a vblank irq happens it will calculate the correct diff between the current and stored hw vblank counter values. Sidenote: Another possible idea that came to mind would be to do this correction only if the power really was removed since the last time we sampled the hw frame counter. But to do that we would need a robust way to detect when it has occurred. Some possibilities could involve some kind of hardare power well transition counter, or potentially we could store a magic value in a scratch register that lives in the same power well. But I'm not sure either of those exist, so would need an actual investigation to find out. All of that is very hardware specific of course, so would have to be done in the driver code. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210218160305.16711-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2021-04-01drm: Refuse to create zero width/height cmdline modesVille Syrjälä1-0/+3
If the user specifies zero width/height cmdline mode i915 will blow up as the fbdev path will bypass the regular fb sanity check that would otherwise have refused to create a framebuffer with zero width/height. The reason I thought to try this is so that I can force a specific depth for fbdev without actually having to hardcode the mode on the kernel cmdline. Eg. if I pass video=0x0-8 I will get an 8bpp framebuffer at my monitor's native resolution. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190607162611.23514-2-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2021-04-01drivers: gpu: drm: bridge: fix kconfig dependency on DRM_KMS_HELPERJulian Braha1-0/+1
When DRM_TOSHIBA_TC358762 is enabled and DRM_KMS_HELPER is disabled, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for DRM_PANEL_BRIDGE Depends on [n]: HAS_IOMEM [=y] && DRM_BRIDGE [=y] && DRM_KMS_HELPER [=n] Selected by [y]: - DRM_TOSHIBA_TC358762 [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_BRIDGE [=y] && OF [=y] This is because DRM_TOSHIBA_TC358762 selects DRM_PANEL_BRIDGE, without depending on or selecting DRM_KMS_HELPER, despite that config option depending on DRM_KMS_HELPER. Signed-off-by: Julian Braha <julianbraha@gmail.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210222215502.24487-1-julianbraha@gmail.com
2021-04-01drm/mediatek: Don't support hdmi connector creationDafna Hirschfeld1-95/+56
commit f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges") broke the display support for elm device since mtk_dpi calls drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR while mtk_hdmi does not yet support this flag. Fix this by accepting DRM_BRIDGE_ATTACH_NO_CONNECTOR in bridge attachment. Implement the drm_bridge_funcs .detect() and .get_edid() operations, and call drm_bridge_hpd_notify() to report HPD. This provides the necessary API to support disabling connector creation. In addition, the field 'conn' is removed from the mtk_hdmi struct since mtk_hdmi don't create a connector. It is replaced with a pointer 'curr_conn' that points to the current connector which can be access through the global state. This patch is inspired by a similar patch for bridge/synopsys/dw-hdmi.c: commit ec971aaa6775 ("drm: bridge: dw-hdmi: Make connector creation optional") But with the difference that in mtk-hdmi only the option of not creating a connector is supported. Fixes: f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges") Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2021-04-01drm/mediatek: Switch the hdmi bridge ops to the atomic versionsDafna Hirschfeld1-8/+15
The bridge operation '.enable' and the audio cb '.get_eld' access hdmi->conn. In the future we will want to support the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR and then we will not have direct access to the connector. The atomic version '.atomic_enable' allows accessing the current connector from the state. This patch switches the bridge to the atomic version to prepare access to the connector in later patches. Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2021-04-01drm/komeda: Fix bit check to import to value of proper typeCarsten Haitzler3-16/+22
Another issue found by KASAN. The bit finding is buried inside the dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that calls the bit stuff. These bit functions want an unsigned long pointer as input and just dumbly casting leads to out-of-bounds accesses. This fixes that. Signed-off-by: Carsten Haitzler <carsten.haitzler@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: James Qian Wang <james.qian.wang@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210204131102.68658-1-carsten.haitzler@foss.arm.com
2021-04-01drm/komeda: Convert sysfs sprintf/snprintf family to sysfs_emitTian Tao1-3/+3
Fix the following coccicheck warning: drivers/gpu/drm/arm/display/komeda/komeda_dev.c:97:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/arm/display/komeda/komeda_dev.c:88:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/arm/display/komeda/komeda_dev.c:65:8-16: WARNING: use scnprintf or sprintf Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Reviewed-by: James Qian Wang <james.qian.wang@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/1617067518-31091-1-git-send-email-tiantao6@hisilicon.com
2021-04-01drm/bridge: anx7625: disable regulators when power offHsin-Yi Wang2-0/+35
When suspending the driver, anx7625_power_standby() will be called to turn off reset-gpios and enable-gpios. However, power supplies are not disabled. To save power, the driver can get the power supply regulators and turn off them in anx7625_power_standby(). Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: Robert Foss <robert.foss@linaro.org> Reviewed-by: Xin Ji <xji@analogixsemi.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210401053202.159302-2-hsinyi@chromium.org
2021-04-01Merge tag 'amd-drm-fixes-5.12-2021-03-31' of ↵Dave Airlie11-20/+26
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-5.12-2021-03-31: amdgpu: - Polaris idle power fix - VM fix - Vangogh S3 fix - Fixes for non-4K page sizes amdkfd: - dqm fence memory corruption fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210401020057.17831-1-alexander.deucher@amd.com
2021-04-01drm/amdgpu: check alignment on CPU page for bo mapXℹ Ruoyao1-4/+4
The page table of AMDGPU requires an alignment to CPU page so we should check ioctl parameters for it. Return -EINVAL if some parameter is unaligned to CPU page, instead of corrupt the page table sliently. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Xi Ruoyao <xry111@mengyan1223.wang> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2021-04-01drm/amdgpu: Set a suitable dev_info.gart_page_sizeHuacai Chen1-2/+2
In Mesa, dev_info.gart_page_size is used for alignment and it was set to AMDGPU_GPU_PAGE_SIZE(4KB). However, the page table of AMDGPU driver requires an alignment on CPU pages. So, for non-4KB page system, gart_page_size should be max_t(u32, PAGE_SIZE, AMDGPU_GPU_PAGE_SIZE). Signed-off-by: Rui Wang <wangr@lemote.com> Signed-off-by: Huacai Chen <chenhc@lemote.com> Link: https://github.com/loongson-community/linux-stable/commit/caa9c0a1 [Xi: rebased for drm-next, use max_t for checkpatch, and reworded commit message.] Signed-off-by: Xi Ruoyao <xry111@mengyan1223.wang> BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1549 Tested-by: Dan Horák <dan@danny.cz> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2021-04-01drm/amdgpu/vangogh: don't check for dpm in is_dpm_running when in suspendAlex Deucher1-0/+5
Do the same thing we do for Renoir. We can check, but since the sbios has started DPM, it will always return true which causes the driver to skip some of the SMU init when it shouldn't. Reviewed-by: Zhan Liu <zhan.liu@amd.com> Acked-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2021-04-01drm/amdkfd: dqm fence memory corruptionQu Huang7-12/+12
Amdgpu driver uses 4-byte data type as DQM fence memory, and transmits GPU address of fence memory to microcode through query status PM4 message. However, query status PM4 message definition and microcode processing are all processed according to 8 bytes. Fence memory only allocates 4 bytes of memory, but microcode does write 8 bytes of memory, so there is a memory corruption. Changes since v1: * Change dqm->fence_addr as a u64 pointer to fix this issue, also fix up query_status and amdkfd_fence_wait_timeout function uses 64 bit fence value to make them consistent. Signed-off-by: Qu Huang <jinsdb@126.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> Cc: stable@vger.kernel.org
2021-03-31Merge tag 'exynos-drm-next-for-v5.13' of ↵Dave Airlie2-6/+5
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next One cleanup - Based on the patch[1], clean up the use of request_irq function series. [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git/commit/?id=cbe16f35bee6880becca6f20d2ebf6b457148552 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Inki Dae <inki.dae@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1617092998-23645-1-git-send-email-inki.dae@samsung.com
2021-03-31Merge tag 'topic/i915-gem-next-2021-03-26' of ↵Dave Airlie114-2165/+2730
ssh://git.freedesktop.org/git/drm/drm into drm-next special i915-gem-next pull as requested - Conversion to dma_resv_locking, obj->mm.lock is gone (Maarten, with help from Thomas Hellström) - watchdog (Tvrtko, one patch to cancel individual request from Chris) - legacy ioctl cleanup (Jason+Ashutosh) - i915-gem TODO and RFC process doc (me) - i915_ prefix for vma_lookup (Liam Howlett) just because I spotted it and put it in here too Signed-off-by: Dave Airlie <airlied@redhat.com> From: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/YF24MHoOSjpKFEXA@phenom.ffwll.local
2021-03-31drm/tegra: Support sector layout on Tegra194Thierry Reding7-0/+78
Tegra194 has a special physical address bit that enables some memory swizzling logic to support different sector layouts. Support the bit that selects the sector layout which is passed in the framebuffer modifier. Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-31drm/tegra: Count number of display controllers at runtimeThierry Reding3-2/+27
In order to be able to attach planes to all possible display controllers the exact number of CRTCs must be known. Keep track of the number of the display controllers that register during initialization. Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-31drm/tegra: gem: Add a clarifying commentThierry Reding1-0/+8
Clarify when a fixed IOV address can be used and when a buffer has to be mapped before the IOVA can be used. Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-31drm/tegra: fb: Add diagnostics for framebuffer modifiersThierry Reding1-0/+1
Add a debug message to let the user know when a framebuffer modifier is not supported. Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-31drm/tegra: dc: Implement hardware cursor on Tegra186 and laterThierry Reding2-8/+58
The hardware cursor on Tegra186 differs slightly from the implementation on older SoC generations. In particular the new implementation relies on software for clipping the cursor against the screen. Fortunately, atomic KMS already computes clipped coordinates for (cursor) planes, so this is trivial to implement. The format supported by the hardware cursor is also slightly different. v2: use more drm_rect helpers (Dmitry) Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-31drm/tegra: dc: Parameterize maximum resolutionThierry Reding3-3/+17
Tegra186 and later support a higher maximum resolution than earlier chips, so make sure to reflect that in the mode configuration. Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-31drm/tegra: dc: Inherit DMA maskThierry Reding2-0/+14
Inherit the DMA mask from host1x (on Tegra210 and earlier) or the display hub (on Tegra186 and later). This is necessary in order to properly map buffers without SMMU support and use the maximum IOVA space available with SMMU support. Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-31gpu: host1x: Add early init and late exit callbacksThierry Reding1-0/+31
These callbacks can be used by client drivers to run code during early init and during late exit. Early init callbacks are run prior to the regular init callbacks while late exit callbacks run after the regular exit callbacks. Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-31gpu: host1x: Fix Tegra194 syncpt interrupt thresholdJon Hunter1-1/+1
Syncpoint interrupts are not working as expected on Tegra194. The problem is that the syncpoint interrupt threshold being used is the global interrupt threshold and not the virtual interrupt threshold. Fix this by using the virtual interrupt threshold which aligns with downstream. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-31gpu: host1x: Assign intr waiter inside lockMikko Perttunen1-2/+3
Move the assignment of the ref out-pointer in host1x_intr_add_action to happen within the spinlock. With the current arrangement, it is possible for the waiter to complete before the assignment has happened, which breaks horribly if the waiter completion callback tries to use the reference. In practice, there is currently no situation where this issue can manifest -- it was first noticed with the upcoming DMA fence implementation patches. As such this doesn't need to be backported. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-31gpu: host1x: Reserve VBLANK syncpoints at initializationMikko Perttunen4-1/+52
On T20-T148 chips, the bootloader can set up a boot splash screen with DC configured to increment syncpoint 26/27 at VBLANK. Because of this we shouldn't allow these syncpoints to be allocated until DC has been reset and will no longer increment them in the background. As such, on these chips, reserve those two syncpoints at initialization, and only mark them free once the DC driver has indicated it's safe to do so. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-31gpu: host1x: Reset max value when freeing a syncpointMikko Perttunen1-0/+2
With job recovery becoming optional, syncpoints may have a mismatch between their value and max value when freed. As such, when freeing, set the max value to the current value of the syncpoint so that it is in a sane state for the next user. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-12 02:00:00 +0300