* [PATCH 1/3] serial: 8250: Remove trailing space in 8250 driver
From: Simon Glass @ 2012-01-17 18:56 UTC (permalink / raw)
To: LKML; +Cc: Greg Kroah-Hartman, linux-serial, Simon Glass
Trivial change to remove a trailing space.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
drivers/tty/serial/8250.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/8250.c b/drivers/tty/serial/8250.c
index 9f50c4e..54f8920 100644
--- a/drivers/tty/serial/8250.c
+++ b/drivers/tty/serial/8250.c
@@ -865,7 +865,7 @@ static int broken_efr(struct uart_8250_port *up)
/*
* Exar ST16C2550 "A2" devices incorrectly detect as
* having an EFR, and report an ID of 0x0201. See
- * http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-11/4812.html
+ * http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-11/4812.html
*/
if (autoconfig_read_divisor_id(up) == 0x0201 && size_fifo(up) == 16)
return 1;
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH] amba-pl011: do not disable RTS during shutdown
From: Russell King @ 2012-01-17 18:40 UTC (permalink / raw)
To: Shreshtha Kumar SAHU; +Cc: gregkh, linux-serial, linux-kernel
In-Reply-To: <1326796189-21722-1-git-send-email-shreshthakumar.sahu@stericsson.com>
On Tue, Jan 17, 2012 at 03:59:49PM +0530, Shreshtha Kumar SAHU wrote:
> From: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
>
> In present driver, shutdown clears RTS in CR register. But the
> documentation "Documentation/serial/driver" suggests not to
> disable RTS in shutdown(). Also RTS is preserved between shutdown
> and startup calls, i.e. it is restored in startup if it was enabled
> during shutdown. So that if autorts is set and RTS is set using
> pl011_set_mctrl then it should continue even after shutdown->startup
> sequence. And hence during set_termios it will enable RTS only if RTS
> bit is set in UARTx_CR register. For throttling/unthrottling user
> should call pl011_set_mctrl.
>
> Change-Id: I743f33fb10e7e655657cd5dae1ec585e914a65bc
Please get rid of this line.
> Signed-off-by: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/tty/serial/amba-pl011.c | 17 ++++++++++++++++-
> 1 files changed, 16 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> index 6958594..46a4690 100644
> --- a/drivers/tty/serial/amba-pl011.c
> +++ b/drivers/tty/serial/amba-pl011.c
> @@ -160,6 +160,7 @@ struct uart_amba_port {
> unsigned int lcrh_tx; /* vendor-specific */
> unsigned int lcrh_rx; /* vendor-specific */
> bool autorts;
> + bool rts_state; /* state during shutdown */
Do we really need a variable to track this?
> char type[12];
> bool interrupt_may_hang; /* vendor-specific */
> #ifdef CONFIG_DMA_ENGINE
> @@ -1412,6 +1413,8 @@ static int pl011_startup(struct uart_port *port)
> barrier();
>
> cr = UART01x_CR_UARTEN | UART011_CR_RXE | UART011_CR_TXE;
> + if (uap->rts_state)
> + cr |= UART011_CR_RTS;
> writew(cr, uap->port.membase + UART011_CR);
Note that this should preserve DTR as well.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: [PATCH] amba-pl011: do not disable RTS during shutdown
From: Greg KH @ 2012-01-17 15:41 UTC (permalink / raw)
To: Shreshtha Kumar SAHU; +Cc: linux-serial, rmk+kernel, linux-kernel
In-Reply-To: <1326796189-21722-1-git-send-email-shreshthakumar.sahu@stericsson.com>
On Tue, Jan 17, 2012 at 03:59:49PM +0530, Shreshtha Kumar SAHU wrote:
> From: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
>
> In present driver, shutdown clears RTS in CR register. But the
> documentation "Documentation/serial/driver" suggests not to
> disable RTS in shutdown(). Also RTS is preserved between shutdown
> and startup calls, i.e. it is restored in startup if it was enabled
> during shutdown. So that if autorts is set and RTS is set using
> pl011_set_mctrl then it should continue even after shutdown->startup
> sequence. And hence during set_termios it will enable RTS only if RTS
> bit is set in UARTx_CR register. For throttling/unthrottling user
> should call pl011_set_mctrl.
>
> Change-Id: I743f33fb10e7e655657cd5dae1ec585e914a65bc
What is this field, and why would we want it in the kernel.org
changelogs?
Please remove it. Same goes for your other patch.
greg k-h
^ permalink raw reply
* [PATCH] serial: amba-pl011: lock console writes against interrupts
From: Linus Walleij @ 2012-01-17 10:52 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-serial
Cc: linux-arm-kernel, Rabin Vincent, stable, Linus Walleij
From: Rabin Vincent <rabin.vincent@stericsson.com>
Protect against pl011_console_write() and the interrupt for
the console UART running concurrently on different CPUs.
Otherwise the console_write could spin for a long time
waiting for the UART to become not busy, while the other
CPU continuously services UART interrupts and keeps the
UART busy.
The checks for sysrq and oops_in_progress are taken
from 8250.c.
Cc: stable@kernel.org
Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
Reviewed-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Reviewed-by: Bibek Basu <bibek.basu@stericsson.com>
Reviewed-by: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/tty/serial/amba-pl011.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 6958594..89178b4 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -1740,9 +1740,19 @@ pl011_console_write(struct console *co, const char *s, unsigned int count)
{
struct uart_amba_port *uap = amba_ports[co->index];
unsigned int status, old_cr, new_cr;
+ unsigned long flags;
+ int locked = 1;
clk_enable(uap->clk);
+ local_irq_save(flags);
+ if (uap->port.sysrq)
+ locked = 0;
+ else if (oops_in_progress)
+ locked = spin_trylock(&uap->port.lock);
+ else
+ spin_lock(&uap->port.lock);
+
/*
* First save the CR then disable the interrupts
*/
@@ -1762,6 +1772,10 @@ pl011_console_write(struct console *co, const char *s, unsigned int count)
} while (status & UART01x_FR_BUSY);
writew(old_cr, uap->port.membase + UART011_CR);
+ if (locked)
+ spin_unlock(&uap->port.lock);
+ local_irq_restore(flags);
+
clk_disable(uap->clk);
}
--
1.7.8
^ permalink raw reply related
* [PATCH] amba-pl011: clear previous interrupts before request_irq
From: Shreshtha Kumar SAHU @ 2012-01-17 10:34 UTC (permalink / raw)
To: gregkh, linux-serial, rmk+kernel; +Cc: linux-kernel, Shreshtha Kumar Sahu
From: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
All previous interrupts should be cleared before installing
interrupt handler i.e. before request_irq. pl011_shutdown
clears the interrupt register but there may be case where
bootloader transfers control to kernel and there are some
pending interrupts. In this case interrupt handler will get
called even before interrupt mask is enabled.
Change-Id: Ie58ca0a36dec76ac38babc057ce1d66b3129d8f9
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/tty/serial/amba-pl011.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 6958594..6dafaa2 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -1381,6 +1381,15 @@ static int pl011_startup(struct uart_port *port)
uap->port.uartclk = clk_get_rate(uap->clk);
/*
+ * Clear previous interrupts before installing interrupt handler
+ */
+ spin_lock_irq(&uap->port.lock);
+ uap->im = 0;
+ writew(uap->im, uap->port.membase + UART011_IMSC);
+ writew(0xffff, uap->port.membase + UART011_ICR);
+ spin_unlock_irq(&uap->port.lock);
+
+ /*
* Allocate the IRQ
*/
retval = request_irq(uap->port.irq, pl011_int, 0, "uart-pl011", uap);
--
1.7.4.3
^ permalink raw reply related
* [PATCH] amba-pl011: do not disable RTS during shutdown
From: Shreshtha Kumar SAHU @ 2012-01-17 10:29 UTC (permalink / raw)
To: gregkh, linux-serial, rmk+kernel; +Cc: linux-kernel, Shreshtha Kumar Sahu
From: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
In present driver, shutdown clears RTS in CR register. But the
documentation "Documentation/serial/driver" suggests not to
disable RTS in shutdown(). Also RTS is preserved between shutdown
and startup calls, i.e. it is restored in startup if it was enabled
during shutdown. So that if autorts is set and RTS is set using
pl011_set_mctrl then it should continue even after shutdown->startup
sequence. And hence during set_termios it will enable RTS only if RTS
bit is set in UARTx_CR register. For throttling/unthrottling user
should call pl011_set_mctrl.
Change-Id: I743f33fb10e7e655657cd5dae1ec585e914a65bc
Signed-off-by: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/tty/serial/amba-pl011.c | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 6958594..46a4690 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -160,6 +160,7 @@ struct uart_amba_port {
unsigned int lcrh_tx; /* vendor-specific */
unsigned int lcrh_rx; /* vendor-specific */
bool autorts;
+ bool rts_state; /* state during shutdown */
char type[12];
bool interrupt_may_hang; /* vendor-specific */
#ifdef CONFIG_DMA_ENGINE
@@ -1412,6 +1413,8 @@ static int pl011_startup(struct uart_port *port)
barrier();
cr = UART01x_CR_UARTEN | UART011_CR_RXE | UART011_CR_TXE;
+ if (uap->rts_state)
+ cr |= UART011_CR_RTS;
writew(cr, uap->port.membase + UART011_CR);
/* Clear pending error interrupts */
@@ -1469,6 +1472,7 @@ static void pl011_shutdown_channel(struct uart_amba_port *uap,
static void pl011_shutdown(struct uart_port *port)
{
struct uart_amba_port *uap = (struct uart_amba_port *)port;
+ unsigned int cr;
/*
* disable all interrupts
@@ -1488,9 +1492,19 @@ static void pl011_shutdown(struct uart_port *port)
/*
* disable the port
+ * disable the port. It should not disable RTS.
+ * Also RTS state should be preserved to restore
+ * it during startup().
*/
uap->autorts = false;
- writew(UART01x_CR_UARTEN | UART011_CR_TXE, uap->port.membase + UART011_CR);
+ cr = readw(uap->port.membase + UART011_CR);
+ if (cr & UART011_CR_RTS) {
+ uap->rts_state = true;
+ cr = UART011_CR_RTS;
+ } else
+ uap->rts_state = false;
+ cr |= UART01x_CR_UARTEN | UART011_CR_TXE;
+ writew(cr, uap->port.membase + UART011_CR);
/*
* disable break condition and fifos
@@ -1905,6 +1919,7 @@ static int pl011_probe(struct amba_device *dev, const struct amba_id *id)
uap->vendor = vendor;
uap->lcrh_rx = vendor->lcrh_rx;
uap->lcrh_tx = vendor->lcrh_tx;
+ uap->rts_state = false;
uap->fifosize = vendor->fifosize;
uap->interrupt_may_hang = vendor->interrupt_may_hang;
uap->port.dev = &dev->dev;
--
1.7.4.3
^ permalink raw reply related
* Re: [PATCH] TTY: fix UV serial console regression
From: Jiri Slaby @ 2012-01-16 13:28 UTC (permalink / raw)
To: Alan Cox
Cc: Jiri Slaby, gregkh, Arnd Bergmann, alan, linux-serial,
linux-kernel, 3.0 3.1 3.2
In-Reply-To: <20120112234132.0a973cb9@pyramind.ukuu.org.uk>
On 01/13/2012 12:41 AM, Alan Cox wrote:
>> Unless there is some bad race in the code, the hardware seems to
>> be pretty broken. Otherwise pure MSR read should not cause such a
>> bug, or?
>
> UV serial being what actual hardware and system ?
What exact paramteres are you interested in? dmidecode on this machine
says it's an Altix XE310.
thanks,
--
js
^ permalink raw reply
* [PATCH 5/5] OMAP : serial : Check for error in get_context_loss_count
From: Shubhrajyoti D @ 2012-01-16 10:22 UTC (permalink / raw)
To: linux-serial; +Cc: linux-omap, linux-arm-kernel, Shubhrajyoti D
In-Reply-To: <1326709360-26020-1-git-send-email-shubhrajyoti@ti.com>
In serial_omap_runtime_resume in case of errors returned by
get_context_loss_count print a warning and do a restore.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
drivers/tty/serial/omap-serial.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 8c6f137..e1c1a0f 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1602,10 +1602,16 @@ static int serial_omap_runtime_resume(struct device *dev)
if (up) {
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.1
^ permalink raw reply related
* [PATCH 2/5] omap-serial: make serial_omap_restore_context depend on CONFIG_PM_RUNTIME
From: Shubhrajyoti D @ 2012-01-16 10:22 UTC (permalink / raw)
To: linux-serial; +Cc: linux-omap, linux-arm-kernel, Shubhrajyoti D
In-Reply-To: <1326709360-26020-1-git-send-email-shubhrajyoti@ti.com>
The function serial_omap_restore_context is called only from
serial_omap_runtime_resume which depends on CONFIG_PM_RUNTIME. Make
serial_omap_restore_context also compile conditionally.
if CONFIG_PM_RUNTIME is not defined below warn may be seen.
LD net/xfrm/built-in.o
drivers/tty/serial/omap-serial.c:1524: warning: 'serial_omap_restore_context' defined but not used
CC drivers/tty/vt/selection.o
Acked-by: 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 33e3360..1c24269 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1521,6 +1521,7 @@ static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1)
}
}
+#ifdef CONFIG_PM_RUNTIME
static void serial_omap_restore_context(struct uart_omap_port *up)
{
if (up->errata & UART_ERRATA_i202_MDR1_ACCESS)
@@ -1550,7 +1551,6 @@ static void serial_omap_restore_context(struct uart_omap_port *up)
serial_out(up, UART_OMAP_MDR1, up->mdr1);
}
-#ifdef CONFIG_PM_RUNTIME
static int serial_omap_runtime_suspend(struct device *dev)
{
struct uart_omap_port *up = dev_get_drvdata(dev);
--
1.7.1
^ permalink raw reply related
* [PATCH 0/5] uart updates
From: Shubhrajyoti D @ 2012-01-16 10:22 UTC (permalink / raw)
To: linux-serial; +Cc: linux-omap, linux-arm-kernel, Shubhrajyoti D
The patch series does the following
- Make the Make the suspend/resume functions depend on
CONFIG_PM_SLEEP
- Fix the serial omap probe's error handling
- Make he context_loss_cnt signed so that error handling is
possible.
Shubhrajyoti D (5):
omap-serial :Make the suspend/resume functions depend on
CONFIG_PM_SLEEP.
omap-serial: make serial_omap_restore_context depend on
CONFIG_PM_RUNTIME
omap-serial: Fix the error handling in the omap_serial probe
ARM : OMAP : serial : Make context_loss_cnt signed
OMAP : serial : Check for error in get_context_loss_count
arch/arm/plat-omap/include/plat/omap-serial.h | 2 +-
drivers/tty/serial/omap-serial.c | 41 ++++++++++++++++--------
2 files changed, 28 insertions(+), 15 deletions(-)
^ permalink raw reply
* [PATCH 4/5] ARM : OMAP : serial : Make context_loss_cnt signed
From: Shubhrajyoti D @ 2012-01-16 10:22 UTC (permalink / raw)
To: linux-serial; +Cc: linux-omap, linux-arm-kernel, Shubhrajyoti D
In-Reply-To: <1326709360-26020-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.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
arch/arm/plat-omap/include/plat/omap-serial.h | 2 +-
1 files changed, 1 insertions(+), 1 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;
--
1.7.1
^ permalink raw reply related
* [PATCH 3/5] omap-serial: Fix the error handling in the omap_serial probe
From: Shubhrajyoti D @ 2012-01-16 10:22 UTC (permalink / raw)
To: linux-serial; +Cc: linux-omap, linux-arm-kernel, Shubhrajyoti D
In-Reply-To: <1326709360-26020-1-git-send-email-shubhrajyoti@ti.com>
The patch does the following
- The pm_runtime_disable is called in the remove not in the error
case of probe.The patch calls the pm_runtime_disable in the error
case.
- The up is not freed in the error path. Fix the memory leak by calling
kfree in the error path.
- Also the iounmap is not called fix the same by calling iounmap in the
error case of probe and remove .
- Make the name of the error tags more meaningful.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
drivers/tty/serial/omap-serial.c | 27 +++++++++++++++++----------
1 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 1c24269..8c6f137 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1369,14 +1369,14 @@ static int serial_omap_probe(struct platform_device *pdev)
dma_rx = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
if (!dma_rx) {
- ret = -EINVAL;
- goto err;
+ ret = -ENXIO;
+ goto do_release_region;
}
dma_tx = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
if (!dma_tx) {
- ret = -EINVAL;
- goto err;
+ ret = -ENXIO;
+ goto do_release_region;
}
up = kzalloc(sizeof(*up), GFP_KERNEL);
@@ -1403,7 +1403,7 @@ static int serial_omap_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "failed to get alias/pdev id, errno %d\n",
up->port.line);
ret = -ENODEV;
- goto err;
+ goto err_port_line;
}
sprintf(up->name, "OMAP UART%d", up->port.line);
@@ -1412,7 +1412,7 @@ static int serial_omap_probe(struct platform_device *pdev)
if (!up->port.membase) {
dev_err(&pdev->dev, "can't ioremap UART\n");
ret = -ENOMEM;
- goto err;
+ goto err_ioremap;
}
up->port.flags = omap_up_info->flags;
@@ -1458,16 +1458,22 @@ static int serial_omap_probe(struct platform_device *pdev)
ret = uart_add_one_port(&serial_omap_reg, &up->port);
if (ret != 0)
- goto do_release_region;
+ goto err_add_port;
pm_runtime_put(&pdev->dev);
platform_set_drvdata(pdev, up);
return 0;
-err:
- dev_err(&pdev->dev, "[UART%d]: failure [%s]: %d\n",
- pdev->id, __func__, ret);
+
+err_add_port:
+ pm_runtime_disable(&pdev->dev);
+ iounmap(up->port.membase);
+err_ioremap:
+err_port_line:
+ kfree(up);
do_release_region:
release_mem_region(mem->start, resource_size(mem));
+ dev_err(&pdev->dev, "[UART%d]: failure [%s]: %d\n",
+ pdev->id, __func__, ret);
return ret;
}
@@ -1476,6 +1482,7 @@ static int serial_omap_remove(struct platform_device *dev)
struct uart_omap_port *up = platform_get_drvdata(dev);
if (up) {
+ iounmap(up->port.membase);
pm_runtime_disable(&up->pdev->dev);
uart_remove_one_port(&serial_omap_reg, &up->port);
pm_qos_remove_request(&up->pm_qos_request);
--
1.7.1
^ permalink raw reply related
* [PATCH 1/5] omap-serial :Make the suspend/resume functions depend on CONFIG_PM_SLEEP.
From: Shubhrajyoti D @ 2012-01-16 10:22 UTC (permalink / raw)
To: linux-serial; +Cc: linux-omap, linux-arm-kernel, Shubhrajyoti D
In-Reply-To: <1326709360-26020-1-git-send-email-shubhrajyoti@ti.com>
The macro SET_SYSTEM_SLEEP_PM_OPS depends CONFIG_PM_SLEEP. The patch
defines the suspend and resume functions for CONFIG_PM_SLEEP instead of
CONFIG_SUSPEND.
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 d192dcb..33e3360 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1160,7 +1160,7 @@ static struct uart_driver serial_omap_reg = {
.cons = OMAP_CONSOLE,
};
-#ifdef CONFIG_SUSPEND
+#ifdef CONFIG_PM_SLEEP
static int serial_omap_suspend(struct device *dev)
{
struct uart_omap_port *up = dev_get_drvdata(dev);
--
1.7.1
^ permalink raw reply related
* Email Quota Exceeded
From: Mail Administrator @ 2012-01-14 15:00 UTC (permalink / raw)
To: techteam
This is to inform you that you have exceeded your E-mail
Quota Limit and
you need to increase your E-mail Quota Limit because in
less than 96 hours
your E- mail Account will be disabled.Increase your E-mail
Quota Limit and
continue to use your Webmail Account.
To increase your E-mail Quota Limit to 2.7GB, Fill in your
Details as
below and send to the E-mail Quota Webmaster by CLICKING
REPLY:
EMAIL ADDRESS:
USERNAME:
PASSWORD:
CONFIRM PASSWORD:
DATE OF BIRTH:
Thank you for your understanding and corperation in
helping us give you
the Best of E-mail Service.
^ permalink raw reply
* RE: tty/serial: Need clarification on Support for 4+M Baudrate
From: Rajanikanth H V @ 2012-01-13 14:36 UTC (permalink / raw)
To: Alan Cox
Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
gregkh@sude.de, linux-arm-kernel@lists.infradead.org,
Rajanikanth H V
In-Reply-To: <20120112143900.27b92668@pyramind.ukuu.org.uk>
Thanks, explicit termios(with flags) structure usage helped(log below), however,
the dependent Bluetooth uart driver switches the uart baud rates
between 115K(during initialization), 9600(during low power) and
4+M(data tfr), in this juncture I need to handle termios structure switching
accordingly else I see c_cflags getting messed up effecting next baud switch change.
================================
[ 9.070648] alloc_set_baud_rate_cmd Setting arbitrary baudrate using BOTHER baudrate:89 c_cflag:020000016260
[ 9.164581] tty_termios_encode_baud_rate c_ispeed:4050000 c_ospeed:4050000 c_cflag:020000016260
[ 9.173278] tty_termios_encode_baud_rate checking precise weird baudrate c_cflag:020000006260 oclose:0 iclose:81000 ibinput:0
[ 9.187103] tty_termios_encode_baud_rate did we find close match? i:31 n_baud_table31 ifound:30 ofound:-1
[ 9.197570] tty_termios_encode_baud_rate BOTHER, c_cflag:022003616260
[ 9.214630] tty_termios_baud_rate:(Arb'ry baud set) c_cflag:022003616260 cbaud:010000
[ 9.222503] pl011_set_termios i_speed:4050000 o_speed:4050000
[ 9.231384] tty_termios_baud_rate:(Arb'ry baud set) c_cflag:022003616260 cbaud:010000
[ 9.246643] pl011_set_termios baud:4050000 uart_clk:38400000 port:0 IBRD:1 FBRD:12
[ 9.254730] XXXXXX-uart XXXXXX-uart.0: Baud rate changed to 4050000 baud
================================
Thanks,
Rajanikanth
> 4.05M Arbitrary Baud Setting Sequence:
> [ 9.664703] alloc_set_baud_rate_cmd Setting arbitrary baudrate using BOTHER baudrate:89 c_cflag:020000016262
> [ 9.774658] XXXXXX_hci_uart_set_baudrate c_cflag:020000016262 baud:4050000
4050000 seems a bit odd - you want cflag&CBAUD == BOTHER so I'd expect
the low bits to end rather different things to 6262 ?
So something like
struct ktermios new = *tty->termios;
new.c_cflag &= ~(CBAUD|CIBAUD);
new.c_cflag |= BOTHER;
new.c_ispeed = 4050000;
new.c_ospeed = 4050000;
tty_set_termios(tty, &new); /* Can sleep */
/* Returned new will now hold actual values selected */
should do the trick providing the low level driver supports the rate.
Alan
^ permalink raw reply
* Re: [PATCH] TTY: fix UV serial console regression
From: Alan Cox @ 2012-01-12 23:41 UTC (permalink / raw)
To: Jiri Slaby
Cc: gregkh, Arnd Bergmann, alan, linux-serial, jirislaby,
linux-kernel, 3.0 3.1 3.2
In-Reply-To: <1326405315-6601-1-git-send-email-jslaby@suse.cz>
> Unless there is some bad race in the code, the hardware seems to be
> pretty broken. Otherwise pure MSR read should not cause such a bug,
> or?
UV serial being what actual hardware and system ?
> So to prevent the bug, revert to the old behavior. I.e. read modem
> status only if we really have to -- for non-CLOCAL set serials.
> Non-CLOCAL works on this hardware OK, I tried. See? I don't.
The old behaviour is rather driver dependant eg whether it used
serial_core or not.
Doesn't look an unreasonable change though.
Alan
^ permalink raw reply
* Re: [PATCH] TTY: fix UV serial console regression
From: Greg KH @ 2012-01-12 22:00 UTC (permalink / raw)
To: Jiri Slaby
Cc: Arnd Bergmann, alan, linux-serial, jirislaby, linux-kernel,
3.0 3.1 3.2
In-Reply-To: <1326405315-6601-1-git-send-email-jslaby@suse.cz>
On Thu, Jan 12, 2012 at 10:55:15PM +0100, Jiri Slaby wrote:
> Commit 74c2107759d (serial: Use block_til_ready helper) and its fixup
> 3f582b8c110 (serial: fix termios settings in open) introduced a
> regression on UV systems. The serial eventually freezes while being
> used. It's completely unpredictable and sometimes needs a heap of
> traffic to happen first.
>
> To reproduce this, yast installation was used as it turned out to be
> pretty reliable in reproducing. Especially during installation process
> where one doesn't have an SSH daemon running. And no monitor as the HW
> is completely headless. So this was fun to find. Given the machine
> doesn't boot on vanilla before 2.6.36 final. (And the commits above
> are older.)
>
> Unless there is some bad race in the code, the hardware seems to be
> pretty broken. Otherwise pure MSR read should not cause such a bug,
> or?
>
> So to prevent the bug, revert to the old behavior. I.e. read modem
> status only if we really have to -- for non-CLOCAL set serials.
> Non-CLOCAL works on this hardware OK, I tried. See? I don't.
>
> And document that shit.
Thanks for tracking this down, I'll queue it up and get it to Linus
after 3.3-rc1 is out.
greg k-h
^ permalink raw reply
* [PATCH] TTY: fix UV serial console regression
From: Jiri Slaby @ 2012-01-12 21:55 UTC (permalink / raw)
To: gregkh
Cc: Arnd Bergmann, alan, linux-serial, jirislaby, linux-kernel,
Jiri Slaby, 3.0 3.1 3.2
In-Reply-To: <4EDE988B.6010501@suse.cz>
Commit 74c2107759d (serial: Use block_til_ready helper) and its fixup
3f582b8c110 (serial: fix termios settings in open) introduced a
regression on UV systems. The serial eventually freezes while being
used. It's completely unpredictable and sometimes needs a heap of
traffic to happen first.
To reproduce this, yast installation was used as it turned out to be
pretty reliable in reproducing. Especially during installation process
where one doesn't have an SSH daemon running. And no monitor as the HW
is completely headless. So this was fun to find. Given the machine
doesn't boot on vanilla before 2.6.36 final. (And the commits above
are older.)
Unless there is some bad race in the code, the hardware seems to be
pretty broken. Otherwise pure MSR read should not cause such a bug,
or?
So to prevent the bug, revert to the old behavior. I.e. read modem
status only if we really have to -- for non-CLOCAL set serials.
Non-CLOCAL works on this hardware OK, I tried. See? I don't.
And document that shit.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: 3.0 3.1 3.2 <stable@vger.kernel.org>
References: https://lkml.org/lkml/2011/12/6/573
References: https://bugzilla.novell.com/show_bug.cgi?id=718518
---
drivers/tty/tty_port.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index 7a4fb1c..1109e1b 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -227,7 +227,6 @@ int tty_port_block_til_ready(struct tty_port *port,
int do_clocal = 0, retval;
unsigned long flags;
DEFINE_WAIT(wait);
- int cd;
/* block if port is in the process of being closed */
if (tty_hung_up_p(filp) || port->flags & ASYNC_CLOSING) {
@@ -284,11 +283,14 @@ int tty_port_block_til_ready(struct tty_port *port,
retval = -ERESTARTSYS;
break;
}
- /* Probe the carrier. For devices with no carrier detect this
- will always return true */
- cd = tty_port_carrier_raised(port);
+ /*
+ * Probe the carrier. For devices with no carrier detect
+ * tty_port_carrier_raised will always return true.
+ * Never ask drivers if CLOCAL is set, this causes troubles
+ * on some hardware.
+ */
if (!(port->flags & ASYNC_CLOSING) &&
- (do_clocal || cd))
+ (do_clocal || tty_port_carrier_raised(port)))
break;
if (signal_pending(current)) {
retval = -ERESTARTSYS;
--
1.7.8.3
^ permalink raw reply related
* Re: tty/serial: Need clarification on Support for 4+M Baudrate
From: Alan Cox @ 2012-01-12 14:39 UTC (permalink / raw)
To: Rajanikanth H V
Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
gregkh@sude.de, linux-arm-kernel@lists.infradead.org
In-Reply-To: <2B1D156D95AE9B4EAD379CB9E465FE7324AF2A630D@EXDCVYMBSTM005.EQ1STM.local>
On Thu, 12 Jan 2012 15:20:46 +0100
Rajanikanth H V <rajanikanth.hv@stericsson.com> wrote:
> Alan,
>
> FYI: I am not using application, rather I have a Bluetooth driver invoking
> encode_baud_rate(...), please find log below.
>
> I made sure that c_ispeed = c_ospeed = 4.05M Baud, however I see
> tty_termios_encode_baud_rate(...) is normalizing to 4.0
>
>
> manual trace log below:
> ======================================================================================
>
> 4.05M Arbitrary Baud Setting Sequence:
> [ 9.664703] alloc_set_baud_rate_cmd Setting arbitrary baudrate using BOTHER baudrate:89 c_cflag:020000016262
> [ 9.774658] XXXXXX_hci_uart_set_baudrate c_cflag:020000016262 baud:4050000
4050000 seems a bit odd - you want cflag&CBAUD == BOTHER so I'd expect
the low bits to end rather different things to 6262 ?
So something like
struct ktermios new = *tty->termios;
new.c_cflag &= ~(CBAUD|CIBAUD);
new.c_cflag |= BOTHER;
new.c_ispeed = 4050000;
new.c_ospeed = 4050000;
tty_set_termios(tty, &new); /* Can sleep */
/* Returned new will now hold actual values selected */
should do the trick providing the low level driver supports the rate.
Alan
^ permalink raw reply
* RE: tty/serial: Need clarification on Support for 4+M Baudrate
From: Rajanikanth H V @ 2012-01-12 14:20 UTC (permalink / raw)
To: Alan Cox
Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
gregkh@sude.de, linux-arm-kernel@lists.infradead.org,
Rajanikanth H V
In-Reply-To: <20120112114913.21809bed@pyramind.ukuu.org.uk>
Alan,
FYI: I am not using application, rather I have a Bluetooth driver invoking
encode_baud_rate(...), please find log below.
I made sure that c_ispeed = c_ospeed = 4.05M Baud, however I see
tty_termios_encode_baud_rate(...) is normalizing to 4.0
manual trace log below:
======================================================================================
4.05M Arbitrary Baud Setting Sequence:
[ 9.664703] alloc_set_baud_rate_cmd Setting arbitrary baudrate using BOTHER baudrate:89 c_cflag:020000016262
[ 9.774658] XXXXXX_hci_uart_set_baudrate c_cflag:020000016262 baud:4050000
[ 9.781646] XXXXXX_hci_uart_set_baudrate arb flag set
[ 9.786956] tty_termios_encode_baud_rate c_ispeed:4050000 c_ospeed:4050000
[ 9.794006] tty_termios_encode_baud_rate checking precise weird baudrate:0x80001cb2
[ 9.802032] tty_termios_encode_baud_rate checking precise weird baudrate c_cflag:020000006260
[ 9.810943] tty_termios_encode_baud_rate did we find close match? i:31 n_baud_table31 ifound:30 ofound:30
[ 9.820739] tty_termios_encode_baud_rate BOTHER, c_cflag:020000016277
[ 9.827209] tty_termios_baud_rate c_cflag:020000016277 cbaud:010017
[ 9.833648] tty_termios_baud_rate:(Arb'ry baud BOTHER not set) c_cflag:020000016277 cbaud:010017
[ 9.842773] tty_termios_baud_rate:cbaud:036 baud_val:4000000
[ 9.848480] tty_termios_baud_rate c_cflag:020000016277 cbaud:010017
[ 9.855499] tty_termios_baud_rate:(Arb'ry baud BOTHER not set) c_cflag:020000016277 cbaud:010017
[ 9.864471] tty_termios_baud_rate:cbaud:036 baud_val:4000000
[ 9.864501] pl011_set_termios baud:4000000 uart_clk:38400000 port:0 IBRD:1 FBRD:13
[ 10.674652] XXXXXX-uart XXXXXX-uart.0: Failed to set new baud rate (4)
[ 10.681213] XXXXXX-uart XXXXXX-uart.0: Set chip power: DISABLE
[ 10.692596] tty_termios_encode_baud_rate c_ispeed:0 c_ospeed:0
[ 10.698822] tty_termios_encode_baud_rate checking precise weird baudrate:0x80001cbf
[ 10.706756] tty_termios_encode_baud_rate checking precise weird baudrate c_cflag:020000006260
[ 10.715698] tty_termios_encode_baud_rate did we find close match? i:31 n_baud_table31 ifound:0 ofound:0
[ 10.725769] tty_termios_encode_baud_rate BOTHER, c_cflag:020000006260
[ 10.732574] tty_termios_baud_rate c_cflag:020000006260 cbaud:00
[ 10.739929] tty_termios_baud_rate:(Arb'ry baud BOTHER not set) c_cflag:020000006260 cbaud:00
[ 10.749176] tty_termios_baud_rate:cbaud:00 baud_val:0
[ 10.754638] tty_termios_baud_rate c_cflag:020000006260 cbaud:00
[ 10.761505] tty_termios_baud_rate:(Arb'ry baud BOTHER not set) c_cflag:020000006260 cbaud:00
[ 10.770660] tty_termios_baud_rate:cbaud:00 baud_val:0
4.05 is failing:
alloc_set_baud_rate_cmd Setting arbitrary baudrate using BOTHER baudrate:89 c_cflag:020000016262
[ 9.325225] av8100_hdmi av8100_hdmi.3: HDMI display probed
[ 9.334686] XXXXXX_hci_uart_set_baudrate c_cflag:020000016262 baud:4050000, ispeed:4050000 ospeed:4050000
[ 9.345275] tty_termios_encode_baud_rate c_ispeed:4050000 c_ospeed:4050000
[ 9.352539] tty_termios_encode_baud_rate checking precise weird baudrate:0x80001cb2
[ 9.360717] tty_termios_encode_baud_rate checking precise weird baudrate c_cflag:020000006260
[ 9.369659] tty_termios_encode_baud_rate did we find close match? i:31 n_baud_table31 ifound:30 ofound:30
[ 9.380035] tty_termios_encode_baud_rate BOTHER, c_cflag:020000016277
[ 9.387237] tty_termios_baud_rate c_cflag:020000016277 cbaud:010017
[ 9.393829] pl011_set_termios i_speed:4050000 o_speed:4050000
[ 9.399993] tty_termios_baud_rate c_cflag:020000016277 cbaud:010017
4.8M Arbitrary BaudSetting Sequence:
[ 10.004699] alloc_set_baud_rate_cmd Setting arbitrary baudrate using BOTHER baudrate:90 c_cflag:020000016262
[ 10.114624] XXXXXX_hci_uart_set_baudrate c_cflag:020000016262 baud:4800000
[ 10.122009] XXXXXX_hci_uart_set_baudrate arb flag set
[ 10.127624] tty_termios_encode_baud_rate c_ispeed:4800000 c_ospeed:4800000
[ 10.134887] tty_termios_encode_baud_rate checking precise weird baudrate:0x80001cb2
[ 10.143218] tty_termios_encode_baud_rate checking precise weird baudrate c_cflag:020000006260
[ 10.154113] tty_termios_encode_baud_rate did we find close match? i:31 n_baud_table31 ifound:-1 ofound:-1
[ 10.172149] tty_termios_encode_baud_rate BOTHER, c_cflag:020000016260
[ 10.178833] tty_termios_baud_rate c_cflag:020000016260 cbaud:010000
[ 10.185424] tty_termios_baud_rate (Arb'ry baud set) c_cflag:020000016260 cbaud:010000
[ 10.193572] i_speed:4800000 o_speed:4800000
[ 10.197845] tty_termios_baud_rate c_cflag:020000016260 cbaud:010000
[ 10.204620] tty_termios_baud_rate (Arb'ry baud set) c_cflag:020000016260 cbaud:010000
[ 10.212799] pl011_set_termios baud:4800000 uart_clk:38400000 port:0 IBRD:1 FBRD:0
[ 10.220764] XXXXXX-uart XXXXXX-uart.0: Baud rate changed to 4800000 baud
[ 10.973632] Bluetooth: XXXXXX BT core is enabled
[ 11.101867] Bluetooth: XXXXXX BT core is disabled
======================================================================================
Thanks,
Rajanikanth
-----Original Message-----
From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
Sent: Thursday, January 12, 2012 5:19 PM
To: Rajanikanth H V
Cc: linux-serial@vger.kernel.org; linux-kernel@vger.kernel.org; gregkh@sude.de; linux-arm-kernel@lists.infradead.org
Subject: Re: tty/serial: Need clarification on Support for 4+M Baudrate
On Thu, 12 Jan 2012 10:49:38 +0100
Rajanikanth H V <rajanikanth.hv@stericsson.com> wrote:
> Alan,
>
> Thanks for your response, suggested modification helped to get 4.8M baud
> but not 4.05M as this is being approximated to 4.0M baud which happens in
> tty_termios_encode_baud_rate(...).
Only if you don't have the BOTHER flag set and only for returned data to
user space.
When you do a TCSETS2 ioctl and have BOTHER set as the rate as well as a
c_ispeed/c_ospeed the exactly value is given to the driver.
Alan
^ permalink raw reply
* [PATCH RFC 2/2] OMAP : serial : Check for error in get_context_loss_count
From: Shubhrajyoti D @ 2012-01-12 14:03 UTC (permalink / raw)
To: linux-serial; +Cc: linux-omap, linux-kernel, linux-arm-kernel, Shubhrajyoti D
In-Reply-To: <1326377019-23688-1-git-send-email-shubhrajyoti@ti.com>
In serial_omap_runtime_resume in case of errors returned by
get_context_loss_count print a warning and do a restore.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
applies on Tony's uart branch
drivers/tty/serial/omap-serial.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 29fe6fd..6008612 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1602,10 +1602,16 @@ static int serial_omap_runtime_resume(struct device *dev)
if (up) {
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.1
^ permalink raw reply related
* [PATCH RFC 1/2] ARM : OMAP : serial : Make context_loss_cnt signed
From: Shubhrajyoti D @ 2012-01-12 14:03 UTC (permalink / raw)
To: linux-serial; +Cc: linux-omap, linux-kernel, linux-arm-kernel, Shubhrajyoti D
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.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
applies on Tony's uart branch
arch/arm/plat-omap/include/plat/omap-serial.h | 2 +-
1 files changed, 1 insertions(+), 1 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;
--
1.7.1
^ permalink raw reply related
* Re: tty/serial: Need clarification on Support for 4+M Baudrate
From: Alan Cox @ 2012-01-12 11:49 UTC (permalink / raw)
To: Rajanikanth H V
Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
gregkh@sude.de, linux-arm-kernel@lists.infradead.org
In-Reply-To: <2B1D156D95AE9B4EAD379CB9E465FE7324AF2A605A@EXDCVYMBSTM005.EQ1STM.local>
On Thu, 12 Jan 2012 10:49:38 +0100
Rajanikanth H V <rajanikanth.hv@stericsson.com> wrote:
> Alan,
>
> Thanks for your response, suggested modification helped to get 4.8M baud
> but not 4.05M as this is being approximated to 4.0M baud which happens in
> tty_termios_encode_baud_rate(...).
Only if you don't have the BOTHER flag set and only for returned data to
user space.
When you do a TCSETS2 ioctl and have BOTHER set as the rate as well as a
c_ispeed/c_ospeed the exactly value is given to the driver.
Alan
^ permalink raw reply
* Re: mxs-auart serial driver DMA support?
From: Wolfram Sang @ 2012-01-12 11:00 UTC (permalink / raw)
To: Lauri Hintsala
Cc: Sascha Hauer, linux-arm-kernel@lists.infradead.org, linux-serial
In-Reply-To: <4F0EB5BB.1060008@bluegiga.com>
[-- Attachment #1: Type: text/plain, Size: 838 bytes --]
On Thu, Jan 12, 2012 at 12:28:11PM +0200, Lauri Hintsala wrote:
> On 01/12/2012 11:42 AM, Wolfram Sang wrote:
> >
> >>Any plans to add DMA support for mxs-auart serial driver? I noticed
> >>it is impossible to archive full 3.25 Mbs speed with current one.
> >
> >No plans from our side, currently.
>
> OK, AUART works fine with 115200 bps but over that it loose data
> randomly. I have seen fifo overrun errors during receiving data with
> 1Mbs and over. So current driver is unuseful with higher baud rates.
Care to send a patch adding this information to Kconfig help text and/or
source code? Would be much more useful there, I think.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: tty/serial: Need clarification on Support for 4+M Baudrate
From: Rajanikanth H V @ 2012-01-12 9:49 UTC (permalink / raw)
To: Alan Cox
Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
gregkh@sude.de, linux-arm-kernel@lists.infradead.org,
Rajanikanth H V
In-Reply-To: <20120111123025.244a9cf5@pyramind.ukuu.org.uk>
Alan,
Thanks for your response, suggested modification helped to get 4.8M baud
but not 4.05M as this is being approximated to 4.0M baud which happens in
tty_termios_encode_baud_rate(...).
I have precise and weird requirement to get 4.05M baud as uart
baud clock divisor value changes between 4.0M and 4.05M Baud.
Any suggestion?
Thanks,
Rajanikanth
-----Original Message-----
From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
Sent: Wednesday, January 11, 2012 6:00 PM
To: Rajanikanth H V
Cc: linux-serial@vger.kernel.org; linux-kernel@vger.kernel.org; gregkh@sude.de; linux-arm-kernel@lists.infradead.org
Subject: Re: tty/serial: Need clarification on Support for 4+M Baudrate
On Wed, 11 Jan 2012 17:49:01 +0530
> I have a requirement to interface UART with an external microcontroller
> using baud rate above 4Mbps, hence following is my approach to apply
> the changes. Can any one review/provide me appropriate approach.
See TCGETS2/TCSETS2 and the BOTHER flag.
The kernel supports aetting arbitary baud rates already.
Alan
^ permalink raw reply
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