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

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

[Cor Peters]

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@victronenergy.com>
---
 arch/arm/boot/dts/am33xx.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 194d884..e8faf19 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -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 {
-- 
1.9.1

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

[Tony Lindgren]

* Cor Peters <cpeters@victronenergy.com> [161115 01:00]:
> 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

> 
> Signed-off-by: Cor Peters <cpeters@victronenergy.com>
> ---
>  arch/arm/boot/dts/am33xx.dtsi | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 194d884..e8faf19 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -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 {
> -- 
> 1.9.1
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [161115 09:35]:
> * Cor Peters <cpeters@victronenergy.com> [161115 01:00]:
> > 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

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

[Tero Kristo]

On 15/11/16 19:38, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [161115 09:35]:
>> * Cor Peters <cpeters@victronenergy.com> [161115 01:00]:
>>> 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...

>
> 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.)

> 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

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

[Tony Lindgren]

* Tero Kristo <t-kristo@ti.com> [161115 11:18]:
> On 15/11/16 19:38, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [161115 09:35]:
> > > * Cor Peters <cpeters@victronenergy.com> [161115 01:00]:
> > > > 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...
> 
> > 
> > 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.)
> 
> > 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

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

[Tero Kristo]

On 16/11/16 19:14, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [161115 11:18]:
>> On 15/11/16 19:38, Tony Lindgren wrote:
>>> * Tony Lindgren <tony@atomide.com> [161115 09:35]:
>>>> * Cor Peters <cpeters@victronenergy.com> [161115 01:00]:
>>>>> 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...
>>
>>>
>>> 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.)
>>
>>> 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.

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

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

[Guenter Roeck]

On Tue, Nov 15, 2016 at 09:35:15AM -0800, Tony Lindgren wrote:
> * Cor Peters <cpeters@victronenergy.com> [161115 01:00]:
> > 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

> Tero, does setting up of PRM_DEVICE as syscon cause issues for
> your reset driver work?
> 
> Regards,
> 
> Tony
> 
> > 
> > Signed-off-by: Cor Peters <cpeters@victronenergy.com>
> > ---
> >  arch/arm/boot/dts/am33xx.dtsi | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> > index 194d884..e8faf19 100644
> > --- a/arch/arm/boot/dts/am33xx.dtsi
> > +++ b/arch/arm/boot/dts/am33xx.dtsi
> > @@ -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 {
> > -- 
> > 1.9.1
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to majordomo@vger.kernel.org
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html