[RFC PATCH 4/7] ARM: OMAP4+: PRM: register interrupt information from DT

Allow the PRM interrupt information to be picked up from device tree.
the only exception is for OMAP4 which uses values pre-populated and allows
compatibility with older dtb.

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/prm44xx.c |   41 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 1ecf244..784b3e1 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c

@@ -17,6 +17,7 @@
 #include <linux/errno.h>
 #include <linux/err.h>
 #include <linux/io.h>
+#include <linux/of_irq.h>
 
 
 #include "soc.h"

@@ -698,11 +699,51 @@ int __init omap44xx_prm_init(void)
 	return prm_register(&omap44xx_prm_ll_data);
 }
 
+static struct of_device_id omap_prm_dt_match_table[] = {
+	{ .compatible = "ti,omap4-prm" },
+	{ .compatible = "ti,omap5-prm" },
+	{ .compatible = "ti,dra7-prm" },
+	{ }
+};
+
 static int omap44xx_prm_late_init(void)
 {
+	struct device_node *np;
+	int irq_num;
+
+	/* OMAP4+ is DT only now */
+	if (!of_have_populated_dt())
+		return 0;
+
 	if (!(prm_features & PRM_HAS_IO_WAKEUP))
 		return 0;
 
+	np = of_find_matching_node(NULL, omap_prm_dt_match_table);
+
+	if (!np) {
+		/* Default loaded up with OMAP4 values - older dtb compatible? */
+		if (!cpu_is_omap44xx())
+			return 0;
+	} else {
+		irq_num = of_irq_get(np, 0);
+		/*
+		 * Already have OMAP4 IRQ num. For all other platforms, we need
+		 * IRQ numbers from DT - old dtb compatible?
+		 */
+		if (irq_num < 0 && !cpu_is_omap44xx()) {
+
+			if (irq_num == -EPROBE_DEFER)
+				return irq_num;
+
+			/* Have nothing to do */
+			return 0;
+		}
+
+		/* Once OMAP4 DT is filled as well */
+		if (irq_num >= 0)
+			omap4_prcm_irq_setup.irq = irq_num;
+	}
+
 	omap44xx_prm_enable_io_wakeup();
 
 	return omap_prcm_register_chain_handler(&omap4_prcm_irq_setup);

-- 
1.7.9.5

* Nishanth Menon [off-list ref] [140605 20:37]:

I'd like to avoid adding more driver like stuff to mach-omap2
and parsing compatible flags and dealing with interupts sounds
very driver like.. But maybe just the handling can be moved
out?

Would a simple driver be doable that parses the compatible
flags, takes care of the IRQ chaining, and gets some SoC specific
function pointers as auxdata?

That would allow further work later on to remove the auxdata
dependencies possibly.

Regards,

Tony

On Mon, Jul 21, 2014 at 5:51 AM, Tony Lindgren [off-list ref] wrote:

quoted

+static struct of_device_id omap_prm_dt_match_table[] = {
+     { .compatible = "ti,omap4-prm" },
+     { .compatible = "ti,omap5-prm" },
+     { .compatible = "ti,dra7-prm" },
+     { }
+};
+

I'd like to avoid adding more driver like stuff to mach-omap2
and parsing compatible flags and dealing with interupts sounds
very driver like.. But maybe just the handling can be moved
out?

I understand your view, but, Handling of interrupts is already in
place even now in mach-omap2. Currently the prm devices are handled by
mach-omap2 and all this does it to prevent hardcoding of irq numbers
within the current code.

Would a simple driver be doable that parses the compatible
flags, takes care of the IRQ chaining, and gets some SoC specific
function pointers as auxdata?

Tero has been trying to move PRM/CM stuff to a separate drivers of
thier own. With that there wont be a need for auxdata even. - this
current logic will get merged with that driver - if and when that is
ready. I am not actually adding any driver logic here - just reusing
the logic and providing glue for using dt description instead of
hardcoded logic that the current mach-omap2 driver does.

That would allow further work later on to remove the auxdata
dependencies possibly.

-- 
---
Regards,
Nishanth Menon

* Nishanth Menon [off-list ref] [140721 04:24]:

On Mon, Jul 21, 2014 at 5:51 AM, Tony Lindgren [off-list ref] wrote:

quoted

quoted

+static struct of_device_id omap_prm_dt_match_table[] = {
+     { .compatible = "ti,omap4-prm" },
+     { .compatible = "ti,omap5-prm" },
+     { .compatible = "ti,dra7-prm" },
+     { }
+};
+

I'd like to avoid adding more driver like stuff to mach-omap2
and parsing compatible flags and dealing with interupts sounds
very driver like.. But maybe just the handling can be moved
out?

I understand your view, but, Handling of interrupts is already in
place even now in mach-omap2. Currently the prm devices are handled by
mach-omap2 and all this does it to prevent hardcoding of irq numbers
within the current code.

Yeah but at a cost of no dev entry, no probe etc. I'd rather keep
that SoC specific data around until a driver can deal with it
in a standard way.

quoted

Would a simple driver be doable that parses the compatible
flags, takes care of the IRQ chaining, and gets some SoC specific
function pointers as auxdata?

Tero has been trying to move PRM/CM stuff to a separate drivers of
thier own. With that there wont be a need for auxdata even. - this
current logic will get merged with that driver - if and when that is
ready. I am not actually adding any driver logic here - just reusing
the logic and providing glue for using dt description instead of
hardcoded logic that the current mach-omap2 driver does.

Well how about let's just leave out the non-standard parts for
now, then once the PRM/CM driver can deal with, it can do things
in a normal way?

Regards,

Tony

On Mon, Jul 21, 2014 at 6:28 AM, Tony Lindgren [off-list ref] wrote:

* Nishanth Menon [off-list ref] [140721 04:24]:

quoted

On Mon, Jul 21, 2014 at 5:51 AM, Tony Lindgren [off-list ref] wrote:

quoted

quoted

+static struct of_device_id omap_prm_dt_match_table[] = {
+     { .compatible = "ti,omap4-prm" },
+     { .compatible = "ti,omap5-prm" },
+     { .compatible = "ti,dra7-prm" },
+     { }
+};
+

I'd like to avoid adding more driver like stuff to mach-omap2
and parsing compatible flags and dealing with interupts sounds
very driver like.. But maybe just the handling can be moved
out?

I understand your view, but, Handling of interrupts is already in
place even now in mach-omap2. Currently the prm devices are handled by
mach-omap2 and all this does it to prevent hardcoding of irq numbers
within the current code.

Yeah but at a cost of no dev entry, no probe etc. I'd rather keep
that SoC specific data around until a driver can deal with it
in a standard way.

quoted

quoted

Would a simple driver be doable that parses the compatible
flags, takes care of the IRQ chaining, and gets some SoC specific
function pointers as auxdata?

Tero has been trying to move PRM/CM stuff to a separate drivers of
thier own. With that there wont be a need for auxdata even. - this
current logic will get merged with that driver - if and when that is
ready. I am not actually adding any driver logic here - just reusing
the logic and providing glue for using dt description instead of
hardcoded logic that the current mach-omap2 driver does.

Well how about let's just leave out the non-standard parts for
now, then once the PRM/CM driver can deal with, it can do things
in a normal way?

Broken PRCM interrupt handling for DRA7. but if you like to state
which parts are ok, I can probably repost with just those and leave
the rest for when ever PRM / CM driver happens to work out (and as a
result keep DRA7 daisy chain support broken till then - so probably
blocking low power features such as suspend-to-ram till that work is
complete.).

-- 
---
Regards,
Nishanth Menon

* Nishanth Menon [off-list ref] [140721 05:11]:

On Mon, Jul 21, 2014 at 6:28 AM, Tony Lindgren [off-list ref] wrote:

quoted

* Nishanth Menon [off-list ref] [140721 04:24]:

quoted

On Mon, Jul 21, 2014 at 5:51 AM, Tony Lindgren [off-list ref] wrote:

quoted

quoted

+static struct of_device_id omap_prm_dt_match_table[] = {
+     { .compatible = "ti,omap4-prm" },
+     { .compatible = "ti,omap5-prm" },
+     { .compatible = "ti,dra7-prm" },
+     { }
+};
+

I'd like to avoid adding more driver like stuff to mach-omap2
and parsing compatible flags and dealing with interupts sounds
very driver like.. But maybe just the handling can be moved
out?

I understand your view, but, Handling of interrupts is already in
place even now in mach-omap2. Currently the prm devices are handled by
mach-omap2 and all this does it to prevent hardcoding of irq numbers
within the current code.

Yeah but at a cost of no dev entry, no probe etc. I'd rather keep
that SoC specific data around until a driver can deal with it
in a standard way.

quoted

quoted

Would a simple driver be doable that parses the compatible
flags, takes care of the IRQ chaining, and gets some SoC specific
function pointers as auxdata?

Tero has been trying to move PRM/CM stuff to a separate drivers of
thier own. With that there wont be a need for auxdata even. - this
current logic will get merged with that driver - if and when that is
ready. I am not actually adding any driver logic here - just reusing
the logic and providing glue for using dt description instead of
hardcoded logic that the current mach-omap2 driver does.

Well how about let's just leave out the non-standard parts for
now, then once the PRM/CM driver can deal with, it can do things
in a normal way?

Broken PRCM interrupt handling for DRA7. but if you like to state
which parts are ok, I can probably repost with just those and leave
the rest for when ever PRM / CM driver happens to work out (and as a
result keep DRA7 daisy chain support broken till then - so probably
blocking low power features such as suspend-to-ram till that work is
complete.).

Well if Tero is fine with this approach, looks OK for me. At least
the .dts entries should work in the long run.

Regards,

Tony