- Feb 21, 2025
-
-
rk3576 has two pcie controllers, both are pcie2x1 work with naneng-combphy. Signed-off-by:
Kever Yang <kever.yang@rock-chips.com>
Link: https://lore.kernel.org/r/20250221104357.1514128-3-kever.yang@rock-chips.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> -
RK3576 is using DWC PCIe controller, with a msi interrupt line going directly to GIC instead of using GIC ITS. Signed-off-by:
Kever Yang <kever.yang@rock-chips.com>
Link: https://lore.kernel.org/r/20250221104357.1514128-2-kever.yang@rock-chips.com
[Fix binding and cleanup commit message]
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> -
Enable use of HDMI 2.0 display modes, e.g. 4K@60Hz, by permitting TMDS character rates above the 340 MHz limit of HDMI 1.4b. Hence, add the required support for SCDC management, including the high TMDS clock ratio and scrambling setup. Additionally, filter out HDMI 2.1 display modes. Signed-off-by:Cristian Ciocaltea <cristian.ciocaltea@collabora.com> -
In preparation to provide scrambling support to the HDMI Connector framework, make use of the more flexible ->detect_ctx() bridge connector helper hook instead of ->detect(). Signed-off-by:Cristian Ciocaltea <cristian.ciocaltea@collabora.com> -
Add a ->detect() variant that also provides a drm_modeset_acquire_ctx reference for greater flexibility in operation, e.g. to support adding scrambling functionality to drm_bridge_connector. When both ->detect_ctx() and ->detect() are defined, the latter is simply ignored. Signed-off-by:Cristian Ciocaltea <cristian.ciocaltea@collabora.com> -
Stop relying on phy_set_bus_width() workaround to setup the TMDS character rate and, instead, use the proper HDMI PHY configuration API for this purpose. Additionally, move the logic into the ->atomic_check() callback where the current mode rate is already provided by drm_connector_hdmi_state->tmds_char_rate. This allows adding later support for high color depth and YUV420 output format, rather then being limited to 8bpc RGB. Signed-off-by:Cristian Ciocaltea <cristian.ciocaltea@collabora.com> -
The ropll_tmds_cfg table used to identify the configuration params for the supported rates expects the search keys - bit_rate field - to be provided in hHz rather than Hz (1 hHz = 100 Hz). This requires multiple conversions between these units being performed at runtime. Improve implementation clarity and efficiency by consistently using the Hz units throughout driver's internal data structures and functions. Signed-off-by:Cristian Ciocaltea <cristian.ciocaltea@collabora.com> -
Drop the rate parameter from a bunch of internal helpers and, instead, make better use of the newly introduced ->tmds_char_rate driver data. No functional changes intended. Signed-off-by:Cristian Ciocaltea <cristian.ciocaltea@collabora.com> -
Add support for 8-bit, 10-bit, 12-bit and 16-bit color depth setup. Signed-off-by:Cristian Ciocaltea <cristian.ciocaltea@collabora.com> -
The current workaround to setup the TMDS character rate relies on the unconventional usage of phy_set_bus_width(). Make use of the recently introduced HDMI PHY configuration API for this purpose. The workaround will be dropped as soon as the switch has been completed on both ends. Signed-off-by:Cristian Ciocaltea <cristian.ciocaltea@collabora.com> -
This is just a leftover from downstream support for HDMI 2.1. Remove the unused struct for now. Signed-off-by:Cristian Ciocaltea <cristian.ciocaltea@collabora.com> -
The switch from 1/10 to 1/40 clock ratio must happen when exceeding the 340 MHz rate limit of HDMI 1.4, i.e. when entering the HDMI 2.0 domain, and not before. While at it, introduce a define for this rate limit constant. Fixes: 553be283 ("phy: rockchip: Add Samsung HDMI/eDP Combo PHY driver") Signed-off-by:
Cristian Ciocaltea <cristian.ciocaltea@collabora.com> -
Extend the HDMI configuration options to allow managing bits per color channel. This is required by some PHY drivers such as rockchip-samsung-hdptx. Signed-off-by:Cristian Ciocaltea <cristian.ciocaltea@collabora.com> -
Allow HDMI PHYs to be configured through the generic functions through a custom structure added to the generic union. The parameters added here are based on HDMI PHY implementation practices. The current set of parameters should cover the potential users. Signed-off-by:
Sandor Yu <Sandor.yu@nxp.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/43757beec6cd418fc17252283de38009d531c7c7.1732627815.git.Sandor.yu@nxp.com
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> -
A previous from Detlev Casanova adds reset handling for the video ports. This also resets the AHB and AXI interface when the system binds the VOP2 controller. This fixes issues when the bootloader (or a previously running kernel when using kexec) left the VOP2 initialized to some degree. Signed-off-by:Sebastian Reichel <sebastian.reichel@collabora.com> -
VOP2 on RK3588 is able to use the HDMI PHY PLL as an alternative and more accurate pixel clock source to improve handling of display modes up to 4K@60Hz on video ports 0, 1 and 2. The HDMI1 PHY PLL clock source cannot be added directly to vop node in rk3588-base.dtsi, along with the HDMI0 related one, because HDMI1 is an optional feature and its PHY node belongs to a separate (extra) DT file. Therefore, add the HDMI1 PHY PLL clock source to VOP2 by overwriting its clocks & clock-names properties in the extra DT file. Signed-off-by:Cristian Ciocaltea <cristian.ciocaltea@collabora.com> -
Since commit c4b09c56 ("phy: phy-rockchip-samsung-hdptx: Add clock provider support"), the HDMI PHY PLL can be used as an alternative and more accurate pixel clock source for VOP2 to improve display modes handling on RK3588 SoC. Add the missing #clock-cells property to allow using the clock provider functionality of HDMI1 PHY. Signed-off-by:
Cristian Ciocaltea <cristian.ciocaltea@collabora.com> -
The RK3588 specific implementation is currently quite limited in terms of handling the full range of display modes supported by the connected screens, e.g. 2560x1440@75Hz, 2048x1152@60Hz, 1024x768@60Hz are just a few of them. Additionally, it doesn't cope well with non-integer refresh rates like 59.94, 29.97, 23.98, etc. Make use of HDMI1 PHY PLL as a more accurate DCLK source to handle all display modes up to 4K@60Hz. Signed-off-by:Cristian Ciocaltea <cristian.ciocaltea@collabora.com> -
Add the necessary DT changes to enable the second HDMI output port on Rockchip RK3588 EVB1. While at it, switch the position of &vop_mmu and @vop to maintain the alphabetical order. Signed-off-by:Cristian Ciocaltea <cristian.ciocaltea@collabora.com> -
The RK3588 EVB1 comes with a W552793DBA-V10 Touchscreen/Display combination. It contains a Wanchanglong W552793BAA panel and a Goodix GT1158 touchscreen. This adds the DT description of it. Signed-off-by:Sebastian Reichel <sebastian.reichel@collabora.com> -
The Rockchip W552793DBA-V10 display/touchscreen board contains a Wanchanglong W552793BAA panel, which in turn is using a Raydium RM67200 MIPI-DSI controller. Add a DSI panel driver for it. The W552793BAA panel init sequence has been taken from the RK3588 EVB1 vendor kernel devicetree. Reviewed-by:
Jessica Zhang <quic_jesszhan@quicinc.com>
Reviewed-by: Andy Yan <andyshrk@163.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> -
The Rockchip W552793DBA-V10 display/touchscreen board contains a Wanchanglong W552793BAA panel, which in turn is using a Raydium RM67200 MIPI-DSI controller. Add a DT binding for the DSI panel. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> -
The RK3588 comes with two DSI2 controllers based on a new Synopsis IP. Add the necessary nodes for them. Signed-off-by:
Heiko Stuebner <heiko.stuebner@cherry.de>
Link: https://lore.kernel.org/r/20241106123758.423584-3-heiko@sntech.de
Signed-off-by: Sebastian Reichel <sre@kernel.org> -
Add the two MIPI-DC-phy nodes to the RK3588, that will be used by the DSI2 controllers and hopefully in some future also for camera input. Signed-off-by:
Heiko Stuebner <heiko.stuebner@cherry.de>
Link: https://lore.kernel.org/r/20241106123758.423584-2-heiko@sntech.de
Signed-off-by: Sebastian Reichel <sre@kernel.org> -
Add phy driver needed to drive either a MIPI DSI output to a DSI display or MIPI CSI input from a camera on rk3588. Right now only the DSI portion is implemented as the whole camera part needs more work in general. Signed-off-by:
Heiko Stuebner <heiko.stuebner@cherry.de>
Tested-by: Daniel Semkowicz <dse@thaumatec.com>
Link: https://lore.kernel.org/r/20241113221018.62150-3-heiko@sntech.de
Signed-off-by: Sebastian Reichel <sre@kernel.org> -
Add dt-binding schema for the MIPI CSI/DSI PHY found on Rockchip RK3588 SoCs. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Tested-by: Daniel Semkowicz <dse@thaumatec.com>
Link: https://lore.kernel.org/r/20241113221018.62150-2-heiko@sntech.de
Signed-off-by: Sebastian Reichel <sre@kernel.org> -
This adds the needed clock resets for all rk3588(s) based SOCs. Signed-off-by:Detlev Casanova <detlev.casanova@collabora.com> -
At the end of initialization, each VP clock needs to be reset before they can be used. Failing to do so can put the VOP in an undefined state where the generated HDMI signal is either lost or not matching the selected mode. This issue can be reproduced by switching modes multiple times. Depending on the setup, after about 10 mode switches, the signal will be lost and the value in register 0x890 (VSYNCWIDTH + VFRONT) will take the value `0x0000018c`. That makes VSYNCWIDTH=0, which is wrong. Adding the clock resets after the VOP configuration fixes the issue. Signed-off-by:Detlev Casanova <detlev.casanova@collabora.com> -
Add the documentation for VOP2 video ports reset clocks. One reset can be set per video port. Reviewed-by:
Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> -
Enabling the GPU power domain requires that the GPU regulator is enabled. The regulator is enabled at boot time, but automatically gets disabled when there are no users. If the GPU driver is not probed at boot time or rebound while the system is running the system will try to enable the power domain before the regulator is enabled resulting in a failure hanging the whole system. Avoid this by adding an explicit dependency. Reported-by:
Adrián Martínez Larumbe <adrian.larumbe@collabora.com>
Tested-by: Adrian Larumbe <adrian.larumbe@collabora.com> # On Rock 5B
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> -
Some power domains require extra voltages to be applied. For example trying to enable the GPU power domain on RK3588 fails when the SoC does not have VDD GPU enabled. The same is expected to happen for the NPU, which also has a dedicated supply line. We get the regulator using devm_of_regulator_get(), so a missing dependency in the devicetree is handled gracefully by printing a warning and creating a dummy regulator. This is necessary, since existing DTs do not have the regulator described. They might still work if the regulator is marked as always-on. It is also working if the regulator is enabled at boot time and the GPU driver is probed before the kernel disables unused regulators. The regulator itself is not acquired at driver probe time, since that creates an unsolvable circular dependency. The power domain driver must be probed early, since SoC peripherals need it. Regulators on the other hand depend on SoC peripherals like SPI, I2C or GPIO. MediaTek does not run into this, since they have two power domain drivers. Signed-off-by:Sebastian Reichel <sebastian.reichel@collabora.com> -
Add optional support for a voltage supply required to enable a power domain. The binding follows the way it is handled by the Mediatek binding to keep things consistent. This will initially be used by the RK3588 GPU power domain, which fails to be enabled when the GPU regulator is not enabled. It is not limited to that platform, since older generations have similar requirements. They worked around this by marking the regulators as always-on instead of describing the dependency. Reviewed-by:
Heiko Stuebner <heiko@sntech.de>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> -
Rework the logic, so that the function exits early when the power domain state is already correct to reduce code indentation. No functional change intended. Reviewed-by:
Heiko Stuebner <heiko@sntech.de>
Tested-by: Adrian Larumbe <adrian.larumbe@collabora.com> # On Rock 5B
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> -
Currently rockchip_do_pmu_set_power_domain prints a warning if there have been errors turning on the power domain, but it does not return any errors and rockchip_pd_power() tries to continue setting up the QOS registers. This usually results in accessing unpowered registers, which triggers an SError and a full system hang. This improves the error handling by forwarding the error to avoid kernel panics. Reviewed-by:
Heiko Stuebner <heiko@sntech.de>
Tested-by: Adrian Larumbe <adrian.larumbe@collabora.com> # On Rock 5B
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> -
Use the cleanup infrastructure to handle the mutex, which slightly improve code readability for this function. Reviewed-by:
Heiko Stuebner <heiko@sntech.de>
Tested-by: Adrian Larumbe <adrian.larumbe@collabora.com> # On Rock 5B
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> -
The Rockchip power-domain controller also plans to make use of per-domain regulators similar to the MediaTek power-domain controller. Since existing DTs are missing the regulator information, the kernel should fallback to the automatically created dummy regulator if necessary. Thus the version without the _optional suffix is needed. The Rockchip driver plans to use the managed version, but to be consistent with existing code the unmanaged version is added at the same time. Signed-off-by:Sebastian Reichel <sebastian.reichel@collabora.com> -
Make HDMI receiver driver use default EDID, not requiring user to load EDID manually using v4l-utils. Signed-off-by:Dmitry Osipenko <dmitry.osipenko@collabora.com> -
Enable HDMI input port of the RK3588 EVB1. Signed-off-by:Sebastian Reichel <sebastian.reichel@collabora.com> -
The Rock 5B has a Micro HDMI port, which can be used for receiving HDMI data. This enables support for it. Signed-off-by:Sebastian Reichel <sebastian.reichel@collabora.com> -
The Rockchip RK3588 has a built-in HDMI receiver block from Synopsys. Let's enable the driver for it. Signed-off-by:Sebastian Reichel <sebastian.reichel@collabora.com>
-
