Basic StarFive JH7100 RISC-V SoC support for 5.17
The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf:
Linux 5.16-rc1 (2021-11-14 13:56:52 -0800)
are available in the Git repository at:
https://github.com/esmil/linux.git tags/for-soc
for you to fetch changes up to 398d6e139782d1ce2c9822beb8effba0c9c51cc4:
RISC-V: Add BeagleV Starlight Beta device tree (2021-11-28 20:07:09 +0100)
----------------------------------------------------------------
Changes since v4:
- The reset driver now always uses 64bit read/write on registers even on 32bit architectures as requested by Andy.
Changes since v3:
- The reset driver now uses 64bit read/write on the registers so we can use the regular bitmap macros. Requested by Andy.
- The pinctrl driver no longer resets the GPIO irq handler to handle_bad_irq on errors, uses reverse xmas tree order where possible and other nits by Andy.
Changes since v2:
- Ahmad and Geert agreed to switch the license of the clock and reset dt headers to GPL-2.0 OR MIT, so that both headers and device tree files can all use the same license.
Bindings are still GPL-2.0-only OR BSD-2-Clause as recommended.
- Clock and reset drivers now set .suppress_bind_attrs = true and use builtin_platform_driver_probe to make sure the probe function is only called at init time so we can use __init and __initconst.
- The clock driver now uses devm_clk_hw_register and .parent_data when registering clocks. This way we can use the dt clock indexes rather than strings for parent lists and decrease the amount of static data needed considerably.
- Various dt binding cleanups from Rob
- Reworked description in the pinctrl dt binding.
- Pinctrl driver now depends on CONFIG_OF again since it uses pinconf_generic_parse_dt_config which is otherwise not defined.
- Pinctrl no longer devm_kfree's data that won't be referenced if dt pinconf parsing fails before registering groups and function, and other nits by Andy.
- The dw8250 quirk no longer needs a skip_clk_set_rate bit, but sets port->set_termios to the function called after clk_set_rate.
Changes since v1:
- Let SOC_STARFIVE select RESET_CONTROLLER but drop SERIAL_8250_DW
- Add missing Signed-of-by to clock dt-binding header
- Use builtin_platform_driver macro for the clock driver, add explicit comment to the determine_rate callback and other small nits from Andy
- Use reset-controller for node names in documentation and device tree
- Use readl_poll_timeout in reset driver to avoid hanging forever if a driver leaves the associated clock gated and sort Kconfig and Makefile entries properly.
- In the pinctrl driver align register names with documentation, remove invalid __init tag from probe function, use of_property_* functions to parse device tree, hoist pinmux unpacking into helper function to better document what's going on, bail on invalid signal group in device tree and fix many other nits from Andy.
- Refactor and rebase 8250_dw quirk on tty-next
----------------------------------------------------------------
Emil Renner Berthing (12):
RISC-V: Add StarFive SoC Kconfig option
dt-bindings: timer: Add StarFive JH7100 clint
dt-bindings: interrupt-controller: Add StarFive JH7100 plic
dt-bindings: reset: Add Starfive JH7100 reset bindings
reset: starfive-jh7100: Add StarFive JH7100 reset driver
dt-bindings: pinctrl: Add StarFive pinctrl definitions
dt-bindings: pinctrl: Add StarFive JH7100 bindings
pinctrl: starfive: Add pinctrl driver for StarFive SoCs
dt-bindings: serial: snps-dw-apb-uart: Add JH7100 uarts
serial: 8250_dw: Add StarFive JH7100 quirk
RISC-V: Add initial StarFive JH7100 device tree
RISC-V: Add BeagleV Starlight Beta device tree
Geert Uytterhoeven (4):
dt-bindings: clock: starfive: Add JH7100 clock definitions
dt-bindings: clock: starfive: Add JH7100 bindings
clk: starfive: Add JH7100 clock generator driver
dt-bindings: reset: Add StarFive JH7100 reset definitions
.../bindings/clock/starfive,jh7100-clkgen.yaml | 56 + .../interrupt-controller/sifive,plic-1.0.0.yaml | 1 + .../bindings/pinctrl/starfive,jh7100-pinctrl.yaml | 307 +++++ .../bindings/reset/starfive,jh7100-reset.yaml | 38 + .../bindings/serial/snps-dw-apb-uart.yaml | 5 + .../devicetree/bindings/timer/sifive,clint.yaml | 1 + MAINTAINERS | 22 + arch/riscv/Kconfig.socs | 8 + arch/riscv/boot/dts/Makefile | 1 + arch/riscv/boot/dts/starfive/Makefile | 2 + .../boot/dts/starfive/jh7100-beaglev-starlight.dts | 164 +++ arch/riscv/boot/dts/starfive/jh7100.dtsi | 230 ++++ drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 1 + drivers/clk/starfive/Kconfig | 9 + drivers/clk/starfive/Makefile | 3 + drivers/clk/starfive/clk-starfive-jh7100.c | 689 ++++++++++ drivers/pinctrl/Kconfig | 17 + drivers/pinctrl/Makefile | 1 + drivers/pinctrl/pinctrl-starfive.c | 1354 ++++++++++++++++++++ drivers/reset/Kconfig | 7 + drivers/reset/Makefile | 1 + drivers/reset/reset-starfive-jh7100.c | 172 +++ drivers/tty/serial/8250/8250_dw.c | 3 + include/dt-bindings/clock/starfive-jh7100.h | 202 +++ include/dt-bindings/pinctrl/pinctrl-starfive.h | 275 ++++ include/dt-bindings/reset/starfive-jh7100.h | 126 ++ 27 files changed, 3696 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/starfive,jh7100-clkgen.yaml create mode 100644 Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml create mode 100644 Documentation/devicetree/bindings/reset/starfive,jh7100-reset.yaml create mode 100644 arch/riscv/boot/dts/starfive/Makefile create mode 100644 arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dts create mode 100644 arch/riscv/boot/dts/starfive/jh7100.dtsi create mode 100644 drivers/clk/starfive/Kconfig create mode 100644 drivers/clk/starfive/Makefile create mode 100644 drivers/clk/starfive/clk-starfive-jh7100.c create mode 100644 drivers/pinctrl/pinctrl-starfive.c create mode 100644 drivers/reset/reset-starfive-jh7100.c create mode 100644 include/dt-bindings/clock/starfive-jh7100.h create mode 100644 include/dt-bindings/pinctrl/pinctrl-starfive.h create mode 100644 include/dt-bindings/reset/starfive-jh7100.h
Quoted 5 lines · Emil Renner Berthing
The following changes since commit
fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf:Linux 5.16-rc1 (2021-11-14 13:56:52 -0800)
Quoted 8 lines
are available in the Git repository at:
https://github.com/esmil/linux.git tags/for-soc
for you to fetch changes up to
398d6e139782d1ce2c9822beb8effba0c9c51cc4:RISC-V: Add BeagleV Starlight Beta device tree (2021-11-28 20:07:09 +0100)
Hi Emil,
I just got through my backlog of pull request and got to yours. All of the contents look
fine but I noticed that there is no tag description. Please sign the tag with a gpg
key and add a description that explains the contents of the branch in your own words, the same way you write the introductory mail of a patch series. This will become the description of the merge commit.
Arnd
Hi Arnd,
Quoted 17 lines · Arnd Bergmann
Quoted 5 lines · Emil Renner Berthing
The following changes since commit
fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf:Linux 5.16-rc1 (2021-11-14 13:56:52 -0800)
Quoted 8 lines
are available in the Git repository at:
https://github.com/esmil/linux.git tags/for-soc
for you to fetch changes up to
398d6e139782d1ce2c9822beb8effba0c9c51cc4:RISC-V: Add BeagleV Starlight Beta device tree (2021-11-28 20:07:09 +0100)
Hi Emil,
Quoted 7 lines
I just got through my backlog of pull request and got to yours. All of the contents look
fine but I noticed that there is no tag description. Please sign the tag with a gpg
key and add a description that explains the contents of the branch in your own words, the same way you write the introductory mail of a patch series. This will become the description of the merge commit.
Ah, gotcha. The thing is that I don't actually have a gpg key at the moment. I can generate one and use that to sign it, but then it won't be part of the web of trust.
Alternatively I can just send it as a series of patches with a cover letter like I did before. That would be a little easier for me, but what do you prefer?
/Emil
Quoted 10 lines · Emil Renner Berthing
Quoted 8 lines · Arnd Bergmann
On Sun, Nov 28, 2021 at 9:06 PM Emil Renner Berthing <[email protected]> wrote:
I just got through my backlog of pull request and got to yours. All of the contents look
fine but I noticed that there is no tag description. Please sign the tag with a gpg
key and add a description that explains the contents of the branch in your own words, the same way you write the introductory mail of a patch series. This will become the description of the merge commit.
Quoted 6 lines
Ah, gotcha. The thing is that I don't actually have a gpg key at the moment. I can generate one and use that to sign it, but then it won't be part of the web of trust.
Alternatively I can just send it as a series of patches with a cover letter like I did before. That would be a little easier for me, but what do you prefer?
I'd prefer a pull request. The most important bit to me is actually the tag description, not the signature. I'll go through the contents once more anyway, which should be enough for me to merge it.
A signed tag is still better than one without a signature, that way at least your key is part of the git history and we can confirm that another pull request came was signed with the same key, even if we don't know who you are ;-)
When you create a new key, please follow the directions from
https://www.kernel.org/doc/Documentation/process/maintainer-pgp-guide.rst
andyway, so you can add it to the keyring after you have collected the signatures.
Arnd
Quoted 27 lines · Arnd Bergmann
Quoted 10 lines · Emil Renner Berthing
Quoted 8 lines · Arnd Bergmann
On Sun, Nov 28, 2021 at 9:06 PM Emil Renner Berthing <[email protected]> wrote:
I just got through my backlog of pull request and got to yours. All of the contents look
fine but I noticed that there is no tag description. Please sign the tag with a gpg
key and add a description that explains the contents of the branch in your own words, the same way you write the introductory mail of a patch series. This will become the description of the merge commit.Quoted 6 lines
Ah, gotcha. The thing is that I don't actually have a gpg key at the moment. I can generate one and use that to sign it, but then it won't be part of the web of trust.
Alternatively I can just send it as a series of patches with a cover letter like I did before. That would be a little easier for me, but what do you prefer?I'd prefer a pull request. The most important bit to me is actually the tag description, not the signature. I'll go through the contents once more anyway, which should be enough for me to merge it.
A signed tag is still better than one without a signature, that way at least your key is part of the git history and we can confirm that another pull request came was signed with the same key, even if we don't know who you are ;-)
Quoted 4 lines
When you create a new key, please follow the directions from
https://www.kernel.org/doc/Documentation/process/maintainer-pgp-guide.rst
andyway, so you can add it to the keyring after you have collected the signatures.
Nice, I'll try to follow that then. Thanks!
/Emil