- 28 Jun, 2024 6 commits
-
-
Dragan Simic authored
The commit 587b4ee2 ("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-bootingSigned-off-by:
Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/4449f7d4eead787308300e2d1d37b88c9d1446b2.1717308862.git.dsimic@manjaro.orgSigned-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Cristian Ciocaltea authored
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: 3e4c629c ("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.comSigned-off-by:
-
Cristian Ciocaltea authored
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: a8e35c4b ("arm64: dts: rockchip: add audio nodes to rk3566-roc-pc") Signed-off-by:
-
Cristian Ciocaltea authored
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: 22a442e6 ("arm64: dts: rockchip: add basic dts for the radxa rock3 model a") Reported-by:
Jonas Karlman <jonas@kwiboo.se> Signed-off-by:
-
Niklas Cassel authored
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.orgSigned-off-by:
-
Niklas Cassel authored
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:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20240607-rockchip-pcie-ep-v1-v5-12-0a042d6b0049@kernel.orgSigned-off-by:
-
- 24 Jun, 2024 24 commits
-
-
Jonas Karlman authored
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: 52e02d37 ("arm64: dts: rockchip: add core dtsi file for RK3328 SoCs") Signed-off-by:
-
Trevor Woerner authored
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.txtSigned-off-by:
Trevor Woerner <twoerner@gmail.com> Link: https://lore.kernel.org/r/20240620013301.33653-1-twoerner@gmail.comSigned-off-by:
-
Alexey Charkov authored
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: 6fca4edb ("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.comSigned-off-by:
-
Alexey Charkov authored
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.dtsiSigned-off-by:
-
Alexey Charkov authored
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-bootSigned-off-by:
-
Alexey Charkov authored
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:
-
FUKAUMI Naoki authored
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: 1a5c8d30 ("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.comSigned-off-by:
-
Alex Bee authored
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.comSigned-off-by:
-
Alex Bee authored
Add Neardi LBA3368, a RK3368 based industrial board. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240623090116.670607-3-knaerzche@gmail.comSigned-off-by:
-
Alex Bee authored
Add vendor prefix for Shanghai Neardi Technology Co., Ltd. (http://neardi.com/) Signed-off-by:
-
Peter Robinson authored
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.comSigned-off-by:
-
Peter Robinson authored
Enable the IMU sensor on the PinePhone Pro including the i2c4 bus that it's attached to. Signed-off-by:
-
Peter Robinson authored
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 authored
The PinePhone Pro as SPI flash on board so enable the SPI interface and the flash. Signed-off-by:
-
FUKAUMI Naoki authored
SPI NOR flash chip may vary, so use safe(lowest) spi-max-frequency. Signed-off-by:
-
FUKAUMI Naoki authored
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 authored
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:
-
Alexey Charkov authored
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:
-
Alexey Charkov authored
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 authored
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 authored
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:
-
Dragan Simic authored
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/#uSigned-off-by:
-
Sebastian Kropatsch authored
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 f8020dfb ("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.deSigned-off-by:
-
Sebastian Kropatsch authored
Add devicetree bindings for the FriendlyElec CM3588 NAS board. The CM3588 NAS by FriendlyElec pairs the CM3588 compute module, based on the Rockchip RK3588 SoC, with the CM3588 NAS Kit carrier board. Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
- 28 May, 2024 1 commit
-
-
Alexey Charkov authored
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:
-
- 27 May, 2024 9 commits
-
-
Jonas Karlman authored
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 authored
Add devicetree binding for the Radxa ROCK S0 board. Radxa ROCK S0 is a single-board computer based on the Rockchip RK3308B SoC in an ultra-compact form factor. Signed-off-by:
-
Jonas Karlman authored
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: bc3753ae ("arm64: dts: rockchip: rock-pi-s add more peripherals") Signed-off-by:
-
Jonas Karlman authored
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 authored
Add a disabled RK3308 IO voltage domains node to SoC DT. Signed-off-by:
-
Jonas Karlman authored
The RK3308 SoC contains a controller for one-time-programmable memory, add a device node for it. Signed-off-by:
-
Jonas Karlman authored
Be explicit about the Ethernet port and define mdio and ethernet-phy nodes in the device tree for ROCK Pi S. Fixes: bc3753ae ("arm64: dts: rockchip: rock-pi-s add more peripherals") Signed-off-by:
-
Jonas Karlman authored
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: 2e04c25b ("arm64: dts: rockchip: add ROCK Pi S DTS support") Signed-off-by:
-
Jonas Karlman authored
Add cap-mmc-highspeed to allow use of high speed MMC mode using an eMMC to uSD board. Use disable-wp to signal that no physical write-protect line is present. Also add vcc_io used for card and IO line power as vmmc-supply. Fixes: 2e04c25b ("arm64: dts: rockchip: add ROCK Pi S DTS support") Signed-off-by:
-
