| Age | Commit message (Collapse) | Author |
|---|
|
The lcdifv3 video controller has a clock dependency on the HDMI PHY for
the imx8mp. Powering down the HDMI PHY before the drm display pipeline
finishes after a hot-plug monitor disconnection event causes a vblank
timeout error due to the lcdif clock stopping. Likely because of this,
the downstream code doesn't power down the HDMI PHY (it was commented),
leaving the PHY ON even on a disconnection event, resulting in the HDMI
data and clock signals still running. This appears to cause issues when
using HDMI with bridge devices (e.g. HDMI-->eDP) to handle HPD (Hot-Plug Detect)
events from the bridge.
To address the problem, the workaround moves the PHY power-off logic to
the suspend of the lcdifv3 driver. At this position, it guarantees that
the DRM pipeline has finished and disabled and the PHY can be powered off
without problems. Doing this appears to be safe as the PHY is powered on
again on imx8mp_hdmi_phy_init() before starting the DRM pipeline. The PHY
is controlled by the HDMI TX BLK CTRL peripheral, but the downstream driver
for the peripheral is not fully implemented. So, the workaround maps
HDMI TX BLK CTRL register space to the lcdifv3 driver and controls it
directly, similar to the approach used in the imx HDMI driver.
Upstream-Status: Inappropriate [other]
The imx8mp already has a fully working implementation on upstream [1] and
[2]. Nonetheless, attempting to backport it appears impractical, leading
to the adoption of this workaround.
[1] https://lore.kernel.org/lkml/20240210204606.11944-1-aford173@gmail.com/
[2] https://lore.kernel.org/lkml/20240203165307.7806-1-aford173@gmail.com/
Signed-off-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
|
|
Return EPROBE_DEFER in the probe function if the LDB bridge is missing
some of its child bridges. The current implementation returns
EPROBE_DEFER in the bind function, which is incorrect because the kernel
assumes the driver is fully functional when bind is called.
When both HDMI and LVDS is configured the above actually happens in
about 20% of the boots, resulting in a kernel backtrace and neither of
the two graphical outputs being functional.
drm_mode_config_cleanup tries to cleanup a not instantiated device,
if one fixes that the next hickup occurs...
This commit assures to not take this code path.
[ 7.130956] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 7.142436] Modules linked in: crct10dif_ce snd_soc_imx_spdif snd_soc_imx_hdmi mwifiex panel_lvds cfg80211 rfkill ahci_imx atmel_
mxt_ts flexcan can_dev mxc_jpeg_encdec snd_soc_fsl_audmix v4l2_jpeg imx8_media_dev(C) snd_soc_fsl_spdif snd_soc_fsl_asrc snd_soc_fsl
_sai cdns_mhdp_imx(+) cdns_mhdp_drmcore caam error galcore fuse
[ 7.171161] CPU: 1 PID: 277 Comm: systemd-udevd Tainted: G C 5.15.129-6.5.0-06970-gdc84adb6e1b2-dirty #31
[ 7.182073] Hardware name: Toradex Apalis iMX8QP V1.1 on Apalis Evaluation Board (DT)
[ 7.189932] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 7.196905] pc : drm_mode_config_cleanup+0x54/0x300
[ 7.201815] lr : drm_mode_config_init_release+0x10/0x20
[ 7.207079] sp : ffff800009ffb710
[ 7.210411] x29: ffff800009ffb770 x28: ffff000003210550 x27: ffff00001af06a00
[ 7.217582] x26: ffff80000812cdd0 x25: dead000000000122 x24: dead000000000100
[ 7.224748] x23: ffff8000094b7250 x22: ffff00001a9c7810 x21: ffff00001a9c7800
[ 7.231907] x20: ffff00001a9c7aa8 x19: fffffffffffffff8 x18: 0000000000000000
[ 7.239065] x17: ffff8000763e6000 x16: ffff800009c18000 x15: 0000000000000000
[ 7.246222] x14: 0000000000000000 x13: 0000000000000010 x12: 0000000000000001
[ 7.253373] x11: 0000000000000001 x10: 00000000000009e0 x9 : ffff800009bda000
[ 7.260531] x8 : ffff00001ae41c80 x7 : ffff00001a9a9e00 x6 : 0000000000000000
[ 7.267690] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[ 7.274839] x2 : ffff8000087b58e0 x1 : 0000000000000000 x0 : ffff00001b13a120
[ 7.282000] Call trace:
[ 7.284456] drm_mode_config_cleanup+0x54/0x300
[ 7.289008] drm_mode_config_init_release+0x10/0x20
[ 7.293900] drm_managed_release+0xa4/0x13c
[ 7.298097] drm_dev_put.part.0+0x90/0xc0
[ 7.302127] drm_dev_put+0x14/0x2c
[ 7.305541] imx_drm_bind+0xbc/0x200
[ 7.309129] try_to_bring_up_master+0x214/0x2e0
[ 7.313714] __component_add+0xa0/0x18c
...
Upstream-Status: Inappropriate [Other]
The upstream imx8qm-ldb driver is a complete rewrite, the bind() calls
are not present as part of the driver.
Upstream: drivers/gpu/drm/bridge/imx/{imx8qm-ldb-drv.c|imx8qm-ldb.c}
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
When the FW is already loaded and running on the uCPU access to
IRAM/DRAM from the Cortex A core is no longer granted.
Trying to load the FW to IRAM/DRAM results in a asynchronous abort.
Fix this by loading the FW only if the uCPU is still in reset.
If the reset is deasserted assume that the FW is already loaded
and do nothing.
Note that asserting the reset and enabling access to IRAM/DRAM by
writing '7' to APB_CTRL seems to be not enough to allow (re) writing
the FW.
The error was triggered by enabling both LVDS and HDMI. This resulted
in cdns_mhdp_imx_probe being called twice, returning EPROBE_DEFER
on the first invocation and then on the second invocation the FW is
already loaded and the uCPU started.
[ 7.407427] SError Interrupt on CPU0, code 0x00000000bf000002 -- SError
[ 7.407443] CPU: 0 PID: 200 Comm: kworker/u10:4 Tainted: G C O 5.15.129-6.4.0-devel+git.3311382cb124 #1
[ 7.407452] Hardware name: Toradex Apalis iMX8QP V1.1 on Apalis Evaluation Board (DT)
[ 7.407458] Workqueue: events_unbound deferred_probe_work_func
[ 7.407478] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 7.407486] pc : mutex_unlock+0x44/0x70
[ 7.407498] lr : cdns_mhdp_bus_write+0xa4/0x100 [cdns_mhdp_drmcore]
[ 7.407536] sp : ffff80000b19b910
[ 7.407539] x29: ffff80000b19b910 x28: ffff00000324e550 x27: ffff00001b2df700
[ 7.407549] x26: 0000000000000000 x25: ffff80000109f1c0 x24: ffff000003a2a120
[ 7.407558] x23: ffff000003a28080 x22: 0000000022222211 x21: ffff000003a28d88
[ 7.407567] x20: 0000000000000004 x19: ffff000003a28080 x18: 0000000000000001
[ 7.407576] x17: 3038363236353a32 x16: 3a64706e65673a64 x15: 00007de44ad2f95c
[ 7.407584] x14: 0000000000000008 x13: 0000000000000008 x12: 0000000000000000
[ 7.407593] x11: 0000000000000001 x10: 00000000000009e0 x9 : ffff80000b19b810
[ 7.407601] x8 : ffff000002801880 x7 : ffff00007fb0a440 x6 : 0000000000000000
[ 7.407610] x5 : 0000000000220000 x4 : 0000000000000000 x3 : ffff000003a28d88
[ 7.407618] x2 : 0000000000000000 x1 : ffff000002800e40 x0 : ffff000002800e40
[ 7.407629] Kernel panic - not syncing: Asynchronous SError Interrupt
[ 7.407634] CPU: 0 PID: 200 Comm: kworker/u10:4 Tainted: G C O 5.15.129-6.4.0-devel+git.3311382cb124 #1
[ 7.407641] Hardware name: Toradex Apalis iMX8QP V1.1 on Apalis Evaluation Board (DT)
[ 7.407644] Workqueue: events_unbound deferred_probe_work_func
[ 7.407652] Call trace:
[ 7.407654] dump_backtrace+0x0/0x1e0
[ 7.407667] show_stack+0x18/0x40
[ 7.407674] dump_stack_lvl+0x68/0x84
[ 7.407683] dump_stack+0x18/0x34
[ 7.407690] panic+0x188/0x348
[ 7.407696] add_taint+0x0/0xc0
[ 7.407706] arm64_serror_panic+0x6c/0x7c
[ 7.407711] do_serror+0x58/0x5c
[ 7.407716] el1h_64_error_handler+0x30/0x50
[ 7.407722] el1h_64_error+0x78/0x7c
[ 7.407728] mutex_unlock+0x44/0x70
[ 7.407734] cdns_mhdp_firmware_write_section+0x74/0xa0 [cdns_mhdp_imx]
[ 7.407749] cdns_mhdp_firmware_init_imx8qm+0xac/0x1c0 [cdns_mhdp_imx]
[ 7.407759] __cdns_hdmi_probe+0x174/0x37c [cdns_mhdp_drmcore]
[ 7.407786] cdns_hdmi_bind+0x28/0x90 [cdns_mhdp_drmcore]
[ 7.407810] cdns_mhdp_imx_bind+0xe4/0x170 [cdns_mhdp_imx]
[ 7.407821] component_bind_all+0x124/0x284
[ 7.407829] imx_drm_bind+0x15c/0x20c
[ 7.407837] try_to_bring_up_master+0x228/0x314
[ 7.407843] __component_add+0xa0/0x18c
[ 7.407849] component_add+0x14/0x20
[ 7.407855] cdns_mhdp_imx_probe+0x1c/0x30 [cdns_mhdp_imx]
[ 7.407865] platform_probe+0x68/0xe0
[ 7.407872] really_probe+0xbc/0x46c
[ 7.407877] __driver_probe_device+0x104/0x160
[ 7.407883] driver_probe_device+0x40/0x120
[ 7.407888] __device_attach_driver+0xbc/0x160
[ 7.407894] bus_for_each_drv+0x78/0xd0
[ 7.407903] __device_attach+0xa8/0x1e4
[ 7.407909] device_initial_probe+0x14/0x20
[ 7.407914] bus_probe_device+0x98/0xa0
[ 7.407920] deferred_probe_work_func+0x94/0xe4
[ 7.407925] process_one_work+0x1d0/0x374
[ 7.407932] worker_thread+0x13c/0x490
[ 7.407937] kthread+0x150/0x160
[ 7.407945] ret_from_fork+0x10/0x20
[ 7.407954] SMP: stopping secondary CPUs
[ 7.411611] Kernel Offset: disabled
[ 7.411613] CPU features: 0x4,000820b1,20000846
[ 7.411618] Memory Limit: none
Upstream-Status: Inappropriate [other]
Upstream does not have a driver for the cadence HDMI IP.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Several cadence API functions are missing mutex protection. Adding the
missing mutex calls in cadence API functions to prevent unstable display
behavior.
Signed-off-by: Oliver F. Brown <oliver.brown@oss.nxp.com>
Upstream-Status: Inappropriate [other]
Upstream does not have a driver for the cadence HDMI IP.
Cherry picked from NXP downstream commit ce02e24ef317a3bb24b056cbb650e0e314663ffc.
Neither the missing mutex calls nor the double mutex unlock in an
error path were showing negative effects in our known use cases.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Return EPROBE_DEFER in the probe function if the LDB bridge is missing
some of its child bridges. The current implementation returns
EPROBE_DEFER in the bind function, which is incorrect because the kernel
assumes the driver is fully functional when bind is called. This results
in a deferal loop if native HDMI and the ldb bridge are enabled that
looks as follows:
dwhdmi-imx 32fd8000.hdmi: Detected HDMI TX controller v2.13a with HDCP (samsung_dw_hdmi_phy2)
dwhdmi-imx 32fd8000.hdmi: registered DesignWare HDMI I2C bus driver
imx-drm display-subsystem: bound imx-lcdifv3-crtc.0 (ops lcdifv3_crtc_ops)
imx-drm display-subsystem: bound imx-lcdifv3-crtc.1 (ops lcdifv3_crtc_ops)
dwhdmi-imx 32fd8000.hdmi: Detected HDMI TX controller v2.13a with HDCP (samsung_dw_hdmi_phy2)
dwhdmi-imx 32fd8000.hdmi: registered DesignWare HDMI I2C bus driver
...
Upstream-Status: Inappropriate [Other]
The upstream imx8mp-ldb driver is a complete rewrite of the downstream
one and is most likely not affected because there is no bind:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/bridge/fsl-ldb.c
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
|
|
Add supplies to the driver that can be used to turn the Lontium lt8912b
on and off. It can have up to 7 independent supplies, we add them all
and enable/disable them with bulk_enable/disable.
Upstream-Status: Backport [f6d8a80f1d10ff01cff3ac26e242165a270bbbad]
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20231115121338.22959-4-francesco@dolcini.it
|
|
Add support for suspend and resume. The lt8912b will power off when
going into suspend and power on when resuming.
Upstream-Status: Backport [0b82a2b70f890e8dd7a46dfbfcce00bd7e434762]
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20231115121338.22959-2-francesco@dolcini.it
|
|
When unloading the module the driver crashes because it is still
registered and used in the drm chain. This patch fixes it detaching and
disabling the bridge before removing the bridge.
Upstream-Status: Inappropriate [other]
The upstream driver uses devm functions and is most likely not affected
by this issue. However, kernel 5.15 does not support them yet.
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
|
|
If PLL locking failed, the regulator needs to be disabled again.
Upstream-Status: Backport [8a91b29f1f50ce7742cdbe5cf11d17f128511f3f]
Fixes: 5664e3c907e2 ("drm/bridge: ti-sn65dsi83: Add vcc supply regulator support")
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230504065316.2640739-1-alexander.stein@ew.tq-group.com
|
|
VCC needs to be enabled before releasing the enable GPIO.
Upstream-Status: Backport [5664e3c907e20523cda622268716867e77648d0c]
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211213133626.2498056-5-alexander.stein@ew.tq-group.com
|
|
The enable signal may not be controllable by the kernel. Make it
optional.
This is a similar to commit bbda1704fc15 ("drm/bridge: ti-sn65dsi86: Make
enable GPIO optional")
Upstream-Status: Backport [5995aef006698bb639547a439f47492de5c37f05]
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211213133626.2498056-3-alexander.stein@ew.tq-group.com
|
|
Commit 24417d5b0c00 ("drm/bridge: ti-sn65dsi83: Implement .detach
callback") moved the unregistration of the bridge DSI device and bridge
itself to the detach callback.
While this is correct for the DSI device detach and unregistration, the
bridge is added in the driver probe, and should thus be removed as part
of its remove callback.
Upstream-Status: Backport [c05f1a4e2c4b8a217b448828c4e59fb47454dc75]
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Fixes: 24417d5b0c00 ("drm/bridge: ti-sn65dsi83: Implement .detach callback")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20211025151536.1048186-14-maxime@cerno.tech
|
|
Current code always sets reset line low in .pre_enable callback and
holds it low for 10ms. This is sub-optimal and increases the time
between enablement of the DSI83 and valid LVDS clock.
Rework the reset handling such that the reset line is held low for 10ms
both in probe() of the driver and .disable callback, which guarantees
that the reset line was always held low for more than 10ms and therefore
the reset line timing requirement is satisfied. Furthermore, move the
reset handling into .enable callback so the entire DSI83 initialization
is now in one place.
This reduces DSI83 enablement delay by up to 10ms.
Upstream-Status: Backport [30a46873941f1422e9169c9e38d4874365054c13]
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Robert Foss <robert.foss@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211016210402.171595-1-marex@denx.de
|
|
Move detach implementation from sn65dsi83_remove() to dedicated
.detach callback. There is no functional change to the code, but
that detach is now in the correct location.
Upstream-Status: Backport [24417d5b0c006fd4208284f3462f4012ae79151c]
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Robert Foss <robert.foss@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210907024038.871299-1-marex@denx.de
|
|
Setting the porch values for the Lontium LT8912B does not work properly.
So we need a similar workaround as for the RM68200 and HX8394F until NXP
fixes it by using some magic formula, see commit a8ac1d81bbed ("LF-4250
drm/bridge: nwl-dsi: Workaround RM68200 panel display shift issue")
Unfortunately, the exact same workaround does not work. The applied
workaround was found by trial and error. The only known non-working
resolution is 640x480.
Upstream-Status: Inappropriate [other]
This fix only applies to downstream kernel. The upstream kernel does not
support the NXP i.MX8X MIPI DSI interface yet. A support request at NXP
is pending:
https://community.nxp.com/t5/i-MX-Graphics/i-MX8X-MIPI-DSI-Display-hsync-active-front-and-back-porch-issue/m-p/1737270
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
|
|
Do not generate the HS front and back porch gaps, the HSA gap and
EOT packet, as per "SN65DSI83 datasheet SLLSEC1I - SEPTEMBER 2012
- REVISED OCTOBER 2020", page 22, these packets are not required.
This makes the TI SN65DSI83 bridge work with Samsung DSIM on i.MX8MN.
Upstream-Status: Backport [ca161b259cc84fe1f4a2ce4c73c3832cf6f713f1]
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230403190242.224490-1-marex@denx.de
|
|
Make sure to enable the clk_pixel clock during bind so that all other
driver in the display pipeline can rely on it. Without this change we
might see ghosting effects in around 10% of the reboots because
something in the display pipeline runs out of sync. With this change we
don't disable the clk_pixel when the display is turned off so this might
increase the power consumption in standby mode a bit. However, it would
require some bigger changes in the display pipeline to allow this.
Upstream-Status: Inappropriate [other]
The dpu is currently only supported in the downstream kernel. A fix will
most likely be applied by NXP to the downstream kernel. A similar patch
was provided by them but it breaks the DPMS off/standby mode. See this
ticket for more information:
https://support.nxp.com/s/case/5002p00002vUMOL/ghosting-effect-on-parallel-rgb-interface
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
|
|
Merge branch 5.15-2-2.x-imx from https://github.com/Freescale/linux-fslc that
was merged with v5.15.129 tag.
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
|
|
This is the 5.15.129 stable release
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
|
|
This is the 5.15.128 stable release
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
|
|
This is the 5.15.127 stable release
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
|
|
This is the 5.15.126 stable release
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
|
|
Set a pixel clock tolerance of 10% for the DSI interface of the i.MX 8MM
SoCs. There are some resolutions e.g. 1280x1024@60 Hz that do not work
without this commit.
Upstream-Status: Pending
This driver is not upstream and probably never will. It looks like the
function will become part of mxsfb. They don't verify the pixel clock
frequency there.
Related-to: ELB-4728
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
|
|
Set a pixel clock tolerance of 10% for the DSI interface of the i.MX 8MP
SoCs. There are some resolutions e.g. 1280x1024@60 Hz that do not work
without this commit.
Upstream-Status: Pending
This driver is not upstream and probably never will. It looks like the
function will become part of mxsfb. They don't verify the pixel clock
frequency there.
Related-to: ELB-4728
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
|
|
Set a pixel clock tolerance of 10% for the native HDMI interface of the
i.MX 8MP SoCs. There are some resolutions e.g. 1280x1024@60 Hz that do
not work without this commit.
Upstream-Status: Pending
The dw_hdmi-imx.c file is available upstream but they do not verify the
pixel clock frequency. Adding this check would harm more than it solves.
Related-to: ELB-4728
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
|
|
Loading the hdmi firmware from kernel is broken. The firmware is loaded
from filesystem but never sent to the hdmi controller. This commit fixes
it by waiting for the firmware load to complete and afterwards transfer
it to the controller.
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
Upstream-Status: Pending
Downstream specific, i.MX 8 HDMI subsystem not yet in upstream.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
The HDMI PHY driver currently can only generate a discrete set of
pixelclock frequencies. Any mode read from a monitor's EDID with a non
matching frequency is rejected.
Change that to find the closest possible frequency and accept the mode
if it deviates less than 6%. 6% is chosen as with that any pixelclock
in the range of 22.25Mhz - 297MHz should be accepted.
Related-to: ELB-4015
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
(cherry picked from commit c6944a48583f6dc2d698df387fd648075491bf81)
Upstream-Status: Inappropriate [Downstream specific, i.MX 8M Plus HDMI subsystem not yet ready]
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Enable hot plug detection when it is available on the HDMI port.
Without this connecting to a different monitor with incompatible timing
before the 10 seconds poll period will lead to a broken display output.
Upstream-Status: Backport [3b0a01a6a5224ed9b3f69f44edaa889b2e2b9779]
Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
|
|
This reverts commit d021d751c14752a0266865700f6f212fab40a18c.
Re-enable the data-mapping property which was already used in the
5.4-2.3.0 downstream kernel.
In addition to the revert set bpc from the data-mapping value
as a WARN_ON is printed if missing.
Additionally fix mapping variable used uninitialized.
If a panel-dpi node does not have the data-mapping property defined an
uninitalized pointer is used with strcmp resulting in a kernel crash
during boot.
(backtrace from upstream 6.0 kernel)
[ 6.509726] 8<--- cut here ---
[ 6.513351] Unable to handle kernel NULL pointer dereference at virtual address 00000013
[ 6.522189] [00000013] *pgd=00000000
[ 6.526111] Internal error: Oops: 5 [#1] SMP ARM
[ 6.530833] Modules linked in:
[ 6.533983] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-6.0.0-devel+git.4fe89d07dcc2 #1
[ 6.542483] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
[ 6.548768] PC is at strcmp+0x0/0x34
[ 6.552449] LR is at panel_dpi_probe+0xc4/0x1f0
[ 6.557092] pc : [<c0640e50>] lr : [<c0760dc4>] psr: 60000013
[ 6.563470] sp : f083dcc0 ip : 00000001 fp : c15004d0
[ 6.568791] r10: 00000000 r9 : ef7f4d08 r8 : c2178000
[ 6.574115] r7 : c230b740 r6 : c256d100 r5 : 00000013 r4 : c256b4c0
[ 6.580757] r3 : 00000000 r2 : c2178000 r1 : c12bd7f0 r0 : 00000013
[ 6.587399] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 6.594659] Control: 10c5387d Table: 8000406a DAC: 00000051
[ 6.600507] Register r0 information: non-paged memory
[ 6.605676] Register r1 information: non-slab/vmalloc memory
[ 6.611457] Register r2 information: slab task_struct start c2178000 pointer offset 0
[ 6.619488] Register r3 information: NULL pointer
[ 6.624296] Register r4 information: slab kmalloc-128 start c256b480 pointer offset 64 size 128
[ 6.633208] Register r5 information: non-paged memory
[ 6.638367] Register r6 information: slab kmalloc-192 start c256d0c0 pointer offset 64 size 192
[ 6.647278] Register r7 information: slab kmalloc-256 start c230b700 pointer offset 64 size 256
[ 6.656191] Register r8 information: slab task_struct start c2178000 pointer offset 0
[ 6.664207] Register r9 information: non-slab/vmalloc memory
[ 6.669981] Register r10 information: NULL pointer
[ 6.674876] Register r11 information: non-slab/vmalloc memory
[ 6.680738] Register r12 information: non-paged memory
[ 6.685987] Process swapper/0 (pid: 1, stack limit = 0xaf192ddd)
[ 6.692202] Stack: (0xf083dcc0 to 0xf083e000)
[ 6.696672] dcc0: 00000000 c0e2f724 00000000 c12b606c 00000013 c0a01820 f083dd08 00000001
[ 6.705001] dce0: 00000000 c2178000 c17eea20 c0a06930 c230b7f4 c2178000 00000000 9fb7a78a
[ 6.713328] dd00: c230b740 c2112810 c1e74008 c2178000 00000000 c13c9e68 c1802000 c076116c
[ 6.721654] dd20: c21787a0 9fb7a78a c2178000 c2178000 c156455c f083dd50 2e266000 c1799dd4
[ 6.729980] dd40: 00000000 60000093 00000000 c018a198 00000001 00000080 00000000 00000001
[ 6.738303] dd60: c21787c0 c0e236f8 c2178000 c21787c0 00000001 c0181cac c2178000 c1799dd4
[ 6.746629] dd80: c2178000 c156455c c0e2f724 c17de9e0 a0000013 c0186f08 c0a0167c 00000001
[ 6.754952] dda0: 00000001 c2178000 c156a29c c021e0e8 a0000013 c1799dc4 a0000013 c1799dc4
[ 6.763277] ddc0: c0f7e79c c0e2f724 c0f7e860 9fb7a78a c0f7e79c 00000000 c2112810 c1766a80
[ 6.771602] dde0: 00000000 c17eea20 c13c9e68 c1802000 c15004d0 c079113c 00000000 c2112810
[ 6.779927] de00: c1766a80 00000000 c17eea20 c078e168 c21129bc c079e2c0 c2112810 c1766a80
[ 6.788250] de20: c2112810 00000000 c256b358 c078e534 c0f7e79c 9fb7a78a c0f7e860 c1e76200
[ 6.796577] de40: c2112810 c2112810 00000000 c256b358 c13c9e68 c078e6d4 c2112854 c2112810
[ 6.804900] de60: c1766a80 c2178000 c256b358 c078eedc 00000000 c1766a80 c078ee30 c2178000
[ 6.813226] de80: c256b358 c078c094 c20a98e4 c20a98b0 c2242054 9fb7a78a c20a98e4 c1766a80
[ 6.821550] dea0: c256b300 00000000 c1767dd8 c078d50c c12be0c8 c0e2f660 00000000 c1766a80
[ 6.829875] dec0: 00000000 c17ddb00 c1608fcc 00000000 c13c9e68 c078fe98 c2178000 c1532458
[ 6.838198] dee0: c17ddb00 c1532468 c2178000 c01022a4 c21f6067 c21f605a c21f6059 c014be00
[ 6.846523] df00: c2001300 c21f6000 00000129 c12f2658 c15004d0 00000000 c2178000 00000006
[ 6.854846] df20: 00000006 00000000 c2178000 c17ddb00 c1608fcc c1549870 c1549854 9fb7a78a
[ 6.863171] df40: c15638d4 00000007 c21f6000 c1549874 c1549854 c13c9e68 c1802000 c1501328
[ 6.871494] df60: 00000006 00000006 00000000 c15004d0 00000000 00000129 00000000 c1608f80
[ 6.879820] df80: c0e24474 00000000 00000000 00000000 00000000 00000000 00000000 c0e24488
[ 6.888142] dfa0: 00000000 c0e24474 00000000 c0100128 00000000 00000000 00000000 00000000
[ 6.896465] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 6.904788] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[ 6.913110] strcmp from panel_dpi_probe+0xc4/0x1f0
[ 6.918132] panel_dpi_probe from panel_simple_probe+0x27c/0x604
[ 6.924279] panel_simple_probe from platform_probe+0x58/0xbc
[ 6.930162] platform_probe from really_probe+0xd8/0x410
Upstream-Status: denied [Alternative solution being discused]
https://lore.kernel.org/all/20220628181838.2031-1-max.oss.09@gmail.com/
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Add comments on the lt8912_write_lvds_config() config to document the
current settings and to make it clear that this is a hardcoded
configuration not relevant for the HDMI output (could be removed without
affecting the HDMI port).
No changes on the actual register writes.
Upstream-Status: Backport [fc44f3636a4db6544fd1532280e8adcd1ef13ba2]
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
|
|
In video mode, mode flag combinations with both MIPI_DSI_MODE_VIDEO_BURST
and MIPI_DSI_MODE_VIDEO_SYNC_PULSE set are invalid. This complies with
the description of the SyncInform bit in the DSI_CONFIG register -
'1 = Pulse mode (non burst only)'.
Without this patch, the original check takes the case where neither
MIPI_DSI_MODE_VIDEO_BURST nor MIPI_DSI_MODE_VIDEO_SYNC_PULSE are set
as invalid, which makes the 'Non-Burst Mode with Sync Events' wrongly
unsupported.
Reported-by: Arun Baskar Gnanapragasam <arunbaskar.gnanapragasam@nxp.com>
Cc: Sandor Yu <Sandor.yu@nxp.com>
Reviewed-by: Sandor Yu <Sandor.yu@nxp.com>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
|
|
Bring cdn-dp driver to the version we found in v5.15.125 tag.
Fix build error using defconfig.
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
|
|
commit a337b64f0d5717248a0c894e2618e658e6a9de9f upstream.
Infinite waits for completion of GPU activity have been observed in CI,
mostly inside __i915_active_wait(), triggered by igt@gem_barrier_race or
igt@perf@stress-open-close. Root cause analysis, based of ftrace dumps
generated with a lot of extra trace_printk() calls added to the code,
revealed loops of request dependencies being accidentally built,
preventing the requests from being processed, each waiting for completion
of another one's activity.
After we substitute a new request for a last active one tracked on a
timeline, we set up a dependency of our new request to wait on completion
of current activity of that previous one. While doing that, we must take
care of keeping the old request still in memory until we use its
attributes for setting up that await dependency, or we can happen to set
up the await dependency on an unrelated request that already reuses the
memory previously allocated to the old one, already released. Combined
with perf adding consecutive kernel context remote requests to different
user context timelines, unresolvable loops of await dependencies can be
built, leading do infinite waits.
We obtain a pointer to the previous request to wait upon when we
substitute it with a pointer to our new request in an active tracker,
e.g. in intel_timeline.last_request. In some processing paths we protect
that old request from being freed before we use it by getting a reference
to it under RCU protection, but in others, e.g. __i915_request_commit()
-> __i915_request_add_to_timeline() -> __i915_request_ensure_ordering(),
we don't. But anyway, since the requests' memory is SLAB_FAILSAFE_BY_RCU,
that RCU protection is not sufficient against reuse of memory.
We could protect i915_request's memory from being prematurely reused by
calling its release function via call_rcu() and using rcu_read_lock()
consequently, as proposed in v1. However, that approach leads to
significant (up to 10 times) increase of SLAB utilization by i915_request
SLAB cache. Another potential approach is to take a reference to the
previous active fence.
When updating an active fence tracker, we first lock the new fence,
substitute a pointer of the current active fence with the new one, then we
lock the substituted fence. With this approach, there is a time window
after the substitution and before the lock when the request can be
concurrently released by an interrupt handler and its memory reused, then
we may happen to lock and return a new, unrelated request.
Always get a reference to the current active fence first, before
replacing it with a new one. Having it protected from premature release
and reuse, lock it and then replace with the new one but only if not
yet signalled via a potential concurrent interrupt nor replaced with
another one by a potential concurrent thread, otherwise retry, starting
from getting a reference to the new current one. Adjust users to not
get a reference to the previous active fence themselves and always put the
reference got by __i915_active_fence_set() when no longer needed.
v3: Fix lockdep splat reports and other issues caused by incorrect use of
try_cmpxchg() (use (cmpxchg() != prev) instead)
v2: Protect request's memory by getting a reference to it in favor of
delegating its release to call_rcu() (Chris)
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8211
Fixes: df9f85d8582e ("drm/i915: Serialise i915_active_fence_set() with itself")
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: <stable@vger.kernel.org> # v5.6+
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230720093543.832147-2-janusz.krzysztofik@linux.intel.com
(cherry picked from commit 946e047a3d88d46d15b5c5af0414098e12b243f7)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 14abdfae508228a7307f7491b5c4215ae70c6542 upstream.
For multiple commands the driver was not correctly validating the shader
stages resulting in possible kernel oopses. The validation code was only.
if ever, checking the upper bound on the shader stages but never a lower
bound (valid shader stages start at 1 not 0).
Fixes kernel oopses ending up in vmw_binding_add, e.g.:
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 2443 Comm: testcase Not tainted 6.3.0-rc4-vmwgfx #1
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
RIP: 0010:vmw_binding_add+0x4c/0x140 [vmwgfx]
Code: 7e 30 49 83 ff 0e 0f 87 ea 00 00 00 4b 8d 04 7f 89 d2 89 cb 48 c1 e0 03 4c 8b b0 40 3d 93 c0 48 8b 80 48 3d 93 c0 49 0f af de <48> 03 1c d0 4c 01 e3 49 8>
RSP: 0018:ffffb8014416b968 EFLAGS: 00010206
RAX: ffffffffc0933ec0 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 00000000ffffffff RSI: ffffb8014416b9c0 RDI: ffffb8014316f000
RBP: ffffb8014416b998 R08: 0000000000000003 R09: 746f6c735f726564
R10: ffffffffaaf2bda0 R11: 732e676e69646e69 R12: ffffb8014316f000
R13: ffffb8014416b9c0 R14: 0000000000000040 R15: 0000000000000006
FS: 00007fba8c0af740(0000) GS:ffff8a1277c80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000007c0933eb8 CR3: 0000000118244001 CR4: 00000000003706e0
Call Trace:
<TASK>
vmw_view_bindings_add+0xf5/0x1b0 [vmwgfx]
? ___drm_dbg+0x8a/0xb0 [drm]
vmw_cmd_dx_set_shader_res+0x8f/0xc0 [vmwgfx]
vmw_execbuf_process+0x590/0x1360 [vmwgfx]
vmw_execbuf_ioctl+0x173/0x370 [vmwgfx]
? __drm_dev_dbg+0xb4/0xe0 [drm]
? __pfx_vmw_execbuf_ioctl+0x10/0x10 [vmwgfx]
drm_ioctl_kernel+0xbc/0x160 [drm]
drm_ioctl+0x2d2/0x580 [drm]
? __pfx_vmw_execbuf_ioctl+0x10/0x10 [vmwgfx]
? do_fault+0x1a6/0x420
vmw_generic_ioctl+0xbd/0x180 [vmwgfx]
vmw_unlocked_ioctl+0x19/0x20 [vmwgfx]
__x64_sys_ioctl+0x96/0xd0
do_syscall_64+0x5d/0x90
? handle_mm_fault+0xe4/0x2f0
? debug_smp_processor_id+0x1b/0x30
? fpregs_assert_state_consistent+0x2e/0x50
? exit_to_user_mode_prepare+0x40/0x180
? irqentry_exit_to_user_mode+0xd/0x20
? irqentry_exit+0x3f/0x50
? exc_page_fault+0x8b/0x180
entry_SYSCALL_64_after_hwframe+0x72/0xdc
Signed-off-by: Zack Rusin <zackr@vmware.com>
Cc: security@openanolis.org
Reported-by: Ziming Zhang <ezrakiez@gmail.com>
Testcase-found-by: Niels De Graef <ndegraef@redhat.com>
Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support")
Cc: <stable@vger.kernel.org> # v4.3+
Reviewed-by: Maaz Mombasawala<mombasawalam@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616190934.54828-1-zack@kde.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 5a25cefc0920088bb9afafeb80ad3dcd84fe278b ]
[Why & How]
If there is no TG allocation we can dereference a NULL pointer when
checking if the TG is enabled.
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: Alan Liu <haoping.liu@amd.com>
Signed-off-by: Taimur Hassan <syed.hassan@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 2513ed4f937999c0446fd824f7564f76b697d722 ]
[Why]
When booting, the driver waits for the MPC idle bit to be set as part of
pipe initialization. However, on some systems this occurs before OTG is
enabled, and since the MPC idle bit won't be set until the vupdate
signal occurs (which requires OTG to be enabled), this never happens and
the wait times out. This can add hundreds of milliseconds to the boot
time.
[How]
Do not wait for mpc idle if tg is disabled
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Pavle Kotarac <Pavle.Kotarac@amd.com>
Signed-off-by: Josip Pavic <Josip.Pavic@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Stable-dep-of: 5a25cefc0920 ("drm/amd/display: check TG is non-null before checking if enabled")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
This is the 5.15.124 stable release
Conflicts:
drivers/usb/dwc3/core.h
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
|
|
This is the 5.15.123 stable release
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
|
|
This is the 5.15.121 stable release
Conflicts:
drivers/clk/imx/clk-imx8mn.c
drivers/pwm/pwm-imx-tpm.c
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
|
|
This is the 5.15.120 stable release
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
|
|
This is the 5.15.119 stable release
Conflicts:
arch/arm/boot/dts/imx7d-sdb.dts
drivers/spi/spi-fsl-lpspi.c
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
|
|
This is the 5.15.118 stable release
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
|
|
This is the 5.15.117 stable release
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
|
|
This is the 5.15.116 stable release
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
|
|
This is the 5.15.113 stable release
Conflicts:
sound/soc/fsl/fsl_micfil.c
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
|
|
This is the 5.15.112 stable release
|
|
This is the 5.15.111 stable release
|
|
This is the 5.15.110 stable release
|
|
This is the 5.15.109 stable release
Conflicts:
arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
|
|
This is the 5.15.108 stable release
Conflicts:
drivers/i2c/busses/i2c-imx-lpi2c.c
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
|
