Re: FW: [RFC][PATCH]: Adding support for omap-serail driver

2009-09-11 Thread Govindraj
Hi,


 FWIW, as the author of much of the PM hacker in mach-omap2/serial.c, I
 agree with Tao.

 The only reason for the PM hackery in mach-omap2/serial.c is because
 of the limitations of the 8250 driver.


I have an query,

We have following functionality in serial.c:
1.) Enabling and disabling uart clocks.
2.) Adding rx wakeup capabilities.
3.) Preparing UARTs for idle mode.
4.) Context save and restore.

What functionality should be retained in serial.c file?

AFAIK currently no serial driver has incorporated their platform
specific PM functionality like context_save and restore into their
serial driver, shouldn't these things be retained into
*/mach-omap2/serial.c ?

---
Regards,
Govindraj.R
--
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: FW: [RFC][PATCH]: Adding support for omap-serail driver

2009-09-11 Thread Kevin Hilman
Govindraj govindraj...@gmail.com writes:

 Hi,


 FWIW, as the author of much of the PM hacker in mach-omap2/serial.c, I
 agree with Tao.

 The only reason for the PM hackery in mach-omap2/serial.c is because
 of the limitations of the 8250 driver.


 I have an query,

 We have following functionality in serial.c:
 1.) Enabling and disabling uart clocks.
 2.) Adding rx wakeup capabilities.
 3.) Preparing UARTs for idle mode.
 4.) Context save and restore.

 What functionality should be retained in serial.c file?

 AFAIK currently no serial driver has incorporated their platform
 specific PM functionality like context_save and restore into their
 serial driver, shouldn't these things be retained into
 */mach-omap2/serial.c ?

Only SoC and/or board-specific settings should be done in serial.c
(setup of base addresses, IRQs, DMA channels, etc.)

The driver is an OMAP specific driver, but should be general enough to
independent of any board/SoC specifics.

IMO, all of 1-4 above above belong in the driver.  Evenutally the
enabling/disabling of clocks will be handled by the runtime PM layer,
but the driver will have a similar enable/disable API.

Kevin


--
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: FW: [RFC][PATCH]: Adding support for omap-serail driver

2009-09-10 Thread Kevin Hilman
HU TAO-TGHK48 ta...@motorola.com writes:

 Resend to linux-omap

 -Original Message-
 From: HU TAO-TGHK48 
 Sent: Monday, August 31, 2009 7:50 PM
 To: 'vimal singh'; linux-omap@vger.kernel.org; LKML;
 linux-ser...@vger.kernel.org
 Cc: Ye Yuan.Bo-A22116; Chen Xiaolong-A21785
 Subject: RE: [RFC][PATCH]: Adding support for omap-serail driver

  
 1. Shall we cleanup PM related stuff in arch/arm/mach-omap2/serial.c as
 well?
 Originally serail.c register UART IRQ  to decide if UART idle for a
 while and is able to enter low power mode (e.g. retention).
 To work with original 8250 driver, it is probably the only way since
 8250 is not aware of OMAP PM.

 However  it would be more reasonable to merge PM stuff to
 omap-serial.c. since the new driver is already OMAP specific
 
 2. There is an issue for DMA  with current implementation in serial.c 
 When Rx DMA is active NO Rx IRQ will be generated.
 So serial.c will easily set uart-can_sleep with 1 even there is
 Rx DMA ongoing
 + if ((iir  0x4)  up-use_dma) {
 + up-ier = ~UART_IER_RDI;
 + serial_out(up, UART_IER, up-ier

In my view, the best way is to do the idle detection in
 omap_serial.c.

FWIW, as the author of much of the PM hacker in mach-omap2/serial.c, I
agree with Tao.

The only reason for the PM hackery in mach-omap2/serial.c is because
of the limitations of the 8250 driver.

Kevin

--
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


FW: [RFC][PATCH]: Adding support for omap-serail driver

2009-08-31 Thread HU TAO-TGHK48

Resend to linux-omap

-Original Message-
From: HU TAO-TGHK48 
Sent: Monday, August 31, 2009 7:50 PM
To: 'vimal singh'; linux-omap@vger.kernel.org; LKML;
linux-ser...@vger.kernel.org
Cc: Ye Yuan.Bo-A22116; Chen Xiaolong-A21785
Subject: RE: [RFC][PATCH]: Adding support for omap-serail driver

 
1. Shall we cleanup PM related stuff in arch/arm/mach-omap2/serial.c as
well?
Originally serail.c register UART IRQ  to decide if UART idle for a
while and is able to enter low power mode (e.g. retention).
To work with original 8250 driver, it is probably the only way since
8250 is not aware of OMAP PM.
   
However  it would be more reasonable to merge PM stuff to
omap-serial.c. since the new driver is already OMAP specific

2. There is an issue for DMA  with current implementation in serial.c 
When Rx DMA is active NO Rx IRQ will be generated.
So serial.c will easily set uart-can_sleep with 1 even there is
Rx DMA ongoing
+   if ((iir  0x4)  up-use_dma) {
+   up-ier = ~UART_IER_RDI;
+   serial_out(up, UART_IER, up-ier

   In my view, the best way is to do the idle detection in
omap_serial.c.

3. Can a flag be added to enable auto-RTS and auto-CRT individually?
   OMAP HW supports independent auto-RTS and auto-CTS.
   And we had a case that only auto-RTS can be enabled due to HW design.

Below is the idea.

 In arch/arm/mach-omap2/serial.c
 static struct plat_serialomap_port serial_platform_data[] = {
   {
 .membase= IO_ADDRESS(OMAP_UART1_BASE),
 .irq= 72,
.regshift   = 2,
 +  .rtscts = UART_EFR_RTS


In omap_serial.c
+static int serial_omap_probe(struct platform_device *pdev) {
struct plat_serialomap_port *pdata = pdev-dev.platform_data; ... ...
+   up-rtscts =  pdata-rtscts;

   
serial_omap_set_termios(struct uart_port *port, struct ktermios
*termios,
struct ktermios *old)
{
... ...
if (termios-c_cflag  CRTSCTS)
+   efr |= up-rtscts;

   

Thanks

Tao Hu



-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of vimal singh
Sent: Friday, August 28, 2009 9:50 PM
To: linux-omap@vger.kernel.org; LKML; linux-ser...@vger.kernel.org
Subject: [RFC][PATCH]: Adding support for omap-serail driver

From: Govindraj R govindraj.r...@ti.com

This patch adds support for OMAP3430-HIGH SPEED UART Controller.

It currently adds support for the following features.

1. Supports Interrupt Mode for all three UARTs on SDP/ZOOM2.
2. Supports DMA Mode for all three UARTs on SDP/ZOOM2.
3. Supports Hardware flow control (CTS/RTS) on SDP/ZOOM2.
4. Supports 3.6Mbps baudrate on SDP/ZOOM2.
5. Debug Console support on all UARTs on SDP/ZOOM2.
6. Support for quad uart on ZOOM2 board.

The reason for adding this new driver alternative to 8250 is to avoid
polluting 8250 driver with too many omap specific data as 8250 already
supports more than 16 different uart controllers and may need too many
omap-platform checks to implement feature like DMA support.

Signed-off-by: Govindraj R govindraj.r...@ti.com
---
 arch/arm/plat-omap/include/mach/omap-serial.h |   84 +
 drivers/serial/Kconfig|   92 +
 drivers/serial/Makefile   |1
 drivers/serial/omap-serial.c  | 1431
++
 4 files changed, 1608 insertions(+)

diff --git a/arch/arm/plat-omap/include/mach/omap-serial.h
b/arch/arm/plat-omap/include/mach/omap-serial.h
new file mode 100644
index 000..d1b0bf2
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/omap-serial.h
@@ -0,0 +1,84 @@
+/*
+ * arch/arm/plat-omap/include/mach/omap-serial.h
+ *
+ * Driver for OMAP3430 UART controller.
+ *
+ * Copyright (C) 2009 Texas Instruments.
+ *
+ * Authors:
+ * Thara Gopinath  th...@ti.com
+ * Govindraj R govindraj.r...@ti.com
+ *
+ * This file is licensed under the terms of the GNU General Public 
+License
+ * version 2. This program is licensed as is without any warranty of 
+any
+ * kind, whether express or implied.
+ */
+
+#ifndef __OMAP_SERIAL_H__
+#define __OMAP_SERIAL_H__
+
+#include linux/serial_core.h
+#include linux/platform_device.h
+
+/* TI OMAP CONSOLE */
+#define PORT_OMAP   86
+
+#define DRIVER_NAMEomap-hsuart
+
+/*
+ * We default to IRQ0 for the no irq hack.   Some
+ * machine types want  others as well - they're free
+ * to redefine this in their header file.
+ */
+#define is_real_interrupt(irq)  ((irq) != 0)
+
+#if defined(CONFIG_SERIAL_OMAP_CONSOLE)  defined(CONFIG_MAGIC_SYSRQ) 
+#define SUPPORT_SYSRQ #endif
+
+#ifdef CONFIG_ARCH_OMAP34XX
+#define OMAP_MDR1_DISABLE  0x07
+#define OMAP_MDR1_MODE13X  0x03
+#define OMAP_MDR1_MODE16X  0x00
+#define OMAP_MODE13X_SPEED 230400
+#endif
+
+#define CONSOLE_NAME   console=
+
+#define UART_CLK   (4800)
+#define QUART_CLK