* Re: [PATCH] serial/efm32: add new driver
From: Uwe Kleine-König @ 2011-12-22 8:57 UTC (permalink / raw)
To: Alan Cox
Cc: linux-kernel, devicetree-discuss, Greg Kroah-Hartman,
linux-serial, kernel
In-Reply-To: <20111221202847.4ffeba10@bob.linux.org.uk>
Hello,
On Wed, Dec 21, 2011 at 08:28:47PM +0000, Alan Cox wrote:
> On Wed, 21 Dec 2011 16:05:59 +0100
> Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
>
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> > Hello,
> >
> > note that ARCH_EFM32 isn't in mainline yet, so to be actually usable
> > some arch patches are needed.
>
> Start by running it through the CodingStyle scripts as I see a //
> comment in there 8)
oops
> > +static void efm32_usart_rx_chars(struct efm32_usart_port *efm_port)
> > +{
> > + struct uart_port *port = &efm_port->port;
> > + struct tty_struct *tty = port->state->port.tty;
>
> Needs to be using krefs and checking the tty is not NULL
> (tty_port_tty_get)
ah, I copied from mxs-auart. Will try to find a better example.
> > +static void efm32_usart_set_termios(struct uart_port *port,
> > + struct ktermios *new, struct ktermios *old)
> > +{
> > + struct efm32_usart_port *efm_port = to_efm_port(port);
> > + unsigned long flags;
> > + unsigned baud;
> > + u32 clkdiv;
> > +
> > + /* no modem control lines */
> > + new->c_cflag &= ~(HUPCL | CRTSCTS | CMSPAR);
>
> Minor item - HUPCL shouldn't get cleared - its a request for hangup
> behaviour not a port feature.
ah, I copied that from imx (in an if(0) though).
> > + /* currently only some features are implemented */
> > + new->c_cflag &= ~CSIZE;
> > + new->c_cflag |= CS8;
> > + new->c_cflag |= CSTOPB;
> > + new->c_cflag &= ~PARENB;
>
> If you can do CS8 without parity you can do CS7 with parity.
I sticked to the things I use and tested. According to the manual the
hardware can do 4 up to 16 data bits with and without parity :-)
> > + new->c_iflag = 0;
>
> This seems broken. Lots of the iflgs are user requests and stack
> properties not port features. For example you can do xon/xoff as its
> pure software. As far as I can see you should leave c_iflag alone.
ok.
I will send an update and fix the drivers I copied from.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 1/2 v2] imx: Add save/restore functions for UART control regs
From: Dirk Behme @ 2011-12-22 8:57 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Dirk Behme, Saleem Abdulrasool, Sascha Hauer, Fabio Estevam,
Uwe Kleine-Koenig, linux-serial, Alan Cox
Factor out the uart save/restore functionality instead of
having the same code several times in the driver.
Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
CC: Saleem Abdulrasool <compnerd@compnerd.org>
CC: Sascha Hauer <s.hauer@pengutronix.de>
CC: Fabio Estevam <festevam@gmail.com>
CC: Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>
CC: linux-serial@vger.kernel.org
CC: Alan Cox <alan@linux.intel.com>
---
Changes in v2:
* Rename imx_console_mode/restore() to imx_port_ucrs_save/restore()
* Introduce struct imx_port_ucrs
* Add Alan Cox to CC
drivers/tty/serial/imx.c | 43 +++++++++++++++++++++++++++++++++++--------
1 files changed, 35 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 163fc90..3daa008 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -207,6 +207,12 @@ struct imx_port {
struct imx_uart_data *devdata;
};
+struct imx_port_ucrs {
+ unsigned int ucr1;
+ unsigned int ucr2;
+ unsigned int ucr3;
+};
+
#ifdef CONFIG_IRDA
#define USE_IRDA(sport) ((sport)->use_irda)
#else
@@ -260,6 +266,27 @@ static inline int is_imx21_uart(struct imx_port *sport)
}
/*
+ * Save and restore functions for UCR1, UCR2 and UCR3 registers
+ */
+static void imx_port_ucrs_save(struct uart_port *port,
+ struct imx_port_ucrs *ucr)
+{
+ /* save control registers */
+ ucr->ucr1 = readl(port->membase + UCR1);
+ ucr->ucr2 = readl(port->membase + UCR2);
+ ucr->ucr3 = readl(port->membase + UCR3);
+}
+
+static void imx_port_ucrs_restore(struct uart_port *port,
+ struct imx_port_ucrs *ucr)
+{
+ /* restore control registers */
+ writel(ucr->ucr1, port->membase + UCR1);
+ writel(ucr->ucr2, port->membase + UCR2);
+ writel(ucr->ucr3, port->membase + UCR3);
+}
+
+/*
* Handle any change of modem status signal since we were last called.
*/
static void imx_mctrl_check(struct imx_port *sport)
@@ -1118,13 +1145,14 @@ static void
imx_console_write(struct console *co, const char *s, unsigned int count)
{
struct imx_port *sport = imx_ports[co->index];
- unsigned int old_ucr1, old_ucr2, ucr1;
+ struct imx_port_ucrs old_ucr;
+ unsigned int ucr1;
/*
- * First, save UCR1/2 and then disable interrupts
+ * First, save UCR1/2/3 and then disable interrupts
*/
- ucr1 = old_ucr1 = readl(sport->port.membase + UCR1);
- old_ucr2 = readl(sport->port.membase + UCR2);
+ imx_port_ucrs_save(&sport->port, &old_ucr);
+ ucr1 = old_ucr.ucr1;
if (is_imx1_uart(sport))
ucr1 |= IMX1_UCR1_UARTCLKEN;
@@ -1133,18 +1161,17 @@ imx_console_write(struct console *co, const char *s, unsigned int count)
writel(ucr1, sport->port.membase + UCR1);
- writel(old_ucr2 | UCR2_TXEN, sport->port.membase + UCR2);
+ writel(old_ucr.ucr2 | UCR2_TXEN, sport->port.membase + UCR2);
uart_console_write(&sport->port, s, count, imx_console_putchar);
/*
* Finally, wait for transmitter to become empty
- * and restore UCR1/2
+ * and restore UCR1/2/3
*/
while (!(readl(sport->port.membase + USR2) & USR2_TXDC));
- writel(old_ucr1, sport->port.membase + UCR1);
- writel(old_ucr2, sport->port.membase + UCR2);
+ imx_port_ucrs_restore(&sport->port, &old_ucr);
}
/*
--
1.7.7.4
^ permalink raw reply related
* [PATCH 2/2 v3] imx: add polled io uart methods
From: Dirk Behme @ 2011-12-22 8:57 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Saleem Abdulrasool, Dirk Behme, Sascha Hauer, Fabio Estevam,
Uwe Kleine-Koenig, linux-serial, Alan Cox
In-Reply-To: <1324544273-9820-1-git-send-email-dirk.behme@gmail.com>
From: Saleem Abdulrasool <compnerd@compnerd.org>
These methods are invoked if the iMX uart is used in conjuction with kgdb during
early boot. In order to access the UART without the interrupts, the kernel uses
the basic polling methods for IO with the device. With these methods
implemented, it is now possible to enable kgdb during early boot over serial.
Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
CC: Sascha Hauer <s.hauer@pengutronix.de>
CC: Fabio Estevam <festevam@gmail.com>
CC: Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>
CC: linux-serial@vger.kernel.org
CC: Alan Cox <alan@linux.intel.com>
---
Changes in v3:
* Remove blank line
* Remove '& 0xff' in 'return c' as 'c' is an unsigned char
* Rename imx_console_mode/restore() to imx_port_ucrs_save/restore()
* Add Alan Cox to CC
Changes in the v2 compared to Saleem's original version:
* Remove volatile form status variable
* Remove blank line
* Factor out imx_console_mode/restore()
drivers/tty/serial/imx.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 3daa008..d6162ec 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -102,6 +102,7 @@
#define UCR2_STPB (1<<6) /* Stop */
#define UCR2_WS (1<<5) /* Word size */
#define UCR2_RTSEN (1<<4) /* Request to send interrupt enable */
+#define UCR2_ATEN (1<<3) /* Aging Timer Enable */
#define UCR2_TXEN (1<<2) /* Transmitter enabled */
#define UCR2_RXEN (1<<1) /* Receiver enabled */
#define UCR2_SRST (1<<0) /* SW reset */
@@ -1106,6 +1107,70 @@ imx_verify_port(struct uart_port *port, struct serial_struct *ser)
return ret;
}
+#if defined(CONFIG_CONSOLE_POLL)
+static int imx_poll_get_char(struct uart_port *port)
+{
+ struct imx_port_ucrs old_ucr;
+ unsigned int status;
+ unsigned char c;
+
+ /* save control registers */
+ imx_port_ucrs_save(port, &old_ucr);
+
+ /* disable interrupts */
+ writel(UCR1_UARTEN, port->membase + UCR1);
+ writel(old_ucr.ucr2 & ~(UCR2_ATEN | UCR2_RTSEN | UCR2_ESCI),
+ port->membase + UCR2);
+ writel(old_ucr.ucr3 & ~(UCR3_DCD | UCR3_RI | UCR3_DTREN),
+ port->membase + UCR3);
+
+ /* poll */
+ do {
+ status = readl(port->membase + USR2);
+ } while (~status & USR2_RDR);
+
+ /* read */
+ c = readl(port->membase + URXD0);
+
+ /* restore control registers */
+ imx_port_ucrs_restore(port, &old_ucr);
+
+ return c;
+}
+
+static void imx_poll_put_char(struct uart_port *port, unsigned char c)
+{
+ struct imx_port_ucrs old_ucr;
+ unsigned int status;
+
+ /* save control registers */
+ imx_port_ucrs_save(port, &old_ucr);
+
+ /* disable interrupts */
+ writel(UCR1_UARTEN, port->membase + UCR1);
+ writel(old_ucr.ucr2 & ~(UCR2_ATEN | UCR2_RTSEN | UCR2_ESCI),
+ port->membase + UCR2);
+ writel(old_ucr.ucr3 & ~(UCR3_DCD | UCR3_RI | UCR3_DTREN),
+ port->membase + UCR3);
+
+ /* drain */
+ do {
+ status = readl(port->membase + USR1);
+ } while (~status & USR1_TRDY);
+
+ /* write */
+ writel(c, port->membase + URTX0);
+
+ /* flush */
+ do {
+ status = readl(port->membase + USR2);
+ } while (~status & USR2_TXDC);
+
+ /* restore control registers */
+ imx_port_ucrs_restore(port, &old_ucr);
+}
+#endif
+
static struct uart_ops imx_pops = {
.tx_empty = imx_tx_empty,
.set_mctrl = imx_set_mctrl,
@@ -1123,6 +1188,10 @@ static struct uart_ops imx_pops = {
.request_port = imx_request_port,
.config_port = imx_config_port,
.verify_port = imx_verify_port,
+#if defined(CONFIG_CONSOLE_POLL)
+ .poll_get_char = imx_poll_get_char,
+ .poll_put_char = imx_poll_put_char,
+#endif
};
static struct imx_port *imx_ports[UART_NR];
--
1.7.7.4
^ permalink raw reply related
* Re: [GIT PULL] ARM: amba: Enable module alias autogeneration for AMBA drivers
From: Dave Martin @ 2011-12-22 11:21 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Alessandro Rubini, patches, linux-kernel, linux-arm-kernel, alan,
a.zummo, alsa-devel, cjb, dan.j.williams, dmitry.torokhov,
grant.likely, perex, jassisinghbrar, julia, linus.walleij,
linux-fbdev, linux-input, linux-mmc, linux-serial, linux-watchdog,
lethal, Pawel.Moll, rtc-linux, spi-devel-general, tiwai,
vinod.koul, wim
In-Reply-To: <20111219213942.GM14542@n2100.arm.linux.org.uk>
On Mon, Dec 19, 2011 at 09:39:42PM +0000, Russell King - ARM Linux wrote:
> On Mon, Dec 19, 2011 at 01:24:09PM +0000, Dave Martin wrote:
> > Hi Russell,
> >
> > This one isn't urgent, but I'm not seeing the amba modalias patches
> > anywhere yet. Did you have any outstanding concerns which need to be
> > resolved?
> >
> > If you can suggest when/if these are likely to merge that would be great.
> >
> > Since Alessandro is now expecting to have to rebase on top of the amba
> > additions anyway, we shouldn't need to worry about conflicting with his
> > patches.
> >
> > Of course, if you've already merged these somewhere, then there's no
> > problem.
>
> I have pulled it, I just haven't merged it in anywhere yet.
OK, great -- thanks.
I wasn't too familiar with the procedure, so I just wanted
to be sure that I hadn't done things wrong.
Have a good Christmas in the meantime!
Cheers
---Dave
^ permalink raw reply
* [PATCH] serial/efm32: add new driver
From: Uwe Kleine-König @ 2011-12-22 13:38 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Alan Cox
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Greg Kroah-Hartman,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <20111221202847.4ffeba10-Z/y2cZnRghHXmaaqVzeoHQ@public.gmane.org>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
changes since (implicit) v1:
- fix checkpatch issues
- use tty_port_tty_get/tty_kref_put in efm32_usart_rx_chars
- handle parity and csize in .set_termios and
efm32_usart_console_get_options
- drop clearing HUPCL from c_cflag and everything from c_iflag in
.set_termios
These were all spotted by Alan.
.../devicetree/bindings/tty/serial/efm32-usart.txt | 14 +
drivers/tty/serial/Kconfig | 10 +
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/efm32-usart.c | 750 ++++++++++++++++++++
include/linux/serial_core.h | 2 +
5 files changed, 777 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/tty/serial/efm32-usart.txt
create mode 100644 drivers/tty/serial/efm32-usart.c
diff --git a/Documentation/devicetree/bindings/tty/serial/efm32-usart.txt b/Documentation/devicetree/bindings/tty/serial/efm32-usart.txt
new file mode 100644
index 0000000..eef2721
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/efm32-usart.txt
@@ -0,0 +1,14 @@
+* Energymicro efm32 UART
+
+Required properties:
+- compatible : Should be "efm32,usart"
+- reg : Address and length of the register set
+- interrupts : Should contain uart interrupt
+
+Example:
+
+uart@0x4000c400 {
+ compatible = "efm32,usart";
+ reg = <0x4000c400 0x400>;
+ interrupts = <15>;
+};
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 925a1e5..cfeb0f3 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1610,4 +1610,14 @@ config SERIAL_XILINX_PS_UART_CONSOLE
help
Enable a Xilinx PS UART port to be the system console.
+config SERIAL_EFM32_USART
+ bool "EFM32 USART port."
+ depends on ARCH_EFM32
+ select SERIAL_CORE
+
+config SERIAL_EFM32_USART_CONSOLE
+ bool "EFM32 USART console support"
+ depends on SERIAL_EFM32_USART=y
+ select SERIAL_CORE_CONSOLE
+
endmenu
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index e10cf5b..d3ab42b 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -94,3 +94,4 @@ obj-$(CONFIG_SERIAL_MSM_SMD) += msm_smd_tty.o
obj-$(CONFIG_SERIAL_MXS_AUART) += mxs-auart.o
obj-$(CONFIG_SERIAL_LANTIQ) += lantiq.o
obj-$(CONFIG_SERIAL_XILINX_PS_UART) += xilinx_uartps.o
+obj-$(CONFIG_SERIAL_EFM32_USART) += efm32-usart.o
diff --git a/drivers/tty/serial/efm32-usart.c b/drivers/tty/serial/efm32-usart.c
new file mode 100644
index 0000000..a46b43c
--- /dev/null
+++ b/drivers/tty/serial/efm32-usart.c
@@ -0,0 +1,750 @@
+#include <linux/kernel.h>
+#include <linux/serial_core.h>
+#include <linux/module.h>
+#include <linux/io.h>
+#include <linux/platform_device.h>
+#include <linux/console.h>
+#include <linux/slab.h>
+#include <linux/clk.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+
+#define DRIVER_NAME "efm32-usart"
+#define DEV_NAME "ttyefm"
+
+#define USARTn_CTRL 0x00
+#define USARTn_CTRL_SYNC 0x0001
+
+#define USARTn_FRAME 0x04
+#define USARTn_FRAME_DATABITS__MASK 0x000f
+#define USARTn_FRAME_DATABITS(n) ((n) - 3)
+#define USARTn_FRAME_PARITY_NONE 0x0000
+#define USARTn_FRAME_PARITY_EVEN 0x0200
+#define USARTn_FRAME_PARITY_ODD 0x0300
+#define USARTn_FRAME_STOPBITS_HALF 0x0000
+#define USARTn_FRAME_STOPBITS_ONE 0x1000
+#define USARTn_FRAME_STOPBITS_TWO 0x3000
+
+#define USARTn_CMD 0x0c
+#define USARTn_CMD_RXEN 0x0001
+#define USARTn_CMD_RXDIS 0x0002
+#define USARTn_CMD_TXEN 0x0004
+#define USARTn_CMD_TXDIS 0x0008
+
+#define USARTn_STATUS 0x10
+#define USARTn_STATUS_TXENS 0x0002
+#define USARTn_STATUS_TXC 0x0020
+#define USARTn_STATUS_TXBL 0x0040
+#define USARTn_STATUS_RXDATAV 0x0080
+
+#define USARTn_CLKDIV 0x14
+
+#define USARTn_RXDATAX 0x18
+#define USARTn_RXDATAX_PERR 0x4000
+#define USARTn_RXDATAX_FERR 0x8000
+
+#define USARTn_TXDATA 0x34
+
+#define USARTn_IF 0x40
+#define USARTn_IF_TXBL 0x0002
+#define USARTn_IF_RXDATAV 0x0004
+
+#define USARTn_IFS 0x44
+#define USARTn_IFC 0x48
+#define USARTn_IEN 0x4c
+
+#define USARTn_ROUTE 0x54
+#define USARTn_ROUTE_RXPEN 0x0001
+#define USARTn_ROUTE_TXPEN 0x0002
+
+struct efm32_usart_port {
+ struct uart_port port;
+ unsigned int txirq;
+ struct clk *clk;
+};
+#define to_efm_port(_port) container_of(_port, struct efm32_usart_port, port)
+#define efm_debug(efm_port, format, arg...) \
+ dev_dbg(efm_port->port.dev, format, ##arg)
+
+static void efm32_usart_write32(struct efm32_usart_port *efm_port,
+ u32 value, unsigned offset)
+{
+ __raw_writel(value, efm_port->port.membase + offset);
+}
+
+static u32 efm32_usart_read32(struct efm32_usart_port *efm_port,
+ unsigned offset)
+{
+ return __raw_readl(efm_port->port.membase + offset);
+}
+
+static unsigned int efm32_usart_tx_empty(struct uart_port *port)
+{
+ struct efm32_usart_port *efm_port = to_efm_port(port);
+ u32 status = efm32_usart_read32(efm_port, USARTn_STATUS);
+
+ /* XXX: does TXBL also mean that the shifter is done? */
+ if (status & USARTn_STATUS_TXBL)
+ return TIOCSER_TEMT;
+ else
+ return 0;
+}
+
+static void efm32_usart_set_mctrl(struct uart_port *port, unsigned int mctrl)
+{
+ /* sorry, neither handshaking lines nor loop functionallity */
+}
+
+static unsigned int efm32_usart_get_mctrl(struct uart_port *port)
+{
+ /* sorry, no handshaking lines available */
+ return TIOCM_CAR | TIOCM_CTS | TIOCM_DSR;
+}
+
+static void efm32_usart_stop_tx(struct uart_port *port)
+{
+ struct efm32_usart_port *efm_port = to_efm_port(port);
+ u32 ien = efm32_usart_read32(efm_port, USARTn_IEN);
+
+ efm32_usart_write32(efm_port, ien & ~USARTn_IF_TXBL, USARTn_IEN);
+}
+
+static void efm32_usart_tx_chars(struct efm32_usart_port *efm_port)
+{
+ struct uart_port *port = &efm_port->port;
+ struct circ_buf *xmit = &port->state->xmit;
+
+ while (efm32_usart_read32(efm_port, USARTn_STATUS) &
+ USARTn_STATUS_TXBL) {
+ if (port->x_char) {
+ port->icount.tx++;
+ efm32_usart_write32(efm_port, port->x_char,
+ USARTn_TXDATA);
+ port->x_char = 0;
+ continue;
+ }
+ if (!uart_circ_empty(xmit) && !uart_tx_stopped(port)) {
+ port->icount.tx++;
+ efm32_usart_write32(efm_port, xmit->buf[xmit->tail],
+ USARTn_TXDATA);
+ xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
+ } else
+ break;
+ }
+
+ if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+ uart_write_wakeup(port);
+
+ if (!port->x_char && uart_circ_empty(xmit))
+ efm32_usart_stop_tx(port);
+}
+
+static void efm32_usart_start_tx(struct uart_port *port)
+{
+ struct efm32_usart_port *efm_port = to_efm_port(port);
+ u32 ien;
+
+ efm32_usart_write32(efm_port, USARTn_IF_TXBL, USARTn_IFC);
+ ien = efm32_usart_read32(efm_port, USARTn_IEN);
+ efm32_usart_write32(efm_port, ien | USARTn_IF_TXBL, USARTn_IEN);
+ efm32_usart_write32(efm_port, USARTn_CMD_TXEN, USARTn_CMD);
+
+ efm32_usart_tx_chars(efm_port);
+}
+
+static void efm32_usart_stop_rx(struct uart_port *port)
+{
+ struct efm32_usart_port *efm_port = to_efm_port(port);
+
+ efm32_usart_write32(efm_port, USARTn_CMD_RXDIS, USARTn_CMD);
+}
+
+static void efm32_usart_enable_ms(struct uart_port *port)
+{
+ /* no handshake lines, no modem status interrupts */
+}
+
+static void efm32_usart_break_ctl(struct uart_port *port, int ctl)
+{
+ /* not possible without fiddling with gpios */
+}
+
+static void efm32_usart_rx_chars(struct efm32_usart_port *efm_port)
+{
+ struct uart_port *port = &efm_port->port;
+ struct tty_struct *tty = tty_port_tty_get(&port->state->port);
+
+ spin_lock(&port->lock);
+
+ while (efm32_usart_read32(efm_port, USARTn_STATUS) &
+ USARTn_STATUS_RXDATAV) {
+ u32 rxdata = efm32_usart_read32(efm_port, USARTn_RXDATAX);
+ int flag = 0;
+
+ port->icount.rx++;
+
+ /* XXX detect BREAK and overrun */
+
+ if (rxdata & USARTn_RXDATAX_PERR) {
+ port->icount.parity++;
+ if (port->read_status_mask & USARTn_RXDATAX_PERR)
+ flag = TTY_PARITY;
+ } else if (rxdata & USARTn_RXDATAX_FERR) {
+ port->icount.frame++;
+ if (port->read_status_mask & USARTn_RXDATAX_FERR)
+ flag = TTY_FRAME;
+ }
+
+ if (rxdata & port->ignore_status_mask)
+ continue;
+
+ if (tty)
+ tty_insert_flip_char(tty, rxdata, flag);
+ }
+ spin_unlock(&port->lock);
+
+ if (tty) {
+ tty_flip_buffer_push(tty);
+ tty_kref_put(tty);
+ }
+}
+
+static irqreturn_t efm32_usart_rxirq(int irq, void *data)
+{
+ struct efm32_usart_port *efm_port = data;
+ u32 irqflag = efm32_usart_read32(efm_port, USARTn_IF);
+
+ if (irqflag & USARTn_IF_RXDATAV) {
+ efm32_usart_write32(efm_port, USARTn_IF_RXDATAV, USARTn_IFC);
+ efm32_usart_rx_chars(efm_port);
+
+ return IRQ_HANDLED;
+ } else
+ return IRQ_NONE;
+}
+
+static irqreturn_t efm32_usart_txirq(int irq, void *data)
+{
+ struct efm32_usart_port *efm_port = data;
+ u32 irqflag = efm32_usart_read32(efm_port, USARTn_IF);
+
+ if (irqflag & USARTn_IF_TXBL) {
+ efm32_usart_write32(efm_port, USARTn_IF_TXBL, USARTn_IFC);
+ efm32_usart_tx_chars(efm_port);
+ return IRQ_HANDLED;
+ } else
+ return IRQ_NONE;
+}
+
+static int efm32_usart_startup(struct uart_port *port)
+{
+ struct efm32_usart_port *efm_port = to_efm_port(port);
+ int ret;
+
+ ret = clk_enable(efm_port->clk);
+ if (ret) {
+ efm_debug(efm_port, "failed to enable clk\n");
+ goto err_clk_enable;
+ }
+ port->uartclk = clk_get_rate(efm_port->clk);
+
+ /* Enable pins at default location */
+ efm32_usart_write32(efm_port, USARTn_ROUTE_RXPEN | USARTn_ROUTE_TXPEN,
+ USARTn_ROUTE);
+
+ ret = request_irq(port->irq, efm32_usart_rxirq, 0,
+ DRIVER_NAME, efm_port);
+ if (ret) {
+ efm_debug(efm_port, "failed to register rxirq\n");
+ goto err_request_irq_rx;
+ }
+
+ /* disable all irqs */
+ efm32_usart_write32(efm_port, 0, USARTn_IEN);
+
+ ret = request_irq(efm_port->txirq, efm32_usart_txirq, 0,
+ DRIVER_NAME, efm_port);
+ if (ret) {
+ efm_debug(efm_port, "failed to register txirq\n");
+ free_irq(port->irq, efm_port);
+err_request_irq_rx:
+
+ clk_disable(efm_port->clk);
+ } else {
+ efm32_usart_write32(efm_port, USARTn_IF_RXDATAV, USARTn_IEN);
+ efm32_usart_write32(efm_port, USARTn_CMD_RXEN, USARTn_CMD);
+ }
+
+err_clk_enable:
+ return ret;
+}
+
+static void efm32_usart_shutdown(struct uart_port *port)
+{
+ struct efm32_usart_port *efm_port = to_efm_port(port);
+
+ efm32_usart_write32(efm_port, 0, USARTn_IEN);
+ free_irq(port->irq, efm_port);
+
+ clk_disable(efm_port->clk);
+}
+
+static void efm32_usart_set_termios(struct uart_port *port,
+ struct ktermios *new, struct ktermios *old)
+{
+ struct efm32_usart_port *efm_port = to_efm_port(port);
+ unsigned long flags;
+ unsigned baud;
+ u32 clkdiv;
+ u32 frame = 0;
+
+ /* no modem control lines */
+ new->c_cflag &= ~(CRTSCTS | CMSPAR);
+
+ baud = uart_get_baud_rate(port, new, old,
+ DIV_ROUND_CLOSEST(port->uartclk, 16 * 8192),
+ DIV_ROUND_CLOSEST(port->uartclk, 16));
+
+ switch (new->c_cflag & CSIZE) {
+ case CS5:
+ frame |= USARTn_FRAME_DATABITS(5);
+ break;
+ case CS6:
+ frame |= USARTn_FRAME_DATABITS(6);
+ break;
+ case CS7:
+ frame |= USARTn_FRAME_DATABITS(7);
+ break;
+ case CS8:
+ frame |= USARTn_FRAME_DATABITS(8);
+ break;
+ }
+
+ /* tx only supports a "half" stop bit */
+ new->c_cflag |= CSTOPB;
+ frame |= USARTn_FRAME_STOPBITS_ONE;
+
+ if (new->c_cflag & PARENB) {
+ if (new->c_cflag & PARODD)
+ frame |= USARTn_FRAME_PARITY_ODD;
+ else
+ frame |= USARTn_FRAME_PARITY_EVEN;
+ } else
+ frame |= USARTn_FRAME_PARITY_NONE;
+
+ /*
+ * the 6 lowest bits of CLKDIV are dc, bit 6 has value 0.25.
+ * port->uartclk <= 14e6, so 4 * port->uartclk doesn't overflow.
+ */
+ clkdiv = (DIV_ROUND_CLOSEST(4 * port->uartclk, 16 * baud) - 4) << 6;
+
+ spin_lock_irqsave(&port->lock, flags);
+
+ efm32_usart_write32(efm_port,
+ USARTn_CMD_TXDIS | USARTn_CMD_RXDIS, USARTn_CMD);
+
+ port->read_status_mask = 0;
+ port->ignore_status_mask = 0;
+
+ uart_update_timeout(port, new->c_cflag, baud);
+
+ efm32_usart_write32(efm_port, 0, USARTn_CTRL);
+ efm32_usart_write32(efm_port, frame, USARTn_FRAME);
+ efm32_usart_write32(efm_port, clkdiv, USARTn_CLKDIV);
+
+ efm32_usart_write32(efm_port, USARTn_CMD_TXEN | USARTn_CMD_RXEN,
+ USARTn_CMD);
+
+ spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static const char *efm32_usart_type(struct uart_port *port)
+{
+ return port->type == PORT_EFMUSART ? "efm32-usart" : NULL;
+}
+
+static void efm32_usart_release_port(struct uart_port *port)
+{
+ struct efm32_usart_port *efm_port = to_efm_port(port);
+
+ clk_unprepare(efm_port->clk);
+ clk_put(efm_port->clk);
+ iounmap(port->membase);
+}
+
+static int efm32_usart_request_port(struct uart_port *port)
+{
+ struct efm32_usart_port *efm_port = to_efm_port(port);
+ int ret;
+
+ port->membase = ioremap(port->mapbase, 60);
+ if (!efm_port->port.membase) {
+ ret = -ENOMEM;
+ efm_debug(efm_port, "failed to remap\n");
+ goto err_ioremap;
+ }
+
+ efm_port->clk = clk_get(port->dev, NULL);
+ if (IS_ERR(efm_port->clk)) {
+ ret = PTR_ERR(efm_port->clk);
+ efm_debug(efm_port, "failed to get clock\n");
+ goto err_clk_get;
+ }
+
+ ret = clk_prepare(efm_port->clk);
+ if (ret) {
+ clk_put(efm_port->clk);
+err_clk_get:
+
+ iounmap(port->membase);
+err_ioremap:
+ return ret;
+ }
+ return 0;
+}
+
+static void efm32_usart_config_port(struct uart_port *port, int type)
+{
+ if (type & UART_CONFIG_TYPE &&
+ !efm32_usart_request_port(port))
+ port->type = PORT_EFMUSART;
+}
+
+static int efm32_usart_verify_port(struct uart_port *port,
+ struct serial_struct *serinfo)
+{
+ int ret = 0;
+
+ if (serinfo->type != PORT_UNKNOWN && serinfo->type != PORT_EFMUSART)
+ ret = -EINVAL;
+
+ return ret;
+}
+
+static struct uart_ops efm32_usart_pops = {
+ .tx_empty = efm32_usart_tx_empty,
+ .set_mctrl = efm32_usart_set_mctrl,
+ .get_mctrl = efm32_usart_get_mctrl,
+ .stop_tx = efm32_usart_stop_tx,
+ .start_tx = efm32_usart_start_tx,
+ .stop_rx = efm32_usart_stop_rx,
+ .enable_ms = efm32_usart_enable_ms,
+ .break_ctl = efm32_usart_break_ctl,
+ .startup = efm32_usart_startup,
+ .shutdown = efm32_usart_shutdown,
+ .set_termios = efm32_usart_set_termios,
+ .type = efm32_usart_type,
+ .release_port = efm32_usart_release_port,
+ .request_port = efm32_usart_request_port,
+ .config_port = efm32_usart_config_port,
+ .verify_port = efm32_usart_verify_port,
+};
+
+static struct efm32_usart_port *efm32_usart_ports[3];
+
+#ifdef CONFIG_SERIAL_EFM32_USART_CONSOLE
+static void efm32_usart_console_putchar(struct uart_port *port, int ch)
+{
+ struct efm32_usart_port *efm_port = to_efm_port(port);
+ unsigned int timeout = 0x400;
+ u32 status;
+
+ while (1) {
+ status = efm32_usart_read32(efm_port, USARTn_STATUS);
+
+ if (status & USARTn_STATUS_TXBL)
+ break;
+ if (!timeout--)
+ return;
+ }
+ efm32_usart_write32(efm_port, ch, USARTn_TXDATA);
+}
+
+static void efm32_usart_console_write(struct console *co, const char *s,
+ unsigned int count)
+{
+ struct efm32_usart_port *efm_port = efm32_usart_ports[co->index];
+ u32 status = efm32_usart_read32(efm_port, USARTn_STATUS);
+ unsigned int timeout = 0x400;
+
+ if (!(status & USARTn_STATUS_TXENS))
+ efm32_usart_write32(efm_port, USARTn_CMD_TXEN, USARTn_CMD);
+
+ uart_console_write(&efm_port->port, s, count,
+ efm32_usart_console_putchar);
+
+ /* Wait for the transmitter to become empty */
+ while (1) {
+ u32 status = efm32_usart_read32(efm_port, USARTn_STATUS);
+ if (status & USARTn_STATUS_TXC)
+ break;
+ if (!timeout--)
+ break;
+ }
+
+ if (!(status & USARTn_STATUS_TXENS))
+ efm32_usart_write32(efm_port, USARTn_CMD_TXDIS, USARTn_CMD);
+}
+
+static void efm32_usart_console_get_options(struct efm32_usart_port *efm_port,
+ int *baud, int *parity, int *bits)
+{
+ u32 ctrl = efm32_usart_read32(efm_port, USARTn_CTRL);
+ u32 route, clkdiv, frame;
+
+ if (ctrl & USARTn_CTRL_SYNC)
+ /* not operating in async mode */
+ return;
+
+ route = efm32_usart_read32(efm_port, USARTn_ROUTE);
+ if (!(route & USARTn_ROUTE_TXPEN))
+ /* tx pin not routed */
+ return;
+
+ clkdiv = efm32_usart_read32(efm_port, USARTn_CLKDIV);
+
+ *baud = DIV_ROUND_CLOSEST(4 * efm_port->port.uartclk,
+ 16 * (4 + (clkdiv >> 6)));
+
+ frame = efm32_usart_read32(efm_port, USARTn_FRAME);
+ if (frame & USARTn_FRAME_PARITY_ODD)
+ *parity = 'o';
+ else if (frame & USARTn_FRAME_PARITY_EVEN)
+ *parity = 'e';
+ else
+ *parity = 'n';
+
+ *bits = (frame & USARTn_FRAME_DATABITS__MASK) -
+ USARTn_FRAME_DATABITS(4) + 4;
+
+ efm_debug(efm_port, "get_opts: options=%d%c%d\n",
+ *baud, *parity, *bits);
+}
+
+static int efm32_usart_console_setup(struct console *co, char *options)
+{
+ struct efm32_usart_port *efm_port;
+ int baud = 115200;
+ int bits = 8;
+ int parity = 'n';
+ int flow = 'n';
+ int ret;
+
+ if (co->index < 0 || co->index >= ARRAY_SIZE(efm32_usart_ports)) {
+ unsigned i;
+ for (i = 0; i < ARRAY_SIZE(efm32_usart_ports); ++i) {
+ if (efm32_usart_ports[i]) {
+ pr_warn("efm32-console: fall back to console index %u (from %hhi)\n",
+ i, co->index);
+ co->index = i;
+ break;
+ }
+ }
+ }
+
+ efm_port = efm32_usart_ports[co->index];
+ if (!efm_port) {
+ pr_warn("efm32-console: No port at %d\n", co->index);
+ return -ENODEV;
+ }
+
+ ret = clk_prepare(efm_port->clk);
+ if (ret) {
+ dev_warn(efm_port->port.dev,
+ "console: clk_prepare failed: %d\n", ret);
+ return ret;
+ }
+
+ efm_port->port.uartclk = clk_get_rate(efm_port->clk);
+
+ if (options)
+ uart_parse_options(options, &baud, &parity, &bits, &flow);
+ else
+ efm32_usart_console_get_options(efm_port,
+ &baud, &parity, &bits);
+
+ return uart_set_options(&efm_port->port, co, baud, parity, bits, flow);
+}
+
+static struct uart_driver efm32_usart_reg;
+
+static struct console efm32_usart_console = {
+ .name = DEV_NAME,
+ .write = efm32_usart_console_write,
+ .device = uart_console_device,
+ .setup = efm32_usart_console_setup,
+ .flags = CON_PRINTBUFFER,
+ .index = -1,
+ .data = &efm32_usart_reg,
+};
+
+#else
+#define efm32_usart_console (*(struct console *)NULL)
+#endif /* ifdef CONFIG_SERIAL_EFM32_USART_CONSOLE / else */
+
+static struct uart_driver efm32_usart_reg = {
+ .owner = THIS_MODULE,
+ .driver_name = DRIVER_NAME,
+ .dev_name = DEV_NAME,
+ .nr = ARRAY_SIZE(efm32_usart_ports),
+ .cons = &efm32_usart_console,
+};
+
+static int efm32_usart_probe_dt(struct platform_device *pdev,
+ struct efm32_usart_port *efm_port)
+{
+ struct device_node *np = pdev->dev.of_node;
+ int ret;
+
+ if (!np)
+ return 1;
+
+ ret = of_alias_get_id(np, "serial");
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to get alias id: %d\n", ret);
+ return ret;
+ } else {
+ efm_port->port.line = ret;
+ return 0;
+ }
+
+}
+
+static int __devinit efm32_usart_probe(struct platform_device *pdev)
+{
+ struct efm32_usart_port *efm_port;
+ struct resource *res;
+ int ret;
+
+ efm_port = kzalloc(sizeof(*efm_port), GFP_KERNEL);
+ if (!efm_port) {
+ dev_dbg(&pdev->dev, "failed to allocate private data\n");
+ return -ENOMEM;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ ret = -ENODEV;
+ dev_dbg(&pdev->dev, "failed to determine base address\n");
+ goto err_get_base;
+ }
+
+ if (resource_size(res) < 60) {
+ ret = -EINVAL;
+ dev_dbg(&pdev->dev, "memory resource too small\n");
+ goto err_too_small;
+ }
+
+ ret = platform_get_irq(pdev, 0);
+ if (ret <= 0) {
+ dev_dbg(&pdev->dev, "failed to get rx irq\n");
+ goto err_get_rxirq;
+ }
+
+ efm_port->port.irq = ret;
+
+ ret = platform_get_irq(pdev, 1);
+ if (ret <= 0)
+ ret = efm_port->port.irq + 1;
+
+ efm_port->txirq = ret;
+
+ efm_port->port.dev = &pdev->dev;
+ efm_port->port.mapbase = res->start;
+ efm_port->port.type = PORT_EFMUSART;
+ efm_port->port.iotype = UPIO_MEM32;
+ efm_port->port.fifosize = 2;
+ efm_port->port.ops = &efm32_usart_pops;
+ efm_port->port.flags = UPF_BOOT_AUTOCONF;
+
+ ret = efm32_usart_probe_dt(pdev, efm_port);
+ if (ret > 0)
+ /* not created by device tree */
+ efm_port->port.line = pdev->id;
+
+ if (efm_port->port.line >= 0 &&
+ efm_port->port.line < ARRAY_SIZE(efm32_usart_ports))
+ efm32_usart_ports[efm_port->port.line] = efm_port;
+
+ ret = uart_add_one_port(&efm32_usart_reg, &efm_port->port);
+ if (ret) {
+ dev_dbg(&pdev->dev, "failed to add port: %d\n", ret);
+
+ if (pdev->id >= 0 && pdev->id < ARRAY_SIZE(efm32_usart_ports))
+ efm32_usart_ports[pdev->id] = NULL;
+err_get_rxirq:
+err_too_small:
+err_get_base:
+ kfree(efm_port);
+ } else {
+ platform_set_drvdata(pdev, efm_port);
+ dev_dbg(&pdev->dev, "\\o/\n");
+ }
+
+ return ret;
+}
+
+static int __devexit efm32_usart_remove(struct platform_device *pdev)
+{
+ struct efm32_usart_port *efm_port = platform_get_drvdata(pdev);
+
+ platform_set_drvdata(pdev, NULL);
+
+ uart_remove_one_port(&efm32_usart_reg, &efm_port->port);
+
+ if (pdev->id >= 0 && pdev->id < ARRAY_SIZE(efm32_usart_ports))
+ efm32_usart_ports[pdev->id] = NULL;
+
+ kfree(efm_port);
+
+ return 0;
+}
+
+static struct of_device_id efm32_usart_dt_ids[] = {
+ {
+ .compatible = "efm32,usart",
+ }, {
+ /* sentinel */
+ }
+};
+MODULE_DEVICE_TABLE(of, efm32_usart_dt_ids);
+
+static struct platform_driver efm32_usart_driver = {
+ .probe = efm32_usart_probe,
+ .remove = __devexit_p(efm32_usart_remove),
+
+ .driver = {
+ .name = DRIVER_NAME,
+ .owner = THIS_MODULE,
+ .of_match_table = efm32_usart_dt_ids,
+ },
+};
+
+static int __init efm32_usart_init(void)
+{
+ int ret;
+
+ ret = uart_register_driver(&efm32_usart_reg);
+ if (ret)
+ return ret;
+
+ ret = platform_driver_register(&efm32_usart_driver);
+ if (ret)
+ uart_unregister_driver(&efm32_usart_reg);
+
+ pr_info("EFM32 USART driver\n");
+
+ return ret;
+}
+module_init(efm32_usart_init);
+
+static void __exit efm32_usart_exit(void)
+{
+ platform_driver_unregister(&efm32_usart_driver);
+ uart_unregister_driver(&efm32_usart_reg);
+}
+
+MODULE_AUTHOR("Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>");
+MODULE_DESCRIPTION("EFM32 USART driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:" DRIVER_NAME);
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index eadf33d..eb45d4d 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -207,6 +207,8 @@
/* Xilinx PSS UART */
#define PORT_XUARTPS 98
+#define PORT_EFMUSART 99
+
#ifdef __KERNEL__
#include <linux/compiler.h>
--
1.7.7.3
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply related
* Re: [GIT PULL] ARM: amba: Enable module alias autogeneration for AMBA drivers
From: Russell King - ARM Linux @ 2011-12-22 18:50 UTC (permalink / raw)
To: Dave Martin
Cc: Alessandro Rubini, patches, linux-kernel, linux-arm-kernel, alan,
a.zummo, alsa-devel, cjb, dan.j.williams, dmitry.torokhov,
grant.likely, perex, jassisinghbrar, julia, linus.walleij,
linux-fbdev, linux-input, linux-mmc, linux-serial, linux-watchdog,
lethal, Pawel.Moll, rtc-linux, spi-devel-general, tiwai,
vinod.koul, wim
In-Reply-To: <20111222112125.GA2573@localhost>
On Thu, Dec 22, 2011 at 11:21:25AM +0000, Dave Martin wrote:
> On Mon, Dec 19, 2011 at 09:39:42PM +0000, Russell King - ARM Linux wrote:
> > I have pulled it, I just haven't merged it in anywhere yet.
>
> OK, great -- thanks.
>
> I wasn't too familiar with the procedure, so I just wanted
> to be sure that I hadn't done things wrong.
FYI, I'll be pushing out an update to my tree Friday evening.
^ permalink raw reply
* Re: [PATCH] serial/efm32: add new driver
From: Arnd Bergmann @ 2011-12-23 10:35 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-kernel, Alan Cox, devicetree-discuss, Greg Kroah-Hartman,
kernel, linux-serial
In-Reply-To: <1324561092-1945-1-git-send-email-u.kleine-koenig@pengutronix.de>
On Thursday 22 December 2011, Uwe Kleine-König wrote:
> @@ -0,0 +1,14 @@
> +* Energymicro efm32 UART
> +
> +Required properties:
> +- compatible : Should be "efm32,usart"
> +- reg : Address and length of the register set
> +- interrupts : Should contain uart interrupt
> +
> +Example:
> +
> +uart@0x4000c400 {
> + compatible = "efm32,usart";
> + reg = <0x4000c400 0x400>;
> + interrupts = <15>;
> +};
Do you know if the usart was actually designed by energymicro or licensed
from another party? If it is a licensed part, it would be better to
list the "compatible" value under the company name that made it.
I would suggest that you also support the "clock-frequency" and/or
"current-speed" properties that are defined for serial ports, see the
of_serial driver.
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 925a1e5..cfeb0f3 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1610,4 +1610,14 @@ config SERIAL_XILINX_PS_UART_CONSOLE
> help
> Enable a Xilinx PS UART port to be the system console.
>
> +config SERIAL_EFM32_USART
> + bool "EFM32 USART port."
> + depends on ARCH_EFM32
> + select SERIAL_CORE
Why not tristate? If it's not a console, you should be able to use
it as a module.
I would generally prefer not to make the driver depend on the
platform, so we can get better compile time coverage. I think a better
set of dependencies would be
depends on HAVE_CLK
depends on OF
default ARCH_EFM32
> +static void efm32_usart_write32(struct efm32_usart_port *efm_port,
> + u32 value, unsigned offset)
> +{
> + __raw_writel(value, efm_port->port.membase + offset);
> +}
> +
> +static u32 efm32_usart_read32(struct efm32_usart_port *efm_port,
> + unsigned offset)
> +{
> + return __raw_readl(efm_port->port.membase + offset);
> +}
Please use writel_relaxed() instead of __raw_writel().
> +static int __devinit efm32_usart_probe(struct platform_device *pdev)
> +{
> + struct efm32_usart_port *efm_port;
> + struct resource *res;
> + int ret;
> +
> + efm_port = kzalloc(sizeof(*efm_port), GFP_KERNEL);
> + if (!efm_port) {
> + dev_dbg(&pdev->dev, "failed to allocate private data\n");
> + return -ENOMEM;
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + ret = -ENODEV;
> + dev_dbg(&pdev->dev, "failed to determine base address\n");
> + goto err_get_base;
> + }
> +
> + if (resource_size(res) < 60) {
> + ret = -EINVAL;
> + dev_dbg(&pdev->dev, "memory resource too small\n");
> + goto err_too_small;
> + }
of_iomap() would be simpler here. I think you can leave out the assignment to
mapbase, and go straight to membase here.
checking the resource size should not be necessary, because that would imply
having an invalid device tree, which you don't have to check at run time.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Western Union End Of Year Customers Promotion
From: Western® Union Money Transfer @ 2011-12-23 10:07 UTC (permalink / raw)
Welcome To Western® Union Office
Website: www.westernunion.com
Dear Western Union value customer,
We happilly announce to you that you have been awarded with the sum
of $50,000 USD by our office, as one of our customers who uses
Western Union in their daily business transaction this year.
This award has been selected through the internet, where your e-mail
address was indicated and notified.Please provide Mr. Ernest Ihioria
with the following details 1. Name:______2. Address:______3. Country:_______
4. Phone Number:____
Mr. Ernest Ihioria.
TEL: +234 807 165 9227
E-Mail: western_uinon@w.cn
As soon as these details are received and verified,
your fund will be remmitted to you. Thank you for using western union.
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] serial/efm32: add new driver
From: Uwe Kleine-König @ 2011-12-23 20:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, Alan Cox, devicetree-discuss, Greg Kroah-Hartman,
kernel, linux-serial
In-Reply-To: <201112231035.23215.arnd@arndb.de>
Hello Arnd,
On Fri, Dec 23, 2011 at 10:35:22AM +0000, Arnd Bergmann wrote:
> On Thursday 22 December 2011, Uwe Kleine-König wrote:
>
> > @@ -0,0 +1,14 @@
> > +* Energymicro efm32 UART
> > +
> > +Required properties:
> > +- compatible : Should be "efm32,usart"
> > +- reg : Address and length of the register set
> > +- interrupts : Should contain uart interrupt
> > +
> > +Example:
> > +
> > +uart@0x4000c400 {
> > + compatible = "efm32,usart";
> > + reg = <0x4000c400 0x400>;
> > + interrupts = <15>;
> > +};
>
> Do you know if the usart was actually designed by energymicro or licensed
> from another party? If it is a licensed part, it would be better to
> list the "compatible" value under the company name that made it.
I don't know so I passed the question to them.
> I would suggest that you also support the "clock-frequency" and/or
> "current-speed" properties that are defined for serial ports, see the
> of_serial driver.
I will have a look to find out what they mean and update the patch
accordingly.
> > diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> > index 925a1e5..cfeb0f3 100644
> > --- a/drivers/tty/serial/Kconfig
> > +++ b/drivers/tty/serial/Kconfig
> > @@ -1610,4 +1610,14 @@ config SERIAL_XILINX_PS_UART_CONSOLE
> > help
> > Enable a Xilinx PS UART port to be the system console.
> >
> > +config SERIAL_EFM32_USART
> > + bool "EFM32 USART port."
> > + depends on ARCH_EFM32
> > + select SERIAL_CORE
>
> Why not tristate? If it's not a console, you should be able to use
> it as a module.
Hmm, in theory yes. (In practice modules on mmu are not that trivial,
see the corresponding thread on lakml.) I will update but I guess I can
only build test that configuration.
> I would generally prefer not to make the driver depend on the
> platform, so we can get better compile time coverage. I think a better
> set of dependencies would be
>
> depends on HAVE_CLK
> depends on OF
> default ARCH_EFM32
I'd prefer something like:
depends on HAVE_CLK
depends on ARCH_EFM32 || I_DO_BUILD_COVERAGE_TESTING
This would make it easier for Joe User to pick the right options for his
kernel (assuming he found out to better keep I_DO_BUILD_COVERAGE_TESTING
disabled). There is no hard dependency on OF in the driver and I guess
at least the in-production (and out-of-tree) usage will still stick to
non-OF because it saves some RAM. So I'd prefer not to add that.
(And it would help build coverage testing ;-)
> > +static void efm32_usart_write32(struct efm32_usart_port *efm_port,
> > + u32 value, unsigned offset)
> > +{
> > + __raw_writel(value, efm_port->port.membase + offset);
> > +}
> > +
> > +static u32 efm32_usart_read32(struct efm32_usart_port *efm_port,
> > + unsigned offset)
> > +{
> > + return __raw_readl(efm_port->port.membase + offset);
> > +}
>
> Please use writel_relaxed() instead of __raw_writel().
ok
> > +static int __devinit efm32_usart_probe(struct platform_device *pdev)
> > +{
> > + struct efm32_usart_port *efm_port;
> > + struct resource *res;
> > + int ret;
> > +
> > + efm_port = kzalloc(sizeof(*efm_port), GFP_KERNEL);
> > + if (!efm_port) {
> > + dev_dbg(&pdev->dev, "failed to allocate private data\n");
> > + return -ENOMEM;
> > + }
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + if (!res) {
> > + ret = -ENODEV;
> > + dev_dbg(&pdev->dev, "failed to determine base address\n");
> > + goto err_get_base;
> > + }
> > +
> > + if (resource_size(res) < 60) {
> > + ret = -EINVAL;
> > + dev_dbg(&pdev->dev, "memory resource too small\n");
> > + goto err_too_small;
> > + }
>
> of_iomap() would be simpler here. I think you can leave out the assignment to
> mapbase, and go straight to membase here.
but ioremap is only done in .request_port, so it's necessary to have two
steps here, isn't it?
> checking the resource size should not be necessary, because that would imply
> having an invalid device tree, which you don't have to check at run time.
hmm, I prefer an error message over an access to unmapped memory even if
that can only happen when the device tree is broken.
Best regards and thanks for your comments,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH v5] tty: serial: imx: Allow UART to be a source for wakeup
From: Shawn Guo @ 2011-12-26 1:53 UTC (permalink / raw)
To: Fabio Estevam
Cc: linux-arm-kernel, kernel, alan, linux-serial, Fabio Estevam,
Greg Kroah-Hartman
In-Reply-To: <1323746628-25163-1-git-send-email-festevam@gmail.com>
On Tue, Dec 13, 2011 at 01:23:48AM -0200, Fabio Estevam wrote:
> Allow UART to be a source for wakeup from low power mode.
>
> Tested on a MX27PDK by doing:
>
> echo enabled > /sys/devices/platform/imx21-uart.0/tty/ttymxc0/power/wakeup
>
> echo mem > /sys/power/state
>
> and then pressing a key in the console will wakeup the sytem.
>
> Suggested-by: Shawn Guo <shawn.guo@freescale.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
I queued this for 3.3, and will send a pull-request to Greg.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH 1/2 v2] imx: Add save/restore functions for UART control regs
From: Shawn Guo @ 2011-12-26 1:58 UTC (permalink / raw)
To: Dirk Behme
Cc: linux-arm-kernel, Sascha Hauer, Dirk Behme, linux-serial,
Uwe Kleine-Koenig, Fabio Estevam, Saleem Abdulrasool, Alan Cox,
Greg Kroah-Hartman
In-Reply-To: <1324544273-9820-1-git-send-email-dirk.behme@gmail.com>
On Thu, Dec 22, 2011 at 09:57:52AM +0100, Dirk Behme wrote:
> Factor out the uart save/restore functionality instead of
> having the same code several times in the driver.
>
> Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
> CC: Saleem Abdulrasool <compnerd@compnerd.org>
> CC: Sascha Hauer <s.hauer@pengutronix.de>
> CC: Fabio Estevam <festevam@gmail.com>
> CC: Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>
> CC: linux-serial@vger.kernel.org
> CC: Alan Cox <alan@linux.intel.com>
I queued this for 3.3, and will send a pull-request to Greg.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH 2/2 v3] imx: add polled io uart methods
From: Shawn Guo @ 2011-12-26 1:59 UTC (permalink / raw)
To: Dirk Behme
Cc: linux-arm-kernel, Sascha Hauer, Dirk Behme, linux-serial,
Uwe Kleine-Koenig, Fabio Estevam, Saleem Abdulrasool, Alan Cox,
Greg Kroah-Hartman
In-Reply-To: <1324544273-9820-2-git-send-email-dirk.behme@gmail.com>
On Thu, Dec 22, 2011 at 09:57:53AM +0100, Dirk Behme wrote:
> From: Saleem Abdulrasool <compnerd@compnerd.org>
>
> These methods are invoked if the iMX uart is used in conjuction with kgdb during
> early boot. In order to access the UART without the interrupts, the kernel uses
> the basic polling methods for IO with the device. With these methods
> implemented, it is now possible to enable kgdb during early boot over serial.
>
> Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
> Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
> CC: Sascha Hauer <s.hauer@pengutronix.de>
> CC: Fabio Estevam <festevam@gmail.com>
> CC: Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>
> CC: linux-serial@vger.kernel.org
> CC: Alan Cox <alan@linux.intel.com>
I queued this for 3.3, and will send a pull-request to Greg.
--
Regards,
Shawn
^ permalink raw reply
* question about lqasc_release_port in drivers/tty/serial/lantiq.c
From: Julia Lawall @ 2011-12-26 17:42 UTC (permalink / raw)
To: alan, linux-serial, linux-kernel
The function lqasc_release_port in the file drivers/tty/serial/lantiq.c is
defined as follows:
static void
lqasc_release_port(struct uart_port *port)
{
if (port->flags & UPF_IOREMAP) {
iounmap(port->membase);
port->membase = NULL;
}
}
But port->membase is initialized using devm_ioremap_nocache, implying that
it should be freed with devm_ioremap. devm_ioremap, however, requires an
additional &pdev->dev argument. Maybe the call to iounmap is not needed
at all?
julia
^ permalink raw reply
* serial: add support for 400 and 800 v3 series Titan cards
From: Yegor Yefremov @ 2011-12-27 14:47 UTC (permalink / raw)
To: linux-serial; +Cc: gregkh
add support for 400Hv3, 410Hv3 and 800Hv3
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
---
drivers/tty/serial/8250_pci.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
Index: b/drivers/tty/serial/8250_pci.c
===================================================================
--- a/drivers/tty/serial/8250_pci.c
+++ b/drivers/tty/serial/8250_pci.c
@@ -1152,6 +1152,10 @@
#define PCI_DEVICE_ID_TITAN_800E 0xA014
#define PCI_DEVICE_ID_TITAN_200EI 0xA016
#define PCI_DEVICE_ID_TITAN_200EISI 0xA017
+#define PCI_DEVICE_ID_TITAN_400V3 0xA310
+#define PCI_DEVICE_ID_TITAN_410V3 0xA312
+#define PCI_DEVICE_ID_TITAN_800V3 0xA314
+#define PCI_DEVICE_ID_TITAN_800V3B 0xA315
#define PCI_DEVICE_ID_OXSEMI_16PCI958 0x9538
#define PCIE_DEVICE_ID_NEO_2_OX_IBM 0x00F6
#define PCI_DEVICE_ID_PLX_CRONYX_OMEGA 0xc001
@@ -3443,6 +3447,18 @@
{ PCI_VENDOR_ID_TITAN, PCI_DEVICE_ID_TITAN_200EISI,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
pbn_oxsemi_2_4000000 },
+ { PCI_VENDOR_ID_TITAN, PCI_DEVICE_ID_TITAN_400V3,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ pbn_b0_4_921600 },
+ { PCI_VENDOR_ID_TITAN, PCI_DEVICE_ID_TITAN_410V3,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ pbn_b0_4_921600 },
+ { PCI_VENDOR_ID_TITAN, PCI_DEVICE_ID_TITAN_800V3,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ pbn_b0_4_921600 },
+ { PCI_VENDOR_ID_TITAN, PCI_DEVICE_ID_TITAN_800V3B,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ pbn_b0_4_921600 },
{ PCI_VENDOR_ID_SIIG, PCI_DEVICE_ID_SIIG_1S_10x_550,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
^ permalink raw reply
* [GIT PULL] tty: serial: imx changes for 3.3
From: Shawn Guo @ 2012-01-01 1:04 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Alan Cox, Sascha Hauer, linux-arm-kernel, linux-serial
Hi Greg,
I collected a few imx tty/serial changes below for 3.3. Can you please
take a look and consider to pull the branch for 3.3 if it looks all
good to you?
Regards,
Shawn
The following changes since commit 5f0a6e2d503896062f641639dacfe5055c2f593b:
Linux 3.2-rc7 (2011-12-23 21:51:06 -0800)
are available in the git repository at:
git://git.linaro.org/people/shawnguo/linux-2.6.git imx/serial
Dirk Behme (1):
imx: Add save/restore functions for UART control regs
Eric Miao (1):
tty: serial: imx: move del_timer_sync() to avoid potential deadlock
Fabio Estevam (1):
tty: serial: imx: Allow UART to be a source for wakeup
Saleem Abdulrasool (1):
imx: add polled io uart methods
Uwe Kleine-König (2):
serial/imx: propagate error from of_alias_get_id instead of using -ENODEV
serial/imx: let probing fail for the dt case without a valid alias
drivers/tty/serial/imx.c | 146 +++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 132 insertions(+), 14 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v8 19/20] OMAP2+: UART: Do not gate uart clocks if used for debug_prints
From: Bedia, Vaibhav @ 2012-01-02 9:25 UTC (permalink / raw)
To: R, Govindraj, linux-omap@vger.kernel.org
Cc: Hilman, Kevin, Tony Lindgren, Nayak, Rajendra, Basak, Partha,
Shilimkar, Santosh, linux-serial@vger.kernel.org,
Sripathy, Vishwanath, linux-arm-kernel@lists.infradead.org
In-Reply-To: <1321005712-21871-5-git-send-email-govindraj.raja@ti.com>
Hello,
On Fri, Nov 11, 2011 at 15:31:52, R, Govindraj wrote:
[...]
>
> - if ((cpu_is_omap34xx() || cpu_is_omap44xx()) && bdata->pads)
> + if (((cpu_is_omap34xx() || cpu_is_omap44xx()) && bdata->pads)
> + && !uart_debug)
> device_init_wakeup(&pdev->dev, true);
> }
I was testing this on AM335x and realized that this leads to creation of two
'wakeup' entries for UART. One is created by the tty layer in serial-core.c
and the other is created here.
Here's what I see on a branch based on Tony's 3.2-rc6:
./sys/devices/platform/omap/omap_uart.0/power/wakeup
./sys/devices/platform/omap/omap_uart.0/tty/ttyO0/power/wakeup
Shouldn't the OMAP serial just enable the 'wakeup' entry created by serial-core.c?
Regards,
Vaibhav
^ permalink raw reply
* Re: [PATCH v8 19/20] OMAP2+: UART: Do not gate uart clocks if used for debug_prints
From: Govindraj @ 2012-01-02 10:30 UTC (permalink / raw)
To: Bedia, Vaibhav
Cc: R, Govindraj, linux-omap@vger.kernel.org, Hilman, Kevin,
Tony Lindgren, Nayak, Rajendra, Basak, Partha, Shilimkar, Santosh,
linux-serial@vger.kernel.org, Sripathy, Vishwanath,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <B5906170F1614E41A8A28DE3B8D1214304B3E2@DBDE01.ent.ti.com>
Hi Vaibhav,
On Mon, Jan 2, 2012 at 2:55 PM, Bedia, Vaibhav <vaibhav.bedia@ti.com> wrote:
> Hello,
>
> On Fri, Nov 11, 2011 at 15:31:52, R, Govindraj wrote:
> [...]
>>
>> - if ((cpu_is_omap34xx() || cpu_is_omap44xx()) && bdata->pads)
>> + if (((cpu_is_omap34xx() || cpu_is_omap44xx()) && bdata->pads)
>> + && !uart_debug)
>> device_init_wakeup(&pdev->dev, true);
>> }
>
> I was testing this on AM335x and realized that this leads to creation of two
> 'wakeup' entries for UART. One is created by the tty layer in serial-core.c
> and the other is created here.
>
> Here's what I see on a branch based on Tony's 3.2-rc6:
>
> ./sys/devices/platform/omap/omap_uart.0/power/wakeup
> ./sys/devices/platform/omap/omap_uart.0/tty/ttyO0/power/wakeup
>
> Shouldn't the OMAP serial just enable the 'wakeup' entry created by serial-core.c?
currently runtime pm is available from omap-serial device and not from tty_dev.
Setting tty_dev wakeup is to use irq_wakeup from suspend available
from serail_core layer which I think we are not using for omap-uart
and we use pad wakeup from suspend path.
Also omap-uart.x/power/wakeup is used to gate uart clocks using runtime
PM api's in omap-serial driver.
--
Thanks,
Govindraj.R
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v8 19/20] OMAP2+: UART: Do not gate uart clocks if used for debug_prints
From: Bedia, Vaibhav @ 2012-01-03 10:24 UTC (permalink / raw)
To: Govindraj
Cc: R, Govindraj, linux-omap@vger.kernel.org, Hilman, Kevin,
Tony Lindgren, Nayak, Rajendra, Basak, Partha, Shilimkar, Santosh,
linux-serial@vger.kernel.org, Sripathy, Vishwanath,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAAL8m4yXD-gpeXNVsCOYeDkYDWmVX8FUcpXKjx6k=AXSF4V9iA@mail.gmail.com>
Hi Govindraj,
On Mon, Jan 02, 2012 at 16:00:37, Govindraj wrote:
>
> currently runtime pm is available from omap-serial device and not from tty_dev.
> Setting tty_dev wakeup is to use irq_wakeup from suspend available
> from serail_core layer which I think we are not using for omap-uart
> and we use pad wakeup from suspend path.
>
> Also omap-uart.x/power/wakeup is used to gate uart clocks using runtime
> PM api's in omap-serial driver.
>
Thanks for clarifying. On AM335x, one of the UARTs is in a wakeup domain
and swakeup from this is used to come out of suspend.
I have basic suspend-resume working on it. Strangely this works irrespective
of the value of tty_dev wakeup entry. Do you know if this is expected on OMAP?
The other issue concerning runtime PM is that as soon as I set a non-zero to
the autosuspend_delay_ms I get some garbage characters and eventually the
console stops responding.
[root@arago /]# cat .../omap_uart.0/power/autosuspend_delay_ms
-1
[root@arago /]# echo 3000 > ÖKWëé«+×é«+wU.Éѹ,z,½Ý.ɽosuspend_delayÕ£½ÍÕÍ...
[root@arago /]# <- No response after some time
The comment in the code mentions delay is receiving characters if runtime PM
is enabled. Any idea what's going wrong at my end?
Regards,
Vaibhav B.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v8 19/20] OMAP2+: UART: Do not gate uart clocks if used for debug_prints
From: Govindraj @ 2012-01-03 10:31 UTC (permalink / raw)
To: Bedia, Vaibhav
Cc: R, Govindraj, linux-omap@vger.kernel.org, Hilman, Kevin,
Tony Lindgren, Nayak, Rajendra, Basak, Partha, Shilimkar, Santosh,
linux-serial@vger.kernel.org, Sripathy, Vishwanath,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <B5906170F1614E41A8A28DE3B8D1214304BAD3@DBDE01.ent.ti.com>
On Tue, Jan 3, 2012 at 3:54 PM, Bedia, Vaibhav <vaibhav.bedia@ti.com> wrote:
> Hi Govindraj,
>
> On Mon, Jan 02, 2012 at 16:00:37, Govindraj wrote:
>>
>> currently runtime pm is available from omap-serial device and not from tty_dev.
>> Setting tty_dev wakeup is to use irq_wakeup from suspend available
>> from serail_core layer which I think we are not using for omap-uart
>> and we use pad wakeup from suspend path.
>>
>> Also omap-uart.x/power/wakeup is used to gate uart clocks using runtime
>> PM api's in omap-serial driver.
>>
>
> Thanks for clarifying. On AM335x, one of the UARTs is in a wakeup domain
> and swakeup from this is used to come out of suspend.
>
> I have basic suspend-resume working on it. Strangely this works irrespective
> of the value of tty_dev wakeup entry. Do you know if this is expected on OMAP?
>
AFAIK yes.
> The other issue concerning runtime PM is that as soon as I set a non-zero to
> the autosuspend_delay_ms I get some garbage characters and eventually the
> console stops responding.
>
> [root@arago /]# cat .../omap_uart.0/power/autosuspend_delay_ms
> -1
> [root@arago /]# echo 3000 > ÖKWëé«+×é«+wU.Éѹ,z,½Ý.ɽosuspend_delayÕ£½ÍÕÍ...
> [root@arago /]# <- No response after some time
>
try enabling CONFIG_CPU_IDLE for pm qos_usage from uart driver.
--
Thanks,
Govindraj.R
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v8 19/20] OMAP2+: UART: Do not gate uart clocks if used for debug_prints
From: Bedia, Vaibhav @ 2012-01-03 11:52 UTC (permalink / raw)
To: Govindraj
Cc: R, Govindraj, linux-omap@vger.kernel.org, Hilman, Kevin,
Tony Lindgren, Nayak, Rajendra, Basak, Partha, Shilimkar, Santosh,
linux-serial@vger.kernel.org, Sripathy, Vishwanath,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAAL8m4yhtUNjoKwECnQEYNoaL-M+RaHXACanAeJW64DPsJ_hWg@mail.gmail.com>
On Tue, Jan 03, 2012 at 16:01:52, Govindraj wrote:
> >
> > I have basic suspend-resume working on it. Strangely this works irrespective
> > of the value of tty_dev wakeup entry. Do you know if this is expected on OMAP?
> >
>
> AFAIK yes.
Ok.
>
> > The other issue concerning runtime PM is that as soon as I set a non-zero to
> > the autosuspend_delay_ms I get some garbage characters and eventually the
> > console stops responding.
> >
> > [root@arago /]# cat .../omap_uart.0/power/autosuspend_delay_ms
> > -1
> > [root@arago /]# echo 3000 > ÖKWëé«+×é«+wU.Éѹ,z,½Ý.ɽosuspend_delayÕ£½ÍÕÍ...
> > [root@arago /]# <- No response after some time
> >
>
> try enabling CONFIG_CPU_IDLE for pm qos_usage from uart driver.
>
Its enabled.
Regards,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v8 19/20] OMAP2+: UART: Do not gate uart clocks if used for debug_prints
From: Govindraj @ 2012-01-03 14:12 UTC (permalink / raw)
To: Bedia, Vaibhav
Cc: R, Govindraj, linux-omap@vger.kernel.org, Hilman, Kevin,
Tony Lindgren, Nayak, Rajendra, Basak, Partha, Shilimkar, Santosh,
linux-serial@vger.kernel.org, Sripathy, Vishwanath,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <B5906170F1614E41A8A28DE3B8D1214304BB42@DBDE01.ent.ti.com>
On Tue, Jan 3, 2012 at 5:22 PM, Bedia, Vaibhav <vaibhav.bedia@ti.com> wrote:
> On Tue, Jan 03, 2012 at 16:01:52, Govindraj wrote:
>> >
>> > I have basic suspend-resume working on it. Strangely this works irrespective
>> > of the value of tty_dev wakeup entry. Do you know if this is expected on OMAP?
>> >
>>
>> AFAIK yes.
>
> Ok.
>
>>
>> > The other issue concerning runtime PM is that as soon as I set a non-zero to
>> > the autosuspend_delay_ms I get some garbage characters and eventually the
>> > console stops responding.
>> >
>> > [root@arago /]# cat .../omap_uart.0/power/autosuspend_delay_ms
>> > -1
>> > [root@arago /]# echo 3000 > ÖKWëé«+×é«+wU.Éѹ,z,½Ý.ɽosuspend_delayÕ£½ÍÕÍ...
>> > [root@arago /]# <- No response after some time
>> >
>>
>> try enabling CONFIG_CPU_IDLE for pm qos_usage from uart driver.
>>
>
> Its enabled.
I checked on Beagle-xm with latest LO master I don't see that issue.
Lo master commit used
commit: 6489f6de3a219dfd23a91261eea1b09fba7ae128
Logs:
http://pastebin.pandaboard.org/index.php/view/55509914
--
Thanks,
Govindraj.R
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: USB disconnect -> kernel panic
From: Greg KH @ 2012-01-03 23:58 UTC (permalink / raw)
To: Sarah Sharp, Oliver Neukum
Cc: Bdale Garbee, keithp-aN4HjG94KOLQT0dZR+AlfA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120102182255.GC8562@xanatos>
On Mon, Jan 02, 2012 at 10:22:55AM -0800, Sarah Sharp wrote:
> On Sat, Dec 24, 2011 at 03:32:26PM -0700, Bdale Garbee wrote:
> > Hi Sarah! Merry Christmas!
> >
> > I've been working on another production run of Altus Metrum products
> > today, and in the process of flashing and calibrating a pile of our
> > TeleDongle units, I've been seeing sporadic kernel panics when
> > unplugging them from my notebook USB. Has now happened three times this
> > morning.
> >
> > I'm running 3.1.6 now, but I saw this under 3.1.5 too, at least once.
> > The notebook is an HP 2540p.
> >
> > Keith suggested I send you the attached photo of my screen showing the
> > panic info.
>
> It's somewhere in the tty layer, and doesn't look USB related. I think
> Greg KH is the tty maintainer right now, so you might want to ask him.
We've had some cdc_acm driver problems in the past, but I thought they
were all resolved. 3.1.3 should have fixed those problems. We have
some more cleanups queued up for 3.3, but nothing that should be fixing
something like this.
Oliver, any thoughts about this (see the original post on linux-usb for
the crash dump.)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: USB disconnect -> kernel panic
From: Bdale Garbee @ 2012-01-04 3:09 UTC (permalink / raw)
To: Greg KH, Sarah Sharp, Oliver Neukum
Cc: keithp-aN4HjG94KOLQT0dZR+AlfA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120103235847.GF21311-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1500 bytes --]
On Tue, 3 Jan 2012 15:58:47 -0800, Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> wrote:
> On Mon, Jan 02, 2012 at 10:22:55AM -0800, Sarah Sharp wrote:
> > On Sat, Dec 24, 2011 at 03:32:26PM -0700, Bdale Garbee wrote:
> > > Hi Sarah! Merry Christmas!
> > >
> > > I've been working on another production run of Altus Metrum products
> > > today, and in the process of flashing and calibrating a pile of our
> > > TeleDongle units, I've been seeing sporadic kernel panics when
> > > unplugging them from my notebook USB. Has now happened three times this
> > > morning.
> > >
> > > I'm running 3.1.6 now, but I saw this under 3.1.5 too, at least once.
> > > The notebook is an HP 2540p.
> > >
> > > Keith suggested I send you the attached photo of my screen showing the
> > > panic info.
> >
> > It's somewhere in the tty layer, and doesn't look USB related. I think
> > Greg KH is the tty maintainer right now, so you might want to ask him.
>
> We've had some cdc_acm driver problems in the past, but I thought they
> were all resolved. 3.1.3 should have fixed those problems. We have
> some more cleanups queued up for 3.3, but nothing that should be fixing
> something like this.
>
> Oliver, any thoughts about this (see the original post on linux-usb for
> the crash dump.)
For what it's worth, it happened to me again today running 3.2.0-rc7. I
didn't bother photographing the screen again, though I'm happy to do
that if it'll help.
Bdale
[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: USB disconnect -> kernel panic
From: Oliver Neukum @ 2012-01-04 9:01 UTC (permalink / raw)
To: Greg KH
Cc: Sarah Sharp, Oliver Neukum, Bdale Garbee,
keithp-aN4HjG94KOLQT0dZR+AlfA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120103235847.GF21311-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
Am Mittwoch, 4. Januar 2012, 00:58:47 schrieb Greg KH:
> On Mon, Jan 02, 2012 at 10:22:55AM -0800, Sarah Sharp wrote:
> > On Sat, Dec 24, 2011 at 03:32:26PM -0700, Bdale Garbee wrote:
> > > Hi Sarah! Merry Christmas!
> > >
> > > I've been working on another production run of Altus Metrum products
> > > today, and in the process of flashing and calibrating a pile of our
> > > TeleDongle units, I've been seeing sporadic kernel panics when
> > > unplugging them from my notebook USB. Has now happened three times this
> > > morning.
> > >
> > > I'm running 3.1.6 now, but I saw this under 3.1.5 too, at least once.
> > > The notebook is an HP 2540p.
> > >
> > > Keith suggested I send you the attached photo of my screen showing the
> > > panic info.
> >
> > It's somewhere in the tty layer, and doesn't look USB related. I think
> > Greg KH is the tty maintainer right now, so you might want to ask him.
>
> We've had some cdc_acm driver problems in the past, but I thought they
> were all resolved. 3.1.3 should have fixed those problems. We have
> some more cleanups queued up for 3.3, but nothing that should be fixing
> something like this.
>
> Oliver, any thoughts about this (see the original post on linux-usb for
> the crash dump.)
Do you have a pointer? I assumed this to be this issue:
http://www.spinics.net/lists/linux-usb/msg55779.html
And I am waiting for the announced patch.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: USB disconnect -> kernel panic
From: Keith Packard @ 2012-01-04 17:26 UTC (permalink / raw)
To: Oliver Neukum, Greg KH
Cc: Sarah Sharp, Oliver Neukum, Bdale Garbee, linux-usb, linux-serial
In-Reply-To: <201201041001.57080.oneukum@suse.de>
[-- Attachment #1: Type: text/plain, Size: 596 bytes --]
On Wed, 4 Jan 2012 10:01:57 +0100, Oliver Neukum <oneukum@suse.de> wrote:
> Do you have a pointer? I assumed this to be this issue:
> http://www.spinics.net/lists/linux-usb/msg55779.html
> And I am waiting for the announced patch.
The patch was posted to the list about half an hour after the Thilo's
first message:
From: Thilo-Alexander Ginkel <thilo@ginkel.com>
Subject: [PATCH 1/1] usb: cdc-acm: Fix acm_tty_hangup() vs. acm_tty_close() race
Date: Sat, 17 Dec 2011 10:55:10 +0100
Message-Id: <1324115710-14756-1-git-send-email-thilo@ginkel.com>
--
keith.packard@intel.com
[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox