ARM: am33xx.dtsi: Added syscon compatible prcm_dev device

PATCH In review Cor Peters 4 participants 7 messages Nov 15, 2016 – Nov 16, 2016 4 messages not in the archive

Subsystems (2)

Device tree bindings Watchdog device drivers

lore

Share & tools

lore

Cor Peters

author

2016-11-15 08:44 UTC #0 lore raw

PATCH 2/2 ARM: am33xx.dtsi: Added syscon compatible prcm_dev device

This patch adds the PRM_DEV as a syscon compatible device to am33xx.dtsi. This is needed for the watchdog bootstatus patch.

Signed-off-by Cor Peters <cpeters-JQzsJ8WnmGqc6Wr4J9gsBQC/[email protected]>

---
 arch/arm/boot/dts/am33xx.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

arch/arm/boot/dts/am33xx.dtsi +6 -0

index 194d884..e8faf19 100644
@@ -115,6 +115,7 @@
                        prcm: prcm@200000 {
                                compatible = "ti,am3-prcm";
                                reg = <0x200000 0x4000>;
+                               ranges = <0 0x200000 0x4000>;
 
                                prcm_clocks: clocks {
                                        #address-cells = <1>;

@@ -123,6 +124,11 @@
 
                                prcm_clockdomains: clockdomains {
                                };
+
+                               prcm_wkup: prcm-wkup@f00 {
+                                       compatible = "ti,omap3-prcm-dev", "syscon";
+                                       reg = <0xf00 0xff>;
+                               };
                        };
 
                        scm: scm@210000 {

Signature · 5 lines

1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Tony Lindgren

2016-11-15 17:35 UTC #1 lore raw

Quoted 2 lines · Cor Peters

This patch adds the PRM_DEV as a syscon compatible device to am33xx.dtsi. This is needed for the watchdog bootstatus patch.

We somehow need to see the bootreason for sure.. But we need to check with Tero on the reset driver work too.

Tero, does setting up of PRM_DEVICE as syscon cause issues for your reset driver work?

Regards,

Tony

Quoted 36 lines

Signed-off-by Cor Peters <cpeters-JQzsJ8WnmGqc6Wr4J9gsBQC/[email protected]>

---
 arch/arm/boot/dts/am33xx.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

arch/arm/boot/dts/am33xx.dtsi +6 -0

index 194d884..e8faf19 100644
@@ -115,6 +115,7 @@
                        prcm: prcm@200000 {
                                compatible = "ti,am3-prcm";
                                reg = <0x200000 0x4000>;
+                               ranges = <0 0x200000 0x4000>;
 
                                prcm_clocks: clocks {
                                        #address-cells = <1>;

@@ -123,6 +124,11 @@
 
                                prcm_clockdomains: clockdomains {
                                };
+
+                               prcm_wkup: prcm-wkup@f00 {
+                                       compatible = "ti,omap3-prcm-dev", "syscon";
+                                       reg = <0xf00 0xff>;
+                               };
                        };
 
                        scm: scm@210000 {

Signature · 5 lines

1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

Tony Lindgren

2016-11-15 17:38 UTC #3 lore raw

Quoted 9 lines · Tony Lindgren

Quoted 2 lines · Cor Peters
This patch adds the PRM_DEV as a syscon compatible device to am33xx.dtsi. This is needed for the watchdog bootstatus patch.
We somehow need to see the bootreason for sure.. But we need to check with Tero on the reset driver work too.
Tero, does setting up of PRM_DEVICE as syscon cause issues for your reset driver work?

The nightmare scenario is that we have drivers calling random syscon areas across various interconnect targets and then we have zero chance of getting genpd to ever to work properly.

Do the reset drivers offer some way of exporting the reset status?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

Tero Kristo

2016-11-15 19:18 UTC #5 lore raw

Quoted 10 lines · Tony Lindgren

Quoted 9 lines · Tony Lindgren
Quoted 2 lines · Cor Peters
This patch adds the PRM_DEV as a syscon compatible device to am33xx.dtsi. This is needed for the watchdog bootstatus patch.
We somehow need to see the bootreason for sure.. But we need to check with Tero on the reset driver work too.
Tero, does setting up of PRM_DEVICE as syscon cause issues for your reset driver work?

Good question, currently the reset driver is on hold waiting for hwmod / interconnect work to nudge forward. We could probably try to even re-use the syscon reset driver for OMAPs (drivers/reset/reset-ti-syscon.c); reset handling is not performance critical as such, and we only have few sources for these so...

Quoted 4 lines

The nightmare scenario is that we have drivers calling random syscon areas across various interconnect targets and then we have zero chance of getting genpd to ever to work properly.

Exporting this specific area exposes a few interesting features, like performing a system wide reset or tweaking SRAM PM configs (preventing SRAM LDOs from idling for example.)

Quoted 1 line

Do the reset drivers offer some way of exporting the reset status?

reset_control_status() can be used to read the reset status, this is however mostly meant for checking if reset line is currently asserted or not. We could in theory overload this for checking if reset has been asserted previously or not (checking current status for watchdog reset doesn't make much sense for example.)

-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 6861ab40-8727-86ab-17bc-6bb7dc3de30a-l0cyMroinI0@public.gmane.org

Tony Lindgren

2016-11-16 17:14 UTC #7 lore raw

Quoted 27 lines · Tero Kristo

Quoted 10 lines · Tony Lindgren
Quoted 9 lines · Tony Lindgren
Quoted 2 lines · Cor Peters
This patch adds the PRM_DEV as a syscon compatible device to am33xx.dtsi. This is needed for the watchdog bootstatus patch.
We somehow need to see the bootreason for sure.. But we need to check with Tero on the reset driver work too.
Tero, does setting up of PRM_DEVICE as syscon cause issues for your reset driver work?
Good question, currently the reset driver is on hold waiting for hwmod / interconnect work to nudge forward. We could probably try to even re-use the syscon reset driver for OMAPs (drivers/reset/reset-ti-syscon.c); reset handling is not performance critical as such, and we only have few sources for these so...
Quoted 4 lines
The nightmare scenario is that we have drivers calling random syscon areas across various interconnect targets and then we have zero chance of getting genpd to ever to work properly.
Exporting this specific area exposes a few interesting features, like performing a system wide reset or tweaking SRAM PM configs (preventing SRAM LDOs from idling for example.)

Quoted 7 lines

Quoted 1 line
Do the reset drivers offer some way of exporting the reset status?
reset_control_status() can be used to read the reset status, this is however mostly meant for checking if reset line is currently asserted or not. We could in theory overload this for checking if reset has been asserted previously or not (checking current status for watchdog reset doesn't make much sense for example.)

OK in that case I'd prefer that we get the status from a reset driver. I think a minimal reset driver could be already done as a regular device driver that works also as a loadable module. It probably still needs some callback functions passed to it in platform_data via pdata-quirks.c though.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

Tero Kristo

2016-11-16 18:58 UTC #9 lore raw

Quoted 36 lines · Tony Lindgren

Quoted 27 lines · Tero Kristo
Quoted 10 lines · Tony Lindgren
Quoted 9 lines · Tony Lindgren
Quoted 2 lines · Cor Peters
This patch adds the PRM_DEV as a syscon compatible device to am33xx.dtsi. This is needed for the watchdog bootstatus patch.
We somehow need to see the bootreason for sure.. But we need to check with Tero on the reset driver work too.
Tero, does setting up of PRM_DEVICE as syscon cause issues for your reset driver work?
Good question, currently the reset driver is on hold waiting for hwmod / interconnect work to nudge forward. We could probably try to even re-use the syscon reset driver for OMAPs (drivers/reset/reset-ti-syscon.c); reset handling is not performance critical as such, and we only have few sources for these so...
Quoted 4 lines
The nightmare scenario is that we have drivers calling random syscon areas across various interconnect targets and then we have zero chance of getting genpd to ever to work properly.
Exporting this specific area exposes a few interesting features, like performing a system wide reset or tweaking SRAM PM configs (preventing SRAM LDOs from idling for example.)
Quoted 7 lines
Quoted 1 line
Do the reset drivers offer some way of exporting the reset status?
reset_control_status() can be used to read the reset status, this is however mostly meant for checking if reset line is currently asserted or not. We could in theory overload this for checking if reset has been asserted previously or not (checking current status for watchdog reset doesn't make much sense for example.)

Quoted 5 lines

OK in that case I'd prefer that we get the status from a reset driver. I think a minimal reset driver could be already done as a regular device driver that works also as a loadable module. It probably still needs some callback functions passed to it in platform_data via pdata-quirks.c though.

Yea I think this should be doable. The driver can be extended later with support for other features also once those are actually required.

-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Guenter Roeck

2016-11-15 18:38 UTC #10 lore raw

In reply to a message not in the archive

Quoted 7 lines · Tony Lindgren

Quoted 2 lines · Cor Peters
This patch adds the PRM_DEV as a syscon compatible device to am33xx.dtsi. This is needed for the watchdog bootstatus patch.
We somehow need to see the bootreason for sure.. But we need to check with Tero on the reset driver work too.

Another problem is that the boot reason bit is not well defined and, if I understand correctly, can change with different SoCs. So this would also need a means to select the actual register bit to use.

Thanks,
Guenter

Quoted 36 lines

Tero, does setting up of PRM_DEVICE as syscon cause issues for your reset driver work?

Regards,

Tony

Quoted 29 lines

Signed-off-by Cor Peters <cpeters-JQzsJ8WnmGqc6Wr4J9gsBQC/[email protected]>

---
 arch/arm/boot/dts/am33xx.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

arch/arm/boot/dts/am33xx.dtsi +6 -0

index 194d884..e8faf19 100644
@@ -115,6 +115,7 @@
                        prcm: prcm@200000 {
                                compatible = "ti,am3-prcm";
                                reg = <0x200000 0x4000>;
+                               ranges = <0 0x200000 0x4000>;
 
                                prcm_clocks: clocks {
                                        #address-cells = <1>;

@@ -123,6 +124,11 @@
 
                                prcm_clockdomains: clockdomains {
                                };
+
+                               prcm_wkup: prcm-wkup@f00 {
+                                       compatible = "ti,omap3-prcm-dev", "syscon";
+                                       reg = <0xf00 0xff>;
+                               };
                        };

Quoted 11 lines

Quoted 7 lines
arch/arm/boot/dts/am33xx.dtsi +0 -0
                        scm: scm@210000 {
Signature · 5 lines
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html