summaryrefslogtreecommitdiff
path: root/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
AgeCommit message (Collapse)Author
2024-09-30arm64: dts: rockchip: Split up RK3588's PCIe pinctrlsSam Edwards
These pinctrls manage the low-speed PCIe signals: - CLKREQ#: An output on the RK3588 (both RC or EP modes), used to request that external clock-generation circuitry provide a clock. - PERST#: An input on the RK3588 in EP mode, used to detect a reset signal from the RC. In RC mode, the hardware does not use this signal: Linux itself generates it by putting the pin in GPIO mode. - WAKE#: In EP mode, this is an output; in RC mode, this is an input. Each of these signals serves a distinct purpose, and more importantly, PERST# should not be muxed when the RK3588 is in the RC role. Bundling them together in pinctrl groups prevents proper use: indeed, almost none of the current board-specific .dts files make any use of them. (Exception: Rock 5A recently had a patch land that misuses _pins; this patch corrects that.) However, on some RK3588 boards, the PCIe 3 controller will indefinitely stall the boot if CLKREQ# is not muxed (details in the next patch). This patch unbundles the signals to allow them to be used. Signed-off-by: Sam Edwards <CFSworks@gmail.com> Link: https://lore.kernel.org/r/20240912025034.180233-2-CFSworks@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-09-04arm64: dts: rockchip: rk3588s fix sdio pins to pull upAlex Zhao
The sdio requires the cmd and data pins to pull up by soc. Signed-off-by: Alex Zhao <zzc@rock-chips.com> [adapted to pinctrl filename change] Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20240829204517.398669-2-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-24arm64: dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPsDragan Simic
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>