* [PATCH 7/7] UART: OMAP: Trivial optimisation of the probe and remove
From: Shubhrajyoti D @ 2012-04-16 15:07 UTC (permalink / raw)
To: linux-serial; +Cc: linux-omap, linux-arm-kernel, Shubhrajyoti D, Govindraj.R
In-Reply-To: <1334588821-5224-1-git-send-email-shubhrajyoti@ti.com>
The probe and remove may not be needed after initialisation and
remove the code could be be put in the devint and devexit section.
Cc: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
drivers/tty/serial/omap-serial.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index cbc9d64..42ad500 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1358,7 +1358,7 @@ static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
return omap_up_info;
}
-static int serial_omap_probe(struct platform_device *pdev)
+static int __devinit serial_omap_probe(struct platform_device *pdev)
{
struct uart_omap_port *up;
struct resource *mem, *irq, *dma_tx, *dma_rx;
@@ -1489,7 +1489,7 @@ err_port_line:
return ret;
}
-static int serial_omap_remove(struct platform_device *dev)
+static int __devexit serial_omap_remove(struct platform_device *dev)
{
struct uart_omap_port *up = platform_get_drvdata(dev);
@@ -1654,7 +1654,7 @@ MODULE_DEVICE_TABLE(of, omap_serial_of_match);
static struct platform_driver serial_omap_driver = {
.probe = serial_omap_probe,
- .remove = serial_omap_remove,
+ .remove = __devexit_p(serial_omap_remove),
.driver = {
.name = DRIVER_NAME,
.pm = &serial_omap_dev_pm_ops,
--
1.7.4.1
^ permalink raw reply related
* [PATCH 6/7] UART: OMAP: Remove the hardcode serial_omap_console_ports array.
From: Shubhrajyoti D @ 2012-04-16 15:07 UTC (permalink / raw)
To: linux-serial; +Cc: linux-omap, linux-arm-kernel, Shubhrajyoti D, Govindraj.R
In-Reply-To: <1334588821-5224-1-git-send-email-shubhrajyoti@ti.com>
Currently the array serial_omap_console_ports is hard coded to 4.
Make it depend on the maximum uart count.
Also fixes OMAP5 which has 6 instances of uart.
Cc: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
drivers/tty/serial/omap-serial.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 1593986..cbc9d64 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1040,7 +1040,7 @@ static int serial_omap_poll_get_char(struct uart_port *port)
#ifdef CONFIG_SERIAL_OMAP_CONSOLE
-static struct uart_omap_port *serial_omap_console_ports[4];
+static struct uart_omap_port *serial_omap_console_ports[OMAP_MAX_HSUART_PORTS];
static struct uart_driver serial_omap_reg;
--
1.7.4.1
^ permalink raw reply related
* [PATCH 4/7] UART: OMAP: Remove the default setting of special character
From: Shubhrajyoti D @ 2012-04-16 15:06 UTC (permalink / raw)
To: linux-serial; +Cc: linux-omap, linux-arm-kernel, Shubhrajyoti D, Govindraj.R
In-Reply-To: <1334588821-5224-1-git-send-email-shubhrajyoti@ti.com>
Special character detect enable if enabled by default.Received data
comparison with XOFF2 data happens by default.
tty provides only XOFF1 no X0FF2 is provided so no need
to enable check for XOFF2.
Keeping this enabled might give some slow transfers due to dummy xoff2
comparison with xoff2 reset value.
Since not all want the XOFF2 support lets not enable it by
default.
Cc: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
drivers/tty/serial/omap-serial.c | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 887d578..7c69b21 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -682,11 +682,7 @@ serial_omap_configure_xonxoff
serial_out(up, UART_MCR, up->mcr | UART_MCR_TCRTLR);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
serial_out(up, UART_TI752_TCR, OMAP_UART_TCR_TRIG);
- /* Enable special char function UARTi.EFR_REG[5] and
- * load the new software flow control mode IXON or IXOFF
- * and restore the UARTi.EFR_REG[4] ENHANCED_EN value.
- */
- serial_out(up, UART_EFR, up->efr | UART_EFR_SCD);
+
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
serial_out(up, UART_MCR, up->mcr & ~UART_MCR_TCRTLR);
--
1.7.4.1
^ permalink raw reply related
* [PATCH 3/7] UART: OMAP: fix software flow control
From: Shubhrajyoti D @ 2012-04-16 15:06 UTC (permalink / raw)
To: linux-serial
Cc: linux-omap, linux-arm-kernel, Vikram Pandita, stable, Govindraj.R,
Shubhrajyoti D
In-Reply-To: <1334588821-5224-1-git-send-email-shubhrajyoti@ti.com>
From: Vikram Pandita <vikram.pandita@ti.com>
Software flow control register bits were not defined correctly.
Also clarify the IXON and IXOFF logic to reflect what userspace wants.
Cc: stable@vger.kernel.org
Cc: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
arch/arm/plat-omap/include/plat/omap-serial.h | 4 ++--
drivers/tty/serial/omap-serial.c | 12 ++++++------
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
index b7fb6dc..6edc30a 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -42,10 +42,10 @@
#define OMAP_UART_WER_MOD_WKUP 0X7F
/* Enable XON/XOFF flow control on output */
-#define OMAP_UART_SW_TX 0x04
+#define OMAP_UART_SW_TX 0x8
/* Enable XON/XOFF flow control on input */
-#define OMAP_UART_SW_RX 0x04
+#define OMAP_UART_SW_RX 0x2
#define OMAP_UART_SYSC_RESET 0X07
#define OMAP_UART_TCR_TRIG 0X0F
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 10e80bb..887d578 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -651,19 +651,19 @@ serial_omap_configure_xonxoff
/*
* IXON Flag:
- * Enable XON/XOFF flow control on output.
- * Transmit XON1, XOFF1
+ * Flow control for OMAP.TX
+ * OMAP.RX should listen for XON/XOFF
*/
if (termios->c_iflag & IXON)
- up->efr |= OMAP_UART_SW_TX;
+ up->efr |= OMAP_UART_SW_RX;
/*
* IXOFF Flag:
- * Enable XON/XOFF flow control on input.
- * Receiver compares XON1, XOFF1.
+ * Flow control for OMAP.RX
+ * OMAP.TX should send XON/XOFF
*/
if (termios->c_iflag & IXOFF)
- up->efr |= OMAP_UART_SW_RX;
+ up->efr |= OMAP_UART_SW_TX;
serial_out(up, UART_EFR, up->efr | UART_EFR_ECB);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/7] ARM: OMAP: UART: Make context_loss_cnt signed
From: Shubhrajyoti D @ 2012-04-16 15:06 UTC (permalink / raw)
To: linux-serial; +Cc: linux-omap, linux-arm-kernel, Shubhrajyoti D, Govindraj.R
In-Reply-To: <1334588821-5224-1-git-send-email-shubhrajyoti@ti.com>
get_context_loss_count returns an int however it is stored in
unsigned integer context_loss_cnt . This patch tries to make
context_loss_cnt int. So that in case of errors(which may be negative)
the value is not interpreted wrongly.
In serial_omap_runtime_resume in case of errors returned by
get_context_loss_count print a warning and do a restore.
Cc: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
arch/arm/plat-omap/include/plat/omap-serial.h | 2 +-
drivers/tty/serial/omap-serial.c | 10 ++++++++--
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
index 9ff4444..b7fb6dc 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -128,7 +128,7 @@ struct uart_omap_port {
unsigned char msr_saved_flags;
char name[20];
unsigned long port_activity;
- u32 context_loss_cnt;
+ int context_loss_cnt;
u32 errata;
u8 wakeups_enabled;
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d00b38e..fe099bb 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1612,10 +1612,16 @@ static int serial_omap_runtime_resume(struct device *dev)
if (up && pdata) {
if (pdata->get_context_loss_count) {
- u32 loss_cnt = pdata->get_context_loss_count(dev);
+ int loss_cnt = pdata->get_context_loss_count(dev);
- if (up->context_loss_cnt != loss_cnt)
+ if (loss_cnt < 0) {
+ dev_err(dev,
+ "get_context_loss_count failed : %d\n",
+ loss_cnt);
serial_omap_restore_context(up);
+ } else if (up->context_loss_cnt != loss_cnt) {
+ serial_omap_restore_context(up);
+ }
}
/* Errata i291 */
--
1.7.4.1
^ permalink raw reply related
* [PATCH] tty: omap-serial: Keep the wakeup mechanism enabled by default
From: Govindraj.R @ 2012-04-16 12:30 UTC (permalink / raw)
To: linux-omap
Cc: linux-serial, linux-arm-kernel, Govindraj.R, Paul Walmsley,
Kevin Hilman
From: "Govindraj.R" <govindraj.raja@ti.com>
The wakeups can be left enabled by default and should be disabled
only when disabled from sysfs and while entering suspend.
Thanks to Kevin Hilman <khilman@ti.com> for suggesting this.
Discussion References:
http://www.spinics.net/lists/linux-omap/msg67764.html
http://www.spinics.net/lists/linux-omap/msg67838.html
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
---
drivers/tty/serial/omap-serial.c | 30 +++++++++++-------------------
1 files changed, 11 insertions(+), 19 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d00b38e..4a92447 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -930,13 +930,6 @@ serial_omap_pm(struct uart_port *port, unsigned int state,
serial_out(up, UART_EFR, efr);
serial_out(up, UART_LCR, 0);
- if (!device_may_wakeup(&up->pdev->dev)) {
- if (!state)
- pm_runtime_forbid(&up->pdev->dev);
- else
- pm_runtime_allow(&up->pdev->dev);
- }
-
pm_runtime_put(&up->pdev->dev);
}
@@ -1184,10 +1177,16 @@ static struct uart_driver serial_omap_reg = {
static int serial_omap_suspend(struct device *dev)
{
struct uart_omap_port *up = dev_get_drvdata(dev);
+ struct omap_uart_port_info *pdata = dev->platform_data;
if (up) {
uart_suspend_port(&serial_omap_reg, &up->port);
flush_work_sync(&up->qos_work);
+
+ if (!device_may_wakeup(dev)) {
+ pdata->enable_wakeup(up->pdev, false);
+ up->wakeups_enabled = false;
+ }
}
return 0;
@@ -1582,18 +1581,6 @@ static int serial_omap_runtime_suspend(struct device *dev)
if (pdata->get_context_loss_count)
up->context_loss_cnt = pdata->get_context_loss_count(dev);
- if (device_may_wakeup(dev)) {
- if (!up->wakeups_enabled) {
- pdata->enable_wakeup(up->pdev, true);
- up->wakeups_enabled = true;
- }
- } else {
- if (up->wakeups_enabled) {
- pdata->enable_wakeup(up->pdev, false);
- up->wakeups_enabled = false;
- }
- }
-
/* Errata i291 */
if (up->use_dma && pdata->set_forceidle &&
(up->errata & UART_ERRATA_i291_DMA_FORCEIDLE))
@@ -1618,6 +1605,11 @@ static int serial_omap_runtime_resume(struct device *dev)
serial_omap_restore_context(up);
}
+ if (!up->wakeups_enabled) {
+ pdata->enable_wakeup(up->pdev, true);
+ up->wakeups_enabled = true;
+ }
+
/* Errata i291 */
if (up->use_dma && pdata->set_noidle &&
(up->errata & UART_ERRATA_i291_DMA_FORCEIDLE))
--
1.7.9
^ permalink raw reply related
* Re: omap-serial: transmission of x-char with DMA (and other issues)
From: Russell King - ARM Linux @ 2012-04-16 11:19 UTC (permalink / raw)
To: Raja, Govindraj; +Cc: linux-omap, linux-serial
In-Reply-To: <CAMrsUd+Wr=txEKSa=R0ybbd2k5Wue=KZzt82ZMtszL=7_moRLA@mail.gmail.com>
On Mon, Apr 16, 2012 at 04:39:09PM +0530, Raja, Govindraj wrote:
> On Fri, Apr 13, 2012 at 4:11 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > Can someone tell me how this works with the current omap-serial driver
> > please? It looks to me like this has been broken when DMA support was
> > added to the driver.
>
> Yes x-char transmission in dma case is broken will post a patch to fix this.
Looking at the facilities of the OMAP UART hardware and the behaviour of
the DMA hardware, I don't think we have an option to manually insert an
x-char into the data stream. We certainly can't pause TX DMA at the
DMA hardware without the DMA hardware aborting and flushing its FIFO,
and the UART has no way to temporarily suspend requesting DMA service.
So, I think we actually need a pair of new hooks from uart_throttle()
and uart_unthrottle() for these automatic flow control UARTs which
disable the RX FIFO being read (iow, disable RX interrupts if using PIO
or RX DMA if using DMA.) The RX FIFO will then fill, and if the watermarks
are set correctly along with hardware-assisted flow control, the UART
will send the XOFF or deassert RTS for us automatically.
At least with RX DMA (which is hardware source synchronised), the DMA
hardware will apparantly drain its FIFOs to memory when disabled, rather
than aborting and discarding its FIFO contents.
> > Moreover, please look at the probe function error paths. They seem to
> > be lacking any kind of realistic cleanup, so are a potential memory leak.
>
> I thought this is fixed in 3.4-rc3 with this commit:
>
> commit 388bc26226807fbcf4c626b81bb17a2e74aa4b1b
> Author: Shubhrajyoti D <shubhrajyoti@ti.com>
> Date: Wed Mar 21 17:22:22 2012 +0530
>
> omap-serial: Fix the error handling in the omap_serial probe
Well, it also depends on where I base my branches for development - and
if fixes go in after I've started then these things get missed until I
rebase those branches.
If it's already fixed, then great.
> > Then there's the issue of fiddling with the xmit buffer so that it's
> > using coherent memory in the startup and shutdown functions (why? when
> > other serial drivers cope just fine without doing this). If we want to
> > use DMA coherent memory there, there should be a clean way to do this,
> > rather than going behind the upper layers.
>
> Okay I will have a look into this.
I've already cooked up a patch to handle this which adds new hooks from
serial_core into the low level driver for xmit buffer allocation/freeing.
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: omap-serial: transmission of x-char with DMA (and other issues)
From: Raja, Govindraj @ 2012-04-16 11:09 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: linux-omap, linux-serial
In-Reply-To: <20120413104111.GF25053@n2100.arm.linux.org.uk>
On Fri, Apr 13, 2012 at 4:11 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> Can someone tell me how this works with the current omap-serial driver
> please? It looks to me like this has been broken when DMA support was
> added to the driver.
Yes x-char transmission in dma case is broken will post a patch to fix this.
>
> Moreover, please look at the probe function error paths. They seem to
> be lacking any kind of realistic cleanup, so are a potential memory leak.
I thought this is fixed in 3.4-rc3 with this commit:
commit 388bc26226807fbcf4c626b81bb17a2e74aa4b1b
Author: Shubhrajyoti D <shubhrajyoti@ti.com>
Date: Wed Mar 21 17:22:22 2012 +0530
omap-serial: Fix the error handling in the omap_serial probe
>
> Then there's the issue of fiddling with the xmit buffer so that it's
> using coherent memory in the startup and shutdown functions (why? when
> other serial drivers cope just fine without doing this). If we want to
> use DMA coherent memory there, there should be a clean way to do this,
> rather than going behind the upper layers.
Okay I will have a look into this.
--
Thanks,
Govindraj.R
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* omap-serial: transmission of x-char with DMA (and other issues)
From: Russell King - ARM Linux @ 2012-04-13 10:41 UTC (permalink / raw)
To: linux-omap, linux-serial
Can someone tell me how this works with the current omap-serial driver
please? It looks to me like this has been broken when DMA support was
added to the driver.
Moreover, please look at the probe function error paths. They seem to
be lacking any kind of realistic cleanup, so are a potential memory leak.
Then there's the issue of fiddling with the xmit buffer so that it's
using coherent memory in the startup and shutdown functions (why? when
other serial drivers cope just fine without doing this). If we want to
use DMA coherent memory there, there should be a clean way to do this,
rather than going behind the upper layers.
^ permalink raw reply
* [GIT PATCH] TTY/serial patches for 3.4-rc2
From: Greg KH @ 2012-04-12 22:26 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton; +Cc: linux-kernel, linux-serial
The following changes since commit dd775ae2549217d3ae09363e3edb305d0fa19928:
Linux 3.4-rc1 (2012-03-31 16:24:09 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-3.4-rc2
for you to fetch changes up to 11bbd5b6dae49fd7072ebf5eb63735827bd72f42:
pch_uart: Add Kontron COMe-mTT10 uart clock quirk (2012-04-09 10:58:41 -0700)
----------------------------------------------------------------
tty and serial fixes for 3.4-rc2
Here are some tty and serial fixes for 3.4-rc2.
Most important here is the pl011 fix, which has been reported by about
100 different people, which means more people use it than I expected :)
There are also some 8250 driver reverts due to some problems reported by
them. And other minor fixes as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Arnd Bergmann (1):
tty/serial/omap: console can only be built-in
Dan Williams (3):
Revert "serial/8250_pci: init-quirk msi support for kt serial controller"
Revert "serial/8250_pci: setup-quirk workaround for the kt serial controller"
serial/8250_pci: add a "force background timer" flag and use it for the "kt" serial port
Kay Sievers (1):
printk(): add KERN_CONT where needed in hpet and vt code
Kukjin Kim (1):
serial: samsung: fix omission initialize ulcon in reset port fn()
Linus Walleij (1):
serial: PL011: move interrupt clearing
Michael Brunner (1):
pch_uart: Add Kontron COMe-mTT10 uart clock quirk
Shubhrajyoti D (1):
omap-serial: Fix the error handling in the omap_serial probe
Siftar, Gabe (1):
tty/serial: atmel_serial: fix RS485 half-duplex problem
Tilman Schmidt (1):
isdn/gigaset: use gig_dbg() for debugging output
Tomoya MORINAGA (1):
pch_uart: Fix MSI setting issue
Yuriy Kozlov (1):
tty: serial: altera_uart: Check for NULL platform_data in probe.
drivers/char/hpet.c | 4 ++--
drivers/isdn/gigaset/interface.c | 2 +-
drivers/tty/serial/8250/8250.c | 12 +++++-----
drivers/tty/serial/8250/8250_pci.c | 16 +-------------
drivers/tty/serial/Kconfig | 2 +-
drivers/tty/serial/altera_uart.c | 4 ++--
drivers/tty/serial/amba-pl011.c | 8 +++----
drivers/tty/serial/atmel_serial.c | 4 ++++
drivers/tty/serial/omap-serial.c | 43 +++++++++++++++++-------------------
drivers/tty/serial/pch_uart.c | 8 +++++++
drivers/tty/serial/samsung.c | 1 +
drivers/tty/vt/vt.c | 3 +--
include/linux/serial_core.h | 2 +-
13 files changed, 52 insertions(+), 57 deletions(-)
^ permalink raw reply
* Re: Suspend broken on 3.3?
From: Raja, Govindraj @ 2012-04-12 11:51 UTC (permalink / raw)
To: Paul Walmsley
Cc: Kevin Hilman, Joe Woodward, linux-omap, Felipe Balbi, neilb,
linux-serial
In-Reply-To: <alpine.DEB.2.00.1204111323210.29473@utopia.booyaka.com>
On Thu, Apr 12, 2012 at 1:04 AM, Paul Walmsley <paul@pwsan.com> wrote:
> Hi
>
> a few brief comments based on a quick scan:
>
> On Wed, 11 Apr 2012, Raja, Govindraj wrote:
>
>> Here is the patch [1] to do the same.
>
> - I don't see where it affects I/O wakeups for the UART. If I/O wakeups
> are still set on the UART pads, won't that still wake the chip up from
> suspend, even if module-level wakeups are disabled?
pdata->enable_wakeup => omap_uart_enable_wakeup
was disabling both module level and pad wakeup.
omap_uart_enable_wakeup => has enabling/disabling both
module level and pad wakeup together.
>
> - The UART driver and integration code should not be reading from or
> writing to registers outside the UART IP block. PRM register reads and
> writes belong in the PRM code, which should then export a higher-level
> interface to the calling code. This is because, aside from making the
> code easier to read and debug, we're trying to move the PRM and CM code to
> drivers/.
okay.
>
> - The code to change the PM_WKEN* and test the PM_WKST* bits should
> probably be called from omap_hwmod_{enable,disable}_wakeup(), not the UART
> code directly. The UART code shouldn't need to care about the hardware
> details; it should just ask the integration layer to enable or disable
> module-level wakeups.
To implement this I plan to extend the omap_hwmod_omap2_prcm structure
like this:
(unaligned tmp code snippet)
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 8070145..5c7711b 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -343,6 +343,8 @@ struct omap_hwmod_class_sysconfig {
* @idlest_reg_id: IDLEST register ID (e.g., 3 for CM_IDLEST3)
* @idlest_idle_bit: register bit shift for CM_IDLEST slave idle bit
* @idlest_stdby_bit: register bit shift for CM_IDLEST master standby bit
+ * @module_wakeup_offs: PRCM register offset for PM_WKEN
+ * @module_wakeup_bit: regiter bit mask for PM_WKEN
*
* @prcm_reg_id and @module_bit are specific to the AUTOIDLE, WKST,
* WKEN, GRPSEL registers. In an ideal world, no extra information
@@ -357,6 +359,8 @@ struct omap_hwmod_omap2_prcm {
u8 idlest_reg_id;
u8 idlest_idle_bit;
u8 idlest_stdby_bit;
+ s16 module_wakeup_offs;
+ u32 module_wakeup_bit;
};
>
> As you work on these changes, please split them up into several different
> topic series - one for the PRM changes, one for hwmod code/data changes,
> and one for the UART driver/integration changes. Just note the
> dependencies in the series description E-mails. That way, we can avoid
> merge conflicts.
>
Yes fine. Since most changes will be on /mach-omap2/omap_hwmod*.c
Do you prefer the patches to be on any particular tree/branch where hwmod fixes
are already queued.
--
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
^ permalink raw reply related
* (unknown),
From: monicaaluke01@gmail.com @ 2012-04-12 11:21 UTC (permalink / raw)
Do you need a loan?
Вам нужен кредит?
^ permalink raw reply
* Re: [PATCH] serial: 8250: Add cpufreq support
From: Alan Cox @ 2012-04-12 9:47 UTC (permalink / raw)
To: Shankarmurthy, Akshay
Cc: linux-serial@vger.kernel.org, alan@linux.intel.com,
gregkh@linuxfoundation.org, paul.gortmaker@windriver.com,
jamie@jamieiles.com, swarren@nvidia.com, dianders@chromium.org,
davinci-linux-open-source@linux.davincidsp.com,
linux-kernel@vger.kernel.org
In-Reply-To: <6F6B80BD2E18844D97BB4B51FE3705C83179146B@DBDE01.ent.ti.com>
> > > I will have a look at this and add the lock if necessary.
> >
> > At the very least you need reference counts held on the tty struct and to allow for the tty having vanished under you.
> >
>
> I am planning to add "tty->termios_mutex" lock. Any comments ?
Explain how this will help. You need a reference count to the tty itself.
> I understand this and planning to avoid unnecessary registration like these.
> As a solution, UART port's cpu freq status will be sent from the board file.
> Adding a member to the structure "plat_serial8250_port" which says whether
> a port requires cpu freq registration or not. cpu freq register function is
> called in the driver depending upon the status of this structure member.
> I can update the patch accordingly and send out a version 2 to the list.
That sounds sensible.
Alan
^ permalink raw reply
* RE: [PATCH] serial: 8250: Add cpufreq support
From: Shankarmurthy, Akshay @ 2012-04-12 5:21 UTC (permalink / raw)
To: Alan Cox
Cc: linux-serial@vger.kernel.org, alan@linux.intel.com,
gregkh@linuxfoundation.org, paul.gortmaker@windriver.com,
jamie@jamieiles.com, swarren@nvidia.com, dianders@chromium.org,
davinci-linux-open-source@linux.davincidsp.com,
linux-kernel@vger.kernel.org
In-Reply-To: <20120405115322.15e6088c@pyramind.ukuu.org.uk>
On Thu, Apr 05, 2012 at 16:23:22, Alan Cox wrote:
> On Thu, 5 Apr 2012 10:40:55 +0000
> "Shankarmurthy, Akshay" <akshay.s@ti.com> wrote:
>
> > Hi,
> >
> > On Tue, Apr 03, 2012 at 15:25:30, Alan Cox wrote:
> > > > This patch was submitted 2 years ago but didn't make it to the mainline. Now i am reposting it.
> > >
> > > Can you fix it instead of just reposting it ?
> > >
> > >
> > > > +#ifdef CONFIG_CPU_FREQ
> > > > +static int serial8250_cpufreq_transition(struct notifier_block *nb,
> > > > + unsigned long val, void *data) {
> > > > + struct uart_8250_port *p;
> > > > + struct uart_port *uport;
> > >
> > > What is your locking model ?
> > >
> >
> > I will have a look at this and add the lock if necessary.
>
> At the very least you need reference counts held on the tty struct and to allow for the tty having vanished under you.
>
I am planning to add "tty->termios_mutex" lock. Any comments ?
> > >
> > > > +static inline void serial8250_cpufreq_deregister(struct
> > > > +uart_8250_port *p)
> > >
> > > unregister
> >
> > Ok. I will change it.
> >
> > >
> > > > + ret = serial8250_cpufreq_register(uart);
> > > > + if (ret < 0)
> > > > + printk(KERN_ERR "Failed to add cpufreq notifier\n");
> > >
> > > Why do this for devices that don't care.
> >
> > This is taken care in the code. If the device's frequency doesn't
> > change after the change in the cpu frequency then it doesn't go for execution of the function "serial8250_set_termios".
>
> But you still call each function and walk the list for each port on each CPU transition. There are people with 128 ports in their systems and the cpu frequency change is latency critical.
>
> Nothing should even be getting registered in such cases.
>
I understand this and planning to avoid unnecessary registration like these.
As a solution, UART port's cpu freq status will be sent from the board file.
Adding a member to the structure "plat_serial8250_port" which says whether
a port requires cpu freq registration or not. cpu freq register function is
called in the driver depending upon the status of this structure member.
I can update the patch accordingly and send out a version 2 to the list.
Regards,
Akshay
^ permalink raw reply
* [PATCH v2][RESEND] pch_uart: Fix dma channel unallocated issue
From: Tomoya MORINAGA @ 2012-04-12 1:47 UTC (permalink / raw)
To: Alan Cox, Greg Kroah-Hartman, linux-serial, linux-kernel
Cc: qi.wang, yong.y.wang, joel.clark, kok.howg.ewe, Tomoya MORINAGA
This driver anticipates pch_uart_verify_port() is not called
during installation.
However, actually pch_uart_verify_port() is called during
installation.
As a result, memory access violation occurs like below.
0. initial value: use_dma=0
1. starup()
- dma channel is not allocated because use_dma=0
2. pch_uart_verify_port()
- Set use_dma=1
3. UART processing acts DMA mode because use_dma=1
- memory access violation occurs!
This patch fixes the issue.
Solution:
Whenever pch_uart_verify_port() is called and then
dma channel is not allocated, the channel should be allocated.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
---
v2: Re-create this patch for 3.4-rc2.
(RESEND) 1st v2 was sent to stable@vger.kernel.org. So, resend this patch
with correct destination address.
---
drivers/tty/serial/pch_uart.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/pch_uart.c b/drivers/tty/serial/pch_uart.c
index 08b9962..80a32cf 100644
--- a/drivers/tty/serial/pch_uart.c
+++ b/drivers/tty/serial/pch_uart.c
@@ -1440,9 +1440,11 @@ static int pch_uart_verify_port(struct uart_port *port,
__func__);
return -EOPNOTSUPP;
#endif
- priv->use_dma = 1;
priv->use_dma_flag = 1;
dev_info(priv->port.dev, "PCH UART : Use DMA Mode\n");
+ if (!priv->use_dma)
+ pch_request_dma(port);
+ priv->use_dma = 1;
}
return 0;
--
1.7.7.6
^ permalink raw reply related
* Re: Suspend broken on 3.3?
From: Paul Walmsley @ 2012-04-11 19:34 UTC (permalink / raw)
To: Raja, Govindraj
Cc: Kevin Hilman, Joe Woodward, linux-omap, Felipe Balbi, neilb,
linux-serial
In-Reply-To: <CAMrsUd+-5_6dFxcj=BCt+gHwnzA7zBev0t_nQ3dQAGZzWq8X0w@mail.gmail.com>
Hi
a few brief comments based on a quick scan:
On Wed, 11 Apr 2012, Raja, Govindraj wrote:
> Here is the patch [1] to do the same.
- I don't see where it affects I/O wakeups for the UART. If I/O wakeups
are still set on the UART pads, won't that still wake the chip up from
suspend, even if module-level wakeups are disabled?
- The UART driver and integration code should not be reading from or
writing to registers outside the UART IP block. PRM register reads and
writes belong in the PRM code, which should then export a higher-level
interface to the calling code. This is because, aside from making the
code easier to read and debug, we're trying to move the PRM and CM code to
drivers/.
- The code to change the PM_WKEN* and test the PM_WKST* bits should
probably be called from omap_hwmod_{enable,disable}_wakeup(), not the UART
code directly. The UART code shouldn't need to care about the hardware
details; it should just ask the integration layer to enable or disable
module-level wakeups.
As you work on these changes, please split them up into several different
topic series - one for the PRM changes, one for hwmod code/data changes,
and one for the UART driver/integration changes. Just note the
dependencies in the series description E-mails. That way, we can avoid
merge conflicts.
- Paul
^ permalink raw reply
* Re: [PATCH v3 4/4] ARM: omap: pass minimal SoC/board data for UART from dt
From: Ramirez Luna, Omar @ 2012-04-11 15:57 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Rajendra Nayak, linux-serial, linux-omap, devicetree-discuss,
khilman, tony, govindraj.raja, linux-arm-kernel, linaro-dev,
patches, robherring2
In-Reply-To: <4F85435C.1060305@ti.com>
On Wed, Apr 11, 2012 at 3:39 AM, Cousson, Benoit <b-cousson@ti.com> wrote:
> Yes, it is a known issue and the fix was unfortunately was not merged during
> -rc phases but is fixed in 3.4 and should be fixed in 3.3 stable branch as
> well. I received the notification from Greg KH 2 weeks ago about the stable:
> Patch "tty: serial: OMAP: Fix oops due to NULL pdata in DT boot" has been
> added to the 3.3-stable tree
>
> You should just switch to 3.4-rc2 or get the patch if you are stuck to 3.3.
Thanks, switching to 3.4-rc kernels fixed the problem (for cramfs),
and right now this works for me.
Regards,
Omar
^ permalink raw reply
* Re: Suspend broken on 3.3?
From: Raja, Govindraj @ 2012-04-11 13:13 UTC (permalink / raw)
To: Kevin Hilman
Cc: Paul Walmsley, Joe Woodward, linux-omap, Felipe Balbi, neilb,
linux-serial
In-Reply-To: <87fwcb5urr.fsf@ti.com>
On Tue, Apr 10, 2012 at 11:33 PM, Kevin Hilman <khilman@ti.com> wrote:
> "Raja, Govindraj" <govindraj.raja@ti.com> writes:
>
>> Hi Kevin,
>>
>> On Mon, Apr 9, 2012 at 10:40 PM, Kevin Hilman <khilman@ti.com> wrote:
>>> Paul Walmsley <paul@pwsan.com> writes:
[...]
>>
>> Just to summarize on how the behavior should be IIUC if user disables uart
>> wakeup from sysfs and does system wide suspend it should _not_ wakeup
>> from uart.
>
> Correct.
>
>> And if the system is woken up from suspend due to keypad press and
>> uart resumes we have keep module level wakeup enabled from here.
>
> Keypad press, or any other wakeup source, yes.
>
> Basically, UART wakeups (module and IO) should be enabled all the time,
> *except* when suspending and wakeups were disabled by sysfs control.
>
Here is the patch [1] to do the same.
Tested on beagle-XM with retention and off mode in suspend path and
idle path by disabling/enabling the uart wakeups from sysfs for the console.
--
Thanks,
Govindraj.R
[1]:
>From 4e2502015e8b69d3a5047ae9f92820e4833e6d74 Mon Sep 17 00:00:00 2001
From: "Govindraj.R" <govindraj.raja@ti.com>
Date: Tue, 27 Mar 2012 18:55:00 +0530
Subject: [PATCH] OMAP2+: UART: Correct the module level wakeup enable/disable
mechanism
The commit (62f3ec5 ARM: OMAP2+: UART: Add wakeup mechanism for omap-uarts)
removed module level wakeup enable/disable mechanism and retained only
the pad wakeup handling.
On 24xx/34xx/36xx Module level wakeup events are enabled/disabled using
PM_WKEN1_CORE/PM_WKEN_PER regs. The module level wakeups are enabled by
default from bootloader, however the wakeups can be enabled/disabled
using sysfs entry
echo disabled > /sys/devices/platform/omap/omap_uart.X/power/wakeup
[X=0,1,2,3]
Since module level wakeups were left enabled from bootup and when
wakeups were disabled from sysfs uart module level wakeups were
still happening as they were not getting disabled.
The wakeup can be left enabled by default and should be disabled only
when disabled from sysfs and thus prevent system from uart wakeup in suspend
path. However in idle path the wakeup can be enabled and thus uart can wakeup
after gating of uart functional clocks.
Thanks to Kevin Hilman <khilman@ti.com> for suggesting this.
Discussion References:
http://www.spinics.net/lists/linux-omap/msg67764.html
http://www.spinics.net/lists/linux-omap/msg67838.html
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
---
arch/arm/mach-omap2/serial.c | 88 +++++++++++++++++++++++++++++++++++++-
drivers/tty/serial/omap-serial.c | 30 +++++--------
2 files changed, 97 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0cdd359..9312d6b 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -41,6 +41,7 @@
#include "prm-regbits-34xx.h"
#include "control.h"
#include "mux.h"
+#include "iomap.h"
/*
* NOTE: By default the serial auto_suspend timeout is disabled as it causes
@@ -55,6 +56,10 @@
struct omap_uart_state {
int num;
+ void __iomem *wk_st;
+ void __iomem *wk_en;
+ u32 wk_mask;
+
struct list_head node;
struct omap_hwmod *oh;
};
@@ -80,17 +85,46 @@ static struct omap_uart_port_info
omap_serial_default_info[] __initdata = {
};
#ifdef CONFIG_PM
+
+static void omap_uart_disable_module_wakeup(struct omap_uart_state *uart)
+{
+ /* Clear wake-enable bit */
+ if (uart->wk_en && uart->wk_mask) {
+ u32 v = __raw_readl(uart->wk_en);
+ v &= ~uart->wk_mask;
+ __raw_writel(v, uart->wk_en);
+ }
+}
+
+static void omap_uart_enable_module_wakeup(struct omap_uart_state *uart)
+{
+ /* Set wake-enable bit */
+ if (uart->wk_en && uart->wk_mask) {
+ u32 v = __raw_readl(uart->wk_en);
+ v |= uart->wk_mask;
+ __raw_writel(v, uart->wk_en);
+ }
+}
+
static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
{
struct omap_device *od = to_omap_device(pdev);
+ struct omap_uart_state *uart;
if (!od)
return;
- if (enable)
+ list_for_each_entry(uart, &uart_list, node)
+ if (pdev->id == uart->num)
+ break;
+
+ if (enable) {
+ omap_uart_enable_module_wakeup(uart);
omap_hwmod_enable_wakeup(od->hwmods[0]);
- else
+ } else {
+ omap_uart_disable_module_wakeup(uart);
omap_hwmod_disable_wakeup(od->hwmods[0]);
+ }
}
/*
@@ -112,7 +146,56 @@ static void omap_uart_set_smartidle(struct
platform_device *pdev)
omap_hwmod_set_slave_idlemode(od->hwmods[0], HWMOD_IDLEMODE_SMART);
}
+static void omap_uart_idle_init(struct omap_uart_state *uart)
+{
+ if (cpu_is_omap34xx() && !cpu_is_ti816x()) {
+ u32 mod = (uart->num == 2) ? OMAP3430_PER_MOD : CORE_MOD;
+
+ uart->wk_en = OMAP34XX_PRM_REGADDR(mod, PM_WKEN1);
+ uart->wk_st = OMAP34XX_PRM_REGADDR(mod, PM_WKST1);
+ switch (uart->num) {
+ case 0:
+ uart->wk_mask = OMAP3430_ST_UART1_MASK;
+ break;
+ case 1:
+ uart->wk_mask = OMAP3430_ST_UART2_MASK;
+ break;
+ case 2:
+ uart->wk_mask = OMAP3430_ST_UART3_MASK;
+ break;
+ case 3:
+ uart->wk_mask = OMAP3630_ST_UART4_MASK;
+ break;
+ }
+ } else if (cpu_is_omap24xx()) {
+
+ if (cpu_is_omap2430()) {
+ uart->wk_en = OMAP2430_PRM_REGADDR(CORE_MOD, PM_WKEN1);
+ uart->wk_st = OMAP2430_PRM_REGADDR(CORE_MOD, PM_WKST1);
+ } else if (cpu_is_omap2420()) {
+ uart->wk_en = OMAP2420_PRM_REGADDR(CORE_MOD, PM_WKEN1);
+ uart->wk_st = OMAP2420_PRM_REGADDR(CORE_MOD, PM_WKST1);
+ }
+ switch (uart->num) {
+ case 0:
+ uart->wk_mask = OMAP24XX_ST_UART1_MASK;
+ break;
+ case 1:
+ uart->wk_mask = OMAP24XX_ST_UART2_MASK;
+ break;
+ case 2:
+ uart->wk_mask = OMAP24XX_ST_UART3_MASK;
+ break;
+ }
+ } else {
+ uart->wk_en = 0;
+ uart->wk_st = 0;
+ uart->wk_mask = 0;
+ }
+}
+
#else
+static void omap_uart_idle_init(struct omap_uart_state *uart) {}
static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
{}
static void omap_uart_set_noidle(struct platform_device *pdev) {}
@@ -343,6 +426,7 @@ void __init omap_serial_init_port(struct
omap_board_data *bdata,
oh = uart->oh;
name = DRIVER_NAME;
+ omap_uart_idle_init(uart);
omap_up.dma_enabled = info->dma_enabled;
omap_up.uartclk = OMAP24XX_BASE_BAUD * 16;
omap_up.flags = UPF_BOOT_AUTOCONF;
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 0121486..3dec1cf 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -930,13 +930,6 @@ serial_omap_pm(struct uart_port *port, unsigned int state,
serial_out(up, UART_EFR, efr);
serial_out(up, UART_LCR, 0);
- if (!device_may_wakeup(&up->pdev->dev)) {
- if (!state)
- pm_runtime_forbid(&up->pdev->dev);
- else
- pm_runtime_allow(&up->pdev->dev);
- }
-
pm_runtime_put(&up->pdev->dev);
}
@@ -1184,10 +1177,16 @@ static struct uart_driver serial_omap_reg = {
static int serial_omap_suspend(struct device *dev)
{
struct uart_omap_port *up = dev_get_drvdata(dev);
+ struct omap_uart_port_info *pdata = dev->platform_data;
if (up) {
uart_suspend_port(&serial_omap_reg, &up->port);
flush_work_sync(&up->qos_work);
+
+ if (!device_may_wakeup(dev)) {
+ pdata->enable_wakeup(up->pdev, false);
+ up->wakeups_enabled = false;
+ }
}
return 0;
@@ -1585,18 +1584,6 @@ static int serial_omap_runtime_suspend(struct
device *dev)
if (pdata->get_context_loss_count)
up->context_loss_cnt = pdata->get_context_loss_count(dev);
- if (device_may_wakeup(dev)) {
- if (!up->wakeups_enabled) {
- pdata->enable_wakeup(up->pdev, true);
- up->wakeups_enabled = true;
- }
- } else {
- if (up->wakeups_enabled) {
- pdata->enable_wakeup(up->pdev, false);
- up->wakeups_enabled = false;
- }
- }
-
/* Errata i291 */
if (up->use_dma && pdata->set_forceidle &&
(up->errata & UART_ERRATA_i291_DMA_FORCEIDLE))
@@ -1621,6 +1608,11 @@ static int serial_omap_runtime_resume(struct device *dev)
serial_omap_restore_context(up);
}
+ if (!up->wakeups_enabled) {
+ pdata->enable_wakeup(up->pdev, true);
+ up->wakeups_enabled = true;
+ }
+
/* Errata i291 */
if (up->use_dma && pdata->set_noidle &&
(up->errata & UART_ERRATA_i291_DMA_FORCEIDLE))
--
1.7.9
^ permalink raw reply related
* Re: [PATCH v3 4/4] ARM: omap: pass minimal SoC/board data for UART from dt
From: Cousson, Benoit @ 2012-04-11 8:39 UTC (permalink / raw)
To: Ramirez Luna, Omar
Cc: Rajendra Nayak, linux-serial, linux-omap, devicetree-discuss,
khilman, tony, govindraj.raja, linux-arm-kernel, linaro-dev,
patches, robherring2
In-Reply-To: <CAB-zwWjSSsR0XMrntkEmHDtgJ_zDxgJh6KX=TsSKggd9mCgsVQ@mail.gmail.com>
Hi Omar,
On 4/11/2012 2:16 AM, Ramirez Luna, Omar wrote:
> Hi,
>
> On Wed, Dec 14, 2011 at 5:55 AM, Rajendra Nayak<rnayak@ti.com> wrote:
>> Pass minimal data needed for console boot, from dt, for
>> OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
>> static initialization from generic board file.
> ...
>> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
>> index 63b5416..a508ed5 100644
>> --- a/arch/arm/mach-omap2/board-generic.c
>> +++ b/arch/arm/mach-omap2/board-generic.c
>> @@ -69,7 +69,6 @@ static void __init omap_generic_init(void)
>> if (node)
>> irq_domain_add_simple(node, 0);
>>
>> - omap_serial_init();
>> omap_sdrc_init(NULL, NULL);
>>
>> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
>> --
>> 1.7.1
>
> I'm fairly new to DT and I'm trying to boot it with pandaboard and
> k3.3, however above hunk deletes omap serial initialization, which
> causes a panic on boot, because pdata is NULL:
>
> static void serial_omap_start_tx(struct uart_port *port)
> {
> ...
> if (pdata->set_noidle)
>
> Perhaps because this change skips the following path:
>
> omap_serial_init->omap_serial_board_init->omap_serial_init_port
>
> Where pdata is built in omap_device_build.
>
> I'm just trying to confirm that I'm not alone or doing some silly
> thing before getting in depth with the code.
Yes, it is a known issue and the fix was unfortunately was not merged
during -rc phases but is fixed in 3.4 and should be fixed in 3.3 stable
branch as well. I received the notification from Greg KH 2 weeks ago
about the stable: Patch "tty: serial: OMAP: Fix oops due to NULL pdata
in DT boot" has been added to the 3.3-stable tree
You should just switch to 3.4-rc2 or get the patch if you are stuck to 3.3.
Regards,
Benoit
^ permalink raw reply
* Re: [PATCH v3 4/4] ARM: omap: pass minimal SoC/board data for UART from dt
From: Ramirez Luna, Omar @ 2012-04-11 0:16 UTC (permalink / raw)
To: Rajendra Nayak
Cc: khilman-l0cyMroinI0, linaro-dev-cunTk1MwBs8s++Sfvej+rw,
patches-QSEj5FYQhm4dnm+yROfE0A, tony-4v6yS6AI5VpBDgjK7y7TUQ,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
govindraj.raja-l0cyMroinI0, linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1323863746-18145-5-git-send-email-rnayak-l0cyMroinI0@public.gmane.org>
Hi,
On Wed, Dec 14, 2011 at 5:55 AM, Rajendra Nayak <rnayak-l0cyMroinI0@public.gmane.org> wrote:
> Pass minimal data needed for console boot, from dt, for
> OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
> static initialization from generic board file.
...
> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> index 63b5416..a508ed5 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -69,7 +69,6 @@ static void __init omap_generic_init(void)
> if (node)
> irq_domain_add_simple(node, 0);
>
> - omap_serial_init();
> omap_sdrc_init(NULL, NULL);
>
> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> --
> 1.7.1
I'm fairly new to DT and I'm trying to boot it with pandaboard and
k3.3, however above hunk deletes omap serial initialization, which
causes a panic on boot, because pdata is NULL:
static void serial_omap_start_tx(struct uart_port *port)
{
...
if (pdata->set_noidle)
Perhaps because this change skips the following path:
omap_serial_init->omap_serial_board_init->omap_serial_init_port
Where pdata is built in omap_device_build.
I'm just trying to confirm that I'm not alone or doing some silly
thing before getting in depth with the code.
Here it is the panic:
[ 2.024688] Unable to handle kernel NULL pointer dereference at
virtual address 00000028
[ 2.031005] pgd = ed6f0000
[ 2.036315] [00000028] *pgd=af339831, *pte=00000000, *ppte=00000000
[ 2.042907] Internal error: Oops: 17 [#1] SMP
[ 2.046630] Modules linked in:
[ 2.046630] CPU: 0 Not tainted (3.3.0-00002-gda19af1-dirty #11)
[ 2.046630] PC is at serial_omap_start_tx+0x1cc/0x218
[ 2.046630] LR is at serial_omap_start_tx+0x1b8/0x218
[ 2.067840] pc : [<c02b3a54>] lr : [<c02b3a40>] psr: 60000193
[ 2.067840] sp : c21cbe70 ip : 00000001 fp : a0000113
[ 2.073699] r10: ef107000 r9 : ed684600 r8 : 0000001c
[ 2.085327] r7 : 00000002 r6 : 00000007 r5 : 00000000 r4 : ed684600
[ 2.086029] r3 : ef1281c0 r2 : fa020000 r1 : 00000004 r0 : c02b3a40
[ 2.086029] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment user
[ 2.101684] Control: 10c53c7d Table: ad6f004a DAC: 00000015
[ 2.101684] Process S10udev (pid: 497, stack limit = 0xc21ca2f8)
[ 2.116973] Stack: (0xc21cbe70 to 0xc21cc000)
[ 2.123443] be60: a0000113
c0475b74 00000002 00000000
[ 2.126007] be80: c02ac7e0 ef107000 ed684600 20000113 00000000
c02ac830 00000000 ed690ad0
[ 2.139099] bea0: ed6e981c c02ae348 c02ae288 ef107000 c21ca000
0000001c ed6e9800 ef1074fc
[ 2.145385] bec0: c049cab4 ef1dcd80 ed6e9800 c0296aa8 60000113
c02925e8 ef107194 ef107120
[ 2.152191] bee0: ef0003c0 00000000 ef1281c0 c0076214 ef1071b4
ef1071b4 ef1074b4 ef1dcd80
[ 2.159790] bf00: ef107000 b6f5c000 0000001c c21ca000 00000400
00000000 c02968c8 c0292638
[ 2.159790] bf20: c06e3ea0 0000001c c02968c8 ef168b80 c21cbf80
00000000 ef1281c0 ef1dcd80
[ 2.175811] bf40: 0000001c b6f5c000 c21cbf80 00000000 00000000
00000000 00000000 c010841c
[ 2.188476] bf60: c0014400 ef1281c0 ef1dcd80 b6f5c000 0000001c
00000004 00000000 c0108570
[ 2.195068] bf80: 00000000 00000000 0000001c 00000000 0000001c
b6f345c8 0000001c c00144a8
[ 2.195068] bfa0: c21ca000 c00142e0 0000001c b6f345c8 00000001
b6f5c000 0000001c 00000000
[ 2.210723] bfc0: 0000001c b6f345c8 0000001c 00000004 b6f5c000
00000000 00000001 00000000
[ 2.210723] bfe0: 00000000 be988948 b6e5ae98 b6eb7adc 60000110
00000001 89389af9 fef855e7
[ 2.226379] [<c02b3a54>] (serial_omap_start_tx+0x1cc/0x218) from
[<c02ac830>] (uart_start+0x68/0x6c)
[ 2.241973] [<c02ac830>] (uart_start+0x68/0x6c) from [<c02ae348>]
(uart_write+0xc0/0xe4)
[ 2.241973] [<c02ae348>] (uart_write+0xc0/0xe4) from [<c0296aa8>]
(n_tty_write+0x1e0/0x42c)
[ 2.257629] [<c0296aa8>] (n_tty_write+0x1e0/0x42c) from
[<c0292638>] (tty_write+0x140/0x23c)
[ 2.270446] [<c0292638>] (tty_write+0x140/0x23c) from [<c010841c>]
(vfs_write+0xb0/0x134)
[ 2.278594] [<c010841c>] (vfs_write+0xb0/0x134) from [<c0108570>]
(sys_write+0x40/0x70)
[ 2.281311] [<c0108570>] (sys_write+0x40/0x70) from [<c00142e0>]
(ret_fast_syscall+0x0/0x3c)
Regards,
Omar
^ permalink raw reply
* Re: [PATCH v4 1/3] tegra, serial8250: add ->handle_break() uart_port op
From: Stephen Warren @ 2012-04-10 21:14 UTC (permalink / raw)
To: Dan Williams
Cc: gregkh, Sudhakar Mamillapalli, Arnd Bergmann, linux-kernel,
Grant Likely, linux-serial, Colin Cross, Olof Johansson,
Nhan H Mai, Alan Cox, Alan Cox
In-Reply-To: <20120410211053.13805.18954.stgit@dwillia2-linux.jf.intel.com>
On 04/10/2012 03:10 PM, Dan Williams wrote:
> The "KT" serial port has another use case for a "received break" quirk,
> so before adding another special case to the 8250 core take this
> opportunity to push such quirks out of the core and into a uart_port op.
>
> Stephen says:
> "If the callback function is to no longer live in 8250.c itself,
> arch/arm/mach-tegra/devices.c isn't logically a good place to put it,
> and that file will be going away once we get rid of all the board files
> and move solely to device tree."
>
> ...so since 8250_pci.c houses all the quirks for pci serial devices this
> quirk is similarly housed in of_serial.c. Once the open firmware
> conversion completes the infrastructure details
> (include/linux/of_serial.h, and the export) can all be removed to make
> this self contained to of_serial.c.
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Tested-by: Stephen Warren <swarren@wwwdotorg.org>
^ permalink raw reply
* [PATCH v4 0/3] rework quirks for the "kt" serial port
From: Dan Williams @ 2012-04-10 21:10 UTC (permalink / raw)
To: gregkh; +Cc: linux-kernel, linux-serial, alan
Changes since v3: http://marc.info/?l=linux-serial&m=133400008811070&w=2
* Cleaned up "tegra, serial8250: add ->handle_break() uart_port op" to
incorporate Stephen's feedback of just using CONFIG_ARCH_TEGRA instead
of adding CONFIG_SERIAL_TEGRA.
* Added Arnd's ack
* The other two patches have not changed.
---
Dan Williams (2):
tegra, serial8250: add ->handle_break() uart_port op
serial/8250_pci: fix suspend/resume vs init/exit quirks
Sudhakar Mamillapalli (1):
serial/8250_pci: Clear FIFOs for Intel ME Serial Over Lan device on BI
arch/arm/mach-tegra/board-harmony.c | 2 +
arch/arm/mach-tegra/board-paz00.c | 3 ++
arch/arm/mach-tegra/board-seaboard.c | 2 +
arch/arm/mach-tegra/board-trimslice.c | 2 +
drivers/tty/serial/8250/8250.c | 44 ++++++++++----------------------
drivers/tty/serial/8250/8250.h | 2 +
drivers/tty/serial/8250/8250_pci.c | 45 +++++++++++++++++++++++++++++++++
drivers/tty/serial/of_serial.c | 26 +++++++++++++++++++
include/linux/of_serial.h | 17 ++++++++++++
include/linux/serial_8250.h | 1 +
include/linux/serial_core.h | 5 ++++
11 files changed, 118 insertions(+), 31 deletions(-)
create mode 100644 include/linux/of_serial.h
^ permalink raw reply
* [PATCH v4 3/3] serial/8250_pci: fix suspend/resume vs init/exit quirks
From: Dan Williams @ 2012-04-10 21:11 UTC (permalink / raw)
To: gregkh; +Cc: linux-kernel, linux-serial, Alan Cox
In-Reply-To: <20120410210438.13805.40525.stgit@dwillia2-linux.jf.intel.com>
Commit e86ff4a6 "serial/8250_pci: init-quirk msi support for kt serial
controller" introduced a regression in suspend/resume by causing msi's
to be enabled twice without an intervening disable.
00:16.3 Serial controller: Intel Corporation Patsburg KT Controller (rev 05) (prog-if 02 [16550])
Subsystem: Intel Corporation Device 7270
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 72
I/O ports at 4080 [size=8]
Memory at d1c30000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Kernel driver in use: serial
[ 365.250523] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:16.3/msi_irqs'
[ 365.250525] Modules linked in: nls_utf8 ipv6 uinput sg iTCO_wdt
iTCO_vendor_support ioatdma dca i2c_i801 i2c_core wmi sd_mod ahci libahci isci
libsas libata scsi_transport_sas [last unloaded: scsi_wait_scan]
[ 365.250540] Pid: 9030, comm: kworker/u:1 Tainted: G W 3.3.0-isci-3.0.213+ #1
[ 365.250542] Call Trace:
[ 365.250545] [<ffffffff8115e955>] ? sysfs_add_one+0x99/0xad
[ 365.250548] [<ffffffff8102db8b>] warn_slowpath_common+0x85/0x9e
[ 365.250551] [<ffffffff8102dc96>] warn_slowpath_fmt+0x6e/0x70
[ 365.250555] [<ffffffff8115e8fa>] ? sysfs_add_one+0x3e/0xad
[ 365.250558] [<ffffffff8115e8b4>] ? sysfs_pathname+0x3c/0x44
[ 365.250561] [<ffffffff8115e8b4>] ? sysfs_pathname+0x3c/0x44
[ 365.250564] [<ffffffff8115e8b4>] ? sysfs_pathname+0x3c/0x44
[ 365.250567] [<ffffffff8115e8b4>] ? sysfs_pathname+0x3c/0x44
[ 365.250570] [<ffffffff8115e955>] sysfs_add_one+0x99/0xad
[ 365.250573] [<ffffffff8115f031>] create_dir+0x72/0xa5
[ 365.250577] [<ffffffff8115f194>] sysfs_create_dir+0xa2/0xbe
[ 365.250581] [<ffffffff81262463>] kobject_add_internal+0x126/0x1f8
[ 365.250585] [<ffffffff8126255b>] kset_register+0x26/0x3f
[ 365.250588] [<ffffffff8126275a>] kset_create_and_add+0x62/0x7c
[ 365.250592] [<ffffffff81293619>] populate_msi_sysfs+0x34/0x103
[ 365.250595] [<ffffffff81293e1c>] pci_enable_msi_block+0x1b3/0x216
[ 365.250599] [<ffffffff81303f7c>] try_enable_msi+0x13/0x17
[ 365.250603] [<ffffffff81303fb3>] pciserial_resume_ports+0x21/0x42
[ 365.250607] [<ffffffff81304041>] pciserial_resume_one+0x50/0x57
[ 365.250610] [<ffffffff81283e1a>] pci_legacy_resume+0x38/0x47
[ 365.250613] [<ffffffff81283e7d>] pci_pm_restore+0x54/0x87
[ 365.250616] [<ffffffff81283e29>] ? pci_legacy_resume+0x47/0x47
[ 365.250619] [<ffffffff8131e9e8>] dpm_run_callback+0x48/0x7b
[ 365.250623] [<ffffffff8131f39a>] device_resume+0x342/0x394
[ 365.250626] [<ffffffff8131f5b7>] async_resume+0x21/0x49
That patch has since been reverted, but by inspection it seems that
pciserial_suspend_ports() should be invoking .exit() quirks to release
resources acquired during .init().
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
drivers/tty/serial/8250/8250_pci.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index 024551a..24ea98c 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -2814,6 +2814,12 @@ void pciserial_suspend_ports(struct serial_private *priv)
for (i = 0; i < priv->nr; i++)
if (priv->line[i] >= 0)
serial8250_suspend_port(priv->line[i]);
+
+ /*
+ * Ensure that every init quirk is properly torn down
+ */
+ if (priv->quirk->exit)
+ priv->quirk->exit(priv->dev);
}
EXPORT_SYMBOL_GPL(pciserial_suspend_ports);
^ permalink raw reply related
* [PATCH v4 2/3] serial/8250_pci: Clear FIFOs for Intel ME Serial Over Lan device on BI
From: Dan Williams @ 2012-04-10 21:10 UTC (permalink / raw)
To: gregkh
Cc: Sudhakar Mamillapalli, Nhan H Mai, linux-kernel, linux-serial,
Alan Cox
In-Reply-To: <20120410210438.13805.40525.stgit@dwillia2-linux.jf.intel.com>
From: Sudhakar Mamillapalli <sudhakar@fb.com>
When using Serial Over Lan (SOL) over the virtual serial port in a Intel
management engine (ME) device, on device reset the serial FIFOs need to
be cleared to keep the FIFO indexes in-sync between the host and the
engine.
On a reset the serial device assertes BI, so using that as a cue FIFOs
are cleared. So for this purpose a new handle_break callback has been
added. One other problem is that the serial registers might temporarily
go to 0 on reset of this device. So instead of using the IER register
read, if 0 returned use the ier value in uart_8250_port. This is hidden
under a custom serial_in.
Cc: Nhan H Mai <nhan.h.mai@intel.com>
Signed-off-by: Sudhakar Mamillapalli <sudhakar@fb.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
drivers/tty/serial/8250/8250.c | 10 +++++++++
drivers/tty/serial/8250/8250.h | 2 ++
drivers/tty/serial/8250/8250_pci.c | 39 ++++++++++++++++++++++++++++++++++++
3 files changed, 51 insertions(+)
diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index cbd94c3..182efcc 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -568,6 +568,16 @@ static void serial8250_clear_fifos(struct uart_8250_port *p)
}
}
+void serial8250_clear_and_reinit_fifos(struct uart_8250_port *p)
+{
+ unsigned char fcr;
+
+ serial8250_clear_fifos(p);
+ fcr = uart_config[p->port.type].fcr;
+ serial_out(p, UART_FCR, fcr);
+}
+EXPORT_SYMBOL_GPL(serial8250_clear_and_reinit_fifos);
+
/*
* IER sleep support. UARTs which have EFRs need the "extended
* capability" bit enabled. Note that on XR16C850s, we need to
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index 2868a1d..c9d0ebe 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -96,6 +96,8 @@ static inline void serial_out(struct uart_8250_port *up, int offset, int value)
up->port.serial_out(&up->port, offset, value);
}
+void serial8250_clear_and_reinit_fifos(struct uart_8250_port *p);
+
#if defined(__alpha__) && !defined(CONFIG_PCI)
/*
* Digital did something really horribly wrong with the OUT1 and OUT2
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index 858dca8..024551a 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -17,6 +17,7 @@
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/tty.h>
+#include <linux/serial_reg.h>
#include <linux/serial_core.h>
#include <linux/8250_pci.h>
#include <linux/bitops.h>
@@ -1092,11 +1093,49 @@ static int skip_tx_en_setup(struct serial_private *priv,
return pci_default_setup(priv, board, port, idx);
}
+static void kt_handle_break(struct uart_port *p)
+{
+ struct uart_8250_port *up =
+ container_of(p, struct uart_8250_port, port);
+ /*
+ * On receipt of a BI, serial device in Intel ME (Intel
+ * management engine) needs to have its fifos cleared for sane
+ * SOL (Serial Over Lan) output.
+ */
+ serial8250_clear_and_reinit_fifos(up);
+}
+
+static unsigned int kt_serial_in(struct uart_port *p, int offset)
+{
+ struct uart_8250_port *up =
+ container_of(p, struct uart_8250_port, port);
+ unsigned int val;
+
+ /*
+ * When the Intel ME (management engine) gets reset its serial
+ * port registers could return 0 momentarily. Functions like
+ * serial8250_console_write, read and save the IER, perform
+ * some operation and then restore it. In order to avoid
+ * setting IER register inadvertently to 0, if the value read
+ * is 0, double check with ier value in uart_8250_port and use
+ * that instead. up->ier should be the same value as what is
+ * currently configured.
+ */
+ val = inb(p->iobase + offset);
+ if (offset == UART_IER) {
+ if (val == 0)
+ val = up->ier;
+ }
+ return val;
+}
+
static int kt_serial_setup(struct serial_private *priv,
const struct pciserial_board *board,
struct uart_port *port, int idx)
{
port->flags |= UPF_BUG_THRE;
+ port->serial_in = kt_serial_in;
+ port->handle_break = kt_handle_break;
return skip_tx_en_setup(priv, board, port, idx);
}
^ permalink raw reply related
* [PATCH v4 1/3] tegra, serial8250: add ->handle_break() uart_port op
From: Dan Williams @ 2012-04-10 21:10 UTC (permalink / raw)
To: gregkh
Cc: Sudhakar Mamillapalli, Stephen Warren, Arnd Bergmann,
linux-kernel, Grant Likely, linux-serial, Colin Cross,
Olof Johansson, Nhan H Mai, Alan Cox, Alan Cox
In-Reply-To: <20120410210438.13805.40525.stgit@dwillia2-linux.jf.intel.com>
The "KT" serial port has another use case for a "received break" quirk,
so before adding another special case to the 8250 core take this
opportunity to push such quirks out of the core and into a uart_port op.
Stephen says:
"If the callback function is to no longer live in 8250.c itself,
arch/arm/mach-tegra/devices.c isn't logically a good place to put it,
and that file will be going away once we get rid of all the board files
and move solely to device tree."
...so since 8250_pci.c houses all the quirks for pci serial devices this
quirk is similarly housed in of_serial.c. Once the open firmware
conversion completes the infrastructure details
(include/linux/of_serial.h, and the export) can all be removed to make
this self contained to of_serial.c.
Cc: Nhan H Mai <nhan.h.mai@intel.com>
Cc: Colin Cross <ccross@android.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Stephen Warren <swarren@nvidia.com>
[stephen: kill CONFIG_SERIAL_TEGRA in favor just using CONFIG_ARCH_TEGRA]
Cc: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Sudhakar Mamillapalli <sudhakar@fb.com>
Reported-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
arch/arm/mach-tegra/board-harmony.c | 2 ++
arch/arm/mach-tegra/board-paz00.c | 3 +++
arch/arm/mach-tegra/board-seaboard.c | 2 ++
arch/arm/mach-tegra/board-trimslice.c | 2 ++
drivers/tty/serial/8250/8250.c | 34 +++------------------------------
drivers/tty/serial/of_serial.c | 26 +++++++++++++++++++++++++
include/linux/of_serial.h | 17 +++++++++++++++++
include/linux/serial_8250.h | 1 +
include/linux/serial_core.h | 5 +++++
9 files changed, 61 insertions(+), 31 deletions(-)
create mode 100644 include/linux/of_serial.h
diff --git a/arch/arm/mach-tegra/board-harmony.c b/arch/arm/mach-tegra/board-harmony.c
index c00aadb..222182e 100644
--- a/arch/arm/mach-tegra/board-harmony.c
+++ b/arch/arm/mach-tegra/board-harmony.c
@@ -19,6 +19,7 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/serial_8250.h>
+#include <linux/of_serial.h>
#include <linux/clk.h>
#include <linux/dma-mapping.h>
#include <linux/pda_power.h>
@@ -52,6 +53,7 @@ static struct plat_serial8250_port debug_uart_platform_data[] = {
.irq = INT_UARTD,
.flags = UPF_BOOT_AUTOCONF | UPF_FIXED_TYPE,
.type = PORT_TEGRA,
+ .handle_break = tegra_serial_handle_break,
.iotype = UPIO_MEM,
.regshift = 2,
.uartclk = 216000000,
diff --git a/arch/arm/mach-tegra/board-paz00.c b/arch/arm/mach-tegra/board-paz00.c
index 330afdf..d0735c7 100644
--- a/arch/arm/mach-tegra/board-paz00.c
+++ b/arch/arm/mach-tegra/board-paz00.c
@@ -21,6 +21,7 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/serial_8250.h>
+#include <linux/of_serial.h>
#include <linux/clk.h>
#include <linux/dma-mapping.h>
#include <linux/gpio_keys.h>
@@ -55,6 +56,7 @@ static struct plat_serial8250_port debug_uart_platform_data[] = {
.irq = INT_UARTA,
.flags = UPF_BOOT_AUTOCONF | UPF_FIXED_TYPE,
.type = PORT_TEGRA,
+ .handle_break = tegra_serial_handle_break,
.iotype = UPIO_MEM,
.regshift = 2,
.uartclk = 216000000,
@@ -65,6 +67,7 @@ static struct plat_serial8250_port debug_uart_platform_data[] = {
.irq = INT_UARTC,
.flags = UPF_BOOT_AUTOCONF | UPF_FIXED_TYPE,
.type = PORT_TEGRA,
+ .handle_break = tegra_serial_handle_break,
.iotype = UPIO_MEM,
.regshift = 2,
.uartclk = 216000000,
diff --git a/arch/arm/mach-tegra/board-seaboard.c b/arch/arm/mach-tegra/board-seaboard.c
index d669847..5b687b8 100644
--- a/arch/arm/mach-tegra/board-seaboard.c
+++ b/arch/arm/mach-tegra/board-seaboard.c
@@ -18,6 +18,7 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/serial_8250.h>
+#include <linux/of_serial.h>
#include <linux/i2c.h>
#include <linux/delay.h>
#include <linux/input.h>
@@ -47,6 +48,7 @@ static struct plat_serial8250_port debug_uart_platform_data[] = {
/* Memory and IRQ filled in before registration */
.flags = UPF_BOOT_AUTOCONF | UPF_FIXED_TYPE,
.type = PORT_TEGRA,
+ .handle_break = tegra_serial_handle_break,
.iotype = UPIO_MEM,
.regshift = 2,
.uartclk = 216000000,
diff --git a/arch/arm/mach-tegra/board-trimslice.c b/arch/arm/mach-tegra/board-trimslice.c
index cd52820..f735858 100644
--- a/arch/arm/mach-tegra/board-trimslice.c
+++ b/arch/arm/mach-tegra/board-trimslice.c
@@ -22,6 +22,7 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/serial_8250.h>
+#include <linux/of_serial.h>
#include <linux/io.h>
#include <linux/i2c.h>
#include <linux/gpio.h>
@@ -48,6 +49,7 @@ static struct plat_serial8250_port debug_uart_platform_data[] = {
.irq = INT_UARTA,
.flags = UPF_BOOT_AUTOCONF | UPF_FIXED_TYPE,
.type = PORT_TEGRA,
+ .handle_break = tegra_serial_handle_break,
.iotype = UPIO_MEM,
.regshift = 2,
.uartclk = 216000000,
diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index 5c27f7e..cbd94c3 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -1332,27 +1332,6 @@ static void serial8250_enable_ms(struct uart_port *port)
}
/*
- * Clear the Tegra rx fifo after a break
- *
- * FIXME: This needs to become a port specific callback once we have a
- * framework for this
- */
-static void clear_rx_fifo(struct uart_8250_port *up)
-{
- unsigned int status, tmout = 10000;
- do {
- status = serial_in(up, UART_LSR);
- if (status & (UART_LSR_FIFOE | UART_LSR_BRK_ERROR_BITS))
- status = serial_in(up, UART_RX);
- else
- break;
- if (--tmout == 0)
- break;
- udelay(1);
- } while (1);
-}
-
-/*
* serial8250_rx_chars: processes according to the passed in LSR
* value, and returns the remaining LSR bits not handled
* by this Rx routine.
@@ -1386,20 +1365,10 @@ serial8250_rx_chars(struct uart_8250_port *up, unsigned char lsr)
up->lsr_saved_flags = 0;
if (unlikely(lsr & UART_LSR_BRK_ERROR_BITS)) {
- /*
- * For statistics only
- */
if (lsr & UART_LSR_BI) {
lsr &= ~(UART_LSR_FE | UART_LSR_PE);
port->icount.brk++;
/*
- * If tegra port then clear the rx fifo to
- * accept another break/character.
- */
- if (port->type == PORT_TEGRA)
- clear_rx_fifo(up);
-
- /*
* We do the SysRQ and SAK checking
* here because otherwise the break
* may get masked by ignore_status_mask
@@ -3037,6 +3006,7 @@ static int __devinit serial8250_probe(struct platform_device *dev)
port.serial_in = p->serial_in;
port.serial_out = p->serial_out;
port.handle_irq = p->handle_irq;
+ port.handle_break = p->handle_break;
port.set_termios = p->set_termios;
port.pm = p->pm;
port.dev = &dev->dev;
@@ -3209,6 +3179,8 @@ int serial8250_register_port(struct uart_port *port)
uart->port.set_termios = port->set_termios;
if (port->pm)
uart->port.pm = port->pm;
+ if (port->handle_break)
+ uart->port.handle_break = port->handle_break;
if (serial8250_isa_config != NULL)
serial8250_isa_config(0, &uart->port,
diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c
index e8c9cee..5410c06 100644
--- a/drivers/tty/serial/of_serial.c
+++ b/drivers/tty/serial/of_serial.c
@@ -12,10 +12,13 @@
#include <linux/init.h>
#include <linux/module.h>
#include <linux/slab.h>
+#include <linux/delay.h>
#include <linux/serial_core.h>
#include <linux/serial_8250.h>
+#include <linux/serial_reg.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
+#include <linux/of_serial.h>
#include <linux/of_platform.h>
#include <linux/nwpserial.h>
@@ -24,6 +27,26 @@ struct of_serial_info {
int line;
};
+#ifdef CONFIG_ARCH_TEGRA
+void tegra_serial_handle_break(struct uart_port *p)
+{
+ unsigned int status, tmout = 10000;
+
+ do {
+ status = p->serial_in(p, UART_LSR);
+ if (status & (UART_LSR_FIFOE | UART_LSR_BRK_ERROR_BITS))
+ status = p->serial_in(p, UART_RX);
+ else
+ break;
+ if (--tmout == 0)
+ break;
+ udelay(1);
+ } while (1);
+}
+/* FIXME remove this export when tegra finishes conversion to open firmware */
+EXPORT_SYMBOL_GPL(tegra_serial_handle_break);
+#endif
+
/*
* Fill a struct uart_port for a given device node
*/
@@ -84,6 +107,9 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
| UPF_FIXED_PORT | UPF_FIXED_TYPE;
port->dev = &ofdev->dev;
+ if (type == PORT_TEGRA)
+ port->handle_break = tegra_serial_handle_break;
+
return 0;
}
diff --git a/include/linux/of_serial.h b/include/linux/of_serial.h
new file mode 100644
index 0000000..4a73ed8
--- /dev/null
+++ b/include/linux/of_serial.h
@@ -0,0 +1,17 @@
+#ifndef __LINUX_OF_SERIAL_H
+#define __LINUX_OF_SERIAL_H
+
+/*
+ * FIXME remove this file when tegra finishes conversion to open firmware,
+ * expectation is that all quirks will then be self-contained in
+ * drivers/tty/serial/of_serial.c.
+ */
+#ifdef CONFIG_ARCH_TEGRA
+extern void tegra_serial_handle_break(struct uart_port *port);
+#else
+static inline void tegra_serial_handle_break(struct uart_port *port)
+{
+}
+#endif
+
+#endif /* __LINUX_OF_SERIAL */
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index 8f012f8..a522fd9 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -38,6 +38,7 @@ struct plat_serial8250_port {
int (*handle_irq)(struct uart_port *);
void (*pm)(struct uart_port *, unsigned int state,
unsigned old);
+ void (*handle_break)(struct uart_port *);
};
/*
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 2db407a..65db992 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -310,6 +310,7 @@ struct uart_port {
int (*handle_irq)(struct uart_port *);
void (*pm)(struct uart_port *, unsigned int state,
unsigned int old);
+ void (*handle_break)(struct uart_port *);
unsigned int irq; /* irq number */
unsigned long irqflags; /* irq flags */
unsigned int uartclk; /* base uart clock */
@@ -533,6 +534,10 @@ uart_handle_sysrq_char(struct uart_port *port, unsigned int ch)
static inline int uart_handle_break(struct uart_port *port)
{
struct uart_state *state = port->state;
+
+ if (port->handle_break)
+ port->handle_break(port);
+
#ifdef SUPPORT_SYSRQ
if (port->cons && port->cons->index == port->line) {
if (!port->sysrq) {
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox