- Dec 02, 2024
-
-
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>
-
In some cases, rk_hdptx_phy_runtime_resume() may be invoked before platform_set_drvdata() is executed in ->probe(), leading to a NULL pointer dereference when using the return of dev_get_drvdata(). Ensure platform_set_drvdata() is called before devm_pm_runtime_enable(). Reported-by: Dmitrii Osipenko <dmitry.osipenko@collabora.com> Fixes: 553be283 ("phy: rockchip: Add Samsung HDMI/eDP Combo PHY driver") 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>
-
When I converted rk808 to device managed resources I converted the rk808 specific pm_power_off handler to devm_register_sys_off_handler() using SYS_OFF_MODE_POWER_OFF_PREPARE, which is allowed to sleep. I did this because the driver's poweroff function makes use of regmap and the backend of that might sleep. But the PMIC poweroff function will kill off the board power and the kernel does some extra steps after the prepare handler. Thus the prepare handler should not be used for the PMIC's poweroff routine. Instead the normal SYS_OFF_MODE_POWER_OFF phase should be used. The old pm_power_off method is also being called from there, so this would have been a cleaner conversion anyways. But it still makes sense to investigate the sleep handling and check if there are any issues. Apparently the Rockchip and Meson I2C drivers (the only platforms using the PMICs handled by this driver) both have support for atomic transfers and thus may be called from the atomic poweroff context. Things are different on the SPI side. That is so far only used by rk806 and that one is only used by Rockchip RK3588. Unfortunately the Rockchip SPI driver does not support atomic transfers. That means this change will introduce an error splash directly before doing the final power off on all upstream supported RK3588 boards: [ 13.761353] ------------[ cut here ]------------ [ 13.761764] Voluntary context switch within RCU read-side critical section! [ 13.761776] WARNING: CPU: 0 PID: 1 at kernel/rcu/tree_plugin.h:330 rcu_note_context_switch+0x3ac/0x404 [ 13.763219] Modules linked in: [ 13.763498] CPU: 0 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.10.0-12284-g2818a9a19514 #1499 [ 13.764297] Hardware name: Rockchip RK3588 EVB1 V10 Board (DT) [ 13.764812] pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 13.765427] pc : rcu_note_context_switch+0x3ac/0x404 [ 13.765871] lr : rcu_note_context_switch+0x3ac/0x404 [ 13.766314] sp : ffff800084f4b5b0 [ 13.766609] x29: ffff800084f4b5b0 x28: ffff00040139b800 x27: 00007dfb4439ae80 [ 13.767245] x26: ffff00040139bc80 x25: 0000000000000000 x24: ffff800082118470 [ 13.767880] x23: 0000000000000000 x22: ffff000400300000 x21: ffff000400300000 [ 13.768515] x20: ffff800083a9d600 x19: ffff0004fee48600 x18: fffffffffffed448 [ 13.769151] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000048 [ 13.769787] x14: fffffffffffed490 x13: ffff80008473b3c0 x12: 0000000000000900 [ 13.770421] x11: 0000000000000300 x10: ffff800084797bc0 x9 : ffff80008473b3c0 [ 13.771057] x8 : 00000000ffffefff x7 : ffff8000847933c0 x6 : 0000000000000300 [ 13.771692] x5 : 0000000000000301 x4 : 40000000fffff300 x3 : 0000000000000000 [ 13.772328] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000400300000 [ 13.772964] Call trace: [ 13.773184] rcu_note_context_switch+0x3ac/0x404 [ 13.773598] __schedule+0x94/0xb0c [ 13.773907] schedule+0x34/0x104 [ 13.774198] schedule_timeout+0x84/0xfc [ 13.774544] wait_for_completion_timeout+0x78/0x14c [ 13.774980] spi_transfer_one_message+0x588/0x690 [ 13.775403] __spi_pump_transfer_message+0x19c/0x4ec [ 13.775846] __spi_sync+0x2a8/0x3c4 [ 13.776161] spi_write_then_read+0x120/0x208 [ 13.776543] rk806_spi_bus_read+0x54/0x88 [ 13.776905] _regmap_raw_read+0xec/0x16c [ 13.777257] _regmap_bus_read+0x44/0x7c [ 13.777601] _regmap_read+0x60/0xd8 [ 13.777915] _regmap_update_bits+0xf4/0x13c [ 13.778289] regmap_update_bits_base+0x64/0x98 [ 13.778686] rk808_power_off+0x70/0xfc [ 13.779024] sys_off_notify+0x40/0x6c [ 13.779356] atomic_notifier_call_chain+0x60/0x90 [ 13.779776] do_kernel_power_off+0x54/0x6c [ 13.780146] machine_power_off+0x18/0x24 [ 13.780499] kernel_power_off+0x70/0x7c [ 13.780845] __do_sys_reboot+0x210/0x270 [ 13.781198] __arm64_sys_reboot+0x24/0x30 [ 13.781558] invoke_syscall+0x48/0x10c [ 13.781897] el0_svc_common+0x3c/0xe8 [ 13.782228] do_el0_svc+0x20/0x2c [ 13.782528] el0_svc+0x34/0xd8 [ 13.782806] el0t_64_sync_handler+0x120/0x12c [ 13.783197] el0t_64_sync+0x190/0x194 [ 13.783527] ---[ end trace 0000000000000000 ]--- The board will shutdown nevertheless, since this also re-enables interrupts. A proper fix for this requires changes to the core SPI subsystem and will be done as a follow-up series. Note, that this patch also fixes a problem for the Asus C201. Without the function being registered as a proper shutdown handler the syscall for poweroff exits early and does not even call the shutdown prepare handler. This in turn means the system can no longer poweroff properly since my original change. Fixes: 4fec8a5a ("mfd: rk808: Convert to device managed resources") Cc: stable@vger.kernel.org Reported-by: Urja <urja@urja.dev> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Enable driver for the Rockchip RK3588 video decoder, which will also be used by the RK3566/RK3568 in the future. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Add the rkvdec2 Video Decoder to the RK3588s devicetree. Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
-
Document the Rockchip RK3588 Video Decoder bindings. Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
-
This driver supports the second generation of the Rockchip Video decoder, also known as vdpu34x. It is currently only used on the RK3588(s) SoC. There are 2 decoders on the RK3588 SoC that can work in pair to decode 8K video at 30 FPS but currently, only using one core at a time is supported. Scheduling requests between the two cores will be implemented later. The core supports H264, HEVC, VP9 and AVS2 decoding but this driver currently only supports H264. The driver is based on rkvdec and they may share some code in the future. The decision to make a different driver is mainly because rkvdec2 has more features and can work with multiple cores. The registers are mapped in a struct in RAM using bitfields. It is IO copied to the HW when all values are configured. The decision to use such a struct instead of writing buffers one by one is based on the following reasons: - Rockchip cores are known to misbehave when registers are not written in address order, - Those cores also need the software to write all registers, even if they are written their default values or are not related to the task (this core will not start decoding some H264 frames if some VP9 registers are not written to 0) - In the future, to support multiple cores, the scheduler could be optimized by storing the precomputed registers values and copy them to the HW as soos as a core becomes available. This makes the code more readable and may bring performance improvements in future features. Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
-
The table will be shared with the rkvdec2 driver in following commits. As HW formatted CABAC tables can be shared between drivers, it makes sense to group them in an include folder. Each driver can include the tables they need so that all tables are not built in the kernel, but rather in each driver, if the driver is enabled. Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
-
This flag is needed for drivers that have a minimum height lower than 32 pixels. This is because when the flag is not set, the height is halved, which would make it lower than 16 pixels if min height is 16. Setting this flag will keep the height at its value and have a valid SPS. Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
-
This drops to hs200 mode and 150Mhz as this is actually stable across eMMC modules. There exist some that are incompatible at higher rates with the rk3588 and to avoid your filesystem corrupting due to IO errors, be more conservative and reduce the max. speed. Signed-off-by: Carsten Haitzler <raster@rasterman.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Also describe clkreq and wake signals in the PCIe pinmux used by the onboard LAN card. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Add rfkill support for bluetooth. Bluetooth support itself is still missing, but this ensures bluetooth can be powered off properly. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
With the proper GATE_LINK support, we no longer need to keep the linked clocks always on. Thus it's time to drop the CLK_IS_CRITICAL flag for them. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Recent Rockchip SoCs have a new hardware block called Native Interface Unit (NIU), which gates clocks to devices behind them. These clock gates will only have a running output clock when all of the following conditions are met: 1. the parent clock is enabled 2. the enable bit is set correctly 3. the linked clock is enabled To handle them this code registers them as a normal gate type clock, which takes care of condition 1 + 2. The linked clock is handled by using runtime PM clocks. Handling it via runtime PM requires setting up a struct device for each of these clocks with a driver attached to use the correct runtime PM operations. Thus the complete handling of these clocks has been moved into its own driver. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-