* [PATCH 0/4] serial: fsl_lpuart: fix various DMA related issues
@ 2014-11-28 0:23 Stefan Agner
2014-11-28 0:23 ` [PATCH 1/4] serial: fsl_lpuart: delete timer on shutdown Stefan Agner
` (4 more replies)
0 siblings, 5 replies; 11+ messages in thread
From: Stefan Agner @ 2014-11-28 0:23 UTC (permalink / raw)
To: gregkh
Cc: jslaby, jingchang.lu, shawn.guo, linux-serial, linux-arm-kernel,
linux-kernel, stefan
Patch 1 and 3 are actual fixes, whereas 2 and 4 don't lead to issues
in standard cases but are still worthwhile fixes.
Stefan Agner (4):
serial: fsl_lpuart: delete timer on shutdown
serial: fsl_lpuart: move DMA channel request to probe
serial: fsl_lpuart: avoid new transfer while DMA is running
serial: fsl_lpuart: update RX timer on successful DMA transfer
drivers/tty/serial/fsl_lpuart.c | 110 +++++++++++++++++++---------------------
1 file changed, 52 insertions(+), 58 deletions(-)
--
2.1.3
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 1/4] serial: fsl_lpuart: delete timer on shutdown
2014-11-28 0:23 [PATCH 0/4] serial: fsl_lpuart: fix various DMA related issues Stefan Agner
@ 2014-11-28 0:23 ` Stefan Agner
2014-11-28 0:23 ` [PATCH 2/4] serial: fsl_lpuart: move DMA channel request to probe Stefan Agner
` (3 subsequent siblings)
4 siblings, 0 replies; 11+ messages in thread
From: Stefan Agner @ 2014-11-28 0:23 UTC (permalink / raw)
To: gregkh
Cc: jslaby, jingchang.lu, shawn.guo, linux-serial, linux-arm-kernel,
linux-kernel, stefan
If the serial port gets closed while a RX transfer is in progress,
the timer might fire after the serial port shutdown finished.
Setup the timer on UART startup which allows to delete the timer
unconditionally on shutdown. This also saves the initialization
on each transfer too.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
drivers/tty/serial/fsl_lpuart.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 6dd53af..b1905a9 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -506,9 +506,6 @@ static inline void lpuart_prepare_rx(struct lpuart_port *sport)
spin_lock_irqsave(&sport->port.lock, flags);
- init_timer(&sport->lpuart_timer);
- sport->lpuart_timer.function = lpuart_timer_func;
- sport->lpuart_timer.data = (unsigned long)sport;
sport->lpuart_timer.expires = jiffies + sport->dma_rx_timeout;
add_timer(&sport->lpuart_timer);
@@ -1106,6 +1103,8 @@ static int lpuart_startup(struct uart_port *port)
sport->lpuart_dma_use = false;
} else {
sport->lpuart_dma_use = true;
+ setup_timer(&sport->lpuart_timer, lpuart_timer_func,
+ (unsigned long)sport);
temp = readb(port->membase + UARTCR5);
writeb(temp | UARTCR5_TDMAS, port->membase + UARTCR5);
}
@@ -1180,6 +1179,8 @@ static void lpuart_shutdown(struct uart_port *port)
devm_free_irq(port->dev, port->irq, sport);
if (sport->lpuart_dma_use) {
+ del_timer_sync(&sport->lpuart_timer);
+
lpuart_dma_tx_free(port);
lpuart_dma_rx_free(port);
}
--
2.1.3
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH 2/4] serial: fsl_lpuart: move DMA channel request to probe
2014-11-28 0:23 [PATCH 0/4] serial: fsl_lpuart: fix various DMA related issues Stefan Agner
2014-11-28 0:23 ` [PATCH 1/4] serial: fsl_lpuart: delete timer on shutdown Stefan Agner
@ 2014-11-28 0:23 ` Stefan Agner
2014-11-28 0:23 ` [PATCH 3/4] serial: fsl_lpuart: avoid new transfer while DMA is running Stefan Agner
` (2 subsequent siblings)
4 siblings, 0 replies; 11+ messages in thread
From: Stefan Agner @ 2014-11-28 0:23 UTC (permalink / raw)
To: gregkh
Cc: jslaby, jingchang.lu, shawn.guo, linux-serial, linux-arm-kernel,
linux-kernel, stefan
Move the DMA channel request to probe to avoid requesting the DMA
channel on each opening of the ttyLPx device. This also fixes a
potential issue that TX channel is not freed when only RX channel
allocation fails. The DMA channels are now handled independently,
so one could use UART with DMA only in TX direction for instance.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
drivers/tty/serial/fsl_lpuart.c | 96 +++++++++++++++++++----------------------
1 file changed, 44 insertions(+), 52 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index b1905a9..629291d 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -237,7 +237,8 @@ struct lpuart_port {
unsigned int rxfifo_size;
bool lpuart32;
- bool lpuart_dma_use;
+ bool lpuart_dma_tx_use;
+ bool lpuart_dma_rx_use;
struct dma_chan *dma_tx_chan;
struct dma_chan *dma_rx_chan;
struct dma_async_tx_descriptor *dma_tx_desc;
@@ -568,7 +569,7 @@ static void lpuart_start_tx(struct uart_port *port)
temp = readb(port->membase + UARTCR2);
writeb(temp | UARTCR2_TIE, port->membase + UARTCR2);
- if (sport->lpuart_dma_use) {
+ if (sport->lpuart_dma_tx_use) {
if (!uart_circ_empty(xmit) && !sport->dma_tx_in_progress)
lpuart_prepare_tx(sport);
} else {
@@ -760,14 +761,14 @@ static irqreturn_t lpuart_int(int irq, void *dev_id)
sts = readb(sport->port.membase + UARTSR1);
if (sts & UARTSR1_RDRF) {
- if (sport->lpuart_dma_use)
+ if (sport->lpuart_dma_rx_use)
lpuart_prepare_rx(sport);
else
lpuart_rxint(irq, dev_id);
}
if (sts & UARTSR1_TDRE &&
!(readb(sport->port.membase + UARTCR5) & UARTCR5_TDMAS)) {
- if (sport->lpuart_dma_use)
+ if (sport->lpuart_dma_tx_use)
lpuart_pio_tx(sport);
else
lpuart_txint(irq, dev_id);
@@ -950,26 +951,17 @@ static int lpuart_dma_tx_request(struct uart_port *port)
{
struct lpuart_port *sport = container_of(port,
struct lpuart_port, port);
- struct dma_chan *tx_chan;
struct dma_slave_config dma_tx_sconfig;
dma_addr_t dma_bus;
unsigned char *dma_buf;
int ret;
- tx_chan = dma_request_slave_channel(sport->port.dev, "tx");
-
- if (!tx_chan) {
- dev_err(sport->port.dev, "Dma tx channel request failed!\n");
- return -ENODEV;
- }
-
- dma_bus = dma_map_single(tx_chan->device->dev,
+ dma_bus = dma_map_single(sport->dma_tx_chan->device->dev,
sport->port.state->xmit.buf,
UART_XMIT_SIZE, DMA_TO_DEVICE);
- if (dma_mapping_error(tx_chan->device->dev, dma_bus)) {
+ if (dma_mapping_error(sport->dma_tx_chan->device->dev, dma_bus)) {
dev_err(sport->port.dev, "dma_map_single tx failed\n");
- dma_release_channel(tx_chan);
return -ENOMEM;
}
@@ -978,16 +970,14 @@ static int lpuart_dma_tx_request(struct uart_port *port)
dma_tx_sconfig.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
dma_tx_sconfig.dst_maxburst = sport->txfifo_size;
dma_tx_sconfig.direction = DMA_MEM_TO_DEV;
- ret = dmaengine_slave_config(tx_chan, &dma_tx_sconfig);
+ ret = dmaengine_slave_config(sport->dma_tx_chan, &dma_tx_sconfig);
if (ret < 0) {
dev_err(sport->port.dev,
"Dma slave config failed, err = %d\n", ret);
- dma_release_channel(tx_chan);
return ret;
}
- sport->dma_tx_chan = tx_chan;
sport->dma_tx_buf_virt = dma_buf;
sport->dma_tx_buf_bus = dma_bus;
sport->dma_tx_in_progress = 0;
@@ -999,34 +989,24 @@ static int lpuart_dma_rx_request(struct uart_port *port)
{
struct lpuart_port *sport = container_of(port,
struct lpuart_port, port);
- struct dma_chan *rx_chan;
struct dma_slave_config dma_rx_sconfig;
dma_addr_t dma_bus;
unsigned char *dma_buf;
int ret;
- rx_chan = dma_request_slave_channel(sport->port.dev, "rx");
-
- if (!rx_chan) {
- dev_err(sport->port.dev, "Dma rx channel request failed!\n");
- return -ENODEV;
- }
-
dma_buf = devm_kzalloc(sport->port.dev,
FSL_UART_RX_DMA_BUFFER_SIZE, GFP_KERNEL);
if (!dma_buf) {
dev_err(sport->port.dev, "Dma rx alloc failed\n");
- dma_release_channel(rx_chan);
return -ENOMEM;
}
- dma_bus = dma_map_single(rx_chan->device->dev, dma_buf,
+ dma_bus = dma_map_single(sport->dma_rx_chan->device->dev, dma_buf,
FSL_UART_RX_DMA_BUFFER_SIZE, DMA_FROM_DEVICE);
- if (dma_mapping_error(rx_chan->device->dev, dma_bus)) {
+ if (dma_mapping_error(sport->dma_rx_chan->device->dev, dma_bus)) {
dev_err(sport->port.dev, "dma_map_single rx failed\n");
- dma_release_channel(rx_chan);
return -ENOMEM;
}
@@ -1034,16 +1014,14 @@ static int lpuart_dma_rx_request(struct uart_port *port)
dma_rx_sconfig.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
dma_rx_sconfig.src_maxburst = 1;
dma_rx_sconfig.direction = DMA_DEV_TO_MEM;
- ret = dmaengine_slave_config(rx_chan, &dma_rx_sconfig);
+ ret = dmaengine_slave_config(sport->dma_rx_chan, &dma_rx_sconfig);
if (ret < 0) {
dev_err(sport->port.dev,
"Dma slave config failed, err = %d\n", ret);
- dma_release_channel(rx_chan);
return ret;
}
- sport->dma_rx_chan = rx_chan;
sport->dma_rx_buf_virt = dma_buf;
sport->dma_rx_buf_bus = dma_bus;
sport->dma_rx_in_progress = 0;
@@ -1055,31 +1033,24 @@ static void lpuart_dma_tx_free(struct uart_port *port)
{
struct lpuart_port *sport = container_of(port,
struct lpuart_port, port);
- struct dma_chan *dma_chan;
dma_unmap_single(sport->port.dev, sport->dma_tx_buf_bus,
UART_XMIT_SIZE, DMA_TO_DEVICE);
- dma_chan = sport->dma_tx_chan;
- sport->dma_tx_chan = NULL;
+
sport->dma_tx_buf_bus = 0;
sport->dma_tx_buf_virt = NULL;
- dma_release_channel(dma_chan);
}
static void lpuart_dma_rx_free(struct uart_port *port)
{
struct lpuart_port *sport = container_of(port,
struct lpuart_port, port);
- struct dma_chan *dma_chan;
dma_unmap_single(sport->port.dev, sport->dma_rx_buf_bus,
FSL_UART_RX_DMA_BUFFER_SIZE, DMA_FROM_DEVICE);
- dma_chan = sport->dma_rx_chan;
- sport->dma_rx_chan = NULL;
sport->dma_rx_buf_bus = 0;
sport->dma_rx_buf_virt = NULL;
- dma_release_channel(dma_chan);
}
static int lpuart_startup(struct uart_port *port)
@@ -1098,16 +1069,20 @@ static int lpuart_startup(struct uart_port *port)
sport->rxfifo_size = 0x1 << (((temp >> UARTPFIFO_RXSIZE_OFF) &
UARTPFIFO_FIFOSIZE_MASK) + 1);
- /* Whether use dma support by dma request results */
- if (lpuart_dma_tx_request(port) || lpuart_dma_rx_request(port)) {
- sport->lpuart_dma_use = false;
- } else {
- sport->lpuart_dma_use = true;
+ if (sport->dma_rx_chan && !lpuart_dma_rx_request(port)) {
+ sport->lpuart_dma_rx_use = true;
setup_timer(&sport->lpuart_timer, lpuart_timer_func,
(unsigned long)sport);
+ } else
+ sport->lpuart_dma_rx_use = false;
+
+
+ if (sport->dma_tx_chan && !lpuart_dma_tx_request(port)) {
+ sport->lpuart_dma_tx_use = true;
temp = readb(port->membase + UARTCR5);
writeb(temp | UARTCR5_TDMAS, port->membase + UARTCR5);
- }
+ } else
+ sport->lpuart_dma_tx_use = false;
ret = devm_request_irq(port->dev, port->irq, lpuart_int, 0,
DRIVER_NAME, sport);
@@ -1178,12 +1153,13 @@ static void lpuart_shutdown(struct uart_port *port)
devm_free_irq(port->dev, port->irq, sport);
- if (sport->lpuart_dma_use) {
+ if (sport->lpuart_dma_rx_use) {
+ lpuart_dma_rx_free(&sport->port);
del_timer_sync(&sport->lpuart_timer);
-
- lpuart_dma_tx_free(port);
- lpuart_dma_rx_free(port);
}
+
+ if (sport->lpuart_dma_tx_use)
+ lpuart_dma_tx_free(&sport->port);
}
static void lpuart32_shutdown(struct uart_port *port)
@@ -1305,7 +1281,7 @@ lpuart_set_termios(struct uart_port *port, struct ktermios *termios,
/* update the per-port timeout */
uart_update_timeout(port, termios->c_cflag, baud);
- if (sport->lpuart_dma_use) {
+ if (sport->lpuart_dma_rx_use) {
/* Calculate delay for 1.5 DMA buffers */
sport->dma_rx_timeout = (sport->port.timeout - HZ / 50) *
FSL_UART_RX_DMA_BUFFER_SIZE * 3 /
@@ -1836,6 +1812,16 @@ static int lpuart_probe(struct platform_device *pdev)
return ret;
}
+ sport->dma_tx_chan = dma_request_slave_channel(sport->port.dev, "tx");
+ if (!sport->dma_tx_chan)
+ dev_info(sport->port.dev, "DMA tx channel request failed, "
+ "operating without tx DMA\n");
+
+ sport->dma_rx_chan = dma_request_slave_channel(sport->port.dev, "rx");
+ if (!sport->dma_rx_chan)
+ dev_info(sport->port.dev, "DMA rx channel request failed, "
+ "operating without rx DMA\n");
+
return 0;
}
@@ -1847,6 +1833,12 @@ static int lpuart_remove(struct platform_device *pdev)
clk_disable_unprepare(sport->clk);
+ if (sport->dma_tx_chan)
+ dma_release_channel(sport->dma_tx_chan);
+
+ if (sport->dma_rx_chan)
+ dma_release_channel(sport->dma_rx_chan);
+
return 0;
}
--
2.1.3
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH 3/4] serial: fsl_lpuart: avoid new transfer while DMA is running
2014-11-28 0:23 [PATCH 0/4] serial: fsl_lpuart: fix various DMA related issues Stefan Agner
2014-11-28 0:23 ` [PATCH 1/4] serial: fsl_lpuart: delete timer on shutdown Stefan Agner
2014-11-28 0:23 ` [PATCH 2/4] serial: fsl_lpuart: move DMA channel request to probe Stefan Agner
@ 2014-11-28 0:23 ` Stefan Agner
2014-11-28 0:23 ` [PATCH 4/4] serial: fsl_lpuart: update RX timer on successful DMA transfer Stefan Agner
2014-12-12 13:44 ` [PATCH 0/4] serial: fsl_lpuart: fix various DMA related issues Stefan Agner
4 siblings, 0 replies; 11+ messages in thread
From: Stefan Agner @ 2014-11-28 0:23 UTC (permalink / raw)
To: gregkh
Cc: jslaby, jingchang.lu, shawn.guo, linux-serial, linux-arm-kernel,
linux-kernel, stefan
When the UART is DMA receive mode (RDMAS set) and a character just
arrived, while another interrupt is handled, the RDRF (receiver data
register full flag) is set. But since the DMA will take care of it
there is no need to handle it by calling lpuart_prepare_rx. Handling
it leads in adding the RX timeout timer twice:
[ 43.528029] Kernel BUG at 8004ee7c [verbose debug info unavailable]
[ 43.534329] Internal error: Oops - BUG: 0 [#1] ARM
[ 43.539145] Modules linked in:
[ 43.542242] CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.0-rc5-00014-ge956e1a-dirty #1293
[ 43.550448] task: 80795630 ti: 8078a000 task.ti: 8078a000
[ 43.555886] PC is at add_timer+0x24/0x28
[ 43.559833] LR is at lpuart_int+0x188/0x3b0
[ 43.564039] pc : [<8004ee7c>] lr : [<802cbd3c>] psr: a0000193
[ 43.564039] sp : 8078be18 ip : 8078be28 fp : 8078be24
[ 43.575560] r10: 8e80b840 r9 : 807d23ff r8 : 20000193
[ 43.580812] r7 : 00000020 r6 : 00000001 r5 : 000000a0 r4 : 8e994e10
[ 43.587368] r3 : ffff9bd1 r2 : 80815360 r1 : 8e994e10 r0 : 8e994f20
[ 43.593923] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 43.601352] Control: 10c5387d Table: 8c424059 DAC: 00000015
[ 43.607125] Process swapper (pid: 0, stack limit = 0x8078a238)
...
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
drivers/tty/serial/fsl_lpuart.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 629291d..be9ccdf 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -756,18 +756,18 @@ out:
static irqreturn_t lpuart_int(int irq, void *dev_id)
{
struct lpuart_port *sport = dev_id;
- unsigned char sts;
+ unsigned char sts, crdma;
sts = readb(sport->port.membase + UARTSR1);
+ crdma = readb(sport->port.membase + UARTCR5);
- if (sts & UARTSR1_RDRF) {
+ if (sts & UARTSR1_RDRF && !(crdma & UARTCR5_RDMAS)) {
if (sport->lpuart_dma_rx_use)
lpuart_prepare_rx(sport);
else
lpuart_rxint(irq, dev_id);
}
- if (sts & UARTSR1_TDRE &&
- !(readb(sport->port.membase + UARTCR5) & UARTCR5_TDMAS)) {
+ if (sts & UARTSR1_TDRE && !(crdma & UARTCR5_TDMAS)) {
if (sport->lpuart_dma_tx_use)
lpuart_pio_tx(sport);
else
--
2.1.3
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH 4/4] serial: fsl_lpuart: update RX timer on successful DMA transfer
2014-11-28 0:23 [PATCH 0/4] serial: fsl_lpuart: fix various DMA related issues Stefan Agner
` (2 preceding siblings ...)
2014-11-28 0:23 ` [PATCH 3/4] serial: fsl_lpuart: avoid new transfer while DMA is running Stefan Agner
@ 2014-11-28 0:23 ` Stefan Agner
2014-12-12 13:44 ` [PATCH 0/4] serial: fsl_lpuart: fix various DMA related issues Stefan Agner
4 siblings, 0 replies; 11+ messages in thread
From: Stefan Agner @ 2014-11-28 0:23 UTC (permalink / raw)
To: gregkh
Cc: jslaby, jingchang.lu, shawn.guo, linux-serial, linux-arm-kernel,
linux-kernel, stefan
To end a DMA transfer which did not consume a whole buffer (e.g. one
character only), a RX timer is used. When lots of data are received
the DMA transfer will complete and setup another DMA transfer, which
in turn might complete again. In this cases, it is not necessary to
abort the DMA transfers using the RX timer. This change pushes the
RX timer timeout into the future each time a DMA transfer completed.
Aborting the DMA was not very harmful, since the next received
character lead to setup of another RX DMA.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
drivers/tty/serial/fsl_lpuart.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index be9ccdf..b1c1589 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -462,6 +462,7 @@ static void lpuart_dma_rx_complete(void *arg)
unsigned long flags;
async_tx_ack(sport->dma_rx_desc);
+ mod_timer(&sport->lpuart_timer, jiffies + sport->dma_rx_timeout);
spin_lock_irqsave(&sport->port.lock, flags);
--
2.1.3
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH 0/4] serial: fsl_lpuart: fix various DMA related issues
2014-11-28 0:23 [PATCH 0/4] serial: fsl_lpuart: fix various DMA related issues Stefan Agner
` (3 preceding siblings ...)
2014-11-28 0:23 ` [PATCH 4/4] serial: fsl_lpuart: update RX timer on successful DMA transfer Stefan Agner
@ 2014-12-12 13:44 ` Stefan Agner
2014-12-12 14:32 ` Greg KH
4 siblings, 1 reply; 11+ messages in thread
From: Stefan Agner @ 2014-12-12 13:44 UTC (permalink / raw)
To: gregkh
Cc: jslaby, jingchang.lu, shawn.guo, linux-serial, linux-arm-kernel,
linux-kernel
Any thoughts on this patchset? Would have hopped that it makes it into
3.19 as those are mostly fixes.
--
Stefan
On 2014-11-28 01:23, Stefan Agner wrote:
> Patch 1 and 3 are actual fixes, whereas 2 and 4 don't lead to issues
> in standard cases but are still worthwhile fixes.
>
> Stefan Agner (4):
> serial: fsl_lpuart: delete timer on shutdown
> serial: fsl_lpuart: move DMA channel request to probe
> serial: fsl_lpuart: avoid new transfer while DMA is running
> serial: fsl_lpuart: update RX timer on successful DMA transfer
>
> drivers/tty/serial/fsl_lpuart.c | 110 +++++++++++++++++++---------------------
> 1 file changed, 52 insertions(+), 58 deletions(-)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/4] serial: fsl_lpuart: fix various DMA related issues
2014-12-12 13:44 ` [PATCH 0/4] serial: fsl_lpuart: fix various DMA related issues Stefan Agner
@ 2014-12-12 14:32 ` Greg KH
2014-12-12 16:19 ` Stefan Agner
0 siblings, 1 reply; 11+ messages in thread
From: Greg KH @ 2014-12-12 14:32 UTC (permalink / raw)
To: Stefan Agner
Cc: jslaby, jingchang.lu, shawn.guo, linux-serial, linux-arm-kernel,
linux-kernel
On Fri, Dec 12, 2014 at 02:44:06PM +0100, Stefan Agner wrote:
> Any thoughts on this patchset? Would have hopped that it makes it into
> 3.19 as those are mostly fixes.
"mostly"?
I'll get to these after 3.19-rc1 is out, but it really looks like these
will be for 3.20-rc1, unless you break them up into "bugfix only" type
patches.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/4] serial: fsl_lpuart: fix various DMA related issues
2014-12-12 14:32 ` Greg KH
@ 2014-12-12 16:19 ` Stefan Agner
2015-01-09 22:14 ` Greg KH
0 siblings, 1 reply; 11+ messages in thread
From: Stefan Agner @ 2014-12-12 16:19 UTC (permalink / raw)
To: Greg KH
Cc: jslaby, jingchang.lu, shawn.guo, linux-serial, linux-arm-kernel,
linux-kernel
On 2014-12-12 15:32, Greg KH wrote:
> On Fri, Dec 12, 2014 at 02:44:06PM +0100, Stefan Agner wrote:
>> Any thoughts on this patchset? Would have hopped that it makes it into
>> 3.19 as those are mostly fixes.
>
> "mostly"?
>
Well, all of them fix a bug, but PATCH 2/4 does this by also moving DMA
allocation to probe. I would really have to split up that patch and make
two incremental steps (split-up of RX/TX DMA allocation to make each
single action revert-able and move to probe). But this would lead to
more changed lines in total. The patchset as is already somewhat tested
since we use it in our 3.18 BSP, whereas a new set would not be tested.
One could also argument, it only affects fsl_lpuart (UART in rather not
very widespread SoC's Freescale Vybrid and LS1021a).
> I'll get to these after 3.19-rc1 is out, but it really looks like these
> will be for 3.20-rc1, unless you break them up into "bugfix only" type
> patches.
PATCH 1/4 fixes a bug which happens on a normal console rather often on
my setup. So if you decide that patchset is for 3.20-rc1, that one would
be nice to have in 3.19 as well...
--
Stefan
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/4] serial: fsl_lpuart: fix various DMA related issues
2014-12-12 16:19 ` Stefan Agner
@ 2015-01-09 22:14 ` Greg KH
2015-01-09 22:19 ` Stefan Agner
0 siblings, 1 reply; 11+ messages in thread
From: Greg KH @ 2015-01-09 22:14 UTC (permalink / raw)
To: Stefan Agner
Cc: jslaby, jingchang.lu, shawn.guo, linux-serial, linux-arm-kernel,
linux-kernel
On Fri, Dec 12, 2014 at 05:19:02PM +0100, Stefan Agner wrote:
> On 2014-12-12 15:32, Greg KH wrote:
> > On Fri, Dec 12, 2014 at 02:44:06PM +0100, Stefan Agner wrote:
> >> Any thoughts on this patchset? Would have hopped that it makes it into
> >> 3.19 as those are mostly fixes.
> >
> > "mostly"?
> >
>
> Well, all of them fix a bug, but PATCH 2/4 does this by also moving DMA
> allocation to probe. I would really have to split up that patch and make
> two incremental steps (split-up of RX/TX DMA allocation to make each
> single action revert-able and move to probe). But this would lead to
> more changed lines in total. The patchset as is already somewhat tested
> since we use it in our 3.18 BSP, whereas a new set would not be tested.
>
> One could also argument, it only affects fsl_lpuart (UART in rather not
> very widespread SoC's Freescale Vybrid and LS1021a).
>
>
> > I'll get to these after 3.19-rc1 is out, but it really looks like these
> > will be for 3.20-rc1, unless you break them up into "bugfix only" type
> > patches.
>
>
> PATCH 1/4 fixes a bug which happens on a normal console rather often on
> my setup. So if you decide that patchset is for 3.20-rc1, that one would
> be nice to have in 3.19 as well...
Please redo this patchset then, makeing it obvious that some are fixes,
and need to go for 3.19 and others are ok for 3.20. As it is, the
changelog entries do not look like anything here is for 3.19, sorry.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/4] serial: fsl_lpuart: fix various DMA related issues
2015-01-09 22:14 ` Greg KH
@ 2015-01-09 22:19 ` Stefan Agner
2015-01-09 22:34 ` Greg KH
0 siblings, 1 reply; 11+ messages in thread
From: Stefan Agner @ 2015-01-09 22:19 UTC (permalink / raw)
To: Greg KH
Cc: jslaby, jingchang.lu, shawn.guo, linux-serial, linux-arm-kernel,
linux-kernel
On 2015-01-09 23:14, Greg KH wrote:
> On Fri, Dec 12, 2014 at 05:19:02PM +0100, Stefan Agner wrote:
>> On 2014-12-12 15:32, Greg KH wrote:
>> > On Fri, Dec 12, 2014 at 02:44:06PM +0100, Stefan Agner wrote:
>> >> Any thoughts on this patchset? Would have hopped that it makes it into
>> >> 3.19 as those are mostly fixes.
>> >
>> > "mostly"?
>> >
>>
>> Well, all of them fix a bug, but PATCH 2/4 does this by also moving DMA
>> allocation to probe. I would really have to split up that patch and make
>> two incremental steps (split-up of RX/TX DMA allocation to make each
>> single action revert-able and move to probe). But this would lead to
>> more changed lines in total. The patchset as is already somewhat tested
>> since we use it in our 3.18 BSP, whereas a new set would not be tested.
>>
>> One could also argument, it only affects fsl_lpuart (UART in rather not
>> very widespread SoC's Freescale Vybrid and LS1021a).
>>
>>
>> > I'll get to these after 3.19-rc1 is out, but it really looks like these
>> > will be for 3.20-rc1, unless you break them up into "bugfix only" type
>> > patches.
>>
>>
>> PATCH 1/4 fixes a bug which happens on a normal console rather often on
>> my setup. So if you decide that patchset is for 3.20-rc1, that one would
>> be nice to have in 3.19 as well...
>
> Please redo this patchset then, makeing it obvious that some are fixes,
> and need to go for 3.19 and others are ok for 3.20. As it is, the
> changelog entries do not look like anything here is for 3.19, sorry.
>
Ok, will create a patchset with 1 and 3 for 3.19 (since this two really
lead to reproducible kernel traces), and the rest for 3.20. Do you
prefer to have the patches in a single patchset (with 3 moved to 2) or
should I create two patchsets?
--
Stefan
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/4] serial: fsl_lpuart: fix various DMA related issues
2015-01-09 22:19 ` Stefan Agner
@ 2015-01-09 22:34 ` Greg KH
0 siblings, 0 replies; 11+ messages in thread
From: Greg KH @ 2015-01-09 22:34 UTC (permalink / raw)
To: Stefan Agner
Cc: jslaby, jingchang.lu, shawn.guo, linux-serial, linux-arm-kernel,
linux-kernel
On Fri, Jan 09, 2015 at 11:19:50PM +0100, Stefan Agner wrote:
> On 2015-01-09 23:14, Greg KH wrote:
> > On Fri, Dec 12, 2014 at 05:19:02PM +0100, Stefan Agner wrote:
> >> On 2014-12-12 15:32, Greg KH wrote:
> >> > On Fri, Dec 12, 2014 at 02:44:06PM +0100, Stefan Agner wrote:
> >> >> Any thoughts on this patchset? Would have hopped that it makes it into
> >> >> 3.19 as those are mostly fixes.
> >> >
> >> > "mostly"?
> >> >
> >>
> >> Well, all of them fix a bug, but PATCH 2/4 does this by also moving DMA
> >> allocation to probe. I would really have to split up that patch and make
> >> two incremental steps (split-up of RX/TX DMA allocation to make each
> >> single action revert-able and move to probe). But this would lead to
> >> more changed lines in total. The patchset as is already somewhat tested
> >> since we use it in our 3.18 BSP, whereas a new set would not be tested.
> >>
> >> One could also argument, it only affects fsl_lpuart (UART in rather not
> >> very widespread SoC's Freescale Vybrid and LS1021a).
> >>
> >>
> >> > I'll get to these after 3.19-rc1 is out, but it really looks like these
> >> > will be for 3.20-rc1, unless you break them up into "bugfix only" type
> >> > patches.
> >>
> >>
> >> PATCH 1/4 fixes a bug which happens on a normal console rather often on
> >> my setup. So if you decide that patchset is for 3.20-rc1, that one would
> >> be nice to have in 3.19 as well...
> >
> > Please redo this patchset then, makeing it obvious that some are fixes,
> > and need to go for 3.19 and others are ok for 3.20. As it is, the
> > changelog entries do not look like anything here is for 3.19, sorry.
> >
>
> Ok, will create a patchset with 1 and 3 for 3.19 (since this two really
> lead to reproducible kernel traces), and the rest for 3.20. Do you
> prefer to have the patches in a single patchset (with 3 moved to 2) or
> should I create two patchsets?
What would you want if you were in my shoes and had to maintain two
different branches?
(hint, two different patchsets...)
greg k-h
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2015-01-09 22:34 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-28 0:23 [PATCH 0/4] serial: fsl_lpuart: fix various DMA related issues Stefan Agner
2014-11-28 0:23 ` [PATCH 1/4] serial: fsl_lpuart: delete timer on shutdown Stefan Agner
2014-11-28 0:23 ` [PATCH 2/4] serial: fsl_lpuart: move DMA channel request to probe Stefan Agner
2014-11-28 0:23 ` [PATCH 3/4] serial: fsl_lpuart: avoid new transfer while DMA is running Stefan Agner
2014-11-28 0:23 ` [PATCH 4/4] serial: fsl_lpuart: update RX timer on successful DMA transfer Stefan Agner
2014-12-12 13:44 ` [PATCH 0/4] serial: fsl_lpuart: fix various DMA related issues Stefan Agner
2014-12-12 14:32 ` Greg KH
2014-12-12 16:19 ` Stefan Agner
2015-01-09 22:14 ` Greg KH
2015-01-09 22:19 ` Stefan Agner
2015-01-09 22:34 ` Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).