aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/bridge
AgeCommit message (Collapse)AuthorFilesLines
2023-06-27drm/bridge: dw-hdmi: truly enforce 420-only formats when drm mode demands itAdrián Larumbe1-3/+4
The current output bus format selection logic is enforcing YUV420 even when the drm mode allows for other bus formats as well. Fix it by adding check for 420-only drm modes. Signed-off-by: Adrián Larumbe <[email protected]> Acked-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/6e6a217c180584a67ed7992c785764ba54af9151.1687702042.git.adrian.larumbe@collabora.com
2023-06-27drm/bridge: dw-hdmi: change YUV420 selection logic at clock setupAdrián Larumbe1-0/+6
Right now clocking value selection code is prioritising RGB, YUV444 modes over YUV420 for HDMI2 sinks. However, because of the bus format selection procedure in dw-hdmi, for HDMI2 sinks YUV420 is the format that will always be picked during the drm bridge chain check stage. Later on dw_hdmi_setup will configure a colour space based on the bus format that doesn't match the pixel value we had calculated as described above. Fix it by bringing back dw-hdmi bus format check when picking the right pixel clock. Signed-off-by: Adrián Larumbe <[email protected]> Acked-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/6230bfae2cd97cf6527fc62ba5c850464919ccf8.1687702042.git.adrian.larumbe@collabora.com
2023-06-26drm/bridge: ti-sn65dsi86: Fix auxiliary bus lifetimeDouglas Anderson1-13/+22
Memory for the "struct device" for any given device isn't supposed to be released until the device's release() is called. This is important because someone might be holding a kobject reference to the "struct device" and might try to access one of its members even after any other cleanup/uninitialization has happened. Code analysis of ti-sn65dsi86 shows that this isn't quite right. When the code was written, it was believed that we could rely on the fact that the child devices would all be freed before the parent devices and thus we didn't need to worry about a release() function. While I still believe that the parent's "struct device" is guaranteed to outlive the child's "struct device" (because the child holds a kobject reference to the parent), the parent's "devm" allocated memory is a different story. That appears to be freed much earlier. Let's make this better for ti-sn65dsi86 by allocating each auxiliary with kzalloc and then free that memory in the release(). Fixes: bf73537f411b ("drm/bridge: ti-sn65dsi86: Break GPIO and MIPI-to-eDP bridge into sub-drivers") Suggested-by: Stephen Boyd <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20230613065812.v2.1.I24b838a5b4151fb32bccd6f36397998ea2df9fbb@changeid
2023-06-23drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDIDDouglas Anderson1-79/+0
In order to read the EDID from an eDP panel, you not only need to power on the bridge chip itself but also the panel. In the ps8640 driver, this was made to work by having the bridge chip manually power the panel on by calling pre_enable() on everything connectorward on the bridge chain. This worked OK, but... ...when trying to do the same thing on ti-sn65dsi86, feedback was that this wasn't a great idea. As a result, we designed the "DP AUX" bus. With the design we ended up with the panel driver itself was in charge of reading the EDID. The panel driver could power itself on and the bridge chip was able to power itself on because it implemented the DP AUX bus. Despite the fact that we came up with a new scheme, implemented in on ti-sn65dsi86, and even implemented it on parade-ps8640, we still kept the old code around. This was because the new scheme required a DT change. Previously the panel was a simple "platform_device" and in DT at the top level. With the new design the panel needs to be listed in DT under the DP controller node. The old code allowed us to properly fetch EDIDs with ps8640 with the old DTs. Unfortunately, the old code stopped working as of commit 102e80d1fa2c ("drm/bridge: ps8640: Use atomic variants of drm_bridge_funcs"). There are cases at bootup where connector->state->state is NULL and the kernel crashed at: * drm_atomic_bridge_chain_pre_enable * drm_atomic_get_old_bridge_state * drm_atomic_get_old_private_obj_state The crash went away at commit 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init order") which added a NULL check. However, even though we were no longer crashing the end result was that we weren't actually powering the panel on when we thought we were. Things could end up working (despite warning splats) if userspace was persistent and tried to get the mode again, but it wasn't great. A bit of digging was done to see if there was an easy fix but there was nothing obvious. Instead, the only device using ps8640 the "old" way had its DT updated so that the panel was no longer a simple "platform_deice". See commit c2d94f72140a ("arm64: dts: mediatek: mt8173-elm: Move display to ps8640 auxiliary bus") and commit 113b5cc06f44 ("arm64: dts: mediatek: mt8173-elm: remove panel model number in DT"). Let's delete the old broken code so nobody gets tempted to copy it or figure out how it works (since it doesn't). NOTE: from a device tree "purist" point of view, we're supposed to keep old device trees working and this patch is technically "against policy". Reasons I'm still proposing it anyway: 1. Officially, old mt8173-elm device trees worked via the "little white lie" approach. The DT would list an arbitrary/representative panel that would be used for power sequencing. The mode information in the panel driver would then be ignored / overridden by the EDID reading code in ps8640. I don't feel too terrible breaking DTs that contained the wrong "compatible" string to begin with. NOTE that any old device trees that _didn't_ lie about their compatible will still work because the mode information will come from the hardcoded panels in panel-edp. 2. The only users of the old code were Chromebooks and Chromebooks don't bake their DTs into the BIOS (they are bundled with the kernel). Thus we don't need to worry about breaking someone using an old DT with a new kernel. 3. The old code was broken anyway. If someone wants to fix the old code instead of deleting it then they have my blessing, but without a proper fix the old code isn't useful. Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20230616165517.v2.1.I7b8f60b3fbfda068f9bf452d584dc934494bfbfa@changeid
2023-06-22drm: bridge: dw_hdmi: fix connector access for scdcAdrián Larumbe1-4/+5
Commit 5d844091f237 ("drm/scdc-helper: Pimp SCDC debugs") changed the scdc interface to pick up an i2c adapter from a connector instead. However, in the case of dw-hdmi, the wrong connector was being used to pass i2c adapter information, since dw-hdmi's embedded connector structure is only populated when the bridge attachment callback explicitly asks for it. drm-meson is handling connector creation, so this won't happen, leading to a NULL pointer dereference. Fix it by having scdc functions access dw-hdmi's current connector pointer instead, which is assigned during the bridge enablement stage. Fixes: 5d844091f237 ("drm/scdc-helper: Pimp SCDC debugs") Signed-off-by: Adrián Larumbe <[email protected]> Reported-by: Lukas F. Hartmann <[email protected]> Acked-by: Neil Armstrong <[email protected]> [narmstrong: moved Fixes tag before first S-o-b and added Reported-by tag] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-22drm: bridge: dw-mipi-dsi: Fix enable/disable of DSI controllerOndrej Jirman1-12/+16
Before this patch, booting to Linux VT and doing a simple: echo 2 > /sys/class/graphics/fb0/blank echo 0 > /sys/class/graphics/fb0/blank would result in failures to re-enable the panel. Mode set callback is called only once during boot in this scenario, while calls to enable/disable callbacks are balanced afterwards. The driver doesn't work unless userspace calls modeset before enabling the CRTC/connector. This patch moves enabling of the DSI host from mode_set into pre_enable callback, and removes some old hacks where this bridge driver is directly calling into other bridge driver's callbacks. pre_enable_prev_first flag is set on the panel's bridge so that panel drivers will get their prepare function called between DSI host's pre_enable and enable callbacks, so that they get a chance to perform panel setup while DSI host is already enabled in command mode. Otherwise panel's prepare would be called before DSI host is enabled, and any DSI communication used in prepare callback would fail. With all these changes, the enable/disable sequence is now well balanced, and host's and panel's callbacks are called in proper order documented in the drm_panel API documentation without needing the old hacks. (Mainly that panel->prepare is called when DSI host is ready to allow the panel driver to send DSI commands and vice versa during disable.) Tested on Pinephone Pro. Trace of the callbacks follows. Before: [ 1.253882] dw-mipi-dsi-rockchip ff960000.dsi: mode_set [ 1.290732] panel-himax-hx8394 ff960000.dsi.0: prepare [ 1.475576] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 1.475593] panel-himax-hx8394 ff960000.dsi.0: enable echo 2 > /sys/class/graphics/fb0/blank [ 13.722799] panel-himax-hx8394 ff960000.dsi.0: disable [ 13.774502] dw-mipi-dsi-rockchip ff960000.dsi: post_disable [ 13.774526] panel-himax-hx8394 ff960000.dsi.0: unprepare echo 0 > /sys/class/graphics/fb0/blank [ 17.735796] panel-himax-hx8394 ff960000.dsi.0: prepare [ 17.923522] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 17.923540] panel-himax-hx8394 ff960000.dsi.0: enable [ 17.944330] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO [ 17.944335] panel-himax-hx8394 ff960000.dsi.0: sending command 0xb9 failed: -110 [ 17.944340] panel-himax-hx8394 ff960000.dsi.0: Panel init sequence failed: -110 echo 2 > /sys/class/graphics/fb0/blank [ 431.148583] panel-himax-hx8394 ff960000.dsi.0: disable [ 431.169259] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO [ 431.169268] panel-himax-hx8394 ff960000.dsi.0: Failed to enter sleep mode: -110 [ 431.169282] dw-mipi-dsi-rockchip ff960000.dsi: post_disable [ 431.169316] panel-himax-hx8394 ff960000.dsi.0: unprepare [ 431.169357] pclk_mipi_dsi0 already disabled echo 0 > /sys/class/graphics/fb0/blank [ 432.796851] panel-himax-hx8394 ff960000.dsi.0: prepare [ 432.981537] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 432.981568] panel-himax-hx8394 ff960000.dsi.0: enable [ 433.002290] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO [ 433.002299] panel-himax-hx8394 ff960000.dsi.0: sending command 0xb9 failed: -110 [ 433.002312] panel-himax-hx8394 ff960000.dsi.0: Panel init sequence failed: -110 ----------------------------------------------------------------------- After: [ 1.248372] dw-mipi-dsi-rockchip ff960000.dsi: mode_set [ 1.248704] dw-mipi-dsi-rockchip ff960000.dsi: pre_enable [ 1.285377] panel-himax-hx8394 ff960000.dsi.0: prepare [ 1.468392] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 1.468421] panel-himax-hx8394 ff960000.dsi.0: enable echo 2 > /sys/class/graphics/fb0/blank [ 16.210357] panel-himax-hx8394 ff960000.dsi.0: disable [ 16.261315] dw-mipi-dsi-rockchip ff960000.dsi: post_disable [ 16.261339] panel-himax-hx8394 ff960000.dsi.0: unprepare echo 0 > /sys/class/graphics/fb0/blank [ 19.161453] dw-mipi-dsi-rockchip ff960000.dsi: pre_enable [ 19.197869] panel-himax-hx8394 ff960000.dsi.0: prepare [ 19.382141] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 19.382158] panel-himax-hx8394 ff960000.dsi.0: enable (But depends on functionality intorduced in Linux 6.3, so this patch will not build on older kernels when applied to older stable branches.) Fixes: 46fc51546d44 ("drm/bridge/synopsys: Add MIPI DSI host controller bridge") Signed-off-by: Ondrej Jirman <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-22drm/bridge: tc358762: Handle HS/VS polarityMarek Vasut1-2/+25
Add support for handling the HS/VS sync signals polarity in the bridge driver, otherwise e.g. DSIM bridge feeds the TC358762 inverted polarity sync signals and the image is shifted to the left, up, and wobbly. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-22drm/bridge: tc358762: Guess the meaning of LCDCTRL bitsMarek Vasut1-3/+13
The register content and behavior is very similar to TC358764 VP_CTRL. All the bits except for unknown bit 6 also seem to match, even though the datasheet is just not available. Add a comment and reuse the bit definitions. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-22drm/bridge: tc358762: Instruct DSI host to generate HSE packetsMarek Vasut1-1/+1
This bridge seems to need the HSE packet, otherwise the image is shifted up and corrupted at the bottom. This makes the bridge work with Samsung DSIM on i.MX8MM and i.MX8MP. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-22drm/bridge: tc358762: Switch to atomic opsMarek Vasut1-6/+9
Switch the bridge driver over to atomic ops. No functional change. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-22drm/bridge: tc358762: Split register programming from pre-enable to enableMarek Vasut1-2/+9
Move the register programming part, which actually enables the bridge and makes it push data out of its DPI side, into the enable callback. The DSI host like DSIM may not be able to transmit commands in pre_enable, moving the register programming into enable assures it can transmit commands. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-22drm/bridge: tc358764: Use BIT() macro for actual bitsMarek Vasut1-6/+6
None of these four bits are bitfields, use BIT() macro and treat them as bits. No functional change. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-21drm/bridge: lt9611uxc: Add MODULE_FIRMWARE macroJuerg Haefliger1-1/+5
The module loads firmware so add a MODULE_FIRMWARE macro to provide that information via modinfo. Signed-off-by: Juerg Haefliger <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-19Merge drm/drm-next into drm-misc-nextThomas Zimmermann1-0/+4
Backmerging into drm-misc-next to get commit 2c1c7ba457d4 ("drm/amdgpu: support partition drm devices"), which is required to fix commit 0adec22702d4 ("drm: Remove struct drm_driver.gem_prime_mmap"). Signed-off-by: Thomas Zimmermann <[email protected]>
2023-06-19Backmerge tag 'v6.4-rc7' of ↵Dave Airlie1-0/+4
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next Linux 6.4-rc7 Need this to pull in the msm work. Signed-off-by: Dave Airlie <[email protected]>
2023-06-16drm/bridge: tc358764: Fix debug print parameter orderMarek Vasut1-1/+1
The debug print parameters were swapped in the output and they were printed as decimal values, both the hardware address and the value. Update the debug print to print the parameters in correct order, and use hexadecimal print for both address and value. Fixes: f38b7cca6d0e ("drm/bridge: tc358764: Add DSI to LVDS bridge driver") Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/bridge: ti-sn65dsi86: Avoid possible buffer overflowSu Hui1-0/+4
Smatch error:buffer overflow 'ti_sn_bridge_refclk_lut' 5 <= 5. Fixes: cea86c5bb442 ("drm/bridge: ti-sn65dsi86: Implement the pwm_chip") Signed-off-by: Su Hui <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-05drm/bridge: imx: turn imx8{qm,qxp}-ldb into single-object modulesMasahiro Yamada3-4/+0
With the previous fix, these modules are built from a single C file. Rename the source files so they match the module names. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Liu Ying <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-05drm/bridge: imx: fix mixed module-builtin objectMasahiro Yamada3-2/+25
With CONFIG_DRM_IMX8QM_LDB=m and CONFIG_DRM_IMX8QXP_LDB=y (or vice versa), imx-ldb-helper.o is linked to a module and also to vmlinux even though the expected CFLAGS are different between builtins and modules. This is the same situation as fixed by commit 637a642f5ca5 ("zstd: Fixing mixed module-builtin objects"). Split imx-ldb-helper.c into a separate module. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Liu Ying <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-01drm/bridge: tc358762: Add reset GPIO supportMarek Vasut1-0/+15
Add reset GPIO support. The reset GPIO is cleared after supply regulator was enabled, and set before supply regulator is disabled. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-31drm/bridge: display-connector: handle hdmi-pwr supplyDmitry Baryshkov1-26/+29
On some devices the +5V Power pin of the HDMI connector and/or the ESD protection logic is powered on by a separate regulator. Instead of declaring this regulator as always-on, make hdmi-connector support the additional hdmi-pwr supply. Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-31drm/bridge: display-connector: rename dp_pwr to connector_pwrDmitry Baryshkov1-9/+9
In preparation to adding support for the hdmi_pwr supply, rename dp_pwr structure field to the generic connector_pwr. Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-30drm: Switch i2c drivers back to use .probe()Uwe Kleine-König27-28/+28
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Kieran Bingham <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Martyn Welch <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-26drm: bridge: samsung-dsim: Support non-burst modeAdam Ford1-6/+19
The high-speed clock is hard-coded to the burst-clock frequency specified in the device tree. However, when using devices like certain bridge chips without burst mode and varying resolutions and refresh rates, it may be necessary to set the high-speed clock dynamically based on the desired pixel clock for the connected device. This also removes the need to set a clock speed from the device tree for non-burst mode operation, since the pixel clock rate is the rate requested from the attached device like a bridge chip. This should have no impact for people using burst-mode and setting the burst clock rate is still required for those users. If the burst clock is not present, change the error message to dev_info indicating the clock use the pixel clock. Signed-off-by: Adam Ford <[email protected]> Tested-by: Chen-Yu Tsai <[email protected]> Tested-by: Frieder Schrempf <[email protected]> Reviewed-by: Frieder Schrempf <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Reviewed-by: Jagan Teki <[email protected]> Tested-by: Jagan Teki <[email protected]> # imx8mm-icore Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-26drm: bridge: samsung-dsim: Dynamically configure DPHY timingAdam Ford1-7/+51
The DPHY timings are currently hard coded. Since the input clock can be variable, the phy timings need to be variable too. To facilitate this, we need to cache the hs_clock based on what is generated from the PLL. The phy_mipi_dphy_get_default_config_for_hsclk function configures the DPHY timings in pico-seconds, and a small macro converts those timings into clock cycles based on the hs_clk. Signed-off-by: Adam Ford <[email protected]> Signed-off-by: Lucas Stach <[email protected]> Tested-by: Chen-Yu Tsai <[email protected]> Tested-by: Frieder Schrempf <[email protected]> Reviewed-by: Frieder Schrempf <[email protected]> Tested-by: Michael Walle <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Reviewed-by: Jagan Teki <[email protected]> Tested-by: Jagan Teki <[email protected]> # imx8mm-icore Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-26drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHYAdam Ford1-0/+1
In order to support variable DPHY timings, it's necessary to enable GENERIC_PHY_MIPI_DPHY so phy_mipi_dphy_get_default_config can be used to determine the nominal values for a given resolution and refresh rate. Signed-off-by: Adam Ford <[email protected]> Tested-by: Frieder Schrempf <[email protected]> Reviewed-by: Frieder Schrempf <[email protected]> Tested-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-26drm: bridge: samsung-dsim: Fetch pll-clock-frequency automaticallyAdam Ford1-7/+15
Make the pll-clock-frequency optional. If it's present, use it to maintain backwards compatibility with existing hardware. If it is absent, read clock rate of "sclk_mipi" to determine the rate. Since it can be optional, change the message from an error to dev_info. Signed-off-by: Adam Ford <[email protected]> Tested-by: Chen-Yu Tsai <[email protected]> Tested-by: Frieder Schrempf <[email protected]> Reviewed-by: Frieder Schrempf <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Reviewed-by: Jagan Teki <[email protected]> Tested-by: Jagan Teki <[email protected]> # imx8mm-icore Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-26drm: bridge: samsung-dsim: Fix PMS Calculator on imx8m[mnp]Adam Ford1-2/+20
According to Table 13-45 of the i.MX8M Mini Reference Manual, the min and max values for M and the frequency range for the VCO_out calculator were incorrect. This information was contradicted in other parts of the mini, nano and plus manuals. After reaching out to my NXP Rep, when confronting him about discrepencies in the Nano manual, he responded with: "Yes it is definitely wrong, the one that is part of the NOTE in MIPI_DPHY_M_PLLPMS register table against PMS_P, PMS_M and PMS_S is not correct. I will report this to Doc team, the one customer should be take into account is the Table 13-40 DPHY PLL Parameters and the Note above." These updated values also match what is used in the NXP downstream kernel. To fix this, make new variables to hold the min and max values of m and the minimum value of VCO_out, and update the PMS calculator to use these new variables instead of using hard-coded values to keep the backwards compatibility with other parts using this driver. Fixes: 4d562c70c4dc ("drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano support") Signed-off-by: Adam Ford <[email protected]> Reviewed-by: Lucas Stach <[email protected]> Tested-by: Chen-Yu Tsai <[email protected]> Tested-by: Frieder Schrempf <[email protected]> Reviewed-by: Frieder Schrempf <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Reviewed-by: Jagan Teki <[email protected]> Tested-by: Jagan Teki <[email protected]> # imx8mm-icore Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-26drm: bridge: samsung-dsim: fix blanking packet size calculationLucas Stach1-3/+15
Scale the blanking packet sizes to match the ratio between HS clock and DPI interface clock. The controller seems to do internal scaling to the number of active lanes, so we don't take those into account. Signed-off-by: Lucas Stach <[email protected]> Signed-off-by: Adam Ford <[email protected]> Tested-by: Chen-Yu Tsai <[email protected]> Tested-by: Frieder Schrempf <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Reviewed-by: Jagan Teki <[email protected]> Tested-by: Jagan Teki <[email protected]> # imx8mm-icore Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-25drm/bridge: ti-sn65dsi83: Fix enable/disable flow to meet specFrieder Schrempf1-3/+16
The datasheet describes the following initialization flow including minimum delay times between each step: 1. DSI data lanes need to be in LP-11 and the clock lane in HS mode 2. toggle EN signal 3. initialize registers 4. enable PLL 5. soft reset 6. enable DSI stream 7. check error status register To meet this requirement we need to make sure the host bridge's pre_enable() is called first by using the pre_enable_prev_first flag. Furthermore we need to split enable() into pre_enable() which covers steps 2-5 from above and enable() which covers step 7 and is called after the host bridge's enable(). Signed-off-by: Frieder Schrempf <[email protected]> Fixes: ceb515ba29ba ("drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver") Tested-by: Alexander Stein <[email protected]> #TQMa8MxML/MBa8Mx Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-25drm: bridge: samsung-dsim: Fix i.MX8M enable flow to meet specFrieder Schrempf1-2/+23
According to the documentation [1] the proper enable flow is: 1. Enable DSI link and keep data lanes in LP-11 (stop state) 2. Disable stop state to bring data lanes into HS mode Currently we do this all at once within enable(), which doesn't allow to meet the requirements of some downstream bridges. To fix this we now enable the DSI in pre_enable() and force it into stop state using the FORCE_STOP_STATE bit in the ESCMODE register until enable() is called where we reset the bit. We currently do this only for i.MX8M as Exynos uses a different init flow where samsung_dsim_init() is called from samsung_dsim_host_transfer(). [1] https://docs.kernel.org/gpu/drm-kms-helpers.html#mipi-dsi-bridge-operation Signed-off-by: Frieder Schrempf <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Tested-by: Alexander Stein <[email protected]> #TQMa8MxML/MBa8Mx Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-25drm/bridge: tc358767: explicitly set readable registersAlexander Stein1-1/+194
This map was created from register map from datasheet (section 5.1.2). Unused registers are stated by address, so they show up in debugfs as well. Signed-off-by: Alexander Stein <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-23drm/bridge: dw-hdmi: Replace all non-returning strlcpy with strscpyAzeem Shaikh1-1/+1
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89 Signed-off-by: Azeem Shaikh <[email protected]> Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-23drm/bridge: anx7625: Prevent endless probe loopNícolas F. R. A. Prado1-40/+88
During probe, the driver registers i2c dummy devices and populates the aux bus, which registers a device for the panel. After doing that, the driver can still defer probe if needed. This ordering of operations is troublesome however, because the deferred probe work will retry probing all pending devices every time a new device is registered. Therefore, if modules need to be loaded in order to satisfy the dependencies for this driver to complete probe, the kernel will stall, since it'll keep trying to probe the anx7625 driver, but never succeed, given that modules would only be loaded after the deferred probe work completes. Two changes are required to avoid this issue: * Move of_find_mipi_dsi_host_by_node(), which can defer probe, to before anx7625_register_i2c_dummy_clients() and devm_of_dp_aux_populate_ep_devices(), which register devices. * Make use of the done_probing callback when populating the aux bus, so that the bridge registration is only done after the panel is probed. This is required because the panel might need to defer probe, but the aux bus population needs the i2c dummy devices working, so this call couldn't just be moved to an earlier point in probe. One caveat is that if the panel is described outside the aux bus, the probe loop issue can still happen, but we don't have a way to avoid it in that case since there's no callback available. With this patch applied, it's possible to boot on mt8192-asurada-spherion with CONFIG_DRM_ANALOGIX_ANX7625=y CONFIG_MTK_MMSYS=m CONFIG_BACKLIGHT_PWM=y and also with CONFIG_DRM_ANALOGIX_ANX7625=y CONFIG_MTK_MMSYS=y CONFIG_BACKLIGHT_PWM=m Fixes: adca62ec370c ("drm/bridge: anx7625: Support reading edid through aux channel") Fixes: 269332997a16 ("drm/bridge: anx7625: Return -EPROBE_DEFER if the dsi host was not found") Reported-by: "kernelci.org bot" <[email protected]> Signed-off-by: Nícolas F. R. A. Prado <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-22drm: bridge: samsung-dsim: Implement support for clock/data polarity swapMarek Vasut1-1/+26
Implement support for DSI clock and data lane DN/DP polarity swap by means of decoding 'lane-polarities' DT property. The controller does support DN/DP swap of clock lane and all data lanes, the controller does not support polarity swap of individual data lane bundles, add a check which verifies all data lanes have the same polarity. This has been validated on an imx8mm board that actually has the MIPI DSI clock lanes inverted. Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Fabio Estevam <[email protected]> Reviewed-by: Jagan Teki <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-17drm/bridge: tc358767: Switch to devm MIPI-DSI helpersAlexander Stein1-2/+2
DSI device registering and attaching needs to be undone upon deregistration. This fixes module unload/load. Fixes: bbfd3190b656 ("drm/bridge: tc358767: Add DSI-to-DPI mode support") Signed-off-by: Alexander Stein <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-16drm/bridge: tc358768: remove unneeded semicolonFrancesco Dolcini1-1/+1
Remove unneeded stray semicolon. Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Francesco Dolcini <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-16gpu: drm: bridge: No need to set device_driver ownerAnup Sharma1-1/+0
There is no need to exclusively set the .owner member of the struct device_driver when defining the platform_driver struct. The Linux core takes care of setting the .owner member as part of the call to module_platform_driver() helper function. Issue identified using the platform_no_drv_owner.cocci Coccinelle semantic patch as: drivers/gpu/drm/bridge/samsung-dsim.c:1957:6-11: No need to set .owner here. The core will do it. No functional changes are intended. Signed-off-by: Anup Sharma <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ZF9igb/nvL6GRBsq@yoga
2023-05-06drm/bridge: lt9611: Do not generate HFP/HBP/HSA and EOT packetMarek Vasut1-1/+3
Do not generate the HS front and back porch gaps, the HSA gap and EOT packet, as these packets are not required. This makes the bridge work with Samsung DSIM on i.MX8MM and i.MX8MP. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-06drm/bridge: lt9211: Do not generate HFP/HBP/HSA and EOT packetMarek Vasut1-1/+3
Do not generate the HS front and back porch gaps, the HSA gap and EOT packet, as these packets are not required. This makes the bridge work with Samsung DSIM on i.MX8MM and i.MX8MP. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-05drm/bridge: tc358768: remove unused variableFrancesco Dolcini1-3/+1
Remove the unused phy_delay_nsk variable, before it was wrongly used to compute some register value, the fixed computation is no longer using it and therefore can be removed. Signed-off-by: Francesco Dolcini <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-05drm/bridge: tc358768: fix THS_TRAILCNT computationFrancesco Dolcini1-3/+4
Correct computation of THS_TRAILCNT register. This register must be set to a value that ensure that THS_TRAIL > 60 ns + 4 x UI and THS_TRAIL > 8 x UI and THS_TRAIL < TEOT with TEOT = 105 ns + (12 x UI) with the actual value of THS_TRAIL being (1 + THS_TRAILCNT) x ByteClk cycle + ((1 to 2) + 2) xHSBYTECLK cycle + - (PHY output delay) with PHY output delay being about (8 + (5 to 6)) x MIPIBitClk cycle in the BitClk conversion. Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-05drm/bridge: tc358768: fix TXTAGOCNT computationFrancesco Dolcini1-1/+1
Correct computation of TXTAGOCNT register. This register must be set to a value that ensure that the TTA-GO period = (4 x TLPX) with the actual value of TTA-GO being 4 x (TXTAGOCNT + 1) x (HSByteClk cycle) Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-05drm/bridge: tc358768: fix THS_ZEROCNT computationFrancesco Dolcini1-3/+4
Correct computation of THS_ZEROCNT register. This register must be set to a value that ensure that THS_PREPARE + THS_ZERO > 145ns + 10*UI with the actual value of (THS_PREPARE + THS_ZERO) being ((1 to 2) + 1 + (TCLK_ZEROCNT + 1) + (3 to 4)) x ByteClk cycle + + HSByteClk x (2 + (1 to 2)) + (PHY delay) with PHY delay being about (8 + (5 to 6)) x MIPIBitClk cycle in the BitClk conversion. Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-05drm/bridge: tc358768: fix TCLK_TRAILCNT computationFrancesco Dolcini1-3/+5
Correct computation of TCLK_TRAILCNT register. The driver does not implement non-continuous clock mode, so the actual value doesn't make a practical difference yet. However this change also ensures that the value does not write to reserved registers bits in case of under/overflow. This register must be set to a value that ensures that TCLK-TRAIL > 60ns and TEOT <= (105 ns + 12 x UI) with the actual value of TCLK-TRAIL being (TCLK_TRAILCNT + (1 to 2)) xHSByteClkCycle + (2 + (1 to 2)) * HSBYTECLKCycle - (PHY output delay) with PHY output delay being about (2 to 3) x MIPIBitClk cycle in the BitClk conversion. Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-05drm/bridge: tc358768: fix TCLK_ZEROCNT computationFrancesco Dolcini1-4/+4
Correct computation of TCLK_ZEROCNT register. This register must be set to a value that ensure that (TCLK-PREPARECNT + TCLK-ZERO) > 300ns with the actual value of (TCLK-PREPARECNT + TCLK-ZERO) being (1 to 2) + (TCLK_ZEROCNT + 1)) x HSByteClkCycle + (PHY output delay) with PHY output delay being about (2 to 3) x MIPIBitClk cycle in the BitClk conversion. Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-05drm/bridge: tc358768: fix PLL target frequencyFrancesco Dolcini1-3/+5
Correctly compute the PLL target frequency, the current formula works correctly only when the input bus width is 24bit, actually to properly compute the PLL target frequency what is relevant is the bits-per-pixel on the DSI link. No regression expected since the DSI format is currently hard-coded as MIPI_DSI_FMT_RGB888. Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-05drm/bridge: tc358768: fix PLL parameters computationFrancesco Dolcini1-1/+5
According to Toshiba documentation the PLL input clock after the divider should be not less than 4MHz, fix the PLL parameters computation accordingly. Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-05drm/bridge: tc358768: always enable HS video modeFrancesco Dolcini1-2/+1
Always enable HS video mode setting the TXMD bit, without this change no video output is present with DSI sinks that are setting MIPI_DSI_MODE_LPM flag (tested with LT8912B DSI-HDMI bridge). Previously the driver was enabling HS mode only when the DSI sink was not explicitly setting the MIPI_DSI_MODE_LPM, however this is not correct. The MIPI_DSI_MODE_LPM is supposed to indicate that the sink is willing to receive data in low power mode, however clearing the TC358768_DSI_CONTROL_TXMD bit will make the TC358768 send video in LP mode that is not the intended behavior. Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-04drm/bridge: ti-sn65dsi83: Fix enable error pathAlexander Stein1-0/+1
If PLL locking failed, the regulator needs to be disabled again. Fixes: 5664e3c907e2 ("drm/bridge: ti-sn65dsi83: Add vcc supply regulator support") Signed-off-by: Alexander Stein <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.