- 29 Mar, 2023 6 commits
-
-
Krzysztof Kozlowski authored
Allow 'rotation' property (coming from panel-common.yaml) already used in DTS: sc7180-trogdor-quackingstick-r0.dtb: panel@0: 'rotation' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20230326155425.91181-6-krzysztof.kozlowski@linaro.orgSigned-off-by:
Rob Herring <robh@kernel.org>
-
Krzysztof Kozlowski authored
Panels are supposed to have one reg. This fixes dtbs_check warnings like: sc7180-idp.dtb: panel@0: 'reg' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by:
-
Krzysztof Kozlowski authored
Panels are supposed to have one port (coming from panel-common.yaml binding): msm8916-samsung-a3u-eur.dtb: panel@0: 'port' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by:
-
Krzysztof Kozlowski authored
Few panels like Samsung s6e3fc2x01 and sofef00 use vddio-supply instead of power-supply (in DTS and Linux driver), so allow it to fix: sdm845-oneplus-enchilada.dtb: panel@0: 'power-supply' is a required property Signed-off-by:
-
Krzysztof Kozlowski authored
The nt36672a bindings were added with a mistake on VDDIO supply calling it in one place vddio and in other vddi0. Typical name is rather vddio which is also now used by DTS (sdm845-xiaomi-beryllium-common.dtsi) and Linux driver. Fixes: c2abcf30 ("dt-bindings: display: novatek,nt36672a: Fix unevaluated properties warning") Fixes: 9528a024 ("dt-bindings: display: panel: Add bindings for Novatek nt36672a") Signed-off-by:
-
Krzysztof Kozlowski authored
There is nothing special in Innolux p120zdg-bf1 panel, so just like other Innolux panels it can be made part of panel-simple. Signed-off-by:
-
- 28 Mar, 2023 1 commit
-
-
Rob Herring authored
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when we just want to test for presence of a property and nothing more. Reviewed-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Liu Ying <victor.liu@nxp.com> # i.MX bridge Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20230310144705.1542207-1-robh@kernel.orgSigned-off-by:
-
- 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:
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:
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:
-
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 13 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:
-
Ye Xingchen authored
Replace the open-code with dev_err_probe() to simplify the code. Signed-off-by:
-
