- 28 Jun, 2024 10 commits
-
-
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 <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-2-raphael.gallais-pou@foss.st.com
-
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:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240624141926.5250-4-lvzhaoxiong@huaqin.corp-partner.google.comSigned-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 22 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:
Jocelyn Falempe <jfalempe@redhat.com> Signed-off-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:
-
Marek Vasut authored
This reverts commit 01338bb8. With clock improvements in place, this seems to be no longer necessary. Set the CLRSIPO to default setting recommended by manufacturer. Reviewed-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Marek Vasut authored
The only information in the datasheet regarding this divider is a note in SYS_PLLPARAM register documentation which states that when LSCLK is 270 MHz, LSCLK_DIV should be 1. What should LSCLK_DIV be set to when LSCLK is 162 MHz (for DP 1.62G mode) is unclear, but empirical test confirms using LSCLK_DIV 1 has no adverse effects either. In the worst case, the internal TC358767 clock would run faster. Reviewed-by:
-
Marek Vasut authored
This line_pixel_subtract is no longer needed now that the bridge can request and obtain specific pixel clock on input to the bridge, with clock frequency that matches the Pixel PLL frequency. The line_pixel_subtract is now always 0, so drop it entirely. The line_pixel_subtract was not reliable as it never worked when the Pixel PLL and input clock were off just so that the required amount of pixels to subtract would not be whole integer. Reviewed-by:
-
Marek Vasut authored
Use tc_pxl_pll_calc() to find out the exact clock frequency generated by the Pixel PLL. Use the Pixel PLL frequency as adjusted_mode clock frequency and pass it down the display pipeline to obtain exactly this frequency on input into this bridge. The precise input frequency that matches the Pixel PLL frequency is important for this bridge, as if the frequencies do not match, the bridge does suffer VFIFO overruns or underruns. Reviewed-by:
-
Marek Vasut authored
Split tc_pxl_pll_en() into tc_pxl_pll_calc() which does only Pixel PLL parameter calculation and tc_pxl_pll_en() which calls tc_pxl_pll_calc() and then configures the Pixel PLL register. This is a preparatory patch for further rework, where tc_pxl_pll_calc() will also be used to find out the exact clock frequency generated by the Pixel PLL. This frequency will be used as adjusted_mode clock frequency and passed down the display pipeline to obtain exactly this frequency on input into this bridge. The precise input frequency that matches the Pixel PLL frequency is important for this bridge, as if the frequencies do not match, the bridge does suffer VFIFO overruns or underruns. Reviewed-by:
-
Thomas Zimmermann authored
The function drm_simple_encoder_init() is a trivial helper and deprecated. Replace it with the regular call to drm_encoder_init(). Resolves the dependency on drm_simple_kms_helper.h. No functional changes. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
- 26 Jun, 2024 8 commits
-
-
Michael Walle authored
The Ortustech COM35H3P70ULC panel is based on the ILI9806E DSI display controller. Co-developed-by:
Gunnar Dibbern <gunnar.dibbern@lht.dlh.de> Signed-off-by:
Michael Walle <mwalle@kernel.org> Reviewed-by:
-
Michael Walle authored
Add the device tree binding for the Ilitek ILI9806E controller which can be found on the Ortustech COME35H3P70ULC DSI display panel. There are no peculiarities except for two different power signals. Reviewed-by:
-
Jerome Brunet authored
Add support for the Lincoln Technologies LCD197 1080x1920 DSI panel. Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20240626142212.1341556-4-jbrunet@baylibre.comSigned-off-by:
-
Jerome Brunet authored
Like for mipi_dsi_msleep(), usleep_range() may often be called in between mipi_dsi_dcs_*() functions and needs a multi compatible counter part. Suggested-by:
-
Jerome Brunet authored
This adds the bindings for the 1080x1920 Lincoln LCD197 DSI panel to panel-simple-dsi. Signed-off-by:
-
Tejas Vipin authored
Use functions introduced in commit 966e397e ("drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi()") and commit f79d6d28 ("drm/mipi-dsi: wrap more functions for streamline handling") for sitronix-st7703 based panels. Signed-off-by:
Tejas Vipin <tejasvipin76@gmail.com> Reviewed-by:
Guido Günther <agx@sigxcpu.org> Reviewed-by:
-
Lucas Stach authored
The timeout when waiting for the PRE safe window is rather short, as normally we would only need to wait a few dozen usecs for the problematic scanline region to pass and we don't want to spin too long in case something goes wrong. This however mixes badly with preemption, as we can easily get scheduled away from the CPU for a longer time than our timeout, in which case we would hit a spurious timeout and wrongly skip the PRE update. Instead of disabling preemption across the wait loop, potentially impacting the overall system latency, use a wait loop with a fixed max number of iterations, so time spent away from the CPU is not accounted against the timeout budget. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Link: https://lore.kernel.org/r/20240517104549.3648939-3-l.stach@pengutronix.deSigned-off-by:
-
Lucas Stach authored
imx-drm doesn't mandate a modeset when the framebuffer modifier changes, but currently the tile prefetch and resolve (TPR) configuration of the PRE is only set up on the initial modeset. As the TPR configuration is double buffered, same as all the other PRE states, we can support dynamic reconfiguration of the buffer layout from one frame to another. As switching between (super-)tiled and linear prefetch needs to touch the CTRL register make sure to do the reconfiguration inside the safe window. Signed-off-by:
-
