- 03 May, 2022 1 commit
-
-
Sascha Hauer authored
The VOP2 driver needs rockchip specific information for a drm_encoder. This patch creates a struct rockchip_encoder with a struct drm_encoder embedded in it. This is used throughout the rockchip driver instead of struct drm_encoder directly. The information the VOP2 drivers needs is the of_graph endpoint node of the encoder. To ease bisectability this is added here. While at it convert the different encoder-to-driverdata macros to static inline functions in order to gain type safety and readability. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Tested-by:
Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-3-s.hauer@pengutronix.de
-
- 02 May, 2022 15 commits
-
-
Chen-Yu Tsai authored
The VOP in Rockchip SoCs that support YUV planes also support swapping of the U and V elements. Supporting the swapped variants, especially NV21, would be beneficial for multimedia applications, as the hardware video decoders only output NV21, and supporting this pixel format in the display pipeline would allow the decoded video frames to be output directly. Add support for this to support the various formats that have U/V swapped. Signed-off-by:
Chen-Yu Tsai <wenst@chromium.org> Signed-off-by:
-
José Expósito authored
Once EDID is parsed, the monitor HDMI support information is available through drm_display_info.is_hdmi. This driver calls drm_detect_hdmi_monitor() to receive the same information and stores its own cached value, which is less efficient. Avoid calling drm_detect_hdmi_monitor() and use drm_display_info.is_hdmi instead and also remove hdmi_data_info.sink_is_hdmi as it is no longer necessary. Signed-off-by:
José Expósito <jose.exposito89@gmail.com> Signed-off-by:
-
José Expósito authored
Once EDID is parsed, the monitor HDMI support information is available through drm_display_info.is_hdmi. This driver calls drm_detect_hdmi_monitor() to receive the same information and stores its own cached value, which is less efficient. Avoid calling drm_detect_hdmi_monitor() and use drm_display_info.is_hdmi instead and also remove hdmi_data_info.sink_is_hdmi as it is no longer necessary. Signed-off-by:
-
Tom Rix authored
Smatch reports this issue cdn-dp-core.c:51:20: warning: symbol 'rk3399_cdn_dp' was not declared. Should it be static? rk3399_cdn_dp is only used in cdn-dp-core.c so change its storge-class specifier to static. Signed-off-by:
Tom Rix <trix@redhat.com> Signed-off-by:
-
Robin Murphy authored
Defer the IOMMU domain setup until after successfully binding components, so we can figure out IOMMU support directly from the VOP devices themselves, rather than manually inferring it from the DT (which also fails to account for whether the IOMMU driver is actually loaded). Although this is somewhat of a logical cleanup, the main motivation is to prepare for a change in the iommu_domain_alloc() interface. Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
-
Yang Yingliang authored
It will cause null-ptr-deref in resource_size(), if platform_get_resource() returns NULL, move calling resource_size() after devm_ioremap_resource() that will check 'res' to avoid null-ptr-deref. Fixes: 2048e328 ("drm: rockchip: Add basic drm driver") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
Uwe Kleine-König authored
tfp410_fini() always returns zero. Make it return no value which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and platform driver remove callbacks is ignored anyway. This prepares making i2c and platform remove callbacks return void, too. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220428162803.185275-1-u.kleine-koenig@pengutronix.de
-
Marek Vasut authored
The i.MX8MP contains two syscon registers which are responsible for configuring the on-SoC DPI-to-LVDS serializer. Implement a simple bridge driver for this serializer. -- - Add sentinel of_device_table - Add RB from Sam - Rename to fsl-ldb altogether Reviewed-by:Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Peng Fan <peng.fan@nxp.com> Cc: Robby Cai <robby.cai@nxp.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> To: dri-devel@lists.freedesktop.org V2: - Rename syscon to fsl,syscon V3: - Consistently use MX8MP V4: - Fix MODULE_DESCRIPTION to also use MX8MP Signed-off-by:
-
Marek Vasut authored
The i.MX8MP contains two syscon registers which are responsible for configuring the on-SoC DPI-to-LVDS serializer. Add DT binding which represents this serializer as a bridge. Acked-by:
-
Alvin Šipraga authored
The ADV7511 family of bridges supports two modes for CEC RX: legacy and non-legacy mode. The only difference is whether the chip uses a single CEC RX buffer, or uses all three available RX buffers. Currently the adv7511 driver uses legacy mode. While debugging a stall in CEC RX on an ADV7535, we reached out to Analog Devices, who suggested to use non-legacy mode instead. According to the programming guide for the ADV7511 [1], and the register control manual of the ADV7535 [2], this is the default behaviour on reset. As previously stated, the adv7511 driver currently overrides this to legacy mode. This patch updates the adv7511 driver to instead use non-legacy mode with all three CEC RX buffers. As a result of this change, we no longer experience any stalling of CEC RX with the ADV7535. It is not known why non-legacy mode solves this particular issue, but besides this, no functional change is to be expected by this patch. Please note that this has only been tested on an ADV7535. What follows is a brief description of the non-legacy mode interrupt handling behaviour. The programming guide in [1] gives a more detailed explanation. With three RX buffers, the interrupt handler checks the CEC_RX_STATUS register (renamed from CEC_RX_ENABLE in this patch), which contains 2-bit psuedo-timestamps for each of the RX buffers. The RX timestamps for each buffer represent the time of arrival for the CEC frame held in a given buffer, with lower timestamp values indicating chronologically older frames. A special value of 0 indicates that the given RX buffer is inactive and should be skipped. The interrupt handler parses these timestamps and then reads the active RX buffers in the prescribed order using the same logic as before. Changes have been made to ensure that the correct RX buffer is cleared after processing. This clearing procesure also sets the timestamp of the given RX buffer to 0 to mark it as inactive. [1] https://www.analog.com/media/en/technical-documentation/user-guides/ADV7511_Programming_Guide.pdf cf. CEC Map, register 0x4A, bit 3, default value 1: 0 = Use only buffer 0 to store CEC frames (Legacy mode) 1 = Use all 3 buffers to stores the CEC frames (Non-legacy mode) [2] The ADV7535 register control manual is under NDA, but trust me when I say that non-legacy CEC RX mode is the default here too. Here the register is offset by 0x70 and has an address of 0xBA in the DSI_CEC regiser map. Signed-off-by:
Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by:
-
Alvin Šipraga authored
Like the ADV7533, the ADV7535 has an offset for the CEC register map, and it is the same value (ADV7533_REG_CEC_OFFSET = 0x70). Rather than testing for numerous chip types in the offset calculations throughout the driver, just compute it during driver probe and put it in the private adv7511 data structure. Signed-off-by:
-
Pin-Yen Lin authored
Send DPCD SET_POWER command to downstream in .atomic_disable to make the downstream monitor enter the power down mode, so the device suspend won't be affected. Fixes: b5c84a9e ("drm/bridge: add it6505 driver") Signed-off-by:
Pin-Yen Lin <treapking@chromium.org> Signed-off-by:
-
Jagan Teki authored
AM-1280800N3TZQW-T00H panel support 8 bpc not 6 bpc as per recent testing in i.MX8MM platform. Fix it. Fixes: bca684e6 ("drm/panel: simple: Add AM-1280800N3TZQW-T00H") Signed-off-by:
Jagan Teki <jagan@amarulasolutions.com> Reviewed-by:
-
Christian König authored
Instead of manually adjusting the plane state. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220429134230.24334-3-christian.koenig@amd.com
-
Christian König authored
drm_gem_plane_helper_prepare_fb() was using drm_atomic_set_fence_for_plane() which ignores all implicit fences when an explicit fence is already set. That's rather unfortunate when the fb still has a kernel fence we need to wait for to avoid presenting garbage on the screen. So instead update the fence in the plane state directly. While at it also take care of all potential GEM objects and not just the first one. Also remove the now unused drm_atomic_set_fence_for_plane() function, new drivers should probably use the atomic helpers directly. v2: improve kerneldoc, use local variable and num_planes, WARN_ON_ONCE on missing planes. Signed-off-by:Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220429134230.24334-1-christian.koenig@amd.com
-
- 29 Apr, 2022 10 commits
-
-
Heiko Schocher authored
Add Startek KD070WVFPA043-C069A 7" TFT LCD panel support. Signed-off-by:
Heiko Schocher <hs@denx.de> [fabio: passed .flags and .bus_flags] Signed-off-by:
Fabio Estevam <festevam@denx.de> Acked-by:
-
Fabio Estevam authored
Add Startek KD070WVFPA043-C069A 7" TFT LCD panel compatible string. Signed-off-by:
-
Minghao Chi authored
Simplify the return expression. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Reviewed-by:
-
Minghao Chi authored
Simplify the return expression. Reported-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220429090208.3852879-1-chi.minghao@zte.com.cn
-
Minghao Chi authored
Simplify the return expression. Reported-by:
-
Dan Carpenter authored
The "dsi->bus_clk" pointer cannot be an error pointer at this point. The check is confusing and unnecessary. Delete it. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Marek Vasut authored
Per toshiba,tc358767.yaml DT binding document, port@2 the output (e)DP port is optional. In case this port is not described in DT, the bridge driver operates in DPI-to-DP mode. The drm_of_find_panel_or_bridge() call in tc_probe_edp_bridge_endpoint() returns -ENODEV in case port@2 is not present in DT and this specific return value is incorrectly propagated outside of tc_probe_edp_bridge_endpoint() function. All other error values must be propagated and are propagated correctly. Return 0 in case the port@2 is missing instead, that reinstates the original behavior before the commit this patch fixes. Fixes: 8478095a ("drm/bridge: tc358767: Move (e)DP bridge endpoint parsing into dedicated function") Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220428213132.447890-1-marex@denx.de
-
Jani Nikula authored
Drop the kernel-doc for static functions, it's excessive, but retain the info in plain comments. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/20220426091913.1339941-2-jani.nikula@intel.com
-
Jani Nikula authored
Fix the below drm/edid kernel-doc warnings: drivers/gpu/drm/drm_edid.c:1589: warning: Function parameter or member '_edid' not described in 'drm_edid_header_is_valid' drivers/gpu/drm/drm_edid.c:1589: warning: Excess function parameter 'raw_edid' description in 'drm_edid_header_is_valid' drivers/gpu/drm/drm_edid.c:1737: warning: Function parameter or member '_block' not described in 'drm_edid_block_valid' drivers/gpu/drm/drm_edid.c:1737: warning: Excess function parameter 'raw_edid' description in 'drm_edid_block_valid' drivers/gpu/drm/drm_edid.c:2136: warning: Function parameter or member 'read_block' not described in 'drm_do_get_edid' drivers/gpu/drm/drm_edid.c:2136: warning: Function parameter or member 'context' not described in 'drm_do_get_edid' drivers/gpu/drm/drm_edid.c:2136: warning: Excess function parameter 'get_edid_block' description in 'drm_do_get_edid' drivers/gpu/drm/drm_edid.c:2136: warning: Excess function parameter 'data' description in 'drm_do_get_edid' Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> References: https://lore.kernel.org/r/20220406154431.567414c3@canb.auug.org.au References: https://lore.kernel.org/r/20220420162431.2b28ddea@canb.auug.org.auSigned-off-by:
-
Javier Martinez Canillas authored
The DRM_DP_AUX_CHARDEV and DRM_DP_CEC Kconfig symbols enable code that use DP helper functions, that are only present if CONFIG_DRM_DISPLAY_DP_HELPER is also enabled. But these don't select the DRM_DISPLAY_DP_HELPER symbol, meaning that it is possible to enable any of them without CONFIG_DRM_DISPLAY_DP_HELPER. That will lead to the following linking errors with the mentioned config: LD vmlinux.o MODPOST vmlinux.symvers MODINFO modules.builtin.modinfo GEN modules.builtin LD .tmp_vmlinux.kallsyms1 KSYMS .tmp_vmlinux.kallsyms1.S AS .tmp_vmlinux.kallsyms1.S LD .tmp_vmlinux.kallsyms2 KSYMS .tmp_vmlinux.kallsyms2.S AS .tmp_vmlinux.kallsyms2.S LD vmlinux SYSMAP System.map SORTTAB vmlinux OBJCOPY arch/arm64/boot/Image MODPOST modules-only.symvers ERROR: modpost: "drm_dp_dpcd_write" [drivers/gpu/drm/display/drm_display_helper.ko] undefined! ERROR: modpost: "drm_dp_read_desc" [drivers/gpu/drm/display/drm_display_helper.ko] undefined! ERROR: modpost: "drm_dp_dpcd_read" [drivers/gpu/drm/display/drm_display_helper.ko] undefined! make[1]: *** [scripts/Makefile.modpost:134: modules-only.symvers] Error 1 make[1]: *** Deleting file 'modules-only.symvers' make: *** [Makefile:1749: modules] Error 2 Besides making these symbols to select CONFIG_DRM_DISPLAY_DP_HELPER, make them to depend on DRM_DISPLAY_HELPER, since can't be enabled without it. Note: It seems this has been an issue for a long time but was made easier to reproduce after the commit 1e0f6642 ("drm/display: Introduce a DRM display-helper module"). Adding a Fixes: tag just to make sure that this fix will be picked for stable once the mentioned change also lands there. Fixes: 1e0f6642 ("drm/display: Introduce a DRM display-helper module") Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
-
- 28 Apr, 2022 3 commits
-
-
Wayne Lin authored
[Why] It's reasonable that we receive NAK while doing DP_REMOTE_DPCD_READ. Downstream device might reply NAK with the reason and source should react accordingly. e.g. 1. When downstream device can't handle corresponding message in time, it then replies NAK as reason been set as DEFER. 2. When multi-function branch-sink device doesn't enumerate virtual DP peer devices for those multi-function down facing ports. Without virtual DPCD, branch device might reply NAK with reason as BAD_PARAM indicating this port can't do aux DPCD read. It's expected result. Not an error. [How] Use drm_dbg_kms() to replace drm_err() when receive NAK. Changes since v1: * drm_dp_mst_topology.c file path changed. Folder was rename from 'dp' to 'display' Signed-off-by:
Wayne Lin <Wayne.Lin@amd.com> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Reviewed-by:
-
Steven Price authored
While the check for format_count > 64 in __drm_universal_plane_init() shouldn't be hit (it's a WARN_ON), in its current position it will then leak the plane->format_types array and fail to call drm_mode_object_unregister() leaking the modeset identifier. Move it to the start of the function to avoid allocating those resources in the first place. Signed-off-by:
Steven Price <steven.price@arm.com> Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/dri-devel/20211203102815.38624-1-steven.price@arm.com/
-
Miaoqian Lin authored
The get_sg_table() function does not return NULL. It returns error pointers. Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Signed-off-by:
-
- 27 Apr, 2022 3 commits
-
-
Thomas Zimmermann authored
Add a format helper that converts RGB565 to XRGB8888. Use this function in drm_fb_blit_toio(). Fixes simpledrm output for this combination of formats. UEFI and/or Grub will usually set 32-bit output in XRGB8888 format. The issue can be reproduced by enabling simpledrm and requesting a console framebuffer of different format on the kernel command line; for example nomodeset video=1024x768-16 In this case, conversion helpers will display nothing on the console. The patch makes this work by implementing the rsp conversion helpers. It also enables odd userspace configurations, such as running Xorg with 16-bit color depth on a 32-bit output buffer. v2: * use helpers for struct drm_rect (Javier) * improve commit message (Javier) Signed-off-by:
-
Thomas Zimmermann authored
Add a format helper that converts RGB888 to XRGB8888. Use this function in drm_fb_blit_toio(). Fixes simpledrm output for this combination of formats. UEFI and/or Grub will usually set 32-bit output in XRGB8888 format. The issue can be reproduced by enabling simpledrm and requesting a console framebuffer of different format on the kernel command line; for example nomodeset video=1024x768-24 In this case, conversion helpers will display nothing on the console. The patch makes this work by implementing the rsp conversion helpers. It also enables odd userspace configurations, such as running Xorg with 24-bit color depth on a 32-bit output buffer. v2: * use helpers for struct drm_rect (Javier) * improve commit message (Javier) Signed-off-by:
-
Thomas Zimmermann authored
Not all possible format conversions are supported yet. Print a warning on unsupported combinations. Signed-off-by:
-
- 26 Apr, 2022 8 commits
-
-
Chia-I Wu authored
Otherwise, ring names are marked [UNSAFE-MEMORY]. Signed-off-by:
Chia-I Wu <olvaffe@gmail.com> Cc: Rob Clark <robdclark@chromium.org> Reviewed-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by:
-
Chia-I Wu authored
drm_sched_job and drm_run_job have the same prototype. v2: rename the class from drm_sched_job_entity to drm_sched_job (Andrey) Signed-off-by:
-
Guo Zhengkui authored
Fix the following coccicheck warning: drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gt215.c:71:5-12: Unneeded variable: "disable". Return "0ULL" on line 85. Signed-off-by:
Guo Zhengkui <guozhengkui@vivo.com> Reviewed-by:
-
Tom Rix authored
Sparse reports these issues wndwgv100.c:120:1: warning: symbol 'gv100_disp_wndw_mthd' was not declared. Should it be static? wndwgv100.c:140:1: warning: symbol 'gv100_disp_wndw' was not declared. Should it be static? These variable are only used in wndwgv100.c. Single file variables should be static. So use static as their storage-class specifiers. Signed-off-by:
-
Tom Rix authored
Sparse reports this issue wimmgv100.c:39:1: warning: symbol 'gv100_disp_wimm' was not declared. Should it be static? This variable is only used in wimmgv100.c. Single file variables should be static. So use static as its storage-class specifier. Signed-off-by:
-
Tom Rix authored
Sparse reports these issues coregv100.c:27:1: warning: symbol 'gv100_disp_core_mthd_base' was not declared. Should it be static? coregv100.c:43:1: warning: symbol 'gv100_disp_core_mthd_sor' was not declared. Should it be static? These variables are only used in coregv100.c. Single file use variables should be static, so add static to their storage-class specifier. Signed-off-by:
-
Colin Ian King authored
In the unlikely event that pointer perfmon is null the WARN_ON return path occurs after the pointer has already been deferenced. Fix this by only dereferencing perfmon after it has been null checked. Fixes: 26a4dc29 ("drm/v3d: Expose performance counters to userspace") Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Reviewed-by:
Juan A. Suarez <jasuarez@igalia.com> Signed-off-by:
Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220424183512.1365683-1-colin.i.king@gmail.com
-
Samuel Holland authored
Now that the various blocks in the D1 display engine pipeline are supported, we can enable the overall engine. Acked-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by:
Samuel Holland <samuel@sholland.org> Signed-off-by:
-
