[PATCHv9 00/18] omap PRCM chain handler

[PATCHv9 00/18] omap PRCM chain handler

[Tero Kristo]

Hello,

Following set contains the version 9 of this work. This patch set contains
a number of patches tagged as 'TEMP', they are only meant for testing
purposes and to provide proof of concept. Most of the 'TEMP' patches are
related to UART runtime handling and they will be replaced by work done
by Govindraj Raja.

As this is a new set sent to linux-arm and linux-kernel lists, the basic
concept being tackled with this set is to provide a mechanism for multiple
drivers to register for PRCM interrupts. PRCM interrupt contains a SoC
depenpend number of events, which of most interesting ones are wakeup and
IO chain. These are the only supported events in the driver currently, but
it is possible to add more by tweaking omap3xxx-prm.c and omap4xxx-prm.c
files.

This driver should also be expanded later to contain much of the code
currently included within the OMAP voltage framework, which resides under
arch/arm/mach-omap2/voltage*,vc*,vp*.

Changes compared to previous version of this set:

- PRM driver is now moved under /drivers/mfd
- PRM driver split into three parts now, common, omap3 and omap4
- version of the driver to init is detected based on PRM version (patch 11)
- cleaned up the initialization logic a bit (platform device is built
  separately, provide two different drivers)
- renamed PRM hwmods as prm3xxx and prm4xxx

These patches have been tested on omap3 beagle and omap4 blaze platforms.
Tested features include suspend and dynamic idle.
Tested trees are available at:

git at gitorious.org:~kristo/omap-pm/omap-pm-work.git

branches: omap3_prcm_chain and omap4_prcm_chain

-Tero


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
 

[PATCHv9 01/18] OMAP2+: hwmod: Add API to enable IO ring wakeup.

[Tero Kristo]

From: R, Govindraj <govindraj.raja@ti.com>

Add API to enable IO pad wakeup capability based on mux dynamic pad and
wake_up enable flag available from hwmod_mux initialization.

Use the wakeup_enable flag and enable wakeup capability
for the given pads. Wakeup capability will be enabled/disabled
during hwmod idle transition based on whether wakeup_flag is
set or cleared.

Map the enable/disable pad wakeup API's to hwmod_wakeup_enable/disable.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |   59 ++++++++++++++++++++++++++++++++++++++
 1 files changed, 59 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 84cc0bd..e751dd9 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2062,6 +2062,34 @@ static int __init omap_hwmod_setup_all(void)
 core_initcall(omap_hwmod_setup_all);
 
 /**
+ * omap_hwmod_set_ioring_wakeup - enable io pad wakeup flag.
+ * @oh: struct omap_hwmod *
+ * @set: bool value indicating to set or clear wakeup status.
+ *
+ * Set or Clear wakeup flag for the io_pad.
+ */
+static int omap_hwmod_set_ioring_wakeup(struct omap_hwmod *oh, bool set_wake)
+{
+	struct omap_device_pad *pad;
+	int ret = -EINVAL, j;
+
+	if (oh->mux && oh->mux->enabled) {
+		for (j = 0; j < oh->mux->nr_pads_dynamic; j++) {
+			pad = oh->mux->pads_dynamic[j];
+			if (pad->flags & OMAP_DEVICE_PAD_WAKEUP) {
+				if (set_wake)
+					pad->idle |= OMAP_WAKEUP_EN;
+				else
+					pad->idle &= ~OMAP_WAKEUP_EN;
+				ret = 0;
+			}
+		}
+	}
+
+	return ret;
+}
+
+/**
  * omap_hwmod_enable - enable an omap_hwmod
  * @oh: struct omap_hwmod *
  *
@@ -2393,6 +2421,35 @@ int omap_hwmod_del_initiator_dep(struct omap_hwmod *oh,
 {
 	return _del_initiator_dep(oh, init_oh);
 }
+/**
+ * omap_hwmod_enable_ioring_wakeup - Set wakeup flag for iopad.
+ * @oh: struct omap_hwmod *
+ *
+ * Traverse through dynamic pads, if pad is enabled then
+ * set wakeup enable bit flag for the mux pin. Wakeup pad bit
+ * will be set during hwmod idle transistion.
+ * Return error if pads are not enabled or not available.
+ */
+int omap_hwmod_enable_ioring_wakeup(struct omap_hwmod *oh)
+{
+	/* Enable pad wake-up capability */
+	return omap_hwmod_set_ioring_wakeup(oh, true);
+}
+
+/**
+ * omap_hwmod_disable_ioring_wakeup - Clear wakeup flag for iopad.
+ * @oh: struct omap_hwmod *
+ *
+ * Traverse through dynamic pads, if pad is enabled then
+ * clear wakeup enable bit flag for the mux pin. Wakeup pad bit
+ * will be set during hwmod idle transistion.
+ * Return error if pads are not enabled or not available.
+ */
+int omap_hwmod_disable_ioring_wakeup(struct omap_hwmod *oh)
+{
+	/* Disable pad wakeup capability */
+	return omap_hwmod_set_ioring_wakeup(oh, false);
+}
 
 /**
  * omap_hwmod_enable_wakeup - allow device to wake up the system
@@ -2419,6 +2476,7 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
 	v = oh->_sysc_cache;
 	_enable_wakeup(oh, &v);
 	_write_sysconfig(v, oh);
+	omap_hwmod_enable_ioring_wakeup(oh);
 	spin_unlock_irqrestore(&oh->_lock, flags);
 
 	return 0;
@@ -2449,6 +2507,7 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
 	v = oh->_sysc_cache;
 	_disable_wakeup(oh, &v);
 	_write_sysconfig(v, oh);
+	omap_hwmod_disable_ioring_wakeup(oh);
 	spin_unlock_irqrestore(&oh->_lock, flags);
 
 	return 0;
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
 

[PATCHv9 02/18] OMAP2+: hwmod: Add API to check IO PAD wakeup status

[Tero Kristo]

From: R, Govindraj <govindraj.raja@ti.com>

Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
---
 arch/arm/mach-omap2/mux.c                    |   30 ++++++++++++++++++++++++++
 arch/arm/mach-omap2/mux.h                    |   13 +++++++++++
 arch/arm/mach-omap2/omap_hwmod.c             |    7 ++++++
 arch/arm/plat-omap/include/plat/omap_hwmod.h |    1 +
 4 files changed, 51 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index c7fb22a..50ee806 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -351,6 +351,36 @@ err1:
 	return NULL;
 }
 
+/**
+ * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
+ * @hmux:		Pads for a hwmod
+ *
+ * Gets the wakeup status of given pad from omap-hwmod.
+ * Returns true if wakeup event is set for pad else false
+ * if wakeup is not occured or pads are not avialable.
+ */
+bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
+{
+	int i;
+	unsigned int val;
+	u8 ret = false;
+
+	for (i = 0; i < hmux->nr_pads; i++) {
+		struct omap_device_pad *pad = &hmux->pads[i];
+
+		if (pad->flags & OMAP_DEVICE_PAD_WAKEUP) {
+			val = omap_mux_read(pad->partition,
+					pad->mux->reg_offset);
+			if (val & OMAP_WAKEUP_EVENT) {
+				ret = true;
+				break;
+			}
+		}
+	}
+
+	return ret;
+}
+
 /* Assumes the calling function takes care of locking */
 void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
 {
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 2132308..8b2150a 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -225,8 +225,21 @@ omap_hwmod_mux_init(struct omap_device_pad *bpads, int nr_pads);
  */
 void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state);
 
+/**
+ * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
+ * @hmux:		Pads for a hwmod
+ *
+ * Called only from omap_hwmod.c, do not use.
+ */
+bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux);
 #else
 
+static inline bool
+omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
+{
+	return 0;
+}
+
 static inline int omap_mux_init_gpio(int gpio, int val)
 {
 	return 0;
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e751dd9..a8b24d7 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2724,3 +2724,10 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod *oh)
 
 	return 0;
 }
+
+int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh)
+{
+	if (oh && oh->mux)
+		return omap_hwmod_mux_get_wake_status(oh->mux);
+	return -EINVAL;
+}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 38ac4af..9c70cc8 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -606,6 +606,7 @@ u32 omap_hwmod_get_context_loss_count(struct omap_hwmod *oh);
 
 int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
 
+int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh);
 /*
  * Chip variant-specific hwmod init routines - XXX should be converted
  * to use initcalls once the initial boot ordering is straightened out
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
 

[PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod

[Tero Kristo]

This patch is temporary until Paul can provide a final version.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   56 ++++++++++++++++++++++++++++
 1 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..26ced4f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -161,6 +161,7 @@ static struct omap_hwmod omap3xxx_l3_main_hwmod = {
 };
 
 static struct omap_hwmod omap3xxx_l4_wkup_hwmod;
+static struct omap_hwmod omap3xxx_prm_hwmod;
 static struct omap_hwmod omap3xxx_uart1_hwmod;
 static struct omap_hwmod omap3xxx_uart2_hwmod;
 static struct omap_hwmod omap3xxx_uart3_hwmod;
@@ -478,6 +479,24 @@ static struct omap_hwmod omap3xxx_l4_per_hwmod = {
 	.flags		= HWMOD_NO_IDLEST,
 };
 
+static struct omap_hwmod_addr_space omap3xxx_prm_addrs[] = {
+	{
+		.pa_start	= 0x48306000,
+		.pa_end		= 0x48306000 + SZ_8K + SZ_4K - 1,
+		.flags		= ADDR_TYPE_RT
+	},
+	{}
+};
+
+/* L4_WKUP -> PRM interface */
+static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__prm = {
+	.master		= &omap3xxx_l4_wkup_hwmod,
+	.slave		= &omap3xxx_prm_hwmod,
+	.clk		= "wkup_l4_ick",
+	.addr		= omap3xxx_prm_addrs,
+	.user		= OCP_USER_MPU,
+};
+
 /* Slave interfaces on the L4_WKUP interconnect */
 static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_slaves[] = {
 	&omap3xxx_l4_core__l4_wkup,
@@ -493,6 +512,40 @@ static struct omap_hwmod omap3xxx_l4_wkup_hwmod = {
 	.flags		= HWMOD_NO_IDLEST,
 };
 
+/* Slave interfaces on the L4_WKUP interconnect */
+static struct omap_hwmod_ocp_if *omap3xxx_prm_slaves[] = {
+	&omap3xxx_l4_wkup__prm,
+};
+
+static struct omap_hwmod_class_sysconfig omap3xxx_prm_sysc = {
+	.rev_offs	= 0x0804,
+	.sysc_offs	= 0x0814,
+	.sysc_flags	= SYSC_HAS_AUTOIDLE,
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_prm_hwmod_class = {
+	.name		= "prm",
+	.sysc		= &omap3xxx_prm_sysc,
+};
+
+static struct omap_hwmod_irq_info omap3xxx_prm_irqs[] = {
+	{ .irq = 11 },
+	{ .irq = -1 }
+};
+
+/* PRM */
+static struct omap_hwmod omap3xxx_prm_hwmod = {
+	.name		= "prm3xxx",
+	.mpu_irqs	= omap3xxx_prm_irqs,
+	.class		= &omap3xxx_prm_hwmod_class,
+	.main_clk	= "wkup_32k_fck",
+	.slaves		= omap3xxx_prm_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap3xxx_prm_slaves),
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+	.flags		= HWMOD_NO_IDLEST,
+};
+
 /* Master interfaces on the MPU device */
 static struct omap_hwmod_ocp_if *omap3xxx_mpu_masters[] = {
 	&omap3xxx_mpu__l3_main,
@@ -3201,6 +3254,9 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
 	&omap3xxx_l4_core_hwmod,
 	&omap3xxx_l4_per_hwmod,
 	&omap3xxx_l4_wkup_hwmod,
+
+	&omap3xxx_prm_hwmod,
+
 	&omap3xxx_mmc1_hwmod,
 	&omap3xxx_mmc2_hwmod,
 	&omap3xxx_mmc3_hwmod,
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
 

[PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod

[Paul Walmsley]

Hi Tero

On Fri, 23 Sep 2011, Tero Kristo wrote:

> This patch is temporary until Paul can provide a final version.
> 
> Signed-off-by: Tero Kristo <t-kristo@ti.com>

Here's an updated version of this one.  The one change is that the hwmod's 
name is now "prm3xxx" to reflect that the register layout of this IP block 
is quite different from its OMAP2 predecessors and OMAP4 successors.  
This should avoid some of the special-purpose driver probing code.


- Paul

From: Paul Walmsley <paul@pwsan.com>
Date: Mon, 10 Oct 2011 13:11:11 -0600
Subject: [PATCH] OMAP3xxx: hwmod data: add PRM hwmod

Add a hwmod for the Power & Reset Management (PRM) IP block that is
present on OMAP3xxx SoCs.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   62 ++++++++++++++++++++++++++++
 1 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ab35acb..382fad9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -160,6 +160,7 @@ static struct omap_hwmod omap3xxx_l3_main_hwmod = {
 };
 
 static struct omap_hwmod omap3xxx_l4_wkup_hwmod;
+static struct omap_hwmod omap3xxx_prm_hwmod;
 static struct omap_hwmod omap3xxx_uart1_hwmod;
 static struct omap_hwmod omap3xxx_uart2_hwmod;
 static struct omap_hwmod omap3xxx_uart3_hwmod;
@@ -475,6 +476,29 @@ static struct omap_hwmod omap3xxx_l4_per_hwmod = {
 	.flags		= HWMOD_NO_IDLEST,
 };
 
+static struct omap_hwmod_addr_space omap3xxx_prm_addrs[] = {
+	{
+		.pa_start	= 0x48306000,
+		.pa_end		= 0x48306000 + SZ_8K + SZ_4K - 1,
+		.flags		= ADDR_TYPE_RT
+	},
+	{ }
+};
+
+/* L4_WKUP -> PRM interface */
+static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__prm = {
+	.master		= &omap3xxx_l4_wkup_hwmod,
+	.slave		= &omap3xxx_prm_hwmod,
+	.clk		= "wkup_l4_ick",
+	.addr		= omap3xxx_prm_addrs,
+	.user		= OCP_USER_MPU,
+};
+
+/* Master interfaces on the L4_WKUP interconnect */
+static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_masters[] = {
+	&omap3xxx_l4_wkup__prm,
+};
+
 /* Slave interfaces on the L4_WKUP interconnect */
 static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_slaves[] = {
 	&omap3xxx_l4_core__l4_wkup,
@@ -484,11 +508,46 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_slaves[] = {
 static struct omap_hwmod omap3xxx_l4_wkup_hwmod = {
 	.name		= "l4_wkup",
 	.class		= &l4_hwmod_class,
+	.masters	= omap3xxx_l4_wkup_masters,
+	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_wkup_masters),
 	.slaves		= omap3xxx_l4_wkup_slaves,
 	.slaves_cnt	= ARRAY_SIZE(omap3xxx_l4_wkup_slaves),
 	.flags		= HWMOD_NO_IDLEST,
 };
 
+/* Slave interfaces on the L4_WKUP interconnect */
+static struct omap_hwmod_ocp_if *omap3xxx_prm_slaves[] = {
+	&omap3xxx_l4_wkup__prm,
+};
+
+static struct omap_hwmod_class_sysconfig omap3xxx_prm_sysc = {
+	.rev_offs	= 0x0804,
+	.sysc_offs	= 0x0814,
+	.sysc_flags	= SYSC_HAS_AUTOIDLE,
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_prm_hwmod_class = {
+	.name		= "prm",
+	.sysc		= &omap3xxx_prm_sysc,
+};
+
+static struct omap_hwmod_irq_info omap3xxx_prm_irqs[] = {
+	{ .irq = 11 },
+	{ .irq = -1 }
+};
+
+/* PRM */
+static struct omap_hwmod omap3xxx_prm_hwmod = {
+	.name		= "prm3xxx",
+	.mpu_irqs	= omap3xxx_prm_irqs,
+	.class		= &omap3xxx_prm_hwmod_class,
+	.main_clk	= "wkup_32k_fck",
+	.slaves		= omap3xxx_prm_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap3xxx_prm_slaves),
+	.flags		= HWMOD_NO_IDLEST,
+};
+
 /* Master interfaces on the MPU device */
 static struct omap_hwmod_ocp_if *omap3xxx_mpu_masters[] = {
 	&omap3xxx_mpu__l3_main,
@@ -3128,6 +3187,9 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
 	&omap3xxx_l4_core_hwmod,
 	&omap3xxx_l4_per_hwmod,
 	&omap3xxx_l4_wkup_hwmod,
+
+	&omap3xxx_prm_hwmod,
+
 	&omap3xxx_mmc1_hwmod,
 	&omap3xxx_mmc2_hwmod,
 	&omap3xxx_mmc3_hwmod,
-- 
1.7.6.3

[PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod

[Cousson, Benoit]

Hi Paul,

On 10/10/2011 9:24 PM, Paul Walmsley wrote:
> Hi Tero
>
> On Fri, 23 Sep 2011, Tero Kristo wrote:
>
>> This patch is temporary until Paul can provide a final version.
>>
>> Signed-off-by: Tero Kristo<t-kristo@ti.com>
>
> Here's an updated version of this one.  The one change is that the hwmod's
> name is now "prm3xxx" to reflect that the register layout of this IP block
> is quite different from its OMAP2 predecessors and OMAP4 successors.
> This should avoid some of the special-purpose driver probing code.

This is not really aligned with the naming convention we've been using 
so far.
In both cases, the hwmod should just be named "prm". If a version 
information is needed, then it should be added in the revision class field.

It will make the device creation even simpler and not dependent of the 
SoC version.
I did not check the whole series, but I'm not sure we need a special 
treatment in the case of the prm.

Regards,
Benoit

>
>
> - Paul
>
> From: Paul Walmsley<paul@pwsan.com>
> Date: Mon, 10 Oct 2011 13:11:11 -0600
> Subject: [PATCH] OMAP3xxx: hwmod data: add PRM hwmod
>
> Add a hwmod for the Power&  Reset Management (PRM) IP block that is
> present on OMAP3xxx SoCs.
>
> Signed-off-by: Paul Walmsley<paul@pwsan.com>
> ---
>   arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   62 ++++++++++++++++++++++++++++
>   1 files changed, 62 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index ab35acb..382fad9 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -160,6 +160,7 @@ static struct omap_hwmod omap3xxx_l3_main_hwmod = {
>   };
>
>   static struct omap_hwmod omap3xxx_l4_wkup_hwmod;
> +static struct omap_hwmod omap3xxx_prm_hwmod;
>   static struct omap_hwmod omap3xxx_uart1_hwmod;
>   static struct omap_hwmod omap3xxx_uart2_hwmod;
>   static struct omap_hwmod omap3xxx_uart3_hwmod;
> @@ -475,6 +476,29 @@ static struct omap_hwmod omap3xxx_l4_per_hwmod = {
>   	.flags		= HWMOD_NO_IDLEST,
>   };
>
> +static struct omap_hwmod_addr_space omap3xxx_prm_addrs[] = {
> +	{
> +		.pa_start	= 0x48306000,
> +		.pa_end		= 0x48306000 + SZ_8K + SZ_4K - 1,
> +		.flags		= ADDR_TYPE_RT
> +	},
> +	{ }
> +};
> +
> +/* L4_WKUP ->  PRM interface */
> +static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__prm = {
> +	.master		=&omap3xxx_l4_wkup_hwmod,
> +	.slave		=&omap3xxx_prm_hwmod,
> +	.clk		= "wkup_l4_ick",
> +	.addr		= omap3xxx_prm_addrs,
> +	.user		= OCP_USER_MPU,
> +};
> +
> +/* Master interfaces on the L4_WKUP interconnect */
> +static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_masters[] = {
> +	&omap3xxx_l4_wkup__prm,
> +};
> +
>   /* Slave interfaces on the L4_WKUP interconnect */
>   static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_slaves[] = {
>   	&omap3xxx_l4_core__l4_wkup,
> @@ -484,11 +508,46 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_slaves[] = {
>   static struct omap_hwmod omap3xxx_l4_wkup_hwmod = {
>   	.name		= "l4_wkup",
>   	.class		=&l4_hwmod_class,
> +	.masters	= omap3xxx_l4_wkup_masters,
> +	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_wkup_masters),
>   	.slaves		= omap3xxx_l4_wkup_slaves,
>   	.slaves_cnt	= ARRAY_SIZE(omap3xxx_l4_wkup_slaves),
>   	.flags		= HWMOD_NO_IDLEST,
>   };
>
> +/* Slave interfaces on the L4_WKUP interconnect */
> +static struct omap_hwmod_ocp_if *omap3xxx_prm_slaves[] = {
> +	&omap3xxx_l4_wkup__prm,
> +};
> +
> +static struct omap_hwmod_class_sysconfig omap3xxx_prm_sysc = {
> +	.rev_offs	= 0x0804,
> +	.sysc_offs	= 0x0814,
> +	.sysc_flags	= SYSC_HAS_AUTOIDLE,
> +	.sysc_fields	=&omap_hwmod_sysc_type1,
> +};
> +
> +static struct omap_hwmod_class omap3xxx_prm_hwmod_class = {
> +	.name		= "prm",
> +	.sysc		=&omap3xxx_prm_sysc,
> +};
> +
> +static struct omap_hwmod_irq_info omap3xxx_prm_irqs[] = {
> +	{ .irq = 11 },
> +	{ .irq = -1 }
> +};
> +
> +/* PRM */
> +static struct omap_hwmod omap3xxx_prm_hwmod = {
> +	.name		= "prm3xxx",
> +	.mpu_irqs	= omap3xxx_prm_irqs,
> +	.class		=&omap3xxx_prm_hwmod_class,
> +	.main_clk	= "wkup_32k_fck",
> +	.slaves		= omap3xxx_prm_slaves,
> +	.slaves_cnt	= ARRAY_SIZE(omap3xxx_prm_slaves),
> +	.flags		= HWMOD_NO_IDLEST,
> +};
> +
>   /* Master interfaces on the MPU device */
>   static struct omap_hwmod_ocp_if *omap3xxx_mpu_masters[] = {
>   	&omap3xxx_mpu__l3_main,
> @@ -3128,6 +3187,9 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
>   	&omap3xxx_l4_core_hwmod,
>   	&omap3xxx_l4_per_hwmod,
>   	&omap3xxx_l4_wkup_hwmod,
> +
> +	&omap3xxx_prm_hwmod,
> +
>   	&omap3xxx_mmc1_hwmod,
>   	&omap3xxx_mmc2_hwmod,
>   	&omap3xxx_mmc3_hwmod,

[PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod

[Paul Walmsley]

On Mon, 10 Oct 2011, Cousson, Benoit wrote:

> Hi Paul,
> 
> On 10/10/2011 9:24 PM, Paul Walmsley wrote:
> > Hi Tero
> > 
> > On Fri, 23 Sep 2011, Tero Kristo wrote:
> > 
> > > This patch is temporary until Paul can provide a final version.
> > > 
> > > Signed-off-by: Tero Kristo<t-kristo@ti.com>
> > 
> > Here's an updated version of this one.  The one change is that the hwmod's
> > name is now "prm3xxx" to reflect that the register layout of this IP block
> > is quite different from its OMAP2 predecessors and OMAP4 successors.
> > This should avoid some of the special-purpose driver probing code.
> 
> This is not really aligned with the naming convention we've been using so far.
> In both cases, the hwmod should just be named "prm". If a version information
> is needed, then it should be added in the revision class field.
> 
> It will make the device creation even simpler and not dependent of the SoC
> version.
> I did not check the whole series, but I'm not sure we need a special treatment
> in the case of the prm.

OK, sounds like this needs more discussion, so will drop this patch from 
the pull request.


- Paul

[PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod

[Paul Walmsley]

Hi Beno?t

On Mon, 10 Oct 2011, Cousson, Benoit wrote:

> On 10/10/2011 9:24 PM, Paul Walmsley wrote:
> > On Fri, 23 Sep 2011, Tero Kristo wrote:
> > 
> > > This patch is temporary until Paul can provide a final version.
> > > 
> > > Signed-off-by: Tero Kristo<t-kristo@ti.com>
> > 
> > Here's an updated version of this one.  The one change is that the hwmod's
> > name is now "prm3xxx" to reflect that the register layout of this IP block
> > is quite different from its OMAP2 predecessors and OMAP4 successors.
> > This should avoid some of the special-purpose driver probing code.
> 
> This is not really aligned with the naming convention we've been using so far.
> In both cases, the hwmod should just be named "prm". If a version information
> is needed, then it should be added in the revision class field.
> 
> It will make the device creation even simpler and not dependent of the SoC
> version.

The problem in this case is that we should be using a completely different 
device driver for the PRM that's in the OMAP3 chips, from the driver used 
for OMAP2 or OMAP4 PRM blocks, due to the completely different register 
layout.  As far as I know, we haven't yet used the hwmod IP version to 
probe a different device driver when the version number changes.  There's 
no support for that in the current Linux platform* code, so we'd need 
special-purpose code for that.

In an ideal world, we'd have an omap_bus, etc., which would include an 
additional interface version number as part of its driver matching 
criteria.  Device drivers would then specify which interface version 
numbers they supported.  The device data would specify that interface 
version number should be matched.

But as it is right now in the current platform_device/platform_driver 
based system, we have only the name to match.  We could implement 
something where we concatenate the existing IP version number onto the 
hwmod name, and modify the device drivers to use that name.  But that 
seems like a lot of potential churn in light of a future DT and/or 
omap_bus migration.

So I'm proposing to use the IP version number field that's in the hwmod 
data to indicate evolutionary revisions of an IP block -- rather than 
revolutionary revisions that would require a new driver.  Then, since we 
use the hwmod name for driver matching, we'd use a different name for 
radically different IPs.

If it's the "3xxx" that you're objecting to in the name, we could call it 
"prm2" or "prmxyz" - the '3xxx' just seemed like the most logical 
approach.  The name of the hwmod class in the patch is still "prm", of 
course. 

Thoughts?

...

N.B., it's true that by waiting, this problem will presumably go away, 
with DT, in which the driver matching data would go into the 
"compatible" string in the DT.

But I guess it would be good to figure out a clean approach in the 
meantime.


- Paul

[PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod

[Cousson, Benoit]

On 10/10/2011 10:42 PM, Paul Walmsley wrote:
> Hi Beno?t
>
> On Mon, 10 Oct 2011, Cousson, Benoit wrote:
>
>> On 10/10/2011 9:24 PM, Paul Walmsley wrote:
>>> On Fri, 23 Sep 2011, Tero Kristo wrote:
>>>
>>>> This patch is temporary until Paul can provide a final version.
>>>>
>>>> Signed-off-by: Tero Kristo<t-kristo@ti.com>
>>>
>>> Here's an updated version of this one.  The one change is that the hwmod's
>>> name is now "prm3xxx" to reflect that the register layout of this IP block
>>> is quite different from its OMAP2 predecessors and OMAP4 successors.
>>> This should avoid some of the special-purpose driver probing code.
>>
>> This is not really aligned with the naming convention we've been using so far.
>> In both cases, the hwmod should just be named "prm". If a version information
>> is needed, then it should be added in the revision class field.
>>
>> It will make the device creation even simpler and not dependent of the SoC
>> version.
>
> The problem in this case is that we should be using a completely different
> device driver for the PRM that's in the OMAP3 chips, from the driver used
> for OMAP2 or OMAP4 PRM blocks, due to the completely different register
> layout.  As far as I know, we haven't yet used the hwmod IP version to
> probe a different device driver when the version number changes.  There's
> no support for that in the current Linux platform* code, so we'd need
> special-purpose code for that.
>
> In an ideal world, we'd have an omap_bus, etc., which would include an
> additional interface version number as part of its driver matching
> criteria.  Device drivers would then specify which interface version
> numbers they supported.  The device data would specify that interface
> version number should be matched.
>
> But as it is right now in the current platform_device/platform_driver
> based system, we have only the name to match.  We could implement
> something where we concatenate the existing IP version number onto the
> hwmod name, and modify the device drivers to use that name.  But that
> seems like a lot of potential churn in light of a future DT and/or
> omap_bus migration.
>
> So I'm proposing to use the IP version number field that's in the hwmod
> data to indicate evolutionary revisions of an IP block -- rather than
> revolutionary revisions that would require a new driver.  Then, since we
> use the hwmod name for driver matching, we'd use a different name for
> radically different IPs.
>
> If it's the "3xxx" that you're objecting to in the name, we could call it
> "prm2" or "prmxyz" - the '3xxx' just seemed like the most logical
> approach.  The name of the hwmod class in the patch is still "prm", of
> course.

Yes, but that's different, the number is supposed to represent the 
instance number in the IP naming convention. So prm2 != prmv2.

> Thoughts?

In fact the device name does not have to match the hwmod name. So we can 
just create an "omap2_prm" omap_device for OMAP2, "omap3_prm" 
omap_device for OMAP3...
That will allow the relevant PRM  driver to be bound to the proper device.

> N.B., it's true that by waiting, this problem will presumably go away,
> with DT, in which the driver matching data would go into the
> "compatible" string in the DT.

Yes, this will become indeed straightforward with DT.

We will just have something like:
prm {
	compatible = "prm-omap2";
	ti,hwmods = "prm";
}

> But I guess it would be good to figure out a clean approach in the
> meantime.

I guess the different device names should make that work in the meantime.

Regards,
Benoit

[PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod

[Paul Walmsley]

On Tue, 11 Oct 2011, Cousson, Benoit wrote:

> On 10/10/2011 10:42 PM, Paul Walmsley wrote:
>
> > If it's the "3xxx" that you're objecting to in the name, we could call it
> > "prm2" or "prmxyz" - the '3xxx' just seemed like the most logical
> > approach.  The name of the hwmod class in the patch is still "prm", of
> > course.
> 
> Yes, but that's different, the number is supposed to represent the instance
> number in the IP naming convention. So prm2 != prmv2.

Heh, that works as long as there's no "prmv" IP block ;-)

> > Thoughts?
> 
> In fact the device name does not have to match the hwmod name. So we can just
> create an "omap2_prm" omap_device for OMAP2, "omap3_prm" omap_device for
> OMAP3...
> That will allow the relevant PRM  driver to be bound to the proper device.

We can, we'd just need to add this extra mapping layer, so it doesn't 
become a nasty special-case hack for each IP block that this applies to.

Sounds like something for 3.3 (if ever...)


- Paul

[PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod

[Cousson, Benoit]

On 10/11/2011 12:35 AM, Paul Walmsley wrote:
> On Tue, 11 Oct 2011, Cousson, Benoit wrote:
>
>> On 10/10/2011 10:42 PM, Paul Walmsley wrote:
>>
>>> If it's the "3xxx" that you're objecting to in the name, we could call it
>>> "prm2" or "prmxyz" - the '3xxx' just seemed like the most logical
>>> approach.  The name of the hwmod class in the patch is still "prm", of
>>> course.
>>
>> Yes, but that's different, the number is supposed to represent the instance
>> number in the IP naming convention. So prm2 != prmv2.
>
> Heh, that works as long as there's no "prmv" IP block ;-)
>
>>> Thoughts?
>>
>> In fact the device name does not have to match the hwmod name. So we can just
>> create an "omap2_prm" omap_device for OMAP2, "omap3_prm" omap_device for
>> OMAP3...
>> That will allow the relevant PRM  driver to be bound to the proper device.
>
> We can, we'd just need to add this extra mapping layer, so it doesn't
> become a nasty special-case hack for each IP block that this applies to.
>
> Sounds like something for 3.3 (if ever...)

Yeah, since PRM and CM are critical pieces for the hwmod to DT 
migration, having them DT adapted for 3.3 will be very nice.

Benoit

[PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod

[Paul Walmsley]

On Tue, 11 Oct 2011, Cousson, Benoit wrote:

> In fact the device name does not have to match the hwmod name. So we can just
> create an "omap2_prm" omap_device for OMAP2, "omap3_prm" omap_device for
> OMAP3...
> That will allow the relevant PRM  driver to be bound to the proper device.

Incidentally, given that we would be using the hwmod name and the version 
number to determine the appropriate omap_device name, what IP version 
numbers should we assign to these PRM IP blocks for different SoCs?


- Paul

[PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod

[Cousson, Benoit]

On 10/11/2011 1:26 AM, Paul Walmsley wrote:
> On Tue, 11 Oct 2011, Cousson, Benoit wrote:
>
>> In fact the device name does not have to match the hwmod name. So we can just
>> create an "omap2_prm" omap_device for OMAP2, "omap3_prm" omap_device for
>> OMAP3...
>> That will allow the relevant PRM  driver to be bound to the proper device.
>
> Incidentally, given that we would be using the hwmod name and the version
> number to determine the appropriate omap_device name, what IP version
> numbers should we assign to these PRM IP blocks for different SoCs?

It can just be 1, 2 and 3... The idea is just to differentiate the IP 
for each OMAP.

Regards,
Benoit

[PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod

[Paul Walmsley]

On Wed, 12 Oct 2011, Cousson, Benoit wrote:

> On 10/11/2011 1:26 AM, Paul Walmsley wrote:
> > On Tue, 11 Oct 2011, Cousson, Benoit wrote:
> > 
> > > In fact the device name does not have to match the hwmod name. So we 
> > > can just create an "omap2_prm" omap_device for OMAP2, "omap3_prm" 
> > > omap_device for OMAP3... That will allow the relevant PRM driver to 
> > > be bound to the proper device.
> > 
> > Incidentally, given that we would be using the hwmod name and the version
> > number to determine the appropriate omap_device name, what IP version
> > numbers should we assign to these PRM IP blocks for different SoCs?
> 
> It can just be 1, 2 and 3... The idea is just to differentiate the IP for each
> OMAP.

So those are basically arbitrary?  Something is not clear here.

In the current hwmod design, IP blocks with different interfaces were 
intended to be uniquely identified by the hwmod name alone.  That is why 
omap_hwmod_lookup() only takes a 'name' parameter.

If I understand what you want to do, you wish to change this to uniquely 
identify them by a (name, interface version number) tuple.

I don't have a problem with this in theory, but it implies some changes to 
the existing model.  Specifically:

- we'll need to add an interface version number to the struct omap_hwmod

- we'll need to modify omap_hwmod_lookup() to take an interface version 
number

- the "ti,hwmod" DT binding that you proposed earlier will need to include 
an interface version number


- Paul

[PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod

[Paul Walmsley]

On Thu, 13 Oct 2011, Paul Walmsley wrote:

> On Wed, 12 Oct 2011, Cousson, Benoit wrote:
> 
> > On 10/11/2011 1:26 AM, Paul Walmsley wrote:
> > > On Tue, 11 Oct 2011, Cousson, Benoit wrote:
> > > 
> > > > In fact the device name does not have to match the hwmod name. So we 
> > > > can just create an "omap2_prm" omap_device for OMAP2, "omap3_prm" 
> > > > omap_device for OMAP3... That will allow the relevant PRM driver to 
> > > > be bound to the proper device.
> > > 
> > > Incidentally, given that we would be using the hwmod name and the version
> > > number to determine the appropriate omap_device name, what IP version
> > > numbers should we assign to these PRM IP blocks for different SoCs?
> > 
> > It can just be 1, 2 and 3... The idea is just to differentiate the IP for each
> > OMAP.
> 
> So those are basically arbitrary?  Something is not clear here.
> 
> In the current hwmod design, IP blocks with different interfaces were 
> intended to be uniquely identified by the hwmod name alone.  That is why 
> omap_hwmod_lookup() only takes a 'name' parameter.
> 
> If I understand what you want to do, you wish to change this to uniquely 
> identify them by a (name, interface version number) tuple.
> 
> I don't have a problem with this in theory, but it implies some changes to 
> the existing model.  Specifically:
> 
> - we'll need to add an interface version number to the struct omap_hwmod
> 
> - we'll need to modify omap_hwmod_lookup() to take an interface version 
> number
> 
> - the "ti,hwmod" DT binding that you proposed earlier will need to include 
> an interface version number

Hmm, reflecting on this further, is your intention to bind drivers to 
hwmods by the struct omap_hwmod_class instead?

If we define that "rev" field as the interface version number, that should 
probably work.

So then in C struct format, in a platform_device system, the mapping table 
would basically become

struct omap_hwmod_driver_map {
	const char *class_name;
	const u32 class_rev;
	const char *platform_device_name;
}

- Paul

[PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod

[Cousson, Benoit]

On 10/13/2011 6:51 PM, Paul Walmsley wrote:
> On Thu, 13 Oct 2011, Paul Walmsley wrote:
>
>> On Wed, 12 Oct 2011, Cousson, Benoit wrote:
>>
>>> On 10/11/2011 1:26 AM, Paul Walmsley wrote:
>>>> On Tue, 11 Oct 2011, Cousson, Benoit wrote:
>>>>
>>>>> In fact the device name does not have to match the hwmod name. So we
>>>>> can just create an "omap2_prm" omap_device for OMAP2, "omap3_prm"
>>>>> omap_device for OMAP3... That will allow the relevant PRM driver to
>>>>> be bound to the proper device.
>>>>
>>>> Incidentally, given that we would be using the hwmod name and the version
>>>> number to determine the appropriate omap_device name, what IP version
>>>> numbers should we assign to these PRM IP blocks for different SoCs?
>>>
>>> It can just be 1, 2 and 3... The idea is just to differentiate the IP for each
>>> OMAP.
>>
>> So those are basically arbitrary?  Something is not clear here.
>>
>> In the current hwmod design, IP blocks with different interfaces were
>> intended to be uniquely identified by the hwmod name alone.  That is why
>> omap_hwmod_lookup() only takes a 'name' parameter.
>>
>> If I understand what you want to do, you wish to change this to uniquely
>> identify them by a (name, interface version number) tuple.
>>
>> I don't have a problem with this in theory, but it implies some changes to
>> the existing model.  Specifically:
>>
>> - we'll need to add an interface version number to the struct omap_hwmod
>>
>> - we'll need to modify omap_hwmod_lookup() to take an interface version
>> number
>>
>> - the "ti,hwmod" DT binding that you proposed earlier will need to include
>> an interface version number
>
> Hmm, reflecting on this further, is your intention to bind drivers to
> hwmods by the struct omap_hwmod_class instead?

Well, somehow, the class was added for that purpose, to allow one timer 
driver to bind to 2 different hwmods. But in that case the device name 
was the same.

> If we define that "rev" field as the interface version number, that should
> probably work.
>
> So then in C struct format, in a platform_device system, the mapping table
> would basically become
>
> struct omap_hwmod_driver_map {
> 	const char *class_name;
> 	const u32 class_rev;
> 	const char *platform_device_name;
> }

This is needed if and only if you want to have a different driver for 
the same IP.

In the case of the timer, we do have only one device name and one driver:
class=timer, rev=1, device=omap_timer
class=timer, rev=2, device=omap_timer

Regards,
Benoit

[PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod

[Tero Kristo]

On Thu, 2011-10-20 at 16:51 +0200, Cousson, Benoit wrote:
> On 10/13/2011 6:51 PM, Paul Walmsley wrote:
> > On Thu, 13 Oct 2011, Paul Walmsley wrote:
> >
> >> On Wed, 12 Oct 2011, Cousson, Benoit wrote:
> >>
> >>> On 10/11/2011 1:26 AM, Paul Walmsley wrote:
> >>>> On Tue, 11 Oct 2011, Cousson, Benoit wrote:
> >>>>
> >>>>> In fact the device name does not have to match the hwmod name. So we
> >>>>> can just create an "omap2_prm" omap_device for OMAP2, "omap3_prm"
> >>>>> omap_device for OMAP3... That will allow the relevant PRM driver to
> >>>>> be bound to the proper device.
> >>>>
> >>>> Incidentally, given that we would be using the hwmod name and the version
> >>>> number to determine the appropriate omap_device name, what IP version
> >>>> numbers should we assign to these PRM IP blocks for different SoCs?
> >>>
> >>> It can just be 1, 2 and 3... The idea is just to differentiate the IP for each
> >>> OMAP.
> >>
> >> So those are basically arbitrary?  Something is not clear here.
> >>
> >> In the current hwmod design, IP blocks with different interfaces were
> >> intended to be uniquely identified by the hwmod name alone.  That is why
> >> omap_hwmod_lookup() only takes a 'name' parameter.
> >>
> >> If I understand what you want to do, you wish to change this to uniquely
> >> identify them by a (name, interface version number) tuple.
> >>
> >> I don't have a problem with this in theory, but it implies some changes to
> >> the existing model.  Specifically:
> >>
> >> - we'll need to add an interface version number to the struct omap_hwmod
> >>
> >> - we'll need to modify omap_hwmod_lookup() to take an interface version
> >> number
> >>
> >> - the "ti,hwmod" DT binding that you proposed earlier will need to include
> >> an interface version number
> >
> > Hmm, reflecting on this further, is your intention to bind drivers to
> > hwmods by the struct omap_hwmod_class instead?
> 
> Well, somehow, the class was added for that purpose, to allow one timer 
> driver to bind to 2 different hwmods. But in that case the device name 
> was the same.
> 
> > If we define that "rev" field as the interface version number, that should
> > probably work.
> >
> > So then in C struct format, in a platform_device system, the mapping table
> > would basically become
> >
> > struct omap_hwmod_driver_map {
> > 	const char *class_name;
> > 	const u32 class_rev;
> > 	const char *platform_device_name;
> > }
> 
> This is needed if and only if you want to have a different driver for 
> the same IP.
> 
> In the case of the timer, we do have only one device name and one driver:
> class=timer, rev=1, device=omap_timer
> class=timer, rev=2, device=omap_timer
> 
> Regards,
> Benoit

Currently the delta between the different versions of the driver are so
minimal that it is easy to cope both omap3 and omap4 PRM with the same
driver; however it might be beneficial in the future to split it up. The
detection logic I made into devices.c file can easily be changed to suit
whatever need. It does not really matter whether there is a different
name for the hwmod or not, it is probably easier implementation wise if
the hwmod name is same, but only some field within e.g. class changes.

-Tero


Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business ID: 0115040-6. Domicile: Helsinki
 

[PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod

[Cousson, Benoit]

Hi Paul,

Sorry, I kind of forgot to answer that email.

On 10/13/2011 6:38 PM, Paul Walmsley wrote:
> On Wed, 12 Oct 2011, Cousson, Benoit wrote:
>
>> On 10/11/2011 1:26 AM, Paul Walmsley wrote:
>>> On Tue, 11 Oct 2011, Cousson, Benoit wrote:
>>>
>>>> In fact the device name does not have to match the hwmod name. So we
>>>> can just create an "omap2_prm" omap_device for OMAP2, "omap3_prm"
>>>> omap_device for OMAP3... That will allow the relevant PRM driver to
>>>> be bound to the proper device.
>>>
>>> Incidentally, given that we would be using the hwmod name and the version
>>> number to determine the appropriate omap_device name, what IP version
>>> numbers should we assign to these PRM IP blocks for different SoCs?
>>
>> It can just be 1, 2 and 3... The idea is just to differentiate the IP for each
>> OMAP.
>
> So those are basically arbitrary?  Something is not clear here.

Yeah, for me too, I think I did not get your concern...

> In the current hwmod design, IP blocks with different interfaces were
> intended to be uniquely identified by the hwmod name alone.  That is why
> omap_hwmod_lookup() only takes a 'name' parameter.
>
> If I understand what you want to do, you wish to change this to uniquely
> identify them by a (name, interface version number) tuple.

No, not for the same OMAP. The version is different for different OMAP 
version. So far the only IP with 2 different hwmod name for the same 
functionality is the timer. We have timer and timer_1ms, and that's for 
that kind of IP that we introduced the class to still be able to 
identify the functionality for the driver.

> I don't have a problem with this in theory, but it implies some changes to
> the existing model.  Specifically:
>
> - we'll need to add an interface version number to the struct omap_hwmod
>
> - we'll need to modify omap_hwmod_lookup() to take an interface version
> number
>
> - the "ti,hwmod" DT binding that you proposed earlier will need to include
> an interface version number

I still do not understand why we need that for the PRM.
AFAIK, we do have only one version of the PRM at the time. It is not 
similar to the timer case.

I'm still a little bit confused by your usecase.

You have only one PRM instance per OMAP. So you just have to do 
omap_hwmod_lookup("prm") to retrieve the relevant hwmod for the SoC.

If you need to build a different device per SoC to allow different 
driver to be bound to it, you can just append the version number to the 
hwmod name to build the device name.

Am I still missing something?

Regards,
Benoit

[PATCHv9 04/18] TEMP: OMAP4xxx: hwmod data: add PRM hwmod

[Tero Kristo]

This patch is temporary until Benoit can provide final version.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   65 ++++++++++++++++++++++++++++
 1 files changed, 65 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6201422..c09bf4d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -3990,6 +3990,68 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
 	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
 };
 
+ /*
+ * 'prm' class
+ * power and reset manager (part of the prcm infrastructure)
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_prm_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_flags	= 0,
+};
+
+static struct omap_hwmod_class omap44xx_prm_hwmod_class = {
+	.name	= "prm",
+	.sysc	= &omap44xx_prm_sysc,
+};
+
+/* prm */
+static struct omap_hwmod omap44xx_prm_hwmod;
+static struct omap_hwmod_irq_info omap44xx_prm_irqs[] = {
+	{ .irq = 11 + OMAP44XX_IRQ_GIC_START },
+	{ .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap44xx_prm_resets[] = {
+	{ .name = "rst_global_warm_sw", .rst_shift = 0 },
+	{ .name = "rst_global_cold_sw", .rst_shift = 1 },
+};
+
+static struct omap_hwmod_addr_space omap44xx_prm_addrs[] = {
+	{
+		.pa_start       = 0x4a306000,
+		.pa_end         = 0x4a307fff,
+		.flags          = ADDR_TYPE_RT
+	},
+	{ }
+};
+
+/* l4_wkup -> prm */
+static struct omap_hwmod_ocp_if omap44xx_l4_wkup__prm = {
+	.master		= &omap44xx_l4_wkup_hwmod,
+	.slave		= &omap44xx_prm_hwmod,
+	.clk		= "l4_wkup_clk_mux_ck",
+	.addr		= omap44xx_prm_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* prm slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_prm_slaves[] = {
+	&omap44xx_l4_wkup__prm,
+};
+
+static struct omap_hwmod omap44xx_prm_hwmod = {
+	.name		= "prm4xxx",
+	.class		= &omap44xx_prm_hwmod_class,
+	.mpu_irqs	= omap44xx_prm_irqs,
+	.clkdm_name	= "l4_wkup_clkdm",
+	.rst_lines	= omap44xx_prm_resets,
+	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_prm_resets),
+	.slaves		= omap44xx_prm_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap44xx_prm_slaves),
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
 /*
  * 'smartreflex' class
  * smartreflex module (monitor silicon performance and outputs a measure of
@@ -5448,6 +5510,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
 	/* mpu class */
 	&omap44xx_mpu_hwmod,
 
+	/* prm class */
+	&omap44xx_prm_hwmod,
+
 	/* smartreflex class */
 	&omap44xx_smartreflex_core_hwmod,
 	&omap44xx_smartreflex_iva_hwmod,
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
 

[PATCHv9 05/18] mfd: omap-prm: add driver skeleton

[Tero Kristo]

This driver will eventually support OMAP soc PRM module features, e.g. PRCM
chain interrupts and voltage processor / controller. This patch only adds
basic skeleton for the driver that can be probed for omap3 and omap4.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
---
 drivers/mfd/Kconfig           |    7 +++++
 drivers/mfd/Makefile          |    2 +
 drivers/mfd/omap-prm-common.c |   24 ++++++++++++++++
 drivers/mfd/omap3xxx-prm.c    |   60 +++++++++++++++++++++++++++++++++++++++++
 drivers/mfd/omap4xxx-prm.c    |   60 +++++++++++++++++++++++++++++++++++++++++
 include/linux/mfd/omap-prm.h  |   24 ++++++++++++++++
 6 files changed, 177 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mfd/omap-prm-common.c
 create mode 100644 drivers/mfd/omap3xxx-prm.c
 create mode 100644 drivers/mfd/omap4xxx-prm.c
 create mode 100644 include/linux/mfd/omap-prm.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 21574bd..1ae2571 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -770,6 +770,13 @@ config MFD_AAT2870_CORE
 	  additional drivers must be enabled in order to use the
 	  functionality of the device.
 
+config OMAP_PRM
+	bool "OMAP Power and Reset Management driver"
+	depends on (ARCH_OMAP) && PM
+	help
+	  Say Y to enable support for the OMAP Power and Reset Management
+	  driver.
+
 endif # MFD_SUPPORT
 
 menu "Multimedia Capabilities Port drivers"
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index c580203..503d85d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -102,3 +102,5 @@ obj-$(CONFIG_MFD_PM8921_CORE) 	+= pm8921-core.o
 obj-$(CONFIG_MFD_PM8XXX_IRQ) 	+= pm8xxx-irq.o
 obj-$(CONFIG_TPS65911_COMPARATOR)	+= tps65911-comparator.o
 obj-$(CONFIG_MFD_AAT2870_CORE)	+= aat2870-core.o
+obj-$(CONFIG_OMAP_PRM)		+= omap-prm-common.o omap3xxx-prm.o \
+				   omap4xxx-prm.o
diff --git a/drivers/mfd/omap-prm-common.c b/drivers/mfd/omap-prm-common.c
new file mode 100644
index 0000000..39b199c8
--- /dev/null
+++ b/drivers/mfd/omap-prm-common.c
@@ -0,0 +1,24 @@
+/*
+ * OMAP Power and Reset Management (PRM) driver common functionality
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ *
+ * Author: Tero Kristo <t-kristo@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/ctype.h>
+#include <linux/module.h>
+#include <linux/io.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/err.h>
+
+MODULE_AUTHOR("Tero Kristo <t-kristo@ti.com>");
+MODULE_DESCRIPTION("OMAP PRM core driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/mfd/omap3xxx-prm.c b/drivers/mfd/omap3xxx-prm.c
new file mode 100644
index 0000000..177aced
--- /dev/null
+++ b/drivers/mfd/omap3xxx-prm.c
@@ -0,0 +1,60 @@
+/*
+ * OMAP Power and Reset Management (PRM) driver for OMAP3xxx
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ *
+ * Author: Tero Kristo <t-kristo@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/ctype.h>
+#include <linux/module.h>
+#include <linux/io.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/err.h>
+#include <linux/platform_device.h>
+#include <linux/mfd/omap-prm.h>
+
+#define DRIVER_NAME "prm3xxx"
+
+static int __devinit omap3xxx_prm_probe(struct platform_device *pdev)
+{
+	return 0;
+}
+
+static int __devexit omap3xxx_prm_remove(struct platform_device *pdev)
+{
+	return 0;
+}
+
+static struct platform_driver omap3xxx_prm_driver = {
+	.probe		= omap3xxx_prm_probe,
+	.remove		= __devexit_p(omap3xxx_prm_remove),
+	.driver		= {
+		.owner	= THIS_MODULE,
+		.name	= DRIVER_NAME,
+	},
+};
+
+static int __init omap3xxx_prm_init(void)
+{
+	return platform_driver_register(&omap3xxx_prm_driver);
+}
+module_init(omap3xxx_prm_init);
+
+static void __exit omap3xxx_prm_exit(void)
+{
+	platform_driver_unregister(&omap3xxx_prm_driver);
+}
+module_exit(omap3xxx_prm_exit);
+
+MODULE_ALIAS("platform:"DRIVER_NAME);
+MODULE_AUTHOR("Tero Kristo <t-kristo@ti.com>");
+MODULE_DESCRIPTION("OMAP3xxx PRM driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/mfd/omap4xxx-prm.c b/drivers/mfd/omap4xxx-prm.c
new file mode 100644
index 0000000..9de8f3e
--- /dev/null
+++ b/drivers/mfd/omap4xxx-prm.c
@@ -0,0 +1,60 @@
+/*
+ * OMAP Power and Reset Management (PRM) driver for OMAP4xxx
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ *
+ * Author: Tero Kristo <t-kristo@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/ctype.h>
+#include <linux/module.h>
+#include <linux/io.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/err.h>
+#include <linux/platform_device.h>
+#include <linux/mfd/omap-prm.h>
+
+#define DRIVER_NAME "prm4xxx"
+
+static int __devinit omap4xxx_prm_probe(struct platform_device *pdev)
+{
+	return 0;
+}
+
+static int __devexit omap4xxx_prm_remove(struct platform_device *pdev)
+{
+	return 0;
+}
+
+static struct platform_driver omap4xxx_prm_driver = {
+	.probe		= omap4xxx_prm_probe,
+	.remove		= __devexit_p(omap4xxx_prm_remove),
+	.driver		= {
+		.owner	= THIS_MODULE,
+		.name	= DRIVER_NAME,
+	},
+};
+
+static int __init omap4xxx_prm_init(void)
+{
+	return platform_driver_register(&omap4xxx_prm_driver);
+}
+module_init(omap4xxx_prm_init);
+
+static void __exit omap4xxx_prm_exit(void)
+{
+	platform_driver_unregister(&omap4xxx_prm_driver);
+}
+module_exit(omap4xxx_prm_exit);
+
+MODULE_ALIAS("platform:"DRIVER_NAME);
+MODULE_AUTHOR("Tero Kristo <t-kristo@ti.com>");
+MODULE_DESCRIPTION("OMAP4xxx PRM driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/omap-prm.h b/include/linux/mfd/omap-prm.h
new file mode 100644
index 0000000..ddc814e
--- /dev/null
+++ b/include/linux/mfd/omap-prm.h
@@ -0,0 +1,28 @@
+/*
+ * OMAP Power and Reset Management (PRM) driver
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ *
+ * Author: Tero Kristo <t-kristo@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __LINUX_MFD_OMAP_PRM_H__
+#define __LINUX_MFD_OMAP_PRM_H__
+
+#ifdef CONFIG_OMAP_PRM
+int omap_prcm_event_to_irq(const char *name);
+#else
+static inline int omap_prcm_event_to_irq(const char *name) { return -ENOENT; }
+#endif
+
+struct omap_prm_platform_config {
+	int irq;
+	void __iomem *base;
+};
+
+#endif
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
 

[PATCHv9 05/18] mfd: omap-prm: add driver skeleton

[Kevin Hilman]

On 09/23/2011 05:46 AM, Tero Kristo wrote:
> This driver will eventually support OMAP soc PRM module features, e.g. PRCM
> chain interrupts and voltage processor / controller. This patch only adds
> basic skeleton for the driver that can be probed for omap3 and omap4.
> 
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Samuel Ortiz <sameo@linux.intel.com>

> +config OMAP_PRM
> +	bool "OMAP Power and Reset Management driver"
> +	depends on (ARCH_OMAP) && PM

Minor: this should probably be

	default ARCH_OMAP && PM

So it's enabled by default whenever a PM kernel is built for OMAP.

Kevin

[PATCHv9 06/18] mfd: omap-prm: added chain interrupt handler

[Tero Kristo]

Introduce a chained interrupt handler mechanism for the PRCM
interrupt, so that individual PRCM event can cleanly be handled by
handlers in separate drivers. We do this by introducing PRCM event
names, which are then matched to the particular PRCM interrupt bit
depending on the specific OMAP SoC being used.

PRCM interrupts have two priority levels, high or normal. High priority
is needed for IO event handling, so that we can be sure that IO events
are processed before other events. This reduces latency for IO event
customers and also prevents incorrect ack sequence on OMAP3.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Avinash.H.M <avinashhm@ti.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Govindraj.R <govindraj.raja@ti.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
---
 drivers/mfd/omap-prm-common.c |  239 +++++++++++++++++++++++++++++++++++++++++
 drivers/mfd/omap-prm.h        |   40 +++++++
 drivers/mfd/omap3xxx-prm.c    |   29 +++++-
 drivers/mfd/omap4xxx-prm.c    |   28 +++++-
 4 files changed, 334 insertions(+), 2 deletions(-)
 create mode 100644 drivers/mfd/omap-prm.h

diff --git a/drivers/mfd/omap-prm-common.c b/drivers/mfd/omap-prm-common.c
index 39b199c8..2886eb2 100644
--- a/drivers/mfd/omap-prm-common.c
+++ b/drivers/mfd/omap-prm-common.c
@@ -15,10 +15,249 @@
 #include <linux/ctype.h>
 #include <linux/module.h>
 #include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/interrupt.h>
 #include <linux/slab.h>
 #include <linux/init.h>
 #include <linux/err.h>
 
+#include "omap-prm.h"
+
+#define OMAP_PRCM_MAX_NR_PENDING_REG 2
+
+struct omap_prm_device {
+	const struct omap_prcm_irq_setup *irq_setup;
+	const struct omap_prcm_irq *irqs;
+	struct irq_chip_generic **irq_chips;
+	int nr_irqs;
+	u32 *saved_mask;
+	u32 *priority_mask;
+	int base_irq;
+	int irq;
+	void __iomem *base;
+};
+
+static struct omap_prm_device prm_dev;
+
+static inline u32 prm_read_reg(int offset)
+{
+	return __raw_readl(prm_dev.base + offset);
+}
+
+static inline void prm_write_reg(u32 value, int offset)
+{
+	__raw_writel(value, prm_dev.base + offset);
+}
+
+static void prm_pending_events(unsigned long *events)
+{
+	u32 mask, st;
+	int i;
+
+	memset(events, 0, prm_dev.irq_setup->nr_regs * sizeof(unsigned long));
+
+	for (i = 0; i < prm_dev.irq_setup->nr_regs; i++) {
+		mask = prm_read_reg(prm_dev.irq_setup->mask + i * 4);
+		st = prm_read_reg(prm_dev.irq_setup->ack + i * 4);
+		events[i] = mask & st;
+	}
+}
+
+/*
+ * Move priority events from events to priority_events array
+ */
+static void prm_events_filter_priority(unsigned long *events,
+	unsigned long *priority_events)
+{
+	int i;
+
+	for (i = 0; i < prm_dev.irq_setup->nr_regs; i++) {
+		priority_events[i] = events[i] & prm_dev.priority_mask[i];
+		events[i] ^= priority_events[i];
+	}
+}
+
+/*
+ * PRCM Interrupt Handler
+ *
+ * This is a common handler for the OMAP PRCM interrupts. Pending
+ * interrupts are detected by a call to prm_pending_events and
+ * dispatched accordingly. Clearing of the wakeup events should be
+ * done by the SoC specific individual handlers.
+ */
+static void prcm_irq_handler(unsigned int irq, struct irq_desc *desc)
+{
+	unsigned long pending[OMAP_PRCM_MAX_NR_PENDING_REG];
+	unsigned long priority_pending[OMAP_PRCM_MAX_NR_PENDING_REG];
+	struct irq_chip *chip = irq_desc_get_chip(desc);
+	unsigned int virtirq;
+	int nr_irqs = prm_dev.irq_setup->nr_regs * 32;
+
+	/*
+	 * Loop until all pending irqs are handled, since
+	 * generic_handle_irq() can cause new irqs to come
+	 */
+	while (1) {
+		prm_pending_events(pending);
+
+		/* No bit set, then all IRQs are handled */
+		if (find_first_bit(pending, nr_irqs) >= nr_irqs)
+			break;
+
+		prm_events_filter_priority(pending, priority_pending);
+
+		/*
+		 * Loop on all currently pending irqs so that new irqs
+		 * cannot starve previously pending irqs
+		 */
+
+		/* Serve priority events first */
+		for_each_set_bit(virtirq, priority_pending, nr_irqs)
+			generic_handle_irq(prm_dev.base_irq + virtirq);
+
+		/* Serve normal events next */
+		for_each_set_bit(virtirq, pending, nr_irqs)
+			generic_handle_irq(prm_dev.base_irq + virtirq);
+	}
+	if (chip->irq_ack)
+		chip->irq_ack(&desc->irq_data);
+	if (chip->irq_eoi)
+		chip->irq_eoi(&desc->irq_data);
+	chip->irq_unmask(&desc->irq_data);
+}
+
+/*
+ * Given a PRCM event name, returns the corresponding IRQ on which the
+ * handler should be registered.
+ */
+int omap_prcm_event_to_irq(const char *name)
+{
+	int i;
+
+	for (i = 0; i < prm_dev.nr_irqs; i++)
+		if (!strcmp(prm_dev.irqs[i].name, name))
+			return prm_dev.base_irq + prm_dev.irqs[i].offset;
+
+	return -ENOENT;
+}
+
+/*
+ * Reverses memory allocated and other steps done by
+ * omap_prcm_register_chain_handler
+ */
+void omap_prcm_irq_cleanup(void)
+{
+	int i;
+
+	if (prm_dev.irq_chips) {
+		for (i = 0; i < prm_dev.irq_setup->nr_regs; i++) {
+			if (prm_dev.irq_chips[i])
+				irq_remove_generic_chip(prm_dev.irq_chips[i],
+					0xffffffff, 0, 0);
+			prm_dev.irq_chips[i] = NULL;
+		}
+		kfree(prm_dev.irq_chips);
+		prm_dev.irq_chips = NULL;
+	}
+
+	kfree(prm_dev.saved_mask);
+	prm_dev.saved_mask = NULL;
+
+	kfree(prm_dev.priority_mask);
+	prm_dev.priority_mask = NULL;
+
+	irq_set_chained_handler(prm_dev.irq, NULL);
+
+	if (prm_dev.base_irq > 0)
+		irq_free_descs(prm_dev.base_irq,
+			prm_dev.irq_setup->nr_regs * 32);
+	prm_dev.base_irq = 0;
+}
+
+/*
+ * Initializes the prcm chain handler based on provided parameters.
+ */
+int omap_prcm_register_chain_handler(int irq, void __iomem *base,
+	const struct omap_prcm_irq_setup *irq_setup,
+	const struct omap_prcm_irq *irqs, int nr_irqs)
+{
+	int nr_regs = irq_setup->nr_regs;
+	u32 mask[OMAP_PRCM_MAX_NR_PENDING_REG];
+	int offset;
+	int max_irq = 0;
+	int i;
+	struct irq_chip_generic *gc;
+	struct irq_chip_type *ct;
+
+	if (nr_regs > OMAP_PRCM_MAX_NR_PENDING_REG) {
+		pr_err("PRCM: nr_regs too large\n");
+		goto err;
+	}
+
+	prm_dev.irq_setup = irq_setup;
+	prm_dev.irqs = irqs;
+	prm_dev.nr_irqs = nr_irqs;
+	prm_dev.irq = irq;
+	prm_dev.base = base;
+
+	prm_dev.irq_chips = kzalloc(sizeof(void *) * nr_regs, GFP_KERNEL);
+	prm_dev.saved_mask = kzalloc(sizeof(u32) * nr_regs, GFP_KERNEL);
+	prm_dev.priority_mask = kzalloc(sizeof(u32) * nr_regs, GFP_KERNEL);
+
+	if (!prm_dev.irq_chips || !prm_dev.saved_mask ||
+	    !prm_dev.priority_mask) {
+		pr_err("PRCM: kzalloc failed\n");
+		goto err;
+	}
+
+	memset(mask, 0, sizeof(mask));
+
+	for (i = 0; i < nr_irqs; i++) {
+		offset = irqs[i].offset;
+		mask[offset >> 5] |= 1 << (offset & 0x1f);
+		if (offset > max_irq)
+			max_irq = offset;
+		if (irqs[i].priority)
+			prm_dev.priority_mask[offset >> 5] |=
+				1 << (offset & 0x1f);
+	}
+
+	irq_set_chained_handler(prm_dev.irq, prcm_irq_handler);
+
+	prm_dev.base_irq = irq_alloc_descs(-1, 0, irq_setup->nr_regs * 32, 0);
+
+	if (prm_dev.base_irq < 0) {
+		pr_err("PRCM: failed to allocate irq descs\n");
+		goto err;
+	}
+
+	for (i = 0; i <= irq_setup->nr_regs; i++) {
+		gc = irq_alloc_generic_chip("PRCM", 1,
+			prm_dev.base_irq + i * 32, base, handle_level_irq);
+
+		if (!gc) {
+			pr_err("PRCM: failed to allocate generic chip\n");
+			goto err;
+		}
+		ct = gc->chip_types;
+		ct->chip.irq_ack = irq_gc_ack_set_bit;
+		ct->chip.irq_mask = irq_gc_mask_clr_bit;
+		ct->chip.irq_unmask = irq_gc_mask_set_bit;
+
+		ct->regs.ack = irq_setup->ack + i * 4;
+		ct->regs.mask = irq_setup->mask + i * 4;
+
+		irq_setup_generic_chip(gc, mask[i], 0, IRQ_NOREQUEST, 0);
+		prm_dev.irq_chips[i] = gc;
+	}
+
+	return 0;
+
+err:
+	omap_prcm_irq_cleanup();
+	return -ENOMEM;
+}
+
 MODULE_AUTHOR("Tero Kristo <t-kristo@ti.com>");
 MODULE_DESCRIPTION("OMAP PRM core driver");
 MODULE_LICENSE("GPL");
diff --git a/drivers/mfd/omap-prm.h b/drivers/mfd/omap-prm.h
new file mode 100644
index 0000000..7ffefe1
--- /dev/null
+++ b/drivers/mfd/omap-prm.h
@@ -0,0 +1,40 @@
+/*
+ * OMAP Power and Reset Management (PRM) driver common definitions
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ *
+ * Author: Tero Kristo <t-kristo@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __DRIVERS_MFD_OMAP_PRM_H__
+#define __DRIVERS_MFD_OMAP_PRM_H__
+
+struct omap_prcm_irq_setup {
+	u32 ack;
+	u32 mask;
+	int nr_regs;
+};
+
+struct omap_prcm_irq {
+	const char *name;
+	unsigned int offset;
+	bool priority;
+};
+
+#define OMAP_PRCM_IRQ(_name, _offset, _priority) {	\
+	.name = _name,					\
+	.offset = _offset,				\
+	.priority = _priority				\
+	}
+
+void omap_prcm_irq_cleanup(void);
+int omap_prcm_register_chain_handler(int irq, void __iomem *base,
+	const struct omap_prcm_irq_setup *irq_setup,
+	const struct omap_prcm_irq *irqs, int nr_irqs);
+
+#endif
diff --git a/drivers/mfd/omap3xxx-prm.c b/drivers/mfd/omap3xxx-prm.c
index 177aced..9be21ee 100644
--- a/drivers/mfd/omap3xxx-prm.c
+++ b/drivers/mfd/omap3xxx-prm.c
@@ -21,11 +21,38 @@
 #include <linux/platform_device.h>
 #include <linux/mfd/omap-prm.h>
 
+#include "omap-prm.h"
+
 #define DRIVER_NAME "prm3xxx"
 
+#define OMAP3_PRM_IRQSTATUS_OFFSET	0x818
+#define OMAP3_PRM_IRQENABLE_OFFSET	0x81c
+
+static const struct omap_prcm_irq_setup omap3_prcm_irq_setup = {
+	.ack		= OMAP3_PRM_IRQSTATUS_OFFSET,
+	.mask		= OMAP3_PRM_IRQENABLE_OFFSET,
+	.nr_regs	= 1,
+};
+
+static const struct omap_prcm_irq omap3_prcm_irqs[] = {
+	OMAP_PRCM_IRQ("wkup",	0,	0),
+	OMAP_PRCM_IRQ("io",	9,	1),
+};
+
 static int __devinit omap3xxx_prm_probe(struct platform_device *pdev)
 {
-	return 0;
+	int ret = 0;
+	struct omap_prm_platform_config *pdata = pdev->dev.platform_data;
+
+	ret = omap_prcm_register_chain_handler(pdata->irq, pdata->base,
+		&omap3_prcm_irq_setup, omap3_prcm_irqs,
+		ARRAY_SIZE(omap3_prcm_irqs));
+
+	if (ret) {
+		pr_err("%s: chain handler register failed: %d\n", __func__,
+			ret);
+	}
+	return ret;
 }
 
 static int __devexit omap3xxx_prm_remove(struct platform_device *pdev)
diff --git a/drivers/mfd/omap4xxx-prm.c b/drivers/mfd/omap4xxx-prm.c
index 9de8f3e..6e134a7 100644
--- a/drivers/mfd/omap4xxx-prm.c
+++ b/drivers/mfd/omap4xxx-prm.c
@@ -21,11 +21,37 @@
 #include <linux/platform_device.h>
 #include <linux/mfd/omap-prm.h>
 
+#include "omap-prm.h"
+
 #define DRIVER_NAME "prm4xxx"
 
+#define OMAP4_PRM_IRQSTATUS_OFFSET	0x10
+#define OMAP4_PRM_IRQENABLE_OFFSET	0x18
+
+static const struct omap_prcm_irq_setup omap4_prcm_irq_setup = {
+	.ack		= OMAP4_PRM_IRQSTATUS_OFFSET,
+	.mask		= OMAP4_PRM_IRQENABLE_OFFSET,
+	.nr_regs	= 2,
+};
+
+static const struct omap_prcm_irq omap4_prcm_irqs[] = {
+	OMAP_PRCM_IRQ("io",	9,	1),
+};
+
 static int __devinit omap4xxx_prm_probe(struct platform_device *pdev)
 {
-	return 0;
+	int ret = 0;
+	struct omap_prm_platform_config *pdata = pdev->dev.platform_data;
+
+	ret = omap_prcm_register_chain_handler(pdata->irq, pdata->base,
+		&omap4_prcm_irq_setup, omap4_prcm_irqs,
+		ARRAY_SIZE(omap4_prcm_irqs));
+
+	if (ret) {
+		pr_err("%s: chain handler register failed: %d\n", __func__,
+			ret);
+	}
+	return ret;
 }
 
 static int __devexit omap4xxx_prm_remove(struct platform_device *pdev)
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
 

[PATCHv9 06/18] mfd: omap-prm: added chain interrupt handler

[Kevin Hilman]

Tero Kristo <t-kristo@ti.com> writes:

> Introduce a chained interrupt handler mechanism for the PRCM
> interrupt, so that individual PRCM event can cleanly be handled by
> handlers in separate drivers. We do this by introducing PRCM event
> names, which are then matched to the particular PRCM interrupt bit
> depending on the specific OMAP SoC being used.
>
> PRCM interrupts have two priority levels, high or normal. High priority
> is needed for IO event handling, so that we can be sure that IO events
> are processed before other events. This reduces latency for IO event
> customers and also prevents incorrect ack sequence on OMAP3.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Avinash.H.M <avinashhm@ti.com>
> Cc: Cousson, Benoit <b-cousson@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Govindraj.R <govindraj.raja@ti.com>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> ---
>  drivers/mfd/omap-prm-common.c |  239 +++++++++++++++++++++++++++++++++++++++++
>  drivers/mfd/omap-prm.h        |   40 +++++++
>  drivers/mfd/omap3xxx-prm.c    |   29 +++++-
>  drivers/mfd/omap4xxx-prm.c    |   28 +++++-
>  4 files changed, 334 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/mfd/omap-prm.h
>
> diff --git a/drivers/mfd/omap-prm-common.c b/drivers/mfd/omap-prm-common.c
> index 39b199c8..2886eb2 100644
> --- a/drivers/mfd/omap-prm-common.c
> +++ b/drivers/mfd/omap-prm-common.c
> @@ -15,10 +15,249 @@
>  #include <linux/ctype.h>
>  #include <linux/module.h>
>  #include <linux/io.h>
> +#include <linux/irq.h>
> +#include <linux/interrupt.h>
>  #include <linux/slab.h>
>  #include <linux/init.h>
>  #include <linux/err.h>
>  
> +#include "omap-prm.h"
> +
> +#define OMAP_PRCM_MAX_NR_PENDING_REG 2
> +
> +struct omap_prm_device {
> +	const struct omap_prcm_irq_setup *irq_setup;
> +	const struct omap_prcm_irq *irqs;
> +	struct irq_chip_generic **irq_chips;
> +	int nr_irqs;
> +	u32 *saved_mask;
> +	u32 *priority_mask;
> +	int base_irq;
> +	int irq;
> +	void __iomem *base;
> +};
> +
> +static struct omap_prm_device prm_dev;

This shouldn't be statically allocated, and needlessly forces us to
assume a single, global PRM (which is the case today, but who knows...)

Instead, it should be allocated at init time and associated with the
instance (using set_drvdata or somthing.) 

> +static inline u32 prm_read_reg(int offset)
> +{
> +	return __raw_readl(prm_dev.base + offset);
> +}
> +
> +static inline void prm_write_reg(u32 value, int offset)
> +{
> +	__raw_writel(value, prm_dev.base + offset);
> +}

This doesn't seem right either.

The register layout/access parts are what are are different between the
OMAP3 and OMAP4 versions, so I would expect anything that accesses
registers to be going through the SoC specific code.

I'm having some second thoughts about the split of common and SoC
specific code here.  Currently the SoC specific code is basically
identical (ignoring the s/omap3/omap4/ throughout.)

I think we need to discuss this further, but what seems to me that the
current design is to have 2 separate drivers, with some common helper
functions.  I'm starting to think that what we need instead is a single,
common driver with a set of SoC-specific functions that implement the
SoC-specific details.   This latter approach follows what is done in the
powerdomain code today for example: common code in powerdomain.c and SoC
specific implementation of all the "ops" in powerdomain2xxx_3xxx.c and
powerdomain4xxx.c.

Kevin

[PATCHv9 06/18] mfd: omap-prm: added chain interrupt handler

[Felipe Balbi]

Hi,

On Thu, Nov 17, 2011 at 02:34:46PM -0800, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
> 
> > Introduce a chained interrupt handler mechanism for the PRCM
> > interrupt, so that individual PRCM event can cleanly be handled by
> > handlers in separate drivers. We do this by introducing PRCM event
> > names, which are then matched to the particular PRCM interrupt bit
> > depending on the specific OMAP SoC being used.
> >
> > PRCM interrupts have two priority levels, high or normal. High priority
> > is needed for IO event handling, so that we can be sure that IO events
> > are processed before other events. This reduces latency for IO event
> > customers and also prevents incorrect ack sequence on OMAP3.
> >
> > Signed-off-by: Tero Kristo <t-kristo@ti.com>
> > Cc: Paul Walmsley <paul@pwsan.com>
> > Cc: Kevin Hilman <khilman@ti.com>
> > Cc: Avinash.H.M <avinashhm@ti.com>
> > Cc: Cousson, Benoit <b-cousson@ti.com>
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: Govindraj.R <govindraj.raja@ti.com>
> > Cc: Samuel Ortiz <sameo@linux.intel.com>
> > ---
> >  drivers/mfd/omap-prm-common.c |  239 +++++++++++++++++++++++++++++++++++++++++
> >  drivers/mfd/omap-prm.h        |   40 +++++++
> >  drivers/mfd/omap3xxx-prm.c    |   29 +++++-
> >  drivers/mfd/omap4xxx-prm.c    |   28 +++++-
> >  4 files changed, 334 insertions(+), 2 deletions(-)
> >  create mode 100644 drivers/mfd/omap-prm.h
> >
> > diff --git a/drivers/mfd/omap-prm-common.c b/drivers/mfd/omap-prm-common.c
> > index 39b199c8..2886eb2 100644
> > --- a/drivers/mfd/omap-prm-common.c
> > +++ b/drivers/mfd/omap-prm-common.c
> > @@ -15,10 +15,249 @@
> >  #include <linux/ctype.h>
> >  #include <linux/module.h>
> >  #include <linux/io.h>
> > +#include <linux/irq.h>
> > +#include <linux/interrupt.h>
> >  #include <linux/slab.h>
> >  #include <linux/init.h>
> >  #include <linux/err.h>
> >  
> > +#include "omap-prm.h"
> > +
> > +#define OMAP_PRCM_MAX_NR_PENDING_REG 2
> > +
> > +struct omap_prm_device {
> > +	const struct omap_prcm_irq_setup *irq_setup;
> > +	const struct omap_prcm_irq *irqs;
> > +	struct irq_chip_generic **irq_chips;
> > +	int nr_irqs;
> > +	u32 *saved_mask;
> > +	u32 *priority_mask;
> > +	int base_irq;
> > +	int irq;
> > +	void __iomem *base;
> > +};
> > +
> > +static struct omap_prm_device prm_dev;
> 
> This shouldn't be statically allocated, and needlessly forces us to
> assume a single, global PRM (which is the case today, but who knows...)
> 
> Instead, it should be allocated at init time and associated with the
> instance (using set_drvdata or somthing.) 
> 
> > +static inline u32 prm_read_reg(int offset)
> > +{
> > +	return __raw_readl(prm_dev.base + offset);
> > +}
> > +
> > +static inline void prm_write_reg(u32 value, int offset)
> > +{
> > +	__raw_writel(value, prm_dev.base + offset);
> > +}
> 
> This doesn't seem right either.
> 
> The register layout/access parts are what are are different between the
> OMAP3 and OMAP4 versions, so I would expect anything that accesses
> registers to be going through the SoC specific code.
> 
> I'm having some second thoughts about the split of common and SoC
> specific code here.  Currently the SoC specific code is basically
> identical (ignoring the s/omap3/omap4/ throughout.)
> 
> I think we need to discuss this further, but what seems to me that the
> current design is to have 2 separate drivers, with some common helper
> functions.  I'm starting to think that what we need instead is a single,
> common driver with a set of SoC-specific functions that implement the
> SoC-specific details.   This latter approach follows what is done in the
> powerdomain code today for example: common code in powerdomain.c and SoC
> specific implementation of all the "ops" in powerdomain2xxx_3xxx.c and
> powerdomain4xxx.c.

Is it so that only register layout is different ? In that case isn't it
better to use driver_data field of the id_table structure to pass
different register offsets based on the e.g. driver name ? Something
like below:

static const struct platform_device_id omap_prm_id_table[] __devinitconst = {
	{
		.name	= "omap3-prm",
		.driver_data = (kernel_ulong_t) &omap3_prm_data,
	},
	{
		.name	= "omap4-prm",
		.driver_data = (kernel_ulong_t) &omap4_prm_data,
	},
};
MODULE_DEVICE_TABLE(platform, omap_prm_id_table);

struct platform_driver omap_prm_driver = {
	.probe		= omap_prm_probe,
	.remove		= omap_prm_remove,
	.id_table	= omap_prm_id_table,
};

then on probe you get your id, copy id->driver_data to your own
structure and use that to access your registers. Works for you ?

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111118/1f89329a/attachment.sig>

[PATCHv9 06/18] mfd: omap-prm: added chain interrupt handler

[Tero Kristo]

On Fri, 2011-11-18 at 21:18 +0200, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Nov 17, 2011 at 02:34:46PM -0800, Kevin Hilman wrote:
> > Tero Kristo <t-kristo@ti.com> writes:
> > 
> > > Introduce a chained interrupt handler mechanism for the PRCM
> > > interrupt, so that individual PRCM event can cleanly be handled by
> > > handlers in separate drivers. We do this by introducing PRCM event
> > > names, which are then matched to the particular PRCM interrupt bit
> > > depending on the specific OMAP SoC being used.
> > >
> > > PRCM interrupts have two priority levels, high or normal. High priority
> > > is needed for IO event handling, so that we can be sure that IO events
> > > are processed before other events. This reduces latency for IO event
> > > customers and also prevents incorrect ack sequence on OMAP3.
> > >
> > > Signed-off-by: Tero Kristo <t-kristo@ti.com>
> > > Cc: Paul Walmsley <paul@pwsan.com>
> > > Cc: Kevin Hilman <khilman@ti.com>
> > > Cc: Avinash.H.M <avinashhm@ti.com>
> > > Cc: Cousson, Benoit <b-cousson@ti.com>
> > > Cc: Tony Lindgren <tony@atomide.com>
> > > Cc: Govindraj.R <govindraj.raja@ti.com>
> > > Cc: Samuel Ortiz <sameo@linux.intel.com>
> > > ---
> > >  drivers/mfd/omap-prm-common.c |  239 +++++++++++++++++++++++++++++++++++++++++
> > >  drivers/mfd/omap-prm.h        |   40 +++++++
> > >  drivers/mfd/omap3xxx-prm.c    |   29 +++++-
> > >  drivers/mfd/omap4xxx-prm.c    |   28 +++++-
> > >  4 files changed, 334 insertions(+), 2 deletions(-)
> > >  create mode 100644 drivers/mfd/omap-prm.h
> > >
> > > diff --git a/drivers/mfd/omap-prm-common.c b/drivers/mfd/omap-prm-common.c
> > > index 39b199c8..2886eb2 100644
> > > --- a/drivers/mfd/omap-prm-common.c
> > > +++ b/drivers/mfd/omap-prm-common.c
> > > @@ -15,10 +15,249 @@
> > >  #include <linux/ctype.h>
> > >  #include <linux/module.h>
> > >  #include <linux/io.h>
> > > +#include <linux/irq.h>
> > > +#include <linux/interrupt.h>
> > >  #include <linux/slab.h>
> > >  #include <linux/init.h>
> > >  #include <linux/err.h>
> > >  
> > > +#include "omap-prm.h"
> > > +
> > > +#define OMAP_PRCM_MAX_NR_PENDING_REG 2
> > > +
> > > +struct omap_prm_device {
> > > +	const struct omap_prcm_irq_setup *irq_setup;
> > > +	const struct omap_prcm_irq *irqs;
> > > +	struct irq_chip_generic **irq_chips;
> > > +	int nr_irqs;
> > > +	u32 *saved_mask;
> > > +	u32 *priority_mask;
> > > +	int base_irq;
> > > +	int irq;
> > > +	void __iomem *base;
> > > +};
> > > +
> > > +static struct omap_prm_device prm_dev;
> > 
> > This shouldn't be statically allocated, and needlessly forces us to
> > assume a single, global PRM (which is the case today, but who knows...)
> > 
> > Instead, it should be allocated at init time and associated with the
> > instance (using set_drvdata or somthing.) 
> > 
> > > +static inline u32 prm_read_reg(int offset)
> > > +{
> > > +	return __raw_readl(prm_dev.base + offset);
> > > +}
> > > +
> > > +static inline void prm_write_reg(u32 value, int offset)
> > > +{
> > > +	__raw_writel(value, prm_dev.base + offset);
> > > +}
> > 
> > This doesn't seem right either.
> > 
> > The register layout/access parts are what are are different between the
> > OMAP3 and OMAP4 versions, so I would expect anything that accesses
> > registers to be going through the SoC specific code.
> > 
> > I'm having some second thoughts about the split of common and SoC
> > specific code here.  Currently the SoC specific code is basically
> > identical (ignoring the s/omap3/omap4/ throughout.)
> > 
> > I think we need to discuss this further, but what seems to me that the
> > current design is to have 2 separate drivers, with some common helper
> > functions.  I'm starting to think that what we need instead is a single,
> > common driver with a set of SoC-specific functions that implement the
> > SoC-specific details.   This latter approach follows what is done in the
> > powerdomain code today for example: common code in powerdomain.c and SoC
> > specific implementation of all the "ops" in powerdomain2xxx_3xxx.c and
> > powerdomain4xxx.c.
> 
> Is it so that only register layout is different ? In that case isn't it
> better to use driver_data field of the id_table structure to pass
> different register offsets based on the e.g. driver name ? Something
> like below:
> 
> static const struct platform_device_id omap_prm_id_table[] __devinitconst = {
> 	{
> 		.name	= "omap3-prm",
> 		.driver_data = (kernel_ulong_t) &omap3_prm_data,
> 	},
> 	{
> 		.name	= "omap4-prm",
> 		.driver_data = (kernel_ulong_t) &omap4_prm_data,
> 	},
> };
> MODULE_DEVICE_TABLE(platform, omap_prm_id_table);
> 
> struct platform_driver omap_prm_driver = {
> 	.probe		= omap_prm_probe,
> 	.remove		= omap_prm_remove,
> 	.id_table	= omap_prm_id_table,
> };
> 
> then on probe you get your id, copy id->driver_data to your own
> structure and use that to access your registers. Works for you ?
> 

Functionality is rather different for some of the features also, e.g.
latency calculation for different sleep modes (if we want to move this
here at some point.) PRCM interrupt handling is really similar for both
OMAP3 and OMAP4, thus there are currently almost no differences between
these two, because the driver only supports the interrupt handling as of
now. But yes, I agree with Kevin that this should probably be a common
driver for both, and having some device specific extensions added to
this once needed. I have a few questions though:

- How should the omap revision be passed to the driver? Somewhere in the
platform data? This has been grieving me a lot with this driver, as it
doesn't seem too easy to reach a solution that would be accepted by
everyone.

- How about device tree related stuff? Should the driver just use this
and not support platform data at all?

-Tero

[PATCHv9 07/18] mfd: omap-prm: added suspend prepare and complete callbacks

[Tero Kristo]

These are needed because runtime PM is disabled during suspend, and
it is bad if we get interrupts from the PRCM chain handler during it.
Now, PRCM interrupt forwarding is disabled until the suspend->complete,
which makes sure that all the needed drivers are up.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
---
 drivers/mfd/omap-prm-common.c |   34 +++++++++++++++++++++++++++++++++-
 drivers/mfd/omap-prm.h        |    2 ++
 drivers/mfd/omap3xxx-prm.c    |    1 +
 drivers/mfd/omap4xxx-prm.c    |    1 +
 4 files changed, 37 insertions(+), 1 deletions(-)

diff --git a/drivers/mfd/omap-prm-common.c b/drivers/mfd/omap-prm-common.c
index 2886eb2..e8522fc 100644
--- a/drivers/mfd/omap-prm-common.c
+++ b/drivers/mfd/omap-prm-common.c
@@ -20,6 +20,7 @@
 #include <linux/slab.h>
 #include <linux/init.h>
 #include <linux/err.h>
+#include <linux/platform_device.h>
 
 #include "omap-prm.h"
 
@@ -35,6 +36,7 @@ struct omap_prm_device {
 	int base_irq;
 	int irq;
 	void __iomem *base;
+	int suspended;
 };
 
 static struct omap_prm_device prm_dev;
@@ -92,12 +94,20 @@ static void prcm_irq_handler(unsigned int irq, struct irq_desc *desc)
 	struct irq_chip *chip = irq_desc_get_chip(desc);
 	unsigned int virtirq;
 	int nr_irqs = prm_dev.irq_setup->nr_regs * 32;
+	int i;
+
+	if (prm_dev.suspended)
+		for (i = 0; i < prm_dev.irq_setup->nr_regs; i++) {
+			prm_dev.saved_mask[i] =
+				prm_read_reg(prm_dev.irq_setup->mask + i * 4);
+			prm_write_reg(0, prm_dev.irq_setup->mask + i * 4);
+		}
 
 	/*
 	 * Loop until all pending irqs are handled, since
 	 * generic_handle_irq() can cause new irqs to come
 	 */
-	while (1) {
+	while (!prm_dev.suspended) {
 		prm_pending_events(pending);
 
 		/* No bit set, then all IRQs are handled */
@@ -258,6 +268,28 @@ err:
 	return -ENOMEM;
 }
 
+static int omap_prm_prepare(struct device *kdev)
+{
+	prm_dev.suspended = 1;
+	return 0;
+}
+
+static void omap_prm_complete(struct device *kdev)
+{
+	int i;
+
+	prm_dev.suspended = 0;
+
+	for (i = 0; i < prm_dev.irq_setup->nr_regs; i++)
+		prm_write_reg(prm_dev.saved_mask[i],
+			prm_dev.irq_setup->mask + i * 4);
+}
+
+const struct dev_pm_ops omap_prm_pm_ops = {
+	.prepare = omap_prm_prepare,
+	.complete = omap_prm_complete,
+};
+
 MODULE_AUTHOR("Tero Kristo <t-kristo@ti.com>");
 MODULE_DESCRIPTION("OMAP PRM core driver");
 MODULE_LICENSE("GPL");
diff --git a/drivers/mfd/omap-prm.h b/drivers/mfd/omap-prm.h
index 7ffefe1..c901810 100644
--- a/drivers/mfd/omap-prm.h
+++ b/drivers/mfd/omap-prm.h
@@ -32,6 +32,8 @@ struct omap_prcm_irq {
 	.priority = _priority				\
 	}
 
+extern const struct dev_pm_ops omap_prm_pm_ops;
+
 void omap_prcm_irq_cleanup(void);
 int omap_prcm_register_chain_handler(int irq, void __iomem *base,
 	const struct omap_prcm_irq_setup *irq_setup,
diff --git a/drivers/mfd/omap3xxx-prm.c b/drivers/mfd/omap3xxx-prm.c
index 9be21ee..38b88aa 100644
--- a/drivers/mfd/omap3xxx-prm.c
+++ b/drivers/mfd/omap3xxx-prm.c
@@ -66,6 +66,7 @@ static struct platform_driver omap3xxx_prm_driver = {
 	.driver		= {
 		.owner	= THIS_MODULE,
 		.name	= DRIVER_NAME,
+		.pm	= &omap_prm_pm_ops,
 	},
 };
 
diff --git a/drivers/mfd/omap4xxx-prm.c b/drivers/mfd/omap4xxx-prm.c
index 6e134a7..92cc67d 100644
--- a/drivers/mfd/omap4xxx-prm.c
+++ b/drivers/mfd/omap4xxx-prm.c
@@ -65,6 +65,7 @@ static struct platform_driver omap4xxx_prm_driver = {
 	.driver		= {
 		.owner	= THIS_MODULE,
 		.name	= DRIVER_NAME,
+		.pm	= &omap_prm_pm_ops,
 	},
 };
 
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
 

[PATCHv9 07/18] mfd: omap-prm: added suspend prepare and complete callbacks

[Kevin Hilman]

Tero Kristo <t-kristo@ti.com> writes:

> These are needed because runtime PM is disabled during suspend, and
> it is bad if we get interrupts from the PRCM chain handler during it.
> Now, PRCM interrupt forwarding is disabled until the suspend->complete,
> which makes sure that all the needed drivers are up.

Just to clarify...  based on reading the patch, the wakeup and PRCM
interrupts themselves still happen (and are saved). They are just not
dispatched to the drivers until ->complete().

I think the changelog should be a bit clearer about that.

Thanks,

Kevin

[PATCHv9 07/18] mfd: omap-prm: added suspend prepare and complete callbacks

[Tero Kristo]

Hi Kevin,

On Fri, 2011-11-18 at 11:02 -0800, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
> 
> > These are needed because runtime PM is disabled during suspend, and
> > it is bad if we get interrupts from the PRCM chain handler during it.
> > Now, PRCM interrupt forwarding is disabled until the suspend->complete,
> > which makes sure that all the needed drivers are up.
> 
> Just to clarify...  based on reading the patch, the wakeup and PRCM
> interrupts themselves still happen (and are saved). They are just not
> dispatched to the drivers until ->complete().
> 

Yea, this is true. We just postpone the dispatching until ->complete().
This is accomplished by disabling all the interrupts from the mask
register once a wakeup interrupt happens, saving the mask, and restoring
it at complete() which triggers the pending interrupts again.

> I think the changelog should be a bit clearer about that.

I can take a look at this for the next version.

-Tero

> 
> Thanks,
> 
> Kevin

[PATCHv9 08/18] OMAP2+: mux: add support for PAD wakeup interrupts

[Tero Kristo]

OMAP mux now provides a service routine to parse pending wakeup events
and to call registered ISR whenever active wakeups are detected. This
routine is called directly from PRCM interrupt handler.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/mux.c |   38 ++++++++++++++++++++++++++++++++++++++
 1 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 50ee806..b27c061 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -32,6 +32,9 @@
 #include <linux/debugfs.h>
 #include <linux/seq_file.h>
 #include <linux/uaccess.h>
+#include <linux/irq.h>
+#include <linux/interrupt.h>
+#include <linux/mfd/omap-prm.h>
 
 #include <asm/system.h>
 
@@ -381,6 +384,33 @@ bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
 	return ret;
 }
 
+/**
+ * omap_hwmod_mux_handle_irq - Process wakeup events for a single hwmod
+ *
+ * Checks a single hwmod for every wakeup capable pad to see if there is an
+ * active wakeup event. If this is the case, call the corresponding ISR.
+ */
+static int _omap_hwmod_mux_handle_irq(struct omap_hwmod *oh, void *data)
+{
+	if (!oh->mux || !oh->mux->enabled)
+		return 0;
+	if (omap_hwmod_mux_get_wake_status(oh->mux))
+		generic_handle_irq(oh->mpu_irqs[0].irq);
+	return 0;
+}
+
+/**
+ * omap_hwmod_mux_handle_irq - Process pad wakeup irqs.
+ *
+ * Calls a function for each registered omap_hwmod to check
+ * pad wakeup statuses.
+ */
+static irqreturn_t omap_hwmod_mux_handle_irq(int irq, void *unused)
+{
+	omap_hwmod_for_each(_omap_hwmod_mux_handle_irq, NULL);
+	return IRQ_HANDLED;
+}
+
 /* Assumes the calling function takes care of locking */
 void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
 {
@@ -745,6 +775,7 @@ static void __init omap_mux_free_names(struct omap_mux *m)
 static int __init omap_mux_late_init(void)
 {
 	struct omap_mux_partition *partition;
+	int ret;
 
 	list_for_each_entry(partition, &mux_partitions, node) {
 		struct omap_mux_entry *e, *tmp;
@@ -765,6 +796,13 @@ static int __init omap_mux_late_init(void)
 		}
 	}
 
+	ret = request_irq(omap_prcm_event_to_irq("io"),
+		omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND,
+			"hwmod_io", omap_mux_late_init);
+
+	if (ret)
+		printk(KERN_WARNING "Failed to setup hwmod io irq %d\n", ret);
+
 	omap_mux_dbg_init();
 
 	return 0;
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
 

[PATCHv9 09/18] omap3: pm: use prcm chain handler

[Tero Kristo]

PM interrupt handling is now done through the PRCM chain handler. The
interrupt handling logic is also split in two parts, to server IO and
WKUP events separately. This allows us to handle IO chain events in a
clean way.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/pm34xx.c |  104 +++++++++++++++---------------------------
 1 files changed, 37 insertions(+), 67 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7255d9b..712fd15 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -29,6 +29,7 @@
 #include <linux/delay.h>
 #include <linux/slab.h>
 #include <linux/console.h>
+#include <linux/mfd/omap-prm.h>
 #include <trace/events/power.h>
 
 #include <asm/suspend.h>
@@ -198,7 +199,7 @@ static void omap3_save_secure_ram_context(void)
  * that any peripheral wake-up events occurring while attempting to
  * clear the PM_WKST_x are detected and cleared.
  */
-static int prcm_clear_mod_irqs(s16 module, u8 regs)
+static int prcm_clear_mod_irqs(s16 module, u8 regs, u32 ignore_bits)
 {
 	u32 wkst, fclk, iclk, clken;
 	u16 wkst_off = (regs == 3) ? OMAP3430ES2_PM_WKST3 : PM_WKST1;
@@ -210,6 +211,7 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
 
 	wkst = omap2_prm_read_mod_reg(module, wkst_off);
 	wkst &= omap2_prm_read_mod_reg(module, grpsel_off);
+	wkst &= ~ignore_bits;
 	if (wkst) {
 		iclk = omap2_cm_read_mod_reg(module, iclk_off);
 		fclk = omap2_cm_read_mod_reg(module, fclk_off);
@@ -225,6 +227,7 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
 			omap2_cm_set_mod_reg_bits(clken, module, fclk_off);
 			omap2_prm_write_mod_reg(wkst, module, wkst_off);
 			wkst = omap2_prm_read_mod_reg(module, wkst_off);
+			wkst &= ~ignore_bits;
 			c++;
 		}
 		omap2_cm_write_mod_reg(iclk, module, iclk_off);
@@ -234,76 +237,35 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
 	return c;
 }
 
-static int _prcm_int_handle_wakeup(void)
+static irqreturn_t _prcm_int_handle_io(int irq, void *unused)
 {
 	int c;
 
-	c = prcm_clear_mod_irqs(WKUP_MOD, 1);
-	c += prcm_clear_mod_irqs(CORE_MOD, 1);
-	c += prcm_clear_mod_irqs(OMAP3430_PER_MOD, 1);
-	if (omap_rev() > OMAP3430_REV_ES1_0) {
-		c += prcm_clear_mod_irqs(CORE_MOD, 3);
-		c += prcm_clear_mod_irqs(OMAP3430ES2_USBHOST_MOD, 1);
-	}
+	c = prcm_clear_mod_irqs(WKUP_MOD, 1,
+		~(OMAP3430_ST_IO_MASK | OMAP3430_ST_IO_CHAIN_MASK));
 
-	return c;
+	return c ? IRQ_HANDLED : IRQ_NONE;
 }
 
-/*
- * PRCM Interrupt Handler
- *
- * The PRM_IRQSTATUS_MPU register indicates if there are any pending
- * interrupts from the PRCM for the MPU. These bits must be cleared in
- * order to clear the PRCM interrupt. The PRCM interrupt handler is
- * implemented to simply clear the PRM_IRQSTATUS_MPU in order to clear
- * the PRCM interrupt. Please note that bit 0 of the PRM_IRQSTATUS_MPU
- * register indicates that a wake-up event is pending for the MPU and
- * this bit can only be cleared if the all the wake-up events latched
- * in the various PM_WKST_x registers have been cleared. The interrupt
- * handler is implemented using a do-while loop so that if a wake-up
- * event occurred during the processing of the prcm interrupt handler
- * (setting a bit in the corresponding PM_WKST_x register and thus
- * preventing us from clearing bit 0 of the PRM_IRQSTATUS_MPU register)
- * this would be handled.
- */
-static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id)
+static irqreturn_t _prcm_int_handle_wakeup(int irq, void *unused)
 {
-	u32 irqenable_mpu, irqstatus_mpu;
-	int c = 0;
-
-	irqenable_mpu = omap2_prm_read_mod_reg(OCP_MOD,
-					 OMAP3_PRM_IRQENABLE_MPU_OFFSET);
-	irqstatus_mpu = omap2_prm_read_mod_reg(OCP_MOD,
-					 OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
-	irqstatus_mpu &= irqenable_mpu;
-
-	do {
-		if (irqstatus_mpu & (OMAP3430_WKUP_ST_MASK |
-				     OMAP3430_IO_ST_MASK)) {
-			c = _prcm_int_handle_wakeup();
-
-			/*
-			 * Is the MPU PRCM interrupt handler racing with the
-			 * IVA2 PRCM interrupt handler ?
-			 */
-			WARN(c == 0, "prcm: WARNING: PRCM indicated MPU wakeup "
-			     "but no wakeup sources are marked\n");
-		} else {
-			/* XXX we need to expand our PRCM interrupt handler */
-			WARN(1, "prcm: WARNING: PRCM interrupt received, but "
-			     "no code to handle it (%08x)\n", irqstatus_mpu);
-		}
-
-		omap2_prm_write_mod_reg(irqstatus_mpu, OCP_MOD,
-					OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
-
-		irqstatus_mpu = omap2_prm_read_mod_reg(OCP_MOD,
-					OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
-		irqstatus_mpu &= irqenable_mpu;
+	int c;
 
-	} while (irqstatus_mpu);
+	/*
+	 * Clear all except ST_IO and ST_IO_CHAIN for wkup module,
+	 * these are handled in a separate handler to avoid acking
+	 * IO events before parsing in mux code
+	 */
+	c = prcm_clear_mod_irqs(WKUP_MOD, 1,
+		OMAP3430_ST_IO_MASK | OMAP3430_ST_IO_CHAIN_MASK);
+	c += prcm_clear_mod_irqs(CORE_MOD, 1, 0);
+	c += prcm_clear_mod_irqs(OMAP3430_PER_MOD, 1, 0);
+	if (omap_rev() > OMAP3430_REV_ES1_0) {
+		c += prcm_clear_mod_irqs(CORE_MOD, 3, 0);
+		c += prcm_clear_mod_irqs(OMAP3430ES2_USBHOST_MOD, 1, 0);
+	}
 
-	return IRQ_HANDLED;
+	return c ? IRQ_HANDLED : IRQ_NONE;
 }
 
 static void omap34xx_save_context(u32 *save)
@@ -876,12 +838,20 @@ static int __init omap3_pm_init(void)
 	 * supervised mode for powerdomains */
 	prcm_setup_regs();
 
-	ret = request_irq(INT_34XX_PRCM_MPU_IRQ,
-			  (irq_handler_t)prcm_interrupt_handler,
-			  IRQF_DISABLED, "prcm", NULL);
+	ret = request_irq(omap_prcm_event_to_irq("wkup"),
+		_prcm_int_handle_wakeup, 0, "pm_wkup", NULL);
+
+	if (ret) {
+		printk(KERN_ERR "Failed to request pm_wkup irq\n");
+		goto err1;
+	}
+
+	/* IO interrupt is shared with mux code */
+	ret = request_irq(omap_prcm_event_to_irq("io"),
+		_prcm_int_handle_io, IRQF_SHARED, "pm_io", omap3_pm_init);
+
 	if (ret) {
-		printk(KERN_ERR "request_irq failed to register for 0x%x\n",
-		       INT_34XX_PRCM_MPU_IRQ);
+		printk(KERN_ERR "Failed to request pm_io irq\n");
 		goto err1;
 	}
 
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
 

[PATCHv9 10/18] OMAP3: pm: do not enable PRCM MPU interrupts manually

[Tero Kristo]

This is handled automatically by the PRCM chain interrupt mechanism now.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/pm34xx.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 712fd15..4bbf1cd 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -661,10 +661,6 @@ static void __init prcm_setup_regs(void)
 			  OMAP3430_GRPSEL_GPT1_MASK |
 			  OMAP3430_GRPSEL_GPT12_MASK,
 			  WKUP_MOD, OMAP3430_PM_MPUGRPSEL);
-	/* For some reason IO doesn't generate wakeup event even if
-	 * it is selected to mpu wakeup goup */
-	omap2_prm_write_mod_reg(OMAP3430_IO_EN_MASK | OMAP3430_WKUP_EN_MASK,
-			  OCP_MOD, OMAP3_PRM_IRQENABLE_MPU_OFFSET);
 
 	/* Enable PM_WKEN to support DSS LPR */
 	omap2_prm_write_mod_reg(OMAP3430_PM_WKEN_DSS_EN_DSS_MASK,
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
 

[PATCHv9 11/18] omap3+: add omap prm driver initialization

[Tero Kristo]

OMAP PRM driver is initialized based on availability of PRM hwmods.
This patch will sequentially check for a list of known PRM hwmods and
will add an omap device if any is found.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/devices.c |   46 +++++++++++++++++++++++++++++++++++++++++
 1 files changed, 46 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 10adf66..d6750a4 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -419,6 +419,51 @@ static void omap_init_pmu(void)
 	platform_device_register(&omap_pmu_device);
 }
 
+#ifdef CONFIG_OMAP_PRM
+
+#include <linux/mfd/omap-prm.h>
+
+static const char * const omap_prm_devnames[] = {
+	"prm3xxx",
+	"prm4xxx",
+	NULL,
+};
+
+static void omap_init_prm(void)
+{
+	struct platform_device *pdev;
+	struct omap_hwmod *oh = NULL;
+	struct omap_prm_platform_config *pdata;
+	int i = 0;
+
+	while (!oh && omap_prm_devnames[i]) {
+		oh = omap_hwmod_lookup(omap_prm_devnames[i]);
+		i++;
+	}
+
+	if (!oh) {
+		pr_info("prm hwmod not available\n");
+		return;
+	}
+
+	pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+
+	if (!pdata) {
+		pr_err("%s: kzalloc failed\n", __func__);
+		return;
+	}
+
+	pdata->irq = oh->mpu_irqs[0].irq;
+	pdata->base = omap_hwmod_get_mpu_rt_va(oh);
+
+	pdev = omap_device_build(oh->name, -1, oh, pdata,
+		sizeof(*pdata), NULL, 0, 0);
+
+	WARN(IS_ERR(pdev), "Unable to build omap device for PRM\n");
+}
+#else
+static inline void omap_init_prm(void) { }
+#endif
 
 #if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) || defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
 
@@ -687,6 +732,7 @@ static int __init omap2_init_devices(void)
 	omap_init_mbox();
 	omap_init_mcspi();
 	omap_init_pmu();
+	omap_init_prm();
 	omap_hdq_init();
 	omap_init_sti();
 	omap_init_sham();
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
 

[PATCHv9 12/18] TEMP: serial: added mux support

[Tero Kristo]

Just for PRCM chain handler testing purposes. This should be replaced with
a proper implementation.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/serial.c |   71 ++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 69 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 3d1c1d3..e08feb1 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -862,17 +862,84 @@ void __init omap_serial_init_port(struct omap_board_data *bdata)
  * can call this function when they want to have default behaviour
  * for serial ports (e.g initialize them all as serial ports).
  */
+
+struct serial_mux_conf {
+	char *name;
+	int omap3_mux;
+	int omap4_mux;
+};
+
+#define OMAP3_SERIAL_MUX_IN_PU (OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0)
+#define OMAP3_SERIAL_MUX_IN_PD (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0)
+#define OMAP3_SERIAL_MUX_IN (OMAP_PIN_INPUT | OMAP_MUX_MODE0)
+#define OMAP3_SERIAL_MUX_OUT (OMAP_PIN_OUTPUT | OMAP_MUX_MODE0)
+#define OMAP4_SERIAL_MUX_IN_PU (OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0)
+#define OMAP4_SERIAL_MUX_OUT (OMAP_PIN_OUTPUT | OMAP_MUX_MODE0)
+#define OMAP4_SERIAL_MUX_IN (OMAP_PIN_INPUT | OMAP_MUX_MODE0)
+#define SERIAL_DISABLED OMAP_MUX_MODE7
+
+#define OMAP_SERIAL_NUM_PADS_PER_PORT 4
+
+static const struct serial_mux_conf serial_mux_data[] = {
+	{ "uart1_cts.uart1_cts", OMAP3_SERIAL_MUX_IN, SERIAL_DISABLED, },
+	{ "uart1_rts.uart1_rts", OMAP3_SERIAL_MUX_OUT, SERIAL_DISABLED, },
+	{ "uart1_rx.uart1_rx", OMAP3_SERIAL_MUX_IN, SERIAL_DISABLED, },
+	{ "uart1_tx.uart1_tx", OMAP3_SERIAL_MUX_OUT, SERIAL_DISABLED, },
+	{ "uart2_cts.uart2_cts", OMAP3_SERIAL_MUX_IN,
+		OMAP4_SERIAL_MUX_IN_PU, },
+	{ "uart2_rts.uart2_rts", OMAP3_SERIAL_MUX_OUT, OMAP4_SERIAL_MUX_OUT, },
+	{ "uart2_rx.uart2_rx", OMAP3_SERIAL_MUX_IN, OMAP4_SERIAL_MUX_IN_PU, },
+	{ "uart2_tx.uart2_tx", OMAP3_SERIAL_MUX_OUT, OMAP4_SERIAL_MUX_OUT },
+	{ "uart3_cts_rctx.uart3_cts_rctx", OMAP3_SERIAL_MUX_IN_PD,
+		OMAP4_SERIAL_MUX_IN_PU, },
+	{ "uart3_rts_sd.uart3_rts_sd", OMAP3_SERIAL_MUX_OUT,
+		OMAP4_SERIAL_MUX_OUT, },
+	{ "uart3_rx_irrx.uart3_rx_irrx", OMAP3_SERIAL_MUX_IN,
+		OMAP4_SERIAL_MUX_IN, },
+	{ "uart3_tx_irtx.uart3_tx_irtx", OMAP3_SERIAL_MUX_OUT,
+		OMAP4_SERIAL_MUX_OUT, },
+	{ "uart4_rx.uart4_rx", SERIAL_DISABLED, OMAP4_SERIAL_MUX_IN, },
+	{ "uart4_tx.uart4_tx", SERIAL_DISABLED, OMAP4_SERIAL_MUX_OUT, },
+	{ NULL, SERIAL_DISABLED, SERIAL_DISABLED, },
+	{ NULL, SERIAL_DISABLED, SERIAL_DISABLED, },
+};
+
 void __init omap_serial_init(void)
 {
 	struct omap_uart_state *uart;
 	struct omap_board_data bdata;
+	struct omap_device_pad *pads;
+	int idx;
+	int i;
 
+	pads = kmalloc(sizeof(struct omap_device_pad) * 4, GFP_KERNEL);
 	list_for_each_entry(uart, &uart_list, node) {
 		bdata.id = uart->num;
 		bdata.flags = 0;
-		bdata.pads = NULL;
 		bdata.pads_cnt = 0;
+		bdata.pads = pads;
+
+		for (i = 0; i < OMAP_SERIAL_NUM_PADS_PER_PORT; i++) {
+			idx = bdata.id * OMAP_SERIAL_NUM_PADS_PER_PORT + i;
+			pads[i].name = serial_mux_data[idx].name;
+			pads[i].enable = 0;
+			pads[i].idle = 0;
+			pads[i].flags = 0;
+			if (cpu_is_omap34xx())
+				pads[i].enable = serial_mux_data[idx].omap3_mux;
+			if (cpu_is_omap44xx())
+				pads[i].enable = serial_mux_data[idx].omap4_mux;
+			if (pads[i].enable != SERIAL_DISABLED)
+				bdata.pads_cnt++;
+			if (pads[i].enable & OMAP_PIN_INPUT) {
+				pads[i].flags = OMAP_DEVICE_PAD_REMUX |
+					OMAP_DEVICE_PAD_WAKEUP;
+			}
+			pads[i].idle = pads[i].enable;
+		}
+		if (bdata.pads_cnt == 0)
+			bdata.pads = NULL;
 		omap_serial_init_port(&bdata);
-
 	}
+	kfree(pads);
 }
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
 

[PATCHv9 13/18] TEMP: 4430sdp: use common serial init with mux support

[Tero Kristo]

Temporary testing related patch, not meant for integration.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/board-4430sdp.c |   12 +-----------
 1 files changed, 1 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index c7cef44..f1151e8 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -737,17 +737,7 @@ static struct omap_board_data serial4_data __initdata = {
 
 static inline void board_serial_init(void)
 {
-	struct omap_board_data bdata;
-	bdata.flags	= 0;
-	bdata.pads	= NULL;
-	bdata.pads_cnt	= 0;
-	bdata.id	= 0;
-	/* pass dummy data for UART1 */
-	omap_serial_init_port(&bdata);
-
-	omap_serial_init_port(&serial2_data);
-	omap_serial_init_port(&serial3_data);
-	omap_serial_init_port(&serial4_data);
+	omap_serial_init();
 }
 #else
 #define board_mux	NULL
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
 

[PATCHv9 14/18] TEMP: mux: added trace for io wkup event

[Tero Kristo]

Temporary patch for testing purposes, not meant for integration.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/mux.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index b27c061..642fe3f 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -376,6 +376,8 @@ bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
 					pad->mux->reg_offset);
 			if (val & OMAP_WAKEUP_EVENT) {
 				ret = true;
+				pr_info("wkup detected: %04x\n",
+					pad->mux->reg_offset);
 				break;
 			}
 		}
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
 

[PATCHv9 15/18] TEMP: OMAP3: pm: remove serial resume / idle calls from idle path

[Tero Kristo]

This is no longer needed as it will be handled within serial driver itself.
This part should be properly handled with serial runtime support.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Govindraj.R <govindraj.raja@ti.com>
---
 arch/arm/mach-omap2/pm34xx.c |   19 -------------------
 1 files changed, 0 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 4bbf1cd..46c209d 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -341,18 +341,9 @@ void omap_sram_idle(void)
 		omap3_enable_io_chain();
 	}
 
-	/* Block console output in case it is on one of the OMAP UARTs */
-	if (!is_suspending())
-		if (per_next_state < PWRDM_POWER_ON ||
-		    core_next_state < PWRDM_POWER_ON)
-			if (!console_trylock())
-				goto console_still_active;
-
 	/* PER */
 	if (per_next_state < PWRDM_POWER_ON) {
 		per_going_off = (per_next_state == PWRDM_POWER_OFF) ? 1 : 0;
-		omap_uart_prepare_idle(2);
-		omap_uart_prepare_idle(3);
 		omap2_gpio_prepare_for_idle(per_going_off);
 		if (per_next_state == PWRDM_POWER_OFF)
 				omap3_per_save_context();
@@ -360,8 +351,6 @@ void omap_sram_idle(void)
 
 	/* CORE */
 	if (core_next_state < PWRDM_POWER_ON) {
-		omap_uart_prepare_idle(0);
-		omap_uart_prepare_idle(1);
 		if (core_next_state == PWRDM_POWER_OFF) {
 			omap3_core_save_context();
 			omap3_cm_save_context();
@@ -408,8 +397,6 @@ void omap_sram_idle(void)
 			omap3_sram_restore_context();
 			omap2_sms_restore_context();
 		}
-		omap_uart_resume_idle(0);
-		omap_uart_resume_idle(1);
 		if (core_next_state == PWRDM_POWER_OFF)
 			omap2_prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF_MASK,
 					       OMAP3430_GR_MOD,
@@ -423,14 +410,8 @@ void omap_sram_idle(void)
 		omap2_gpio_resume_after_idle();
 		if (per_prev_state == PWRDM_POWER_OFF)
 			omap3_per_restore_context();
-		omap_uart_resume_idle(2);
-		omap_uart_resume_idle(3);
 	}
 
-	if (!is_suspending())
-		console_unlock();
-
-console_still_active:
 	/* Disable IO-PAD and IO-CHAIN wakeup */
 	if (omap3_has_io_wakeup() &&
 	    (per_next_state < PWRDM_POWER_ON ||
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
 

[PATCHv9 16/18] TEMP: OMAP3: serial: made serial to work properly with PRCM chain handler

[Tero Kristo]

This patch is just a temporary hack to allow serial to work properly with
the PRCM chain handler. Should be replaced with a proper implementation
by serial runtime PM support.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Govindraj.R <govindraj.raja@ti.com>
---
 arch/arm/mach-omap2/serial.c     |   29 +++++++++--------------------
 drivers/tty/serial/omap-serial.c |    8 ++++++++
 2 files changed, 17 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index e08feb1..0cc5434 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -39,6 +39,7 @@
 #include <plat/dma.h>
 #include <plat/omap_hwmod.h>
 #include <plat/omap_device.h>
+#include <plat/prcm.h>
 
 #include "prm2xxx_3xxx.h"
 #include "pm.h"
@@ -380,6 +381,7 @@ static void omap_uart_allow_sleep(struct omap_uart_state *uart)
 	omap_uart_smart_idle_enable(uart, 1);
 	uart->can_sleep = 1;
 	del_timer(&uart->timer);
+	omap_uart_disable_clocks(uart);
 }
 
 static void omap_uart_idle_timer(unsigned long data)
@@ -391,36 +393,23 @@ static void omap_uart_idle_timer(unsigned long data)
 
 void omap_uart_prepare_idle(int num)
 {
-	struct omap_uart_state *uart;
-
-	list_for_each_entry(uart, &uart_list, node) {
-		if (num == uart->num && uart->can_sleep) {
-			omap_uart_disable_clocks(uart);
-			return;
-		}
-	}
 }
 
 void omap_uart_resume_idle(int num)
 {
 	struct omap_uart_state *uart;
+	u32 wkst;
 
 	list_for_each_entry(uart, &uart_list, node) {
 		if (num == uart->num && uart->can_sleep) {
-			omap_uart_enable_clocks(uart);
+			omap_uart_block_sleep(uart);
 
-			/* Check for IO pad wakeup */
-			if (cpu_is_omap34xx() && uart->padconf) {
-				u16 p = omap_ctrl_readw(uart->padconf);
-
-				if (p & OMAP3_PADCONF_WAKEUPEVENT0)
-					omap_uart_block_sleep(uart);
+			/* Check for normal UART wakeup (and clear it) */
+			if (uart->wk_st && uart->wk_mask) {
+				wkst = __raw_readl(uart->wk_st) & uart->wk_mask;
+				if (wkst)
+					__raw_writel(wkst, uart->wk_st);
 			}
-
-			/* Check for normal UART wakeup */
-			if (__raw_readl(uart->wk_st) & uart->wk_mask)
-				omap_uart_block_sleep(uart);
-			return;
 		}
 	}
 }
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index c37df8d..cfff8ac 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -261,6 +261,8 @@ static void serial_omap_start_tx(struct uart_port *port)
 	unsigned int start;
 	int ret = 0;
 
+	omap_uart_resume_idle(up->pdev->id);
+
 	if (!up->use_dma) {
 		serial_omap_enable_ier_thri(up);
 		return;
@@ -354,6 +356,8 @@ static inline irqreturn_t serial_omap_irq(int irq, void *dev_id)
 	unsigned int iir, lsr;
 	unsigned long flags;
 
+	omap_uart_resume_idle(up->pdev->id);
+
 	iir = serial_in(up, UART_IIR);
 	if (iir & UART_IIR_NO_INT)
 		return IRQ_NONE;
@@ -641,6 +645,8 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios,
 	unsigned long flags = 0;
 	unsigned int baud, quot;
 
+	omap_uart_resume_idle(up->pdev->id);
+
 	switch (termios->c_cflag & CSIZE) {
 	case CS5:
 		cval = UART_LCR_WLEN5;
@@ -947,6 +953,8 @@ serial_omap_console_write(struct console *co, const char *s,
 	unsigned int ier;
 	int locked = 1;
 
+	omap_uart_resume_idle(up->pdev->id);
+
 	local_irq_save(flags);
 	if (up->port.sysrq)
 		locked = 0;
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
 

[PATCHv9 17/18] TEMP: OMAP: serial: remove padconf hacks

[Tero Kristo]

These are no longer needed as omap_hwmod takes care of multiplexing of pads.
Should be handled properly with serial runtime PM support patches.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Govindraj.R <govindraj.raja@ti.com>
---
 arch/arm/mach-omap2/serial.c |   25 +------------------------
 1 files changed, 1 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0cc5434..cdcdd83 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -73,7 +73,6 @@ struct omap_uart_state {
 	void __iomem *wk_st;
 	void __iomem *wk_en;
 	u32 wk_mask;
-	u32 padconf;
 	u32 dma_enabled;
 
 	struct clk *ick;
@@ -309,13 +308,6 @@ static void omap_uart_enable_wakeup(struct omap_uart_state *uart)
 		v |= uart->wk_mask;
 		__raw_writel(v, uart->wk_en);
 	}
-
-	/* Ensure IOPAD wake-enables are set */
-	if (cpu_is_omap34xx() && uart->padconf) {
-		u16 v = omap_ctrl_readw(uart->padconf);
-		v |= OMAP3_PADCONF_WAKEUPENABLE0;
-		omap_ctrl_writew(v, uart->padconf);
-	}
 }
 
 static void omap_uart_disable_wakeup(struct omap_uart_state *uart)
@@ -326,13 +318,6 @@ static void omap_uart_disable_wakeup(struct omap_uart_state *uart)
 		v &= ~uart->wk_mask;
 		__raw_writel(v, uart->wk_en);
 	}
-
-	/* Ensure IOPAD wake-enables are cleared */
-	if (cpu_is_omap34xx() && uart->padconf) {
-		u16 v = omap_ctrl_readw(uart->padconf);
-		v &= ~OMAP3_PADCONF_WAKEUPENABLE0;
-		omap_ctrl_writew(v, uart->padconf);
-	}
 }
 
 static void omap_uart_smart_idle_enable(struct omap_uart_state *uart,
@@ -478,7 +463,6 @@ static void omap_uart_idle_init(struct omap_uart_state *uart)
 	if (cpu_is_omap34xx() && !cpu_is_ti816x()) {
 		u32 mod = (uart->num > 1) ? OMAP3430_PER_MOD : CORE_MOD;
 		u32 wk_mask = 0;
-		u32 padconf = 0;
 
 		/* XXX These PRM accesses do not belong here */
 		uart->wk_en = OMAP34XX_PRM_REGADDR(mod, PM_WKEN1);
@@ -486,23 +470,18 @@ static void omap_uart_idle_init(struct omap_uart_state *uart)
 		switch (uart->num) {
 		case 0:
 			wk_mask = OMAP3430_ST_UART1_MASK;
-			padconf = 0x182;
 			break;
 		case 1:
 			wk_mask = OMAP3430_ST_UART2_MASK;
-			padconf = 0x17a;
 			break;
 		case 2:
 			wk_mask = OMAP3430_ST_UART3_MASK;
-			padconf = 0x19e;
 			break;
 		case 3:
 			wk_mask = OMAP3630_ST_UART4_MASK;
-			padconf = 0x0d2;
 			break;
 		}
 		uart->wk_mask = wk_mask;
-		uart->padconf = padconf;
 	} else if (cpu_is_omap24xx()) {
 		u32 wk_mask = 0;
 		u32 wk_en = PM_WKEN1, wk_st = PM_WKST1;
@@ -532,7 +511,6 @@ static void omap_uart_idle_init(struct omap_uart_state *uart)
 		uart->wk_en = NULL;
 		uart->wk_st = NULL;
 		uart->wk_mask = 0;
-		uart->padconf = 0;
 	}
 
 	uart->irqflags |= IRQF_SHARED;
@@ -833,8 +811,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata)
 
 	console_unlock();
 
-	if ((cpu_is_omap34xx() && uart->padconf) ||
-	    (uart->wk_en && uart->wk_mask)) {
+	if (uart->oh->mux || (uart->wk_en && uart->wk_mask)) {
 		device_init_wakeup(&pdev->dev, true);
 		DEV_CREATE_FILE(&pdev->dev, &dev_attr_sleep_timeout);
 	}
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
 

[PATCHv9 18/18] TEMP: OMAP device: change pr_warnings to pr_debugs

[Tero Kristo]

Prevents a hang when omap_device would want to print something for
serial console device while enabling / disabling its clocks.
Should be handled properly by serial runtime PM support.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Govindraj.R <govindraj.raja@ti.com>
---
 arch/arm/plat-omap/omap_device.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index d8f2299..ecec0cc 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -154,7 +154,7 @@ static int _omap_device_activate(struct omap_device *od, u8 ignore_lat)
 					"%d: %llu\n",
 					od->pm_lat_level, act_lat);
 			} else
-				dev_warn(&od->pdev->dev,
+				dev_dbg(&od->pdev->dev,
 					 "activate latency %d "
 					 "higher than exptected. (%llu > %d)\n",
 					 od->pm_lat_level, act_lat,
@@ -221,7 +221,7 @@ static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat)
 					"%d: %llu\n",
 					od->pm_lat_level, deact_lat);
 			} else
-				dev_warn(&od->pdev->dev,
+				dev_dbg(&od->pdev->dev,
 					 "deactivate latency %d "
 					 "higher than exptected. (%llu > %d)\n",
 					 od->pm_lat_level, deact_lat,
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
 

[PATCHv9 00/18] omap PRCM chain handler

[Valdis.Kletnieks at vt.edu]

On Fri, 23 Sep 2011 15:46:08 +0300, Tero Kristo said:
> Following set contains the version 9 of this work. This patch set contains
> a number of patches tagged as 'TEMP', they are only meant for testing
> purposes and to provide proof of concept. Most of the 'TEMP' patches are
> related to UART runtime handling and they will be replaced by work done
> by Govindraj Raja.

What do we do with these TEMP patches if the UART patches don't make the same
merge window, or have other issues?  I'm always leery of "will be replaced"
code, because I've seen too many times when it *didn't* get replaced.

(I really don't care what the 'Plan B' is, as long as we have one...)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110923/48e9cd85/attachment.sig>

[PATCHv9 00/18] omap PRCM chain handler

[Sripathy, Vishwanath]

Hi Valdis.Kletnieks,

On Sat, Sep 24, 2011 at 3:53 AM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Fri, 23 Sep 2011 15:46:08 +0300, Tero Kristo said:
>> Following set contains the version 9 of this work. This patch set contains
>> a number of patches tagged as 'TEMP', they are only meant for testing
>> purposes and to provide proof of concept. Most of the 'TEMP' patches are
>> related to UART runtime handling and they will be replaced by work done
>> by Govindraj Raja.
>
> What do we do with these TEMP patches if the UART patches don't make the same
> merge window, or have other issues? ?I'm always leery of "will be replaced"
> code, because I've seen too many times when it *didn't* get replaced.
>
> (I really don't care what the 'Plan B' is, as long as we have one...)
UART Runtime patches are already posted for review and it's also
targeted for next merge window. Our intention is to push both the
features together for next merge window.

Regards
Vishwa

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

[PATCHv9 00/18] omap PRCM chain handler

[Valdis.Kletnieks at vt.edu]

On Sat, 24 Sep 2011 10:54:29 +0530, "Sripathy, Vishwanath" said:

> UART Runtime patches are already posted for review and it's also
> targeted for next merge window. Our intention is to push both the
> features together for next merge window.

Oh, OK. That should work then. Thanks for the clarification...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110924/1ef96d68/attachment.sig>