- Mar 13, 2024
-
-
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>
-
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>
-
HCLK_NVM is used for SFC, eMMC, SDIO and SDMMC. The dependency for SFC, eMMC and SDIO is properly described, but SDMMC is missing the information that it needs HCLK_NVM. Since HCLK_SD clock is sourced from the firmware, adding this dependency is not trivially possible. Considering, that almost any board will use one of the above interfaces, let's just mark hclk_nvm explicitly as critical independently of the linked clock. 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 effectively need two parent clocks. GATE_LINK type clocks handle the second parent via 'linkedclk' by using runtime PM clocks. This requires, that the GATE_LINK clocks are assigned to a device, so they cannot be registered via CLK_OF_DECLARE. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
The proper GATE_LINK implementation will use 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 clocks 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. Note, that a follow-up patch plans to use late registered clocks, which is done using a platform device. to ease reviewing it makes sense to first of all remove this. 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>
-
- Mar 11, 2024
-
-
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: #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>
-
Add support for the board's USB3 connectors. It has 1x USB Type-A and 1x USB Type-C. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Add both USB3 dual-role controllers to the RK3588 devicetree. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Add both USB3-DisplayPort PHYs to RK3588 SoC DT. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
usb2-phy should be named usb2phy according to the DT binding, so let's fix it up accordingly. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Reorder common DT properties alphabetically for usb2phy, according to latest DT style rules. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
The USBDP Phy is used by RK3588 to handle the Dual-Role USB3 controllers. The Phy also supports Displayport Alt-Mode, but the necessary DRM driver has not yet been merged. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
This adds a new USBDP combo PHY with Samsung IP block driver. The driver get lane mux and mapping info in 2 ways, supporting DisplayPort alternate mode or parsing from DT. When parsing from DT, the property "rockchip,dp-lane-mux" provide the DP mux and mapping info. This is needed when the PHY is not used with TypeC Alt-Mode. For example if the USB3 interface of the PHY is connected to a USB Type A connector and the DP interface is connected to a DisplayPort connector. When do DP link training, need to set lane number, link rate, swing, and pre-emphasis via PHY configure interface. Co-developed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Co-developed-by: Zhang Yubing <yubing.zhang@rock-chips.com> Signed-off-by: Zhang Yubing <yubing.zhang@rock-chips.com> Co-developed-by: Frank Wang <frank.wang@rock-chips.com> Signed-off-by: Frank Wang <frank.wang@rock-chips.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Add device tree binding document for Rockchip USBDP Combo PHY with Samsung IP block. Co-developed-by: Frank Wang <frank.wang@rock-chips.com> Signed-off-by: Frank Wang <frank.wang@rock-chips.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Replace the open coded abs_diff() with the existing helper function. Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
The clock framework handles clock rates as "unsigned long", so u32 on 32-bit architectures and u64 on 64-bit architectures. The current code casts the dividend to u64 on 32-bit to avoid a potential overflow. For example DIV_ROUND_UP(3000000000, 1500000000) = (3.0G + 1.5G - 1) / 1.5G = = OVERFLOW / 1.5G, which has been introduced in commit 9556f9da ("clk: divider: handle integer overflow when dividing large clock rates"). On 64 bit platforms this masks the divisor, so that only the lower 32 bit are used. Thus requesting a frequency >= 4.3GHz results in incorrect values. For example requesting 4300000000 (4.3 GHz) will effectively request ca. 5 MHz. Requesting clk_round_rate(clk, ULONG_MAX) is a bit of a special case, since that still returns correct values as long as the parent clock is below 8.5 GHz. Fix this by switching to DIV_ROUND_UP_NO_OVERFLOW, which cannot overflow. This avoids any requirements on the arguments (except that divisor should not be 0 obviously). Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Add a new DIV_ROUND_UP helper, which cannot overflow when big numbers are being used. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
There are cases where an unavailable port is not an error, making this error message a false-positive. Since commit d56de8c9 ("usb: typec: tcpm: try to get role switch from tcpc fwnode") the role switch is tried on the port dev first and tcpc fwnode afterwards. If using the latter bindings getting from port dev fails every time. The kernel log is flooded with the messages like: OF: graph: no port node found in /soc@0/bus@42000000/i2c@42530000/usb-typec@50 Silence this message by making it a debug message. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20240117083206.2901534-1-alexander.stein@ew.tq-group.com [picked up from upstream as alternative to my fix for the TypeC issue] Signed-off-by: Sebastian Reichel <sre@kernel.org>
-
Add driver for the HDMI/eDP TX Combo PHY found on Rockchip RK3588 SoC. The PHY is based on a Samsung IP block and supports HDMI 2.1 TMDS, FRL and eDP links. The maximum data rate is 12Gbps (FRL), while the minimum is 250Mbps (TMDS). Only the TMDS link is currently supported. Co-developed-by: Algea Cao <algea.cao@rock-chips.com> Signed-off-by: Algea Cao <algea.cao@rock-chips.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20240214-phy-hdptx-v4-2-e7974f46c1a7@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
-
Add DT nodes for HDMI0 PHY and related syscon found on RK3588 SoC. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20240219204626.284399-1-cristian.ciocaltea@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-