OMAP: Add DT bindings to specify when devices should not be idled or reset

On OMAP we have co-processor IPs, memory controllers, GPIOs which control regulators and power switches to PMIC, and SoC internal Bus IPs, some or most of which should either not be reset or idled or both. Have a way to pass this information from DT.
(In some cases there are erratas which prevent an IPs from being reset)

Also update omap_hwmod to extract this from DT.

Signed-off-by Rajendra Nayak <[email protected]>

---
 .../devicetree/bindings/arm/omap/omap.txt          |    3 ++-
 arch/arm/mach-omap2/omap_hwmod.c                   |   22 +++++++++++++-------
 2 files changed, 17 insertions(+), 8 deletions(-)

Documentation/devicetree/bindings/arm/omap/omap.txt +0 -0

index 6d498c7..a08647e 100644

Quoted 21 lines · Rajendra Nayak

On OMAP we have co-processor IPs, memory controllers, GPIOs which control regulators and power switches to PMIC, and SoC internal Bus IPs, some or most of which should either not be reset or idled or both. Have a way to pass this information from DT.
(In some cases there are erratas which prevent an IPs from being reset)

Also update omap_hwmod to extract this from DT.

Signed-off-by Rajendra Nayak <[email protected]>

---
 .../devicetree/bindings/arm/omap/omap.txt          |    3 ++-
 arch/arm/mach-omap2/omap_hwmod.c                   |   22 +++++++++++++-------
 2 files changed, 17 insertions(+), 8 deletions(-)

Documentation/devicetree/bindings/arm/omap/omap.txt +0 -0

index 6d498c7..a08647e 100644

Documentation/devicetree/bindings/arm/omap/omap.txt Required properties: · line 25

Quoted 6 lines

Documentation/devicetree/bindings/arm/omap/omap.txt +2 -1

@@ -21,7 +21,8 @@ Required properties:
 Optional properties:
 - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
   during suspend.
-
+- ti,no-reset: When present, the module should not be reset
+- ti,no-idle: When present, the module should not be idled

This naming is a bit confusing as people may think that the hardware has no reset support or no idle support. Let's try to make this to describe the hardware a bit more instead.

Then ideally we'd not map individual bits of data to properties, but describe few basic types of hardware instead and build lists of things instead of tagging things. Or maybe we can get this data from the bus hierarchy instead?

If these options don't work, and the choice may be board specific, then how about ti,skip-reset-on-init, and ti,skip-idle-on-init?

Regards,

Tony

Quoted 33 lines · Tony Lindgren

Quoted 21 lines · Rajendra Nayak

On OMAP we have co-processor IPs, memory controllers, GPIOs which control regulators and power switches to PMIC, and SoC internal Bus IPs, some or most of which should either not be reset or idled or both. Have a way to pass this information from DT.
(In some cases there are erratas which prevent an IPs from being reset)

Also update omap_hwmod to extract this from DT.

Signed-off-by Rajendra Nayak <[email protected]>

---
 .../devicetree/bindings/arm/omap/omap.txt          |    3 ++-
 arch/arm/mach-omap2/omap_hwmod.c                   |   22 +++++++++++++-------
 2 files changed, 17 insertions(+), 8 deletions(-)

Documentation/devicetree/bindings/arm/omap/omap.txt +0 -0

index 6d498c7..a08647e 100644

Documentation/devicetree/bindings/arm/omap/omap.txt Required properties: · line 25

Quoted 6 lines

Documentation/devicetree/bindings/arm/omap/omap.txt +2 -1

@@ -21,7 +21,8 @@ Required properties:
 Optional properties:
 - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
   during suspend.
-
+- ti,no-reset: When present, the module should not be reset
+- ti,no-idle: When present, the module should not be idled

This naming is a bit confusing as people may think that the hardware has no reset support or no idle support. Let's try to make this to describe the hardware a bit more instead.

Quoted 4 lines

Then ideally we'd not map individual bits of data to properties, but describe few basic types of hardware instead and build lists of things instead of tagging things. Or maybe we can get this data from the bus hierarchy instead?

Yeah, I thought if I could do this without any new bindings. For instance, never reset or idle something which is a "cpu" or an "interrupt-controller" or a "memory-controller" or a "bus". For some like memory-controllers though there are no bindings which describe them as memory-controllers.

Quoted 1 line

Quoted 3 lines

If these options don't work, and the choice may be board specific, then how about ti,skip-reset-on-init, and ti,skip-idle-on-init?

This looks fine too.

Quoted 46 lines · Rajendra Nayak

Quoted 33 lines · Tony Lindgren

Quoted 21 lines · Rajendra Nayak

On OMAP we have co-processor IPs, memory controllers, GPIOs which control regulators and power switches to PMIC, and SoC internal Bus IPs, some or most of which should either not be reset or idled or both. Have a way to pass this information from DT.
(In some cases there are erratas which prevent an IPs from being reset)

Also update omap_hwmod to extract this from DT.

Signed-off-by Rajendra Nayak <[email protected]>

---
 .../devicetree/bindings/arm/omap/omap.txt          |    3 ++-
 arch/arm/mach-omap2/omap_hwmod.c                   |   22 +++++++++++++-------
 2 files changed, 17 insertions(+), 8 deletions(-)

Documentation/devicetree/bindings/arm/omap/omap.txt +0 -0

index 6d498c7..a08647e 100644

Documentation/devicetree/bindings/arm/omap/omap.txt Required properties: · line 25

Quoted 6 lines

Documentation/devicetree/bindings/arm/omap/omap.txt +2 -1

@@ -21,7 +21,8 @@ Required properties:
 Optional properties:
 - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
   during suspend.
-
+- ti,no-reset: When present, the module should not be reset
+- ti,no-idle: When present, the module should not be idled

This naming is a bit confusing as people may think that the hardware has no reset support or no idle support. Let's try to make this to describe the hardware a bit more instead.

Quoted 4 lines

Then ideally we'd not map individual bits of data to properties, but describe few basic types of hardware instead and build lists of things instead of tagging things. Or maybe we can get this data from the bus hierarchy instead?

Yeah, I thought if I could do this without any new bindings. For instance, never reset or idle something which is a "cpu" or an "interrupt-controller" or a "memory-controller" or a "bus". For some like memory-controllers though there are no bindings which describe them as memory-controllers.

Quoted 1 line

Quoted 5 lines

Quoted 3 lines

If these options don't work, and the choice may be board specific, then how about ti,skip-reset-on-init, and ti,skip-idle-on-init?

This looks fine too.

Or you could also have various bus specific bindings for the ocp with lists of phandles?

ocp {
	reg = <...>;
	interrupts = <...>;
	ti,reset-on-init = <&module1, &module2>;
	...
};

Or something similar.

Tony

Quoted 11 lines · Tony Lindgren

Or you could also have various bus specific bindings for the ocp with lists of phandles?

ocp {
	reg = <...>;
	interrupts = <...>;
	ti,reset-on-init = <&module1, &module2>;
	...
};

Quoted 1 line

Or something similar.

The only problem I see with this is that some of these modules could be board specific ones and need to be part of the board dts files, like some boards which have PMIC power switch hooked up to some gpio etc. So there could be some SoC specific modules (like emif/gpmc on OMAPs) and some which depend on how the boards are designed.

Quoted 12 lines · Rajendra Nayak

Quoted 11 lines · Tony Lindgren

Or you could also have various bus specific bindings for the ocp with lists of phandles?

ocp {
	reg = <...>;
	interrupts = <...>;
	ti,reset-on-init = <&module1, &module2>;
	...
};

Quoted 7 lines

Quoted 1 line

Or something similar.

The only problem I see with this is that some of these modules could be board specific ones and need to be part of the board dts files, like some boards which have PMIC power switch hooked up to some gpio etc. So there could be some SoC specific modules (like emif/gpmc on OMAPs) and some which depend on how the boards are designed.

You can still override the ocp entry in the board specific .dts file. Would probably be a lot easier than to override each module separately in the board specific .dts file.

So, If I understand this right we would have the dt entries something like,

omap4.dtsi
------

ocp {
	reg = <...>;
	interrupts = <...>;
	ti,no-reset-on-init = <&emif1, &emif2, &gpmc>;
	...
};

omap4-panda-es.dts
------
ocp {

	ti,no-reset-on-init = <&emif1, &emif2, &gpmc, &gpio4>;
	...
};

Is it that, or you suggesting we can _append_ the soc list of modules with board specific modules, which I am not sure if its possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 21 lines · Tony Lindgren

Quoted 12 lines · Rajendra Nayak

Quoted 11 lines · Tony Lindgren

Or you could also have various bus specific bindings for the ocp with lists of phandles?

ocp {
	reg = <...>;
	interrupts = <...>;
	ti,reset-on-init = <&module1, &module2>;
	...
};

Quoted 7 lines

Quoted 1 line

Or something similar.

The only problem I see with this is that some of these modules could be board specific ones and need to be part of the board dts files, like some boards which have PMIC power switch hooked up to some gpio etc. So there could be some SoC specific modules (like emif/gpmc on OMAPs) and some which depend on how the boards are designed.

Quoted 3 lines

You can still override the ocp entry in the board specific .dts file. Would probably be a lot easier than to override each module separately in the board specific .dts file.

So, If I understand this right we would have the dt entries something like,

omap4.dtsi
------

ocp {
	reg = <...>;
	interrupts = <...>;
	ti,no-reset-on-init = <&emif1, &emif2, &gpmc>;
	...
};

omap4-panda-es.dts
------

ocp {
	ti,no-reset-on-init = <&emif1, &emif2, &gpmc, &gpio4>;
	...
};

Is it that, or you suggesting we can _append_ the soc list of modules with board specific modules, which I am not sure if its possible.

Quoted 45 lines · Rajendra Nayak

Quoted 21 lines · Tony Lindgren

Quoted 12 lines · Rajendra Nayak

Quoted 11 lines · Tony Lindgren

Or you could also have various bus specific bindings for the ocp with lists of phandles?

ocp {
	reg = <...>;
	interrupts = <...>;
	ti,reset-on-init = <&module1, &module2>;
	...
};

Quoted 7 lines

Quoted 1 line

Or something similar.

The only problem I see with this is that some of these modules could be board specific ones and need to be part of the board dts files, like some boards which have PMIC power switch hooked up to some gpio etc. So there could be some SoC specific modules (like emif/gpmc on OMAPs) and some which depend on how the boards are designed.

Quoted 3 lines

You can still override the ocp entry in the board specific .dts file. Would probably be a lot easier than to override each module separately in the board specific .dts file.

So, If I understand this right we would have the dt entries something like,

omap4.dtsi
------

ocp {
	reg = <...>;
	interrupts = <...>;
	ti,no-reset-on-init = <&emif1, &emif2, &gpmc>;
	...
};

omap4-panda-es.dts
------

ocp {
	ti,no-reset-on-init = <&emif1, &emif2, &gpmc, &gpio4>;
	...
};

Quoted 3 lines

Is it that, or you suggesting we can _append_ the soc list of modules with board specific modules, which I am not sure if its possible.

Yes I think the board specific entry just overrides the .dtsi entry.

Quoted 16 lines · Rajendra Nayak

On OMAP we have co-processor IPs, memory controllers, GPIOs which control regulators and power switches to PMIC, and SoC internal Bus IPs, some or most of which should either not be reset or idled or both. Have a way to pass this information from DT.
(In some cases there are erratas which prevent an IPs from being reset)

Also update omap_hwmod to extract this from DT.

Signed-off-by Rajendra Nayak <[email protected]>

---
  .../devicetree/bindings/arm/omap/omap.txt          |    3 ++-
  arch/arm/mach-omap2/omap_hwmod.c                   |   22 +++++++++++++-------
  2 files changed, 17 insertions(+), 8 deletions(-)

Documentation/devicetree/bindings/arm/omap/omap.txt Required properties: · line 25

Quoted 11 lines

Documentation/devicetree/bindings/arm/omap/omap.txt +2 -1

index 6d498c7..a08647e 100644
@@ -21,7 +21,8 @@ Required properties:
  Optional properties:
  - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
    during suspend.
-
+- ti,no-reset: When present, the module should not be reset
+- ti,no-idle: When present, the module should not be idled

This naming is a bit confusing as people may think that the hardware has no reset support or no idle support. Let's try to make this to describe the hardware a bit more instead.

Then ideally we'd not map individual bits of data to properties, but describe few basic types of hardware instead and build lists of things instead of tagging things. Or maybe we can get this data from the bus hierarchy instead?

If these options don't work, and the choice may be board specific, then how about ti,skip-reset-on-init, and ti,skip-idle-on-init?

Quoted 17 lines · Tony Lindgren

Quoted 16 lines · Rajendra Nayak

On OMAP we have co-processor IPs, memory controllers, GPIOs which control regulators and power switches to PMIC, and SoC internal Bus IPs, some or most of which should either not be reset or idled or both. Have a way to pass this information from DT.
(In some cases there are erratas which prevent an IPs from being reset)

Also update omap_hwmod to extract this from DT.

Signed-off-by Rajendra Nayak <[email protected]>

---
  .../devicetree/bindings/arm/omap/omap.txt          |    3 ++-
  arch/arm/mach-omap2/omap_hwmod.c                   |   22 +++++++++++++-------
  2 files changed, 17 insertions(+), 8 deletions(-)

Quoted 15 lines

Documentation/devicetree/bindings/arm/omap/omap.txt Required properties: · line 25

Quoted 11 lines

Documentation/devicetree/bindings/arm/omap/omap.txt +2 -1

index 6d498c7..a08647e 100644
@@ -21,7 +21,8 @@ Required properties:
  Optional properties:
  - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
    during suspend.
-
+- ti,no-reset: When present, the module should not be reset
+- ti,no-idle: When present, the module should not be idled

This naming is a bit confusing as people may think that the hardware has no reset support or no idle support. Let's try to make this to describe the hardware a bit more instead.

Yeah, I do agree here. That should look like a real HW property and nor a configuration.

Quoted 5 lines

Then ideally we'd not map individual bits of data to properties, but describe few basic types of hardware instead and build lists of things instead of tagging things. Or maybe we can get this data from the bus hierarchy instead?

Quoted 3 lines

If these options don't work, and the choice may be board specific, then how about ti,skip-reset-on-init, and ti,skip-idle-on-init?

It looks like a configuration as well :-).
I was thinking of something like "ti,do-not-support-reset-on-init", but that a little bit too long.

Regards,
Benoit

Now that we have DT bindings to specify which devices on the SoC should not be reset or idled, get rid of the same information existing as part of the hwmod data files and pass this info from DT instead.

For GPMC, the HWMOD_INIT_NO_RESET flag seems to be added in hwmod not due to any errata around the GPMC IP, but rather because any timings set by the bootloader are not being correctly programmed by the kernel. This seems like something that needs to be fixed as part of GPMC driver in the kernel, and hence the flag is left as is in hwmod, which can be removed once the driver does what its expected to.

Signed-off-by Rajendra Nayak <[email protected]>

---
 arch/arm/boot/dts/am33xx.dtsi              |    2 ++
 arch/arm/boot/dts/omap4.dtsi               |    3 +++
 arch/arm/boot/dts/omap5.dtsi               |    2 ++
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |    4 ++--
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    4 +---
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |    2 --
 6 files changed, 10 insertions(+), 7 deletions(-)

Hi Beno?t, Rajendra,

Quoted 12 lines · Rajendra Nayak

Now that we have DT bindings to specify which devices on the SoC should not be reset or idled, get rid of the same information existing as part of the hwmod data files and pass this info from DT instead.

For GPMC, the HWMOD_INIT_NO_RESET flag seems to be added in hwmod not due to any errata around the GPMC IP, but rather because any timings set by the bootloader are not being correctly programmed by the kernel. This seems like something that needs to be fixed as part of GPMC driver in the kernel, and hence the flag is left as is in hwmod, which can be removed once the driver does what its expected to.

Signed-off-by Rajendra Nayak <[email protected]>

Quoted 8 lines

---
 arch/arm/boot/dts/am33xx.dtsi              |    2 ++
 arch/arm/boot/dts/omap4.dtsi               |    3 +++
 arch/arm/boot/dts/omap5.dtsi               |    2 ++
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |    4 ++--
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    4 +---
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |    2 --
 6 files changed, 10 insertions(+), 7 deletions(-)

Looking at this one, maybe the best thing for this patch is for Rajendra to split it into two patches. Beno?t can merge the DTS patch first, then I can merge the hwmod side as a cleanup once the first one goes in. That will avoid conflicts from other DTS and hwmod changes going into the tree.

Rajendra, when you do the split, please add in the DT documentation part from patch 2. Am going to strip that out from the second patch and just merge the hwmod changes.

Sound good?

- Paul

Quoted 30 lines · Paul Walmsley

Hi Beno?t, Rajendra,

Quoted 12 lines · Rajendra Nayak

Now that we have DT bindings to specify which devices on the SoC should not be reset or idled, get rid of the same information existing as part of the hwmod data files and pass this info from DT instead.

For GPMC, the HWMOD_INIT_NO_RESET flag seems to be added in hwmod not due to any errata around the GPMC IP, but rather because any timings set by the bootloader are not being correctly programmed by the kernel. This seems like something that needs to be fixed as part of GPMC driver in the kernel, and hence the flag is left as is in hwmod, which can be removed once the driver does what its expected to.

Signed-off-by Rajendra Nayak <[email protected]>

Quoted 8 lines

---
  arch/arm/boot/dts/am33xx.dtsi              |    2 ++
  arch/arm/boot/dts/omap4.dtsi               |    3 +++
  arch/arm/boot/dts/omap5.dtsi               |    2 ++
  arch/arm/mach-omap2/omap_hwmod_33xx_data.c |    4 ++--
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    4 +---
  arch/arm/mach-omap2/omap_hwmod_54xx_data.c |    2 --
  6 files changed, 10 insertions(+), 7 deletions(-)

Looking at this one, maybe the best thing for this patch is for Rajendra to split it into two patches. Beno?t can merge the DTS patch first, then I can merge the hwmod side as a cleanup once the first one goes in. That will avoid conflicts from other DTS and hwmod changes going into the tree.

Quoted 5 lines

Rajendra, when you do the split, please add in the DT documentation part from patch 2. Am going to strip that out from the second patch and just merge the hwmod changes.

Sound good?

Sure Paul, I'll repost the complete series with proper splits such that its easier for you and Benoit to pick them up independently.

Hi Rajendra,

Quoted 35 lines · Rajendra Nayak

Quoted 34 lines · Paul Walmsley

Hi Beno?t, Rajendra,

Quoted 12 lines · Rajendra Nayak

Now that we have DT bindings to specify which devices on the SoC should not be reset or idled, get rid of the same information existing as part of the hwmod data files and pass this info from DT instead.

For GPMC, the HWMOD_INIT_NO_RESET flag seems to be added in hwmod not due to any errata around the GPMC IP, but rather because any timings set by the bootloader are not being correctly programmed by the kernel. This seems like something that needs to be fixed as part of GPMC driver in the kernel, and hence the flag is left as is in hwmod, which can be removed once the driver does what its expected to.

Signed-off-by Rajendra Nayak <[email protected]>

Quoted 8 lines

---
  arch/arm/boot/dts/am33xx.dtsi              |    2 ++
  arch/arm/boot/dts/omap4.dtsi               |    3 +++
  arch/arm/boot/dts/omap5.dtsi               |    2 ++
  arch/arm/mach-omap2/omap_hwmod_33xx_data.c |    4 ++--
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    4 +---
  arch/arm/mach-omap2/omap_hwmod_54xx_data.c |    2 --
  6 files changed, 10 insertions(+), 7 deletions(-)

Looking at this one, maybe the best thing for this patch is for Rajendra to split it into two patches. Beno?t can merge the DTS patch first, then I can merge the hwmod side as a cleanup once the first one goes in. That will avoid conflicts from other DTS and hwmod changes going into the tree.

Rajendra, when you do the split, please add in the DT documentation part from patch 2. Am going to strip that out from the second patch and just merge the hwmod changes.

Quoted 4 lines

Quoted 1 line

Sound good?

Sure Paul, I'll repost the complete series with proper splits such that its easier for you and Benoit to pick them up independently.

If you could do it soon, I'm about to send an early pull request to Tony to avoid the trouble we had last time.

Thanks,
Benoit