From: "Govindraj.R" <redacted>
On omap3630 onwards uart wer reg has bit 7
for tx wakeup enable.
Without this bit set some uart sluggishness might be seen
while printing data on console, response is better when
enabling this bit.
Tested with Beagle XM (OMAP3630)
Cc: Kevin Hilman <redacted>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Govindraj.R <redacted>
---
But on omap3430 the bit is not available.
arch/arm/plat-omap/include/plat/omap-serial.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
From: Paul Walmsley <paul@pwsan.com> Date: 2012-01-25 19:14:47
cc'ing linux-arm-kernel also
Hi
some comments
On Tue, 24 Jan 2012, Govindraj.R wrote:
From: "Govindraj.R" <redacted>
On omap3630 onwards uart wer reg has bit 7
for tx wakeup enable.
Without this bit set some uart sluggishness might be seen
while printing data on console, response is better when
enabling this bit.
Tested with Beagle XM (OMAP3630)
Cc: Kevin Hilman <redacted>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Govindraj.R <redacted>
---
But on omap3430 the bit is not available.
Well that's good news that it exists on 36xx+ at least.
But please make a few changes.
This shouldn't set this bit on UARTs that don't support it. It should
only be set if a hwmod dev_attr flag was set to indicate the presence of
this feature. Using a flag is also important since it will allow us to
disable the workaround that we'll need for earlier OMAPs.
Also, I assume that this does not fix the RX sluggishness due to the
missing RX timeout wakeup?
Also, this assignment should be using symbolic macros rather than raw
bits.
- Paul
cc'ing linux-arm-kernel also (correct address this time)
Hi
some comments
On Tue, 24 Jan 2012, Govindraj.R wrote:
From: "Govindraj.R" <redacted>
On omap3630 onwards uart wer reg has bit 7
for tx wakeup enable.
Without this bit set some uart sluggishness might be seen
while printing data on console, response is better when
enabling this bit.
Tested with Beagle XM (OMAP3630)
Cc: Kevin Hilman <redacted>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Govindraj.R <redacted>
---
But on omap3430 the bit is not available.
Well that's good news that it exists on 36xx+ at least.
But please make a few changes.
This shouldn't set this bit on UARTs that don't support it. It should
only be set if a hwmod dev_attr flag was set to indicate the presence of
this feature. Using a flag is also important since it will allow us to
disable the workaround that we'll need for earlier OMAPs.
Also, I assume that this does not fix the RX sluggishness due to the
missing RX timeout wakeup?
Also, this assignment should be using symbolic macros rather than raw
bits.
- Paul
Hello Govindraj
Do you intend to update and repost this serial patch? Or should someone
else deal with it? It would be good to get support for this additional
wakeup bit.
- Paul
On Tue, Mar 6, 2012 at 1:53 AM, Paul Walmsley [off-list ref] wrote:
Hello Govindraj
Do you intend to update and repost this serial patch? Or should someone
else deal with it? It would be good to get support for this additional
wakeup bit.
Thanks for reminding.
(I had got preempted with other activities, apologies for the delay)
I see two ways of adding this tx wake-up flag.
1.) passing a feature flag from pdata and populating the feature value to wer.
2.) Duplicating the uart1/2/3 hwmod for omap3430 without dev attrib
and uart1/2/3/4
hwmod for omap3630 with dev attribs.
Approach-2 adds unnecessary code duplication in hwmod file with and without
dev_attribs, So right now here is the patch to follow approach [1],
If its strongly recommended to use approach-2 will add it.
(My concern is the diffstat it might produce with approach-2)
--
Thanks,
Govindraj.R
[1]:
From 867dfa7328b4219be259a204555a6baae82ec4df Mon Sep 17 00:00:00 2001
From: "Govindraj.R" <redacted>
Date: Tue, 6 Mar 2012 15:04:47 +0530
Subject: [PATCH] OMAP: UART: enable tx wake up capability for 3630 above socs
From omap3630 above UART wer(wakeup enable reg) has TX
wakeup capability, enable the tx wakeup bit by passing
the required feature flag from pdata.
Also add missing wer reg restore from context restore function.
Signed-off-by: Govindraj.R <redacted>
---
arch/arm/mach-omap2/serial.c | 3 +++
arch/arm/plat-omap/include/plat/omap-serial.h | 7 +++++++
drivers/tty/serial/omap-serial.c | 8 +++++++-
3 files changed, 17 insertions(+), 1 deletions(-)
@@ -577,8 +577,10 @@ static int serial_omap_startup(struct uart_port *port)up->ier=UART_IER_RLSI|UART_IER_RDI;serial_out(up,UART_IER,up->ier);+up->wer|=OMAP_UART_WER_MOD_WKUP;+/* Enable module level wake up */-serial_out(up,UART_OMAP_WER,OMAP_UART_WER_MOD_WKUP);+serial_out(up,UART_OMAP_WER,up->wer);pm_runtime_mark_last_busy(&up->pdev->dev);pm_runtime_put_autosuspend(&up->pdev->dev);
@@ -1444,6 +1446,8 @@ static int serial_omap_probe(struct platform_device *pdev)}up->uart_dma.uart_base=mem->start;up->errata=omap_up_info->errata;+if(omap_up_info->has_feature&UART_FEATURE_TX_WAKEUP_EN)+up->wer|=OMAP_UART_TX_WAKEUP_EN;if(omap_up_info->dma_enabled){up->uart_dma.uart_dma_tx=dma_tx->start;
uart_omap_port *up)
serial_omap_mdr1_errataset(up, up->mdr1);
else
serial_out(up, UART_OMAP_MDR1, up->mdr1);
+
+ serial_out(up, UART_OMAP_WER, up->wer);
}
static int serial_omap_runtime_suspend(struct device *dev)
--
1.7.5.4
--
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
I see two ways of adding this tx wake-up flag.
1.) passing a feature flag from pdata and populating the feature value to wer.
2.) Duplicating the uart1/2/3 hwmod for omap3430 without dev attrib
and uart1/2/3/4
hwmod for omap3630 with dev attribs.
Approach-2 adds unnecessary code duplication in hwmod file with and without
dev_attribs, So right now here is the patch to follow approach [1],
If its strongly recommended to use approach-2 will add it.
(My concern is the diffstat it might produce with approach-2)
Both 1 and 2 are needed.
The current way that errata are handled in arch/arm/mach-omap2/serial.c
needs to be changed. Those should be flags that are passed from hwmod
dev_attr data. The presence of the TX wakeup bit should simply be another
dev_attr flag. These flags should be passed to the driver via the
omap_up.errata field for the time being.
The exception to this is if the IP block's revision register was changed
when TX wakeups became possible. If that's the case, then that mechanism
can be used in lieu of dev_attr and platform_data in this situation.
- Paul
On Wed, Mar 7, 2012 at 11:27 AM, Paul Walmsley [off-list ref] wrote:
Hi
On Tue, 6 Mar 2012, Raja, Govindraj wrote:
quoted
I see two ways of adding this tx wake-up flag.
1.) passing a feature flag from pdata and populating the feature value to wer.
2.) Duplicating the uart1/2/3 hwmod for omap3430 without dev attrib
and uart1/2/3/4
hwmod for omap3630 with dev attribs.
Approach-2 adds unnecessary code duplication in hwmod file with and without
dev_attribs, So right now here is the patch to follow approach [1],
If its strongly recommended to use approach-2 will add it.
(My concern is the diffstat it might produce with approach-2)
Both 1 and 2 are needed.
The current way that errata are handled in arch/arm/mach-omap2/serial.c
needs to be changed. Those should be flags that are passed from hwmod
dev_attr data. The presence of the TX wakeup bit should simply be another
dev_attr flag. These flags should be passed to the driver via the
omap_up.errata field for the time being.
okay.
The exception to this is if the IP block's revision register was changed
when TX wakeups became possible. If that's the case, then that mechanism
can be used in lieu of dev_attr and platform_data in this situation.
I will check on the MVR reg available for uart-rev on different omap socs,
and will get back by end on next of week with a possible patch.
--
Thanks,
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