aboutsummaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2024-07-09arm64: dts: rockchip: Add Radxa ROCK 3BJonas Karlman2-0/+782
The Radxa ROCK 3B is a single-board computer based on the Pico-ITX form factor (100mm x 75mm). Two versions of the ROCK 3B exists, a community version based on the RK3568 SoC and an industrial version based on the RK3568J SoC. Add initial support for eMMC, SD-card, Ethernet, HDMI, PCIe and USB. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20240627211737.1985549-3-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-08arm64: dts: rockchip: add ROCK 5 ITX boardHeiko Stuebner2-0/+1178
The ROCK 5 ITX as the name suggests is made in the ITX form factor and actually built in a form to be used in a regular case even providing connectors for regular front-panel io. It can be powered either by 12V, ATX power-supply or PoE. Notable peripherals are the 4 SATA ports, M.2 M-Key slot, M.2 E-key slot, 2*2.5Gb PCIe-connected Ethernet NICs. As of yet unsupported display options consist of 2*HDMI, DP via USB-c, eDP + 2*DSI via PCB connectors. USB ports are 4*USB3 + 2*USB2 on the back panel and 2-port front-panel connector. Schematics for the board can be found on - https://dl.radxa.com/rock5/5itx/radxa_rock_5_itx_X1100_schematic.pdf - https://dl.radxa.com/rock5/5itx/v1110/radxa_rock_5itx_v1110_schematic.pdf Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20240704153815.837392-3-heiko@sntech.de
2024-07-08arm64: dts: rockchip: Add dma-names to uart1 on Pine64 rk3566 devicesDiederik de Haas3-0/+3
Similar to bf6f26deb0e8 ("arm64: dts: rockchip: Add dma-names to uart1 on quartz64-b") also add the dma-names property to the other rk3566 devices from Pine64 with bluetooth functionality. Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Tested-by: Riley Trautman <asonix.dev@gmail.com> Link: https://lore.kernel.org/r/20240705163004.29678-4-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-08arm64: dts: rockchip: Add avdd supplies to hdmi on rock64Diederik de Haas1-0/+2
Pine64's Rock64 was missing the avdd supply properties on the hdmi node, causing the following warnings: dwhdmi-rockchip ff3c0000.hdmi: supply avdd-0v9 not found, using dummy regulator dwhdmi-rockchip ff3c0000.hdmi: supply avdd-1v8 not found, using dummy regulator In the Rock64 Schematic document version 2.0 those supplies are marked as DVIDEO_AVDD_1V0 and DVIDEO_AVDD_1V8 respectively, but in version 3.0 those are named HDMI_AVDD_1V0 and HDMI_AVDD_1V8, which is a bit clearer. In both versions those are connected to LDO3 and LDO1 respectively. While the DeviceTree property is named 'avdd-0v9-supply' the 'rockchip,dw-hdmi.yaml' binding document notes the following: A 0.9V supply that powers up the SoC internal circuitry. The actual pin name varies between the different SoCs and is usually HDMI_TX_AVDD_0V9 or sometimes HDMI_AVDD_1V0. So the 'vdd_10' reference is not an error. Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/20240704191919.38856-1-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: fixes PHY reset for Lunzn Fastrhino R68SChukun Pan1-6/+6
Fixed the PHY address and reset GPIOs (does not match the corresponding pinctrl) for gmac0 and gmac1. Fixes: b9f8ca655d80 ("arm64: dts: rockchip: Add Lunzn Fastrhino R68S") Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://lore.kernel.org/r/20240630150010.55729-7-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: disable display subsystem for Lunzn Fastrhino R6xSChukun Pan1-0/+4
The R66S and R68S boards do not have HDMI output, so disable the display subsystem. Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S") Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://lore.kernel.org/r/20240701143028.1203997-3-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: remove unused usb2 nodes for Lunzn Fastrhino R6xSChukun Pan1-16/+0
Fix the following error when booting: [ 15.851853] platform fd800000.usb: deferred probe pending [ 15.852384] platform fd840000.usb: deferred probe pending [ 15.852881] platform fd880000.usb: deferred probe pending This is due to usb2phy1 is not enabled. There is no USB 2.0 port on the board, just remove it. Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S") Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://lore.kernel.org/r/20240630150010.55729-5-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: fix pmu_io supply for Lunzn Fastrhino R6xSChukun Pan3-2/+10
Fixes pmu_io_domains supply according to the schematic. Among them, the vccio3 is responsible for the io voltage of sdcard. There is no sdcard slot on the R68S, and it's connected to vcc_3v3, so describe the supply of vccio3 separately. Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S") Fixes: b9f8ca655d80 ("arm64: dts: rockchip: Add Lunzn Fastrhino R68S") Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://lore.kernel.org/r/20240630150010.55729-4-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: fix usb regulator for Lunzn Fastrhino R6xSChukun Pan1-12/+4
Remove the non-existent usb_host regulator and fix the supply according to the schematic. Also remove the unnecessary always-on and boot-on for the usb_otg regulator. Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S") Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://lore.kernel.org/r/20240701143028.1203997-2-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: fix regulator name for Lunzn Fastrhino R6xSChukun Pan1-4/+4
Make the regulator name the same as those marked by schematics. Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S") Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://lore.kernel.org/r/20240630150010.55729-2-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: Add dma-names to uart1 on quartz64-bDiederik de Haas1-0/+1
There have been several attempts to set the dma-names property on the SoC level (in rk356x.dtsi), but that appears to cause problems when set on channels without flow control. Quoting part of a previous attempt for clarification: > Nah, enabling it for bluetooth is fine because you have flow control. > My issues have been on channels without flow control. Without DMA it > simply drops messages or the channel hangs until you close and reopen > it. With DMA, when an overflow locks up the channel it is usually > unavailable until the board is rebooted. Setting it on the board level for the bluetooth connection was deemed safe, so do so for the Quartz64 Model B. This fixes the following error/warning: of_dma_request_slave_channel: dma-names property of node '/serial@fe650000' missing or empty dw-apb-uart fe650000.serial: failed to request DMA Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Link: https://libera.irclog.whitequark.org/armlinux/2024-02-29 Link: https://lore.kernel.org/linux-rockchip/18284546.sWSEgdgrri@diego/ Reviewed-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/20240628120130.24076-1-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: Update GPU OPP voltages in RK356x SoC dtsiDragan Simic1-5/+5
Update the values for the exact Rockchip RK356x GPU OPP voltages and the lower limits for the GPU OPP voltage ranges, using the most conservative values (i.e. the highest per-OPP voltages) found in the vendor kernel source (cf. downstream commit f8b9431ee38e ("arm64: dts: rockchip: rk3568: support adjust opp-table by otp")). [1][2] Using the most conservative per-OPP voltages ensures reliable GPU operation regardless of the actual GPU binning, with the downside of possibly using a bit more power than absolutely needed. [1] https://github.com/rockchip-linux/kernel/commit/f8b9431ee38ed561650be7092ab93f564598daa9 [2] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi Suggested-by: Diederik de Haas <didi.debian@cknow.org> Helped-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/80301764e8983c8410c806ed2256403823709897.1719763100.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: Add GPU OPP voltage ranges to RK356x SoC dtsiDragan Simic1-6/+6
Add support for voltage ranges to the GPU OPPs defined in the SoC dtsi for Rockchip RK356x. This is, for example, useful for RK356x-based boards that are designed to use the same power supply for the GPU and NPU portions of the SoC, which is described further in the following documents: - Rockchip RK3566 Hardware Design Guide, version 1.1.0, page 37 - Rockchip RK3568 Hardware Design Guide, version 1.2, page 78 The values for the exact GPU OPP voltages and the lower limits for the GPU OPP voltage ranges differ from the values found in the vendor kernel source (cf. downstream commit f8b9431ee38e ("arm64: dts: rockchip: rk3568: support adjust opp-table by otp")), [1][2] and present the exact GPU OPP voltage values that have served us well so far. [1] https://github.com/rockchip-linux/kernel/commit/f8b9431ee38ed561650be7092ab93f564598daa9 [2] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi Suggested-by: Diederik de Haas <didi.debian@cknow.org> Helped-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/7e9ba70fd54a21d6f1f267df11e0acabff8d24e0.1719763100.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: Drop ethernet-phy-ieee802.3-c22 from PHY compatible ↵Marek Vasut2-6/+3
string on all RK3588 boards The rtl82xx DT bindings do not require ethernet-phy-ieee802.3-c22 as the fallback compatible string. There are fewer users of the Realtek PHY compatible string with fallback compatible string than there are users without fallback compatible string, so drop the fallback compatible string from the few remaining users: $ git grep -ho ethernet-phy-id001c....... | sort | uniq -c 1 ethernet-phy-id001c.c816", 2 ethernet-phy-id001c.c915", 2 ethernet-phy-id001c.c915"; 5 ethernet-phy-id001c.c916", 13 ethernet-phy-id001c.c916"; Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202406290316.YvZdvLxu-lkp@intel.com/ Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20240630034910.173552-2-marex@denx.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: Add missing power-domains for rk356x vop_mmuCristian Ciocaltea1-0/+1
The iommu@fe043e00 on RK356x SoC shares the VOP power domain, but the power-domains property was not provided when the node has been added. The consequence is that an attempt to reload the rockchipdrm module will freeze the entire system. That is because on probe time, pm_runtime_get_suppliers() gets called for vop@fe040000, which blocks when pm_runtime_get_sync() is being invoked for iommu@fe043e00. Fix the issue by adding the missing property. Fixes: 9d6c6d978f97 ("arm64: dts: rockchip: rk356x: Add VOP2 nodes") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20240702-rk356x-fix-vop-mmu-v1-1-a66d1a0c45ea@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-28arm64: dts: rockchip: Delete the SoC variant dtsi for RK3399ProDragan Simic1-22/+0
The commit 587b4ee24fc7 ("arm64: dts: rockchip: add core dtsi file for RK3399Pro SoCs") describes the RK3399Pro's PCI Express interface as the way built-in NPU communicates with the rest of the SoC. All available evidence shows this not to be accurate, as described in detail below. Moreover, the rk3399pro.dtsi isn't used anywhere, so let's delete it. The publicly available schematics of the Radxa Rock Pi N10 carrier board [1] and the Vamrs VMARC RK3399Pro SoM, [2] which put together form the currently single supported RK3399Pro-based board, clearly show that the PCI Express x4 interface of this SoC is fully functional and actually not used by the SoC to communicate with the built-in NPU. In more detail, the VMARC SoM exports the SoC's PCI Express interface at its board-to-board connector, and the Rock Pi N10 routes it to an M.2 M-key slot with four PCI Express lanes. Both the Rockchip RK3399Pro datasheet, version 1.1, [3] and the Rockchip RK3399Pro technical reference manual (TRM), first part of the version 1.0, [4] don't describe that the SoC's PCI Express interface is reserved for the NPU. Instead, the RK3399Pro TRM describes that the NPU uses AHB and AXI interfaces as the host interface (HIF). The RK3399Pro datasheet clearly describes that the PCI Express x4 interface is available for general-purpose use, just like it's the case with the standard Rockchip RK3399 SoC, [5] albeit with a bit shorter feature list provided in the RK3399Pro datasheet. Even the publicly available reference RK3399Pro schematic from Rockchip [6] shows the availability of a standard PCI Express slot with four lanes, which would be pretty much impossible if the PCI Express interface was reserved for the communication with the built-in NPU. Based on the RK3399Pro datasheet [3] and the board schematics, [2][6] the built-in NPU actually exports NPU_PCIE as a separate PCI Express x2 interface that's partially pinmuxed with the NPU's separate USB 3.0 interface, which is described further in the next paragraph. However, the NPU's separate PCI Express x2 interface is left undocumented in the publicly available RK3399Pro documentation, in which it's clearly described as reserved for internal use and not intended for the communication with the NPU. Finally, the evidently independent nature of the separate NPU_PCIE x2 interface makes ignoring it safe when it comes to determining the nature and the availability of the RK3399Pro's main PCI Express x4 interface. The actual application-level communication with the built-in NPU, including powering it up and down and uploading the NPU firmware, is performed through the separate USB 2.0 and USB 3.0 interfaces exported by the NPU, [7] which the VMARC SoM [2] and the reference board design from Rockchip [6] route to the SoC's standard USB 2.0 and USB 3.0 interfaces, to make the NPU accessible to software running on the SoC's ARM cores. [1] https://dl.radxa.com/rockpin10/docs/hw/rockpi_n10_sch_v1.1_20190909.pdf [2] https://dl.radxa.com/rockpin10/docs/hw/VMARC_RK3399Pro_sch_V1.1_20190619.pdf [3] https://www.rockchip.fr/RK3399Pro%20datasheet%20V1.1.pdf [4] https://www.rockchip.fr/Rockchip%20RK3399Pro%20TRM%20V1.0%20Part1.pdf [5] https://www.rockchip.fr/RK3399%20datasheet%20V1.8.pdf [6] https://opensource.rock-chips.com/images/e/e4/RK_EVB_RK3399PRO_LP3S178P332SD8_V11_20181113_RZF.pdf [7] https://wiki.radxa.com/RockpiN10/dev/NPU-booting Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/4449f7d4eead787308300e2d1d37b88c9d1446b2.1717308862.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-28arm64: dts: rockchip: Fix mic-in-differential usage on rk3568-evb1-v10Cristian Ciocaltea1-1/+1
The 'mic-in-differential' DT property supported by the RK809/RK817 audio codec driver is actually valid if prefixed with 'rockchip,': DTC_CHK arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dtb rk3568-evb1-v10.dtb: pmic@20: codec: 'mic-in-differential' does not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/mfd/rockchip,rk809.yaml# Make use of the correct property name. Fixes: 3e4c629ca680 ("arm64: dts: rockchip: enable rk809 audio codec on the rk3568 evb1-v10") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20240622-rk809-fixes-v2-5-c0db420d3639@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-28arm64: dts: rockchip: Fix mic-in-differential usage on rk3566-roc-pcCristian Ciocaltea1-1/+1
The 'mic-in-differential' DT property supported by the RK809/RK817 audio codec driver is actually valid if prefixed with 'rockchip,': DTC_CHK arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dtb rk3566-roc-pc.dtb: pmic@20: codec: 'mic-in-differential' does not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/mfd/rockchip,rk809.yaml# Make use of the correct property name. Fixes: a8e35c4bebe4 ("arm64: dts: rockchip: add audio nodes to rk3566-roc-pc") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20240622-rk809-fixes-v2-4-c0db420d3639@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-28arm64: dts: rockchip: Drop invalid mic-in-differential on rk3568-rock-3aCristian Ciocaltea1-4/+0
The 'mic-in-differential' DT property supported by the RK809/RK817 audio codec driver is actually valid if prefixed with 'rockchip,': DTC_CHK arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dtb rk3568-rock-3a.dtb: pmic@20: codec: 'mic-in-differential' does not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/mfd/rockchip,rk809.yaml# However, the board doesn't make use of differential signaling, hence drop the incorrect property and the now unnecessary 'codec' node. Fixes: 22a442e6586c ("arm64: dts: rockchip: add basic dts for the radxa rock3 model a") Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20240622-rk809-fixes-v2-3-c0db420d3639@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-28arm64: dts: rockchip: Add rock5b overlays for PCIe endpoint modeNiklas Cassel3-0/+43
Add rock5b overlays for PCIe endpoint mode support. If using the rock5b as an endpoint against a normal PC, only the rk3588-rock-5b-pcie-ep.dtbo needs to be applied. If using two rock5b:s, with one board as EP and the other board as RC, rk3588-rock-5b-pcie-ep.dtbo and rk3588-rock-5b-pcie-srns.dtbo has to be applied to the respective boards. Signed-off-by: Niklas Cassel <cassel@kernel.org> Link: https://lore.kernel.org/r/20240607-rockchip-pcie-ep-v1-v5-13-0a042d6b0049@kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-28arm64: dts: rockchip: Add PCIe endpoint mode supportNiklas Cassel1-0/+35
Add a device tree node representing PCIe endpoint mode. The controller can either be configured to run in Root Complex or Endpoint mode. If a user wants to run the controller in endpoint mode, the user has to disable the pcie3x4 node and enable the pcie3x4_ep node. Signed-off-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20240607-rockchip-pcie-ep-v1-v5-12-0a042d6b0049@kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: Increase VOP clk rate on RK3328Jonas Karlman1-2/+2
The VOP on RK3328 needs to run at a higher rate in order to produce a proper 3840x2160 signal. Change to use 300MHz for VIO clk and 400MHz for VOP clk, same rates used by vendor 4.4 kernel. Fixes: 52e02d377a72 ("arm64: dts: rockchip: add core dtsi file for RK3328 SoCs") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20240615170417.3134517-2-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: add gpio-line-names to radxa-zero-3Trevor Woerner1-0/+72
Add names to the pins of the general-purpose expansion header as given in the Radxa documentation[1] following the conventions in the kernel[2] to make it easier for users to correlate pins with functions when using utilities such as 'gpioinfo'. [1] https://docs.radxa.com/en/zero/zero3/hardware-design/hardware-interface [2] https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt Signed-off-by: Trevor Woerner <twoerner@gmail.com> Link: https://lore.kernel.org/r/20240620013301.33653-1-twoerner@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: Split GPU OPPs of RK3588 and RK3588jAlexey Charkov3-38/+74
RK3588j uses a different set of OPPs for its GPU, both in terms of allowed frequencies and in terms of voltages. Move the GPU OPPs table into per-variant .dtsi files to accommodate for this difference. The table for RK3588j is adapted from Rockchip downstream sources [1], while RK3588 one is moved verbatim into the per-variant .dtsi file. The values provided for RK3588 in the downstream sources match those in the original commit. [1] https://github.com/rockchip-linux/kernel/blob/604cec4004abe5a96c734f2fab7b74809d2d742f/arch/arm64/boot/dts/rockchip/rk3588s.dtsi Fixes: 6fca4edb93d3 ("arm64: dts: rockchip: Add rk3588 GPU node") Signed-off-by: Alexey Charkov <alchark@gmail.com> Link: https://lore.kernel.org/r/20240617-rk-dts-additions-v5-8-c1f5f3267f1e@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: Add OPP data for CPU cores on RK3588jAlexey Charkov1-0/+108
RK3588j is the 'industrial' variant of RK3588, and it uses a different set of OPPs both in terms of allowed frequencies and in terms of applicable voltages at each frequency setpoint. Add the OPPs that apply to RK3588j (and apparently RK3588m too) to enable dynamic CPU frequency scaling. OPP values are derived from Rockchip downstream sources [1] by taking only those OPPs which have the highest frequency for a given voltage level and dropping the rest (if they are included, the kernel complains at boot time about them being inefficient) [1] https://github.com/rockchip-linux/kernel/blob/604cec4004abe5a96c734f2fab7b74809d2d742f/arch/arm64/boot/dts/rockchip/rk3588s.dtsi Signed-off-by: Alexey Charkov <alchark@gmail.com> Link: https://lore.kernel.org/r/20240617-rk-dts-additions-v5-7-c1f5f3267f1e@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: Add OPP data for CPU cores on RK3588Alexey Charkov3-0/+151
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/20240617-rk-dts-additions-v5-6-c1f5f3267f1e@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: Add CPU/memory regulator coupling for 2 RK3588 boardsAlexey Charkov2-0/+24
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/20240617-rk-dts-additions-v5-5-c1f5f3267f1e@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: fix mmc aliases for Radxa ZERO 3E/3WFUKAUMI Naoki3-5/+3
align with other Radxa products. - mmc0 is eMMC - mmc1 is microSD for ZERO 3E, there is no eMMC, but aliases should start at 0, so mmc0 is microSD as exception. Fixes: 1a5c8d307c83 ("arm64: dts: rockchip: Add Radxa ZERO 3W/3E") Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Changes in v3: - fix syntax error in rk3566-radxa-zero-3e.dts Changes in v2: - microSD is mmc0 instead of mmc1 for ZERO 3E Link: https://lore.kernel.org/r/20240620224435.2752-1-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: Add Neardi LBA3368 boardAlex Bee2-0/+660
LBA3368 is a RK3368 based industrial board from Neardi. Specs: - 1 GB DDR3 DRAM - 8/16 GB eMMC - µSD slot - 100 mbit ethernet (optional 12V PoE) - Ampak AP6255 Wifi/BT combo - ADC button - 4 x USB 2.0 via onboard GL852G HUB connected to SoC's ehci host - 2 exposed as USB-A - 2 via 2-mm-4-pin connectors - micro USB OTG connector - 2 x UART TTL (2-mm-4-pin connectors) - CSI connector - DSI connector - eDP connector - HDMI 2.0a output (type A) - touchpad connector (I2C, 3.3V) - ALC5640 audio codec - combined headphone/microphone jack - speaker connector pads Signed-off-by: Alex Bee <knaerzche@gmail.com> Link: https://lore.kernel.org/r/20240623090116.670607-5-knaerzche@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: Enable PinePhone Pro vibratorPeter Robinson1-0/+6
The PinePhone Pro has a vibrator attached via GPIO so lets enable it. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Link: https://lore.kernel.org/r/20240623165326.1273944-3-pbrobinson@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: Enable PinePhone Pro IMU sensorPeter Robinson1-0/+15
Enable the IMU sensor on the PinePhone Pro including the i2c4 bus that it's attached to. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Link: https://lore.kernel.org/r/20240623165326.1273944-2-pbrobinson@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: Add Pinephone Pro support for GPIO LEDsPeter Robinson1-0/+43
The PinePhone Pro has a cluster of 3 single RGB GPIO LEDs. Add the GPIO entries for the 3 red/green/blue LEDs and an entry for the multi-color group to allow them to be used as a combined RGB LED. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Link: https://lore.kernel.org/r/20240623165326.1273944-1-pbrobinson@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: Enable SPI flash on PinePhone ProPeter Robinson1-0/+10
The PinePhone Pro as SPI flash on board so enable the SPI interface and the flash. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Link: https://lore.kernel.org/r/20240623204616.1344806-1-pbrobinson@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: change spi-max-frequency for Radxa ROCK 3CFUKAUMI Naoki1-1/+1
SPI NOR flash chip may vary, so use safe(lowest) spi-max-frequency. Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Link: https://lore.kernel.org/r/20240623023329.1044-3-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: add (but disabled) SFC node for Radxa ROCK 5AFUKAUMI Naoki1-0/+13
This commit adds SFC node for Radxa ROCK 5A. since sdhci and sfc on RK3588s share pins(i.e. exclusive), it cannot be enabled both nodes at the same time. so status = "okay" is omitted here. you may be able to enable sfc (and disable sdhci) by fdt overlay. SPI NOR flash chip may vary, so use safe(lowest) spi-max-frequency. Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Link: https://lore.kernel.org/r/20240623023329.1044-2-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: add SFC support for Radxa ROCK 5BFUKAUMI Naoki1-0/+14
This commit adds support for SPI NOR flash on Radxa ROCK 5B. SPI NOR flash chip may vary, so use safe(lowest) spi-max-frequency. Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Link: https://lore.kernel.org/r/20240623023329.1044-1-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: enable automatic fan control on Rock 5BAlexey Charkov1-1/+31
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 Helped-by: Dragan Simic <dsimic@manjaro.org> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Alexey Charkov <alchark@gmail.com> Link: https://lore.kernel.org/r/20240617-rk-dts-additions-v5-4-c1f5f3267f1e@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: add passive GPU cooling on RK3588Alexey Charkov1-1/+15
As the GPU support on RK3588 has been merged upstream, along with OPP values, add a corresponding cooling map for passive cooling using the GPU. Signed-off-by: Alexey Charkov <alchark@gmail.com> Link: https://lore.kernel.org/r/20240617-rk-dts-additions-v5-3-c1f5f3267f1e@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: enable thermal management on all RK3588 boardsAlexey Charkov8-0/+32
This enables the on-chip thermal monitoring sensor (TSADC) on all RK3588(s) boards that don't have it enabled yet. It provides temperature monitoring for the SoC and emergency thermal shutdowns, and is thus important to have in place before CPU DVFS is enabled, as high CPU operating performance points can overheat the chip quickly in the absence of thermal management. Signed-off-by: Alexey Charkov <alchark@gmail.com> Link: https://lore.kernel.org/r/20240617-rk-dts-additions-v5-2-c1f5f3267f1e@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: add thermal zones information on RK3588Alexey Charkov1-0/+153
This includes the necessary device tree data to allow thermal monitoring on RK3588(s) using the on-chip TSADC device, along with trip points for automatic thermal management. Each of the CPU clusters (one for the little cores and two for the big cores) get a passive cooling trip point at 85C, which will trigger DVFS throttling of the respective cluster upon reaching a high temperature condition. All zones also have a critical trip point at 115C, which will trigger a reset. Signed-off-by: Alexey Charkov <alchark@gmail.com> Link: https://lore.kernel.org/r/20240617-rk-dts-additions-v5-1-c1f5f3267f1e@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPsDragan Simic7-3076/+3090
Rename the Rockchip RK3588 SoC dtsi files and, consequently, adjust their contents appropriately, to prepare them for the ability to specify different CPU and GPU OPPs for each of the supported RK3588 SoC variants. As already discussed, [1][2][3][4] some of the RK3588 SoC variants require different OPPs, and it makes more sense to have the OPPs already defined when a board dts(i) file includes one of the SoC variant dtsi files (rk3588.dtsi, rk3588j.dtsi or rk3588s.dtsi), rather than requiring the board dts(i) file to also include a separate rk3588*-opp.dtsi file. The choice of the SoC variant is already made by the inclusion of the SoC dtsi file into the board dts(i) file, and it doesn't make much sense to, effectively, allow the board dts(i) file to include and use an incompatible set of OPPs for the already selected RK3588 SoC variant. The new naming scheme for the RK3588 SoC dtsi files uses "-base" and "-extra" suffixes to denote the DT data shared between all RK5588 SoC variants, and the DT data shared between the unrestricted SoC variants, respectively. For example, the DT data for the RK3588 includes both rk3588-base.dtsi and rk3588-extra.dtsi, because it's an unrestricted SoC variant, while the DT data for the RK3588S variant includes rk3588-base.dtsi only, because it's a restricted SoC variant, feature- and interface-wise. This achieves a more logical naming of the RK3588 SoC dtsi files, which reflects the way DT data for the SoC variants is built by "stacking" the SoC variant features made available through the "-base" and "-extra" SoC dtsi files. Additionally, the SoC variant dtsi files (rk3588.dtsi, rk3588j.dtsi and rk3588s.dtsi) are no longer parents to any other SoC variant dtsi files, which should help with making the new "stacking" approach cleaner and easier to follow. The RK3588 pinctrl dtsi files are also renamed in the same way, for the sake of consistency. This also keeps the "-base" and "-extra" groups of the dtsi files together when looked at in a directory listing, which is helpful. The per-SoC-variant OPPs should go directly into the SoC dtsi files, if no more than one SoC variant uses those OPPs, or be put into a separate "-opp" dtsi file that's shared between and included from two or more SoC variant dtsi files. An example for the former is the non-shared OPP data that should go directly into the RK3588J SoC variant dtsi file (i.e. rk3588j.dtsi), and an example for the latter is the shared OPP data that should be put into rk3588-opp.dtsi and be included from the RK3588 and RK3588S SoC variant dtsi files (i.e. rk3588.dtsi and rk3588s.dtsi, respectively). Consequently, if the OPPs for the RK3588 and RK3588S SoC variants are ever made different, the shared rk3588-opp.dtsi file should be deleted and the new OPPs should be put directly into rk3588.dtsi and rk3588s.dtsi. [4] No functional changes are introduced, which was validated by decompiling and comparing all affected dtb files before and after these changes. As a side note, due to the nature of introduced changes, this commit is best viewed using the --break-rewrites option for git-log(1). [1] https://lore.kernel.org/linux-rockchip/646a33e0-5c1b-471c-8183-2c0df40ea51a@cherry.de/ [2] https://lore.kernel.org/linux-rockchip/CABjd4Yxi=+3gkNnH3BysUzzYsji-=-yROtzEc8jM_g0roKB0-w@mail.gmail.com/ [3] https://lore.kernel.org/linux-rockchip/035a274be262528012173d463e25b55f@manjaro.org/ [4] https://lore.kernel.org/linux-rockchip/673dcf47596e7bc8ba065034e339bb1bbf9cdcb0.1716948159.git.dsimic@manjaro.org/T/#u Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/9ffedc0e2ca7f167d9d795b2a8f43cb9f56a653b.1717923308.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: Add FriendlyElec CM3588 NAS boardSebastian Kropatsch3-0/+1432
The CM3588 NAS by FriendlyElec pairs the CM3588 compute module, based on the Rockchip RK3588 SoC, with the CM3588 NAS Kit carrier board. To reflect the hardware setup, add device tree sources for the SoM and the NAS daughter board as separate files. Hardware features: - Rockchip RK3588 SoC - 4GB/8GB/16GB LPDDR4x RAM - 64GB eMMC - MicroSD card slot - 1x RTL8125B 2.5G Ethernet - 4x M.2 M-Key with PCIe 3.0 x1 (via bifurcation) for NVMe SSDs - 2x USB 3.0 (USB 3.1 Gen1) Type-A, 1x USB 2.0 Type-A - 1x USB 3.0 Type-C with DP AltMode support - 2x HDMI 2.1 out, 1x HDMI in - MIPI-CSI Connector, MIPI-DSI Connector - 40-pin GPIO header - 4 buttons: power, reset, recovery, MASK, user button - 3.5mm Headphone out, 2.0mm PH-2A Mic in - 5V Fan connector, PWM beeper, IR receiver, RTC battery connector PCIe bifurcation is used to handle all four M.2 sockets at PCIe 3.0 x1 speed. Data lane mapping in the DT is done like described in commit f8020dfb311d ("phy: rockchip-snps-pcie3: fix bifurcation on rk3588"). This device tree includes support for eMMC, SD card, ethernet, all USB2 and USB3 ports, all four M.2 slots, GPU, beeper, IR, RTC, UART debugging as well as the buttons and LEDs. The GPIOs are labeled according to the schematics. Reviewed-by: Space Meyer <git@the-space.agency> Signed-off-by: Sebastian Kropatsch <seb-dev@mail.de> Link: https://lore.kernel.org/r/20240616215354.40999-3-seb-dev@mail.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-05-28arm64: dts: rockchip: add rfkill node for M.2 Key E Bluetooth on Rock 5BAlexey Charkov1-0/+7
By default the BT WAKE signal inside the M.2 key E connector on Radxa Rock 5B is driven low, which results in the Bluetooth function being disabled even if the inserted M.2 card supports it. Expose this signal as an RFKILL device so that it can be enabled by the userspace. Tested with an Intel AX210 card, which connects a Bluetooth device over the USB 2.0 bus. Signed-off-by: Alexey Charkov <alchark@gmail.com> Link: https://lore.kernel.org/r/20240517122509.4626-1-alchark@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-05-28arm64: dts: rockchip: Add Radxa ROCK S0Jonas Karlman2-0/+294
Radxa ROCK S0 is a single-board computer based on the Rockchip RK3308B SoC in an ultra-compact form factor. Add initial support for eMMC, SD-card, Ethernet, WiFi/BT and USB. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20240521212247.1240226-3-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-05-28arm64: dts: rockchip: Update WIFi/BT related nodes on rk3308-rock-pi-sJonas Karlman1-4/+36
Update WiFi SDIO and BT UART related props to better reflect details about the optional onboard RTL8723DS WiFi/BT module. Also correct the compatible used for bluetooth to match the WiFi/BT module used on the board. Fixes: bc3753aed81f ("arm64: dts: rockchip: rock-pi-s add more peripherals") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20240521211029.1236094-14-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-05-28arm64: dts: rockchip: Add io-domains to rk3308-rock-pi-sJonas Karlman1-0/+10
The VCCIO4 io-domain used for WiFi/BT is using 1v8 IO signal voltage. Add io-domains node with the VCCIO supplies connected on the board. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20240521211029.1236094-13-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-05-28arm64: dts: rockchip: Add rk3308 IO voltage domainsJonas Karlman1-0/+5
Add a disabled RK3308 IO voltage domains node to SoC DT. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20240521211029.1236094-12-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-05-28arm64: dts: rockchip: Add OTP device node for RK3308Jonas Karlman1-0/+24
The RK3308 SoC contains a controller for one-time-programmable memory, add a device node for it. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20240521211029.1236094-9-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-05-28arm64: dts: rockchip: Add mdio and ethernet-phy nodes to rk3308-rock-pi-sJonas Karlman1-3/+23
Be explicit about the Ethernet port and define mdio and ethernet-phy nodes in the device tree for ROCK Pi S. Fixes: bc3753aed81f ("arm64: dts: rockchip: rock-pi-s add more peripherals") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20240521211029.1236094-8-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-05-28arm64: dts: rockchip: Add pinctrl for UART0 to rk3308-rock-pi-sJonas Karlman1-0/+2
UAR0 CTS/RTS is not wired to any pin and is not used for the default serial console use of UART0 on ROCK Pi S. Override the SoC defined pinctrl props to limit configuration of the two xfer pins wired to one of the GPIO pin headers. Fixes: 2e04c25b1320 ("arm64: dts: rockchip: add ROCK Pi S DTS support") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20240521211029.1236094-6-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Powered by cgit, Gruvboxed by Blaster4385.