- 03 Jun, 2021 13 commits
-
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c:77: warning: expecting prototype for Start hdmi phy macro cell tx3g4c28(). Prototype was for sti_hdmi_tx3g4c28phy_start() instead drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c:187: warning: expecting prototype for Stop hdmi phy macro cell tx3g4c28(). Prototype was for sti_hdmi_tx3g4c28phy_stop() instead Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210602143300.2330146-6-lee.jones@linaro.org
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/mediatek/mtk_disp_rdma.c:72: warning: Function parameter or member 'clk' not described in 'mtk_disp_rdma' drivers/gpu/drm/mediatek/mtk_disp_rdma.c:72: warning: Function parameter or member 'regs' not described in 'mtk_disp_rdma' drivers/gpu/drm/mediatek/mtk_disp_rdma.c:72: warning: Function parameter or member 'cmdq_reg' not described in 'mtk_disp_rdma' drivers/gpu/drm/mediatek/mtk_disp_rdma.c:72: warning: Function parameter or member 'vblank_cb' not described in 'mtk_disp_rdma' drivers/gpu/drm/mediatek/mtk_disp_rdma.c:72: warning: Function parameter or member 'vblank_cb_data' not described in 'mtk_disp_rdma' drivers/gpu/drm/mediatek/mtk_disp_rdma.c:72: warning: Function parameter or member 'fifo_size' not described in 'mtk_disp_rdma' Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-mediatek@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/mediatek/mtk_disp_ovl.c:83: warning: Function parameter or member 'clk' not described in 'mtk_disp_ovl' drivers/gpu/drm/mediatek/mtk_disp_ovl.c:83: warning: Function parameter or member 'regs' not described in 'mtk_disp_ovl' drivers/gpu/drm/mediatek/mtk_disp_ovl.c:83: warning: Function parameter or member 'cmdq_reg' not described in 'mtk_disp_ovl' drivers/gpu/drm/mediatek/mtk_disp_ovl.c:83: warning: Function parameter or member 'vblank_cb' not described in 'mtk_disp_ovl' drivers/gpu/drm/mediatek/mtk_disp_ovl.c:83: warning: Function parameter or member 'vblank_cb_data' not described in 'mtk_disp_ovl' Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-mediatek@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/mediatek/mtk_disp_gamma.c:42: warning: Function parameter or member 'clk' not described in 'mtk_disp_gamma' drivers/gpu/drm/mediatek/mtk_disp_gamma.c:42: warning: Function parameter or member 'regs' not described in 'mtk_disp_gamma' drivers/gpu/drm/mediatek/mtk_disp_gamma.c:42: warning: Function parameter or member 'cmdq_reg' not described in 'mtk_disp_gamma' drivers/gpu/drm/mediatek/mtk_disp_gamma.c:42: warning: Function parameter or member 'data' not described in 'mtk_disp_gamma' Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-mediatek@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/mediatek/mtk_disp_color.c:45: warning: Function parameter or member 'clk' not described in 'mtk_disp_color' drivers/gpu/drm/mediatek/mtk_disp_color.c:45: warning: Function parameter or member 'regs' not described in 'mtk_disp_color' drivers/gpu/drm/mediatek/mtk_disp_color.c:45: warning: Function parameter or member 'cmdq_reg' not described in 'mtk_disp_color' Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-mediatek@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by:
-
Kees Cook authored
Avoid randconfig build failures by requiring VEXPRESS_CONFIG: aarch64-linux-gnu-ld: drivers/gpu/drm/pl111/pl111_versatile.o: in function `pl111_vexpress_clcd_init': pl111_versatile.c:(.text+0x220): undefined reference to `devm_regmap_init_vexpress_config' Fixes: 826fc86b ("drm: pl111: Move VExpress setup into versatile init") Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Arnd Bergmann authored
When LLCC support is in a loadable module, the adreno support cannot be built-in: aarch64-linux-ld: drivers/gpu/drm/msm/adreno/a6xx_gpu.o: in function `a6xx_gpu_init': a6xx_gpu.c:(.text+0xe0): undefined reference to `llcc_slice_getd' a6xx_gpu.c:(.text+0xe0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `llcc_slice_getd' aarch64-linux-ld: a6xx_gpu.c:(.text+0xec): undefined reference to `llcc_slice_getd' a6xx_gpu.c:(.text+0xec): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `llcc_slice_getd' aarch64-linux-ld: drivers/gpu/drm/msm/adreno/a6xx_gpu.o: in function `a6xx_destroy': a6xx_gpu.c:(.text+0x274): undefined reference to `llcc_slice_putd' a6xx_gpu.c:(.text+0x274): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `llcc_slice_putd' aarch64-linux-ld: a6xx_gpu.c:(.text+0x27c): undefined reference to `llcc_slice_putd' Add a Kconfig dependency that disallows the broken configuration but allows all working ones. Fixes: 474dadb8 ("drm/msm/a6xx: Add support for using system cache(LLC)") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Signed-off-by:
-
Kees Cook authored
When cleaning up other drm config dependencies, it is too easy to create larger problems. Instead, mark CONFIG_FB as a "depends": drivers/gpu/drm/Kconfig:74:error: recursive dependency detected! Suggested-by:
Arnd Bergmann <arnd@kernel.org> Link: https://lore.kernel.org/lkml/CAK8P3a3jUQs6c5tESSNMbqfuymewj9FhqRizyHcfOXf8Rgy-nA@mail.gmail.com/Signed-off-by:
-
Zhen Lei authored
Use DEVICE_ATTR_RO helper instead of plain DEVICE_ATTR, which makes the code a bit shorter and easier to read. Signed-off-by:
Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by:
-
lijian authored
deleted the repeated word 'be' in the comments. Signed-off-by:
lijian <lijian@yulong.com> Signed-off-by:
-
Alyssa Rosenzweig authored
The hang_limit is the threshold after which the kernel no longer attempts to schedule a job. Its documentation stated the opposite due to a typo. Correct the wording to indicate the actual purpose of the field. Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/vgem/vgem_drv.c:47: warning: expecting prototype for This is vgem, a (non-hardware(). Prototype was for DRIVER_NAME() instead Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: Adam Jackson <ajax@redhat.com> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: dri-devel@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Signed-off-by:
-
Daniel Vetter authored
We have this nice kerneldoc, but forgot to include it. Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Link: https://patchwork.freedesktop.org/patch/msgid/20210521082457.1656333-1-daniel.vetter@ffwll.ch
-
- 02 Jun, 2021 1 commit
-
-
Christian König authored
When we want to decouble resource management from buffer management we need to be able to handle resources separately. Add a resource pointer and rename bo->mem so that all code needs to change to access the pointer instead. No functional change. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210430092508.60710-4-christian.koenig@amd.com
-
- 01 Jun, 2021 1 commit
-
-
Paul Cercueil authored
The backing memory does not necessarily have the writecombine attribute set, since commit cf8ccbc7 ("drm: Add support for GEM buffers backed by non-coherent memory"). Fixes: cf8ccbc7 ("drm: Add support for GEM buffers backed by non-coherent memory") Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Acked-by:
-
- 31 May, 2021 5 commits
-
-
Simon Ser authored
The kernel versions including the following commits are referenced: DRM_CLIENT_CAP_STEREO_3D 61d8e328 ("drm: Add a STEREO_3D capability to the SET_CLIENT_CAP ioctl") DRM_CLIENT_CAP_UNIVERSAL_PLANES 681e7ec7 ("drm: Allow userspace to ask for universal plane list (v2)") c7dbc6c9 ("drm: Remove command line guard for universal planes") DRM_CLIENT_CAP_ATOMIC 88a48e29 ("drm: add atomic properties") 8b72ce15 ("drm: Always enable atomic API") DRM_CLIENT_CAP_ASPECT_RATIO 7595bda2 ("drm: Add DRM client cap for aspect-ratio") DRM_CLIENT_CAP_WRITEBACK_CONNECTORS d67b6a20 ("drm: writeback: Add client capability for exposing writeback connectors") Signed-off-by:
Simon Ser <contact@emersion.fr> Reviewed-by:
Daniel Stone <daniels@collabora.com> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/434202/
-
Simon Ser authored
Make it clear that the client is responsible for enabling ATOMIC prior to enabling WRITEBACK_CONNECTORS. Linkify the reference to ATOMIC. Signed-off-by:
-
Simon Ser authored
In the docs for DRM_CLIENT_CAP_STEREO_3D and DRM_CLIENT_CAP_ASPECT_RATIO, reference the DRM_MODE_FLAG_* defines that get set when the cap is enabled. Signed-off-by:
-
Yu Kuai authored
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
-
Linus Walleij authored
The Lontium bridge is including legacy header files for GPIO but not using them. Delete the includes. Cc: Adrien Grassein <adrien.grassein@gmail.com> Cc: Robert Foss <robert.foss@linaro.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Adren Grassein <adrien.grassein@gmail.com> Signed-off-by:
-
- 28 May, 2021 15 commits
-
-
Johan Jonker authored
To reduce memory various Rockchip VOP versions share common reg structures. However more recent added SoCs not always have to same futures as the old ones. Add PX30 missing version info, so all VOP version checks work correct if needed in the future. Signed-off-by:
Johan Jonker <jbx6244@gmail.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210131125016.10837-1-jbx6244@gmail.com
-
Colin Ian King authored
The variable bit_per_pix is a u8 and is promoted in the multiplication to an int type and then sign extended to a u64. If the result of the int multiplication is greater than 0x7fffffff then the upper 32 bits will be set to 1 as a result of the sign extension. Avoid this by casting tu_size_reg to u64 to avoid sign extension and also a potential overflow. Fixes: 1a0f7ed3 ("drm/rockchip: cdn-dp: add cdn DP support for rk3399") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Guenter Roeck <groeck@chromium.org> Signed-off-by:
-
Christophe JAILLET authored
'ret' is know to be 0 a this point. Checking the return value of 'phy_init()' and 'phy_set_mode()' was intended instead. So add the missing assignments. Fixes: cca1705c ("drm/rockchip: lvds: Add PX30 support") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Jiapeng Chong authored
Fix the following clang warning: drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c:320:20: warning: unused function 'dsi_set' [-Wunused-function]. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
Thomas Hebb authored
commit cf6d100d ("drm/rockchip: dsi: add dual mipi support") added this devcnt field and call to component_del(). However, these both appear to be erroneous changes left over from an earlier version of the patch. In the version merged, nothing ever modifies devcnt, meaning component_del() runs unconditionally and in addition to the component_del() calls in dw_mipi_dsi_rockchip_host_detach(). The second call fails to delete anything and produces a warning in dmesg. If we look at the previous version of the patch[1], however, we see that it had logic to calculate devcnt and call component_add() in certain situations. This was removed in v6, and the fact that the deletion code was not appears to have been an oversight. [1] https://patchwork.kernel.org/project/dri-devel/patch/20180821140515.22246-8-heiko@sntech.de/ Fixes: cf6d100d ("drm/rockchip: dsi: add dual mipi support") Cc: stable@vger.kernel.org Signed-off-by:
Thomas Hebb <tommyhebb@gmail.com> Signed-off-by:
-
Thomas Hebb authored
When we first enable the DSI encoder, we currently program some per-chip configuration that we look up in rk3399_chip_data based on the device tree compatible we match. This data configures various parameters of the MIPI lanes, including on RK3399 whether DSI1 is slaved to DSI0 in a dual-mode configuration. It also selects which LCDC (i.e. VOP) to scan out from. This causes a problem in RK3399 dual-mode configurations, though: panel prepare() callbacks run before the encoder gets enabled and expect to be able to write commands to the DSI bus, but the bus isn't fully functional until the lane and master/slave configuration have been programmed. As a result, dual-mode panels (and possibly others too) fail to turn on when the rockchipdrm driver is initially loaded. Because the LCDC mux is the only thing we don't know until enable time (and is the only thing that can ever change), we can actually move most of the initialization to bind() and get it out of the way early. That's what this change does. (Rockchip's 4.4 BSP kernel does it in mode_set(), which also avoids the issue, but bind() seems like the more correct place to me.) Tested on a Google Scarlet board (Acer Chromebook Tab 10), which has a Kingdisplay KD097D04 dual-mode panel. Prior to this change, the panel's backlight would turn on but no image would appear when initially loading rockchipdrm. If I kept rockchipdrm loaded and reloaded the panel driver, it would come on. With this change, the panel successfully turns on during initial rockchipdrm load as expected. Fixes: 2d4f7bda ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver") Signed-off-by:
Jonathan Liu <net147@gmail.com> Signed-off-by:
-
Peter Robinson authored
The CDP DP component of the rockchip GPU driver requires firmware so define MODULE_FIRMWARE for rockchip/dptx.bin so the details are available in the module info. Signed-off-by:
Peter Robinson <pbrobinson@gmail.com> Signed-off-by:
-
Yang Yingliang authored
After calling clk_prepare_enable(), clk_disable_unprepare() need be called when calling regmap_write() failed. Fixes: 1a0f7ed3 ("drm/rockchip: cdn-dp: add cdn DP support for rk3399") Reported-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
Alex Bee authored
alpha_en should be set to 0 if it is not used, i.e. to disable alpha blending if it was enabled before and should be disabled now. Fixes: 2aae8ed1 ("drm/rockchip: Add per-pixel alpha support for the PX30 VOP") Signed-off-by:
Alex Bee <knaerzche@gmail.com> Signed-off-by:
-
Alex Bee authored
With commit 2aae8ed1 ("drm/rockchip: Add per-pixel alpha support for the PX30 VOP") alpha support was introduced for PX30's VOP. RK3036, RK3066, RK3126 and RK3188 VOPs support alpha blending in the same manner. With the exception of RK3066 all of them support pre-multiplied alpha. Signed-off-by:
-
Alex Bee authored
Add dither_up, dsp_lut_en and data_blank registers to enable their respective functionality for RK3066's VOP. While at that also fix .rb_swap and .format registers for all windows, which have to be set though RK3066_SYS_CTRL1 register. Also remove .scl from win1: Scaling is only supported on the primary plane. Signed-off-by:
-
Alex Bee authored
Add dither_up, dsp_lut_en and data_blank registers to enable their respective functionality for RK3188's VOP. While at that also fix .dsp_blank register which is (only) set with BIT24 (same as RK3066) Signed-off-by:
-
Alex Bee authored
Add the registers needed to make scaling work on RK3036's win1. Signed-off-by:
-
Javier Martinez Canillas authored
There are drivers that register framebuffer devices very early in the boot process and make use of the existing framebuffer as setup by the firmware. If one of those drivers has registered a fbdev, then the fallback fbdev of the DRM driver won't be bound to the framebuffer console. To avoid that, remove any existing generic driver and take over the graphics device. By doing that, the fb mapped to the console is switched correctly from the early fbdev to the one registered by the rockchip DRM driver: [ 40.752420] fb0: switching to rockchip-drm-fb from EFI VGA Signed-off-by:Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Tested-by:
-
Paul Cercueil authored
The previous commit wrongly assumed that dma_mmap_wc() could be replaced by pgprot_writecombine() + dma_mmap_pages(). It did work on my setup, but did not work everywhere. Use dma_mmap_wc() when the buffer has the write-combine cache attribute, and dma_mmap_pages() when it has the non-coherent cache attribute. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by:
-
- 27 May, 2021 5 commits
-
-
Nikola Cornij authored
[why] Link rate in kHz is what is eventually required to calculate the link bandwidth, which makes kHz a more generic unit. This should also make forward-compatibility with new DP standards easier. [how] - Replace 'link rate DPCD code' with 'link rate in kHz' when used with drm_dp_mst_topology_mgr_init() - Add/remove related DPCD code conversion from/to kHz where applicable Signed-off-by:
Nikola Cornij <nikola.cornij@amd.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Maxime Ripard authored
i915 is broken without -rc3, let's bring that tag in to fix it. Signed-off-by:Maxime Ripard <maxime@cerno.tech>
-
Geert Uytterhoeven authored
The ChromeOS EC ANX7688 bridge is connected to a ChromeOS Embedded Controller, and is accessed using I2C tunneling through the Embedded Controller. Hence add a dependency on I2C_CROS_EC_TUNNEL, to prevent asking the user about this driver when configuring a kernel without support for the ChromeOS EC tunnel I2C bus. Fixes: 44602b10 ("drm/bridge: Add ChromeOS EC ANX7688 bridge driver support") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
-
Zou Wei authored
./drivers/gpu/drm/bridge/lontium-lt8912b.c:758:3-8: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Reported-by:
Zou Wei <zou_wei@huawei.com> Reviewed-by:
-
Jiapeng Chong authored
Eliminate the follow smatch warning: drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:2143 cdns_mhdp_bridge_atomic_reset() warn: inconsistent indenting. Reported-by:
-
