- Feb 14, 2025
-
-
Nicolas Dufresne authoredThe clock frequence are properly set in the DT, there should be no need to systematically set clock in the Hantro driver. Signed-off-by:
Nicolas Dufresne <nicolas.dufresne@collabora.com> -
Nicolas Dufresne authored
From Derek I believe
-
Add support for YUV422 and YUV420 Signed-off-by:Derek Foreman <derek.foreman@collabora.com> -
Nicolas Dufresne authored
-
-
Currently we can only set a maximum from userspace, but it's useful to be able to set a minimum too. This allows a compositor to set a minimum, and fall back to manual tone mapping if the expected range isn't available. Signed-off-by:Derek Foreman <derek.foreman@collabora.com> -
Allow setting HDMI output format independently of the plane formats. Needs to be split into infra/impl Needs an atomic check for the rockchip impl. Signed-off-by:Derek Foreman <derek.foreman@collabora.com> -
We need to set connectors_changed to provoke a mode set when the hdr output metadata changes, otherwise we won't update the DRM infoframe. Signed-off-by:Derek Foreman <derek.foreman@collabora.com> -
Add missing plane color properties. Signed-off-by:Derek Foreman <derek.foreman@collabora.com> -
The hardware can do 10-bit and YUV, so add it here. Signed-off-by:Derek Foreman <derek.foreman@collabora.com>
-
- Feb 06, 2025
-
-
Nicolas Dufresne authored
This is a "customer" format, though on Rockchip RK3588 it has been verified to be NV15 format, which matches what the GPU and display handles has 10bit pixel formats. Signed-off-by:Nicolas Dufresne <nicolas.dufresne@collabora.com> -
Add NV15 and NV20 pixel formats used by the Rockchip Video Decoder for 10-bit buffers. NV15 and NV20 is 10-bit 4:2:0/4:2:2 semi-planar YUV formats similar to NV12 and NV16, using 10-bit components with no padding between each component. Instead, a group of 4 luminance/chrominance samples are stored over 5 bytes in little endian order: YYYY = UVUV = 4 * 10 bits = 40 bits = 5 bytes The '15' and '20' suffix refers to the optimum effective bits per pixel which is achieved when the total number of luminance samples is a multiple of 8 for NV15 and 4 for NV20. Signed-off-by:
Jonas Karlman <jonas@kwiboo.se>
Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Tested-by: Christopher Obbard <chris.obbard@collabora.com>
-
- Jan 27, 2025
-
-
Nicolas Frattaroli authoredThe arm64 defconfig does not enable all filesystems one might reasonably expect. While it's fine not to enable everything under the sun, some of these are actually useful in an embedded use-case and reasonably maintained. Enable F2FS, EROFS, ISO9660, EXFAT and XFS for the benefit of both casual users and people setting up demos on the board. Signed-off-by:Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
-
- Jan 20, 2025
-
-
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> -
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. For now only HDMI0 output is supported, hence add the related PLL clock. Signed-off-by:
Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Tested-by: FUKAUMI Naoki <naoki@radxa.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 HDMI0 PHY. Signed-off-by:
Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Tested-by: FUKAUMI Naoki <naoki@radxa.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 HDMI0 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>
Tested-by: FUKAUMI Naoki <naoki@radxa.com> -
The if_pixclk_rate variable is not being used outside of the if-block in rk3588_calc_cru_cfg(), hence move the superfluous assignment from the first branch to the inner comment-block. Signed-off-by:
Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Tested-by: FUKAUMI Naoki <naoki@radxa.com> -
On RK3588, HDMI PHY PLL can be used as an alternative and more accurate pixel clock source for VOP2 video ports 0, 1 and 2. Document the optional PLL clock properties corresponding to the two HDMI PHYs available on the SoC. Signed-off-by:
Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Tested-by: FUKAUMI Naoki <naoki@radxa.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. Signed-off-by:Cristian Ciocaltea <cristian.ciocaltea@collabora.com> -
For upstreaming, this requires extending the standard PHY API to support HDMI configuration options [1]. Currently, the bus_width PHY attribute is used to pass clock rate and flags for 10-bit color depth, FRL and EARC. This is done by the HDMI bridge driver via phy_set_bus_width(). [1]: https://lore.kernel.org/all/20240306101625.795732-3-alexander.stein@ew.tq-group.com/ Signed-off-by:
Cristian Ciocaltea <cristian.ciocaltea@collabora.com> -
The RK3588 EVB1 has an onboard AP6275P WLAN/BT module. This adds support for the WLAN side, which is connected to the second PCIe bus. The Bluetooth side is connected to UART and handled separately. Signed-off-by:Sebastian Reichel <sebastian.reichel@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> -
Add initial support for the Synopsys DesignWare HDMI RX Controller Driver used by Rockchip RK3588. The driver supports: - HDMI 1.4b and 2.0 modes (HDMI 4k@60Hz) - RGB888, YUV422, YUV444 and YCC420 pixel formats - CEC - EDID configuration The hardware also has Audio and HDCP capabilities, but these are not yet supported by the driver. Co-developed-by:
Dingxian Wen <shawn.wen@rock-chips.com>
Signed-off-by: Dingxian Wen <shawn.wen@rock-chips.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com> -
Add device tree support for Synopsys DesignWare HDMI RX Controller. Reviewed-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Co-developed-by: Dingxian Wen <shawn.wen@rock-chips.com>
Signed-off-by: Dingxian Wen <shawn.wen@rock-chips.com>
Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
Link: https://lore.kernel.org/r/20240719124032.26852-4-shreeya.patel@collabora.com
Signed-off-by: Sebastian Reichel <sre@kernel.org> -
Document bindings for the Synopsys DesignWare HDMI RX Controller. Reviewed-by:
Rob Herring <robh@kernel.org>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20240719124032.26852-3-shreeya.patel@collabora.com
Signed-off-by: Sebastian Reichel <sre@kernel.org> -
Add an entry for Synopsys DesignWare HDMI Receiver Controller Driver. Signed-off-by:
Shreeya Patel <shreeya.patel@collabora.com>
Reviewed-by: Christopher Obbard <chris.obbard@collabora.com>
Link: https://lore.kernel.org/r/20240719124032.26852-2-shreeya.patel@collabora.com
Signed-off-by: Sebastian Reichel <sre@kernel.org> -
Enable Rockchip specific extensions for the Synopsys DesignWare HDMI QP driver. This is needed for the HDMI output support on RK3588 SoC based boards. Signed-off-by:Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
-
