- 03 Jul, 2024 10 commits
-
-
Dragan Simic authored
Panfrost DRM driver uses devfreq to perform DVFS, while using simple_ondemand devfreq governor by default. This causes driver initialization to fail on boot when simple_ondemand governor isn't built into the kernel statically, as a result of the missing module dependency and, consequently, the required governor module not being included in the initial ramdisk. Thus, let's mark simple_ondemand governor as a softdep for Panfrost, to have its kernel module included in the initial ramdisk. This is a rather longstanding issue that has forced distributions to build devfreq governors statically into their kernels, [1][2] or has forced users to introduce some unnecessary workarounds. [3] For future reference, not having support for the simple_ondemand governor in the initial ramdisk produces errors in the kernel log similar to these below, which were taken from a Pine64 RockPro64: panfrost ff9a0000.gpu: [drm:panfrost_devfreq_init [panfrost]] *ERROR* Couldn't initialize GPU devfreq panfrost ff9a0000.gpu: Fatal error during GPU init panfrost: probe of ff9a0000.gpu failed with error -22 Having simple_ondemand marked as a softdep for Panfrost may not resolve this issue for all Linux distributions. In particular, it will remain unresolved for the distributions whose utilities for the initial ramdisk generation do not handle the available softdep information [4] properly yet. However, some Linux distributions already handle softdeps properly while generating their initial ramdisks, [5] and this is a prerequisite step in the right direction for the distributions that don't handle them properly yet. [1] https://gitlab.manjaro.org/manjaro-arm/packages/core/linux/-/blob/linux61/config?ref_type=heads#L8180 [2] https://salsa.debian.org/kernel-team/linux/-/merge_requests/1066 [3] https://forum.pine64.org/showthread.php?tid=15458 [4] https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/commit/?id=49d8e0b59052999de577ab732b719cfbeb89504d [5] https://github.com/archlinux/mkinitcpio/commit/97ac4d37aae084a050be512f6d8f4489054668ad Cc: Diederik de Haas <didi.debian@cknow.org> Cc: Furkan Kardame <f.kardame@manjaro.org> Cc: stable@vger.kernel.org Fixes: f3ba9122 ("drm/panfrost: Add initial panfrost driver") Signed-off-by:
Dragan Simic <dsimic@manjaro.org> Reviewed-by:
Steven Price <steven.price@arm.com> Reviewed-by:
Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by:
-
Thorsten Blum authored
The if condition !A || A && B can be simplified to !A || B. Fixes the following Coccinelle/coccicheck warning reported by excluded_middle.cocci: WARNING !A || A && B is equivalent to !A || B Compile-tested only. Acked-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
Thorsten Blum <thorsten.blum@toblux.com> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
-
Thomas Zimmermann authored
Ast has no special requirements for runtime power management. So replace drm_atomic_helper_commit_tail_rpm() with the regular helper drm_atomic_helper_commit_tail(). Signed-off-by:
Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240627153638.8765-9-tzimmermann@suse.de
-
Thomas Zimmermann authored
The function ast_crtc_dpms() is left over from when the ast driver did not implement atomic modesetting. But DPMS is not supported by atomic modesetting and the helper is only called to enable or disable the CRTC sync pulses. Inline the function into its callers. To disable the CRTC, ast sets (AST_DPMS_VSYNC_OFF | AST_DPMS_HSYNC_OFF) in VGACRB6. Replace the constants with the correct register constants for VGACRB6. Signed-off-by:
-
Thomas Zimmermann authored
The SCREEN_DISABLE bit controls scanout from display memory. The bit affects all planes, so set it only in the CRTC's atomic enable and disable functions. A number of bugs affect this fix. First of all, ast_set_std_regs() tries to set VGASR1 except for the SD bit. But the read bitmask is invert, so it preserves anything except the SD bit. Fix this by re-inverting the read mask. The second issue is that primary-plane and CRTC helpers modify the SD bit. The bit controls scanout for all planes, primary and HW cursor, so set it only in the CRTC code. Further add a constant to represent the SD bit in VGASR1. Keep the plane's atomic_disable around to make the DRM framework happy. v2: - fix typos in commit message Signed-off-by:
-
Thomas Zimmermann authored
The DPMS code, called from the CRTC's atomic_enable, rewrites the gamma LUT. This is already done by the CRTC's atomic_flush. Remove the duplication. v2: - fix a typo in commit message Signed-off-by:
-
Thomas Zimmermann authored
Several color registers are programmed in the DPMS code of the CRTC's atomic_enable helper and the primary plane's atomic_update. It requires the color format and the display mode. Both code paths handle different cases: the DPMS's code will not be executed if the color format changes without a full mode switch. The plane's code only runs if the color format changes, but ignores display-mode changes. The color format is a property of the primary plane, so consolidate all color-format code in the plane's atomic_update. Remove it from the DPMS helper. v2: - clarify commit message (Jocelyn) Signed-off-by:
-
Thomas Zimmermann authored
Do all mode setting in ast_crtc_helper_mode_set_nofb(), which always runs after disabling the CRTC and before programming the planes. Removes implicit synchronization between the CRTC's atomic disable, enable and the vertical retrace. Display-mode updates require HW cursors to be disabled. The HW cursor only picks up changes at vertical retrace periods. So the CRTC's atomic_disable helper waited for the retrace to delay any following mode-setting operations, which then happened in atomic_enable. See [1] for a description of the problem. With the CRTC helper callback mode_set_nofb, we can now synchronize and reprogram in the same place. As it always runs before the plane update, the plane code can be reordered with the CRTC's later atomic_enable et al. Signed-off-by:
-
Thomas Zimmermann authored
The CRTC's atomic_flush function contains code to program the display mode to the AST DP chip. Move the code to the encoder's atomic_mode_set callback. The DRM atomic-modesetting code invoke this callback as part of the atomic commit. v2: - fix typos in commit message Signed-off-by:
-
Thomas Zimmermann authored
The CRTC helpers contain code to enable and disable DisplayPort connectors. Implement this functionality in the respective connector's atomic_enable/atomic_disable callbacks. DRM's atomic-modesetting helpers will call the functions as part of the atomic commit. Signed-off-by:
-
- 01 Jul, 2024 1 commit
-
-
Dave Stevenson authored
Adds test for the cmdline parser, connector property, and drm_analog_tv_mode to ensure the behaviour of the new value is correct. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by:
Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240620110947.3615207-1-dave.stevenson@raspberrypi.com
-
- 30 Jun, 2024 1 commit
-
-
Dragan Simic authored
Lima DRM driver uses devfreq to perform DVFS, while using simple_ondemand devfreq governor by default. This causes driver initialization to fail on boot when simple_ondemand governor isn't built into the kernel statically, as a result of the missing module dependency and, consequently, the required governor module not being included in the initial ramdisk. Thus, let's mark simple_ondemand governor as a softdep for Lima, to have its kernel module included in the initial ramdisk. This is a rather longstanding issue that has forced distributions to build devfreq governors statically into their kernels, [1][2] or may have forced some users to introduce unnecessary workarounds. Having simple_ondemand marked as a softdep for Lima may not resolve this issue for all Linux distributions. In particular, it will remain unresolved for the distributions whose utilities for the initial ramdisk generation do not handle the available softdep information [3] properly yet. However, some Linux distributions already handle softdeps properly while generating their initial ramdisks, [4] and this is a prerequisite step in the right direction for the distributions that don't handle them properly yet. [1] https://gitlab.manjaro.org/manjaro-arm/packages/core/linux-pinephone/-/blob/6.7-megi/config?ref_type=heads#L5749 [2] https://gitlab.com/postmarketOS/pmaports/-/blob/7f64e287e7732c9eaa029653e73ca3d4ba1c8598/main/linux-postmarketos-allwinner/config-postmarketos-allwinner.aarch64#L4654 [3] https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/commit/?id=49d8e0b59052999de577ab732b719cfbeb89504d [4] https://github.com/archlinux/mkinitcpio/commit/97ac4d37aae084a050be512f6d8f4489054668ad Cc: Philip Muller <philm@manjaro.org> Cc: Oliver Smith <ollieparanoid@postmarketos.org> Cc: Daniel Smith <danct12@disroot.org> Cc: stable@vger.kernel.org Fixes: 19969707 ("drm/lima: Add optional devfreq and cooling device support") Signed-off-by:
Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/fdaf2e41bb6a0c5118ff9cc21f4f62583208d885.1718655070.git.dsimic@manjaro.org
-
- 28 Jun, 2024 12 commits
-
-
Raphael Gallais-Pou authored
DSISRC __________ __\_ | \ pll4_p_ck ->| 1 |____dsi_k ck_dsi_phy ->| 0 | |____/ A DSI clock is missing in the clock framework. Looking at the clk_summary, it appears that 'ck_dsi_phy' is not implemented. Since the DSI kernel clock is based on the internal DSI pll. The common clock driver can not directly expose this 'ck_dsi_phy' clock because it does not contain any common registers with the DSI. Thus it needs to be done directly within the DSI phy driver. Signed-off-by:
Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Acked-by:
Yannick Fertre <yannick.fertre@foss.st.com> Tested-by:
Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240129104106.43141-4-raphael.gallais-pou@foss.st.com
-
Yannick Fertre authored
Update control of clocks and supply thanks to the PM runtime mechanism to avoid kernel crash during a system suspend. Signed-off-by:
-
Raphael Gallais-Pou authored
Use RUNTIME_PM_OPS() instead of the old SET_SYSTEM_SLEEP_PM_OPS(). This means we don't need __maybe_unused on the functions. Signed-off-by:
-
Raphael Gallais-Pou authored
The Low-Voltage Differential Signaling (LVDS) Display Interface Transmitter handles the LVDS protocol: it maps the pixels received from the upstream Pixel-DMA LCD-TFT Display Controller (LTDC) onto the LVDS PHY. It is composed of three sub blocks: * LVDS host: handles the LVDS protocol (FPD / OpenLDI) and maps its input pixels onto the data lanes of the PHY * LVDS PHY: parallelize the data and drives the LVDS data lanes * LVDS wrapper: handles top-level settings The LVDS controller driver supports the following high-level features: * FDP-Link-I and OpenLDI (v0.95) protocols * Single-Link or Dual-Link operation * Single-Display or Double-Display (with the same content duplicated on both) * Flexible Bit-Mapping, including JEIDA and VESA * RGB888 or RGB666 output * Synchronous design, with one input pixel per clock cycle Signed-off-by:
-
Raphael Gallais-Pou authored
Add "st,stm32mp25-lvds" compatible. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Acked-by:
-
Zhaoxiong Lv authored
This driver does not have the function to adjust the orientation, so this function is added. Signed-off-by:
Zhaoxiong Lv <lvzhaoxiong@huaqin.corp-partner.google.com> Reviewed-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Link: https://lore.kernel.org/r/20240624141926.5250-6-lvzhaoxiong@huaqin.corp-partner.google.comSigned-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240624141926.5250-6-lvzhaoxiong@huaqin.corp-partner.google.com
-
Zhaoxiong Lv authored
The K&d kd101ne3-40ti is a 10.1" WXGA TFT-LCD panel, use jd9365da controller,which fits in nicely with the existing panel-jadard-jd9365da-h3 driver.Hence,we add a new compatible with panel specific config. Although they have the same control IC, the two panels are different, and the timing will be slightly different, so we added some variables in struct jadard_panel_desc to control the timing. Signed-off-by:
-
Zhaoxiong Lv authored
Remove conditional code and always use mipi_dsi_dcs_*multi() wrappers to simplify driver's init/enable/exit code. Signed-off-by:
-
Zhaoxiong Lv authored
The kingdisplay-kd101ne3 is a 10.1" WXGA TFT-LCD panel with jadard-jd9365da controller. Hence, we add a new compatible with panel specific config. Signed-off-by:
-
Zhaoxiong Lv authored
Currently, the init_code of the jd9365da driver is placed in the enable() function and sent, but this seems to take a long time. It takes 17ms to send each instruction (an init code consists of about 200 instructions), so it takes about 3.5s to send the init_code. So we moved the sending of the inti_code to the prepare() function, and each instruction seemed to take only 25μs. We checked the DSI host and found that the difference in command sending time is caused by the different modes of the DSI host in prepare() and enable() functions. Our DSI Host only supports sending cmd in LP mode, The prepare() function can directly send init_code (LP->cmd) in LP mode, but the enable() function is in HS mode and needs to switch to LP mode before sending init code (HS->LP->cmd->HS). Therefore, it takes longer to send the command. Signed-off-by:
-
Paul Gerber authored
Add support for the AUO G104STN01 10.4" (800x600) LCD-TFT panel. Signed-off-by:
Paul Gerber <paul.gerber@ew.tq-group.com> Reviewed-by:
-
Paul Gerber authored
Add AUO G104STN01 10.4" LCD-TFT LVDS panel compatible string. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240627084446.3197196-2-paul.gerber@ew.tq-group.comSigned-off-by:
-
- 27 Jun, 2024 16 commits
-
-
Lucas Stach authored
Timeouts on the AUX bus are to be expected in certain normal operating conditions. There is no need to raise an error log or re-initialize the whole AUX state machine. Simply acknowledge the AUX_ERR interrupt and let upper layers know about the timeout. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
Robert Foss <rfoss@kernel.org> Tested-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Lucas Stach authored
All AUX error responses raise the AUX_ERR interrupt, so there is no need to read the AUX status register in normal operation. Only read the status when an error occurred and we can expect a different status than OK. Signed-off-by:
-
Lucas Stach authored
Move the wait loop into its own function, so it doesn't need to be replicated in multiple locations. Also move the PLL lock checks between setting the link bandwidth, which may cause the PLL to unlock, and the MACRO_RST which needs the PLL to be locked. Signed-off-by:
-
Lucas Stach authored
The PLL will be reconfigured later, which may cause it to go out of lock anyway, so there is no point in waiting for the PLL to lock here. Instead we can continue execution of the link setup, which will properly set the PLL parameters and will wait for the PLL to lock at the appropriate times. Signed-off-by:
-
Lucas Stach authored
Setting the link bandwidth may change the PLL parameters, which will cause the PLL to go out of lock, so make sure to apply the MACRO_RST, which according to the comment is required to be pulsed after the PLL is locked. Signed-off-by:
-
Lucas Stach authored
This check is way too late in the DP enable flow. The PLL must be locked much earlier, before any link training can happen. If the PLL is unlocked at that point in time there is something seriously wrong in the enable flow. Signed-off-by:
-
Lucas Stach authored
Make sure the controller is in a basic working state after runtime resume. Keep the analog function enable in the mode set path as this enables parts of the PHY that are only required to be powered when there is a data stream being sent out. Signed-off-by:
-
Lucas Stach authored
Platform and PHY power isn't only required when the actual display data stream is active, but may be required earlier to support AUX channel transactions. Move them into the runtime PM calls, so they are properly managed whenever various other parts of the driver need them to be active. Signed-off-by:
-
Lucas Stach authored
The clock is already managed by runtime PM, which is properly invoked from the analogix_dp_set_bridge function, so there is no need for an additional reference. Signed-off-by:
-
Lucas Stach authored
Now that the clock is handled dynamically through analogix_dp_resume/suspend and it isn't statically enabled in the driver probe routine, there is no need for the remove function anymore. Signed-off-by:
-
Lucas Stach authored
There is no reason to enable the controller clock in driver probe, as there is no HW initialization done in this function. Instead rely on either runtime PM to handle the controller clock or statically enable it in the driver bind routine, after which real hardware access is required to work. Signed-off-by:
-
Lucas Stach authored
AUX transactions require the controller to be in working state and take a runtime PM reference. To avoid potential races beween the first transactions on the bus and runtime PM being set up, move the AUX registration behind the runtime PM setup. Signed-off-by:
-
Lucas Stach authored
Hook up the runtime PM suspend/resume paths to make the rockchip glue behave more like the exynos one. The same suspend/resume functions are used for system sleep via the runtime PM force suspend/resume. Signed-off-by:
-
Lucas Stach authored
This isn't used, but gives the impression of the power on and power off platform calls being non-symmetrical. Remove the unused callback and rename the power_on_start to simply power_on. Signed-off-by:
-
Geert Uytterhoeven authored
When CONFIG_DRM_PANIC=y, but CONFIG_DRM=m: ld: drivers/gpu/drm/drm_panic.o: in function `drm_panic_setup_logo': drivers/gpu/drm/drm_panic.c:99: multiple definition of `init_module'; drivers/gpu/drm/drm_drv.o:drivers/gpu/drm/drm_drv.c:1079: first defined here Fix this by restricting the graphical logo handling and its device_initcall() to the built-in case. Logos are freed during late kernel initialization, so they are no longer available at module load time anyway. Fixes: 294bbd1f ("drm/panic: Add support for drawing a monochrome graphical logo") Reported-by:kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202406261341.GYsbLpN1-lkp@intel.com/Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
-
Geert Uytterhoeven authored
DRM core code cannot call into DRM helper code, as this would lead to circular references in the modular case. Hence drop the selection of DRM_KMS_HELPER. It was unused anyway, as v10 switched from using the DRM format helpers to its own color format conversion, cfr. commit 95443097 ("drm/panic: Add support for color format conversion"). Remove the unneeded include of <drm/drm_format_helper.h>. Fixes: bf9fb17c ("drm/panic: Add a drm panic handler") Signed-off-by:
-
