- Nov 19, 2024
-
-
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>
-
Add the necessary DT changes to enable HDMI0 on Radxa ROCK 5A. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20241019-rk3588-hdmi0-dt-v2-5-466cd80e8ff9@collabora.com Signed-off-by: Sebastian Reichel <sre@kernel.org>
-
add gpu node to make it usable on Radxa ROCK 5A. Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Link: https://lore.kernel.org/r/20241019025008.852-1-naoki@radxa.com Signed-off-by: Sebastian Reichel <sre@kernel.org>
-
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>
-
Providing the random seed to firmware was tied to the fact that the device has a valid OTP, which worked for some Apple chips. However, it turns out the BCM43752 device also needs the random seed in order to get firmware running. Suspect it is simply tied to the firmware branch used for the device. Introducing a mechanism to allow setting it for a device through the device table. Co-developed-by: Ondrej Jirman <megi@xff.cz> Signed-off-by: Ondrej Jirman <megi@xff.cz> Co-developed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> Link: https://lore.kernel.org/r/20240910-wireless-mainline-v14-4-9d80fea5326d@wesion.com Signed-off-by: Sebastian Reichel <sre@kernel.org>
-
WiFi modules often require 32kHz clock to function. Add support to enable the clock to PCIe driver and move "brcm,bcm4329-fmac" check to the top of brcmf_of_probe. Change function prototypes from void to int and add appropriate errno's for return values that will be send to bus when error occurred. Co-developed-by: Ondrej Jirman <megi@xff.cz> Signed-off-by: Ondrej Jirman <megi@xff.cz> Co-developed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Reviewed-by: Sai Krishna <saikrishnag@marvell.com> Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> Link: https://lore.kernel.org/r/20240910-wireless-mainline-v14-3-9d80fea5326d@wesion.com Signed-off-by: Sebastian Reichel <sre@kernel.org>
-
Not only AP6275P Wi-Fi device but also all Broadcom wireless devices allow external low power clock input. In DTS the clock as an optional choice in the absence of an internal clock. Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> Link: https://lore.kernel.org/r/20240910-wireless-mainline-v14-2-9d80fea5326d@wesion.com Signed-off-by: Sebastian Reichel <sre@kernel.org>
-
It's the device id used by AP6275P which is the Wi-Fi module used by Rockchip's RK3588 evaluation board and also used in some other RK3588 boards. Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> Link: https://lore.kernel.org/r/20240910-wireless-mainline-v14-1-9d80fea5326d@wesion.com Signed-off-by: Sebastian Reichel <sre@kernel.org>
-
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>
-
- Nov 18, 2024
-
-
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>
-
The RK3588 SoC family integrates the newer Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller IP and a HDMI/eDP TX Combo PHY based on a Samsung IP block. Add just the basic support for now, i.e. RGB output up to 4K@60Hz, without audio, CEC or any of the HDMI 2.1 specific features. Co-developed-by: Algea Cao <algea.cao@rock-chips.com> Signed-off-by: Algea Cao <algea.cao@rock-chips.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
-
The Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller supports the following features, among others: * Fixed Rate Link (FRL) * 4K@120Hz and 8K@60Hz video modes * Variable Refresh Rate (VRR) including Quick Media Switching (QMS), aka Cinema VRR * Fast Vactive (FVA), aka Quick Frame Transport (QFT) * SCDC I2C DDC access * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4 * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds * Multi-stream audio * Enhanced Audio Return Channel (EARC) Add driver to enable basic support, i.e. RGB output up to 4K@60Hz, without audio, CEC or any HDMI 2.1 specific features. Co-developed-by: Algea Cao <algea.cao@rock-chips.com> Signed-off-by: Algea Cao <algea.cao@rock-chips.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
-
Rockchip RK3588 SoC integrates the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller. Since this is a new IP block, quite different from those used in the previous generations of Rockchip SoCs, add a new binding file for it. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
-
Add dt-binding schema containing the common properties for the Synopsys DesignWare HDMI QP TX controller. Note this is not a full dt-binding specification, but is meant to be referenced by platform-specific bindings for this IP core. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
-
The initial vop2 support for rk3588 in mainline is not able to handle all display modes supported by connected displays, e.g. 2560x1440-75.00Hz, 2048x1152-60.00Hz, 1024x768-60.00Hz. Additionally, it doesn't cope with non-integer refresh rates like 59.94, 29.97, 23.98, etc. Make use of the HDMI0 PHY PLL to support the additional display modes. Note this requires commit "drm/rockchip: vop2: Improve display modes handling on rk3588", which needs a rework to be upstreamable. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
-
The initial vop2 support for rk3588 in mainline is not able to handle all display modes supported by connected displays, e.g. 2560x1440-75.00Hz, 2048x1152-60.00Hz, 1024x768-60.00Hz. Additionally, it doesn't cope with non-integer refresh rates like 59.94, 29.97, 23.98, etc. Make use of the HDMI0 PHY PLL to support the additional display modes. Note this requires commit "drm/rockchip: vop2: Improve display modes handling on rk3588", which needs a rework to be upstreamable. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
-
The HDMI0 PHY can be used as a clock provider on RK3588, hence add the missing #clock-cells property.
-
Add the necessary DT changes to enable HDMI0 on Rockchip RK3588 EVB1. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
-
Add the necessary DT changes to enable HDMI0 on Rock 5B. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
-
Add DT node for the HDMI0 bridge found on RK3588 SoC. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
-
The initial vop2 support for rk3588 in mainline is not able to handle all display modes supported by connected displays, e.g. 2560x1440-75.00Hz, 2048x1152-60.00Hz, 1024x768-60.00Hz. Additionally, it doesn't cope with non-integer refresh rates like 59.94, 29.97, 23.98, etc. Improve HDMI0 clocking in order to support the additional display modes. Fixes: 5a028e8f ("drm/rockchip: vop2: Add support for rk3588") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
-
Allow using the clock provided by HDMI0 PHY PLL to improve HDMI output support on RK3588 SoC. 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>
-
Sebastian Reichel authored
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 proper 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 ]--- At this point the SPI transaction has already been programmed and the poweroff will proceed, so the board will shutdown anyways. As a side-effect this also works around the prepare shutdown handler not being called at all on Asus C201 and thus fixes its poweroff functionality, which regressed due to the conversion from pm_power_off to using SYS_OFF_MODE_POWER_OFF_PREPARE. 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>
-
Sebastian Reichel authored
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>
-