Zhaoxiong Lv
e1c550898f
drm/panel: jd9365da: Add the function of adjusting orientation
...
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.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240624141926.5250-6-lvzhaoxiong@huaqin.corp-partner.google.com
2024-06-28 10:33:24 +02:00
Zhaoxiong Lv
2b976ad760
drm/panel: jd9365da: Support for kd101ne3-40ti MIPI-DSI panel
...
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 <lvzhaoxiong@huaqin.corp-partner.google.com >
Acked-by: Jessica Zhang <quic_jesszhan@quicinc.com >
Link: https://lore.kernel.org/r/20240624141926.5250-5-lvzhaoxiong@huaqin.corp-partner.google.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240624141926.5250-5-lvzhaoxiong@huaqin.corp-partner.google.com
2024-06-28 10:33:24 +02:00
Zhaoxiong Lv
35583e1299
drm/panel: panel-jadard-jd9365da-h3: use wrapped MIPI DCS functions
...
Remove conditional code and always use mipi_dsi_dcs_*multi() wrappers to
simplify driver's init/enable/exit code.
Signed-off-by: Zhaoxiong Lv <lvzhaoxiong@huaqin.corp-partner.google.com >
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com >
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org >
Link: https://lore.kernel.org/r/20240624141926.5250-4-lvzhaoxiong@huaqin.corp-partner.google.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240624141926.5250-4-lvzhaoxiong@huaqin.corp-partner.google.com
2024-06-28 10:33:23 +02:00
Zhaoxiong Lv
e7f5112ae1
dt-bindings: display: panel: Add compatible for kingdisplay-kd101ne3
...
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 <lvzhaoxiong@huaqin.corp-partner.google.com >
Acked-by: Conor Dooley <conor.dooley@microchip.com >
Link: https://lore.kernel.org/r/20240624141926.5250-3-lvzhaoxiong@huaqin.corp-partner.google.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240624141926.5250-3-lvzhaoxiong@huaqin.corp-partner.google.com
2024-06-28 10:33:23 +02:00
Zhaoxiong Lv
38cae7b626
drm/panel: jd9365da: Modify the method of sending commands
...
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: Zhaoxiong Lv <lvzhaoxiong@huaqin.corp-partner.google.com >
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org >
Link: https://lore.kernel.org/r/20240624141926.5250-2-lvzhaoxiong@huaqin.corp-partner.google.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240624141926.5250-2-lvzhaoxiong@huaqin.corp-partner.google.com
2024-06-28 10:33:22 +02:00
Paul Gerber
6c2b2cd337
drm/panel: simple: Add AUO G104STN01 panel entry
...
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: Neil Armstrong <neil.armstrong@linaro.org >
Link: https://lore.kernel.org/r/20240627084446.3197196-3-paul.gerber@ew.tq-group.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240627084446.3197196-3-paul.gerber@ew.tq-group.com
2024-06-28 10:32:13 +02:00
Paul Gerber
21335cf6af
dt-bindings: display: simple: Add AUO G104STN01 panel
...
Add AUO G104STN01 10.4" LCD-TFT LVDS panel compatible string.
Signed-off-by: Paul Gerber <paul.gerber@ew.tq-group.com >
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org >
Link: https://lore.kernel.org/r/20240627084446.3197196-2-paul.gerber@ew.tq-group.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240627084446.3197196-2-paul.gerber@ew.tq-group.com
2024-06-28 10:32:12 +02:00
Lucas Stach
61bfcd1908
drm/bridge: analogix_dp: handle AUX transfer timeouts
...
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: Robert Foss <rfoss@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-14-l.stach@pengutronix.de
2024-06-27 11:52:19 +02:00
Lucas Stach
e857142bbb
drm/bridge: analogix_dp: only read AUX status when an error occured
...
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 <l.stach@pengutronix.de >
Reviewed-by: Robert Foss <rfoss@kernel.org >
Tested-by: Heiko Stuebner <heiko@sntech.de >
Signed-off-by: Robert Foss <rfoss@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-13-l.stach@pengutronix.de
2024-06-27 11:52:18 +02:00
Lucas Stach
0fa5e37f87
drm/bridge: analogix_dp: simplify and correct PLL lock checks
...
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 <l.stach@pengutronix.de >
Reviewed-by: Robert Foss <rfoss@kernel.org >
Tested-by: Heiko Stuebner <heiko@sntech.de >
Signed-off-by: Robert Foss <rfoss@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-12-l.stach@pengutronix.de
2024-06-27 11:52:16 +02:00
Lucas Stach
917c8d192b
drm/bridge: analogix_dp: don't wait for PLL lock too early
...
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 <l.stach@pengutronix.de >
Reviewed-by: Robert Foss <rfoss@kernel.org >
Tested-by: Heiko Stuebner <heiko@sntech.de >
Signed-off-by: Robert Foss <rfoss@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-11-l.stach@pengutronix.de
2024-06-27 11:52:14 +02:00
Lucas Stach
90986e356c
drm/bridge: analogix_dp: move macro reset after link bandwidth setting
...
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 <l.stach@pengutronix.de >
Reviewed-by: Robert Foss <rfoss@kernel.org >
Tested-by: Heiko Stuebner <heiko@sntech.de >
Signed-off-by: Robert Foss <rfoss@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-10-l.stach@pengutronix.de
2024-06-27 11:52:12 +02:00
Lucas Stach
b8a4cdbb01
drm/bridge: analogix_dp: remove PLL lock check from analogix_dp_config_video
...
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 <l.stach@pengutronix.de >
Reviewed-by: Robert Foss <rfoss@kernel.org >
Tested-by: Heiko Stuebner <heiko@sntech.de >
Reviewed-by: Robet Foss <rfoss@kernel.org >
Signed-off-by: Robert Foss <rfoss@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-9-l.stach@pengutronix.de
2024-06-27 11:52:11 +02:00
Lucas Stach
3efe2ace7f
drm/bridge: analogix_dp: move basic controller init into runtime PM
...
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 <l.stach@pengutronix.de >
Reviewed-by: Robert Foss <rfoss@kernel.org >
Tested-by: Heiko Stuebner <heiko@sntech.de >
Signed-off-by: Robert Foss <rfoss@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-8-l.stach@pengutronix.de
2024-06-27 11:52:09 +02:00
Lucas Stach
73f613908e
drm/bridge: analogix_dp: move platform and PHY power handling into runtime PM
...
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 <l.stach@pengutronix.de >
Reviewed-by: Robert Foss <rfoss@kernel.org >
Tested-by: Heiko Stuebner <heiko@sntech.de >
Signed-off-by: Robert Foss <rfoss@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-7-l.stach@pengutronix.de
2024-06-27 11:52:07 +02:00
Lucas Stach
dcbaaa239d
drm/bridge: analogix_dp: remove clk handling from analogix_dp_set_bridge
...
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 <l.stach@pengutronix.de >
Reviewed-by: Robert Foss <rfoss@kernel.org >
Tested-by: Heiko Stuebner <heiko@sntech.de >
Signed-off-by: Robert Foss <rfoss@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-6-l.stach@pengutronix.de
2024-06-27 11:52:06 +02:00
Lucas Stach
e7514df007
drm/bridge: analogix_dp: remove unused analogix_dp_remove
...
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 <l.stach@pengutronix.de >
Reviewed-by: Robert Foss <rfoss@kernel.org >
Tested-by: Heiko Stuebner <heiko@sntech.de >
Signed-off-by: Robert Foss <rfoss@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-5-l.stach@pengutronix.de
2024-06-27 11:52:04 +02:00
Lucas Stach
f37952339c
drm/bridge: analogix_dp: handle clock via runtime PM
...
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 <l.stach@pengutronix.de >
Reviewed-by: Robert Foss <rfoss@kernel.org >
Tested-by: Heiko Stuebner <heiko@sntech.de >
Signed-off-by: Robert Foss <rfoss@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-4-l.stach@pengutronix.de
2024-06-27 11:52:02 +02:00
Lucas Stach
2d192f4a3a
drm/bridge: analogix_dp: register AUX bus after enabling runtime PM
...
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 <l.stach@pengutronix.de >
Reviewed-by: Robert Foss <rfoss@kernel.org >
Tested-by: Heiko Stuebner <heiko@sntech.de >
Signed-off-by: Robert Foss <rfoss@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-3-l.stach@pengutronix.de
2024-06-27 11:52:00 +02:00
Lucas Stach
c91b5bd7b1
drm/rockchip: analogix_dp: add runtime PM handling
...
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 <l.stach@pengutronix.de >
Reviewed-by: Robert Foss <rfoss@kernel.org >
Reviewed-by: Heiko Stuebner <heiko@sntech.de >
Tested-by: Heiko Stuebner <heiko@sntech.de >
Signed-off-by: Robert Foss <rfoss@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-2-l.stach@pengutronix.de
2024-06-27 11:51:58 +02:00
Lucas Stach
6d4618ad04
drm/bridge: analogix_dp: remove unused platform power_on_end callback
...
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: Lucas Stach <l.stach@pengutronix.de >
Reviewed-by: Robert Foss <rfoss@kernel.org >
Tested-by: Heiko Stuebner <heiko@sntech.de >
Signed-off-by: Robert Foss <rfoss@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240619182200.3752465-1-l.stach@pengutronix.de
2024-06-27 11:51:56 +02:00
Geert Uytterhoeven
54be78446d
drm/panic: Restrict graphical logo handling to built-in
...
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: 294bbd1f26lkp@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: Jocelyn Falempe <jfalempe@redhat.com >
Link: https://patchwork.freedesktop.org/patch/msgid/4009fca99a7c05f617cc9899c6d0a5748415595d.1719391132.git.geert+renesas@glider.be
2024-06-27 11:41:58 +02:00
Geert Uytterhoeven
e044e707fc
drm/panic: Do not select DRM_KMS_HELPER
...
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
9544309775bf9fb17c66geert+renesas@glider.be >
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com >
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com >
Link: https://patchwork.freedesktop.org/patch/msgid/60155f8c939ed286e324a7c12a1daa69fe49fcf6.1719391132.git.geert+renesas@glider.be
2024-06-27 11:40:58 +02:00
Marek Vasut
86b0e0c1ad
Revert "drm/bridge: tc358767: Set default CLRSIPO count"
...
This reverts commit 01338bb82falexander.stein@ew.tq-group.com >
Signed-off-by: Marek Vasut <marex@denx.de >
Signed-off-by: Robert Foss <rfoss@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240625120334.145320-5-marex@denx.de
2024-06-27 11:07:08 +02:00
Marek Vasut
9c433c87e8
drm/bridge: tc358767: Set LSCLK divider for SYSCLK to 1
...
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: Alexander Stein <alexander.stein@ew.tq-group.com >
Signed-off-by: Marek Vasut <marex@denx.de >
Signed-off-by: Robert Foss <rfoss@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240625120334.145320-4-marex@denx.de
2024-06-27 11:07:07 +02:00
Marek Vasut
3f13e53bcf
drm/bridge: tc358767: Drop line_pixel_subtract
...
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: Alexander Stein <alexander.stein@ew.tq-group.com >
Signed-off-by: Marek Vasut <marex@denx.de >
Signed-off-by: Robert Foss <rfoss@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240625120334.145320-3-marex@denx.de
2024-06-27 11:07:07 +02:00
Marek Vasut
a723d43400
drm/bridge: tc358767: Use tc_pxl_pll_calc() to correct adjusted_mode clock
...
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: Alexander Stein <alexander.stein@ew.tq-group.com >
Signed-off-by: Marek Vasut <marex@denx.de >
Signed-off-by: Robert Foss <rfoss@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240625120334.145320-2-marex@denx.de
2024-06-27 11:07:07 +02:00
Marek Vasut
84708c2d18
drm/bridge: tc358767: Split tc_pxl_pll_en() into parameter calculation and enablement
...
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: Alexander Stein <alexander.stein@ew.tq-group.com >
Signed-off-by: Marek Vasut <marex@denx.de >
Signed-off-by: Robert Foss <rfoss@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240625120334.145320-1-marex@denx.de
2024-06-27 11:07:07 +02:00
Thomas Zimmermann
04aaa4dc97
drm/ast: Inline drm_simple_encoder_init()
...
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: Jocelyn Falempe <jfalempe@redhat.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20240625131815.14514-1-tzimmermann@suse.de
2024-06-27 10:06:39 +02:00
Michael Walle
baf272bac6
drm/panel: add Ilitek ILI9806E panel driver
...
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: Gunnar Dibbern <gunnar.dibbern@lht.dlh.de >
Signed-off-by: Michael Walle <mwalle@kernel.org >
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org >
Link: https://lore.kernel.org/r/20240626144433.3097793-3-mwalle@kernel.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240626144433.3097793-3-mwalle@kernel.org
2024-06-26 18:41:10 +02:00
Michael Walle
b7a0c0e9d8
dt-bindings: display: panel: add Ilitek ili9806e panel controller
...
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: Conor Dooley <conor.dooley@microchip.com >
Signed-off-by: Michael Walle <mwalle@kernel.org >
Link: https://lore.kernel.org/r/20240626144433.3097793-2-mwalle@kernel.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240626144433.3097793-2-mwalle@kernel.org
2024-06-26 18:41:09 +02:00
Jerome Brunet
c5207ed463
drm/panel: add lincolntech lcd197 support
...
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.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240626142212.1341556-4-jbrunet@baylibre.com
2024-06-26 18:38:30 +02:00
Jerome Brunet
3ebc76c424
drm/mipi-dsi: add mipi_dsi_usleep_range helper
...
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: Dmitry Baryshkov <dmitry.baryshkov@linaro.org >
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com >
Link: https://lore.kernel.org/r/20240626142212.1341556-3-jbrunet@baylibre.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240626142212.1341556-3-jbrunet@baylibre.com
2024-06-26 18:38:29 +02:00
Jerome Brunet
47d5c1934e
dt-bindings: panel-simple-dsi: add lincoln LCD197 panel bindings
...
This adds the bindings for the 1080x1920 Lincoln LCD197 DSI panel to
panel-simple-dsi.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com >
Acked-by: Conor Dooley <conor.dooley@microchip.com >
Link: https://lore.kernel.org/r/20240626142212.1341556-2-jbrunet@baylibre.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240626142212.1341556-2-jbrunet@baylibre.com
2024-06-26 18:38:29 +02:00
Tejas Vipin
68145ceb9b
drm/panel: sitronix-st7703: transition to mipi_dsi wrapped functions
...
Use functions introduced in commit 966e397e4ff79d6d28d8tejasvipin76@gmail.com >
Reviewed-by: Guido Günther <agx@sigxcpu.org >
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org >
Link: https://lore.kernel.org/r/20240626045244.48858-1-tejasvipin76@gmail.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240626045244.48858-1-tejasvipin76@gmail.com
2024-06-26 18:34:27 +02:00
Lucas Stach
d5316cdd15
gpu: ipu-v3: pre: don't use fixed timeout when waiting for safe window
...
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: Lucas Stach <l.stach@pengutronix.de >
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de >
Link: https://lore.kernel.org/r/20240517104549.3648939-3-l.stach@pengutronix.de
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de >
Link: https://patchwork.freedesktop.org/patch/msgid/20240517104549.3648939-3-l.stach@pengutronix.de
2024-06-26 17:43:54 +02:00
Lucas Stach
4dbc7d5d61
gpu: ipu-v3: pre: add dynamic buffer layout reconfiguration
...
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: Lucas Stach <l.stach@pengutronix.de >
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de >
Link: https://lore.kernel.org/r/20240517104549.3648939-2-l.stach@pengutronix.de
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de >
Link: https://patchwork.freedesktop.org/patch/msgid/20240517104549.3648939-2-l.stach@pengutronix.de
2024-06-26 17:43:54 +02:00
Lucas Stach
ee7ff5e26b
gpu: ipu-v3: pre: move state into struct
...
Move the variables tracking the current dynamic state into a struct
to separate it a bit better from the static device properties.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de >
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de >
Link: https://lore.kernel.org/r/20240517104549.3648939-1-l.stach@pengutronix.de
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de >
Link: https://patchwork.freedesktop.org/patch/msgid/20240517104549.3648939-1-l.stach@pengutronix.de
2024-06-26 17:43:54 +02:00
R Sundar
81112c6f36
gpu: ipu-v3: pre: replace of_node_put() with __free
...
use the new cleanup magic to replace of_node_put() with
__free(device_node) marking to auto release when they get out of scope.
Suggested-by: Julia Lawall <julia.lawall@inria.fr >
Signed-off-by: R Sundar <prosunofficial@gmail.com >
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de >
Link: https://lore.kernel.org/r/20240427045024.7083-1-prosunofficial@gmail.com
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de >
Link: https://patchwork.freedesktop.org/patch/msgid/20240427045024.7083-1-prosunofficial@gmail.com
2024-06-26 17:43:46 +02:00
Dave Stevenson
328ab5688f
MAINTAINERS: drm: vc4: Drop Emma's tree
...
Emma stepped back from VC4 maintenance a while ago, and
all patches are now merged through drm-misc.
Drop Emma's tree from MAINTAINERS.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com >
Signed-off-by: Maxime Ripard <mripard@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240621131926.3133484-2-dave.stevenson@raspberrypi.com
2024-06-26 15:32:04 +02:00
Dave Stevenson
3cc9ec4ff7
MAINTAINERS: drm: vc4: Add Raspberry Pi as maintainers
...
Add myself as maintainer for VC4 alongside Maxime, and
our internal review list as reviewer.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com >
Acked-by: Daniel Stone <daniels@collabora.com >
Signed-off-by: Maxime Ripard <mripard@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240621131926.3133484-1-dave.stevenson@raspberrypi.com
2024-06-26 15:32:03 +02:00
Chen Ni
7bd09a2db0
drm/qxl: Add check for drm_cvt_mode
...
Add check for the return value of drm_cvt_mode() and return the error if
it fails in order to avoid NULL pointer dereference.
Fixes: 1b043677d4nichen@iscas.ac.cn >
Reviewed-by: Heng Qi <hengqi@linux.alibaba.com >
Signed-off-by: Maxime Ripard <mripard@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240621071031.1987974-1-nichen@iscas.ac.cn
2024-06-26 15:32:03 +02:00
Chen-Yu Tsai
97370f8ed2
drm/mediatek: select DRM_GEM_DMA_HELPER if DRM_FBDEV_EMULATION=y
...
With the recent switch from fbdev-generic to fbdev-dma, the driver now
requires the DRM GEM DMA helpers. This dependency is missing, and will
cause a link failure if fbdev emulation is enabled.
Add the missing dependency.
Fixes: 0992284b4fwenst@chromium.org >
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de >
Acked-by: Chun-Kuang Hu <chunkuang.hu@mediatek.com >
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de >
Link: https://patchwork.freedesktop.org/patch/msgid/20240620054708.2230665-1-wenst@chromium.org
2024-06-26 11:11:43 +02:00
Jerome Brunet
c19f15b1e0
dt-bindings: display: meson-dw-hdmi: add missing power-domain
...
All Amlogic instances of the Synopsys HDMI controller need a power domain
enabled. This is currently missing because the Amlogic HDMI driver directly
pokes the power domain controller registers, which it should not do.
Instead The HDMI controller should use the power controller.
Fix the bindings accordingly.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com >
Acked-by: Conor Dooley <conor.dooley@microchip.com >
Link: https://lore.kernel.org/r/20240625145017.1003346-2-jbrunet@baylibre.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240625145017.1003346-2-jbrunet@baylibre.com
2024-06-26 09:28:31 +02:00
Dmitry Baryshkov
06ec7893a4
drm/connector: hdmi: shorten too long function name
...
If CONFIG_MODVERSIONS is enabled, then using the HDMI Connector
framework can result in build failures. Rename the function to make it
fit into the name requirements.
ERROR: modpost: too long symbol "drm_atomic_helper_connector_hdmi_disable_audio_infoframe" [drivers/gpu/drm/msm/msm.ko]
Reported-by: Mark Brown <broonie@kernel.org >
Reviewed-by: Maxime Ripard <mripard@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240624-hdmi-connector-shorten-name-v1-1-5bd3410138db@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org >
2024-06-25 15:09:56 +03:00
Jeff Johnson
26149e6fe1
drm/ttm/tests: add missing MODULE_DESCRIPTION() macros
...
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/ttm/tests/ttm_device_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/ttm/tests/ttm_pool_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/ttm/tests/ttm_resource_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/ttm/tests/ttm_tt_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/ttm/tests/ttm_bo_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/ttm/tests/ttm_mock_manager.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com >
Acked-by: Christian König <christian.koenig@amd.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20240624-md-drivers-gpu-drm-ttm-tests-v2-1-76bb765e19c9@quicinc.com
Signed-off-by: Christian König <christian.koenig@amd.com >
2024-06-25 09:53:13 +02:00
Geert Uytterhoeven
294bbd1f26
drm/panic: Add support for drawing a monochrome graphical logo
...
Re-use the existing support for boot-up logos to draw a monochrome
graphical logo in the DRM panic handler. When no suitable graphical
logo is available, the code falls back to the ASCII art penguin logo.
Note that all graphical boot-up logos are freed during late kernel
initialization, hence a copy must be made for later use.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be >
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com >
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com >
Link: https://patchwork.freedesktop.org/patch/msgid/3f1a5f56213f3e4584773eb2813e212b2dff6d14.1718305355.git.geert+renesas@glider.be
2024-06-24 13:24:02 +02:00
Geert Uytterhoeven
a40d031d7b
drm/panic: Rename logo to logo_ascii
...
Rename variables related to the ASCII logo, to prepare for the advent of
support for graphical logos.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be >
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com >
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com >
Link: https://patchwork.freedesktop.org/patch/msgid/df77372c16153655c321a290b5a3191ee2dcbc6b.1718305355.git.geert+renesas@glider.be
2024-06-24 13:24:02 +02:00
Geert Uytterhoeven
a3dfb1d120
drm/panic: Spelling s/formater/formatter/
...
Fix a misspelling of "formatter".
Fixes: 54034bebb2geert+renesas@glider.be >
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com >
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com >
Link: https://patchwork.freedesktop.org/patch/msgid/5a11f8caf8759aaa22d421034d3047368e9d5f33.1718305355.git.geert+renesas@glider.be
2024-06-24 13:18:02 +02:00
Geert Uytterhoeven
a03a84bee3
lib/fonts: Fix visiblity of SUN12x22 and TER16x32 if DRM_PANIC
...
When CONFIG_FONTS ("Select compiled-in fonts") is not enabled, the user
should not be asked about any fonts. However, when CONFIG_DRM_PANIC is
enabled, the user is still asked about the Sparc console 12x22 and
Terminus 16x32 fonts.
Fix this by moving the "|| DRM_PANIC" to where it belongs.
Split the dependency in two rules to improve readability.
Fixes: b94605a388geert+renesas@glider.be >
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com >
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com >
Link: https://patchwork.freedesktop.org/patch/msgid/ac474c6755800e61e18bd5af407c6acb449c5149.1718305355.git.geert+renesas@glider.be
2024-06-24 13:18:02 +02:00
