Linux Serial subsystem development
 help / color / mirror / Atom feed
* RE: tty/serial: Need clarification on Support for 4+M Baudrate
From: Rajanikanth H V @ 2012-01-12  9:49 UTC (permalink / raw)
  To: Alan Cox
  Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
	gregkh@sude.de, linux-arm-kernel@lists.infradead.org,
	Rajanikanth H V
In-Reply-To: <20120111123025.244a9cf5@pyramind.ukuu.org.uk>

Alan,

Thanks for your response, suggested modification helped to get 4.8M baud
but not 4.05M as this is being approximated to 4.0M baud which happens in
tty_termios_encode_baud_rate(...).

I have precise and weird requirement to get 4.05M baud as uart
baud clock divisor value changes between 4.0M and 4.05M Baud.

Any suggestion?

Thanks,
Rajanikanth

-----Original Message-----
From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk] 
Sent: Wednesday, January 11, 2012 6:00 PM
To: Rajanikanth H V
Cc: linux-serial@vger.kernel.org; linux-kernel@vger.kernel.org; gregkh@sude.de; linux-arm-kernel@lists.infradead.org
Subject: Re: tty/serial: Need clarification on Support for 4+M Baudrate

On Wed, 11 Jan 2012 17:49:01 +0530
> I have a requirement to interface UART with an external microcontroller 
> using baud rate above 4Mbps, hence following is my approach to apply
> the changes. Can any one review/provide me appropriate approach.

See TCGETS2/TCSETS2 and the BOTHER flag.

The kernel supports aetting arbitary baud rates already.

Alan

^ permalink raw reply

* Re: mxs-auart serial driver DMA support?
From: Lauri Hintsala @ 2012-01-12 10:28 UTC (permalink / raw)
  To: Wolfram Sang
  Cc: Sascha Hauer, linux-arm-kernel@lists.infradead.org, linux-serial
In-Reply-To: <20120112094244.GA2775@pengutronix.de>

On 01/12/2012 11:42 AM, Wolfram Sang wrote:
>
>> Any plans to add DMA support for mxs-auart serial driver? I noticed
>> it is impossible to archive full 3.25 Mbs speed with current one.
>
> No plans from our side, currently.

OK, AUART works fine with 115200 bps but over that it loose data 
randomly. I have seen fifo overrun errors during receiving data with 
1Mbs and over. So current driver is unuseful with higher baud rates.

Regards,
Lauri

^ permalink raw reply

* Re: mxs-auart serial driver DMA support?
From: Wolfram Sang @ 2012-01-12  9:42 UTC (permalink / raw)
  To: Lauri Hintsala
  Cc: Sascha Hauer, linux-arm-kernel@lists.infradead.org, linux-serial
In-Reply-To: <4F0E7EB0.2060906@bluegiga.com>

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]


> Any plans to add DMA support for mxs-auart serial driver? I noticed
> it is impossible to archive full 3.25 Mbs speed with current one.

No plans from our side, currently.

> As I understood porting DMA support from freescale's driver is not
> trivial because MXS DMA implementation has been changed to mainline
> version.

Yes, luckily. DMAENGINE is really the way to go.

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* [PATCH RFC] omap-serial: Fix the error handling in the omap_serial probe
From: Shubhrajyoti D @ 2012-01-12  9:32 UTC (permalink / raw)
  To: linux-serial; +Cc: linux-omap, linux-kernel, linux-arm-kernel, Shubhrajyoti D

The patch does the following

- The pm_runtime_disable is called in the remove not in the error
  case of probe.The patch calls the pm_runtime_disable in the error
  case.
- The  up is not freed in the error path. Fix the memory leak by calling
 kfree in the error path.
- Also the iounmap is not called fix the same by calling iounmap in the
  error case of probe and remove .
- Make the name of the error tags more meaningful.

Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
 drivers/tty/serial/omap-serial.c |   27 +++++++++++++++++----------
 1 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index eb90a01..29fe6fd 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1369,14 +1369,14 @@ static int serial_omap_probe(struct platform_device *pdev)
 
 	dma_rx = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
 	if (!dma_rx) {
-		ret = -EINVAL;
-		goto err;
+		ret = -ENXIO;
+		goto do_release_region;
 	}
 
 	dma_tx = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
 	if (!dma_tx) {
-		ret = -EINVAL;
-		goto err;
+		ret = -ENXIO;
+		goto do_release_region;
 	}
 
 	up = kzalloc(sizeof(*up), GFP_KERNEL);
@@ -1403,7 +1403,7 @@ static int serial_omap_probe(struct platform_device *pdev)
 		dev_err(&pdev->dev, "failed to get alias/pdev id, errno %d\n",
 								up->port.line);
 		ret = -ENODEV;
-		goto err;
+		goto err_port_line;
 	}
 
 	sprintf(up->name, "OMAP UART%d", up->port.line);
@@ -1412,7 +1412,7 @@ static int serial_omap_probe(struct platform_device *pdev)
 	if (!up->port.membase) {
 		dev_err(&pdev->dev, "can't ioremap UART\n");
 		ret = -ENOMEM;
-		goto err;
+		goto err_ioremap;
 	}
 
 	up->port.flags = omap_up_info->flags;
@@ -1458,16 +1458,22 @@ static int serial_omap_probe(struct platform_device *pdev)
 
 	ret = uart_add_one_port(&serial_omap_reg, &up->port);
 	if (ret != 0)
-		goto do_release_region;
+		goto err_add_port;
 
 	pm_runtime_put(&pdev->dev);
 	platform_set_drvdata(pdev, up);
 	return 0;
-err:
-	dev_err(&pdev->dev, "[UART%d]: failure [%s]: %d\n",
-				pdev->id, __func__, ret);
+
+err_add_port:
+	pm_runtime_disable(&pdev->dev);
+	iounmap(up->port.membase);
+err_ioremap:
+err_port_line:
+	kfree(up);
 do_release_region:
 	release_mem_region(mem->start, resource_size(mem));
+	dev_err(&pdev->dev, "[UART%d]: failure [%s]: %d\n",
+				pdev->id, __func__, ret);
 	return ret;
 }
 
@@ -1476,6 +1482,7 @@ static int serial_omap_remove(struct platform_device *dev)
 	struct uart_omap_port *up = platform_get_drvdata(dev);
 
 	if (up) {
+		iounmap(up->port.membase);
 		pm_runtime_disable(&up->pdev->dev);
 		uart_remove_one_port(&serial_omap_reg, &up->port);
 		pm_qos_remove_request(&up->pm_qos_request);
-- 
1.7.1


^ permalink raw reply related

* Re: [PATCH RFC] omap-serial: make serial_omap_restore_context depend on CONFIG_PM_RUNTIME
From: Govindraj @ 2012-01-12  7:32 UTC (permalink / raw)
  To: Shubhrajyoti D; +Cc: linux-serial, linux-omap, linux-arm-kernel
In-Reply-To: <1326261400-3929-1-git-send-email-shubhrajyoti@ti.com>

On Wed, Jan 11, 2012 at 11:26 AM, Shubhrajyoti D <shubhrajyoti@ti.com> wrote:
> The function serial_omap_restore_context is called only from
> serial_omap_runtime_resume which depends on CONFIG_PM_RUNTIME. Make
> serial_omap_restore_context also compile conditionally.
>
> if CONFIG_PM_RUNTIME is not defined below warn may be seen.
>
>  LD      net/xfrm/built-in.o
> drivers/tty/serial/omap-serial.c:1524: warning: 'serial_omap_restore_context' defined but not used
>  CC      drivers/tty/vt/selection.o
>
> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>

Acked-by: Govindraj.R <govindraj.raja@ti.com>

> ---
> applies on Tony's uart branch
>

Should apply on cleanly on mainline also
Please check.

Same comments for other patch (omap-serial :Make the
suspend/resume functions depend on CONFIG_PM_SLEEP)

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

* mxs-auart serial driver DMA support?
From: Lauri Hintsala @ 2012-01-12  6:30 UTC (permalink / raw)
  To: Sascha Hauer; +Cc: linux-serial, linux-arm-kernel-request

Hi,

Any plans to add DMA support for mxs-auart serial driver? I noticed it 
is impossible to archive full 3.25 Mbs speed with current one.

There is DMA supported driver on freescale's git tree:
http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=blob;f=drivers/serial/mxs-auart.c;hb=imx_2.6.35_11.09.01

As I understood porting DMA support from freescale's driver is not 
trivial because MXS DMA implementation has been changed to mainline version.

Regards,
Lauri Hintsala

^ permalink raw reply

* mxs-auart serial driver DMA support?
From: Lauri Hintsala @ 2012-01-12  6:33 UTC (permalink / raw)
  To: Sascha Hauer; +Cc: linux-arm-kernel@lists.infradead.org, linux-serial

Hi,

Any plans to add DMA support for mxs-auart serial driver? I noticed it 
is impossible to archive full 3.25 Mbs speed with current one.

There is DMA supported driver on freescale's git tree:
http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=blob;f=drivers/serial/mxs-auart.c;hb=imx_2.6.35_11.09.01

As I understood porting DMA support from freescale's driver is not 
trivial because MXS DMA implementation has been changed to mainline version.

Regards,
Lauri Hintsala

^ permalink raw reply

* Dear Beneficiary
From: WESTERN UNION MONEY TRANSFER @ 2012-01-11 22:16 UTC (permalink / raw)



Dear Beneficiary,

We are here to notify you that the sum of  $250,000 U.S.Dollars was generated and
awarded to you by the Western Union Foundation in conjunction with the British Union
Foundation.This award was been selected through the internet, where your e-mail
address was indicated and notified.The Western Union  Foundation, All the email
addresses of the people that are active online,among the millions of our customers
who use Western Union in their business transactions.Four people are selected Every
year  to benefit from this promotion and you are one of the Selected Winners.

To avoid misappropriation of funds, proper verifications must be carried out before
the fund is transferred. We require the details below for verification so that the
transfer can be carried out.

1. Receiver's Full Name:
2. Receiver's Address:
3. Receiver's Country:
4. Receiver's Telephone Number:
5. Receiver's Occupation:

 Send the above details to us via the email addresses stated below:

Western Union District Manager (Mr.Peter Parker)
Website: www.westernunion.com
E-mail: western_transfer24@hotmail.com
Tel: +447031806057

Note: You were selected as a winner on this promotion and I personally advise that
you use the funds wisely. However, we need your information as stated above to
commence the transaction due process:

Copyright © 2001-2011 The Western Union Company , All Rights Reserved.


--
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: tty/serial: Need clarification on Support for 4+M Baudrate
From: Alan Cox @ 2012-01-11 12:30 UTC (permalink / raw)
  To: Rajanikanth H V; +Cc: linux-serial, linux-kernel, gregkh, linux-arm-kernel
In-Reply-To: <20120111121901.GA4034@bnru05>

On Wed, 11 Jan 2012 17:49:01 +0530
> I have a requirement to interface UART with an external microcontroller 
> using baud rate above 4Mbps, hence following is my approach to apply
> the changes. Can any one review/provide me appropriate approach.

See TCGETS2/TCSETS2 and the BOTHER flag.

The kernel supports aetting arbitary baud rates already.

Alan

^ permalink raw reply

* tty/serial: Need clarification on Support for 4+M Baudrate
From: Rajanikanth H V @ 2012-01-11 12:19 UTC (permalink / raw)
  To: linux-serial; +Cc: linux-kernel, gregkh, linux-arm-kernel

Ref:
	kernel version 3.0.8

Platform: ARM Based SOC, UART:amba pl011

I have a requirement to interface UART with an external microcontroller 
using baud rate above 4Mbps, hence following is my approach to apply
the changes. Can any one review/provide me appropriate approach.



diff --git a/arch/arm/include/asm/termbits.h b/arch/arm/include/asm/termbits.h
index 704135d..556f5fb 100644
--- a/arch/arm/include/asm/termbits.h
+++ b/arch/arm/include/asm/termbits.h
@@ -155,6 +155,8 @@ struct ktermios {
 #define  B3000000 0010015
 #define  B3500000 0010016
 #define  B4000000 0010017
+#define  B4050000 0010020
+#define  B4800000 0010021
 #define CIBAUD	  002003600000		/* input baud rate */
 #define CMSPAR    010000000000		/* mark or space (stick) parity */
 #define CRTSCTS	  020000000000		/* flow control */
diff --git a/drivers/tty/tty_ioctl.c b/drivers/tty/tty_ioctl.c
index 53f2442..59c0682 100644
--- a/drivers/tty/tty_ioctl.c
+++ b/drivers/tty/tty_ioctl.c
@@ -203,7 +203,7 @@ static const speed_t baud_table[] = {
 	76800, 153600, 307200, 614400, 921600
 #else
 	500000, 576000, 921600, 1000000, 1152000, 1500000, 2000000,
-	2500000, 3000000, 3500000, 4000000
+	2500000, 3000000, 3500000, 4000000, 4050000, 4800000
 #endif
 };
 
@@ -213,7 +213,7 @@ static const tcflag_t baud_bits[] = {
 	B1200, B1800, B2400, B4800, B9600, B19200, B38400,
 	B57600, B115200, B230400, B460800, B500000, B576000,
 	B921600, B1000000, B1152000, B1500000, B2000000, B2500000,
-	B3000000, B3500000, B4000000
+	B3000000, B3500000, B4000000, B4050000, B4800000
 };
 #else
 static const tcflag_t baud_bits[] = {
diff --git a/include/asm-generic/termbits.h b/include/asm-generic/termbits.h
index 232b478..f71e72f 100644
--- a/include/asm-generic/termbits.h
+++ b/include/asm-generic/termbits.h
@@ -156,6 +156,8 @@ struct ktermios {
 #define  B3000000 0010015
 #define  B3500000 0010016
 #define  B4000000 0010017
+#define  B4050000 0010020
+#define  B4800000 0010021
 #define CIBAUD	  002003600000	/* input baud rate */
 #define CMSPAR	  010000000000	/* mark or space (stick) parity */
 #define CRTSCTS	  020000000000	/* flow control */

^ permalink raw reply related

* [PATCH RFC] omap-serial: make serial_omap_restore_context depend on CONFIG_PM_RUNTIME
From: Shubhrajyoti D @ 2012-01-11  5:56 UTC (permalink / raw)
  To: linux-serial; +Cc: linux-omap, linux-arm-kernel, Shubhrajyoti D

The function serial_omap_restore_context is called only from
serial_omap_runtime_resume which depends on CONFIG_PM_RUNTIME. Make
serial_omap_restore_context also compile conditionally.

if CONFIG_PM_RUNTIME is not defined below warn may be seen.

  LD      net/xfrm/built-in.o
drivers/tty/serial/omap-serial.c:1524: warning: 'serial_omap_restore_context' defined but not used
  CC      drivers/tty/vt/selection.o

Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
applies on Tony's uart branch

 drivers/tty/serial/omap-serial.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index ca24ab3..91b0f65 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1521,6 +1521,7 @@ static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1)
 	}
 }
 
+#ifdef CONFIG_PM_RUNTIME
 static void serial_omap_restore_context(struct uart_omap_port *up)
 {
 	if (up->errata & UART_ERRATA_i202_MDR1_ACCESS)
@@ -1550,7 +1551,6 @@ static void serial_omap_restore_context(struct uart_omap_port *up)
 		serial_out(up, UART_OMAP_MDR1, up->mdr1);
 }
 
-#ifdef CONFIG_PM_RUNTIME
 static int serial_omap_runtime_suspend(struct device *dev)
 {
 	struct uart_omap_port *up = dev_get_drvdata(dev);
-- 
1.7.1


^ permalink raw reply related

* [PATCH RFC] omap-serial :Make the suspend/resume functions depend on CONFIG_PM_SLEEP.
From: Shubhrajyoti D @ 2012-01-11  5:54 UTC (permalink / raw)
  To: linux-serial; +Cc: linux-omap, linux-arm-kernel, Shubhrajyoti D

    The macro SET_SYSTEM_SLEEP_PM_OPS  depends CONFIG_PM_SLEEP. The patch
    defines the suspend and resume functions for CONFIG_PM_SLEEP instead of
    CONFIG_SUSPEND.

Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
applies on Tony's uart branch

 drivers/tty/serial/omap-serial.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 91b0f65..eb90a01 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1160,7 +1160,7 @@ static struct uart_driver serial_omap_reg = {
 	.cons		= OMAP_CONSOLE,
 };
 
-#ifdef CONFIG_SUSPEND
+#ifdef CONFIG_PM_SLEEP
 static int serial_omap_suspend(struct device *dev)
 {
 	struct uart_omap_port *up = dev_get_drvdata(dev);
-- 
1.7.1


^ permalink raw reply related

* Re: [PATCH] Updated TTY MAINTAINERS info
From: Greg KH @ 2012-01-09 22:52 UTC (permalink / raw)
  To: Lucas Kannebley Tavares
  Cc: linux-serial, linux-kernel, Thadeu Lima de Souza Cascardo
In-Reply-To: <4F0B4F66.8000302@linux.vnet.ibm.com>

On Mon, Jan 09, 2012 at 06:34:46PM -0200, Lucas Kannebley Tavares wrote:
> On 01/09/2012 06:07 PM, Greg KH wrote:
> >On Mon, Jan 09, 2012 at 05:39:24PM -0200, Lucas Kannebley Tavares wrote:
> >>Greg Kroah-Hartman is the current TTY maintainer, however he wouldn't appear
> >>listed as such upon running get_maintainers.pl for drivers under
> >>drivers/tty/serial.
> >>
> >>Signed-off-by: Lucas Kannebley Tavares<lucaskt@linux.vnet.ibm.com>
> >>---
> >>  MAINTAINERS |    2 +-
> >>  1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >>diff --git a/MAINTAINERS b/MAINTAINERS
> >>index cc6a466..6a856df 100644
> >>--- a/MAINTAINERS
> >>+++ b/MAINTAINERS
> >>@@ -6641,7 +6641,7 @@ TTY LAYER
> >>  M:	Greg Kroah-Hartman<gregkh@suse.de>
> >>  S:	Maintained
> >>  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6.git
> >>-F:	drivers/tty/*
> >>+F:	drivers/tty/
> >
> >Isn't this just a bug in the get_maintainers.pl script?  Why does this
> >patch fix the problem?
> >
> >greg k-h
> >
> 
> To quote from MAINTAINERS
> 
> >	F: Files and directories with wildcard patterns.
> >	   A trailing slash includes all files and subdirectory files.
> >	   F:	drivers/net/	all files in and below drivers/net
> >	   F:	drivers/net/*	all files in drivers/net, but not below
> 
> In this case I believe you are the maintainer for the entire tree,
> or am I mistaken? If so, the documentation states that it shouldn't
> have an asterisk.

Ah, I missed that, you are correct.  I'll queue this up for the next
round of tty patches to go to Linus (after 3.3-rc1 is out.)

thanks,

greg k-h

^ permalink raw reply

* Re: [PATCH] Updated TTY MAINTAINERS info
From: Lucas Kannebley Tavares @ 2012-01-09 20:34 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-serial, linux-kernel, Thadeu Lima de Souza Cascardo
In-Reply-To: <20120109200751.GA8337@suse.de>

On 01/09/2012 06:07 PM, Greg KH wrote:
> On Mon, Jan 09, 2012 at 05:39:24PM -0200, Lucas Kannebley Tavares wrote:
>> Greg Kroah-Hartman is the current TTY maintainer, however he wouldn't appear
>> listed as such upon running get_maintainers.pl for drivers under
>> drivers/tty/serial.
>>
>> Signed-off-by: Lucas Kannebley Tavares<lucaskt@linux.vnet.ibm.com>
>> ---
>>   MAINTAINERS |    2 +-
>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index cc6a466..6a856df 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -6641,7 +6641,7 @@ TTY LAYER
>>   M:	Greg Kroah-Hartman<gregkh@suse.de>
>>   S:	Maintained
>>   T:	git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6.git
>> -F:	drivers/tty/*
>> +F:	drivers/tty/
>
> Isn't this just a bug in the get_maintainers.pl script?  Why does this
> patch fix the problem?
>
> greg k-h
>

To quote from MAINTAINERS

 >	F: Files and directories with wildcard patterns.
 >	   A trailing slash includes all files and subdirectory files.
 >	   F:	drivers/net/	all files in and below drivers/net
 >	   F:	drivers/net/*	all files in drivers/net, but not below

In this case I believe you are the maintainer for the entire tree, or am 
I mistaken? If so, the documentation states that it shouldn't have an 
asterisk.

Lucas


^ permalink raw reply

* Re: [PATCH] Updated TTY MAINTAINERS info
From: Greg KH @ 2012-01-09 20:07 UTC (permalink / raw)
  To: Lucas Kannebley Tavares
  Cc: linux-serial, linux-kernel, Thadeu Lima de Souza Cascardo
In-Reply-To: <1326137964-10671-1-git-send-email-lucaskt@linux.vnet.ibm.com>

On Mon, Jan 09, 2012 at 05:39:24PM -0200, Lucas Kannebley Tavares wrote:
> Greg Kroah-Hartman is the current TTY maintainer, however he wouldn't appear
> listed as such upon running get_maintainers.pl for drivers under
> drivers/tty/serial.
> 
> Signed-off-by: Lucas Kannebley Tavares <lucaskt@linux.vnet.ibm.com>
> ---
>  MAINTAINERS |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cc6a466..6a856df 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6641,7 +6641,7 @@ TTY LAYER
>  M:	Greg Kroah-Hartman <gregkh@suse.de>
>  S:	Maintained
>  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6.git
> -F:	drivers/tty/*
> +F:	drivers/tty/

Isn't this just a bug in the get_maintainers.pl script?  Why does this
patch fix the problem?

greg k-h

^ permalink raw reply

* [PATCH] Updated TTY MAINTAINERS info
From: Lucas Kannebley Tavares @ 2012-01-09 19:39 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: linux-serial, linux-kernel, Thadeu Lima de Souza Cascardo

Greg Kroah-Hartman is the current TTY maintainer, however he wouldn't appear
listed as such upon running get_maintainers.pl for drivers under
drivers/tty/serial.

Signed-off-by: Lucas Kannebley Tavares <lucaskt@linux.vnet.ibm.com>
---
 MAINTAINERS |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index cc6a466..6a856df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6641,7 +6641,7 @@ TTY LAYER
 M:	Greg Kroah-Hartman <gregkh@suse.de>
 S:	Maintained
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6.git
-F:	drivers/tty/*
+F:	drivers/tty/
 F:	drivers/tty/serial/serial_core.c
 F:	include/linux/serial_core.h
 F:	include/linux/serial.h
-- 
1.7.4.4


^ permalink raw reply related

* [GIT PATCH] TTY/serial driver merge for 3.3
From: Greg KH @ 2012-01-09 19:09 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton; +Cc: linux-kernel, linux-serial

Here is the big tty/serial merge for 3.3.

Lots of good fixes and reworks by Jiri on the tty and serial drivers,
resolving some nasty issues, and a number of driver updates as well.
Full details are in the shortlog below.

Please pull from:
	git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-next

All of these patches have been in the -mm and -next trees for a while.

thanks,

greg k-h

------------

 Documentation/serial/driver                |    2 +-
 arch/powerpc/kernel/legacy_serial.c        |    3 +
 arch/x86/include/asm/mrst.h                |    2 +-
 arch/x86/kernel/early_printk.c             |    2 +-
 arch/x86/platform/mrst/early_printk_mrst.c |   16 +-
 drivers/parport/parport_ax88796.c          |   13 +-
 drivers/parport/parport_sunbpp.c           |   13 +-
 drivers/tty/n_hdlc.c                       |    6 +-
 drivers/tty/n_tty.c                        |    8 +-
 drivers/tty/pty.c                          |   26 +-
 drivers/tty/serial/8250.c                  |   98 ++---
 drivers/tty/serial/8250.h                  |   26 +
 drivers/tty/serial/8250_dw.c               |   12 +-
 drivers/tty/serial/8250_fsl.c              |   63 +++
 drivers/tty/serial/8250_pci.c              |   47 ++-
 drivers/tty/serial/Kconfig                 |   37 ++-
 drivers/tty/serial/Makefile                |    2 +
 drivers/tty/serial/atmel_serial.c          |   12 +-
 drivers/tty/serial/bfin_sport_uart.c       |   22 +-
 drivers/tty/serial/bfin_sport_uart.h       |    5 +-
 drivers/tty/serial/bfin_uart.c             |   83 ++--
 drivers/tty/serial/ifx6x60.c               |    1 -
 drivers/tty/serial/imx.c                   |  148 +++++-
 drivers/tty/serial/m32r_sio.c              |    7 +-
 drivers/tty/serial/max3100.c               |    1 -
 drivers/tty/serial/max3107-aava.c          |    1 -
 drivers/tty/serial/max3107.c               |    1 -
 drivers/tty/serial/mfd.c                   |   18 +-
 drivers/tty/serial/mrst_max3110.c          |    1 -
 drivers/tty/serial/msm_serial_hs.c         |   23 +-
 drivers/tty/serial/mxs-auart.c             |    5 +-
 drivers/tty/serial/omap-serial.c           |    2 +-
 drivers/tty/serial/pch_uart.c              |  160 ++++++-
 drivers/tty/serial/sc26xx.c                |   14 +-
 drivers/tty/serial/serial_core.c           |  325 +++++++-----
 drivers/tty/serial/serial_cs.c             |    8 +-
 drivers/tty/serial/sirfsoc_uart.c          |  783 ++++++++++++++++++++++++++++
 drivers/tty/serial/sirfsoc_uart.h          |  185 +++++++
 drivers/tty/serial/timbuart.c              |   15 +-
 drivers/tty/serial/vr41xx_siu.c            |   13 +-
 drivers/tty/tty_io.c                       |  309 +++++++-----
 drivers/tty/tty_ldisc.c                    |   22 +-
 drivers/tty/vt/consolemap.c                |    2 +-
 include/linux/serial_8250.h                |    5 +
 include/linux/serial_core.h                |  100 +---
 45 files changed, 1989 insertions(+), 658 deletions(-)
 create mode 100644 drivers/tty/serial/8250_fsl.c
 create mode 100644 drivers/tty/serial/sirfsoc_uart.c
 create mode 100644 drivers/tty/serial/sirfsoc_uart.h

---------------

Alexander Stein (1):
      drivers/tty/serial/pch_uart.c: add console support

Axel Lin (2):
      parport: convert drivers/parport/* to use module_platform_driver()
      TTY: serial: convert drivers/tty/serial/* to use module_platform_driver()

Claudio Scordino (1):
      atmel_serial: fix spinlock lockup in RS485 code

Dan Williams (2):
      serial/8250_pci: setup-quirk workaround for the kt serial controller
      serial/8250_pci: init-quirk msi support for kt serial controller

Dave Young (1):
      tty_ldisc: remove unnecessary negative return check for wait_event_timeout

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

Ilya Zykov (1):
      tty: n_hdlc not atomic use tty->flags.

Jiri Slaby (19):
      TTY: move pgrp killing
      TTY: extract /dev/tty handling from tty_open
      TTY: extract driver lookup from tty_open
      TTY: coalesce fail paths in tty_open
      TTY: move tty_lookup_driver to switch-cases
      TTY: move debug checking out of tty_release
      TTY: open/release, cleanup printks
      TTY: serial, cleanup include file
      TTY: serial, cleanup atmel_set_ldisc
      TTY: serial, switch closing_wait and close_delay to jiffies
      TTY: serial, use tty_port_close_start helper
      TTY: serial, document few functions
      TTY: serial, do not touch tty->alt_speed
      TTY: serial, inline uart_get
      TTY: serial, define uart_port_activate/shutdown
      TTY: serial, fill uart_port_shutdown
      TTY: serial, extract uart_port_startup
      TTY: pty, cleanup the pty counting
      TTY: ldisc, remove some unneeded includes

Lars-Peter Clausen (1):
      TTY: Remove redundant spi driver bus initialization

Maciej Szmigiero (1):
      serial: fix serial_cs I/O windows for Argosy RS-COM 2P

Mayank Rana (2):
      msm_serial_hs: Fix type inconsistency for tx and rx command_ptr_ptr
      msm_serial_hs: Fix spinlock recursion in handling CTS

Mika Westerberg (1):
      serial, mfd: don't hardcode the console

Paul Gortmaker (8):
      serial: move struct uart_8250_port from 8250.c to 8250.h
      serial: clean up parameter passing for 8250 Rx IRQ handling
      serial: export the key functions for an 8250 IRQ handler
      serial: make 8250 timeout use the specified IRQ handler
      serial: manually inline serial8250_handle_port
      serial: add irq handler for Freescale 16550 errata.
      serial: make FSL errata depend on 8250_CONSOLE, not just 8250
      serial: driver for m32 arch should not have DEC alpha errata

Rong Wang (1):
      UART: add CSR SiRFprimaII SoC on-chip uart drivers

Saleem Abdulrasool (1):
      imx: add polled io uart methods

Shubhrajyoti D (2):
      serial: OMAP2+: UART: Make the SERIAL_OMAP depend on ARCH_OMAP2PLUS
      OMAP: UART: fix the return type of check_modem_status

Sonic Zhang (8):
      serial: bfin-uart: Request CTS GPIO PIN when the serial device starts up.
      serial: bfin-uart: Add tty ASYNC_CTS_FLOW flag to do CTS flow control.
      serial: bfin-uart: remove redundant CTS check for hardware CTS control.
      tty: bfin-sport-uart: Rx interrupt is not called always with irq disabled.
      serial: bfin-sport-uart: Request CTS GPIO PIN when the sport emulated serial device starts up.
      serial: bfin-sport-uart: Add tty ASYNC_CTS_FLOW flag to do CTS flow control.
      serial: bfin-uart: Enable hardware automatic CTS only when CTS pin is available.
      serial: bfin-uart: Remove ASYNC_CTS_FLOW flag for hardware automatic CTS.

Thorsten Wißmann (1):
      drivers/tty: Remove unneeded spaces

Uwe Kleine-König (6):
      serial/imx: propagate error of platform_driver_register in init routine
      serial/mxs-auart: only wake up tty layer once
      serial: use DIV_ROUND_CLOSEST instead of open coding it
      serial/documentation: fix documented name of DCD cpp symbol
      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

Wolfram Sang (1):
      serial: 8250: replace hardcoded 0xbf with #define

Yegor Yefremov (1):
      serial: add support for 400 and 800 v3 series Titan cards

Zeng Zhaoming (1):
      tty: Fix memory leak in virtual console when enable unicode translation

^ permalink raw reply

* [PATCH v3] serial/efm32: add new driver
From: Uwe Kleine-König @ 2012-01-09 16:44 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: <1324561092-1945-1-git-send-email-u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Hello,

changes since v2:
- use {read,write}l_relaxed
- rename driver to efm32-uart as USARTs and UARTs can be handled both
  with it
- disable TX in .stop_tx (which needs some changes related to
  USARTn_IF_TXC)

Best regards
Uwe

 .../devicetree/bindings/tty/serial/efm32-uart.txt  |   14 +
 arch/arm/boot/dts/efm32gg-dk3750.dts               |    2 +-
 arch/arm/mach-efm32/devices/pdev-efm32-usart.c     |    6 +-
 drivers/tty/serial/Kconfig                         |   13 +
 drivers/tty/serial/Makefile                        |    1 +
 drivers/tty/serial/efm32-uart.c                    |  761 ++++++++++++++++++++
 include/linux/serial_core.h                        |    2 +
 7 files changed, 795 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/tty/serial/efm32-uart.txt
 create mode 100644 drivers/tty/serial/efm32-uart.c

diff --git a/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt b/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt
new file mode 100644
index 0000000..6588b69
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt
@@ -0,0 +1,14 @@
+* Energymicro efm32 UART
+
+Required properties:
+- compatible : Should be "efm32,uart"
+- reg : Address and length of the register set
+- interrupts : Should contain uart interrupt
+
+Example:
+
+uart@0x4000c400 {
+	compatible = "efm32,uart";
+	reg = <0x4000c400 0x400>;
+	interrupts = <15>;
+};
diff --git a/arch/arm/boot/dts/efm32gg-dk3750.dts b/arch/arm/boot/dts/efm32gg-dk3750.dts
index a4aa4f3..2a28b0f 100644
--- a/arch/arm/boot/dts/efm32gg-dk3750.dts
+++ b/arch/arm/boot/dts/efm32gg-dk3750.dts
@@ -32,7 +32,7 @@
 		ranges;
 
 		uart1: uart@0x4000c400 { /* USART1 */
-			compatible = "efm32,usart";
+			compatible = "efm32,uart";
 			reg = <0x4000c400 0x400>;
 			interrupts = <15>;
 			status = "ok";
diff --git a/arch/arm/mach-efm32/devices/pdev-efm32-usart.c b/arch/arm/mach-efm32/devices/pdev-efm32-usart.c
index 03ff343..c7d91e1 100644
--- a/arch/arm/mach-efm32/devices/pdev-efm32-usart.c
+++ b/arch/arm/mach-efm32/devices/pdev-efm32-usart.c
@@ -20,19 +20,19 @@ static const struct resource efm32_usart2_resources[] __initconst = {
 
 const struct platform_device_info efm32_usart_devinfo[] __initconst = {
 	[0] = {
-		.name = "efm32-usart",
+		.name = "efm32-uart",
 		.id = 0,
 		.res = efm32_usart0_resources,
 		.num_res = ARRAY_SIZE(efm32_usart0_resources),
 	},
 	[1] = {
-		.name = "efm32-usart",
+		.name = "efm32-uart",
 		.id = 1,
 		.res = efm32_usart1_resources,
 		.num_res = ARRAY_SIZE(efm32_usart1_resources),
 	},
 	[2] = {
-		.name = "efm32-usart",
+		.name = "efm32-uart",
 		.id = 2,
 		.res = efm32_usart2_resources,
 		.num_res = ARRAY_SIZE(efm32_usart2_resources),
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 925a1e5..b91974a 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1610,4 +1610,17 @@ config SERIAL_XILINX_PS_UART_CONSOLE
 	help
 	  Enable a Xilinx PS UART port to be the system console.
 
+config SERIAL_EFM32_UART
+	tristate "EFM32 UART/USART port."
+	depends on ARCH_EFM32
+	select SERIAL_CORE
+	help
+	  This driver support the USART and UART ports on
+	  Energy Micro's efm32 SoCs.
+
+config SERIAL_EFM32_UART_CONSOLE
+	bool "EFM32 UART/USART console support"
+	depends on SERIAL_EFM32_UART=y
+	select SERIAL_CORE_CONSOLE
+
 endmenu
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index e10cf5b..7814122 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_UART) += efm32-uart.o
diff --git a/drivers/tty/serial/efm32-uart.c b/drivers/tty/serial/efm32-uart.c
new file mode 100644
index 0000000..ed0bc0d
--- /dev/null
+++ b/drivers/tty/serial/efm32-uart.c
@@ -0,0 +1,761 @@
+#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-uart"
+#define DEV_NAME "ttyefm"
+
+#define UARTn_CTRL		0x00
+#define UARTn_CTRL_SYNC		0x0001
+#define UARTn_CTRL_TXBIL		0x1000
+
+#define UARTn_FRAME		0x04
+#define UARTn_FRAME_DATABITS__MASK	0x000f
+#define UARTn_FRAME_DATABITS(n)	((n) - 3)
+#define UARTn_FRAME_PARITY_NONE	0x0000
+#define UARTn_FRAME_PARITY_EVEN	0x0200
+#define UARTn_FRAME_PARITY_ODD		0x0300
+#define UARTn_FRAME_STOPBITS_HALF	0x0000
+#define UARTn_FRAME_STOPBITS_ONE	0x1000
+#define UARTn_FRAME_STOPBITS_TWO	0x3000
+
+#define UARTn_CMD		0x0c
+#define UARTn_CMD_RXEN			0x0001
+#define UARTn_CMD_RXDIS		0x0002
+#define UARTn_CMD_TXEN			0x0004
+#define UARTn_CMD_TXDIS		0x0008
+
+#define UARTn_STATUS		0x10
+#define UARTn_STATUS_TXENS		0x0002
+#define UARTn_STATUS_TXC		0x0020
+#define UARTn_STATUS_TXBL		0x0040
+#define UARTn_STATUS_RXDATAV		0x0080
+
+#define UARTn_CLKDIV		0x14
+
+#define UARTn_RXDATAX		0x18
+#define UARTn_RXDATAX_PERR		0x4000
+#define UARTn_RXDATAX_FERR		0x8000
+
+#define UARTn_TXDATA		0x34
+
+#define UARTn_IF		0x40
+#define UARTn_IF_TXC			0x0001
+#define UARTn_IF_TXBL			0x0002
+#define UARTn_IF_RXDATAV		0x0004
+
+#define UARTn_IFS		0x44
+#define UARTn_IFC		0x48
+#define UARTn_IEN		0x4c
+
+#define UARTn_ROUTE		0x54
+#define UARTn_ROUTE_RXPEN		0x0001
+#define UARTn_ROUTE_TXPEN		0x0002
+
+struct efm32_uart_port {
+	struct uart_port port;
+	unsigned int txirq;
+	struct clk *clk;
+};
+#define to_efm_port(_port) container_of(_port, struct efm32_uart_port, port)
+#define efm_debug(efm_port, format, arg...)			\
+	dev_dbg(efm_port->port.dev, format, ##arg)
+
+static void efm32_uart_write32(struct efm32_uart_port *efm_port,
+		u32 value, unsigned offset)
+{
+	writel_relaxed(value, efm_port->port.membase + offset);
+}
+
+static u32 efm32_uart_read32(struct efm32_uart_port *efm_port,
+		unsigned offset)
+{
+	return readl_relaxed(efm_port->port.membase + offset);
+}
+
+static unsigned int efm32_uart_tx_empty(struct uart_port *port)
+{
+	struct efm32_uart_port *efm_port = to_efm_port(port);
+	u32 status = efm32_uart_read32(efm_port, UARTn_STATUS);
+
+	/* XXX: does TXBL also mean that the shifter is done? */
+	if (status & UARTn_STATUS_TXBL)
+		return TIOCSER_TEMT;
+	else
+		return 0;
+}
+
+static void efm32_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
+{
+	/* sorry, neither handshaking lines nor loop functionallity */
+}
+
+static unsigned int efm32_uart_get_mctrl(struct uart_port *port)
+{
+	/* sorry, no handshaking lines available */
+	return TIOCM_CAR | TIOCM_CTS | TIOCM_DSR;
+}
+
+static void efm32_uart_stop_tx(struct uart_port *port)
+{
+	struct efm32_uart_port *efm_port = to_efm_port(port);
+	u32 ien = efm32_uart_read32(efm_port,  UARTn_IEN);
+
+	efm32_uart_write32(efm_port, UARTn_CMD_TXDIS, UARTn_CMD);
+	efm32_uart_write32(efm_port,
+			ien & ~(UARTn_IF_TXC | UARTn_IF_TXBL), UARTn_IEN);
+}
+
+static void efm32_uart_tx_chars(struct efm32_uart_port *efm_port)
+{
+	struct uart_port *port = &efm_port->port;
+	struct circ_buf *xmit = &port->state->xmit;
+
+	while (efm32_uart_read32(efm_port, UARTn_STATUS) &
+			UARTn_STATUS_TXBL) {
+		if (port->x_char) {
+			port->icount.tx++;
+			efm32_uart_write32(efm_port, port->x_char,
+					UARTn_TXDATA);
+			port->x_char = 0;
+			continue;
+		}
+		if (!uart_circ_empty(xmit) && !uart_tx_stopped(port)) {
+			port->icount.tx++;
+			efm32_uart_write32(efm_port, xmit->buf[xmit->tail],
+					UARTn_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_uart_read32(efm_port, UARTn_STATUS) &
+				UARTn_STATUS_TXC)
+		efm32_uart_stop_tx(port);
+}
+
+static void efm32_uart_start_tx(struct uart_port *port)
+{
+	struct efm32_uart_port *efm_port = to_efm_port(port);
+	u32 ien;
+
+	efm32_uart_write32(efm_port,
+			UARTn_IF_TXBL | UARTn_IF_TXC, UARTn_IFC);
+	ien = efm32_uart_read32(efm_port,  UARTn_IEN);
+	efm32_uart_write32(efm_port,
+			ien | UARTn_IF_TXBL | UARTn_IF_TXC, UARTn_IEN);
+	efm32_uart_write32(efm_port, UARTn_CMD_TXEN, UARTn_CMD);
+
+	efm32_uart_tx_chars(efm_port);
+}
+
+static void efm32_uart_stop_rx(struct uart_port *port)
+{
+	struct efm32_uart_port *efm_port = to_efm_port(port);
+
+	efm32_uart_write32(efm_port, UARTn_CMD_RXDIS, UARTn_CMD);
+}
+
+static void efm32_uart_enable_ms(struct uart_port *port)
+{
+	/* no handshake lines, no modem status interrupts */
+}
+
+static void efm32_uart_break_ctl(struct uart_port *port, int ctl)
+{
+	/* not possible without fiddling with gpios */
+}
+
+static void efm32_uart_rx_chars(struct efm32_uart_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_uart_read32(efm_port, UARTn_STATUS) &
+			UARTn_STATUS_RXDATAV) {
+		u32 rxdata = efm32_uart_read32(efm_port, UARTn_RXDATAX);
+		int flag = 0;
+
+		port->icount.rx++;
+
+		/* XXX detect BREAK and overrun */
+
+		if (rxdata & UARTn_RXDATAX_PERR) {
+			port->icount.parity++;
+			if (port->read_status_mask & UARTn_RXDATAX_PERR)
+				flag = TTY_PARITY;
+		} else if (rxdata & UARTn_RXDATAX_FERR) {
+			port->icount.frame++;
+			if (port->read_status_mask & UARTn_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_uart_rxirq(int irq, void *data)
+{
+	struct efm32_uart_port *efm_port = data;
+	u32 irqflag = efm32_uart_read32(efm_port, UARTn_IF);
+
+	if (irqflag & UARTn_IF_RXDATAV) {
+		efm32_uart_write32(efm_port, UARTn_IF_RXDATAV, UARTn_IFC);
+		efm32_uart_rx_chars(efm_port);
+
+		return IRQ_HANDLED;
+	} else
+		return IRQ_NONE;
+}
+
+static irqreturn_t efm32_uart_txirq(int irq, void *data)
+{
+	struct efm32_uart_port *efm_port = data;
+	u32 irqflag = efm32_uart_read32(efm_port, UARTn_IF);
+
+	/* TXBL doesn't need to be cleared */
+	if (irqflag & UARTn_IF_TXC)
+		efm32_uart_write32(efm_port, UARTn_IF_TXC, UARTn_IFC);
+
+	if (irqflag & (UARTn_IF_TXC | UARTn_IF_TXBL)) {
+		efm32_uart_tx_chars(efm_port);
+		return IRQ_HANDLED;
+	} else
+		return IRQ_NONE;
+}
+
+static int efm32_uart_startup(struct uart_port *port)
+{
+	struct efm32_uart_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_uart_write32(efm_port, UARTn_ROUTE_RXPEN | UARTn_ROUTE_TXPEN,
+			UARTn_ROUTE);
+
+	ret = request_irq(port->irq, efm32_uart_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_uart_write32(efm_port, 0, UARTn_IEN);
+
+	ret = request_irq(efm_port->txirq, efm32_uart_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_uart_write32(efm_port, UARTn_IF_RXDATAV, UARTn_IEN);
+		efm32_uart_write32(efm_port, UARTn_CMD_RXEN, UARTn_CMD);
+	}
+
+err_clk_enable:
+	return ret;
+}
+
+static void efm32_uart_shutdown(struct uart_port *port)
+{
+	struct efm32_uart_port *efm_port = to_efm_port(port);
+
+	efm32_uart_write32(efm_port, 0, UARTn_IEN);
+	free_irq(port->irq, efm_port);
+
+	clk_disable(efm_port->clk);
+}
+
+static void efm32_uart_set_termios(struct uart_port *port,
+		struct ktermios *new, struct ktermios *old)
+{
+	struct efm32_uart_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 |= UARTn_FRAME_DATABITS(5);
+		break;
+	case CS6:
+		frame |= UARTn_FRAME_DATABITS(6);
+		break;
+	case CS7:
+		frame |= UARTn_FRAME_DATABITS(7);
+		break;
+	case CS8:
+		frame |= UARTn_FRAME_DATABITS(8);
+		break;
+	}
+
+	/* tx only supports a "half" stop bit */
+	new->c_cflag |= CSTOPB;
+	frame |= UARTn_FRAME_STOPBITS_ONE;
+
+	if (new->c_cflag & PARENB) {
+		if (new->c_cflag & PARODD)
+			frame |= UARTn_FRAME_PARITY_ODD;
+		else
+			frame |= UARTn_FRAME_PARITY_EVEN;
+	} else
+		frame |= UARTn_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_uart_write32(efm_port,
+			UARTn_CMD_TXDIS | UARTn_CMD_RXDIS, UARTn_CMD);
+
+	port->read_status_mask = 0;
+	port->ignore_status_mask = 0;
+
+	uart_update_timeout(port, new->c_cflag, baud);
+
+	efm32_uart_write32(efm_port, UARTn_CTRL_TXBIL, UARTn_CTRL);
+	efm32_uart_write32(efm_port, frame, UARTn_FRAME);
+	efm32_uart_write32(efm_port, clkdiv, UARTn_CLKDIV);
+
+	efm32_uart_write32(efm_port, UARTn_CMD_TXEN | UARTn_CMD_RXEN,
+			UARTn_CMD);
+
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static const char *efm32_uart_type(struct uart_port *port)
+{
+	return port->type == PORT_EFMUART ? "efm32-uart" : NULL;
+}
+
+static void efm32_uart_release_port(struct uart_port *port)
+{
+	struct efm32_uart_port *efm_port = to_efm_port(port);
+
+	clk_unprepare(efm_port->clk);
+	clk_put(efm_port->clk);
+	iounmap(port->membase);
+}
+
+static int efm32_uart_request_port(struct uart_port *port)
+{
+	struct efm32_uart_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_uart_config_port(struct uart_port *port, int type)
+{
+	if (type & UART_CONFIG_TYPE &&
+			!efm32_uart_request_port(port))
+		port->type = PORT_EFMUART;
+}
+
+static int efm32_uart_verify_port(struct uart_port *port,
+		struct serial_struct *serinfo)
+{
+	int ret = 0;
+
+	if (serinfo->type != PORT_UNKNOWN && serinfo->type != PORT_EFMUART)
+		ret = -EINVAL;
+
+	return ret;
+}
+
+static struct uart_ops efm32_uart_pops = {
+	.tx_empty = efm32_uart_tx_empty,
+	.set_mctrl = efm32_uart_set_mctrl,
+	.get_mctrl = efm32_uart_get_mctrl,
+	.stop_tx = efm32_uart_stop_tx,
+	.start_tx = efm32_uart_start_tx,
+	.stop_rx = efm32_uart_stop_rx,
+	.enable_ms = efm32_uart_enable_ms,
+	.break_ctl = efm32_uart_break_ctl,
+	.startup = efm32_uart_startup,
+	.shutdown = efm32_uart_shutdown,
+	.set_termios = efm32_uart_set_termios,
+	.type = efm32_uart_type,
+	.release_port = efm32_uart_release_port,
+	.request_port = efm32_uart_request_port,
+	.config_port = efm32_uart_config_port,
+	.verify_port = efm32_uart_verify_port,
+};
+
+static struct efm32_uart_port *efm32_uart_ports[3];
+
+#ifdef CONFIG_SERIAL_EFM32_UART_CONSOLE
+static void efm32_uart_console_putchar(struct uart_port *port, int ch)
+{
+	struct efm32_uart_port *efm_port = to_efm_port(port);
+	unsigned int timeout = 0x400;
+	u32 status;
+
+	while (1) {
+		status = efm32_uart_read32(efm_port, UARTn_STATUS);
+
+		if (status & UARTn_STATUS_TXBL)
+			break;
+		if (!timeout--)
+			return;
+	}
+	efm32_uart_write32(efm_port, ch, UARTn_TXDATA);
+}
+
+static void efm32_uart_console_write(struct console *co, const char *s,
+		unsigned int count)
+{
+	struct efm32_uart_port *efm_port = efm32_uart_ports[co->index];
+	u32 status = efm32_uart_read32(efm_port, UARTn_STATUS);
+	unsigned int timeout = 0x400;
+
+	if (!(status & UARTn_STATUS_TXENS))
+		efm32_uart_write32(efm_port, UARTn_CMD_TXEN, UARTn_CMD);
+
+	uart_console_write(&efm_port->port, s, count,
+			efm32_uart_console_putchar);
+
+	/* Wait for the transmitter to become empty */
+	while (1) {
+		u32 status = efm32_uart_read32(efm_port, UARTn_STATUS);
+		if (status & UARTn_STATUS_TXC)
+			break;
+		if (!timeout--)
+			break;
+	}
+
+	if (!(status & UARTn_STATUS_TXENS))
+		efm32_uart_write32(efm_port, UARTn_CMD_TXDIS, UARTn_CMD);
+}
+
+static void efm32_uart_console_get_options(struct efm32_uart_port *efm_port,
+		int *baud, int *parity, int *bits)
+{
+	u32 ctrl = efm32_uart_read32(efm_port, UARTn_CTRL);
+	u32 route, clkdiv, frame;
+
+	if (ctrl & UARTn_CTRL_SYNC)
+		/* not operating in async mode */
+		return;
+
+	route = efm32_uart_read32(efm_port, UARTn_ROUTE);
+	if (!(route & UARTn_ROUTE_TXPEN))
+		/* tx pin not routed */
+		return;
+
+	clkdiv = efm32_uart_read32(efm_port, UARTn_CLKDIV);
+
+	*baud = DIV_ROUND_CLOSEST(4 * efm_port->port.uartclk,
+			16 * (4 + (clkdiv >> 6)));
+
+	frame = efm32_uart_read32(efm_port, UARTn_FRAME);
+	if (frame & UARTn_FRAME_PARITY_ODD)
+		*parity = 'o';
+	else if (frame & UARTn_FRAME_PARITY_EVEN)
+		*parity = 'e';
+	else
+		*parity = 'n';
+
+	*bits = (frame & UARTn_FRAME_DATABITS__MASK) -
+			UARTn_FRAME_DATABITS(4) + 4;
+
+	efm_debug(efm_port, "get_opts: options=%d%c%d\n",
+			*baud, *parity, *bits);
+}
+
+static int efm32_uart_console_setup(struct console *co, char *options)
+{
+	struct efm32_uart_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_uart_ports)) {
+		unsigned i;
+		for (i = 0; i < ARRAY_SIZE(efm32_uart_ports); ++i) {
+			if (efm32_uart_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_uart_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_uart_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_uart_reg;
+
+static struct console efm32_uart_console = {
+	.name = DEV_NAME,
+	.write = efm32_uart_console_write,
+	.device = uart_console_device,
+	.setup = efm32_uart_console_setup,
+	.flags = CON_PRINTBUFFER,
+	.index = -1,
+	.data = &efm32_uart_reg,
+};
+
+#else
+#define efm32_uart_console (*(struct console *)NULL)
+#endif /* ifdef CONFIG_SERIAL_EFM32_UART_CONSOLE / else */
+
+static struct uart_driver efm32_uart_reg = {
+	.owner = THIS_MODULE,
+	.driver_name = DRIVER_NAME,
+	.dev_name = DEV_NAME,
+	.nr = ARRAY_SIZE(efm32_uart_ports),
+	.cons = &efm32_uart_console,
+};
+
+static int efm32_uart_probe_dt(struct platform_device *pdev,
+		struct efm32_uart_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_uart_probe(struct platform_device *pdev)
+{
+	struct efm32_uart_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_EFMUART;
+	efm_port->port.iotype = UPIO_MEM32;
+	efm_port->port.fifosize = 2;
+	efm_port->port.ops = &efm32_uart_pops;
+	efm_port->port.flags = UPF_BOOT_AUTOCONF;
+
+	ret = efm32_uart_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_uart_ports))
+		efm32_uart_ports[efm_port->port.line] = efm_port;
+
+	ret = uart_add_one_port(&efm32_uart_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_uart_ports))
+			efm32_uart_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_uart_remove(struct platform_device *pdev)
+{
+	struct efm32_uart_port *efm_port = platform_get_drvdata(pdev);
+
+	platform_set_drvdata(pdev, NULL);
+
+	uart_remove_one_port(&efm32_uart_reg, &efm_port->port);
+
+	if (pdev->id >= 0 && pdev->id < ARRAY_SIZE(efm32_uart_ports))
+		efm32_uart_ports[pdev->id] = NULL;
+
+	kfree(efm_port);
+
+	return 0;
+}
+
+static struct of_device_id efm32_uart_dt_ids[] = {
+	{
+		.compatible = "efm32,uart",
+	}, {
+		/* sentinel */
+	}
+};
+MODULE_DEVICE_TABLE(of, efm32_uart_dt_ids);
+
+static struct platform_driver efm32_uart_driver = {
+	.probe = efm32_uart_probe,
+	.remove = __devexit_p(efm32_uart_remove),
+
+	.driver = {
+		.name = DRIVER_NAME,
+		.owner = THIS_MODULE,
+		.of_match_table = efm32_uart_dt_ids,
+	},
+};
+
+static int __init efm32_uart_init(void)
+{
+	int ret;
+
+	ret = uart_register_driver(&efm32_uart_reg);
+	if (ret)
+		return ret;
+
+	ret = platform_driver_register(&efm32_uart_driver);
+	if (ret)
+		uart_unregister_driver(&efm32_uart_reg);
+
+	pr_info("EFM32 UART/USART driver\n");
+
+	return ret;
+}
+module_init(efm32_uart_init);
+
+static void __exit efm32_uart_exit(void)
+{
+	platform_driver_unregister(&efm32_uart_driver);
+	uart_unregister_driver(&efm32_uart_reg);
+}
+
+MODULE_AUTHOR("Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>");
+MODULE_DESCRIPTION("EFM32 UART/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..d3999ef 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_EFMUART   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

* [PATCH] jsm: Fixed EEH recovery error
From: Lucas Kannebley Tavares @ 2012-01-09 12:58 UTC (permalink / raw)
  To: Greg KH
  Cc: Thadeu Lima de Souza Cascardo, Breno Leitao, Alan Cox,
	linux-serial, linux-kernel, Breno Leitao

There was an error on the jsm driver that would cause it to be unable to
recover after a second error is detected.

At the first error, the device recovers properly:

[72521.485691] EEH: Detected PCI bus error on device 0003:02:00.0
[72521.485695] EEH: This PCI device has failed 1 times in the last hour:
...
[72532.035693] ttyn3 at MMIO 0x0 (irq = 49) is a jsm
[72532.105689] jsm: Port 3 added

However, at the second error, it cascades until EEH disables the device:

[72631.229549] Call Trace:
...
[72641.725687] jsm: Port 3 added
[72641.725695] EEH: Detected PCI bus error on device 0003:02:00.0
[72641.725698] EEH: This PCI device has failed 3 times in the last hour:

It was caused because the PCI state was not being saved after the first
restore. Therefore, at the second recovery the PCI state would not be
restored.

Signed-off-by: Lucas Kannebley Tavares <lucaskt@linux.vnet.ibm.com>
Signed-off-by: Breno Leitao <brenohl@br.ibm.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> 
---
 drivers/tty/serial/jsm/jsm_driver.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/serial/jsm/jsm_driver.c b/drivers/tty/serial/jsm/jsm_driver.c
index 7c867a0..7545fe1 100644
--- a/drivers/tty/serial/jsm/jsm_driver.c
+++ b/drivers/tty/serial/jsm/jsm_driver.c
@@ -251,6 +251,7 @@ static void jsm_io_resume(struct pci_dev *pdev)
 	struct jsm_board *brd = pci_get_drvdata(pdev);
 
 	pci_restore_state(pdev);
+	pci_save_state(pdev);
 
 	jsm_uart_port_init(brd);
 }
-- 
1.7.4.4


^ permalink raw reply related

* Re: [PATCH] serial/efm32: add new driver
From: Uwe Kleine-König @ 2012-01-09 10:34 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-kernel, Alan Cox, devicetree-discuss, Greg Kroah-Hartman,
	kernel, linux-serial
In-Reply-To: <20111223204428.GI24496@pengutronix.de>

Hello,

On Fri, Dec 23, 2011 at 09:44:28PM +0100, Uwe Kleine-König wrote:
> 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 got an answer here over the holidays and Energy Micro designed the
part.
 
> > 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.
I took that look and I don't understand what they are good for in my
case.
clock-frequency is used to initialize port->uartclk (and helps setting
up port->custom_divisor if current-speed is given). The driver I posted
uses the clk API to determine the clock frequency. So shouldn't the frequency
better be specified in the clk part of the dt? (I don't know yet how a
dt binding for clks should/can look like, so this is a bit speculative,
but I'd expect to have nothing more clk related in a device
specification but a reference to a clk definition.)

Independant of my driver I wonder if defining current-speed should also
result in

	port->flags |= UPF_SPD_CUST;

(in of_platform_serial_setup()).

Having said that and taking into account that my driver doesn't use
port->custom_divisor, do you keep suggesting that I should use
"clock-frequency" and/or "current-speed"?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply

* Kconfig option for compile time build coverage (Was: Re: [PATCH] serial/efm32: add new driver)
From: Uwe Kleine-König @ 2012-01-09  9:59 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Greg Kroah-Hartman,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-serial-u79uwXL29TY76Z2rM5mHXA, Andrew Morton, Alan Cox
In-Reply-To: <20111223204428.GI24496-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

Hello,

On Fri, Dec 23, 2011 at 09:44:28PM +0100, Uwe Kleine-König wrote:
> On Fri, Dec 23, 2011 at 10:35:22AM +0000, Arnd Bergmann wrote:
> > On Thursday 22 December 2011, Uwe Kleine-König wrote:
> > > [...]
> > > +config SERIAL_EFM32_USART
> > > +	bool "EFM32 USART port."
> > > +	depends on ARCH_EFM32
> > > +	select SERIAL_CORE
> [...]
> > 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). [...]
What do you think about this I_DO_BUILD_COVERAGE_TESTING option? It
would allow testers to get all possible options enabled (though there
will never be an EFM32 USART port on a non-EFM32 machine I guess) and
still users and distribution packagers would easily keep the option off
even without cluttering .config and {menu,n,x,whatever}config.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply

* Re: [PATCH] jsm: Fixed EEH recovery error
From: Greg KH @ 2012-01-06 21:04 UTC (permalink / raw)
  To: Lucas Kannebley Tavares
  Cc: Thadeu Lima de Souza Cascardo, Breno Leitao, Alan Cox,
	linux-serial, linux-kernel
In-Reply-To: <4F075D02.3010407@linux.vnet.ibm.com>

On Fri, Jan 06, 2012 at 06:43:46PM -0200, Lucas Kannebley Tavares wrote:
> 
> On 09/12/2011 12:35 PM, Thadeu Lima de Souza Cascardo wrote:
> >On Mon, Sep 12, 2011 at 10:36:05AM -0300, Lucas Kannebley Tavares wrote:
> >>There was an error on the jsm driver that would cause it to be unable to
> >>recover after a second error is detected.
> >>
> >>At the first error, the device recovers properly:
> >>
> >>[72521.485691] EEH: Detected PCI bus error on device 0003:02:00.0
> >>[72521.485695] EEH: This PCI device has failed 1 times in the last hour:
> >>...
> >>[72532.035693] ttyn3 at MMIO 0x0 (irq = 49) is a jsm
> >>[72532.105689] jsm: Port 3 added
> >>
> >>However, at the second error, it cascades until EEH disables the device:
> >>
> >>[72631.229549] Call Trace:
> >>...
> >>[72641.725687] jsm: Port 3 added
> >>[72641.725695] EEH: Detected PCI bus error on device 0003:02:00.0
> >>[72641.725698] EEH: This PCI device has failed 3 times in the last hour:
> >>
> >>It was caused because the PCI state was not being saved after the first
> >>restore. Therefore, at the second recovery the PCI state would not be
> >>restored.
> >>
> >>Signed-off-by: Lucas Kannebley Tavares<lucaskt@linux.vnet.ibm.com>
> >Signed-off-by: Breno Leitao <brenohl@br.ibm.com>
> >Acked-by: Thadeu Lima de Souza Cascardo<cascardo@linux.vnet.ibm.com>
> 
> Adding Greg to the CC list. It wasn't added earlier because
> get_maintainers.pl only listed Alan's name. I apologize for the
> delay.
> 
> This is a bugfix to EEH handling on jsm.

Can someone send me a patch in a format that I could actually apply it
in?

thanks,

greg k-h

^ permalink raw reply

* Re: [PATCH] jsm: Fixed EEH recovery error
From: Lucas Kannebley Tavares @ 2012-01-06 20:43 UTC (permalink / raw)
  To: Thadeu Lima de Souza Cascardo
  Cc: Breno Leitao, Alan Cox, linux-serial, linux-kernel, Greg KH
In-Reply-To: <20110912153508.GA8851@oc1711230544.ibm.com>


On 09/12/2011 12:35 PM, Thadeu Lima de Souza Cascardo wrote:
> On Mon, Sep 12, 2011 at 10:36:05AM -0300, Lucas Kannebley Tavares wrote:
>> There was an error on the jsm driver that would cause it to be unable to
>> recover after a second error is detected.
>>
>> At the first error, the device recovers properly:
>>
>> [72521.485691] EEH: Detected PCI bus error on device 0003:02:00.0
>> [72521.485695] EEH: This PCI device has failed 1 times in the last hour:
>> ...
>> [72532.035693] ttyn3 at MMIO 0x0 (irq = 49) is a jsm
>> [72532.105689] jsm: Port 3 added
>>
>> However, at the second error, it cascades until EEH disables the device:
>>
>> [72631.229549] Call Trace:
>> ...
>> [72641.725687] jsm: Port 3 added
>> [72641.725695] EEH: Detected PCI bus error on device 0003:02:00.0
>> [72641.725698] EEH: This PCI device has failed 3 times in the last hour:
>>
>> It was caused because the PCI state was not being saved after the first
>> restore. Therefore, at the second recovery the PCI state would not be
>> restored.
>>
>> Signed-off-by: Lucas Kannebley Tavares<lucaskt@linux.vnet.ibm.com>
>Signed-off-by: Breno Leitao <brenohl@br.ibm.com>
> Acked-by: Thadeu Lima de Souza Cascardo<cascardo@linux.vnet.ibm.com>

Adding Greg to the CC list. It wasn't added earlier because 
get_maintainers.pl only listed Alan's name. I apologize for the delay.

This is a bugfix to EEH handling on jsm.

>
>> ---
>>   drivers/tty/serial/jsm/jsm_driver.c |    1 +
>>   1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/tty/serial/jsm/jsm_driver.c b/drivers/tty/serial/jsm/jsm_driver.c
>> index 96da178..8941b15 100644
>> --- a/drivers/tty/serial/jsm/jsm_driver.c
>> +++ b/drivers/tty/serial/jsm/jsm_driver.c
>> @@ -270,6 +270,7 @@ static void jsm_io_resume(struct pci_dev *pdev)
>>   	struct jsm_board *brd = pci_get_drvdata(pdev);
>>
>>   	pci_restore_state(pdev);
>> +	pci_save_state(pdev);
>>
>>   	jsm_uart_port_init(brd);
>>   }
>> --
>> 1.7.4.4
>>


^ permalink raw reply

* Re: [PATCH 29/29] Drivers: tty: serial: jsm: jsm_tty: fixed a brace coding style issue
From: Lucas Kannebley Tavares @ 2012-01-06 20:08 UTC (permalink / raw)
  To: Greg KH
  Cc: Breno Leitao, Zac Storer, leitao, linux-serial, linux-kernel,
	Alan Cox
In-Reply-To: <20120106195332.GA10814@kroah.com>

On 01/06/2012 05:53 PM, Greg KH wrote:
> On Fri, Jan 06, 2012 at 05:46:17PM -0200, Lucas Kannebley Tavares wrote:
>> On 01/06/2012 04:26 PM, Lucas Kannebley Tavares wrote:
>>> On 11/18/2011 12:30 PM, Breno Leitao wrote:
>>>> On 11/18/2011 03:03 AM, Zac Storer wrote:
>>>>> Fixed a brace coding style issue.
>>>>>
>>>>> Signed-off-by: Zac Storer<zac.3.14159@gmail.com>
>>>> Acked-by: Breno Leitao<brenohl@br.ibm.com>
>>> Acked-by: Lucas Kannebley Tavares<lucaskt@linux.vnet.ibm.com>
>>>
>>
>> Adding Alan and Greg so they can catch this up on their trees.
>
> Catch what up with what?
>
> What patch is this?  Where is it?  Why wasn't it sent to me in the first
> place?
>
> Also note, the merge window for new patches to be sent to subsystem
> maintainers has been over for a week or so now, all of of the
> maintainers are now busy merging stuff with Linus, so trivial stuff like
> this is going to have to wait a few weeks at the earliest before it can
> start to be queued up.
>
> thanks,
>
> greg k-h
>

I said catch up because I didn't see it on any trees I looked and 
figured it had been passed over.
As for not sending it to you earlier, I and Breno had only replied to 
Zac's original CC list, and I only noticed you were missing now. But, as 
you've said it, it's a trivial patch, without great consequences 
(although good to have). No rush in it.

Thanks

Lucas


^ permalink raw reply

* Re: [PATCH 29/29] Drivers: tty: serial: jsm: jsm_tty: fixed a brace coding style issue
From: Greg KH @ 2012-01-06 19:53 UTC (permalink / raw)
  To: Lucas Kannebley Tavares
  Cc: Breno Leitao, Zac Storer, leitao, linux-serial, linux-kernel,
	Alan Cox
In-Reply-To: <4F074F89.6060300@linux.vnet.ibm.com>

On Fri, Jan 06, 2012 at 05:46:17PM -0200, Lucas Kannebley Tavares wrote:
> On 01/06/2012 04:26 PM, Lucas Kannebley Tavares wrote:
> >On 11/18/2011 12:30 PM, Breno Leitao wrote:
> >>On 11/18/2011 03:03 AM, Zac Storer wrote:
> >>>Fixed a brace coding style issue.
> >>>
> >>>Signed-off-by: Zac Storer<zac.3.14159@gmail.com>
> >>Acked-by: Breno Leitao<brenohl@br.ibm.com>
> >Acked-by: Lucas Kannebley Tavares<lucaskt@linux.vnet.ibm.com>
> >
> 
> Adding Alan and Greg so they can catch this up on their trees.

Catch what up with what?

What patch is this?  Where is it?  Why wasn't it sent to me in the first
place?

Also note, the merge window for new patches to be sent to subsystem
maintainers has been over for a week or so now, all of of the
maintainers are now busy merging stuff with Linus, so trivial stuff like
this is going to have to wait a few weeks at the earliest before it can
start to be queued up.

thanks,

greg k-h

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox