- 27 Mar, 2023 4 commits
-
-
Bjorn Andersson authored
This panel is found in Lenovo Flex 5G laptop, so add the entry for it Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Vinod Koul <vkoul@kernel.org> Acked-by:
Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Dan Carpenter authored
Don't dereference "db->dsi_dev" when it is an error pointer. Fixes: 249a4f5e ("drm/panel: Add Magnachip D53E6EA8966 Panel Driver") Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/de0273a8-8910-4ac4-b4ed-f7691c4d2ca6@kili.mountain
-
Caio Novais authored
Compiling AMD GPU drivers displays two warnings: drivers/gpu/drm/scheduler/sched_main.c:738: warning: Function parameter or member 'file' not described in 'drm_sched_job_add_syncobj_dependency' drivers/gpu/drm/scheduler/sched_main.c:738: warning: Excess function parameter 'file_private' description in 'drm_sched_job_add_syncobj_dependency' Get rid of them by renaming the variable name on the function description Signed-off-by:
Caio Novais <caionovais@usp.br> Link: https://lore.kernel.org/r/20230325131532.6356-1-caionovais@usp.brReviewed-by:
Luben Tuikov <luben.tuikov@amd.com> Signed-off-by:
-
Hsin-Yi Wang authored
There are 2 banks on it6505, and when writing to different bank, REG_BANK_SEL needs to be set to the targeted bank. The current code set this additionally, which causes a race condition when a process is writing bank 0 registers while another process set the bank to 1. Set ranges in regmap config so the regmap API would handle the bank changes. Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by:
-
- 24 Mar, 2023 2 commits
-
-
Rob Herring authored
Cleanup bindings dropping unneeded quotes. Once all these are fixed, checking for this can be enabled in yamllint. Reviewed-by:
Chun-Kuang Hu <chunkuang.hu@kernel.org> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by:
Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> #display/msm Link: https://lore.kernel.org/r/20230320233823.2919475-1-robh@kernel.orgSigned-off-by:
Rob Herring <robh@kernel.org>
-
Pin-yen Lin authored
drm_edid_read returns NULL on error, so feeding it directly into drm_edid_duplicate may lead to NULL pointer dereference. Add a check to guard this. Fixes: 6a17b4d1 ("drm/bridge: ps8640: Add a cache for EDID") Signed-off-by:
Pin-yen Lin <treapking@chromium.org> Signed-off-by:
-
- 23 Mar, 2023 14 commits
-
-
Pin-yen Lin authored
When there are multiple EDID reads, the bridge will be repeatedly enabled and disabled. Add a cache for EDID to speed this up. Signed-off-by:
Robert Foss <rfoss@kernel.org> Reviewed-by:
-
Pin-yen Lin authored
Skip the drm_bridge_chain_pre_enable call when the bridge is already pre_enabled. This make pre_enable and post_disable (thus pm_runtime_get/put) symmetric. Fixes: 46f20630 ("drm/bridge: ps8640: Rework power state handling") Signed-off-by:
-
AngeloGioacchino Del Regno authored
MediaTek MT8186 has a Mali-G52 MC2 2EE (Bifrost): add a new compatible and platform data using the same supplies list as "mt8183_b" (only one regulator), and a new pm_domains list with only two power domains. Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by:
Steven Price <steven.price@arm.com> Reviewed-by:
Chen-Yu Tsai <wenst@chromium.org> Tested-by:
Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316102041.210269-13-angelogioacchino.delregno@collabora.com
-
AngeloGioacchino Del Regno authored
The "mediatek,mt8183-mali" compatible uses platform data that calls for getting (and managing) two regulators ("mali" and "sram") but devfreq does not support this usecase, resulting in DVFS not working. Since a lot of MediaTek SoCs need to set the voltages for the GPU SRAM regulator in a specific relation to the GPU VCORE regulator, a MediaTek SoC specific driver was introduced to automatically satisfy, through coupling, these constraints: this means that there is at all no need to manage both regulators in panfrost but to otherwise just manage the main "mali" (-> gpu vcore) regulator instead. Keeping in mind that we cannot break the ABI, the most sensible route (avoiding hacks and uselessly overcomplicated code) to get a MT8183 node with one power supply was to add a new "mediatek,mt8183b-mali" compatible, which effectively deprecates the former. Signed-off-by: -
Alyssa Rosenzweig authored
Required for Mali-G57 on the Mediatek MT8192 and MT8195, which uses even more power domains than the MT8183 before it. Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> [Angelo: Removed unneeded "sram" supply, added mt8195 to commit description] Co-developed-by:
-
Alyssa Rosenzweig authored
MediaTek MT8192 has a Mali-G57 with a special GPU ID. Add its GPU ID, but treat it as otherwise identical to a standard Mali-G57. We do _not_ fix up the GPU ID here -- userspace needs to be aware of the special GPU ID, in case we find functional differences between MediaTek's implementation and the standard Mali-G57 down the line. Signed-off-by:
-
Alyssa Rosenzweig authored
Increase the MAX_PM_DOMAINS constant from 3 to 5, to support the extra power domains required by the Mali-G57 on the MT8192. Signed-off-by:
-
AngeloGioacchino Del Regno authored
The MediaTek MT8195 SoC has a Mali G57 MC5 (Valhall-JM) and has the same number of power domains and requirements as MT8192 in terms of bindings. Signed-off-by:
-
AngeloGioacchino Del Regno authored
MT8186 has a Mali-G52 MC2 2EE GPU (two cores): add a binding with two power domains (one per core) for it. Signed-off-by:
-
AngeloGioacchino Del Regno authored
Since new platform data was required in Panfrost for getting GPU DVFS finally working on MediaTek SoCs, add a new "mediatek,mt8183b-mali" compatible. Signed-off-by:
-
AngeloGioacchino Del Regno authored
MediaTek MT8192 (and similar) needs five power domains for the Mali GPU and no sram-supply: change the binding to allow so by also introducing power-domain-names in the generic binding; while at it, also disallow the newly introduced power-domain-names for all non-MediaTek bindings. Fixes: 5d82e74a ("dt-bindings: Add compatible for Mali Valhall (JM)") Signed-off-by:
-
AngeloGioacchino Del Regno authored
Commit ("dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183") incorrectly introduced power domain names for MT8183, causing validation issues. Add power-domain-names to the base schema, allowing a maximum of five elements; since platforms having a single power domain don't need any actual domain name, disallow that for each sub-schema. Fixes: a7a596cd ("dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183") Signed-off-by: -
AngeloGioacchino Del Regno authored
In preparation for adding (and fixing) power-domain-names and MediaTek MT8192 bindings, allow up to five items for power-domains. Signed-off-by:
-
AngeloGioacchino Del Regno authored
In preparation for adding new bindings for new MediaTek SoCs, split out the power-domains variation from the `else` in the current mediatek,mt8183-mali conditional. The sram-supply part is left in place to be disallowed for anything that is not compatible with "mediatek,mt8183-mali" as this regulator is MediaTek-specific and it is, and will ever be, used only for this specific string due to the addition of the mediatek-regulator-coupler driver. Signed-off-by:
-
- 22 Mar, 2023 14 commits
-
-
Alfredo Cruz authored
devm_regmap_init_mmio() may return an invalid pointer in case of an error. This patch adds the corresponding IS_ERR check to vop2->map. Signed-off-by:
Alfredo Cruz <alfredo.carlon@gmail.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230322224411.15612-1-alfredo.carlon@gmail.com
-
Toby Chen authored
This fixes a use-after-free crash during rmmod. The DRM encoder is embedded inside the larger rockchip_hdmi, which is allocated with the component. The component memory gets freed before the main drm device is destroyed. Fix it by running encoder cleanup before tearing down its container. Signed-off-by:
Toby Chen <tobyc@nvidia.com> [moved encoder cleanup above clk_disable, similar to bind-error-path] Signed-off-by:
-
Tom Rix authored
clang reportes this error drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2322:8: error: variable 'possible_crtcs' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if (vp) { ^~ drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2336:36: note: uninitialized use occurs here ret = vop2_plane_init(vop2, win, possible_crtcs); ^~~~~~~~~~~~~~ drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2322:4: note: remove the 'if' if its condition is always true if (vp) { ^~~~~~~~ The else-statement changes the win->type to OVERLAY without setting the possible_crtcs variable. Rework the block, initialize possible_crtcs to 0 to remove the else-statement. Split the else-if-statement out to its own if-statement so the OVERLAY check will catch when the win-type has been changed. Fixes: 368419a2 ("drm/rockchip: vop2: initialize possible_crtcs properly") Signed-off-by:Tom Rix <trix@redhat.com> Acked-by:
Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by:
-
Thomas Zimmermann authored
Rename symbols to match the style of other fbdev-emulation source code. No functional changes. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
Zack Rusin <zackr@vmware.com> Tested-by:
Sui Jingfeng <suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230320150751.20399-9-tzimmermann@suse.de
-
Thomas Zimmermann authored
Consolidate all handling of CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM by making the module parameter optional in drm_fb_helper.c. Without the config option, modules can set smem_start in struct fb_info for internal usage, but not export if to userspace. The address can only be exported by enabling the option and setting the module parameter. Also update the comment. Signed-off-by:
-
Thomas Zimmermann authored
Clean up fbdev and client state if the probe function fails. It used to leak allocated resources. Also reorder the individual steps to simplify cleanup. v2: * move screen_size update into separate patches Signed-off-by:
-
Thomas Zimmermann authored
The size of the screen memory should be equivalent to the size of the screen's GEM buffer. Don't recalculate the value. Signed-off-by:
-
Thomas Zimmermann authored
The size of the framebuffer can either be stored in screen_info or smem_len. Take both into account in the deferred I/O code. Signed-off-by:
-
Thomas Zimmermann authored
Export the fb_info release code as drm_fb_helper_release_info(). Will help with cleaning up failed fbdev probing. Signed-off-by:
-
Thomas Zimmermann authored
Remove the flag prefer_shadow_fbdev from struct drm_mode_config. Drivers set this flag to enable shadow buffering in the generic fbdev emulation. Such shadow buffering is now mandatory, so the flag is unused. Signed-off-by:
-
Thomas Zimmermann authored
Remove all codepaths that implement fbdev output directly on GEM buffers. Always allocate a shadow buffer in system memory and set up deferred I/O for mmap. The fbdev code that operated directly on GEM buffers was used by drivers based on GEM DMA helpers. Those drivers have been migrated to use fbdev-dma, a dedicated fbdev emulation for DMA memory. All remaining users of fbdev-generic require shadow buffering. Memory management of the remaining callers uses TTM, GEM SHMEM helpers or a variant of GEM DMA helpers that is incompatible with fbdev-dma. Therefore remove the unused codepaths from fbdev-generic and simplify the code. Using a shadow buffer with deferred I/O is probably the best case for most remaining callers. Some of the TTM-based drivers might benefit from a dedicated fbdev emulation that operates directly on the driver's video memory. Signed-off-by:
-
Ye Xingchen authored
Replace the open-code with dev_err_probe() to simplify the code. Signed-off-by:
Ye Xingchen <ye.xingchen@zte.com.cn> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Ye Xingchen authored
Replace the open-code with dev_err_probe() to simplify the code. Signed-off-by:
-
Christian König authored
Not used by any drivers any more, the only use case in drm_dev_init() can be inlined now. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316082035.567520-2-christian.koenig@amd.com
-
- 21 Mar, 2023 2 commits
-
-
Maíra Canal authored
As lima_gem_add_deps() performs the same steps as drm_sched_job_add_syncobj_dependency(), replace the open-coded implementation in Lima in order to simply use the DRM function. Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Qiang Yu <yuq825@gmail.com> Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230224214133.411966-1-mcanal@igalia.com
-
Tom Rix authored
clang with W=1 reports drivers/gpu/drm/gma500/psb_irq.c:35:19: error: unused function 'gma_pipe_event' [-Werror,-Wunused-function] static inline u32 gma_pipe_event(int pipe) ^ This function is not used, so remove it. Signed-off-by:Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230319142320.1704336-1-trix@redhat.com
-
- 20 Mar, 2023 4 commits
-
-
Maíra Canal authored
Commit 45d9c8dd ("drm/vgem: use shmem helpers") introduced shmem helpers to vgem and with that, removed all uses of the struct drm_vgem_gem_object. So, as the struct is no longer used, delete it. Signed-off-by:
Melissa Wen <mwen@igalia.com> Signed-off-by:
-
Petr Tesarik authored
The DRM device passed to drm_gem_prime_fd_to_handle() is where the dma-buf is being imported, not the device where it was exported. Also fix a trivial typo in drm_gem_prime_import_dev(). Signed-off-by:
Petr Tesarik <petr.tesarik.ext@huawei.com> Reviewed-by:
Simon Ser <contact@emersion.fr> Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
