Re: [GIT PULL] TI clock driver changes for 3.18 merge window
Quoting Tero Kristo (2014-09-29 09:13:09) > Hi Mike, > > The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: > >Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) > > are available in the git repository at: > >g...@github.com:t-kristo/linux-pm.git for-v3.18/ti-clk-driver > > for you to fetch changes up to 04ed831f224d4553682f48e1b4a6b68f2622b68e: > >clk: ti: dra7-atl-clock: Mark the device as pm_runtime_irq_safe > (2014-09-29 11:51:14 +0300) Pulled! Thanks, Mike > > > Mostly fixes, except for the of_clk_init() change for the clock driver. > Boot tested on pretty much every board I have access to, also merge > tested with latest master to see if there are any conflicts with anything. > > > Behan Webster (1): >clk: ti: LLVMLinux: Move __init outside of type definition > > Peter Ujfalusi (1): >clk: ti: dra7-atl-clock: Mark the device as pm_runtime_irq_safe > > Sebastian Andrzej Siewior (1): >clk: ti: consider the fact that of_clk_get() might return an error > > Tero Kristo (2): >clk: ti: change clock init to use generic of_clk_init >clk: ti: dra7-atl-clock: fix a memory leak > > arch/arm/mach-omap2/io.c | 12 +-- > arch/arm/mach-omap2/prm_common.c |2 -- > drivers/clk/ti/clk-dra7-atl.c|2 ++ > drivers/clk/ti/clk.c | 68 > -- > drivers/clk/ti/clockdomain.c |5 +++ > drivers/clk/ti/divider.c |4 +-- > include/linux/clk/ti.h |1 + > 7 files changed, 63 insertions(+), 31 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND v6 0/7] net: cpsw: Support for am335x chip MACIDs
From: Markus Pargmann Date: Mon, 29 Sep 2014 08:53:12 +0200 > Another resend of this series to add the netdev list. > > This series adds support to the cpsw driver to read the MACIDs of the am335x > chip and use them as fallback. These addresses are only used if there are no > mac addresses in the devicetree, for example set by a bootloader. Series applied to net-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/13] arm: dts: am33xx: add DMA properties for UART
Cc: devicet...@vger.kernel.org
Reviewed-by: Tony Lindgren
Tested-by: Tony Lindgren
Signed-off-by: Sebastian Andrzej Siewior
---
arch/arm/boot/dts/am33xx.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 3a0a161342ba..078a760a4a21 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -200,6 +200,8 @@
reg = <0x44e09000 0x2000>;
interrupts = <72>;
status = "disabled";
+ dmas = <&edma 26>, <&edma 27>;
+ dma-names = "tx", "rx";
};
uart1: serial@48022000 {
@@ -209,6 +211,8 @@
reg = <0x48022000 0x2000>;
interrupts = <73>;
status = "disabled";
+ dmas = <&edma 28>, <&edma 29>;
+ dma-names = "tx", "rx";
};
uart2: serial@48024000 {
@@ -218,6 +222,8 @@
reg = <0x48024000 0x2000>;
interrupts = <74>;
status = "disabled";
+ dmas = <&edma 30>, <&edma 31>;
+ dma-names = "tx", "rx";
};
uart3: serial@481a6000 {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/13] tty: serial: 8250: omap: add dma support
This patch adds the required pieces to 8250-OMAP UART driver for DMA
support. The TX burst size is set to 1 so we can send an arbitrary
amount of bytes.
The RX burst is currently set to 48 which means we receive an DMA
interrupt every 48 bytes and have to reprogram everything. Less bytes in
the RX-FIFO mean that no DMA transfer will happen and the UART will send a
RX-timeout _or_ RDI event at which point the FIFO will be manually purged.
There is a workaround for TX-DMA on AM33xx where we put the first byte
into the FIFO to kick start the DMA process. Haven't seen this problem on
OMAP36xx (beagle board xm) or DRA7xx.
On AM375x there is "Usage Note 2.7: UART: Cannot Acknowledge Idle
Requests in Smartidle Mode When Configured for DMA Operations" in the
errata document. This problem persists even after disabling DMA in the
UART and will be addressed in the HWMOD.
v10:
- delay update_registers() from set_termios() until TX-DMA is
done. It has been reported / proved that invoking
update_registers() while TX-DMA is in progress may stall the
DMA operation and it won't finish.
- use the new omap DMA-TX-RX hooks and DMA only interrupt
routine.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250_omap.c | 71 +
1 file changed, 71 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 6500547f8fda..57a8b1241b85 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -88,6 +88,7 @@ struct omap8250_priv {
u8 wer;
u8 xon;
u8 xoff;
+ u8 delayed_restore;
u16 quot;
bool is_suspending;
@@ -211,6 +212,18 @@ static void omap8250_update_scr(struct uart_8250_port *up,
static void omap8250_restore_regs(struct uart_8250_port *up)
{
struct omap8250_priv *priv = up->port.private_data;
+ struct uart_8250_dma*dma = up->dma;
+
+ if (dma && dma->tx_running) {
+ /*
+* TCSANOW requests the change to occur immediately however if
+* we have a TX-DMA operation in progress then it has been
+* observed that it might stall and never complete. Therefore we
+* delay DMA completes to prevent this hang from happen.
+*/
+ priv->delayed_restore = 1;
+ return;
+ }
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
serial_out(up, UART_EFR, UART_EFR_ECB);
@@ -375,6 +388,10 @@ static void omap_8250_set_termios(struct uart_port *port,
priv->scr = OMAP_UART_SCR_RX_TRIG_GRANU1_MASK | OMAP_UART_SCR_TX_EMPTY |
OMAP_UART_SCR_TX_TRIG_GRANU1_MASK;
+ if (up->dma)
+ priv->scr |= OMAP_UART_SCR_DMAMODE_1 |
+ OMAP_UART_SCR_DMAMODE_CTL;
+
priv->xon = termios->c_cc[VSTART];
priv->xoff = termios->c_cc[VSTOP];
@@ -554,6 +571,9 @@ static int omap_8250_startup(struct uart_port *port)
priv->wer |= OMAP_UART_TX_WAKEUP_EN;
serial_out(up, UART_OMAP_WER, priv->wer);
+ if (up->dma)
+ up->dma->rx_dma(up, 0);
+
pm_runtime_mark_last_busy(port->dev);
pm_runtime_put_autosuspend(port->dev);
return 0;
@@ -572,6 +592,8 @@ static void omap_8250_shutdown(struct uart_port *port)
struct omap8250_priv *priv = port->private_data;
flush_work(&priv->qos_work);
+ if (up->dma)
+ up->dma->rx_dma(up, UART_IIR_RX_TIMEOUT);
pm_runtime_get_sync(port->dev);
@@ -725,6 +747,7 @@ static void omap_8250_dma_tx_complete(void *param)
struct circ_buf *xmit = &p->port.state->xmit;
unsigned long flags;
boolen_thri = false;
+ struct omap8250_priv*priv = p->port.private_data;
dma_sync_single_for_cpu(dma->txchan->device->dev, dma->tx_addr,
UART_XMIT_SIZE, DMA_TO_DEVICE);
@@ -737,6 +760,11 @@ static void omap_8250_dma_tx_complete(void *param)
xmit->tail &= UART_XMIT_SIZE - 1;
p->port.icount.tx += dma->tx_size;
+ if (priv->delayed_restore) {
+ priv->delayed_restore = 0;
+ omap8250_restore_regs(p);
+ }
+
if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
uart_write_wakeup(&p->port);
@@ -909,6 +937,18 @@ static int omap_8250_dma_handle_irq(struct uart_port *port)
serial8250_rpm_put(up);
return 1;
}
+
+static bool the_no_dma_filter_fn(struct dma_chan *chan, void *param)
+{
+ return false;
+}
+
+#else
+
+static inline int omap_8250_rx_dma(struct uart_8250_port *p, unsigned int iir)
+{
+ return -EINVAL;
+}
#endif
static int omap8250_probe(struct platform_device *pdev)
@@ -1010,6 +1050,32 @@ static int omap8250_probe(struct platform_device *pdev)
pm_runtime_get_sync(
[PATCH 11/13] arm: dts: dra7: add DMA properties for UART
Cc: devicet...@vger.kernel.org
Reviewed-by: Tony Lindgren
Tested-by: Tony Lindgren
Signed-off-by: Sebastian Andrzej Siewior
---
arch/arm/boot/dts/dra7.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d678152db4cb..f273e3811f75 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -332,6 +332,8 @@
ti,hwmods = "uart1";
clock-frequency = <4800>;
status = "disabled";
+ dmas = <&sdma 49>, <&sdma 50>;
+ dma-names = "tx", "rx";
};
uart2: serial@4806c000 {
@@ -341,6 +343,8 @@
ti,hwmods = "uart2";
clock-frequency = <4800>;
status = "disabled";
+ dmas = <&sdma 51>, <&sdma 52>;
+ dma-names = "tx", "rx";
};
uart3: serial@4802 {
@@ -350,6 +354,8 @@
ti,hwmods = "uart3";
clock-frequency = <4800>;
status = "disabled";
+ dmas = <&sdma 53>, <&sdma 54>;
+ dma-names = "tx", "rx";
};
uart4: serial@4806e000 {
@@ -359,6 +365,8 @@
ti,hwmods = "uart4";
clock-frequency = <4800>;
status = "disabled";
+ dmas = <&sdma 55>, <&sdma 56>;
+ dma-names = "tx", "rx";
};
uart5: serial@48066000 {
@@ -368,6 +376,8 @@
ti,hwmods = "uart5";
clock-frequency = <4800>;
status = "disabled";
+ dmas = <&sdma 63>, <&sdma 64>;
+ dma-names = "tx", "rx";
};
uart6: serial@48068000 {
@@ -377,6 +387,8 @@
ti,hwmods = "uart6";
clock-frequency = <4800>;
status = "disabled";
+ dmas = <&sdma 79>, <&sdma 80>;
+ dma-names = "tx", "rx";
};
uart7: serial@4842 {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/13] tty: serial: 8250: omap: add custom irq handling
We have (or will have) custom DMA callbacks in the omap driver due to
the different behaviour in the RX and TX case. To make this work
we need a few changes in the IRQ handler to invoke the rx_handler again
after the "manual" mode or retry the tx_handler again before falling
back to the manual mode.
Heikki didn't want to see the extra hacks in the generic / default irq
handler and Peter wasn't too happy about an OMAP-only IRQ handler. The
way I planned it is to use this extra IRQ routine only in DMA case. If
Peter dislike this approach then I hope Heikki doesn't block changes in
the default IRQ handler :)
Cc: Heikki Krogerus
Cc: Peter Hurley
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250.h | 2 ++
drivers/tty/serial/8250/8250_core.c | 6 ++--
drivers/tty/serial/8250/8250_omap.c | 55 +
3 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index 4bb831ab5db0..28097a912c10 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -119,6 +119,8 @@ static inline void serial_dl_write(struct uart_8250_port
*up, int value)
}
struct uart_8250_port *serial8250_get_port(int line);
+void serial8250_rpm_get(struct uart_8250_port *p);
+void serial8250_rpm_put(struct uart_8250_port *p);
#if defined(__alpha__) && !defined(CONFIG_PCI)
/*
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 93b0799936fd..6a3b4399bf3c 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -541,20 +541,22 @@ void serial8250_clear_and_reinit_fifos(struct
uart_8250_port *p)
}
EXPORT_SYMBOL_GPL(serial8250_clear_and_reinit_fifos);
-static void serial8250_rpm_get(struct uart_8250_port *p)
+void serial8250_rpm_get(struct uart_8250_port *p)
{
if (!(p->capabilities & UART_CAP_RPM))
return;
pm_runtime_get_sync(p->port.dev);
}
+EXPORT_SYMBOL_GPL(serial8250_rpm_get);
-static void serial8250_rpm_put(struct uart_8250_port *p)
+void serial8250_rpm_put(struct uart_8250_port *p)
{
if (!(p->capabilities & UART_CAP_RPM))
return;
pm_runtime_mark_last_busy(p->port.dev);
pm_runtime_put_autosuspend(p->port.dev);
}
+EXPORT_SYMBOL_GPL(serial8250_rpm_put);
/*
* These two wrappers ensure that enable_runtime_pm_tx() can be called more
than
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 1659858e595a..6500547f8fda 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -854,6 +855,60 @@ static int omap_8250_tx_dma(struct uart_8250_port *p)
return ret;
}
+/*
+ * This is mostly serial8250_handle_irq(). We have a slightly different DMA
+ * hoook for RX/TX and need different logic for them in the ISR. Therefore we
+ * use the default routine in the non-DMA case and this one for with DMA.
+ */
+static int omap_8250_dma_handle_irq(struct uart_port *port)
+{
+ struct uart_8250_port *up = up_to_u8250p(port);
+ unsigned char status;
+ unsigned long flags;
+ u8 iir;
+ int dma_err = 0;
+
+ serial8250_rpm_get(up);
+
+ iir = serial_port_in(port, UART_IIR);
+ if (iir & UART_IIR_NO_INT) {
+ serial8250_rpm_put(up);
+ return 0;
+ }
+
+ spin_lock_irqsave(&port->lock, flags);
+
+ status = serial_port_in(port, UART_LSR);
+
+ if (status & (UART_LSR_DR | UART_LSR_BI)) {
+
+ dma_err = omap_8250_rx_dma(up, iir);
+ if (dma_err) {
+ status = serial8250_rx_chars(up, status);
+ omap_8250_rx_dma(up, 0);
+ }
+ }
+ serial8250_modem_status(up);
+ if (status & UART_LSR_THRE && up->dma->tx_err) {
+ if (uart_tx_stopped(&up->port) ||
+ uart_circ_empty(&up->port.state->xmit)) {
+ up->dma->tx_err = 0;
+ serial8250_tx_chars(up);
+ } else {
+ /*
+* try again due to an earlier failer which
+* might have been resolved by now.
+*/
+ dma_err = omap_8250_tx_dma(up);
+ if (dma_err)
+ serial8250_tx_chars(up);
+ }
+ }
+
+ spin_unlock_irqrestore(&port->lock, flags);
+ serial8250_rpm_put(up);
+ return 1;
+}
#endif
static int omap8250_probe(struct platform_device *pdev)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/13] tty: serial: 8250: make serial8250_console_setup() non _init
if I boot with console=ttyS0 and the omap driver is module I end up with
| console [ttyS0] disabled
| omap8250 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 88, base_baud =
300) is a 8250
| Unable to handle kernel paging request at virtual address c07a9de0
| Modules linked in: 8250_omap(+)
| CPU: 0 PID: 908 Comm: modprobe Not tainted 3.17.0-rc5+ #1593
| PC is at serial8250_console_setup+0x0/0xc8
| LR is at register_console+0x13c/0x3a4
| [] (register_console) from []
(uart_add_one_port+0x3cc/0x420)
| [] (uart_add_one_port) from []
(serial8250_register_8250_port+0x298/0x39c)
| [] (serial8250_register_8250_port) from []
(omap8250_probe+0x218/0x3dc [8250_omap])
| [] (omap8250_probe [8250_omap]) from []
(platform_drv_probe+0x2c/0x5c)
| [] (platform_drv_probe) from []
(driver_probe_device+0x104/0x228)
…
| [] (SyS_init_module) from [] (ret_fast_syscall+0x0/0x30)
| Code: 7823603b f8314620 051b3013 491ed416 (44792204)
because serial8250_console_setup() is already gone.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index a1904628a2a1..159b72471622 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -3237,7 +3237,7 @@ serial8250_console_write(struct console *co, const char
*s, unsigned int count)
serial8250_rpm_put(up);
}
-static int __init serial8250_console_setup(struct console *co, char *options)
+static int serial8250_console_setup(struct console *co, char *options)
{
struct uart_port *port;
int baud = 9600;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/13] tty: serial: Add 8250-core based omap driver
This patch provides a 8250-core based UART driver for the internal OMAP UART. The long term goal is to provide the same functionality as the current OMAP uart driver and DMA support. I tried to merge omap-serial code together with the 8250-core code. There should should be hardly a noticable difference. The trigger levels are different compared to omap-serial: - omap serial TX: Interrupt comes after TX FIFO has room for 16 bytes. TX of 4096 bytes in one go results in 256 interrupts RX: Interrupt comes after there is on byte in the FIFO. RX of 4096 bytes results in 4096 interrupts. - this driver TX: Interrupt comes once the TX FIFO is empty. TX of 4096 bytes results in 65 interrupts. That means there will be gaps on the line while the driver reloads the FIFO. RX: Interrupt comes once there are 48 bytes in the FIFO or less over "longer" time frame. We have 1 / 11520 * 10^3 * 16 => 1.38… ms 1.38ms to react and purge the FIFO on 115200,8N1. Since the other driver fired after each byte it had ~5.47ms time to react. This _may_ cause problems if one relies on no missing bytes and has no flow control. On the other hand we get only 85 interrupts for the same amount of data. It has been only tested as console UART on am335x-evm, dra7-evm and beagle bone. I also did some longer raw-transfers to meassure the load. The device name is ttyS based instead of ttyO. If a ttyO based node name is required please ask udev for it. If both driver are activated (this and omap-serial) then this serial driver will take control over the device due to the link order v9…v10: - Tony noticed that omap3 won't show anything after waking up from core off. In v9 I reworked the register restore and set IER to 0 by accident. This went unnoticed because start_tx usually sets ier (either due to DMA bug or due to TX-complete IRQ). - dropped EFR and SLEEP from capabilities. We do have both but nobody should touch it. We already handle SLEEP ourself. - make the private copy of the registers (like EFR) u8 instead u32 - drop MDR1 & DL[ML] reset in restore registers. Does not look required it is set to the required value later. - update MDR1 & SCR only if changed. - set MDR1 as the last thing. The errata says that we should setup everything before MDR1 set. - avoid div by 0 in omap_8250_get_divisor() if baud rate gets very large (Frans Klaver fixed the same thing omap-serial) - drop "is in early stage" from Kconfig. v8…v9: - less on a file seems to hang the am335x after a while. I believe I introduce this bug a while ago since I can reproduce this prior to v8. Fixed by redoing the omap8250_restore_regs() v7…v8: - redo the register write. There is now one function for that which is used from set_termios() and runtime-resume. - drop PORT_OMAP_16750 and move the setup to the omap file. We have our own set termios function anyway (Heikki Krogerus) - use MEM instead of MEM32. TRM of AM/DM37x says that 32bit access on THR might result in data abort. We only need 32bit access in the errata function which is before we use 8250's read function so it doesn't matter. v4…v7: - change trigger levels after some tests with raw transfers. v3…v4: - drop RS485 support - wire up ->throttle / ->unthrottle v2…v3: - wire up startup & shutdown for wakeup-irq handling. - RS485 handling (well the core does). v1…v2: - added runtime PM. Could somebody could please double check this? - added omap_8250_set_termios() Reviewed-by: Tony Lindgren Tested-by: Tony Lindgren Tested-by: Frans Klaver Signed-off-by: Sebastian Andrzej Siewior --- drivers/tty/serial/8250/8250_omap.c | 914 drivers/tty/serial/8250/Kconfig | 9 + drivers/tty/serial/8250/Makefile| 1 + 3 files changed, 924 insertions(+) create mode 100644 drivers/tty/serial/8250/8250_omap.c diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c new file mode 100644 index ..2f653c48639d --- /dev/null +++ b/drivers/tty/serial/8250/8250_omap.c @@ -0,0 +1,914 @@ +/* + * 8250-core based driver for the OMAP internal UART + * + * based on omap-serial.c, Copyright (C) 2010 Texas Instruments. + * + * Copyright (C) 2014 Sebastian Andrzej Siewior + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "8250.h" + +#define DEFAULT_CLK_SPEED 4800 + +#define UART_ERRATA_i202_MDR1_ACCESS (1 << 0) +#define OMAP_UART_WER_HAS_TX_WAKEUP(1 << 1) + +#define OMAP_UART_FCR_RX_TRIG 6 +#define OMAP_UA
[PATCH 04/13] tty: serial: 8250_dma: handle error on TX submit
Right now it is possible that serial8250_tx_dma() fails and returns
-EBUSY. The caller (serial8250_start_tx()) will then enable
UART_IER_THRI which will generate an interrupt once the TX FIFO is
empty.
In serial8250_handle_irq() nothing will happen because up->dma is set
and so serial8250_tx_chars() won't be invoked. We end up with plenty of
interrupts and some "too much work for irq" output.
This patch introduces dma_tx_err in struct uart_8250_port to signal that
the last invocation of serial8250_tx_dma() failed so we can fill the TX
FIFO manually. Should the next invocation of serial8250_start_tx()
succeed then the dma_tx_err flag along with the THRI bit is removed and
DMA only usage may continue.
Reviewed-by: Tony Lindgren
Tested-by: Tony Lindgren
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250.h | 1 +
drivers/tty/serial/8250/8250_core.c | 3 ++-
drivers/tty/serial/8250/8250_dma.c | 30 +-
3 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index 1bcb4b2141a6..a63d198f8d03 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -41,6 +41,7 @@ struct uart_8250_dma {
size_t tx_size;
unsigned char tx_running:1;
+ unsigned char tx_err: 1;
};
struct old_serial_port {
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 159b72471622..ea57c87f8528 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1594,7 +1594,8 @@ int serial8250_handle_irq(struct uart_port *port,
unsigned int iir)
status = serial8250_rx_chars(up, status);
}
serial8250_modem_status(up);
- if (!up->dma && (status & UART_LSR_THRE))
+ if ((!up->dma || (up->dma && up->dma->tx_err)) &&
+ (status & UART_LSR_THRE))
serial8250_tx_chars(up);
spin_unlock_irqrestore(&port->lock, flags);
diff --git a/drivers/tty/serial/8250/8250_dma.c
b/drivers/tty/serial/8250/8250_dma.c
index 148ffe4c232f..69e54abb6e71 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -36,8 +36,16 @@ static void __dma_tx_complete(void *param)
if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
uart_write_wakeup(&p->port);
- if (!uart_circ_empty(xmit) && !uart_tx_stopped(&p->port))
- serial8250_tx_dma(p);
+ if (!uart_circ_empty(xmit) && !uart_tx_stopped(&p->port)) {
+ int ret;
+
+ ret = serial8250_tx_dma(p);
+ if (ret) {
+ dma->tx_err = 1;
+ p->ier |= UART_IER_THRI;
+ serial_port_out(&p->port, UART_IER, p->ier);
+ }
+ }
spin_unlock_irqrestore(&p->port.lock, flags);
}
@@ -69,6 +77,7 @@ int serial8250_tx_dma(struct uart_8250_port *p)
struct uart_8250_dma*dma = p->dma;
struct circ_buf *xmit = &p->port.state->xmit;
struct dma_async_tx_descriptor *desc;
+ int ret;
if (uart_tx_stopped(&p->port) || dma->tx_running ||
uart_circ_empty(xmit))
@@ -80,8 +89,10 @@ int serial8250_tx_dma(struct uart_8250_port *p)
dma->tx_addr + xmit->tail,
dma->tx_size, DMA_MEM_TO_DEV,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
- if (!desc)
- return -EBUSY;
+ if (!desc) {
+ ret = -EBUSY;
+ goto err;
+ }
dma->tx_running = 1;
@@ -94,8 +105,17 @@ int serial8250_tx_dma(struct uart_8250_port *p)
UART_XMIT_SIZE, DMA_TO_DEVICE);
dma_async_issue_pending(dma->txchan);
-
+ if (dma->tx_err) {
+ dma->tx_err = 0;
+ if (p->ier & UART_IER_THRI) {
+ p->ier &= ~UART_IER_THRI;
+ serial_out(p, UART_IER, p->ier);
+ }
+ }
return 0;
+err:
+ dma->tx_err = 1;
+ return ret;
}
EXPORT_SYMBOL_GPL(serial8250_tx_dma);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/13] tty: serial: 8250: Fix wording in runtime-PM comments
Frans reworded the two comments with better English for better
understanding. His review hit the mailing list after the patch got
applied so here is an incremental update.
Reported-by: Frans Klaver
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 139f3d2b8aa9..a1904628a2a1 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -557,7 +557,7 @@ static void serial8250_rpm_put(struct uart_8250_port *p)
}
/*
- * This two wrapper ensure, that enable_runtime_pm_tx() can be called more than
+ * These two wrappers ensure that enable_runtime_pm_tx() can be called more
than
* once and disable_runtime_pm_tx() will still disable RPM because the fifo is
* empty and the HW can idle again.
*/
@@ -1532,7 +1532,7 @@ void serial8250_tx_chars(struct uart_8250_port *up)
DEBUG_INTR("THRE...");
/*
-* With RPM enabled, we have to wait once the FIFO is empty before the
+* With RPM enabled, we have to wait until the FIFO is empty before the
* HW can go idle. So we get here once again with empty FIFO and disable
* the interrupt and RPM in __stop_tx()
*/
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/13] tty: serial: 8250_omap: add custom DMA-TX callback
This patch provides mostly a copy of serial8250_tx_dma() +
__dma_tx_complete() with the following extensions:
- DMA bug
At least on AM335x the following problem exists: Even if the TX FIFO is
empty and a TX transfer is programmed (and started) the UART does not
trigger the DMA transfer.
After $TRESHOLD number of bytes have been written to the FIFO manually the
UART reevaluates the whole situation and decides that now there is enough
room in the FIFO and so the transfer begins.
This problem has not been seen on DRA7 or beagle board xm (OMAP3). I am not
sure if this is UART-IP core specific or DMA engine.
The workaround is to use a threshold of one byte, program the DMA
transfer minus one byte and then to put the first byte into the FIFO to
kick start the transfer.
- support for runtime PM
RPM is enabled on start_tx(). We can't disable RPM on DMA complete callback
because there is still data in the FIFO which is being sent. We have to wait
until the FIFO is empty before we disable it.
For this to happen we fake a TX sent error and enable THRI. Once the
FIFO is empty we receive an interrupt and since the TTY-buffer is still
empty we "put RPM" via __stop_tx(). Should it been filed then in the
start_tx() path we should program the DMA transfer and remove the error
flag and the THRI bit.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250_omap.c | 144
include/uapi/linux/serial_reg.h | 1 +
2 files changed, 145 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 2f653c48639d..5f183d197dfa 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "8250.h"
@@ -29,6 +30,7 @@
#define UART_ERRATA_i202_MDR1_ACCESS (1 << 0)
#define OMAP_UART_WER_HAS_TX_WAKEUP(1 << 1)
+#define OMAP_DMA_TX_KICK (1 << 2)
#define OMAP_UART_FCR_RX_TRIG 6
#define OMAP_UART_FCR_TX_TRIG 4
@@ -616,6 +618,148 @@ static void omap_8250_unthrottle(struct uart_port *port)
pm_runtime_put_autosuspend(port->dev);
}
+#ifdef CONFIG_SERIAL_8250_DMA
+static int omap_8250_tx_dma(struct uart_8250_port *p);
+
+static void omap_8250_dma_tx_complete(void *param)
+{
+ struct uart_8250_port *p = param;
+ struct uart_8250_dma*dma = p->dma;
+ struct circ_buf *xmit = &p->port.state->xmit;
+ unsigned long flags;
+ boolen_thri = false;
+
+ dma_sync_single_for_cpu(dma->txchan->device->dev, dma->tx_addr,
+ UART_XMIT_SIZE, DMA_TO_DEVICE);
+
+ spin_lock_irqsave(&p->port.lock, flags);
+
+ dma->tx_running = 0;
+
+ xmit->tail += dma->tx_size;
+ xmit->tail &= UART_XMIT_SIZE - 1;
+ p->port.icount.tx += dma->tx_size;
+
+ if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+ uart_write_wakeup(&p->port);
+
+ if (!uart_circ_empty(xmit) && !uart_tx_stopped(&p->port)) {
+ int ret;
+
+ ret = omap_8250_tx_dma(p);
+ if (ret)
+ en_thri = true;
+
+ } else if (p->capabilities & UART_CAP_RPM) {
+ en_thri = true;
+ }
+
+ if (en_thri) {
+ dma->tx_err = 1;
+ p->ier |= UART_IER_THRI;
+ serial_port_out(&p->port, UART_IER, p->ier);
+ }
+
+ spin_unlock_irqrestore(&p->port.lock, flags);
+}
+
+static int omap_8250_tx_dma(struct uart_8250_port *p)
+{
+ struct uart_8250_dma*dma = p->dma;
+ struct omap8250_priv*priv = p->port.private_data;
+ struct circ_buf *xmit = &p->port.state->xmit;
+ struct dma_async_tx_descriptor *desc;
+ unsigned intskip_byte = 0;
+ int ret;
+
+ if (dma->tx_running)
+ return 0;
+ if (uart_tx_stopped(&p->port) || uart_circ_empty(xmit)) {
+
+ /*
+* Even if no data, we need to return an error for the two cases
+* below so serial8250_tx_chars() is invoked and properly clears
+* THRI and/or runtime suspend.
+*/
+ if (dma->tx_err || p->capabilities & UART_CAP_RPM) {
+ ret = -EBUSY;
+ goto err;
+ }
+ if (p->ier & UART_IER_THRI) {
+ p->ier &= ~UART_IER_THRI;
+ serial_out(p, UART_IER, p->ier);
+ }
+ return 0;
+ }
+
+ dma->tx_size = CIRC_CNT_TO_END(xmit->head, xmit->tail, UART_XMIT_SIZE);
+ if (priv->habit & OMAP_DMA_TX_KICK) {
+ u8 tx_lvl;
+
+ /*
+* We need to put the first byte into the FIFO in order to start
+* the DMA transfer. For trans
[PATCH 06/13] tty: serial: 8250: allow to use custom DMA implementation
The OMAP has a few corner cases where it needs a share of kindness of
affection to do the right thing. Heikki Krogerus suggested that instead
adding the quirks into the default DMA implementation, OMAP could get
its own copy of the function. And Alan suggested the same thing so here
we go.
This patch provides callbacks for custom TX/RX DMA implementation. If
there are not setup / used, then the default (current) implementation is
used.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250.h | 3 +++
drivers/tty/serial/8250/8250_core.c | 11 ---
drivers/tty/serial/8250/8250_dma.c | 2 --
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index ebab625179d4..4bb831ab5db0 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -16,6 +16,9 @@
#include
struct uart_8250_dma {
+ int (*tx_dma)(struct uart_8250_port *p);
+ int (*rx_dma)(struct uart_8250_port *p, unsigned int iir);
+
dma_filter_fn fn;
void*rx_param;
void*tx_param;
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index ea57c87f8528..93b0799936fd 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1350,7 +1350,7 @@ static void serial8250_start_tx(struct uart_port *port)
struct uart_8250_port *up = up_to_u8250p(port);
serial8250_rpm_get_tx(up);
- if (up->dma && !serial8250_tx_dma(up)) {
+ if (up->dma && !up->dma->tx_dma(up)) {
return;
} else if (!(up->ier & UART_IER_THRI)) {
up->ier |= UART_IER_THRI;
@@ -1588,7 +1588,7 @@ int serial8250_handle_irq(struct uart_port *port,
unsigned int iir)
if (status & (UART_LSR_DR | UART_LSR_BI)) {
if (up->dma)
- dma_err = serial8250_rx_dma(up, iir);
+ dma_err = up->dma->rx_dma(up, iir);
if (!up->dma || dma_err)
status = serial8250_rx_chars(up, status);
@@ -3624,8 +3624,13 @@ int serial8250_register_8250_port(struct uart_8250_port
*up)
uart->dl_read = up->dl_read;
if (up->dl_write)
uart->dl_write = up->dl_write;
- if (up->dma)
+ if (up->dma) {
uart->dma = up->dma;
+ if (!uart->dma->tx_dma)
+ uart->dma->tx_dma = serial8250_tx_dma;
+ if (!uart->dma->rx_dma)
+ uart->dma->rx_dma = serial8250_rx_dma;
+ }
if (serial8250_isa_config != NULL)
serial8250_isa_config(0, &uart->port,
diff --git a/drivers/tty/serial/8250/8250_dma.c
b/drivers/tty/serial/8250/8250_dma.c
index db9eda3c12d6..258430b72039 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -118,7 +118,6 @@ int serial8250_tx_dma(struct uart_8250_port *p)
dma->tx_err = 1;
return ret;
}
-EXPORT_SYMBOL_GPL(serial8250_tx_dma);
int serial8250_rx_dma(struct uart_8250_port *p, unsigned int iir)
{
@@ -165,7 +164,6 @@ int serial8250_rx_dma(struct uart_8250_port *p, unsigned
int iir)
return 0;
}
-EXPORT_SYMBOL_GPL(serial8250_rx_dma);
int serial8250_request_dma(struct uart_8250_port *p)
{
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/13] tty: serial: 8250_omap: add custom DMA-RX callback
The omap needs a DMA request pending right away. If it is
enqueued once the bytes are in the FIFO then nothing will happen
and the FIFO will be later purged via RX-timeout interrupt.
This patch enqueues RX-DMA request on completion but not if it
was aborted on error. The first enqueue will happen in the driver
in startup.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250_omap.c | 96 +
1 file changed, 96 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 5f183d197dfa..1659858e595a 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -619,6 +619,102 @@ static void omap_8250_unthrottle(struct uart_port *port)
}
#ifdef CONFIG_SERIAL_8250_DMA
+static int omap_8250_rx_dma(struct uart_8250_port *p, unsigned int iir);
+
+static void __dma_rx_do_complete(struct uart_8250_port *p, bool error)
+{
+ struct uart_8250_dma*dma = p->dma;
+ struct tty_port *tty_port = &p->port.state->port;
+ struct dma_tx_state state;
+ int count;
+
+ dma_sync_single_for_cpu(dma->rxchan->device->dev, dma->rx_addr,
+ dma->rx_size, DMA_FROM_DEVICE);
+
+ dma->rx_running = 0;
+ dmaengine_tx_status(dma->rxchan, dma->rx_cookie, &state);
+ dmaengine_terminate_all(dma->rxchan);
+
+ count = dma->rx_size - state.residue;
+
+ tty_insert_flip_string(tty_port, dma->rx_buf, count);
+ p->port.icount.rx += count;
+ if (!error)
+ omap_8250_rx_dma(p, 0);
+
+ tty_flip_buffer_push(tty_port);
+}
+
+static void __dma_rx_complete(void *param)
+{
+ __dma_rx_do_complete(param, false);
+}
+
+static int omap_8250_rx_dma(struct uart_8250_port *p, unsigned int iir)
+{
+ struct uart_8250_dma*dma = p->dma;
+ struct dma_async_tx_descriptor *desc;
+
+ switch (iir & 0x3f) {
+ case UART_IIR_RLSI:
+ /* 8250_core handles errors and break interrupts */
+ if (dma->rx_running) {
+ dmaengine_pause(dma->rxchan);
+ __dma_rx_do_complete(p, true);
+ }
+ return -EIO;
+ case UART_IIR_RX_TIMEOUT:
+ /*
+* If RCVR FIFO trigger level was not reached, complete the
+* transfer and let 8250_core copy the remaining data.
+*/
+ if (dma->rx_running) {
+ dmaengine_pause(dma->rxchan);
+ __dma_rx_do_complete(p, true);
+ }
+ return -ETIMEDOUT;
+ case UART_IIR_RDI:
+ /*
+* The OMAP UART is a special BEAST. If we receive RDI we _have_
+* a DMA transfer programmed but it didn't work. One reason is
+* that we were too slow and there were too many bytes in the
+* FIFO, the UART counted wrong and never kicked the DMA engine
+* to do anything. That means once we receive RDI on OMAP then
+* the DMA won't do anything soon so we have to cancel the DMA
+* transfer and purge the FIFO manually.
+*/
+ if (dma->rx_running) {
+ dmaengine_pause(dma->rxchan);
+ __dma_rx_do_complete(p, true);
+ }
+ return -ETIMEDOUT;
+
+ default:
+ break;
+ }
+
+ if (dma->rx_running)
+ return 0;
+
+ desc = dmaengine_prep_slave_single(dma->rxchan, dma->rx_addr,
+ dma->rx_size, DMA_DEV_TO_MEM,
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ if (!desc)
+ return -EBUSY;
+
+ dma->rx_running = 1;
+ desc->callback = __dma_rx_complete;
+ desc->callback_param = p;
+
+ dma->rx_cookie = dmaengine_submit(desc);
+
+ dma_sync_single_for_device(dma->rxchan->device->dev, dma->rx_addr,
+ dma->rx_size, DMA_FROM_DEVICE);
+
+ dma_async_issue_pending(dma->rxchan);
+ return 0;
+}
+
static int omap_8250_tx_dma(struct uart_8250_port *p);
static void omap_8250_dma_tx_complete(void *param)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/13] tty: serial: 8250_dma: keep own book keeping about RX transfers
After dmaengine_terminate_all() has been invoked then both DMA drivers
(edma and omap-dma) do not invoke dma_cookie_complete() to mark the
transfer as complete. This dma_cookie_complete() is performed by the
Synopsys DesignWare driver which is probably the only one that is used
by omap8250-dma and hence don't see following problem…
…which is that once a RX transfer has been terminated then following
query of channel status reports DMA_IN_PROGRESS (again: the actual
transfer has been canceled, there is nothing going on anymore).
This means that serial8250_rx_dma() never enqueues another DMA transfer
because it (wrongly) assumes that there is a transer already pending.
Vinod Koul refuses to accept a patch which adds this
dma_cookie_complete() to both drivers and so dmaengine_tx_status() would
report DMA_COMPLETE instead (and behave like the Synopsys DesignWare
driver already does). He argues that I am not allowed to use the cookie
to query the status and that the driver already cleaned everything up after
the invokation of dmaengine_terminate_all().
To end this I add a bookkeeping whether or not a RX-transfer has been
started to the 8250-dma code. It has already been done for the TX side.
*Now* we learn about the RX status based on our bookkeeping and don't
need dmaengine_tx_status() for this anymore.
Cc: vinod.k...@intel.com
Reviewed-by: Tony Lindgren
Tested-by: Tony Lindgren
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250.h | 1 +
drivers/tty/serial/8250/8250_dma.c | 10 --
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index a63d198f8d03..ebab625179d4 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -42,6 +42,7 @@ struct uart_8250_dma {
unsigned char tx_running:1;
unsigned char tx_err: 1;
+ unsigned char rx_running:1;
};
struct old_serial_port {
diff --git a/drivers/tty/serial/8250/8250_dma.c
b/drivers/tty/serial/8250/8250_dma.c
index 69e54abb6e71..db9eda3c12d6 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -61,6 +61,7 @@ static void __dma_rx_complete(void *param)
dma_sync_single_for_cpu(dma->rxchan->device->dev, dma->rx_addr,
dma->rx_size, DMA_FROM_DEVICE);
+ dma->rx_running = 0;
dmaengine_tx_status(dma->rxchan, dma->rx_cookie, &state);
dmaengine_terminate_all(dma->rxchan);
@@ -123,10 +124,6 @@ int serial8250_rx_dma(struct uart_8250_port *p, unsigned
int iir)
{
struct uart_8250_dma*dma = p->dma;
struct dma_async_tx_descriptor *desc;
- struct dma_tx_state state;
- int dma_status;
-
- dma_status = dmaengine_tx_status(dma->rxchan, dma->rx_cookie, &state);
switch (iir & 0x3f) {
case UART_IIR_RLSI:
@@ -137,7 +134,7 @@ int serial8250_rx_dma(struct uart_8250_port *p, unsigned
int iir)
* If RCVR FIFO trigger level was not reached, complete the
* transfer and let 8250_core copy the remaining data.
*/
- if (dma_status == DMA_IN_PROGRESS) {
+ if (dma->rx_running) {
dmaengine_pause(dma->rxchan);
__dma_rx_complete(p);
}
@@ -146,7 +143,7 @@ int serial8250_rx_dma(struct uart_8250_port *p, unsigned
int iir)
break;
}
- if (dma_status)
+ if (dma->rx_running)
return 0;
desc = dmaengine_prep_slave_single(dma->rxchan, dma->rx_addr,
@@ -155,6 +152,7 @@ int serial8250_rx_dma(struct uart_8250_port *p, unsigned
int iir)
if (!desc)
return -EBUSY;
+ dma->rx_running = 1;
desc->callback = __dma_rx_complete;
desc->callback_param = p;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/13] dmaengine: edma: check for echan->edesc => NULL in edma_dma_pause()
I added book keeping of whether or not the 8250-dma driver has an RX
transfer pending or not so we don't BUG here if it calls
dmaengine_pause() on a channel which has not a pending transfer. Guess
what, this is not enough.
The following can be triggered with a busy RX channel and hackbench in
background:
- DMA transfer completes. The callback is delayed via
vchan_cookie_complete() into a tasklet so it das not happen asap.
- hackbench keeps the system busy so the tasklet does not run "soon".
- the UART collected enough data and generates an "timeout"-interrupt.
Since 8250-dma *thinks* the DMA-transfer is still pending it tries to
cancel it via invoking dmaengine_pause() first. This causes the segfault
because echan->edesc is NULL now that the transfer completed (however
the callback did not run yet).
With this patch we don't BUG in the scenario described.
Cc: vinod.k...@intel.com
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/dma/edma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 7b65633f495e..123f578d6dd3 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -288,7 +288,7 @@ static int edma_slave_config(struct edma_chan *echan,
static int edma_dma_pause(struct edma_chan *echan)
{
/* Pause/Resume only allowed with cyclic mode */
- if (!echan->edesc->cyclic)
+ if (!echan->edesc || !echan->edesc->cyclic)
return -EINVAL;
edma_pause(echan->ch_num);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/13 v10] omap 8250 based UART + DMA
The queue is getting smaller. The highlights of v9…v10 - the DMA stall Frans Klaver reported which popped up in yocto is gone. It also seems that the "ack the err-irq even if nothing happened" in EDMA can be dropped. - the RX- and TX-DMA callbacks are now OMAP-only and no "bugs" flags are introduced into the generic DMA code. This also means that there is custom IRQ routine in case of DMA. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.17-rc7
* Paul Walmsley [140929 10:14]: > > PM: chip off except CORE via suspend: > Pass ( 1/ 1): 3730beaglexm > > PM: chip off except CORE via dynamic idle: > Pass ( 1/ 1): 3730beaglexm Most likely the two tests above should now also work also for 37xxevm, 3530es3beagle and 3530es31beagle in case you want to enable that. > PM: chip off via suspend: > Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, > 3730es12beaglexm > > PM: chip off via dynamic idle: > Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, > 3730es12beaglexm Since looks like these are working finally :) Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v3.17-rc7
Here are some basic OMAP test results for Linux v3.17-rc7. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.17-rc7/20140928222901/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 4430es2panda, 3517evm Pass (13/17): am335xbonelt, am335xbone, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 PM: chip retention via suspend: skip ( 1/12): 4430es2panda FAIL ( 5/12): am335xbonelt, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: skip ( 1/12): 4430es2panda FAIL ( 6/12): am335xbonelt, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 5/12): 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm vmlinux object size (delta in bytes from test_v3.17-rc6 (0f33be009b89d2268e94194dc4fd01a7851b6d51)): text data bsstotal kernel -5300 -53 omap1_defconfig +11 +320 +43 omap1_defconfig_1510innovator_only -2100 -21 omap1_defconfig_5912osk_only +775 -80 +767 multi_v7_defconfig +55100 +551 omap2plus_defconfig -500 -5 omap2plus_defconfig_2430sdp_only +39100 +391 omap2plus_defconfig_am33xx_only +7900 +79 omap2plus_defconfig_am43xx_only +55100 +551 omap2plus_defconfig_cpupm +15100 +151 omap2plus_defconfig_dra7xx_only -15900 -159 omap2plus_defconfig_n800_multi_omap2xxx -159 +80 -151 omap2plus_defconfig_n800_only_a +54700 +547 omap2plus_defconfig_no_pm +7900 +79 omap2plus_defconfig_omap2_4_only +22700 +227 omap2plus_defconfig_omap3_4_only +7900 +79 omap2plus_defconfig_omap5_only +2600 -60 +200 rmk_omap3430_ldp_allnoconfig +99 -80 +91 rmk_omap3430_ldp_oldconfig +480 +4 +52 rmk_omap4430_sdp_allnoconfig -23 -80 -31 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.17-rc6 (0f33be009b89d2268e94194dc4fd01a7851b6d51)) avail rsrvd high freed board kconfig -224768k -36352k . -404k 3517evmomap2plus_defconfig -484604k -38660k . -404k 4430es2panda omap2plus_defconfig -4k 4k . . am335xbonelt omap2plus_defconfig The 4430 Pandaboard and the 3517EVM have gone offline.
Re: [PATCH 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
* Peter Hurley | 2014-09-17 08:20:41 [-0400]: >> So I connected my am335x-evm >> with beagle board xm because both of them have an old fashion UART >> connector (instead those uart-to-usb). Both configured with HW-Flow and >> I haven't seen the function invoked but I saw "port->icount.overrun" >> being incremented. This shouldn't happen. So I am a little puzzled here… > >Yeah, that's weird. Do you have a break-out box to confirm that RTS/CTS are >being driven? => - beagle board According to schematics the board has only RX and TX connected. No RTS/CTS - am335x-evm The schematics say "DNI" next to a resistor on RTS/CTS. DNI stands most likely for "Do Not Install". With a scope it looks like the the wire behind the MAX is open. - beagle bone black Only RX and TX are wired towards the USB2serial device. In short: each device I have has RTS/CTS not working/connected and I can't test HW handshake with HW available. >Regards, >Peter Hurley Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] TI clock driver changes for 3.18 merge window
Hi Mike, The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) are available in the git repository at: g...@github.com:t-kristo/linux-pm.git for-v3.18/ti-clk-driver for you to fetch changes up to 04ed831f224d4553682f48e1b4a6b68f2622b68e: clk: ti: dra7-atl-clock: Mark the device as pm_runtime_irq_safe (2014-09-29 11:51:14 +0300) Mostly fixes, except for the of_clk_init() change for the clock driver. Boot tested on pretty much every board I have access to, also merge tested with latest master to see if there are any conflicts with anything. Behan Webster (1): clk: ti: LLVMLinux: Move __init outside of type definition Peter Ujfalusi (1): clk: ti: dra7-atl-clock: Mark the device as pm_runtime_irq_safe Sebastian Andrzej Siewior (1): clk: ti: consider the fact that of_clk_get() might return an error Tero Kristo (2): clk: ti: change clock init to use generic of_clk_init clk: ti: dra7-atl-clock: fix a memory leak arch/arm/mach-omap2/io.c | 12 +-- arch/arm/mach-omap2/prm_common.c |2 -- drivers/clk/ti/clk-dra7-atl.c|2 ++ drivers/clk/ti/clk.c | 68 -- drivers/clk/ti/clockdomain.c |5 +++ drivers/clk/ti/divider.c |4 +-- include/linux/clk/ti.h |1 + 7 files changed, 63 insertions(+), 31 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
am335x: hwmod WARN() when CONFIG_PM_RUNTIME=N
Hi all, Booting linux-next for 20140926 with CONFIG_PM_RUNTIME=N on a AM335X Beaglebone, I'm getting these sort of warnings for several devices (timer, uart, gpmc). config: http://sprunge.us/WGLM dmesg, CONFIG_PM_RUNTIME=y: http://sprunge.us/REhi dmesg, CONFIG_PM_RUNTIME=N: http://sprunge.us/YHFZ Any ideas? Here's an example of the warning: [0.217795] WARNING: CPU: 0 PID: 1 at /home/zeta/fast/linux/next/arch/arm/mach-omap2/omap_hwmod.c:2166 _enable+0x270/0x2ac() [0.217805] omap_hwmod: mpu: enabled state can only be entered from initialized, idle, or disabled state [0.217821] CPU: 0 PID: 1 Comm: swapper Tainted: GW 3.17.0-rc6-next-20140926-1-g41b7528 #512 [0.217831] Backtrace: [0.217862] [] (dump_backtrace) from [] (show_stack+0x18/0x1c) [0.217871] r6:c0024e64 r5:0009 r4:df03fbf0 r3: [0.217898] [] (show_stack) from [] (dump_stack+0x20/0x28) [0.217917] [] (dump_stack) from [] (warn_slowpath_common+0x6c/0x8c) [0.217930] [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x38/0x40) [0.217937] r8:dfbd69d4 r7:0001 r6:a113 r5:0001 r4:c04fea44 [0.217965] [] (warn_slowpath_fmt) from [] (_enable+0x270/0x2ac) [0.217972] r3:c047833c r2:c0478ecc [0.217990] [] (_enable) from [] (omap_hwmod_enable+0x2c/0x4c) [0.217997] r7:0001 r6:a113 r5:c04feaa4 r4:c04fea44 [0.218023] [] (omap_hwmod_enable) from [] (omap_device_enable+0x40/0x80) [0.218030] r6:df0ae780 r5:df0ae740 r4: r3:df0ae700 [0.218053] [] (omap_device_enable) from [] (_omap_device_notifier_call+0x1e4/0x200) [0.218060] r5:df0b4c10 r4:df0ae740 [0.218088] [] (_omap_device_notifier_call) from [] (notifier_call_chain+0x4c/0x8c) [0.218095] r10: r9: r8:0001 r7:df0b4c10 r6: r5: [0.218118] r4: [0.218133] [] (notifier_call_chain) from [] (__blocking_notifier_call_chain+0x50/0x68) [0.218140] r8: r7:0001 r6:df0b4c10 r5: r4:df003908 r3: [0.218168] [] (__blocking_notifier_call_chain) from [] (blocking_notifier_call_chain+0x20/0x28) [0.218175] r7:df0b4e10 r6: r5:df0b4c10 r4:df0b4c18 [0.218204] [] (blocking_notifier_call_chain) from [] (device_add+0x3fc/0x50c) [0.218224] [] (device_add) from [] (of_device_add+0x38/0x40) [0.218231] r9:dfbd69d4 r8:df0b4c00 r7:0001 r6:c04e709c r5: r4:df0b4e10 [0.218259] [] (of_device_add) from [] (of_platform_device_create_pdata+0xe0/0x124) [0.218273] [] (of_platform_device_create_pdata) from [] (of_platform_bus_create+0xe8/0x194) [0.218280] r10: r9:df0b4e10 r8:c04eb0e4 r7:0001 r6:c04e709c r5:dfbd69d4 [0.218303] r4: [0.218317] [] (of_platform_bus_create) from [] (of_platform_bus_create+0x144/0x194) [0.218324] r10: r9:df0b4e10 r8:c04eb0e4 r7:0001 r6:c04e709c r5:dfbd68f0 [0.218347] r4:dfbd69d4 [0.218361] [] (of_platform_bus_create) from [] (of_platform_populate+0x64/0xa8) [0.218369] r10:c0520bc0 r9:0001 r8: r7:c04e709c r6:c04eb0e4 r5:dfbd5ae0 [0.218391] r4:dfbd68f0 [0.218409] [] (of_platform_populate) from [] (pdata_quirks_init+0x3c/0x4c) [0.218416] r9: r8:c04c1aac r7:c04bf5e8 r6:df0aeb80 r5:c04eb0e4 r4:c04e7094 [0.218444] [] (pdata_quirks_init) from [] (omap_generic_init+0x18/0x24) [0.218451] r5:c04e59ec r4:c04e59ec [0.218472] [] (omap_generic_init) from [] (customize_machine+0x24/0x48) [0.218487] [] (customize_machine) from [] (do_one_initcall+0x108/0x1d0) [0.218500] [] (do_one_initcall) from [] (kernel_init_freeable+0xfc/0x1c0) [0.218508] r10:c0520bc0 r9:c04e6220 r8:0066 r7:c04bf5e8 r6:c0520bc0 r5:c04e6208 [0.218530] r4:0003 [0.218553] [] (kernel_init_freeable) from [] (kernel_init+0x10/0xf4) [0.218561] r10: r9: r8: r7: r6: r5:c03caa54 [0.218583] r4: [0.218598] [] (kernel_init) from [] (ret_from_fork+0x14/0x2c) [0.218605] r4: r3: [0.218618] ---[ end trace cb88537fdc8fa202 ]--- -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 3/4] rtc: omap: Update Kconfig for OMAP RTC
On Mon, Sep 29, 2014 at 10:55:39AM +0530, Lokesh Vutla wrote: > From: Tero Kristo > > RTC is present in AM43xx and DRA7xx also. Updating the Kconfig > to depend on ARCH_OMAP or ARCH_DAVINCI > > Signed-off-by: Lokesh Vutla > Signed-off-by: Tero Kristo Reviewed-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: [PATCH 02/16] tty: serial: 8250_core: add run time pm
* Frans Klaver | 2014-09-29 11:46:20 [+0200]:
>On Wed, Sep 10, 2014 at 09:29:57PM +0200, Sebastian Andrzej Siewior wrote:
>> +/*
>> + * This two wrapper ensure, that enable_runtime_pm_tx() can be called more
>> than
>
>These two wrappers ensure that enable_runtime_pm_tx() ...
fixed
>> @@ -1469,7 +1531,12 @@ void serial8250_tx_chars(struct uart_8250_port *up)
>>
>> DEBUG_INTR("THRE...");
>>
>> -if (uart_circ_empty(xmit))
>> +/*
>> + * With RPM enabled, we have to wait once the FIFO is empty before the
>
>s,once,until,? Or do I not understand the sentence correctly?
No, you understand it correct. "until" is the better word here.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/16] tty: serial: Add 8250-core based omap driver
On Mon, Sep 29, 2014 at 3:27 PM, Sebastian Andrzej Siewior wrote: > * Frans Klaver | 2014-09-29 11:38:23 [+0200]: > >>threshold > fixed > >>> +/* >>> + * It claims to be 16C750 compatible however it is a little different. >>> + * It has EFR and has no FCR7_64byte bit. The AFE (which it claims to >>> + * have) is enabled via EFR instead of MCR. The type is set here 8250 >>> + * just to get things going. UNKNOWN does not work for a few reasons >>> and >>> + * we don't need our own type since we don't use 8250's set_termios() >>> + * and our "bugs" are handeld via the bug member. >> >>handled > replaced that last line with > or pm callback. > > since there no bugs member anymore. > >> >>> + */ >>> +up.port.type = PORT_8250; >>> +up.port.iotype = UPIO_MEM; >>> +up.port.flags = UPF_FIXED_PORT | UPF_FIXED_TYPE | UPF_SOFT_FLOW | >>> +UPF_HARD_FLOW; >>> +up.port.private_data = priv; >>> + >>> +up.port.regshift = 2; >>> +up.port.fifosize = 64; >>> +up.tx_loadsz = 64; >>> +up.capabilities = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP; >>> +#ifdef CONFIG_PM_RUNTIME >>> +/* >>> + * PM_RUNTIME is mostly transparent. However to do it right we need to >>> a >> >>need to _do_ a ...? > I think dropping that 'to' should fix it. Yup. > >>> + * TX empty interrupt before we can put the device to auto idle. So if >>> + * PM_RUNTIME is not enabled we don't add that flag and can spare that >>> + * one extra interrupt in the TX path. >>> + */ >> >> >> >>> +config SERIAL_8250_OMAP >>> +tristate "Support for OMAP internal UART (8250 based driver)" >>> +depends on SERIAL_8250 && ARCH_OMAP2PLUS >>> +help >>> + If you have a machine based on an Texas Instruments OMAP CPU you >>> + can enable its onboard serial ports by enabling this option. >>> + >>> + This driver is in early stage and uses ttyS instead of ttyO. >>> + >> >>I just wondered if this driver should be marked experimental? > What did you have in mind? CONFIG_EXPERIMENTAL is gone. After all that > debuging that I had in the meantime I was thinking about dropping that > "early stage". That was the other option. I'm good with that. Also, I never noticed CONFIG_EXPERIMENTAL being gone, so that's down the drain ;). > >>Thanks, >>Frans > > Sebastian > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/16] tty: serial: Add 8250-core based omap driver
* Frans Klaver | 2014-09-29 11:38:23 [+0200]: >threshold fixed >> +/* >> + * It claims to be 16C750 compatible however it is a little different. >> + * It has EFR and has no FCR7_64byte bit. The AFE (which it claims to >> + * have) is enabled via EFR instead of MCR. The type is set here 8250 >> + * just to get things going. UNKNOWN does not work for a few reasons and >> + * we don't need our own type since we don't use 8250's set_termios() >> + * and our "bugs" are handeld via the bug member. > >handled replaced that last line with or pm callback. since there no bugs member anymore. > >> + */ >> +up.port.type = PORT_8250; >> +up.port.iotype = UPIO_MEM; >> +up.port.flags = UPF_FIXED_PORT | UPF_FIXED_TYPE | UPF_SOFT_FLOW | >> +UPF_HARD_FLOW; >> +up.port.private_data = priv; >> + >> +up.port.regshift = 2; >> +up.port.fifosize = 64; >> +up.tx_loadsz = 64; >> +up.capabilities = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP; >> +#ifdef CONFIG_PM_RUNTIME >> +/* >> + * PM_RUNTIME is mostly transparent. However to do it right we need to a > >need to _do_ a ...? I think dropping that 'to' should fix it. >> + * TX empty interrupt before we can put the device to auto idle. So if >> + * PM_RUNTIME is not enabled we don't add that flag and can spare that >> + * one extra interrupt in the TX path. >> + */ > > > >> +config SERIAL_8250_OMAP >> +tristate "Support for OMAP internal UART (8250 based driver)" >> +depends on SERIAL_8250 && ARCH_OMAP2PLUS >> +help >> + If you have a machine based on an Texas Instruments OMAP CPU you >> + can enable its onboard serial ports by enabling this option. >> + >> + This driver is in early stage and uses ttyS instead of ttyO. >> + > >I just wondered if this driver should be marked experimental? What did you have in mind? CONFIG_EXPERIMENTAL is gone. After all that debuging that I had in the meantime I was thinking about dropping that "early stage". >Thanks, >Frans Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk, ti, LLVMLinux: Move __init outside of type definition
On 09/27/2014 03:57 AM, Behan Webster wrote:
On 09/26/14 17:55, Felipe Balbi wrote:
On Fri, Sep 26, 2014 at 05:31:48PM -0700, Behan Webster wrote:
As written, the __init for ti_clk_get_div_table is in the middle of
the return
type.
The gcc documentation indicates that section attributes should be
added to the
end of the function declaration:
extern void foobar (void) __attribute__ ((section ("bar")));
However gcc seems to be very permissive with where attributes can be
placed.
clang on the other hand isn't so permissive, and fails if you put the
section
definition in the middle of the return type:
drivers/clk/ti/divider.c:298:28: error: expected ';' after struct
static struct clk_div_table
^
;
drivers/clk/ti/divider.c:298:1: warning: 'static' ignored on this
declaration [-Wmissing-declarations]
static struct clk_div_table
^
drivers/clk/ti/divider.c:299:9: error: type specifier missing,
defaults to 'int' [-Werror,-Wimplicit-int]
__init *ti_clk_get_div_table(struct device_node *node)
~~ ^
drivers/clk/ti/divider.c:345:9: warning: incompatible pointer types
returning 'struct clk_div_table *' from a function with result
type 'int *' [-Wincompatible-pointer-types]
return table;
^
drivers/clk/ti/divider.c:419:9: warning: incompatible pointer types
assigning to 'const struct clk_div_table *' from 'int *'
[-Wincompatible-pointer-types]
*table = ti_clk_get_div_table(node);
^ ~~
3 warnings and 2 errors generated.
By convention, most of the kernel code puts section attributes
between the
return type and function name. In the case where the return type is a
pointer,
it's important to place the '*' on left of the __init.
This updated code works for both gcc and clang.
Signed-off-by: Behan Webster
Reviewed-by: Mark Charlebois
makes sense to me:
Reviewed-by: Felipe Balbi
Thank you.
I wonder if we should add this a Sparse or Coccinelle rule.
+1
I'm hoping it can be added to checkpatch as well.
Behan
Thanks, patch applied to for-v3.18/ti-clk-drv.
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
On Mon, Sep 29, 2014 at 11:54:40AM +0200, Sebastian Andrzej Siewior wrote: > There is a patch named "ARM: edma: unconditionally ack the error > interrupt". I have the feeling that this is not really required once we > delay set_termios. I couldn't reproduce the bug with beagleblack with my > usual test case. I think so too. I didn't need it either. > For your "too much work for irq" problem: Could you add trace_printk() > in tx/rx dma start/complete, and irq routine? The interresting part is > what is the irq routine doing once entered. It might be a condition that > is ignored at first and "acked" later while serving another event. Or it > is really doing something and this is more or less "legal". I'll have a look at that. > > >Thanks, > >Frans > > Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/16] tty: serial: 8250_dma: add pm runtime
* Frans Klaver | 2014-09-29 11:26:06 [+0200]: >On Wed, Sep 10, 2014 at 09:30:08PM +0200, Sebastian Andrzej Siewior wrote: >> There is nothing to do for RPM in the RX path. If the HW goes off then it >> won't assert the DMA line and the transfer won't happen. So we hope that >> the HW does not go off for RX to work (DMA or PIO makes no difference >> here). >> >> For TX the situation is slightly different. RPM is enabled on >> start_tx(). We can't disable RPM on DMA complete callback because there >> is still data in the FIFO which is being sent. We have to wait until >> the FIFO is empty before we disable it. >> For this to happen we fake a TX sent error and enable THRI. Once the >> FIFO is empty we receive an interrupt and since the TTY-buffer is still >> empty we "put RPM" via __stop_tx(). Should it been filed then in the >> start_tx() path we should program the DMA transfer and remove the error >> flag and the THRI bit. > >That last sentence starts out a bit messy. This got mered so there is nothing I can do about it anymore. But I will try to fix comments in code where and in patches that are not yet merged (what you report :)) Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
* Frans Klaver | 2014-09-29 10:50:42 [+0200]: >This version fixes the console things for us. It also increases the >amount of data we can push over the serial port. If I push the data >towards our requirements, we're not there yet. I get the "too much work >for irq" notice still. However, I don't think you'd need to be fixing >that in this series (or at all). We had similar issues there with >omap-serial as well. > >As far as I'm concerned, this is > >Tested-by: Frans Klaver Thanks a lot. There is a patch named "ARM: edma: unconditionally ack the error interrupt". I have the feeling that this is not really required once we delay set_termios. I couldn't reproduce the bug with beagleblack with my usual test case. For your "too much work for irq" problem: Could you add trace_printk() in tx/rx dma start/complete, and irq routine? The interresting part is what is the irq routine doing once entered. It might be a condition that is ignored at first and "acked" later while serving another event. Or it is really doing something and this is more or less "legal". >Thanks, >Frans Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/16] tty: serial: 8250_core: add run time pm
On Wed, Sep 10, 2014 at 09:29:57PM +0200, Sebastian Andrzej Siewior wrote:
> +/*
> + * This two wrapper ensure, that enable_runtime_pm_tx() can be called more
> than
These two wrappers ensure that enable_runtime_pm_tx() ...
> + * once and disable_runtime_pm_tx() will still disable RPM because the fifo
> is
> + * empty and the HW can idle again.
> + */
> +static void serial8250_rpm_get_tx(struct uart_8250_port *p)
> +{
> + unsigned char rpm_active;
> +
> + if (!(p->capabilities & UART_CAP_RPM))
> + return;
> +
> + rpm_active = xchg(&p->rpm_tx_active, 1);
> + if (rpm_active)
> + return;
> + pm_runtime_get_sync(p->port.dev);
> +}
> +
> +static void serial8250_rpm_put_tx(struct uart_8250_port *p)
> +{
> + unsigned char rpm_active;
> +
> + if (!(p->capabilities & UART_CAP_RPM))
> + return;
> +
> + rpm_active = xchg(&p->rpm_tx_active, 0);
> + if (!rpm_active)
> + return;
> + pm_runtime_mark_last_busy(p->port.dev);
> + pm_runtime_put_autosuspend(p->port.dev);
> +}
> +
> @@ -1469,7 +1531,12 @@ void serial8250_tx_chars(struct uart_8250_port *up)
>
> DEBUG_INTR("THRE...");
>
> - if (uart_circ_empty(xmit))
> + /*
> + * With RPM enabled, we have to wait once the FIFO is empty before the
s,once,until,? Or do I not understand the sentence correctly?
> + * HW can go idle. So we get here once again with empty FIFO and disable
> + * the interrupt and RPM in __stop_tx()
> + */
> + if (uart_circ_empty(xmit) && !(up->capabilities & UART_CAP_RPM))
> __stop_tx(up);
> }
> EXPORT_SYMBOL_GPL(serial8250_tx_chars);
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/16] tty: serial: Add 8250-core based omap driver
On Wed, Sep 10, 2014 at 09:30:01PM +0200, Sebastian Andrzej Siewior wrote: > + /* > + * We enable TRIG_GRANU for RX and TX and additionaly we set > + * SCR_TX_EMPTY bit. The result is the following: > + * - RX_TRIGGER amount of bytes in the FIFO will cause an interrupt. > + * - less than RX_TRIGGER number of bytes will also cause an interrupt > + * once the UART decides that there no new bytes arriving. > + * - Once THRE is enabled, the interrupt will be fired once the FIFO is > + * empty - the trigger level is ignored here. > + * > + * Once DMA is enabled: > + * - UART will assert the TX DMA line once there is room for TX_TRIGGER > + * bytes in the TX FIFO. On each assert the DMA engine will move > + * TX_TRIGGER bytes into the FIFO. > + * - UART will assert the RX DMA line once there are RX_TRIGGER bytes in > + * the FIFO and move RX_TRIGGER bytes. > + * This is because treshold and trigger values are the same. threshold > + /* > + * It claims to be 16C750 compatible however it is a little different. > + * It has EFR and has no FCR7_64byte bit. The AFE (which it claims to > + * have) is enabled via EFR instead of MCR. The type is set here 8250 > + * just to get things going. UNKNOWN does not work for a few reasons and > + * we don't need our own type since we don't use 8250's set_termios() > + * and our "bugs" are handeld via the bug member. handled > + */ > + up.port.type = PORT_8250; > + up.port.iotype = UPIO_MEM; > + up.port.flags = UPF_FIXED_PORT | UPF_FIXED_TYPE | UPF_SOFT_FLOW | > + UPF_HARD_FLOW; > + up.port.private_data = priv; > + > + up.port.regshift = 2; > + up.port.fifosize = 64; > + up.tx_loadsz = 64; > + up.capabilities = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP; > +#ifdef CONFIG_PM_RUNTIME > + /* > + * PM_RUNTIME is mostly transparent. However to do it right we need to a need to _do_ a ...? > + * TX empty interrupt before we can put the device to auto idle. So if > + * PM_RUNTIME is not enabled we don't add that flag and can spare that > + * one extra interrupt in the TX path. > + */ > +config SERIAL_8250_OMAP > + tristate "Support for OMAP internal UART (8250 based driver)" > + depends on SERIAL_8250 && ARCH_OMAP2PLUS > + help > + If you have a machine based on an Texas Instruments OMAP CPU you > + can enable its onboard serial ports by enabling this option. > + > + This driver is in early stage and uses ttyS instead of ttyO. > + I just wondered if this driver should be marked experimental? Thanks, Frans -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/9] omap_hsmmc: use separate platform data for ompa3 and omap 1/2 driver
- mmci driver supports multiple slots, omap_hsmmc only one
this leads to one of the major confusions in the omap_hsmmc driver
- platform data should be read-only for the driver
most callbacks are not set by the omap3 platform init code while being
required by the driver, leading to the fact that they are set by the
driver during it's probe function
typical example are card detect / read only detect callbacks
un-bundling by searching for driver name \"omap_hsmmc in the
arch/arm folder. omap_hsmmc_platform_data is not initialized directly,
but from omap2_hsmmc_info, which is defined in a separate header file
not touched by this patch
Signed-off-by: Andreas Fenkart
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 07d4c7b..e3555f2 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -47,7 +47,7 @@ static void omap_hsmmc1_before_set_reg(struct device *dev,
int slot,
int power_on, int vdd)
{
u32 reg, prog_io;
- struct omap_mmc_platform_data *mmc = dev->platform_data;
+ struct omap_hsmmc_platform_data *mmc = dev->platform_data;
if (mmc->slots[0].remux)
mmc->slots[0].remux(dev, slot, power_on);
@@ -120,7 +120,7 @@ static void omap_hsmmc1_after_set_reg(struct device *dev,
int slot,
}
}
-static void hsmmc2_select_input_clk_src(struct omap_mmc_platform_data *mmc)
+static void hsmmc2_select_input_clk_src(struct omap_hsmmc_platform_data *mmc)
{
u32 reg;
@@ -135,7 +135,7 @@ static void hsmmc2_select_input_clk_src(struct
omap_mmc_platform_data *mmc)
static void hsmmc2_before_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
- struct omap_mmc_platform_data *mmc = dev->platform_data;
+ struct omap_hsmmc_platform_data *mmc = dev->platform_data;
if (mmc->slots[0].remux)
mmc->slots[0].remux(dev, slot, power_on);
@@ -147,7 +147,7 @@ static void hsmmc2_before_set_reg(struct device *dev, int
slot,
static int am35x_hsmmc2_set_power(struct device *dev, int slot,
int power_on, int vdd)
{
- struct omap_mmc_platform_data *mmc = dev->platform_data;
+ struct omap_hsmmc_platform_data *mmc = dev->platform_data;
if (power_on)
hsmmc2_select_input_clk_src(mmc);
@@ -161,8 +161,8 @@ static int nop_mmc_set_power(struct device *dev, int slot,
int power_on,
return 0;
}
-static inline void omap_hsmmc_mux(struct omap_mmc_platform_data
*mmc_controller,
- int controller_nr)
+static inline void omap_hsmmc_mux(struct omap_hsmmc_platform_data
+ *mmc_controller, int controller_nr)
{
if (gpio_is_valid(mmc_controller->slots[0].switch_pin) &&
(mmc_controller->slots[0].switch_pin < OMAP_MAX_GPIO_LINES))
@@ -243,7 +243,7 @@ static inline void omap_hsmmc_mux(struct
omap_mmc_platform_data *mmc_controller,
}
static int __init omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
- struct omap_mmc_platform_data *mmc)
+ struct omap_hsmmc_platform_data *mmc)
{
char *hc_name;
@@ -368,7 +368,7 @@ static int omap_hsmmc_done;
void omap_hsmmc_late_init(struct omap2_hsmmc_info *c)
{
struct platform_device *pdev;
- struct omap_mmc_platform_data *mmc_pdata;
+ struct omap_hsmmc_platform_data *mmc_pdata;
int res;
if (omap_hsmmc_done != 1)
@@ -408,12 +408,12 @@ static void __init omap_hsmmc_init_one(struct
omap2_hsmmc_info *hsmmcinfo,
struct omap_device *od;
struct platform_device *pdev;
char oh_name[MAX_OMAP_MMC_HWMOD_NAME_LEN];
- struct omap_mmc_platform_data *mmc_data;
- struct omap_mmc_dev_attr *mmc_dev_attr;
+ struct omap_hsmmc_platform_data *mmc_data;
+ struct omap_hsmmc_dev_attr *mmc_dev_attr;
char *name;
int res;
- mmc_data = kzalloc(sizeof(struct omap_mmc_platform_data), GFP_KERNEL);
+ mmc_data = kzalloc(sizeof(*mmc_data), GFP_KERNEL);
if (!mmc_data) {
pr_err("Cannot allocate memory for mmc device!\n");
return;
@@ -463,7 +463,7 @@ static void __init omap_hsmmc_init_one(struct
omap2_hsmmc_info *hsmmcinfo,
}
res = platform_device_add_data(pdev, mmc_data,
- sizeof(struct omap_mmc_platform_data));
+ sizeof(struct omap_hsmmc_platform_data));
if (res) {
pr_err("Could not add pdata for %s\n", name);
goto put_pdev;
diff --git a/arch/arm/mach-omap2/mmc.h b/arch/arm/mach-omap2/mmc.h
index 0cd4b08..db28c14 100644
--- a/arch/arm/mach-omap2/mmc.h
+++ b/arch/arm/mach-omap2/mmc.h
@@ -1,5 +1,5 @@
#include
-#include
+#include
#define OMAP24XX_NR_MMC2
#define OMAP2420_MMC_SIZE OMAP1_MMC_SI
[PATCH v2 8/9] omap_hsmmc: Remove unnecessary callbacks from platform data
These callbacks are set during driver probe and not from the platform
init, -- evtl. they had been for oamp 1/2 -- for omap3 they are local
functions of the driver. These indirection could be dropped
altogether in favor of regular function calls TODO
Signed-off-by: Andreas Fenkart
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f8cd3b3..0a1398a 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -221,6 +221,25 @@ struct omap_hsmmc_host {
#define HSMMC_WAKE_IRQ_ENABLED (1 << 2)
struct omap_hsmmc_next next_data;
struct omap_hsmmc_platform_data*pdata;
+
+ /* To handle board related suspend/resume functionality for MMC */
+ int (*suspend)(struct device *dev, int slot);
+ int (*resume)(struct device *dev, int slot);
+
+ /* return MMC cover switch state, can be NULL if not supported.
+*
+* possible return values:
+* 0 - closed
+* 1 - open
+*/
+ int (*get_cover_state)(struct device *dev, int slot);
+
+ /* Card detection IRQs */
+ int card_detect_irq;
+
+ int (*card_detect)(struct device *dev, int slot);
+ int (*get_ro)(struct device *dev, int slot);
+
};
struct omap_mmc_of_data {
@@ -262,18 +281,16 @@ static int omap_hsmmc_get_cover_state(struct device *dev,
int slot)
static int omap_hsmmc_suspend_cdirq(struct device *dev, int slot)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
- struct omap_hsmmc_platform_data *mmc = host->pdata;
- disable_irq(mmc->card_detect_irq);
+ disable_irq(host->card_detect_irq);
return 0;
}
static int omap_hsmmc_resume_cdirq(struct device *dev, int slot)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
- struct omap_hsmmc_platform_data *mmc = host->pdata;
- enable_irq(mmc->card_detect_irq);
+ enable_irq(host->card_detect_irq);
return 0;
}
@@ -456,11 +473,11 @@ static int omap_hsmmc_gpio_init(struct omap_hsmmc_host
*host,
if (gpio_is_valid(pdata->switch_pin)) {
if (pdata->cover)
- pdata->get_cover_state =
- omap_hsmmc_get_cover_state;
+ host->get_cover_state =
+ omap_hsmmc_get_cover_state;
else
- pdata->card_detect = omap_hsmmc_card_detect;
- pdata->card_detect_irq =
+ host->card_detect = omap_hsmmc_card_detect;
+ host->card_detect_irq =
gpio_to_irq(pdata->switch_pin);
ret = gpio_request(pdata->switch_pin, "mmc_cd");
if (ret)
@@ -473,7 +490,7 @@ static int omap_hsmmc_gpio_init(struct omap_hsmmc_host
*host,
}
if (gpio_is_valid(pdata->gpio_wp)) {
- pdata->get_ro = omap_hsmmc_get_wp;
+ host->get_ro = omap_hsmmc_get_wp;
ret = gpio_request(pdata->gpio_wp, "mmc_wp");
if (ret)
goto err_free_cd;
@@ -795,8 +812,8 @@ int omap_hsmmc_cover_is_closed(struct omap_hsmmc_host *host)
{
int r = 1;
- if (mmc_pdata(host)->get_cover_state)
- r = mmc_pdata(host)->get_cover_state(host->dev, host->slot_id);
+ if (host->get_cover_state)
+ r = host->get_cover_state(host->dev, host->slot_id);
return r;
}
@@ -1263,11 +1280,11 @@ err:
/* Protect the card while the cover is open */
static void omap_hsmmc_protect_card(struct omap_hsmmc_host *host)
{
- if (!mmc_pdata(host)->get_cover_state)
+ if (!host->get_cover_state)
return;
host->reqs_blocked = 0;
- if (mmc_pdata(host)->get_cover_state(host->dev, host->slot_id)) {
+ if (host->get_cover_state(host->dev, host->slot_id)) {
if (host->protect_card) {
dev_info(host->dev, "%s: cover is closed, "
"card is now accessible\n",
@@ -1290,13 +1307,12 @@ static void omap_hsmmc_protect_card(struct
omap_hsmmc_host *host)
static irqreturn_t omap_hsmmc_detect(int irq, void *dev_id)
{
struct omap_hsmmc_host *host = dev_id;
- struct omap_hsmmc_platform_data *pdata = host->pdata;
int carddetect;
sysfs_notify(&host->mmc->class_dev.kobj, NULL, "cover_switch");
- if (pdata->card_detect)
- carddetect = pdata->card_detect(host->dev, host->slot_id);
+ if (host->card_detect)
+ carddetect = host->card_detect(host->dev, host->slot_id);
else {
omap_hsmmc_protect_card(host);
carddetect = -ENOSYS;
@@ -1672,18 +1688,18 @@ static int omap_hsmmc_get_cd(struct mmc_host *mmc)
{
struct omap_hsmmc_host *host = mmc_priv(mmc);
- if (!mmc_pdata(host)->card_detect)
+ if (!host->card_detect)
[PATCH v2 4/9] omap_hsmmc: remove un-ready power_saving field in omap2_hsmmc_info
these fields are never read, probably an unimplemented feature
or superseded by pm_runtime
Signed-off-by: Andreas Fenkart
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ddfc8df..0a8ac84 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -500,7 +500,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.cover_only = true,
.gpio_cd= 160,
.gpio_wp= -EINVAL,
- .power_saving = true,
},
{
.name = "internal",
@@ -510,7 +509,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.nonremovable = true,
- .power_saving = true,
.remux = rx51_mmc2_remux,
},
{} /* Terminator */
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index bdc8870..30c78c1 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -16,7 +16,6 @@ struct omap2_hsmmc_info {
boolext_clock; /* use external pin for input clock */
boolcover_only; /* No card detect - just cover switch */
boolnonremovable; /* Nonremovable e.g. eMMC */
- boolpower_saving; /* Try to sleep or power off when possible */
booldeferred; /* mmc needs a deferred probe */
int gpio_cd;/* or -EINVAL */
int gpio_wp;/* or -EINVAL */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/9] omap_hsmmc: pass mmc_priv struct to gpio init / free
this is needed when installing callbacks in the host struct and not
in the platform data, e.g. cover detect irq should be stored in
omap_hsmmc_host and not platform data
Signed-off-by: Andreas Fenkart
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d05b7f3..f8cd3b3 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -449,7 +449,8 @@ static inline int omap_hsmmc_have_reg(void)
#endif
-static int omap_hsmmc_gpio_init(struct omap_hsmmc_platform_data *pdata)
+static int omap_hsmmc_gpio_init(struct omap_hsmmc_host *host,
+ struct omap_hsmmc_platform_data *pdata)
{
int ret;
@@ -494,7 +495,8 @@ err_free_sp:
return ret;
}
-static void omap_hsmmc_gpio_free(struct omap_hsmmc_platform_data *pdata)
+static void omap_hsmmc_gpio_free(struct omap_hsmmc_host *host,
+struct omap_hsmmc_platform_data *pdata)
{
if (gpio_is_valid(pdata->gpio_wp))
gpio_free(pdata->gpio_wp);
@@ -2054,14 +2056,10 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
if (IS_ERR(base))
return PTR_ERR(base);
- ret = omap_hsmmc_gpio_init(pdata);
- if (ret)
- goto err;
-
mmc = mmc_alloc_host(sizeof(struct omap_hsmmc_host), &pdev->dev);
if (!mmc) {
ret = -ENOMEM;
- goto err_alloc;
+ goto err;
}
host= mmc_priv(mmc);
@@ -2078,6 +2076,10 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host->next_data.cookie = 1;
host->pbias_enabled = 0;
+ ret = omap_hsmmc_gpio_init(host, pdata);
+ if (ret)
+ goto err_gpio;
+
platform_set_drvdata(pdev, host);
if (pdev->dev.of_node)
@@ -2283,9 +2285,9 @@ err_irq:
if (host->dbclk)
clk_disable_unprepare(host->dbclk);
err1:
+ omap_hsmmc_gpio_free(host, pdata);
+err_gpio:
mmc_free_host(mmc);
-err_alloc:
- omap_hsmmc_gpio_free(pdata);
err:
return ret;
}
@@ -2309,7 +2311,7 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
if (host->dbclk)
clk_disable_unprepare(host->dbclk);
- omap_hsmmc_gpio_free(host->pdata);
+ omap_hsmmc_gpio_free(host, host->pdata);
mmc_free_host(host->mmc);
return 0;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/9] omap_hsmmc: remove un-initialized callbacks from platform data
these callbacks are not set, probably legacy omap 1/2 features
Signed-off-by: Andreas Fenkart
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 5f2b5b7..f68ac1a 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2204,18 +2204,10 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
goto err_irq;
}
- if (pdata->init != NULL) {
- if (pdata->init(&pdev->dev) != 0) {
- dev_err(mmc_dev(host->mmc),
- "Unable to configure MMC IRQs\n");
- goto err_irq;
- }
- }
-
if (omap_hsmmc_have_reg() && !mmc_slot(host).set_power) {
ret = omap_hsmmc_reg_get(host);
if (ret)
- goto err_reg;
+ goto err_irq;
host->use_reg = 1;
}
@@ -2278,9 +2270,6 @@ err_slot_name:
err_irq_cd:
if (host->use_reg)
omap_hsmmc_reg_put(host);
-err_reg:
- if (host->pdata->cleanup)
- host->pdata->cleanup(&pdev->dev);
err_irq:
if (host->tx_chan)
dma_release_channel(host->tx_chan);
@@ -2306,8 +2295,6 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
mmc_remove_host(host->mmc);
if (host->use_reg)
omap_hsmmc_reg_put(host);
- if (host->pdata->cleanup)
- host->pdata->cleanup(&pdev->dev);
if (host->tx_chan)
dma_release_channel(host->tx_chan);
diff --git a/include/linux/platform_data/hsmmc-omap.h
b/include/linux/platform_data/hsmmc-omap.h
index 026efb6..2807786 100644
--- a/include/linux/platform_data/hsmmc-omap.h
+++ b/include/linux/platform_data/hsmmc-omap.h
@@ -45,14 +45,6 @@ struct omap_hsmmc_platform_data {
* maximum frequency on the MMC bus */
unsigned int max_freq;
- /* switch the bus to a new slot */
- int (*switch_slot)(struct device *dev, int slot);
- /* initialize board-specific MMC functionality, can be NULL if
-* not supported */
- int (*init)(struct device *dev);
- void (*cleanup)(struct device *dev);
- void (*shutdown)(struct device *dev);
-
/* To handle board related suspend/resume functionality for MMC */
int (*suspend)(struct device *dev, int slot);
int (*resume)(struct device *dev, int slot);
@@ -95,7 +87,6 @@ struct omap_hsmmc_platform_data {
int switch_pin; /* gpio (card detect) */
int gpio_wp;/* gpio (write protect) */
- int (*set_bus_mode)(struct device *dev, int slot, int bus_mode);
int (*set_power)(struct device *dev, int slot,
int power_on, int vdd);
int (*get_ro)(struct device *dev, int slot);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/9] unshare and simplify omap_hsmmc platform struct
v2: - replace erroneous mmci by omap1/2 - add description to all patches - full compile check with: CONFIG_MACH_OMAP3_BEAGLE=y CONFIG_MACH_DEVKIT8000=y CONFIG_MACH_OMAP_LDP=y CONFIG_MACH_OMAP3530_LV_SOM=y CONFIG_MACH_OMAP3_TORPEDO=y CONFIG_MACH_OVERO=y CONFIG_MACH_OMAP3517EVM=y CONFIG_MACH_CRANEBOARD=y CONFIG_MACH_OMAP3_PANDORA=y CONFIG_MACH_TOUCHBOOK=y CONFIG_MACH_OMAP_3430SDP=y CONFIG_MACH_NOKIA_RX51=y CONFIG_MACH_CM_T35=y CONFIG_MACH_CM_T3517=y CONFIG_MACH_CM_T3730=y CONFIG_MACH_SBC3530=y - reorganized and added more patches, hence no blank ack added Andreas Fenkart (9): omap_hsmmc: use separate platform data for ompa3 and omap 1/2 driver omap_hsmmc: remove unused fields in platform_data omap_hsmmc: remove un-initialized callbacks from platform data omap_hsmmc: remove un-ready power_saving field in omap2_hsmmc_info omap_hsmmc: remove unused get_context_loss_count callback omap_hsmmc: remove unnecessary omap_hsmmc_slot_data indirection omap_hsmmc: pass mmc_priv struct to gpio init / free omap_hsmmc: Remove unnecessary callbacks from platform data omap_hsmmc: remove unused slot_id parameter arch/arm/mach-omap2/board-rx51-peripherals.c | 4 +- arch/arm/mach-omap2/hsmmc.c| 155 +-- arch/arm/mach-omap2/hsmmc.h| 9 +- arch/arm/mach-omap2/mmc.h | 6 +- .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 6 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 6 +- drivers/mmc/host/omap_hsmmc.c | 282 ++--- include/linux/platform_data/hsmmc-omap.h | 88 +++ 8 files changed, 299 insertions(+), 257 deletions(-) create mode 100644 include/linux/platform_data/hsmmc-omap.h -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 9/9] omap_hsmmc: remove unused slot_id parameter
omap_hsmmc only supports one slot. So slot id is always zero, and
slot id is never used in the callbacks
Signed-off-by: Andreas Fenkart
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 0a8ac84..3d5040f 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -484,7 +484,7 @@ static struct omap_mux_partition *partition;
* Current flows to eMMC when eMMC is off and the data lines are pulled up,
* so pull them down. N.B. we pull 8 lines because we are using 8 lines.
*/
-static void rx51_mmc2_remux(struct device *dev, int slot, int power_on)
+static void rx51_mmc2_remux(struct device *dev, int power_on)
{
if (power_on)
omap_mux_write_array(partition, rx51_mmc2_on_mux);
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index a535cd3..bdc0402 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -32,14 +32,14 @@ static u16 control_devconf1_offset;
#define HSMMC_NAME_LEN 9
-static void omap_hsmmc1_before_set_reg(struct device *dev, int slot,
- int power_on, int vdd)
+static void omap_hsmmc1_before_set_reg(struct device *dev,
+ int power_on, int vdd)
{
u32 reg, prog_io;
struct omap_hsmmc_platform_data *mmc = dev->platform_data;
if (mmc->remux)
- mmc->remux(dev, slot, power_on);
+ mmc->remux(dev, power_on);
/*
* Assume we power both OMAP VMMC1 (for CMD, CLK, DAT0..3) and the
@@ -85,8 +85,7 @@ static void omap_hsmmc1_before_set_reg(struct device *dev,
int slot,
}
}
-static void omap_hsmmc1_after_set_reg(struct device *dev, int slot,
-int power_on, int vdd)
+static void omap_hsmmc1_after_set_reg(struct device *dev, int power_on, int
vdd)
{
u32 reg;
@@ -121,20 +120,18 @@ static void hsmmc2_select_input_clk_src(struct
omap_hsmmc_platform_data *mmc)
omap_ctrl_writel(reg, control_devconf1_offset);
}
-static void hsmmc2_before_set_reg(struct device *dev, int slot,
- int power_on, int vdd)
+static void hsmmc2_before_set_reg(struct device *dev, int power_on, int vdd)
{
struct omap_hsmmc_platform_data *mmc = dev->platform_data;
if (mmc->remux)
- mmc->remux(dev, slot, power_on);
+ mmc->remux(dev, power_on);
if (power_on)
hsmmc2_select_input_clk_src(mmc);
}
-static int am35x_hsmmc2_set_power(struct device *dev, int slot,
- int power_on, int vdd)
+static int am35x_hsmmc2_set_power(struct device *dev, int power_on, int vdd)
{
struct omap_hsmmc_platform_data *mmc = dev->platform_data;
@@ -144,8 +141,7 @@ static int am35x_hsmmc2_set_power(struct device *dev, int
slot,
return 0;
}
-static int nop_mmc_set_power(struct device *dev, int slot, int power_on,
- int vdd)
+static int nop_mmc_set_power(struct device *dev, int power_on, int vdd)
{
return 0;
}
@@ -249,7 +245,6 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
snprintf(hc_name, (HSMMC_NAME_LEN + 1), "mmc%islot%i",
c->mmc, 1);
mmc->name = hc_name;
- mmc->nr_slots = 1;
mmc->caps = c->caps;
mmc->internal_clock = !c->ext_clock;
mmc->reg_offset = 0;
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index 30c78c1..148cd9b 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -23,7 +23,7 @@ struct omap2_hsmmc_info {
struct platform_device *pdev; /* mmc controller instance */
int ocr_mask; /* temporary HACK */
/* Remux (pad configuration) when powering on/off */
- void (*remux)(struct device *dev, int slot, int power_on);
+ void (*remux)(struct device *dev, int power_on);
/* init some special card */
void (*init_card)(struct mmc_card *card);
};
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 0a1398a..c063882 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -207,7 +207,6 @@ struct omap_hsmmc_host {
int use_dma, dma_ch;
struct dma_chan *tx_chan;
struct dma_chan *rx_chan;
- int slot_id;
int response_busy;
int context_loss;
int protect_card;
@@ -223,8 +222,8 @@ struct omap_hsmmc_host {
struct omap_hsmmc_platform_data*pdata;
/* To handle board related suspend/resume functionality for MMC */
- int (*suspend)(struct device *dev, int slot);
- int (*
[PATCH v2 6/9] omap_hsmmc: remove unnecessary omap_hsmmc_slot_data indirection
omap_hsmmc supports only one slot per controller, see OMAP_MMC_MAX_SLOTS.
This unnecessary indirection leads to confusion in the omap_hsmmc driver.
For example the card_detect callback is not installed by platform code
but from the driver probe function. So it should be a field of
omap_hsmmc_host. But since it is declared under the platform slot while
the drivers struct omap_hsmmc_host has no slot abstraction, this looks
like a bug, especially when not familiar that this driver only supports
1 slot anyway.
Either we should add a slot abstraction to omap_hsmmc_host or remove
it from the platform data struct. Removed since slot support is
an un-implemented feature
Signed-off-by: Andreas Fenkart
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 312f13d..a535cd3 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -38,8 +38,8 @@ static void omap_hsmmc1_before_set_reg(struct device *dev,
int slot,
u32 reg, prog_io;
struct omap_hsmmc_platform_data *mmc = dev->platform_data;
- if (mmc->slots[0].remux)
- mmc->slots[0].remux(dev, slot, power_on);
+ if (mmc->remux)
+ mmc->remux(dev, slot, power_on);
/*
* Assume we power both OMAP VMMC1 (for CMD, CLK, DAT0..3) and the
@@ -61,7 +61,7 @@ static void omap_hsmmc1_before_set_reg(struct device *dev,
int slot,
omap_ctrl_writel(reg, OMAP243X_CONTROL_DEVCONF1);
}
- if (mmc->slots[0].internal_clock) {
+ if (mmc->internal_clock) {
reg = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
reg |= OMAP2_MMCSDIO1ADPCLKISEL;
omap_ctrl_writel(reg, OMAP2_CONTROL_DEVCONF0);
@@ -114,7 +114,7 @@ static void hsmmc2_select_input_clk_src(struct
omap_hsmmc_platform_data *mmc)
u32 reg;
reg = omap_ctrl_readl(control_devconf1_offset);
- if (mmc->slots[0].internal_clock)
+ if (mmc->internal_clock)
reg |= OMAP2_MMCSDIO2ADPCLKISEL;
else
reg &= ~OMAP2_MMCSDIO2ADPCLKISEL;
@@ -126,8 +126,8 @@ static void hsmmc2_before_set_reg(struct device *dev, int
slot,
{
struct omap_hsmmc_platform_data *mmc = dev->platform_data;
- if (mmc->slots[0].remux)
- mmc->slots[0].remux(dev, slot, power_on);
+ if (mmc->remux)
+ mmc->remux(dev, slot, power_on);
if (power_on)
hsmmc2_select_input_clk_src(mmc);
@@ -153,14 +153,14 @@ static int nop_mmc_set_power(struct device *dev, int
slot, int power_on,
static inline void omap_hsmmc_mux(struct omap_hsmmc_platform_data
*mmc_controller, int controller_nr)
{
- if (gpio_is_valid(mmc_controller->slots[0].switch_pin) &&
- (mmc_controller->slots[0].switch_pin < OMAP_MAX_GPIO_LINES))
- omap_mux_init_gpio(mmc_controller->slots[0].switch_pin,
- OMAP_PIN_INPUT_PULLUP);
- if (gpio_is_valid(mmc_controller->slots[0].gpio_wp) &&
- (mmc_controller->slots[0].gpio_wp < OMAP_MAX_GPIO_LINES))
- omap_mux_init_gpio(mmc_controller->slots[0].gpio_wp,
- OMAP_PIN_INPUT_PULLUP);
+ if (gpio_is_valid(mmc_controller->switch_pin) &&
+ (mmc_controller->switch_pin < OMAP_MAX_GPIO_LINES))
+ omap_mux_init_gpio(mmc_controller->switch_pin,
+ OMAP_PIN_INPUT_PULLUP);
+ if (gpio_is_valid(mmc_controller->gpio_wp) &&
+ (mmc_controller->gpio_wp < OMAP_MAX_GPIO_LINES))
+ omap_mux_init_gpio(mmc_controller->gpio_wp,
+ OMAP_PIN_INPUT_PULLUP);
if (cpu_is_omap34xx()) {
if (controller_nr == 0) {
omap_mux_init_signal("sdmmc1_clk",
@@ -169,7 +169,7 @@ static inline void omap_hsmmc_mux(struct
omap_hsmmc_platform_data
OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal("sdmmc1_dat0",
OMAP_PIN_INPUT_PULLUP);
- if (mmc_controller->slots[0].caps &
+ if (mmc_controller->caps &
(MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA)) {
omap_mux_init_signal("sdmmc1_dat1",
OMAP_PIN_INPUT_PULLUP);
@@ -178,7 +178,7 @@ static inline void omap_hsmmc_mux(struct
omap_hsmmc_platform_data
omap_mux_init_signal("sdmmc1_dat3",
OMAP_PIN_INPUT_PULLUP);
}
- if (mmc_controller->slots[0].caps &
+ if (mmc_controller->caps &
MMC_CAP_8_BIT_DATA) {
omap_mux_init_signal("sdm
[PATCH v2 5/9] omap_hsmmc: remove unused get_context_loss_count callback
trigger of this callback has been removed in 0a82e06e6183
Signed-off-by: Andreas Fenkart
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 1c10402..312f13d 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -32,17 +32,6 @@ static u16 control_devconf1_offset;
#define HSMMC_NAME_LEN 9
-#if defined(CONFIG_ARCH_OMAP3) && defined(CONFIG_PM)
-
-static int hsmmc_get_context_loss(struct device *dev)
-{
- return omap_pm_get_dev_context_loss_count(dev);
-}
-
-#else
-#define hsmmc_get_context_loss NULL
-#endif
-
static void omap_hsmmc1_before_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
@@ -264,7 +253,6 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
mmc->slots[0].caps = c->caps;
mmc->slots[0].internal_clock = !c->ext_clock;
mmc->reg_offset = 0;
- mmc->get_context_loss_count = hsmmc_get_context_loss;
mmc->slots[0].switch_pin = c->gpio_cd;
mmc->slots[0].gpio_wp = c->gpio_wp;
diff --git a/include/linux/platform_data/hsmmc-omap.h
b/include/linux/platform_data/hsmmc-omap.h
index 2807786..dc44dfb 100644
--- a/include/linux/platform_data/hsmmc-omap.h
+++ b/include/linux/platform_data/hsmmc-omap.h
@@ -49,9 +49,6 @@ struct omap_hsmmc_platform_data {
int (*suspend)(struct device *dev, int slot);
int (*resume)(struct device *dev, int slot);
- /* Return context loss count due to PM states changing */
- int (*get_context_loss_count)(struct device *dev);
-
/* Integrating attributes from the omap_hwmod layer */
u8 controller_flags;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/9] omap_hsmmc: remove unused fields in platform_data
platform data is built from omap2_hsmmc_info, remove all fields that
are never set in omap_hsmmc_info, hence never copied to platform data.
Note that the omap_hsmmc driver never used any of these fields, they were
completely unused
compile tested for these platforms
CONFIG_MACH_OMAP3_BEAGLE=y
CONFIG_MACH_DEVKIT8000=y
CONFIG_MACH_OMAP_LDP=y
CONFIG_MACH_OMAP3530_LV_SOM=y
CONFIG_MACH_OMAP3_TORPEDO=y
CONFIG_MACH_OVERO=y
CONFIG_MACH_OMAP3517EVM=y
CONFIG_MACH_CRANEBOARD=y
CONFIG_MACH_OMAP3_PANDORA=y
CONFIG_MACH_TOUCHBOOK=y
CONFIG_MACH_OMAP_3430SDP=y
CONFIG_MACH_NOKIA_RX51=y
CONFIG_MACH_CM_T35=y
CONFIG_MACH_CM_T3517=y
CONFIG_MACH_CM_T3730=y
CONFIG_MACH_SBC3530=y
Signed-off-by: Andreas Fenkart
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index e3555f2..1c10402 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -262,9 +262,7 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
mmc->slots[0].name = hc_name;
mmc->nr_slots = 1;
mmc->slots[0].caps = c->caps;
- mmc->slots[0].pm_caps = c->pm_caps;
mmc->slots[0].internal_clock = !c->ext_clock;
- mmc->max_freq = c->max_freq;
mmc->reg_offset = 0;
mmc->get_context_loss_count = hsmmc_get_context_loss;
@@ -280,18 +278,6 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
if (c->nonremovable)
mmc->slots[0].nonremovable = 1;
- if (c->power_saving)
- mmc->slots[0].power_saving = 1;
-
- if (c->no_off)
- mmc->slots[0].no_off = 1;
-
- if (c->no_off_init)
- mmc->slots[0].no_regulator_off_init = c->no_off_init;
-
- if (c->vcc_aux_disable_is_sleep)
- mmc->slots[0].vcc_aux_disable_is_sleep = 1;
-
/*
* NOTE: MMC slots should have a Vcc regulator set up.
* This may be from a TWL4030-family chip, another
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index 7f2e790..bdc8870 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -12,23 +12,17 @@ struct omap2_hsmmc_info {
u8 mmc;/* controller 1/2/3 */
u32 caps; /* 4/8 wires and any additional host
* capabilities OR'd (ref. linux/mmc/host.h) */
- u32 pm_caps;/* PM capabilities */
booltransceiver;/* MMC-2 option */
boolext_clock; /* use external pin for input clock */
boolcover_only; /* No card detect - just cover switch */
boolnonremovable; /* Nonremovable e.g. eMMC */
boolpower_saving; /* Try to sleep or power off when possible */
- boolno_off; /* power_saving and power is not to go off */
- boolno_off_init;/* no power off when not in MMC sleep state */
- boolvcc_aux_disable_is_sleep; /* Regulator off remapped to sleep */
booldeferred; /* mmc needs a deferred probe */
int gpio_cd;/* or -EINVAL */
int gpio_wp;/* or -EINVAL */
char*name; /* or NULL for default */
struct platform_device *pdev; /* mmc controller instance */
int ocr_mask; /* temporary HACK */
- int max_freq; /* maximum clock, if constrained by external
-* circuitry, or 0 for default */
/* Remux (pad configuration) when powering on/off */
void (*remux)(struct device *dev, int slot, int power_on);
/* init some special card */
diff --git a/include/linux/platform_data/hsmmc-omap.h
b/include/linux/platform_data/hsmmc-omap.h
index cb91db4..026efb6 100644
--- a/include/linux/platform_data/hsmmc-omap.h
+++ b/include/linux/platform_data/hsmmc-omap.h
@@ -30,8 +30,6 @@
#define OMAP_HSMMC_BROKEN_MULTIBLOCK_READ BIT(1)
#define OMAP_HSMMC_SWAKEUP_MISSING BIT(2)
-struct mmc_card;
-
struct omap_hsmmc_dev_attr {
u8 flags;
};
@@ -73,16 +71,9 @@ struct omap_hsmmc_platform_data {
* 4/8 wires and any additional host capabilities
* need to OR'd all capabilities (ref. linux/mmc/host.h)
*/
- u8 wires; /* Used for the MMC driver on omap1 and 2420 */
u32 caps; /* Used for the MMC driver on 2430 and later */
u32 pm_caps;/* PM capabilities of the mmc */
- /*
-* nomux means "standard" muxing is wrong on this board, and
-* that board-specific code handled it before common init logic.
-*/
- unsigned nomux:1;
-
/* switch pin can be for card detect (default) or card cover */
unsigned cover:1;
@@ -92,25 +83,13 @@ struct omap_hsmmc_platform_data {
/* nonremovable e.g. eMMC */
unsigned nonremovable:1;
-
Re: [PATCH 13/16] tty: serial: 8250_dma: add pm runtime
On Wed, Sep 10, 2014 at 09:30:08PM +0200, Sebastian Andrzej Siewior wrote:
> There is nothing to do for RPM in the RX path. If the HW goes off then it
> won't assert the DMA line and the transfer won't happen. So we hope that
> the HW does not go off for RX to work (DMA or PIO makes no difference
> here).
>
> For TX the situation is slightly different. RPM is enabled on
> start_tx(). We can't disable RPM on DMA complete callback because there
> is still data in the FIFO which is being sent. We have to wait until
> the FIFO is empty before we disable it.
> For this to happen we fake a TX sent error and enable THRI. Once the
> FIFO is empty we receive an interrupt and since the TTY-buffer is still
> empty we "put RPM" via __stop_tx(). Should it been filed then in the
> start_tx() path we should program the DMA transfer and remove the error
> flag and the THRI bit.
That last sentence starts out a bit messy.
>
> Reviewed-by: Tony Lindgren
> Tested-by: Tony Lindgren
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> drivers/tty/serial/8250/8250_dma.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_dma.c
> b/drivers/tty/serial/8250/8250_dma.c
> index 898a6781d0b3..e8850219b150 100644
> --- a/drivers/tty/serial/8250/8250_dma.c
> +++ b/drivers/tty/serial/8250/8250_dma.c
> @@ -21,6 +21,7 @@ static void __dma_tx_complete(void *param)
> struct uart_8250_dma*dma = p->dma;
> struct circ_buf *xmit = &p->port.state->xmit;
> unsigned long flags;
> + bool en_thri = false;
>
> dma_sync_single_for_cpu(dma->txchan->device->dev, dma->tx_addr,
> UART_XMIT_SIZE, DMA_TO_DEVICE);
> @@ -40,11 +41,16 @@ static void __dma_tx_complete(void *param)
> int ret;
>
> ret = serial8250_tx_dma(p);
> - if (ret) {
> - dma->tx_err = 1;
> - p->ier |= UART_IER_THRI;
> - serial_port_out(&p->port, UART_IER, p->ier);
> - }
> + if (ret)
> + en_thri = true;
> +
> + } else if (p->capabilities & UART_CAP_RPM)
> + en_thri = true;
> +
> + if (en_thri) {
> + dma->tx_err = 1;
> + p->ier |= UART_IER_THRI;
> + serial_port_out(&p->port, UART_IER, p->ier);
> }
>
> spin_unlock_irqrestore(&p->port.lock, flags);
> --
> 2.1.0
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/16] tty: serial: 8250_dma: handle the UART RDI event while DMA remains idle
On Wed, Sep 10, 2014 at 09:30:07PM +0200, Sebastian Andrzej Siewior wrote:
> Sometimes the OMAP UART does not signal the DMA engine to unload the FIFO.
> Usually this happens when we have >threshold bytes in the FIFO
> and start the DMA transfer. It seems that in those cases the UART won't
> trigger the transfer once the requested threshold is reached. In some
> rare cases the UART does not trigger the DMA transfer even if programmed
> while the FIFO was empty.
> In those cases the UART drops an RDI event and we have to empty the FIFO
> manually. If we ignore it because the DMA transfer is programmed then we
> will enter the function a few times until we receive the RX_TIMEOUT
> event. At that point the FIFO is usually full and we risk to overflow
> the FIFO.
>
> Reviewed-by: Tony Lindgren
> Tested-by: Tony Lindgren
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> drivers/tty/serial/8250/8250_dma.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/tty/serial/8250/8250_dma.c
> b/drivers/tty/serial/8250/8250_dma.c
> index fa1dc966f394..898a6781d0b3 100644
> --- a/drivers/tty/serial/8250/8250_dma.c
> +++ b/drivers/tty/serial/8250/8250_dma.c
> @@ -193,6 +193,24 @@ int serial8250_rx_dma(struct uart_8250_port *p, unsigned
> int iir)
> __dma_rx_do_complete(p, true);
> }
> return -ETIMEDOUT;
> + case UART_IIR_RDI:
> + if (p->bugs & UART_BUG_DMA_RX)
> + break;
> + /*
> + * The OMAP UART is a special BEAST. If we receive RDI we _have_
> + * a DMA transfer programmed but it didn't worked. One reason is
didn't work
> + * that we were too slow and there were too many bytes in the
> + * FIFO, the UART counted wrong and never kicked the DMA engine
> + * to do anything. That means once we receive RDI on OMAP than
then
> + * the DMA won't do anything soon so we have to cancel the DMA
> + * transfer and purge the FIFO manually.
> + */
> + if (dma->rx_running) {
> + dmaengine_pause(dma->rxchan);
> + __dma_rx_do_complete(p, true);
> + }
> + return -ETIMEDOUT;
> +
> default:
> break;
> }
> --
> 2.1.0
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] CLK: TI: consider the fact that of_clk_get() might return an error
On 09/18/2014 05:33 PM, Sebastian Andrzej Siewior wrote:
I "forgot" to update the dtb and the kernel crashed:
|Unable to handle kernel NULL pointer dereference at virtual address 002e
|PC is at __clk_get_flags+0x4/0xc
|LR is at ti_dt_clockdomains_setup+0x70/0xe8
because I did not have the clock nodes. of_clk_get() returns an error
pointer which is not checked here.
Acked-by: Nishanth Menon
Signed-off-by: Sebastian Andrzej Siewior
Thanks, v3 applied to for-v3.18/ti-clk-drv.
-Tero
---
v2…v3:
- added acked by
- fixed "CHECK: Alignment should match open parenthesis"
v1…v2:
add "%s __func__" to the added pr_err
drivers/clk/ti/clockdomain.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/clk/ti/clockdomain.c b/drivers/clk/ti/clockdomain.c
index f1e0038d76ac..b4c5faccaece 100644
--- a/drivers/clk/ti/clockdomain.c
+++ b/drivers/clk/ti/clockdomain.c
@@ -36,6 +36,11 @@ static void __init of_ti_clockdomain_setup(struct
device_node *node)
for (i = 0; i < num_clks; i++) {
clk = of_clk_get(node, i);
+ if (IS_ERR(clk)) {
+ pr_err("%s: Failed get %s' clock nr %d (%ld)\n",
+ __func__, node->full_name, i, PTR_ERR(clk));
+ continue;
+ }
if (__clk_get_flags(clk) & CLK_IS_BASIC) {
pr_warn("can't setup clkdm for basic clk %s\n",
__clk_get_name(clk));
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] clk: ti: change clock init to use generic of_clk_init
On 09/23/2014 06:49 PM, Tony Lindgren wrote:
* Tero Kristo [140912 05:02]:
Previously, the TI clock driver initialized all the clocks hierarchically
under each separate clock provider node. Now, each clock that requires
IO access will instead check their parent node to find out which IO range
to use.
This patch allows the TI clock driver to use a few new features provided
by the generic of_clk_init, and also allows registration of clock nodes
outside the clock hierarchy (for example, any external clocks.)
Signed-off-by: Tero Kristo
Cc: Mike Turquette
Cc: Paul Walmsley
Cc: Tony Lindgren
Cc: Mark Rutland
Cc: Peter Ujfalusi
Cc: Jyri Sarha
Cc: Stefan Assmann
---
Changes from v1:
- fixed the retry logic for deferred clock inits, this wasn't working
properly in v1
Sounds like you want to merge this via the clock tree, so please
feel free to add:
Acked-by: Tony Lindgren
Thanks, applied to for-v3.18/ti-clk-drv.
-Tero
arch/arm/mach-omap2/io.c | 12 +--
arch/arm/mach-omap2/prm_common.c |2 --
drivers/clk/ti/clk.c | 68 --
include/linux/clk/ti.h |1 +
4 files changed, 54 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 5d0667c..a1b82a9 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -734,8 +734,16 @@ int __init omap_clk_init(void)
ti_clk_init_features();
ret = of_prcm_init();
- if (!ret)
- ret = omap_clk_soc_init();
+ if (ret)
+ return ret;
+
+ of_clk_init(NULL);
+
+ ti_dt_clk_init_retry_clks();
+
+ ti_dt_clockdomains_setup();
+
+ ret = omap_clk_soc_init();
return ret;
}
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 76ca320..3b89080 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -525,8 +525,6 @@ int __init of_prcm_init(void)
memmap_index++;
}
- ti_dt_clockdomains_setup();
-
return 0;
}
diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
index b1a6f71..337abe5 100644
--- a/drivers/clk/ti/clk.c
+++ b/drivers/clk/ti/clk.c
@@ -25,8 +25,8 @@
#undef pr_fmt
#define pr_fmt(fmt) "%s: " fmt, __func__
-static int ti_dt_clk_memmap_index;
struct ti_clk_ll_ops *ti_clk_ll_ops;
+static struct device_node *clocks_node_ptr[CLK_MAX_MEMMAPS];
/**
* ti_dt_clocks_register - register DT alias clocks during boot
@@ -108,9 +108,21 @@ void __iomem *ti_clk_get_reg_addr(struct device_node
*node, int index)
struct clk_omap_reg *reg;
u32 val;
u32 tmp;
+ int i;
reg = (struct clk_omap_reg *)&tmp;
- reg->index = ti_dt_clk_memmap_index;
+
+ for (i = 0; i < CLK_MAX_MEMMAPS; i++) {
+ if (clocks_node_ptr[i] == node->parent)
+ break;
+ }
+
+ if (i == CLK_MAX_MEMMAPS) {
+ pr_err("clk-provider not found for %s!\n", node->name);
+ return NULL;
+ }
+
+ reg->index = i;
if (of_property_read_u32_index(node, "reg", index, &val)) {
pr_err("%s must have reg[%d]!\n", node->name, index);
@@ -127,20 +139,14 @@ void __iomem *ti_clk_get_reg_addr(struct device_node
*node, int index)
* @parent: master node
* @index: internal index for clk_reg_ops
*
- * Initializes a master clock IP block and its child clock nodes.
- * Regmap is provided for accessing the register space for the
- * IP block and all the clocks under it.
+ * Initializes a master clock IP block. This basically sets up the
+ * mapping from clocks node to the memory map index. All the clocks
+ * are then initialized through the common of_clk_init call, and the
+ * clocks will access their memory maps based on the node layout.
*/
void ti_dt_clk_init_provider(struct device_node *parent, int index)
{
- const struct of_device_id *match;
- struct device_node *np;
struct device_node *clocks;
- of_clk_init_cb_t clk_init_cb;
- struct clk_init_item *retry;
- struct clk_init_item *tmp;
-
- ti_dt_clk_memmap_index = index;
/* get clocks for this parent */
clocks = of_get_child_by_name(parent, "clocks");
@@ -149,19 +155,31 @@ void ti_dt_clk_init_provider(struct device_node *parent,
int index)
return;
}
- for_each_child_of_node(clocks, np) {
- match = of_match_node(&__clk_of_table, np);
- if (!match)
- continue;
- clk_init_cb = (of_clk_init_cb_t)match->data;
- pr_debug("%s: initializing: %s\n", __func__, np->name);
- clk_init_cb(np);
- }
+ /* add clocks node info */
+ clocks_node_ptr[index] = clocks;
+}
- list_for_each_entry_safe(retry, tmp, &retry_list, link) {
- pr_debug("retry-init: %s\n", retry->n
Re: [PATCH] clk: ti: dra7-atl-clock: Mark the device as pm_runtime_irq_safe
On 09/29/2014 11:10 AM, Peter Ujfalusi wrote: It is safe to call the pm sync calls in interrupt context in this driver. Signed-off-by: Peter Ujfalusi Thanks, applied to for-v3.18/ti-clk-drv. -Tero --- drivers/clk/ti/clk-dra7-atl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/ti/clk-dra7-atl.c b/drivers/clk/ti/clk-dra7-atl.c index af29359677da..f18d149acd65 100644 --- a/drivers/clk/ti/clk-dra7-atl.c +++ b/drivers/clk/ti/clk-dra7-atl.c @@ -228,6 +228,7 @@ static int of_dra7_atl_clk_probe(struct platform_device *pdev) cinfo->iobase = of_iomap(node, 0); cinfo->dev = &pdev->dev; pm_runtime_enable(cinfo->dev); + pm_runtime_irq_safe(cinfo->dev); pm_runtime_get_sync(cinfo->dev); atl_write(cinfo, DRA7_ATL_PCLKMUX_REG(0), DRA7_ATL_PCLKMUX); -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: ti: dra7-atl-clock: fix a memory leak
On 09/15/2014 12:05 PM, Peter Ujfalusi wrote:
On 09/12/2014 04:39 PM, Tero Kristo wrote:
of_clk_add_provider makes an internal copy of the parent_names property
while its called, thus it is no longer needed after this call and can
be freed.
Thanks Tero, indeed this was overlooked in the original driver.
Acked-by: Peter Ujfalusi
Applied to for-v3.18/ti-clk-driver.
-Tero
Signed-off-by: Tero Kristo
Cc: Mike Turquette
Cc: Peter Ujfalusi
---
drivers/clk/ti/clk-dra7-atl.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/ti/clk-dra7-atl.c b/drivers/clk/ti/clk-dra7-atl.c
index 4a65b41..3f9308a 100644
--- a/drivers/clk/ti/clk-dra7-atl.c
+++ b/drivers/clk/ti/clk-dra7-atl.c
@@ -199,6 +199,7 @@ static void __init of_dra7_atl_clock_setup(struct
device_node *node)
if (!IS_ERR(clk)) {
of_clk_add_provider(node, of_clk_src_simple_get, clk);
+ kfree(parent_names);
return;
}
cleanup:
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND v6 0/7] net: cpsw: Support for am335x chip MACIDs
On Monday 29 September 2014 12:23 PM, Markus Pargmann wrote: > Hi, > > Another resend of this series to add the netdev list. > > This series adds support to the cpsw driver to read the MACIDs of the am335x > chip and use them as fallback. These addresses are only used if there are no > mac addresses in the devicetree, for example set by a bootloader. > > Best regards, > > Markus > > > Markus Pargmann (7): > DT doc: net: cpsw mac-address is optional > net: cpsw: Add missing return value > net: cpsw: header, Add missing include > net: cpsw: Replace pr_err by dev_err > net: cpsw: Add am33xx MACID readout > am33xx: define syscon control module device node > arm: dts: am33xx, Add syscon phandle to cpsw node > > Documentation/devicetree/bindings/net/cpsw.txt | 6 +++- > arch/arm/boot/dts/am33xx.dtsi | 6 > drivers/net/ethernet/ti/Kconfig| 2 ++ > drivers/net/ethernet/ti/cpsw.c | 45 > -- > drivers/net/ethernet/ti/cpsw.h | 1 + > 5 files changed, 57 insertions(+), 3 deletions(-) > Acked-by: Mugunthan V N Regards Mugunthan V N -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
On Thu, Sep 25, 2014 at 05:14:03PM +0200, Sebastian Andrzej Siewior wrote: > * Frans Klaver | 2014-09-22 11:28:54 [+0200]: > > >I guess then we'd still have to answer the question why the yocto build > >calls set_termios() so often, but that's not on you then. Did you notice > >it even changing settings? We might want to fix this even if the kernel > >should be able to cope. > > could you please test uart_v10_pre3? I dropped a few register sets and > delayed the register update until TX-DMA is complete. I am traveling > currently and have only my boneblack and it passes my limited testing. > If it solves your problems, too then I would address Heikki's latest > comments and prepare the final v10 (and I hope I didn't break beagle > board in between). This version fixes the console things for us. It also increases the amount of data we can push over the serial port. If I push the data towards our requirements, we're not there yet. I get the "too much work for irq" notice still. However, I don't think you'd need to be fixing that in this series (or at all). We had similar issues there with omap-serial as well. As far as I'm concerned, this is Tested-by: Frans Klaver Thanks, Frans -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clk: ti: dra7-atl-clock: Mark the device as pm_runtime_irq_safe
It is safe to call the pm sync calls in interrupt context in this driver. Signed-off-by: Peter Ujfalusi --- drivers/clk/ti/clk-dra7-atl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/ti/clk-dra7-atl.c b/drivers/clk/ti/clk-dra7-atl.c index af29359677da..f18d149acd65 100644 --- a/drivers/clk/ti/clk-dra7-atl.c +++ b/drivers/clk/ti/clk-dra7-atl.c @@ -228,6 +228,7 @@ static int of_dra7_atl_clk_probe(struct platform_device *pdev) cinfo->iobase = of_iomap(node, 0); cinfo->dev = &pdev->dev; pm_runtime_enable(cinfo->dev); + pm_runtime_irq_safe(cinfo->dev); pm_runtime_get_sync(cinfo->dev); atl_write(cinfo, DRA7_ATL_PCLKMUX_REG(0), DRA7_ATL_PCLKMUX); -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: prevent erronous parsing of children during rate change
On 09/27/2014 02:24 AM, Mike Turquette wrote: Quoting Tero Kristo (2014-09-26 00:18:55) On 09/26/2014 04:35 AM, Stephen Boyd wrote: On 09/23/14 06:38, Tero Kristo wrote: On 09/22/2014 10:18 PM, Stephen Boyd wrote: On 08/21, Tero Kristo wrote: /* Skip children who will be reparented to another clock */ if (child->new_parent && child->new_parent != clk) continue; Are we not hitting the new_parent check here? I don't understand how we can be changing parents here unless the check is being avoided, in which case I wonder why determine_rate isn't being used. It depends how the clock underneath handles the situation. The error I am seeing actually happens with a SoC specific compound clock (DPLL) which integrates set_rate + mux functionality into a single clock node. A call to the clk_set_rate changes the parent of this clock (from bypass clock to reference clock), in addition to changing the rate (tune the mul+div.) I looked at using the determine rate call with this type but it breaks everything up... the parent gets changed but not the clock rate, in addition to some other issues. Ok. Is this omap3_noncore_dpll_set_rate()? Yes. > Can we use determine_rate + clk_set_parent_and_rate()? At least clk_set_parent_and_rate() would allow us to do the mult+div and the parent in the same op call, although I don't understand why setting the parent and then setting the rate is not going to work. Well, setting parent first, then rate later causes problems with the DPLL ending up running with illegal (non-specified) rate, the M+N values are most likely wrong if you just switch from bypass clock to reference clock first without programming the M+N first. I took a quick look and it still seems to me that the OMAP DPLLs are still not modeled properly as mux clocks. Is this correct? Yeah, they are not mux clocks, but rather a compound of mux + DPLL multiplier/divider logic. Changing the DPLL to be a separate mux + DPLL div/mult clock will still have overlapping usage of the DPLL_EN field, as the DPLL must be in bypass mode during M+N change. Or, should the DPLL rate change only be allowed if the mux is in bypass setting? Several drivers still depend on direct dpll clk_set_rate working 'properly' (there are some other issues currently present also which have nothing to do with the mux behavior.) This issue has been lingering for a long time and we can't use determine_rate unless that clock has multiple parents. Simply hacking knowledge of the parent bypass clock into the .set_rate callback is not enough. If you believe this _must_ be changed, I can take a look at this for next merge window, but this will cause a DT data compatibility break if nothing else (personally I don't care about this as I always rebuild DT blob with kernel, but lots of other people seem to do.) -Tero Regards, Mike I'm interested in the other issues that you mentioned too. Mostly these were side-effects from the illegal DPLL setup I guess, like boot hang, failed drivers etc. I didn't really investigate this that much as it is much more simpler just to use safe list iteration here. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
