[pm-wip/uart][PATCH 3/5 v2] OMAP3: serial: Fix uart4 handling for 3630

[pm-wip/uart][PATCH 3/5 v2] OMAP3: serial: Fix uart4 handling for 3630

[Govindraj.R]

This patch makes the following:
 - Adds missing wakeup padding register handling.
 - Fixes a hardcode to use PER module ONLY on UART3.
 - Muxmode usage needed for uart4 for 3630, for padconf
   wakeup on uart4_rx line. uart4_rx signal is available
   under mode-2 in gpmc_wait3. Thus have to ensure we are
   in right mux mode before accesing any padconf register.
   So ensure right mux mode for uarti padconf access.

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Sergio Aguirre <saaguirre@ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
---
 arch/arm/mach-omap2/serial.c |   43 +++++++++++++++++++++++++++++++++++++----
 1 files changed, 38 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index da9fee6..128e19b 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -42,6 +42,7 @@
 #include "prm.h"
 #include "pm.h"
 #include "cm.h"
+#include "mux.h"
 #include "prm-regbits-34xx.h"

 #define UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV	0x52
@@ -68,6 +69,7 @@ struct omap_uart_state {
 	u32 wk_mask;
 	u32 padconf;
 	u32 dma_enabled;
+	u16 muxmode;

 	struct clk *ick;
 	struct clk *fck;
@@ -229,8 +231,20 @@ static inline void omap_uart_disable_clocks(struct omap_uart_state *uart)
 	omap_device_idle(uart->pdev);
 }

+static inline void omap_uart_set_muxmode(struct omap_uart_state *uart)
+{
+	u16 w = omap_ctrl_readw(uart->padconf);
+
+	w &= ~0x7;
+	w |= uart->muxmode;
+	omap_ctrl_writew(w, uart->padconf);
+}
+
 static void omap_uart_enable_wakeup(struct omap_uart_state *uart)
 {
+	if (uart->muxmode && uart->padconf)
+		omap_uart_set_muxmode(uart);
+
 	/* Set wake-enable bit */
 	if (uart->wk_en && uart->wk_mask) {
 		u32 v = __raw_readl(uart->wk_en);
@@ -248,6 +262,9 @@ static void omap_uart_enable_wakeup(struct omap_uart_state *uart)

 static void omap_uart_disable_wakeup(struct omap_uart_state *uart)
 {
+	if (uart->muxmode && uart->padconf)
+		omap_uart_set_muxmode(uart);
+
 	/* Clear wake-enable bit */
 	if (uart->wk_en && uart->wk_mask) {
 		u32 v = __raw_readl(uart->wk_en);
@@ -338,6 +355,9 @@ void omap_uart_resume_idle(int num)
 		if (num == uart->num) {
 			omap_uart_enable_clocks(uart);

+			if (uart->muxmode && uart->padconf)
+				omap_uart_set_muxmode(uart);
+
 			/* Check for IO pad wakeup */
 			if (cpu_is_omap34xx() && uart->padconf) {
 				u16 p = omap_ctrl_readw(uart->padconf);
@@ -416,28 +436,41 @@ static void omap_uart_idle_init(struct omap_uart_state *uart)
 	omap_uart_smart_idle_enable(uart, 0);

 	if (cpu_is_omap34xx()) {
-		u32 mod = (uart->num == 2) ? OMAP3430_PER_MOD : CORE_MOD;
+		u32 mod = (uart->num > 1) ? OMAP3430_PER_MOD : CORE_MOD;
 		u32 wk_mask = 0;
-		u32 padconf = 0;
+		u16 padconf = 0;
+		u16 muxmode = 0;

 		uart->wk_en = OMAP34XX_PRM_REGADDR(mod, PM_WKEN1);
 		uart->wk_st = OMAP34XX_PRM_REGADDR(mod, PM_WKST1);
 		switch (uart->num) {
 		case 0:
 			wk_mask = OMAP3430_ST_UART1_MASK;
-			padconf = 0x182;
+			padconf = omap_mux_request_signal("uart1_rx");
 			break;
 		case 1:
 			wk_mask = OMAP3430_ST_UART2_MASK;
-			padconf = 0x17a;
+			padconf = omap_mux_request_signal("uart2_rx");
 			break;
 		case 2:
 			wk_mask = OMAP3430_ST_UART3_MASK;
-			padconf = 0x19e;
+			padconf = omap_mux_request_signal("uart3_rx_irrx");
+			break;
+		case 3:
+			wk_mask = OMAP3630_ST_UART4_MASK;
+			/**
+			 * get uart4_rx mux pin offset.
+			 * uart4_rx signal is available in gpmc_wait3
+			 * in mux_mode 2. Refer to OMAP36XX TRM and
+			 * /mach-omap2/mux34xx.c file for further details.
+			 */
+			padconf = omap_mux_request_signal("gpmc_wait3");
+			muxmode = OMAP_MUX_MODE2;
 			break;
 		}
 		uart->wk_mask = wk_mask;
 		uart->padconf = padconf;
+		uart->muxmode = muxmode;
 	} else if (cpu_is_omap24xx()) {
 		u32 wk_mask = 0;

-- 
1.6.3.3

Re: [pm-wip/uart][PATCH 3/5 v2] OMAP3: serial: Fix uart4 handling for 3630

[Kevin Hilman]

"Govindraj.R" <govindraj.raja@ti.com> writes:

> This patch makes the following:
>  - Adds missing wakeup padding register handling.
>  - Fixes a hardcode to use PER module ONLY on UART3.
>  - Muxmode usage needed for uart4 for 3630, for padconf
>    wakeup on uart4_rx line. uart4_rx signal is available
>    under mode-2 in gpmc_wait3. Thus have to ensure we are
>    in right mux mode before accesing any padconf register.
>    So ensure right mux mode for uarti padconf access.

I think this mux-mode handling should be done as a separate patch with
more description as exactly what problem this is solving.

Presumably, whatever problem you're solving not unique to 3630 UART4
as the UARTs on the other platforms can be muxed with other
peripherals as well.

Based on the way it's being mux'd (and continually re-mux'd) in this
patch, it looks like the mux settings for that pin are being
dynamically changed elsewhere in the code.  If that's the case, then
that should be better understood, and this code should likely re-mux
to the original settings when its done.

Kevin

Re: [pm-wip/uart][PATCH 3/5 v2] OMAP3: serial: Fix uart4 handling for 3630

[Govindraj]

On Fri, Jun 18, 2010 at 3:15 AM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> "Govindraj.R" <govindraj.raja@ti.com> writes:
>
>> This patch makes the following:
>>  - Adds missing wakeup padding register handling.
>>  - Fixes a hardcode to use PER module ONLY on UART3.
>>  - Muxmode usage needed for uart4 for 3630, for padconf
>>    wakeup on uart4_rx line. uart4_rx signal is available
>>    under mode-2 in gpmc_wait3. Thus have to ensure we are
>>    in right mux mode before accesing any padconf register.
>>    So ensure right mux mode for uarti padconf access.
>
> I think this mux-mode handling should be done as a separate patch with
> more description as exactly what problem this is solving.
>
> Presumably, whatever problem you're solving not unique to 3630 UART4
> as the UARTs on the other platforms can be muxed with other
> peripherals as well.
>
> Based on the way it's being mux'd (and continually re-mux'd) in this
> patch, it looks like the mux settings for that pin are being
> dynamically changed elsewhere in the code.  If that's the case, then
> that should be better understood, and this code should likely re-mux
> to the original settings when its done.
>
> Kevin

Since padconf and mux_mode value is populated based on a cpu_check I
thought other platforms might not be affected

Actually uart4_rx in available under CONTROL_PADCONF_GPMC_WAIT2[31:16]
in mux_mode 2

I am not sure whether this gpmc line is used or not.

I was just trying to be cautious in read and write for uart4_rx
Ensuring that I am using right mux mode wrt uart
Yes I do agree that I can corrupt gpmc_wait2 padconf if used by other
peripheral.

So any thought how do we handle rx wakeup if not available as an
seperate padconf
as in this case uart4_rx
I mean if uart_rx_padconf is not available straight forward and
available under a muxmode

Regards,
Govindraj.R

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



-- 
---
Regards,
Govindraj.R
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [pm-wip/uart][PATCH 3/5 v2] OMAP3: serial: Fix uart4 handling for 3630

[Kevin Hilman]

Govindraj <govindraj.ti@gmail.com> writes:

> On Fri, Jun 18, 2010 at 3:15 AM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> "Govindraj.R" <govindraj.raja@ti.com> writes:
>>
>>> This patch makes the following:
>>>  - Adds missing wakeup padding register handling.
>>>  - Fixes a hardcode to use PER module ONLY on UART3.
>>>  - Muxmode usage needed for uart4 for 3630, for padconf
>>>    wakeup on uart4_rx line. uart4_rx signal is available
>>>    under mode-2 in gpmc_wait3. Thus have to ensure we are
>>>    in right mux mode before accesing any padconf register.
>>>    So ensure right mux mode for uarti padconf access.
>>
>> I think this mux-mode handling should be done as a separate patch with
>> more description as exactly what problem this is solving.
>>
>> Presumably, whatever problem you're solving not unique to 3630 UART4
>> as the UARTs on the other platforms can be muxed with other
>> peripherals as well.
>>
>> Based on the way it's being mux'd (and continually re-mux'd) in this
>> patch, it looks like the mux settings for that pin are being
>> dynamically changed elsewhere in the code.  If that's the case, then
>> that should be better understood, and this code should likely re-mux
>> to the original settings when its done.
>>
>> Kevin
>
> Since padconf and mux_mode value is populated based on a cpu_check I
> thought other platforms might not be affected

What I meant was that the UART pins on OMAP3 are also mux'd with other
peripherals, so if you're managing the mux for UART4, you should also
manage them for the other UARTs.

> Actually uart4_rx in available under CONTROL_PADCONF_GPMC_WAIT2[31:16]
> in mux_mode 2
>
> I am not sure whether this gpmc line is used or not.
>
> I was just trying to be cautious in read and write for uart4_rx
> Ensuring that I am using right mux mode wrt uart
> Yes I do agree that I can corrupt gpmc_wait2 padconf if used by other
> peripheral.
>
> So any thought how do we handle rx wakeup if not available as an
> seperate padconf
> as in this case uart4_rx

The board code should be muxing the UARTs at init time.  If there is a
need to dynamically manage the mux settings, then that is a separate
issue.

Kevin

> I mean if uart_rx_padconf is not available straight forward and
> available under a muxmode
>
> Regards,
> Govindraj.R
>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> -- 
> ---
> Regards,
> Govindraj.R
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html