- Apr 10, 2024
-
-
Detlev Casanova authoredFor the cbcr format, gt2 and gt4 are computed again after src_h has been divided by vsub. As src_h as already been divided by 2 before, introduce cbcr_src_h and cbcr_src_w to keep a copy of those values to be used for cbcr gt2 and gt4 computation. This fixes yuv planes being unaligned vertically when down scaling to 1080 pixels from 2160. Signed-off-by:
Detlev Casanova <detlev.casanova@collabora.com>
Fixes: 604be855 ("drm/rockchip: Add VOP2 driver")
-
- Mar 28, 2024
-
-
Currently the PCIe v3 PHY driver only sets the pcie1ln_sel bits, but does not clear them because of an incorrect write mask. This fixes up the issue by using a newly introduced constant for the write mask. While at it it also introduces a proper GENMASK based constant for the PCIE30_PHY_MODE. Fixes: 2e9bffc4 ("phy: rockchip: Support PCIe v3") Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> -
The pcie1l0_sel and pcie1l1_sel bits in PCIESEL_CON configure the mux for PCIe1L0 and PCIe1L1 to either the PIPE Combo PHYs or the PCIe3 PHY. Thus this configuration interfers with the data-lanes configuration done by the PCIe3 PHY. RK3588 has three Combo PHYs. The first one has a dedicated PCIe controller and is not affected by this. For the other two Combo PHYs, there is one mux for each of them. pcie1l0_sel selects if PCIe 1L0 is muxed to Combo PHY 1 when bit is set to 0 or to the PCIe3 PHY when bit is set to 1. pcie1l1_sel selects if PCIe 1L1 is muxed to Combo PHY 2 when bit is set to 0 or to the PCIe3 PHY when bit is set to 1. Currently the code always muxes 1L0 and 1L1 to the Combi PHYs once one of them is being used in PCIe mode. This is obviously wrong when at least one of the ports should be muxed to the PCIe3 PHY. Fix this by introducing Combo PHY identification and then only setting up the required bit. Fixes: a03c4427 ("phy: rockchip: Add naneng combo phy support for RK3588") Reported-by:
Michal Tomek <mtdev79b@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> -
So far all RK3588 boards use fully aggregated PCIe. CM3588 is one of the few boards using this feature and apparently it is broken. The PHY offers the following mapping options: port 0 lane 0 - always mapped to controller 0 (4L) port 0 lane 1 - to controller 0 or 2 (1L0) port 1 lane 0 - to controller 0 or 1 (2L) port 1 lane 1 - to controller 0, 1 or 3 (1L1) The data-lanes DT property maps these as follows: 0 = no controller (unsupported by the HW) 1 = 4L 2 = 2L 3 = 1L0 4 = 1L1 That allows the following configurations with first column being the mainline data-lane mapping, second column being the downstream name, third column being PCIE3PHY_GRF_CMN_CON0 and PHP_GRF_PCIESEL register values and final column being the user visible lane setup: <1 1 1 1> = AGGREG = [4 0] = x4 (aggregation; used by most boards) <1 1 2 2> = NANBNB = [0 0] = x2 x2 (no bif.) <1 3 2 2> = NANBBI = [1 1] = x2 x1x1 (bif. of port 0) <1 1 2 4> = NABINB = [2 2] = x1x1 x2 (bif. of port 1) <1 3 2 4> = NABIBI = [3 3] = x1x1 x1x1 (bif. of both ports; used by CM3588) The driver currently does not program PHP_GRF_PCIESEL correctly, which is fixed by this patch. As a side-effect the new logic is much simpler than the old logic. Fixes: 2e9bffc4 ("phy: rockchip: Support PCIe v3") Signed-off-by:
Michal Tomek <mtdev79b@gmail.com>
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. Signed-off-by:
Dingxian Wen <shawn.wen@rock-chips.com>
Co-developed-by: Shreeya Patel <shreeya.patel@collabora.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Tested-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. Signed-off-by:
Dingxian Wen <shawn.wen@rock-chips.com>
Co-developed-by: Shreeya Patel <shreeya.patel@collabora.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com> -
Document bindings for the Synopsys DesignWare HDMI RX Controller. Reviewed-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com> -
Export hdmirx_biu soft reset id which is required by the hdmirx controller. Signed-off-by:Shreeya Patel <shreeya.patel@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> -
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> -
Document the DW HDMI TX Controller found on Rockchip RK3588 SoC. Since RK3588 uses different clocks than previous Rockchip SoCs and also requires a couple of reset lines and some additional properties, provide the required changes in the binding to be able to handle all variants. 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>
-
- Mar 26, 2024
-
-
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 HDMI PHY PLL can be used as an alternative dclk source to SoC CRU. It provides more accurate clock rates required to properly support various display modes, e.g. those relying on non-integer refresh rates. Also note this only works for HDMI 2.0 or bellow, e.g. cannot be used to support HDMI 2.1 4K@120Hz mode. Signed-off-by:Cristian Ciocaltea <cristian.ciocaltea@collabora.com> -
The PHY can be used as a clock provider on RK3588, hence add the missing '#clock-cells' property. 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/59d5595a24bbcca897e814440179fa2caf3dff38.1707040881.git.Sandor.yu@nxp.com/ 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> -
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> -
There is a clk == NULL check after the switch to check for unsupported clk types. Since clk is re-assigned in a loop, this check is useless right now for anything but the first round. Let's fix this up by assigning clk = NULL in the loop before the switch statement. Signed-off-by:Sebastian Reichel <sebastian.reichel@collabora.com> -
Move rockchip_clk_add_lookup to clk.h, so that it can be used by sub-devices with their own driver. These might also have to do a lookup, so rename the function to rockchip_clk_set_lookup and add a matching rockchip_clk_add_lookup. Signed-off-by:Sebastian Reichel <sebastian.reichel@collabora.com> -
The proper GATE_LINK implementation will use runtime PM to handle the linked gate clocks, which requires device context. Currently all clocks are registered early via CLK_OF_DECLARE, which is before the kernel knows about devices. Moving the full clocks registration to the probe routine does not work, since the clocks needed for timers must be registered early. To work around this issue, most of the clock tree is registered early, but GATE_LINK clocks are handled in the probe routine. Since the resets are not needed early either, they have also been moved to the probe routine. Signed-off-by:Sebastian Reichel <sebastian.reichel@collabora.com> -
In the future some clocks will be registered using CLK_OF_DECLARE and some are registered later from the driver probe routine. Any clock handled by the probe routine should return -EPROBE_DEFER until that routine has been called. Signed-off-by:Sebastian Reichel <sebastian.reichel@collabora.com> -
All clocks are registered early using CLK_OF_DECLARE(), which marks the DT node as processed. For the processed DT node the probe routine is never called. Thus this whole code is never executed. This could be "fixed" by using CLK_OF_DECLARE_DRIVER, which avoids marking the DT node as processed. But then the probe routine would re-register all the clocks by calling rk3588_clk_init() again. Signed-off-by:Sebastian Reichel <sebastian.reichel@collabora.com> -
Enable PCIe bus used by on-board PCIe Broadcom WLAN controller. The WLAN controller is not detected. There are two reasons for that. First of all it is necessary to keep the HYM8563 clock enabled, but it is disabled because the kernel does not know about the dependency and disables any clocks it deems unused. Apart from that it looks like the controller needs a long time to be properly initialized. So detection only works when rescanning the bus some time after boot. This still needs to be investigated. Both of these issues should be fixable by implementing a pwrseq driver once the following series has landed: https://lore.kernel.org/all/20240104130123.37115-1-brgl@bgdev.pl/ In addition to the above issues, the mainline brcmfmac driver does not yet support the chip version used by AP6275P. Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> -
This introduces additional OPPs that share the same voltage as another OPP already present in the .dtsi but with lower frequency. The idea is to try and limit system throughput more gradually upon reaching the throttling condition for workloads that are close to sustainable power already, thus avoiding needless performance loss. My limited synthetic benchmarking [1] showed around 3.8% performance benefit when these are in place, other things equal (not meant to be comprehensive). Though dmesg complains about these OPPs being 'inefficient': [ 9.009561] cpu cpu0: EM: OPP:816000 is inefficient [ 9.009580] cpu cpu0: EM: OPP:600000 is inefficient [ 9.009591] cpu cpu0: EM: OPP:408000 is inefficient [ 9.011370] cpu cpu4: EM: OPP:2352000 is inefficient [ 9.011379] cpu cpu4: EM: OPP:2304000 is inefficient [ 9.011384] cpu cpu4: EM: OPP:2256000 is inefficient [ 9.011389] cpu cpu4: EM: OPP:600000 is inefficient [ 9.011393] cpu cpu4: EM: OPP:408000 is inefficient [ 9.012978] cpu cpu6: EM: OPP:2352000 is inefficient [ 9.012987] cpu cpu6: EM: OPP:2304000 is inefficient [ 9.012992] cpu cpu6: EM: OPP:2256000 is inefficient [ 9.012996] cpu cpu6: EM: OPP:600000 is inefficient [ 9.013000] cpu cpu6: EM: OPP:408000 is inefficient [1] https://lore.kernel.org/linux-rockchip/CABjd4YxqarUCbZ-a2XLe3TWJ-qjphGkyq=wDnctnEhdoSdPPpw@mail.gmail.com/T/#me92aa0ee25e6eeb1d1501ce85f5af4e58b3b13c5 Signed-off-by:
Alexey Charkov <alchark@gmail.com>
Link: https://lore.kernel.org/r/20240229-rk-dts-additions-v3-5-6afe8473a631@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> -
By default the CPUs on RK3588 start up in a conservative performance mode. Add frequency and voltage mappings to the device tree to enable dynamic scaling via cpufreq. OPP values are adapted from Radxa's downstream kernel for Rock 5B [1], stripping them down to the minimum frequency and voltage combinations as expected by the generic upstream cpufreq-dt driver, and also dropping those OPPs that don't differ in voltage but only in frequency (keeping the top frequency OPP in each case). Note that this patch ignores voltage scaling for the CPU memory interface which the downstream kernel does through a custom cpufreq driver, and which is why the downstream version has two sets of voltage values for each OPP (the second one being meant for the memory interface supply regulator). This is done instead via regulator coupling between CPU and memory interface supplies on affected boards. This has been tested on Rock 5B with u-boot 2023.11 compiled from Collabora's integration tree [2] with binary bl31 and appears to be stable both under active cooling and passive cooling (with throttling) [1] https://github.com/radxa/kernel/blob/stable-5.10-rock5/arch/arm64/boot/dts/rockchip/rk3588s.dtsi [2] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/u-boot Signed-off-by:
Alexey Charkov <alchark@gmail.com>
Link: https://lore.kernel.org/r/20240229-rk-dts-additions-v3-4-6afe8473a631@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> -
RK3588 chips allow for their CPU cores to be powered by a different supply vs. their corresponding memory interfaces, and two of the boards currently upstream do that (EVB1 and QuartzPro64). The voltage of the memory interface though has to match that of the CPU cores that use it, which downstream kernels achieve by the means of a custom cpufreq driver which adjusts both at the same time. It seems that regulator coupling is a more appropriate generic interface for it, so this patch introduces coupling to affected device trees to ensure that memory interface voltage is also updated whenever cpufreq switches between CPU OPPs. Note that other boards, such as Radxa Rock 5B, define both the CPU and memory interface regulators as aliases to the same DT node, so this doesn't apply there. Signed-off-by:
Alexey Charkov <alchark@gmail.com>
Link: https://lore.kernel.org/r/20240229-rk-dts-additions-v3-3-6afe8473a631@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> -
This links the PWM fan on Radxa Rock 5B as an active cooling device managed automatically by the thermal subsystem, with a target SoC temperature of 65C and a minimum-spin interval from 55C to 65C to ensure airflow when the system gets warm Signed-off-by:
Alexey Charkov <alchark@gmail.com>
Helped-by: Dragan Simic <dsimic@manjaro.org>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20240229-rk-dts-additions-v3-2-6afe8473a631@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> -
Include thermal zones information in device tree for RK3588 variants. This also enables the TSADC controller unconditionally on all boards to ensure that thermal protections are in place via throttling and emergency reset, once OPPs are added to enable CPU DVFS. The default settings (using CRU as the emergency reset mechanism) should work on all boards regardless of their wiring, as CRU resets do not depend on any external components. Boards that have the TSHUT signal wired to the reset line of the PMIC may opt to switch to GPIO tshut mode instead (rockchip,hw-tshut-mode = <1>;) It seems though that downstream kernels don't use that, even for those boards where the wiring allows for GPIO based tshut, such as Radxa Rock 5B [1], [2], [3] [1] https://github.com/radxa/kernel/blob/stable-5.10-rock5/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts#L540 [2] https://github.com/radxa/kernel/blob/stable-5.10-rock5/arch/arm64/boot/dts/rockchip/rk3588s.dtsi#L5433 [3] https://dl.radxa.com/rock5/5b/docs/hw/radxa_rock_5b_v1423_sch.pdf page 11 (TSADC_SHUT_H) Signed-off-by:
Alexey Charkov <alchark@gmail.com>
Link: https://lore.kernel.org/r/20240229-rk-dts-additions-v3-1-6afe8473a631@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> -
Add support for using the Radxa Rock 5 Model B USB-C port for USB in OHCI, EHCI or XHCI mode. Displayport AltMode is not yet supported. Note: Enabling support for the USB-C port results in a board reset when the system is supplied with a PD capable power-supply. Until this has been analyzed and fixed, let's disable support for the Type-C port. For details check this Gitlab issue: hardware-enablement/rockchip-3588/linux#8 Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> -
Enable full support (XHCI, EHCI, OHCI) for the lower USB3 port from Radxa Rock 5 Model B. The upper one is already supported. Signed-off-by:Sebastian Reichel <sebastian.reichel@collabora.com> -
Enable full support (XHCI, EHCI, OHCI) for the upper USB3 port from Radxa Rock 5 Model A. The lower one is already supported. Signed-off-by:Sebastian Reichel <sebastian.reichel@collabora.com>
-
