| Message ID | 20221018151407.63395-1-sebastian.reichel@collabora.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | RK3588 Clock and Reset Support | expand |
Hi, On Tue, Oct 18, 2022 at 05:13:58PM +0200, Sebastian Reichel wrote: > Hi, > > This has been part of a bigger patchset adding basic rk3588 support. > Since that gets more and more out of hand, I'm now sending patches > for each subsystem as individual patchset. > > Changes since PATCHv2: > * https://lore.kernel.org/all/20220930153857.299396-1-sebastian.reichel@collabora.com/ > * rebased to v6.1-rc1 > * define rk3588_rst_init() in clk.h to fix build warning > * add input clocks to the binding > * add some more rates from the rate table (merged downstream fix) > * fix input of mux_700m_400m_200m_24m_p clock (merged downstream fix) > > Changes since PATCHv1: > * https://lore.kernel.org/all/20220623160329.239501-1-sebastian.reichel@collabora.com/ > * split dt-binding header addition into its own patch (requested by Heiko) > * split dt-binding header into clock and reset one (requested by Krzysztof) > * use reset identifier instead of register offset (requested by Krzysztof) > * (involves adding lookup table support to rockchip CRU reset code) > * use linear, gapless clock identifier (requested by Krzysztof) > * reword the DT binding description > > Changes since PATCHv0: > * https://lore.kernel.org/all/20220504213251.264819-1-sebastian.reichel@collabora.com/ > * Sync'd with latest downstream changes > * Update bindings according to Rob's comments, except for license > (no feedback from Rockchip) > > -- Sebastian > > Elaine Zhang (5): > dt-bindings: clock: add rk3588 cru bindings > clk: rockchip: add register offset of the cores select parent > clk: rockchip: add pll type for RK3588 > clk: rockchip: clk-cpu: add mux setting for cpu change frequency > clk: rockchip: add clock controller for the RK3588 > > Sebastian Reichel (4): > dt-bindings: clock: add rk3588 clock definitions > dt-bindings: reset: add rk3588 reset definitions > clk: rockchip: simplify rockchip_clk_add_lookup > clk: rockchip: add lookup table support > > .../bindings/clock/rockchip,rk3588-cru.yaml | 71 + > drivers/clk/rockchip/Kconfig | 8 + > drivers/clk/rockchip/Makefile | 1 + > drivers/clk/rockchip/clk-cpu.c | 69 +- > drivers/clk/rockchip/clk-pll.c | 218 +- > drivers/clk/rockchip/clk-rk3588.c | 2538 +++++++++++++++++ > drivers/clk/rockchip/clk.c | 14 +- > drivers/clk/rockchip/clk.h | 95 +- > drivers/clk/rockchip/rst-rk3588.c | 857 ++++++ > drivers/clk/rockchip/softrst.c | 34 +- > .../dt-bindings/clock/rockchip,rk3588-cru.h | 766 +++++ > .../dt-bindings/reset/rockchip,rk3588-cru.h | 754 +++++ > 12 files changed, 5390 insertions(+), 35 deletions(-) > create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3588-cru.yaml > create mode 100644 drivers/clk/rockchip/clk-rk3588.c > create mode 100644 drivers/clk/rockchip/rst-rk3588.c > create mode 100644 include/dt-bindings/clock/rockchip,rk3588-cru.h > create mode 100644 include/dt-bindings/reset/rockchip,rk3588-cru.h Can this be merged? It's the last blocker for basic rk3588 support. -- Sebastian
On Tue, 18 Oct 2022 17:13:58 +0200, Sebastian Reichel wrote: > This has been part of a bigger patchset adding basic rk3588 support. > Since that gets more and more out of hand, I'm now sending patches > for each subsystem as individual patchset. > > Changes since PATCHv2: > * https://lore.kernel.org/all/20220930153857.299396-1-sebastian.reichel@collabora.com/ > * rebased to v6.1-rc1 > * define rk3588_rst_init() in clk.h to fix build warning > * add input clocks to the binding > * add some more rates from the rate table (merged downstream fix) > * fix input of mux_700m_400m_200m_24m_p clock (merged downstream fix) > > [...] Applied, thanks! [1/9] dt-bindings: clock: add rk3588 clock definitions commit: f204a60e545ccd4bc28939054389690fd194cb5e [2/9] dt-bindings: reset: add rk3588 reset definitions commit: 0a8eb7dae617a9537b9a64a6b14e63415c279eb5 [3/9] dt-bindings: clock: add rk3588 cru bindings commit: 4f5ca304f202938a07eb0c2e20551795286d817d [4/9] clk: rockchip: add register offset of the cores select parent commit: cf87691f143e6cc5727767b02ec2be3725534a5d [5/9] clk: rockchip: add pll type for RK3588 commit: 8f6594494b1cb0ad14493795b436413cfe64a0f8 [6/9] clk: rockchip: clk-cpu: add mux setting for cpu change frequency commit: 2004b7b1803719eaaaee5fa6b089b1699a65d31d [7/9] clk: rockchip: simplify rockchip_clk_add_lookup commit: ff94c8660dac444081f2f650fae36a283c55b117 [8/9] clk: rockchip: add lookup table support commit: ada8f95ba04e8fe07289b7de157ae99bb96bc8cb [9/9] clk: rockchip: add clock controller for the RK3588 commit: f1c506d152ff235ad621d3c25d061cb16da67214 Best regards,
On 2022/10/18 23:13, Sebastian Reichel wrote: > Hi, > > This has been part of a bigger patchset adding basic rk3588 support. > Since that gets more and more out of hand, I'm now sending patches > for each subsystem as individual patchset. Awesome work! Thanks for the work to bring upstream support for RK3588. This upstream work is especially important since the vendor kernel has so many weird things and is never properly tested using newer tool chains. But considering the support has been split into different patchset, is there a git repo that I can fetch all the patches and test it on my Rock5B board? Thanks, Qu > > Changes since PATCHv2: > * https://lore.kernel.org/all/20220930153857.299396-1-sebastian.reichel@collabora.com/ > * rebased to v6.1-rc1 > * define rk3588_rst_init() in clk.h to fix build warning > * add input clocks to the binding > * add some more rates from the rate table (merged downstream fix) > * fix input of mux_700m_400m_200m_24m_p clock (merged downstream fix) > > Changes since PATCHv1: > * https://lore.kernel.org/all/20220623160329.239501-1-sebastian.reichel@collabora.com/ > * split dt-binding header addition into its own patch (requested by Heiko) > * split dt-binding header into clock and reset one (requested by Krzysztof) > * use reset identifier instead of register offset (requested by Krzysztof) > * (involves adding lookup table support to rockchip CRU reset code) > * use linear, gapless clock identifier (requested by Krzysztof) > * reword the DT binding description > > Changes since PATCHv0: > * https://lore.kernel.org/all/20220504213251.264819-1-sebastian.reichel@collabora.com/ > * Sync'd with latest downstream changes > * Update bindings according to Rob's comments, except for license > (no feedback from Rockchip) > > -- Sebastian > > Elaine Zhang (5): > dt-bindings: clock: add rk3588 cru bindings > clk: rockchip: add register offset of the cores select parent > clk: rockchip: add pll type for RK3588 > clk: rockchip: clk-cpu: add mux setting for cpu change frequency > clk: rockchip: add clock controller for the RK3588 > > Sebastian Reichel (4): > dt-bindings: clock: add rk3588 clock definitions > dt-bindings: reset: add rk3588 reset definitions > clk: rockchip: simplify rockchip_clk_add_lookup > clk: rockchip: add lookup table support > > .../bindings/clock/rockchip,rk3588-cru.yaml | 71 + > drivers/clk/rockchip/Kconfig | 8 + > drivers/clk/rockchip/Makefile | 1 + > drivers/clk/rockchip/clk-cpu.c | 69 +- > drivers/clk/rockchip/clk-pll.c | 218 +- > drivers/clk/rockchip/clk-rk3588.c | 2538 +++++++++++++++++ > drivers/clk/rockchip/clk.c | 14 +- > drivers/clk/rockchip/clk.h | 95 +- > drivers/clk/rockchip/rst-rk3588.c | 857 ++++++ > drivers/clk/rockchip/softrst.c | 34 +- > .../dt-bindings/clock/rockchip,rk3588-cru.h | 766 +++++ > .../dt-bindings/reset/rockchip,rk3588-cru.h | 754 +++++ > 12 files changed, 5390 insertions(+), 35 deletions(-) > create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3588-cru.yaml > create mode 100644 drivers/clk/rockchip/clk-rk3588.c > create mode 100644 drivers/clk/rockchip/rst-rk3588.c > create mode 100644 include/dt-bindings/clock/rockchip,rk3588-cru.h > create mode 100644 include/dt-bindings/reset/rockchip,rk3588-cru.h >
Hi Qu, On Mon, Nov 21, 2022 at 04:52:22PM +0800, Qu Wenruo wrote: > On 2022/10/18 23:13, Sebastian Reichel wrote: > > This has been part of a bigger patchset adding basic rk3588 support. > > Since that gets more and more out of hand, I'm now sending patches > > for each subsystem as individual patchset. > > Awesome work! Thanks for the work to bring upstream support for RK3588. > > This upstream work is especially important since the vendor kernel has so > many weird things and is never properly tested using newer tool chains. > > But considering the support has been split into different patchset, is there > a git repo that I can fetch all the patches and test it on my Rock5B board? try linux-next + https://lore.kernel.org/all/20221121175814.68927-1-sebastian.reichel@collabora.com/ It should boot, but that's about it. For Rock 5B there is not even ethernet support, since that needs PCIe. Ideally the DT series makes it in time for the 6.2 merge window. Alternatively my working branch (I rebase that!) is available here: https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-misc.git/log/?h=rk3588 It adds PMIC, thermal and cpufrequency support. -- Sebastian
On 2022/11/22 02:28, Sebastian Reichel wrote: > Hi Qu, > > On Mon, Nov 21, 2022 at 04:52:22PM +0800, Qu Wenruo wrote: >> On 2022/10/18 23:13, Sebastian Reichel wrote: >>> This has been part of a bigger patchset adding basic rk3588 support. >>> Since that gets more and more out of hand, I'm now sending patches >>> for each subsystem as individual patchset. >> >> Awesome work! Thanks for the work to bring upstream support for RK3588. >> >> This upstream work is especially important since the vendor kernel has so >> many weird things and is never properly tested using newer tool chains. >> >> But considering the support has been split into different patchset, is there >> a git repo that I can fetch all the patches and test it on my Rock5B board? > > try linux-next + https://lore.kernel.org/all/20221121175814.68927-1-sebastian.reichel@collabora.com/ > > It should boot, but that's about it. For Rock 5B there is not even > ethernet support, since that needs PCIe. Ideally the DT series makes > it in time for the 6.2 merge window. > > Alternatively my working branch (I rebase that!) is available here: > https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-misc.git/log/?h=rk3588 > It adds PMIC, thermal and cpufrequency support. Sorry for the late reply, finally got my extra rock5b to do experiments. (The existing one is now a VM host for 24x7 fstests runs) [TEST REPORT] Yes, I got the expected-to-work parts working: - ttyS2 (serial@feb50000) Both earlycon and later initialized console. - eMMC (mmc@fe2e0000) The rootfs read write seems fine. The latest code seems to have sdmmc, but ironically I don't have any sdcard at hand right now... [PCIE ENABLEMENT] Personally speaking, I can not care less about things like GMAC (Rock5B uses r8125), nor USB (PCIE rules them all) nor graphics (serial is good neough). Thus I'm trying to see if I can re-use the rk3568 pcie drivers. It looks like unlike RK3399, this time we need PHY for PCIE, and it is already done in rk3568 pcie controller, and the core AIX->PCIE is done by the designware core, thus it looks feasible to reuse the driver? But I can be totally wrong, since I'm really just a newbie in arm world. Any hint on the PCIE bus bringup? Or what I can help for the PCIE bringup? I know RK3588S seems to cut the PCIE3 lanes completely, and droped one PCIE2.0 lane, but I don't know the address for the cut one... [VENDOR KERNEL PCIE BUG] Another thing I noticed with vendor (5.10.x) kernel is, the PCIE link up is unreliable, causing random reset. Maybe the incoming upstream bring up can fix it? Thanks, Qu > > -- Sebastian
On 2023/2/2 14:10, Qu Wenruo wrote: > > > On 2022/11/22 02:28, Sebastian Reichel wrote: >> Hi Qu, >> >> On Mon, Nov 21, 2022 at 04:52:22PM +0800, Qu Wenruo wrote: >>> On 2022/10/18 23:13, Sebastian Reichel wrote: >>>> This has been part of a bigger patchset adding basic rk3588 support. >>>> Since that gets more and more out of hand, I'm now sending patches >>>> for each subsystem as individual patchset. >>> >>> Awesome work! Thanks for the work to bring upstream support for RK3588. >>> >>> This upstream work is especially important since the vendor kernel >>> has so >>> many weird things and is never properly tested using newer tool chains. >>> >>> But considering the support has been split into different patchset, >>> is there >>> a git repo that I can fetch all the patches and test it on my Rock5B >>> board? >> >> try linux-next + >> https://lore.kernel.org/all/20221121175814.68927-1-sebastian.reichel@collabora.com/ >> >> It should boot, but that's about it. For Rock 5B there is not even >> ethernet support, since that needs PCIe. Ideally the DT series makes >> it in time for the 6.2 merge window. >> >> Alternatively my working branch (I rebase that!) is available here: >> https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-misc.git/log/?h=rk3588 >> It adds PMIC, thermal and cpufrequency support. > > Sorry for the late reply, finally got my extra rock5b to do experiments. > (The existing one is now a VM host for 24x7 fstests runs) > > [TEST REPORT] > Yes, I got the expected-to-work parts working: > > - ttyS2 (serial@feb50000) > Both earlycon and later initialized console. > > - eMMC (mmc@fe2e0000) > The rootfs read write seems fine. > > The latest code seems to have sdmmc, but ironically I don't have > any sdcard at hand right now... > > [PCIE ENABLEMENT] > Personally speaking, I can not care less about things like GMAC (Rock5B > uses r8125), nor USB (PCIE rules them all) nor graphics (serial is good > neough). > > Thus I'm trying to see if I can re-use the rk3568 pcie drivers. It looks like the current code (in the repo) still lacks the dt-bindings for the resets. Like SRST_PCIE*_POWER_UP and SRST_P_PCIE*. Otherwise a quick glance into the vendor driver doesn't show much difference in the 3568 and 3588 pcie driver. (Except the extra bifurcation part, which is not utilized by any RK3588 boards yet) Thanks, Qu > > It looks like unlike RK3399, this time we need PHY for PCIE, and it is > already done in rk3568 pcie controller, and the core AIX->PCIE is done > by the designware core, thus it looks feasible to reuse the driver? > > But I can be totally wrong, since I'm really just a newbie in arm world. > > Any hint on the PCIE bus bringup? Or what I can help for the PCIE bringup? > > I know RK3588S seems to cut the PCIE3 lanes completely, and droped one > PCIE2.0 lane, but I don't know the address for the cut one... > > [VENDOR KERNEL PCIE BUG] > Another thing I noticed with vendor (5.10.x) kernel is, the PCIE link up > is unreliable, causing random reset. > Maybe the incoming upstream bring up can fix it? > > Thanks, > Qu > >> >> -- Sebastian