- 22 Jun, 2023 6 commits
-
-
Marek Vasut authored
Add support for handling the HS/VS sync signals polarity in the bridge driver, otherwise e.g. DSIM bridge feeds the TC358762 inverted polarity sync signals and the image is shifted to the left, up, and wobbly. Signed-off-by:
Marek Vasut <marex@denx.de> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230615201902.566182-5-marex@denx.de
-
Marek Vasut authored
The register content and behavior is very similar to TC358764 VP_CTRL. All the bits except for unknown bit 6 also seem to match, even though the datasheet is just not available. Add a comment and reuse the bit definitions. Signed-off-by:
-
Marek Vasut authored
This bridge seems to need the HSE packet, otherwise the image is shifted up and corrupted at the bottom. This makes the bridge work with Samsung DSIM on i.MX8MM and i.MX8MP. Signed-off-by:
-
Marek Vasut authored
Switch the bridge driver over to atomic ops. No functional change. Signed-off-by:
-
Marek Vasut authored
Move the register programming part, which actually enables the bridge and makes it push data out of its DPI side, into the enable callback. The DSI host like DSIM may not be able to transmit commands in pre_enable, moving the register programming into enable assures it can transmit commands. Signed-off-by:
-
Marek Vasut authored
None of these four bits are bitfields, use BIT() macro and treat them as bits. No functional change. Signed-off-by:
-
- 21 Jun, 2023 8 commits
-
-
Dmitry Osipenko authored
Replace all drm-shmem locks with a GEM reservation lock. This makes locks consistent with dma-buf locking convention where importers are responsible for holding reservation lock for all operations performed over dma-bufs, preventing deadlock between dma-buf importers and exporters. Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Acked-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230529223935.2672495-7-dmitry.osipenko@collabora.com
-
Dmitry Osipenko authored
Change locking policy of mmap() callback, making exporters responsible for handling dma-buf reservation locking. Previous locking policy stated that dma-buf is locked for both importers and exporters by the dma-buf core, which caused a deadlock problem for DRM drivers in a case of self-imported dma-bufs which required to take the lock from the DRM exporter side. Acked-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
Dmitry Osipenko authored
Don't assert held dma-buf reservation lock on memory mapping of exported buffer. We're going to change dma-buf mmap() locking policy such that exporters will have to handle the lock. The previous locking policy caused deadlock problem for DRM drivers in a case of self-imported dma-bufs once these drivers are moved to use reservation lock universally. The problem is solved by moving the lock down to exporters. This patch prepares DRM drivers for the locking policy update. Reviewed-by:
-
Dmitry Osipenko authored
Don't assert held dma-buf reservation lock on memory mapping of exported buffer. We're going to change dma-buf mmap() locking policy such that exporters will have to handle the lock. The previous locking policy caused deadlock problem for DRM drivers in a case of self-imported dma-bufs once these drivers are moved to use reservation lock universally. The problem is solved by moving the lock down to exporters. This patch prepares udmabuf for the locking policy update. Reviewed-by:
-
Dmitry Osipenko authored
Don't assert held dma-buf reservation lock on memory mapping of exported buffer. We're going to change dma-buf mmap() locking policy such that exporters will have to handle the lock. The previous locking policy caused deadlock problem for DRM drivers in a case of self-imported dma-bufs once these drivers are moved to use reservation lock universally. The problem solved by moving the lock down to exporters. This patch prepares dma-buf heaps for the locking policy update. Reviewed-by:
-
Dmitry Osipenko authored
Don't assert held dma-buf reservation lock on memory mapping of exported buffer. We're going to change dma-buf mmap() locking policy such that exporters will have to handle the lock. The previous locking policy caused deadlock problem for DRM drivers in a case of self-imported dma-bufs once these drivers are moved to use reservation lock universally. The problem is solved by moving the lock down to exporters. This patch prepares videobuf2 for the locking policy update. Reviewed-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Jocelyn Falempe authored
I've contributed to these two drivers, fixing bugs and performance issues. Signed-off-by:
Jocelyn Falempe <jfalempe@redhat.com> Acked-by:
-
Juerg Haefliger authored
The module loads firmware so add a MODULE_FIRMWARE macro to provide that information via modinfo. Signed-off-by:
Juerg Haefliger <juerg.haefliger@canonical.com> Reviewed-by:
-
- 19 Jun, 2023 13 commits
-
-
Maíra Canal authored
Fix the following warnings: drivers/gpu/drm/vkms/vkms_composer.c:42: warning: Function parameter or member 'frame_info' not described in 'pre_mul_alpha_blend' drivers/gpu/drm/vkms/vkms_composer.c:42: warning: Excess function parameter 'src_frame_info' description in 'pre_mul_alpha_blend' drivers/gpu/drm/vkms/vkms_composer.c:93: warning: Cannot understand * @wb_frame_info: The writeback frame buffer metadata on line 93 - I thought it was a doc line by correcting variable names and adding function name. Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230508220030.434118-2-mcanal@igalia.com
-
Maíra Canal authored
The function vkms_compose_row() was introduced in the code without any documentation. In order to make the function more clear, add a kernel-doc to it. Suggested-by:
Melissa Wen <mwen@igalia.com> Signed-off-by:
-
Thomas Zimmermann authored
The callback struct drm_driver.gem_prime_mmap as been removed in commit 0adec227 ("drm: Remove struct drm_driver.gem_prime_mmap"). Do not assign to it. The assigned function, drm_gem_prime_mmap(), is now the default for the operation, so there is no change in functionality. Signed-off-by:
-
Thomas Zimmermann authored
Backmerging into drm-misc-next to get commit 2c1c7ba4 ("drm/amdgpu: support partition drm devices"), which is required to fix commit 0adec227 ("drm: Remove struct drm_driver.gem_prime_mmap"). Signed-off-by:
-
Thomas Zimmermann authored
All drivers initialize this field with drm_gem_prime_mmap(). Call the function directly and remove the field. Simplifies the code and resolves a long-standing TODO item. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230613150441.17720-3-tzimmermann@suse.de
-
Thomas Zimmermann authored
Only the msm driver provides its own implementation of gem_prime_mmap from struct drm_driver. All other drivers use the drm_gem_prime_mmap() helper. Initialize the mmap offset when constructing the buffer object in msm and reduce the gem_prime_mmap code to the generic helper. Prepares msm for the removal of struct drm_driver.gem_prime_mmap. Signed-off-by:
-
Tomi Valkeinen authored
Add drm-misc as the git tree for tilcdc and omapdrm. Change Tomi's email to point to ideasonboard.com instead of kernel.org. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230619082323.20575-1-tomi.valkeinen@ideasonboard.com
-
Aradhya Bhatia authored
Add support for the DSS controller on TI's AM625 SoC in the tidss driver. The AM625 DSS supports 2 video planes connecting to 2 video ports. The first plane is a full plane supporting all the features, while the 2nd plane is a "lite" plane without scaling support. The first video port in AM625 DSS internally provides DPI output to 2 OLDI transmitters. Each OLDI TX outputs 4 differential lanes of video output and 1 of clock output. This patch does not automatically enable the OLDI features of AM625 yet. That support for OLDI will be added subsequently. The second video port outputs DPI data directly out of the SoC. It has 24 data lines and can support a maximum of RGB888 output bus format. Signed-off-by:
Aradhya Bhatia <a-bhatia1@ti.com> Reviewed-by:
-
Aradhya Bhatia authored
The DSS controller on TI's AM625 SoC is an update from that on TI's AM65X SoC. The former has an additional OLDI TX on its first video port that helps output cloned video or WUXGA (1920x1200@60fps) resolution video output over a dual-link mode to reduce the required OLDI clock output. The second video port is same from AM65x DSS and it outputs DPI video data. It can support 2K resolutions @ 60fps, independently. Add the new controller's compatible and update descriptions. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
https://gitlab.freedesktop.org/drm/msmDave Airlie authored
Updates for v6.5.. this includes a backmerg of drm-next tree to be able to use new DRM DSC helpers. Core: + Add Marijn Suijten as drm/msm reviewer + Adreno A660 bindings + SM8350 MDSS bindings fix + Fix adreno_is_a690() warnings + More generic (DRM) and MSM-specific DSC helpers DP: + Removed obsolete USB-PD remains + Documented DP compatible string for sm8550 platform DPU: + Enable missing features (DSPP, DSC, split display) on sc8180x, sc8280xp, sm8450 + Enabled writeback on sc7280 + Implemented tearcheck support to support vsync on SM150 and newer platforms + Native HDMI output support + Dropped unused features: regdma, GC, IGC + Fixed the DSC flush operations + Simplified QoS handling, removing obsolete and unused features and merging SSPP and WB code paths + Reworked dpu_encoder initialisation path + Enabled DSPP support on sdm845 + Disabled color-management if DSPP blocks are not available + Added support for DSC 1.2 blocks found on sm8350 and later + Added .fb_dirty to fix CMD panels DSI: + Drop powerup quirks in favour of using pre_enable_prev_first for downstream bridges + Fixed 14nm DSI PHY programming + Added support for DSI and 28nm DSI PHY on MSM8226 platform + Make use of DRM and MSM DSC helpers MDP5: + Added support for display controller on MSM8226 platform GPU: + A690 support + Don't set IO_PGTABLE_QUIRK_ARM_OUTER_WBWA on devices with coherent SMMU (like A690) + Move cmdstream dumping out of fence signaling path + Cleanups + Support for a6xx devices without GMU (aka "GMU wrapper" + a610 support + a619_holi support (a619 variant without GMU) Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGsUB=tRB4nR6ZCJMuLhro5zN3BQWUSywVYbaipqqDZ_cQ@mail.gmail.com
-
Dave Airlie authored
Backmerge tag 'v6.4-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next Linux 6.4-rc7 Need this to pull in the msm work. Signed-off-by:
-
https://gitlab.freedesktop.org/agd5f/linuxDave Airlie authored
amd-drm-next-6.5-2023-06-16: amdgpu: - Misc display fixes - W=1 fixes - Improve scheduler naming - DCN 3.1.4 fixes - kdoc fixes - Enable W=1 - VCN 4.0 fix - xgmi fixes - TOPDOWN fix for large BAR systems - eDP fix - PSR fixes - SubVP fixes - Freesync fix - DPIA fix - SMU 13.0.5 fixes - vblflash fix - RAS fixes - SDMA 4 fix - BO locking fix - BO backing store fix - NBIO 7.9 fixes - GC 9.4.3 fixes - GPU reset recovery fixes - HMM fix amdkfd: - Fix NULL check - Trap fixes - Queue count fix - Add event age tracking radeon: - fbdev client fix scheduler: - Avoid an infinite loop UAPI: - Add KFD event age tracking: Proposed ROCT-Thunk-Interface: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/commit/efdbf6cfbc026bd68ac3c35d00dacf84370eb81e https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/commit/1820ae0a2db85b6f584611dc0cde1a00e7c22915 Proposed ROCR-Runtime: https://github.com/RadeonOpenCompute/ROCR-Runtime/compare/master...zhums:ROCR-Runtime:new_event_wait_review https://github.com/RadeonOpenCompute/ROCR-Runtime/commit/e1f5bdb88eb882ac798aeca2c00ea3fbb2dba459 https://github.com/RadeonOpenCompute/ROCR-Runtime/commit/7d26afd14107b5c2a754c1a3f415d89f3aabb503 drm: - DP MST fix Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2023-06-15' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Short summary of fixes pull: * Fix fbdev initializer macros Signed-off-by:
-
- 18 Jun, 2023 13 commits
-
-
Linus Torvalds authored
-
Konrad Dybcio authored
A610 is implemented on at least three SoCs: SM6115 (bengal), SM6125 (trinket) and SM6225 (khaje). Trinket does not support speed binning (only a single SKU exists) and we don't yet support khaje upstream. Hence, add a fuse mapping table for bengal to allow for per-chip frequency limiting. Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Akhil P Oommen <quic_akhilpo@quicinc.com> Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/542780/Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Konrad Dybcio authored
A619_holi is implemented on at least two SoCs: SM4350 (holi) and SM6375 (blair). This is what seems to be a first occurrence of this happening, but it's easy to overcome by guarding the SoC-specific fuse values with of_machine_is_compatible(). Do just that to enable frequency limiting on these SoCs. Reviewed-by:
-
Konrad Dybcio authored
Before transitioning to using per-SoC and not per-Adreno speedbin fuse values (need another patchset to land elsewhere), a good improvement/stopgap solution is to use adreno_is_aXYZ macros in place of explicit revision matching. Do so to allow differentiating between A619 and A619_holi. Reviewed-by:
-
Konrad Dybcio authored
The GPU can only be one at a time. Turn a series of ifs into if + elseifs to save some CPU cycles. Reviewed-by:
-
Konrad Dybcio authored
Adreno 619 expects some tunables to be set differently. Make up for it. Fixes: b7616b5c ("drm/msm/adreno: Add A619 support") Reviewed-by:
-
Konrad Dybcio authored
A610 is one of (if not the) lowest-tier SKUs in the A6XX family. It features no GMU, as it's implemented solely on SoCs with SMD_RPM. What's more interesting is that it does not feature a VDDGX line either, being powered solely by VDDCX and has an unfortunate hardware quirk that makes its reset line broken - after a couple of assert/ deassert cycles, it will hang for good and will not wake up again. This GPU requires mesa changes for proper rendering, and lots of them at that. The command streams are quite far away from any other A6XX GPU and hence it needs special care. This patch was validated both by running an (incomplete) downstream mesa with some hacks (frames rendered correctly, though some instructions made the GPU hangcheck which is expected - garbage in, garbage out) and by replaying RD traces captured with the downstream KGSL driver - no crashes there, ever. Add support for this GPU on the kernel side, which comes down to pretty simply adding A612 HWCG tables, altering a few values and adding a special case for handling the reset line. Reviewed-by:
-
Konrad Dybcio authored
A619_holi is a GMU-less variant of the already-supported A619 GPU. It's present on at least SM4350 (holi) and SM6375 (blair). No mesa changes are required. Add the required kernel-side support for it. Signed-off-by:
-
Konrad Dybcio authored
A610 and A619_holi don't support the feature. Disable it to make the GPU stop crashing after almost each and every submission - the received data on the GPU end was simply incomplete in garbled, resulting in almost nothing being executed properly. Extend the disablement to adreno_has_gmu_wrapper, as none of the GMU wrapper Adrenos that don't support yet seem to feature it. Reviewed-by:
-
Konrad Dybcio authored
Some (particularly SMD_RPM, a.k.a non-RPMh) SoCs implement A6XX GPUs but don't implement the associated GMUs. This is due to the fact that the GMU directly pokes at RPMh. Sadly, this means we have to take care of enabling & scaling power rails, clocks and bandwidth ourselves. Reuse existing Adreno-common code and modify the deeply-GMU-infused A6XX code to facilitate these GPUs. This involves if-ing out lots of GMU callbacks and introducing a new type of GMU - GMU wrapper (it's the actual name that Qualcomm uses in their downstream kernels). This is essentially a register region which is convenient to model as a device. We'll use it for managing the GDSCs. The register layout matches the actual GMU_CX/GX regions on the "real GMU" devices and lets us reuse quite a bit of gmu_read/write/rmw calls. Signed-off-by:
-
Konrad Dybcio authored
Since the introduction of A6xx support, we've been enabling the CX GMU power counter 0 in a bit of a weird spot. Move it to hw_init so that GMU wrapper GPUs can reuse the same code paths. As a bonus, this order makes it easier to compare mainline and downstream register access traces. Signed-off-by:
-
Konrad Dybcio authored
Rename lower_bit to hbb_lo and explain what it signifies. Add explanations (wherever possible to other tunables). Port setting min_access_length, ubwc_mode and hbb_hi from downstream. Reviewed-by:
Rob Clark <robdclark@gmail.com> Reviewed-by:
-
Konrad Dybcio authored
Currently we're only deasserting REG_A6XX_RBBM_GBIF_HALT, but we also need REG_A6XX_GBIF_HALT to be set to 0. This is typically done automatically on successful GX collapse, but in case that fails, we should take care of it. Also, add a memory barrier to ensure it's gone through before jumping to further initialization. Reviewed-by:
-
