reset: ti-rstctrl: use the reset-simple driver
Subsystems (2)
PATCH v2 1/1 reset: ti-rstctrl: use the reset-simple driver
We can support the RSTCTRL reset registers on many TI SoCs with reset-simple.
Note that some devices will also need to check the RSTST bits for reset reason. Support for these could be possibly added to the reset controller framework later on.
---
Changes since v1:
- Update patch description to mention the unhandled RSTST bits
- Rebase against Linux next
--- .../devicetree/bindings/reset/ti-rstctrl.txt | 20 ++++++++++++++++++++ drivers/reset/Kconfig | 3 ++- drivers/reset/reset-simple.c | 1 + 3 files changed, 23 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/reset/ti-rstctrl.txt
Documentation/devicetree/bindings/reset/ti-rstctrl.txt new file +20 -0
@@ -0,0 +1,20 @@ +TI RSTCTRL Reset Controller + +Required properties: +- compatible : "ti,rstctrl" +- reg : Should contain 1 register ranges(address and length) +- #reset-cells: 1 + +Example: + prm_gfx: prm@1100 { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x1100 0x100>; + + gfx_rstctrl: rstctrl@4 { + compatible = "ti,rstctrl"; + reg = <0x4 0x4>; + #reset-cells = <1>; + }; + };
drivers/reset/Kconfig +2 -1
@@ -84,7 +84,7 @@ config RESET_PISTACHIO config RESET_SIMPLE bool "Simple Reset Controller Driver" if COMPILE_TEST - default ARCH_SOCFPGA || ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI || ARCH_ZX || ARCH_ASPEED + default ARCH_OMAP2PLUS || ARCH_SOCFPGA || ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI || ARCH_ZX || ARCH_ASPEED help This enables a simple reset controller driver for reset lines that that can be asserted and deasserted by toggling bits in a contiguous,
@@ -95,6 +95,7 @@ config RESET_SIMPLE - ASPEED BMC SoCs - RCC reset controller in STM32 MCUs - Allwinner SoCs + - TI SoCs - ZTE's zx2967 family config RESET_SUNXI
drivers/reset/reset-simple.c +1 -0
@@ -123,6 +123,7 @@ static const struct of_device_id reset_simple_dt_ids[] = { { .compatible = "st,stm32-rcc", }, { .compatible = "allwinner,sun6i-a31-clock-reset", .data = &reset_simple_active_low }, + { .compatible = "ti,rstctrl", }, { .compatible = "zte,zx296718-reset", .data = &reset_simple_active_low }, { .compatible = "aspeed,ast2400-lpc-reset" },
Signature · 1 line
2.16.2
Rob Herring
maintainerQuoted 33 lines · Tony Lindgren
We can support the RSTCTRL reset registers on many TI SoCs with reset-simple.
Note that some devices will also need to check the RSTST bits for reset reason. Support for these could be possibly added to the reset controller framework later on.
Cc Dave Gerlach <[email protected]>Cc Mark Rutland <[email protected]>Cc Nishant Menon <[email protected]>Cc Philipp Zabel <[email protected]>Cc Rob Herring <[email protected]>Cc Suman Anna <[email protected]>Cc Tero Kristo <[email protected]>Signed-off-by Tony Lindgren <[email protected]>---
Changes since v1:
- Update patch description to mention the unhandled RSTST bits
- Rebase against Linux next--- .../devicetree/bindings/reset/ti-rstctrl.txt | 20 ++++++++++++++++++++ drivers/reset/Kconfig | 3 ++- drivers/reset/reset-simple.c | 1 + 3 files changed, 23 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/reset/ti-rstctrl.txtDocumentation/devicetree/bindings/reset/ti-rstctrl.txt new file +0
-0
Documentation/devicetree/bindings/reset/ti-rstctrl.txt line 10
Quoted 10 lines
Documentation/devicetree/bindings/reset/ti-rstctrl.txt new file +10
-0@@ -0,0 +1,20 @@ +TI RSTCTRL Reset Controller + +Required properties: +- compatible : "ti,rstctrl" +- reg : Should contain 1 register ranges(address and length) +- #reset-cells: 1 + +Example: + prm_gfx: prm@1100 { + compatible = "simple-bus";
What's a PRM?
Documentation/devicetree/bindings/reset/ti-rstctrl.txt line 13
Quoted 3 lines
Documentation/devicetree/bindings/reset/ti-rstctrl.txt new file +3
-0+ #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x1100 0x100>;
And what else is in this range?
Documentation/devicetree/bindings/reset/ti-rstctrl.txt line 17
Quoted 4 lines
Documentation/devicetree/bindings/reset/ti-rstctrl.txt new file +4
-0+ + gfx_rstctrl: rstctrl@4 { + compatible = "ti,rstctrl"; + reg = <0x4 0x4>;
Anytime I see a single register in DT I worry about scaling. How many of these in an SoC?
Quoted 3 lines
Documentation/devicetree/bindings/reset/ti-rstctrl.txt new file +3
-0+ #reset-cells = <1>; + }; + };
Hi,
Quoted 13 lines · Rob Herring
Documentation/devicetree/bindings/reset/ti-rstctrl.txt line 10
Quoted 10 lines · Tony Lindgren
Documentation/devicetree/bindings/reset/ti-rstctrl.txt new file +10
-0+TI RSTCTRL Reset Controller + +Required properties: +- compatible : "ti,rstctrl" +- reg : Should contain 1 register ranges(address and length) +- #reset-cells: 1 + +Example: + prm_gfx: prm@1100 { + compatible = "simple-bus";What's a PRM?
PRM is power and reset manager. There is one instance per interconnect instance (clockdomain). PRM shows the status of the connected devices in the interconnect, such as device context lost and hardware wake-up dependencies. It also contains a single reset controller register for external accelerators such as DSP. The reset controller instance then has 1 - 3 bits for external accelerator sub device resets. Then there is a reset status register that shows the reset reason for the external accelerator.
Quoted 5 lines
Documentation/devicetree/bindings/reset/ti-rstctrl.txt line 13
Quoted 3 lines
Documentation/devicetree/bindings/reset/ti-rstctrl.txt new file +3
-0+ #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x1100 0x100>;And what else is in this range?
In PRM, there are also registers for each interconnect device context lost and wake-up dependencies. We don't have a driver for that yet, it's handled by the SoC init code currently.
Unlike the binding for reset controller, the binding for wake-up dependencies and context lost should look similar binding to the clkctrl clock binding we have. That's because there are tons of those registers.
Quoted 7 lines
Documentation/devicetree/bindings/reset/ti-rstctrl.txt line 17
Quoted 4 lines
Documentation/devicetree/bindings/reset/ti-rstctrl.txt new file +4
-0+ + gfx_rstctrl: rstctrl@4 { + compatible = "ti,rstctrl"; + reg = <0x4 0x4>;Anytime I see a single register in DT I worry about scaling. How many of these in an SoC?
There are not many instances of the reset controller. There is one register per interconnect instance for external accelerators, so about 3 - 10 reset controller registers per SoC.
The reg offset above is wrong BTW, it should be 0x10 instead of 0x4. So I need to update this patch for that at least.
Regards,
Tony
Rob Herring
maintainerQuoted 31 lines · Tony Lindgren
Hi,
Quoted 13 lines · Rob Herring
Documentation/devicetree/bindings/reset/ti-rstctrl.txt line 10
Quoted 10 lines · Tony Lindgren
Documentation/devicetree/bindings/reset/ti-rstctrl.txt new file +10
-0+TI RSTCTRL Reset Controller + +Required properties: +- compatible : "ti,rstctrl" +- reg : Should contain 1 register ranges(address and length) +- #reset-cells: 1 + +Example: + prm_gfx: prm@1100 { + compatible = "simple-bus";What's a PRM?
PRM is power and reset manager. There is one instance per interconnect instance (clockdomain). PRM shows the status of the connected devices in the interconnect, such as device context lost and hardware wake-up dependencies. It also contains a single reset controller register for external accelerators such as DSP. The reset controller instance then has 1 - 3 bits for external accelerator sub device resets. Then there is a reset status register that shows the reset reason for the external accelerator.
Quoted 4 lines
Quoted 3 lines
Documentation/devicetree/bindings/reset/ti-rstctrl.txt new file +3
-0+ #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x1100 0x100>;
Quoted 5 lines
Quoted 1 line
And what else is in this range?
In PRM, there are also registers for each interconnect device context lost and wake-up dependencies. We don't have a driver for that yet, it's handled by the SoC init code currently.
Regardless of having/needing a driver, you should take a stab at doing the binding at least. It doesn't make sense to do the binding of the child without doing the parent.
Quoted 10 lines
Unlike the binding for reset controller, the binding for wake-up dependencies and context lost should look similar binding to the clkctrl clock binding we have. That's because there are tons of those registers.
Quoted 5 lines
Quoted 4 lines
Documentation/devicetree/bindings/reset/ti-rstctrl.txt new file +4
-0+ + gfx_rstctrl: rstctrl@4 { + compatible = "ti,rstctrl"; + reg = <0x4 0x4>;
Quoted 7 lines
Quoted 2 lines
Anytime I see a single register in DT I worry about scaling. How many of these in an SoC?
There are not many instances of the reset controller. There is one register per interconnect instance for external accelerators, so about 3 - 10 reset controller registers per SoC.
Okay, seems a reasonable number.
However, couldn't you just have PRM node(s) and have that register as a simple reset driver (along with anything else it handles).
Rob
Quoted 8 lines · Rob Herring
Quoted 3 lines · Tony Lindgren
In PRM, there are also registers for each interconnect device context lost and wake-up dependencies. We don't have a driver for that yet, it's handled by the SoC init code currently.
Regardless of having/needing a driver, you should take a stab at doing the binding at least. It doesn't make sense to do the binding of the child without doing the parent.
Sure, we have already partial binding documentation for PRM at Documentation/devicetree/bindings/arm/omap/prcm.txt. I'll take a look at updating it for the reset controller.
Quoted 18 lines
Quoted 10 lines
Unlike the binding for reset controller, the binding for wake-up dependencies and context lost should look similar binding to the clkctrl clock binding we have. That's because there are tons of those registers.
Quoted 5 lines
Quoted 4 lines
Documentation/devicetree/bindings/reset/ti-rstctrl.txt new file +4
-0+ + gfx_rstctrl: rstctrl@4 { + compatible = "ti,rstctrl"; + reg = <0x4 0x4>;Quoted 7 lines
Quoted 2 lines
Anytime I see a single register in DT I worry about scaling. How many of these in an SoC?
There are not many instances of the reset controller. There is one register per interconnect instance for external accelerators, so about 3 - 10 reset controller registers per SoC.
Quoted 4 lines
Okay, seems a reasonable number.
However, couldn't you just have PRM node(s) and have that register as a simple reset driver (along with anything else it handles).
We could have a driver for PRM, but I'm not sure if doing a separate PRM driver helps much here. It seems like reset-simple already does the job for most part and can be enhanced as needed :)
The missing piece is how to get the extra pieces of information to the consumer drivers.. That is the reset status and context lost status of each device.
Regards,
Tony