summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2023-06-19drm/bridge: tc358768: Attempt to fix DSI horizontal timingsTomi Valkeinen
The DSI horizontal timing calculations done by the driver seem to often lead to underflows or overflows, depending on the videomode. There are two main things the current driver doesn't seem to get right: DSI HSW and HFP, and VSDly. However, even following Toshiba's documentation it seems we don't always get a working display. This patch attems to fix the horizontal timings for DSI event mode, and on a system with a DSI->HDMI encoder, a lot of standard HDMI modes now seem to work. The work relies on Toshiba's documentation, but also quite a bit on empirical testing. Also add quite a bit timing related debug prints to make it easier to improve on this later. I am not able to test pulse mode, and this patch doesn't attempt to fix it. However, the VSDly calculation also affects pulse mode, so this might cause a regression. Upstream-Status: Pending Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-06-19drm/bridge: tc358768: Fix tc358768_ns_to_cnt()Tomi Valkeinen
The tc358768_ns_to_cnt() is, most likely, supposed to do a div-round-up operation, but it misses subtracting one from the dividend. Fix this by just using DIV_ROUND_UP(). Upstream-Status: Pending Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-06-19drm/bridge: tc358768: Clean up clock period codeTomi Valkeinen
The driver defines TC358768_PRECISION as 1000, and uses "nsk" to refer to clock periods. The original author does not remember where all this came from. Effectively the driver is using picoseconds as the unit for clock periods, yet referring to them by "nsk". Clean this up by just saying the periods are in picoseconds. Upstream-Status: Pending Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-06-19drm/bridge: tc358768: Rename dsibclk to hsbyteclkTomi Valkeinen
The Toshiba documentation talks about HSByteClk when referring to the DSI HS byte clock, whereas the driver uses 'dsibclk' name. Also, in a few places the driver calculates the byte clock from the DSI clock, even if the byte clock is already available in a variable. To align the driver with the documentation, change the 'dsibclk' variable to 'hsbyteclk'. This also make it easier to visually separate 'dsibclk' and 'dsiclk' variables. Upstream-Status: Pending Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-06-19drm/bridge: tc358768: Use dev for dbg prints, not priv->devTomi Valkeinen
Simplify the code by capturing the priv->dev value to dev variable, and use it. Upstream-Status: Pending Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-06-19drm/bridge: tc358768: Print logical values, not raw register valuesTomi Valkeinen
The driver debug prints DSI related timings as raw register values in hex. It is much more useful to see the "logical" value of the timing, not the register value. Change the prints to print the values separately, in case a single register contains multiple values, and use %u to have it in a more human consumable form. Upstream-Status: Pending Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-06-19drm/bridge: tc358768: Use struct videomodeTomi Valkeinen
The TC358768 documentation uses HFP, HBP, etc. values to deal with the video mode, while the driver currently uses the DRM display mode (htotal, hsync_start, etc). Change the driver to convert the DRM display mode to struct videomode, which then allows us to use the same units the documentation uses. This makes it much easier to work on the code when using the TC358768 documentation as a reference. Upstream-Status: Pending Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-06-19drm/bridge: tc358768: Cleanup PLL calculationsTomi Valkeinen
As is quite common, some of TC358768's PLL register fields are to be programmed with (value - 1). Specifically, the FBD and PRD, multiplier and divider, are such fields. However, what the driver currently does is that it considers that the formula used for PLL rate calculation is: RefClk * [(FBD + 1)/ (PRD + 1)] * [1 / (2^FRS)] where FBD and PRD are values directly from the registers, while a more sensible way to look at it is: RefClk * FBD / PRD * (1 / (2^FRS)) and when the FBD and PRD values are written to the registers, they will be subtracted by one. Change the driver accordingly, as it simplifies the PLL code. Upstream-Status: Pending Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-06-19drm/bridge: tc358768: Fix bit updatesTomi Valkeinen
The driver has a few places where it does: if (thing_is_enabled_in_config) update_thing_bit_in_hw() This means that if the thing is _not_ enabled, the bit never gets cleared. This affects the h/vsyncs and continuous DSI clock bits. Fix the driver to always update the bit. Upstream-Status: Pending Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-06-19drm/bridge: lt8912b: Fix bridge_detachTomi Valkeinen
The driver calls lt8912_bridge_detach() from its lt8912_remove() function. As the DRM code detaches bridges automatically, this leads to a double detach and a crash. Fix the issue by dropping the call to lt8912_bridge_detach() from lt8912_remove(), and also drop the useless is_attached field. Upstream-Status: Pending Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-06-19Revert "drm/bridge: lt8912b: set hdmi or dvi mode"Tomi Valkeinen
This reverts commit 03ee685c4fc2c3414aa9aa163c2f3904ac5262f9. Setting the HDMI bit causes a green tint to appear on my Dell monitor. The original commit is a bit odd, as it sets the HDMI bit, but does not do anything else (e.g. configure infoframes), and doesn't explain why setting the HDMI bit is needed. Upstream-Status: Pending Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-06-19HACK: drm: tidss: clk_set_rate issue workaroundTomi Valkeinen
Sometimes when changing the VP clock rate, the result is getting a clock rate of 0, which obviously then breaks the display. As a quick workaround, setting the rate a second time seems to fix the problem. Upstream-Status: Inappropriate [other] Just a temporary hack, this should be fixed on the TI SYSFW. Reported to TI [1] and waiting for a fix. [1] https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1239552/am625-clk_set_rate-failing-on-tidss-driver-sysfw-bug Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-06-16can: m_can: Add hrtimer to generate software interruptJudith Mendez
Introduce timer polling method to MCAN since some SoCs may not have M_CAN interrupt routed to A53 Linux and do not have interrupt property in device tree M_CAN node. On AM62x SoC, MCANs on MCU domain do not have hardware interrupt routed to A53 Linux, instead they will use timer polling method. Add an hrtimer to MCAN class device. Each MCAN will have its own hrtimer instantiated if there is no hardware interrupt found in device tree M_CAN node. The timer will generate a software interrupt every 1 ms. In hrtimer callback, we check if there is a transaction pending by reading a register, then process by calling the isr if there is. Upstream-Status: Submitted [https://lore.kernel.org/all/20230530224820.303619-3-jm@ti.com/] Signed-off-by: Judith Mendez <jm@ti.com>
2023-04-28drm/bridge: tc358768: hardcode parallel data format cfg to 1Francesco Dolcini
Set parallel data format to 1 [0], as required by Verdin AM62 V1.0, the default is 0 and it will lead to wrong colors on this specific hardware. [0] 1 = R[1:0], G[1:0], B[1:0], R[7:2], G[7:2], B[7:2] Upstream-Status: Inappropriate [other] A configurable solution to solve this was send upstream, however the discussion stalled [1] and it's not clear the next steps. As a short term work-around just hard-code this to what we need. [1] https://lore.kernel.org/all/20230330095941.428122-4-francesco@dolcini.it/ Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-04-28drm/bridge: tc358768: Add atomic_get_input_bus_fmts() implementationFrancesco Dolcini
Add atomic_get_input_bus_fmts() implementation, tc358768 has a parallel RGB input interface with the actual bus format depending on the amount of parallel input data lines. Without this change when the tc358768 is used with less than 24bit the color mapping is completely wrong. Upstream-Status: Submitted [https://lore.kernel.org/all/20230330095941.428122-7-francesco@dolcini.it/] Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-04-28drm/bridge: tc358768: remove unused variableFrancesco Dolcini
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. Upstream-Status: Submitted [https://lore.kernel.org/all/20230427142934.55435-1-francesco@dolcini.it/] Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-04-28drm/bridge: tc358768: fix THS_TRAILCNT computationFrancesco Dolcini
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. Upstream-Status: Submitted [https://lore.kernel.org/all/20230427142934.55435-1-francesco@dolcini.it/] Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-04-28drm/bridge: tc358768: fix TXTAGOCNT computationFrancesco Dolcini
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) Upstream-Status: Submitted [https://lore.kernel.org/all/20230427142934.55435-1-francesco@dolcini.it/] Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-04-28drm/bridge: tc358768: fix THS_ZEROCNT computationFrancesco Dolcini
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. Upstream-Status: Submitted [https://lore.kernel.org/all/20230427142934.55435-1-francesco@dolcini.it/] Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-04-28drm/bridge: tc358768: fix TCLK_TRAILCNT computationFrancesco Dolcini
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. Upstream-Status: Submitted [https://lore.kernel.org/all/20230427142934.55435-1-francesco@dolcini.it/] Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-04-28drm/bridge: tc358768: fix TCLK_ZEROCNT computationFrancesco Dolcini
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. Upstream-Status: Submitted [https://lore.kernel.org/all/20230427142934.55435-1-francesco@dolcini.it/] Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-04-28drm/bridge: tc358768: fix PLL target frequencyFrancesco Dolcini
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. Upstream-Status: Submitted [https://lore.kernel.org/all/20230427142934.55435-1-francesco@dolcini.it/] Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-04-28drm/bridge: tc358768: fix PLL parameters computationFrancesco Dolcini
According to Toshiba documentation the PLL input clock after the divider should be not less than 4MHz, fix the PLL parameters computation accordingly. Upstream-Status: Submitted [https://lore.kernel.org/all/20230427142934.55435-1-francesco@dolcini.it/] Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-04-28drm/bridge: tc358768: always enable HS video modeFrancesco Dolcini
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. Upstream-Status: Submitted [https://lore.kernel.org/all/20230427142934.55435-1-francesco@dolcini.it/] Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-04-28drm/tidss: Use bus format from the first bridge if presentFrancesco Dolcini
In case there is a bridge connected to the TIDSS, use bus format from the bridge, otherwise behave as before and use the format from the connector display info. This way is possible to use a bridge that convert between different media format. Similar changes were rejected in mainline, there is a request to convert tidss to expose a drm_bridge interface. Upstream-Status: Denied A similar patch was rejected upstream, the request is to implement the DRM bridge interface [1]. TI is going to take care of it [2], we will integrate the solution from upstream as soon as it is available. [1] https://lore.kernel.org/all/20201204121235.4bbbe2eb@collabora.com/ [2] https://lore.kernel.org/all/655cfc4b-a414-47e1-f676-b11e410da32f@ti.com/ Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2023-04-28Merge tag '08.06.00.007' into toradex_ti-linux-5.10.y_bringup_syncFrancesco Dolcini
Merge TI Linux Kernel Release 08.06.00.007
2023-04-18drm/bridge: lt8912b: Fix DSI Video ModeFrancesco Dolcini
LT8912 DSI port supports only Non-Burst mode video operation with Sync Events and continuous clock on clock lane, correct dsi mode flags according to that removing MIPI_DSI_MODE_VIDEO_BURST flag. Upstream-Status: Submitted [https://lore.kernel.org/all/20230330093131.424828-1-francesco@dolcini.it/] Cc: <stable@vger.kernel.org> Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") 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/20230330093131.424828-1-francesco@dolcini.it
2023-04-18drm/bridge: lt8912b: return EPROBE_DEFER if bridge is not foundMatheus Castello
Returns EPROBE_DEFER when of_drm_find_bridge() fails, this is consistent with what all the other DRM bridge drivers are doing and this is required since the bridge might not be there when the driver is probed and this should not be a fatal failure. Upstream-Status: Backport [1a70ca89d59c7c8af006d29b965a95ede0abb0da] Cc: <stable@vger.kernel.org> Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Signed-off-by: Matheus Castello <matheus.castello@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230322143821.109744-1-francesco@dolcini.it
2023-04-18drm/bridge: lt8912b: Add hot plug detectionStefan Eichenberger
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> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Adrien Grassein <adrien.grassein@gmail.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221128112320.25708-1-francesco@dolcini.it
2023-04-18drm/bridge: lt8912b: clarify lvds output statusFrancesco Dolcini
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> Acked-by: Adrien Grassein <adrien.grassein@gmail.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220922124306.34729-5-dev@pschenker.ch
2023-04-18drm/bridge: lt8912b: fix corrupted image outputFrancesco Dolcini
Correct I2C address for the register list in lt8912_write_lvds_config(), these registers are on the first I2C address (0x48), the current function is just writing garbage to the wrong registers and this creates multiple issues (artifacts and output completely corrupted) on some HDMI displays. Correct I2C address comes from Lontium documentation and it is the one used on other out-of-tree LT8912B drivers [1]. [1] https://github.com/boundarydevices/linux/blob/boundary-imx_5.10.x_2.0.0/drivers/video/lt8912.c#L296 Upstream-Status: Backport [051ad2788d35ca07aec8402542e5d38429f2426a] Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Acked-by: Adrien Grassein <adrien.grassein@gmail.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220922124306.34729-4-dev@pschenker.ch
2023-04-18drm/bridge: lt8912b: set hdmi or dvi modePhilippe Schenker
The Lontium LT8912 does have a setting for DVI or HDMI. This patch reads from EDID what the display needs and sets it accordingly. Upstream-Status: Backport [6dd1de12e1243f2013e4fabf31e99e63b1a860d0] Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Acked-by: Adrien Grassein <adrien.grassein@gmail.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220922124306.34729-3-dev@pschenker.ch
2023-04-18drm/bridge: lt8912b: add vsync hsyncPhilippe Schenker
Currently the bridge driver does not take care whether or not the display needs positive/negative vertical/horizontal syncs. Pass these two flags to the bridge from the EDID that was read out from the display. Upstream-Status: Backport [da73a94fa282f78d485bd0aab36c8ac15b6f792c] Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Acked-by: Adrien Grassein <adrien.grassein@gmail.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220922124306.34729-2-dev@pschenker.ch
2023-04-18drm/bridge: lt8912b: Register and attach our DSI device at probeMaxime Ripard
In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Upstream-Status: Backport [d89078c37b10f05fa4f4791b71db2572db361b68] Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211025151536.1048186-7-maxime@cerno.tech
2023-04-18drm/bridge: lt8912b: Switch to devm MIPI-DSI helpersMaxime Ripard
Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. Upstream-Status: Backport [1fdbf66e3d40257902b4c5cdf872730dae24004f] Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211025151536.1048186-6-maxime@cerno.tech
2023-04-18drm/bridge: lt8912b: Drop unused includesLinus Walleij
The Lontium bridge is including legacy header files for GPIO but not using them. Delete the includes. Upstream-Status: Backport [ef9e57cda5fb290258a060e4f3e712148bc5b421] Cc: Adrien Grassein <adrien.grassein@gmail.com> Cc: Robert Foss <robert.foss@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Adren Grassein <adrien.grassein@gmail.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210529002759.468964-1-linus.walleij@linaro.org
2023-04-18drm/bridge: lt8912b: fix platform_no_drv_owner.cocci warningsZou Wei
./drivers/gpu/drm/bridge/lontium-lt8912b.c:758:3-8: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Upstream-Status: Backport [2986d2763daaaa9280ac499ea17e7031a81ac0b7] Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/1622109018-54648-1-git-send-email-zou_wei@huawei.com
2023-04-18drm/bridge: lt8912b: fix incorrect handling of of_* return valuesAdrien Grassein
A static analysis shows several issues in the driver code at probing time. DT parsing errors were bad handled and could lead to bugs: - Bad error detection; - Bad release of resources Upstream-Status: Backport [5a7bd25992e48aacdbd73c09a54f15cd163e92cd] Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Suggested-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Adrien Grassein <adrien.grassein@gmail.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210415183639.1487-1-rdunlap@infradead.org Signed-off-by: Robert Foss <robert.foss@linaro.org>
2023-04-18drm/bridge: lt8912b: Add header file <linux/gpio/consumer.h>Zhang Jianhua
If CONFIG_DRM_LONTIUM_LT8912B=m, the following errors will be seen while compiling lontium-lt8912b.c drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_hard_power_on’: drivers/gpu/drm/bridge/lontium-lt8912b.c:252:2: error: implicit declaration of function ‘gpiod_set_value_cansleep’; did you mean ‘gpio_set_value_cansleep’? [-Werror=implicit-function-declaration] gpiod_set_value_cansleep(lt->gp_reset, 0); ^~~~~~~~~~~~~~~~~~~~~~~~ gpio_set_value_cansleep drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_parse_dt’: drivers/gpu/drm/bridge/lontium-lt8912b.c:628:13: error: implicit declaration of function ‘devm_gpiod_get_optional’; did you mean ‘devm_gpio_request_one’? [-Werror=implicit-function-declaration] gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); ^~~~~~~~~~~~~~~~~~~~~~~ devm_gpio_request_one drivers/gpu/drm/bridge/lontium-lt8912b.c:628:51: error: ‘GPIOD_OUT_HIGH’ undeclared (first use in this function); did you mean ‘GPIOF_INIT_HIGH’? gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); ^~~~~~~~~~~~~~ GPIOF_INIT_HIGH Upstream-Status: Backport [7513ce49027c8218a6fce7ec45c3289b903ba4bd] Signed-off-by: Zhang Jianhua <zhangjianhua18@huawei.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210408093822.207917-1-zhangjianhua18@huawei.com
2023-04-18drm/bridge: Introduce LT8912B DSI to HDMI bridgeAdrien Grassein
Lontium LT8912B is a DSI to HDMI bridge. Upstream-Status: Backport [30e2ae943c260036ea494b601343f6ed5ce7bc60] Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Adrien Grassein <adrien.grassein@gmail.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210326121955.1266230-3-adrien.grassein@gmail.com
2023-03-22drm/bridge: tc358768: Correct BTACNTRL1 programmingDmitry Osipenko
TXTAGOCNT and RXTASURECNT bitfields of BTACNTRL1 register are swapped in the code, correct them. Driver doesn't implement low power mode for now, so this change doesn't make a practical difference yet. Upstream-Status: Backport [43a1f1467cd4bcf248925fd7b3fdf49d73917443] Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # Asus TF700T Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> #TF700T Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211002233447.1105-6-digetx@gmail.com
2023-03-22drm/bridge: tc358768: Disable non-continuous clock modeDmitry Osipenko
Non-continuous clock mode doesn't work because driver doesn't support it properly. The bridge driver programs wrong bitfields that are required by the non-continuous mode (BTACNTRL1 register bitfields are swapped in the code), but fixing them doesn't help. Display panel of ASUS Transformer TF700T tablet supports non-continuous mode and display doesn't work at all using that mode. There are no device-trees that are actively using this DSI bridge in upstream yet, so clearly the broken mode wasn't ever tested properly. It's a bit too difficult to get LP mode working, hence let's disable the offending mode for now and fall back to continuous mode. Upstream-Status: Backport [fbc5a90e82c1131869e76ce5b082693b8a75c121] Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # Asus TF700T Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> #TF700T Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211002233447.1105-5-digetx@gmail.com
2023-03-22drm/bridge: tc358768: Calculate video start delayDmitry Osipenko
Calculate video start delay based on the display timing instead of hardcoding it to a default value. This fixes "trembling" display output on Asus Transformer TF700T which uses Panasonic VVX10F004B00 display panel. Upstream-Status: Backport [b93e947664a1a63a3e6cb5d94f38d5579e41d951] Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # Asus TF700T Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> #TF700T Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211002233447.1105-4-digetx@gmail.com
2023-03-22drm/bridge: tc358768: Support pulse modeDmitry Osipenko
Support pulse-mode synchronization which is supported and used by simple DSI panels like Panasonic VVX10F004B00. Upstream-Status: Backport [0bcdfabfcbe230fbd9f03c297486f013333892c7] Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # Asus TF700T Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> #TF700T Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211002233447.1105-3-digetx@gmail.com
2023-03-22drm/bridge: tc358768: Enable reference clockDmitry Osipenko
The driver assumes that reference clock is always-enabled, but this is hardware-dependent and not true for ASUS Transformer TF700T. Make driver enable / disable the reference clock. Upstream-Status: Backport [45a44b01faa6ef92788b2067631deb486cef8a4d] Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # Asus TF700T Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> #TF700T Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211002233447.1105-2-digetx@gmail.com
2023-03-22drm/bridge: ti-sn65dsi83: Check link status register after enabling the bridgeMarek Vasut
In rare cases, the bridge may not start up correctly, which usually leads to no display output. In case this happens, warn about it in the kernel log. Upstream-Status: Backport [85854fa95972455fd8ff340d7810dde57fe36d44] 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 Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220213022648.495895-1-marex@denx.de
2023-03-22drm/bridge: sn65dsi83: Fix an error handling path in sn65dsi83_probe()Christophe JAILLET
sn65dsi83_parse_dt() takes a reference on 'ctx->host_node' that must be released in the error handling path of this function and of the probe. This is only done in the remove function up to now. Upstream-Status: Backport [6edf615618b8259f16eeb1df98f0ba0d2312c22e] Fixes: ceb515ba29ba ("drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/4bc21aed4b60d3d5ac4b28d8b07a6fdd8da6a536.1640768126.git.christophe.jaillet@wanadoo.fr
2023-03-22drm/bridge: ti-sn65dsi83: Add vcc supply regulator supportAlexander Stein
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
2023-03-22drm/bridge: ti-sn65dsi83: Make enable GPIO optionalAlexander Stein
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
2023-03-22drm/bridge: sn65dsi83: Register and attach our DSI device at probeMaxime Ripard
In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Upstream-Status: Backport [6ef7ee48765fa3067858d11ecdf3acbc7c19df80] Acked-by: Sam Ravnborg <sam@ravnborg.org> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211025151536.1048186-16-maxime@cerno.tech
generated by cgit v1.2.3 (git 2.0.4) at 2024-06-14 00:34:57 +0000