* [PATCH] tty: serial: altera_uart: Add CONSOLE_POLL support
From: Tobias Klauser @ 2012-02-08 13:36 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-serial
This allows altera_uart to be used for KGDB debugging over serial line.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/tty/serial/Makefile | 2 +-
drivers/tty/serial/altera_uart.c | 24 ++++++++++++++++++++++++
2 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index fee0690..d469771 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -81,12 +81,12 @@ obj-$(CONFIG_SERIAL_OF_PLATFORM) += of_serial.o
obj-$(CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL) += nwpserial.o
obj-$(CONFIG_SERIAL_KS8695) += serial_ks8695.o
obj-$(CONFIG_SERIAL_OMAP) += omap-serial.o
+obj-$(CONFIG_SERIAL_ALTERA_UART) += altera_uart.o
obj-$(CONFIG_KGDB_SERIAL_CONSOLE) += kgdboc.o
obj-$(CONFIG_SERIAL_QE) += ucc_uart.o
obj-$(CONFIG_SERIAL_TIMBERDALE) += timbuart.o
obj-$(CONFIG_SERIAL_GRLIB_GAISLER_APBUART) += apbuart.o
obj-$(CONFIG_SERIAL_ALTERA_JTAGUART) += altera_jtaguart.o
-obj-$(CONFIG_SERIAL_ALTERA_UART) += altera_uart.o
obj-$(CONFIG_SERIAL_VT8500) += vt8500_serial.o
obj-$(CONFIG_SERIAL_MRST_MAX3110) += mrst_max3110.o
obj-$(CONFIG_SERIAL_MFD_HSU) += mfd.o
diff --git a/drivers/tty/serial/altera_uart.c b/drivers/tty/serial/altera_uart.c
index 3a9cffa..fefaa4c 100644
--- a/drivers/tty/serial/altera_uart.c
+++ b/drivers/tty/serial/altera_uart.c
@@ -377,6 +377,26 @@ static int altera_uart_verify_port(struct uart_port *port,
return 0;
}
+#ifdef CONFIG_CONSOLE_POLL
+static int altera_uart_poll_get_char(struct uart_port *port)
+{
+ while (!(altera_uart_readl(port, ALTERA_UART_STATUS_REG) &
+ ALTERA_UART_STATUS_RRDY_MSK))
+ cpu_relax();
+
+ return altera_uart_readl(port, ALTERA_UART_RXDATA_REG);
+}
+
+static void altera_uart_poll_put_char(struct uart_port *port, unsigned char c)
+{
+ while (!(altera_uart_readl(port, ALTERA_UART_STATUS_REG) &
+ ALTERA_UART_STATUS_TRDY_MSK))
+ cpu_relax();
+
+ altera_uart_writel(port, c, ALTERA_UART_TXDATA_REG);
+}
+#endif
+
/*
* Define the basic serial functions we support.
*/
@@ -397,6 +417,10 @@ static struct uart_ops altera_uart_ops = {
.release_port = altera_uart_release_port,
.config_port = altera_uart_config_port,
.verify_port = altera_uart_verify_port,
+#ifdef CONFIG_CONSOLE_POLL
+ .poll_get_char = altera_uart_poll_get_char,
+ .poll_put_char = altera_uart_poll_put_char,
+#endif
};
static struct altera_uart altera_uart_ports[CONFIG_SERIAL_ALTERA_UART_MAXPORTS];
--
1.7.5.4
^ permalink raw reply related
* [PATCH] tty: serial: altera_uart: remove early_altera_uart_setup
From: Tobias Klauser @ 2012-02-08 13:35 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-serial
The function has no users inside the tree and the nios2
(out-of-mainline) port doesn't use it either (anymore).
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/tty/serial/altera_uart.c | 23 -----------------------
include/linux/altera_uart.h | 4 ----
2 files changed, 0 insertions(+), 27 deletions(-)
diff --git a/drivers/tty/serial/altera_uart.c b/drivers/tty/serial/altera_uart.c
index bde59d1..5ef414c 100644
--- a/drivers/tty/serial/altera_uart.c
+++ b/drivers/tty/serial/altera_uart.c
@@ -406,29 +406,6 @@ static struct altera_uart altera_uart_ports[CONFIG_SERIAL_ALTERA_UART_MAXPORTS];
#if defined(CONFIG_SERIAL_ALTERA_UART_CONSOLE)
-int __init early_altera_uart_setup(struct altera_uart_platform_uart *platp)
-{
- struct uart_port *port;
- int i;
-
- for (i = 0; i < CONFIG_SERIAL_ALTERA_UART_MAXPORTS && platp[i].mapbase; i++) {
- port = &altera_uart_ports[i].port;
-
- port->line = i;
- port->type = PORT_ALTERA_UART;
- port->mapbase = platp[i].mapbase;
- port->membase = ioremap(port->mapbase, ALTERA_UART_SIZE);
- port->iotype = SERIAL_IO_MEM;
- port->irq = platp[i].irq;
- port->uartclk = platp[i].uartclk;
- port->flags = UPF_BOOT_AUTOCONF;
- port->ops = &altera_uart_ops;
- port->private_data = platp;
- }
-
- return 0;
-}
-
static void altera_uart_console_putc(struct uart_port *port, const char c)
{
while (!(altera_uart_readl(port, ALTERA_UART_STATUS_REG) &
diff --git a/include/linux/altera_uart.h b/include/linux/altera_uart.h
index a10a907..c022c82 100644
--- a/include/linux/altera_uart.h
+++ b/include/linux/altera_uart.h
@@ -5,8 +5,6 @@
#ifndef __ALTUART_H
#define __ALTUART_H
-#include <linux/init.h>
-
struct altera_uart_platform_uart {
unsigned long mapbase; /* Physical address base */
unsigned int irq; /* Interrupt vector */
@@ -14,6 +12,4 @@ struct altera_uart_platform_uart {
unsigned int bus_shift; /* Bus shift (address stride) */
};
-int __init early_altera_uart_setup(struct altera_uart_platform_uart *platp);
-
#endif /* __ALTUART_H */
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] serial: relocate remaining serial drivers from tty/ to tty/serial/
From: Paul Gortmaker @ 2012-02-08 13:58 UTC (permalink / raw)
To: Jiri Slaby
Cc: Alan Cox, Sam Ravnborg, Arnd Bergmann, Greg Kroah-Hartman,
Jiri Slaby, linux-serial, linux-kernel
In-Reply-To: <4F324F4B.3090500@gmail.com>
On 12-02-08 05:32 AM, Jiri Slaby wrote:
> Damnit! They didn't manage to forward Greg's email. What a crap.
>
> On 02/08/2012 11:30 AM, Jiri Slaby wrote:
>> On 01/06/2012 12:21 AM, Paul Gortmaker wrote:
>>> --- /dev/null
>>> +++ b/drivers/tty/serial/8250/Makefile
>>> @@ -0,0 +1,20 @@
>>> +#
>>> +# Makefile for the 8250 serial device drivers.
>>> +#
>>> +
>>> +obj-$(CONFIG_SERIAL_8250) += 8250.o
>>> +obj-$(CONFIG_SERIAL_8250_PNP) += 8250_pnp.o
>>> +obj-$(CONFIG_SERIAL_8250_GSC) += 8250_gsc.o
>>> +obj-$(CONFIG_SERIAL_8250_PCI) += 8250_pci.o
>>> +obj-$(CONFIG_SERIAL_8250_HP300) += 8250_hp300.o
>>> +obj-$(CONFIG_SERIAL_8250_CS) += serial_cs.o
>>> +obj-$(CONFIG_SERIAL_8250_ACORN) += 8250_acorn.o
>>> +obj-$(CONFIG_SERIAL_8250_CONSOLE) += 8250_early.o
>>> +obj-$(CONFIG_SERIAL_8250_FOURPORT) += 8250_fourport.o
>>> +obj-$(CONFIG_SERIAL_8250_ACCENT) += 8250_accent.o
>>> +obj-$(CONFIG_SERIAL_8250_BOCA) += 8250_boca.o
>>> +obj-$(CONFIG_SERIAL_8250_EXAR_ST16C554) += 8250_exar_st16c554.o
>>> +obj-$(CONFIG_SERIAL_8250_HUB6) += 8250_hub6.o
>>> +obj-$(CONFIG_SERIAL_8250_MCA) += 8250_mca.o
>>> +obj-$(CONFIG_SERIAL_8250_FSL) += 8250_fsl.o
>>> +obj-$(CONFIG_SERIAL_8250_DW) += 8250_dw.o
>>
>> ...
>>
>>> diff --git a/drivers/tty/serial/m32r_sio.c b/drivers/tty/serial/8250/m32r_sio.c
>>> similarity index 100%
>>> rename from drivers/tty/serial/m32r_sio.c
>>> rename to drivers/tty/serial/8250/m32r_sio.c
>>> diff --git a/drivers/tty/serial/m32r_sio.h b/drivers/tty/serial/8250/m32r_sio.h
>>> similarity index 100%
>>> rename from drivers/tty/serial/m32r_sio.h
>>> rename to drivers/tty/serial/8250/m32r_sio.h
>>> diff --git a/drivers/tty/serial/m32r_sio_reg.h b/drivers/tty/serial/8250/m32r_sio_reg.h
>>> similarity index 100%
>>> rename from drivers/tty/serial/m32r_sio_reg.h
>>> rename to drivers/tty/serial/8250/m32r_sio_reg.h
>>
>> Hmm, these cannot be built now :(. Why did you move them?
As near as I can tell, I think I got misled by the comment
in the m32r register file:
* These are the UART port assignments, expressed as offsets from the base
* register. These assignments should hold for any serial port based on
* a 8250, 16450, or 16550(A).
But you are right, they should not have been caught up
in the move. I'll send a fix... Sorry about the hassle.
P.
>>
>> It looks like they should be moved back.
>>
>> regards,
^ permalink raw reply
* Re: [PATCH] serial: relocate remaining serial drivers from tty/ to tty/serial/
From: Paul Gortmaker @ 2012-02-08 14:12 UTC (permalink / raw)
To: Jiri Slaby
Cc: Alan Cox, Sam Ravnborg, Arnd Bergmann, Greg Kroah-Hartman,
Jiri Slaby, linux-serial, linux-kernel
In-Reply-To: <4F324F4B.3090500@gmail.com>
[Re: [PATCH] serial: relocate remaining serial drivers from tty/ to tty/serial/] On 08/02/2012 (Wed 11:32) Jiri Slaby wrote:
>
> Hmm, these cannot be built now :(. Why did you move them?
>
> It looks like they should be moved back.
Once again, sorry for the brown paper bag moment. :(
Greg, can you ensure this gets applied at your earliest convenience?
Thanks a lot.
Paul.
---
>From 309293f382ce9beef6d8a0fd8b3cedc9900f66e1 Mon Sep 17 00:00:00 2001
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Wed, 8 Feb 2012 09:05:42 -0500
Subject: [PATCH] m32r: relocate drivers back out of 8250 dir
Commit 9bef3d4197379a995fa80f81950bbbf8d32e9e8b
"serial: group all the 8250 related code together"
inadvertently swept up the m32r driver in the move, because
it had comments mentioning 8250 registers within it. However
these are only there by nature of the driver being based off
the 8250 source code -- the hardware itself does not actually
have any relation to the original 8250 style UARTs.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/tty/serial/{8250 => }/m32r_sio.c | 0
drivers/tty/serial/{8250 => }/m32r_sio.h | 0
drivers/tty/serial/{8250 => }/m32r_sio_reg.h | 0
3 files changed, 0 insertions(+), 0 deletions(-)
rename drivers/tty/serial/{8250 => }/m32r_sio.c (100%)
rename drivers/tty/serial/{8250 => }/m32r_sio.h (100%)
rename drivers/tty/serial/{8250 => }/m32r_sio_reg.h (100%)
diff --git a/drivers/tty/serial/8250/m32r_sio.c b/drivers/tty/serial/m32r_sio.c
similarity index 100%
rename from drivers/tty/serial/8250/m32r_sio.c
rename to drivers/tty/serial/m32r_sio.c
diff --git a/drivers/tty/serial/8250/m32r_sio.h b/drivers/tty/serial/m32r_sio.h
similarity index 100%
rename from drivers/tty/serial/8250/m32r_sio.h
rename to drivers/tty/serial/m32r_sio.h
diff --git a/drivers/tty/serial/8250/m32r_sio_reg.h b/drivers/tty/serial/m32r_sio_reg.h
similarity index 100%
rename from drivers/tty/serial/8250/m32r_sio_reg.h
rename to drivers/tty/serial/m32r_sio_reg.h
--
1.7.9
^ permalink raw reply
* Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree
From: Paul Walmsley @ 2012-02-08 15:50 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Grazvydas Ignotas, khilman, NeilBrown, govindraj.raja,
tomi.valkeinen, linux-serial, linux-omap, linux-arm-kernel
In-Reply-To: <20120204175528.GL1275@n2100.arm.linux.org.uk>
Hi
Just a quick note. Haven't had the chance to follow up on these threads
due to travel and other obligations, but plan to do so soon.
regards -
- Paul
^ permalink raw reply
* [PATCH RFC] OMAP: serial: Remove the hardcode serial_omap_console_ports array.
From: Shubhrajyoti D @ 2012-02-09 13:48 UTC (permalink / raw)
To: linux-serial; +Cc: linux-omap, linux-arm-kernel, Shubhrajyoti D, Govindraj Raja
Currently the array serial_omap_console_ports is hard coded to 4.
Make it depend on the macro OMAP_MAX_HSUART_PORTS(which is 4) which
the maximum uart count.
Cc: Govindraj Raja <govindraj.raja@ti.com>
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
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 1c24269..c570696 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1021,7 +1021,7 @@ static int serial_omap_poll_get_char(struct uart_port *port)
#ifdef CONFIG_SERIAL_OMAP_CONSOLE
-static struct uart_omap_port *serial_omap_console_ports[4];
+static struct uart_omap_port *serial_omap_console_ports[OMAP_MAX_HSUART_PORTS];
static struct uart_driver serial_omap_reg;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH RFC] OMAP: serial: Remove the hardcode serial_omap_console_ports array.
From: Govindraj @ 2012-02-09 13:58 UTC (permalink / raw)
To: Shubhrajyoti D; +Cc: linux-serial, linux-omap, linux-arm-kernel, Govindraj Raja
In-Reply-To: <1328795296-22935-1-git-send-email-shubhrajyoti@ti.com>
On Thu, Feb 9, 2012 at 7:18 PM, Shubhrajyoti D <shubhrajyoti@ti.com> wrote:
> Currently the array serial_omap_console_ports is hard coded to 4.
> Make it depend on the macro OMAP_MAX_HSUART_PORTS(which is 4) which
> the maximum uart count.
>
> Cc: Govindraj Raja <govindraj.raja@ti.com>
> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Acked-by: Govindraj.R <govindraj.raja@ti.com>
> ---
> 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 1c24269..c570696 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -1021,7 +1021,7 @@ static int serial_omap_poll_get_char(struct uart_port *port)
>
> #ifdef CONFIG_SERIAL_OMAP_CONSOLE
>
> -static struct uart_omap_port *serial_omap_console_ports[4];
> +static struct uart_omap_port *serial_omap_console_ports[OMAP_MAX_HSUART_PORTS];
>
> static struct uart_driver serial_omap_reg;
>
> --
> 1.7.1
>
> --
> 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
--
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
* [GIT PATCH] TTY/serial patches for 3.3-rc3
From: Greg KH @ 2012-02-09 20:21 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton; +Cc: linux-kernel, linux-serial
The following changes since commit 62aa2b537c6f5957afd98e29f96897419ed5ebab:
Linux 3.3-rc2 (2012-01-31 13:31:54 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-3.3-rc3
for you to fetch changes up to 197234520bd83aba2199add57a9d2678ee7f9781:
tty: serial: omap-serial: wakeup latency constraint is in microseconds, not milliseconds (2012-02-09 10:48:36 -0800)
----------------------------------------------------------------
Serial/TTY fixes for the 3.3-rc3 tree
Just a few new device ids, omap serial driver regression fixes, and a
build fix for the 8250 driver movement.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Cong Wang (1):
tty: fix a build failure on sparc
Kukjin Kim (2):
serial: samsung: Add support for EXYNOS4212 and EXYNOS4412
serial: samsung: Add support for EXYNOS5250
Paul Gortmaker (1):
m32r: relocate drivers back out of 8250 dir
Paul Walmsley (3):
tty: serial: OMAP: use a 1-byte RX FIFO threshold in PIO mode
tty: serial: OMAP: block idle while the UART is transferring data in PIO mode
tty: serial: omap-serial: wakeup latency constraint is in microseconds, not milliseconds
Samuel Thibault (1):
drivers/tty/vt/vt_ioctl.c: fix KDFONTOP 32bit compatibility layer
arch/arm/mach-omap2/serial.c | 8 +++---
drivers/tty/serial/8250/8250.c | 2 +-
drivers/tty/serial/{8250 => }/m32r_sio.c | 0
drivers/tty/serial/{8250 => }/m32r_sio.h | 0
drivers/tty/serial/{8250 => }/m32r_sio_reg.h | 0
drivers/tty/serial/omap-serial.c | 30 +++++++++++++++++++++----
drivers/tty/serial/samsung.c | 3 +-
drivers/tty/vt/vt_ioctl.c | 1 -
8 files changed, 32 insertions(+), 12 deletions(-)
rename drivers/tty/serial/{8250 => }/m32r_sio.c (100%)
rename drivers/tty/serial/{8250 => }/m32r_sio.h (100%)
rename drivers/tty/serial/{8250 => }/m32r_sio_reg.h (100%)
^ permalink raw reply
* [PATCH] ARM: OMAP2xxx: PM: fix OMAP2xxx-specific UART idle bug in v3.3
From: Paul Walmsley @ 2012-02-10 1:24 UTC (permalink / raw)
To: Tony Lindgren, Mark Brown, linux-omap, linux-arm-kernel
Cc: Arnd Bergmann, Olof Johansson, Jarkko Nikula, Greg KH,
Kevin Hilman, Grazvydas Ignotas, Russell King - ARM Linux,
linux-serial
[ This patch is targeted for v3.3-rc ]
On OMAP2420-based systems, the PM code ignores the state of the UART
functional clocks when determining what idle state to enter. This
breaks the serial port now that the UART driver's clock behavior can
be controlled via the PM autosuspend timeout.
To fix, remove the special-case idle handling for the UARTs in the
OMAP2420/2430 PM idle code added by commit
4af4016c53f52b26461b8030211f8427a58fa5ed ("OMAP3: PM: UART: disable
clocks when idle and off-mode support").
Tested on Nokia N800. This patch is a collaboration between Tony
Lindgren <tony@atomide.com> and Paul Walmsley <paul@pwsan.com>.
Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/pm24xx.c | 8 +-------
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index b8822f8..23de98d 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -82,13 +82,7 @@ static int omap2_fclks_active(void)
f1 = omap2_cm_read_mod_reg(CORE_MOD, CM_FCLKEN1);
f2 = omap2_cm_read_mod_reg(CORE_MOD, OMAP24XX_CM_FCLKEN2);
- /* Ignore UART clocks. These are handled by UART core (serial.c) */
- f1 &= ~(OMAP24XX_EN_UART1_MASK | OMAP24XX_EN_UART2_MASK);
- f2 &= ~OMAP24XX_EN_UART3_MASK;
-
- if (f1 | f2)
- return 1;
- return 0;
+ return (f1 | f2) ? 1 : 0;
}
static void omap2_enter_full_retention(void)
--
1.7.9
^ permalink raw reply related
* Re: [PATCH] ARM: OMAP2xxx: PM: fix OMAP2xxx-specific UART idle bug in v3.3
From: Tony Lindgren @ 2012-02-10 1:52 UTC (permalink / raw)
To: Paul Walmsley
Cc: Mark Brown, linux-omap, linux-arm-kernel, Arnd Bergmann,
Olof Johansson, Jarkko Nikula, Greg KH, Kevin Hilman,
Grazvydas Ignotas, Russell King - ARM Linux, linux-serial
In-Reply-To: <alpine.DEB.2.00.1202091822170.5059@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [120209 16:52]:
>
> [ This patch is targeted for v3.3-rc ]
>
> On OMAP2420-based systems, the PM code ignores the state of the UART
> functional clocks when determining what idle state to enter. This
> breaks the serial port now that the UART driver's clock behavior can
> be controlled via the PM autosuspend timeout.
>
> To fix, remove the special-case idle handling for the UARTs in the
> OMAP2420/2430 PM idle code added by commit
> 4af4016c53f52b26461b8030211f8427a58fa5ed ("OMAP3: PM: UART: disable
> clocks when idle and off-mode support").
>
> Tested on Nokia N800. This patch is a collaboration between Tony
> Lindgren <tony@atomide.com> and Paul Walmsley <paul@pwsan.com>.
Glad to see this piece of code finally gone with runtime PM :)
Applying into fixes.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH] ARM: OMAP2xxx: PM: fix OMAP2xxx-specific UART idle bug in v3.3
From: Kevin Hilman @ 2012-02-10 2:33 UTC (permalink / raw)
To: Paul Walmsley
Cc: Tony Lindgren, Mark Brown, linux-omap, linux-arm-kernel,
Arnd Bergmann, Olof Johansson, Jarkko Nikula, Greg KH,
Grazvydas Ignotas, Russell King - ARM Linux, linux-serial
In-Reply-To: <alpine.DEB.2.00.1202091822170.5059@utopia.booyaka.com>
Paul Walmsley <paul@pwsan.com> writes:
> [ This patch is targeted for v3.3-rc ]
>
> On OMAP2420-based systems, the PM code ignores the state of the UART
> functional clocks when determining what idle state to enter. This
> breaks the serial port now that the UART driver's clock behavior can
> be controlled via the PM autosuspend timeout.
>
> To fix, remove the special-case idle handling for the UARTs in the
> OMAP2420/2430 PM idle code added by commit
> 4af4016c53f52b26461b8030211f8427a58fa5ed ("OMAP3: PM: UART: disable
> clocks when idle and off-mode support").
>
> Tested on Nokia N800. This patch is a collaboration between Tony
> Lindgren <tony@atomide.com> and Paul Walmsley <paul@pwsan.com>.
>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
Acked-by: Kevin Hilman <khilman@ti.com>
^ permalink raw reply
* [PATCH RFC] OMAP: serial: Release the claimed memory region in remove
From: Shubhrajyoti D @ 2012-02-10 5:58 UTC (permalink / raw)
To: linux-serial; +Cc: linux-omap, linux-arm-kernel, Shubhrajyoti D, Govindraj.R
Currently the memory region is not released the folowing error is
observed.
/testsuites # insmod omap-serial.ko
[ 130.746917] omap_uart omap_uart.0: memory region already claimed
[ 130.753143] omap_uart: probe of omap_uart.0 failed with error -16
[ 130.759338] omap_uart omap_uart.1: memory region already claimed
[ 130.765380] omap_uart: probe of omap_uart.1 failed with error -16
[ 130.771606] omap_uart omap_uart.2: memory region already claimed
[ 130.777679] omap_uart: probe of omap_uart.2 failed with error -16
[ 130.783905] omap_uart omap_uart.3: memory region already claimed
[ 130.789947] omap_uart: probe of omap_uart.3 failed with error -16
Fix it by releasing the memory region.
Cc: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
drivers/tty/serial/omap-serial.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 130f7f8..4def6c3 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1480,6 +1480,10 @@ do_release_region:
static int serial_omap_remove(struct platform_device *dev)
{
struct uart_omap_port *up = platform_get_drvdata(dev);
+ struct resource *r;
+
+ r = platform_get_resource(dev, IORESOURCE_MEM, 0);
+ release_mem_region(r->start, resource_size(r));
if (up) {
iounmap(up->port.membase);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 3/5] omap-serial: Fix the error handling in the omap_serial probe
From: Shubhrajyoti @ 2012-02-10 6:00 UTC (permalink / raw)
To: Govindraj; +Cc: linux-serial, linux-omap, linux-arm-kernel
In-Reply-To: <4F19354A.4040707@ti.com>
On Friday 20 January 2012 03:05 PM, Shubhrajyoti wrote:
> On Friday 20 January 2012 02:19 PM, Govindraj wrote:
>> On Mon, Jan 16, 2012 at 3:52 PM, Shubhrajyoti D <shubhrajyoti@ti.com> wrote:
>>> 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 1c24269..8c6f137 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);
>> you can build omap-serial as module insmod and rmmod
>> the module and test this patch.
>>
>> This can be done on zoom board which uses a non-omap uart
>> as console.
> Yes will do that and post another version.
yes , there was a missing memory release just tested with that patch.
thanks,
>> --
>> Thanks,
>> Govindraj.R
^ permalink raw reply
* Re: [PATCH RFC] OMAP: serial: Release the claimed memory region in remove
From: Menon, Nishanth @ 2012-02-10 15:23 UTC (permalink / raw)
To: Shubhrajyoti D; +Cc: linux-serial, Govindraj.R, linux-omap, linux-arm-kernel
In-Reply-To: <1328853482-3687-1-git-send-email-shubhrajyoti@ti.com>
On Thu, Feb 9, 2012 at 23:58, Shubhrajyoti D <shubhrajyoti@ti.com> wrote:
> Currently the memory region is not released the folowing error is
> observed.
>
> /testsuites # insmod omap-serial.ko
> [ 130.746917] omap_uart omap_uart.0: memory region already claimed
> [ 130.753143] omap_uart: probe of omap_uart.0 failed with error -16
> [ 130.759338] omap_uart omap_uart.1: memory region already claimed
> [ 130.765380] omap_uart: probe of omap_uart.1 failed with error -16
> [ 130.771606] omap_uart omap_uart.2: memory region already claimed
> [ 130.777679] omap_uart: probe of omap_uart.2 failed with error -16
> [ 130.783905] omap_uart omap_uart.3: memory region already claimed
> [ 130.789947] omap_uart: probe of omap_uart.3 failed with error -16
>
> Fix it by releasing the memory region.
>
> Cc: Govindraj.R <govindraj.raja@ti.com>
> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
> ---
> drivers/tty/serial/omap-serial.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index 130f7f8..4def6c3 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -1480,6 +1480,10 @@ do_release_region:
> static int serial_omap_remove(struct platform_device *dev)
> {
> struct uart_omap_port *up = platform_get_drvdata(dev);
> + struct resource *r;
> +
> + r = platform_get_resource(dev, IORESOURCE_MEM, 0);
> + release_mem_region(r->start, resource_size(r));
if this is the same region which ioremapped to up->port.membase, then
please release mem region after the unmap.
Regards,
Nishanth Menon
>
> if (up) {
> iounmap(up->port.membase);
> --
> 1.7.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RFC] OMAP: serial: Release the claimed memory region in remove
From: Datta, Shubhrajyoti @ 2012-02-10 18:01 UTC (permalink / raw)
To: Menon, Nishanth; +Cc: linux-serial, Govindraj.R, linux-omap, linux-arm-kernel
In-Reply-To: <CAOMWX4f0Mpj=NRBXZgtLbvCg3uo+8tZY8OAkriPu2YucRGoPkw@mail.gmail.com>
On Fri, Feb 10, 2012 at 8:53 PM, Menon, Nishanth <nm@ti.com> wrote:
> On Thu, Feb 9, 2012 at 23:58, Shubhrajyoti D <shubhrajyoti@ti.com> wrote:
>> Currently the memory region is not released the folowing error is
>> observed.
>>
>> /testsuites # insmod omap-serial.ko
>> [ 130.746917] omap_uart omap_uart.0: memory region already claimed
>> [ 130.753143] omap_uart: probe of omap_uart.0 failed with error -16
>> [ 130.759338] omap_uart omap_uart.1: memory region already claimed
>> [ 130.765380] omap_uart: probe of omap_uart.1 failed with error -16
>> [ 130.771606] omap_uart omap_uart.2: memory region already claimed
>> [ 130.777679] omap_uart: probe of omap_uart.2 failed with error -16
>> [ 130.783905] omap_uart omap_uart.3: memory region already claimed
>> [ 130.789947] omap_uart: probe of omap_uart.3 failed with error -16
>>
>> Fix it by releasing the memory region.
>>
>> Cc: Govindraj.R <govindraj.raja@ti.com>
>> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
>> ---
>> drivers/tty/serial/omap-serial.c | 4 ++++
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
>> index 130f7f8..4def6c3 100644
>> --- a/drivers/tty/serial/omap-serial.c
>> +++ b/drivers/tty/serial/omap-serial.c
>> @@ -1480,6 +1480,10 @@ do_release_region:
>> static int serial_omap_remove(struct platform_device *dev)
>> {
>> struct uart_omap_port *up = platform_get_drvdata(dev);
>> + struct resource *r;
>> +
>> + r = platform_get_resource(dev, IORESOURCE_MEM, 0);
>> + release_mem_region(r->start, resource_size(r));
> if this is the same region which ioremapped to up->port.membase, then
> please release mem region after the unmap.
My bad will send an updated patch.
Thanks ,
> Regards,
> Nishanth Menon
>
>>
>> if (up) {
>> iounmap(up->port.membase);
>> --
>> 1.7.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] OMAP: serial: Release the claimed memory region in remove
From: Shubhrajyoti D @ 2012-02-11 7:33 UTC (permalink / raw)
To: linux-serial; +Cc: linux-omap, linux-arm-kernel, Shubhrajyoti D, Govindraj.R
Currently the memory region is not released the folowing error is
observed.
/testsuites # insmod omap-serial.ko
[ 130.746917] omap_uart omap_uart.0: memory region already claimed
[ 130.753143] omap_uart: probe of omap_uart.0 failed with error -16
[ 130.759338] omap_uart omap_uart.1: memory region already claimed
[ 130.765380] omap_uart: probe of omap_uart.1 failed with error -16
[ 130.771606] omap_uart omap_uart.2: memory region already claimed
[ 130.777679] omap_uart: probe of omap_uart.2 failed with error -16
[ 130.783905] omap_uart omap_uart.3: memory region already claimed
[ 130.789947] omap_uart: probe of omap_uart.3 failed with error -16
Fix it by releasing the memory region.
Cc: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
changes from the rfc version -
move the release after the unmap.
drivers/tty/serial/omap-serial.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 8c6f137..16aa4f0 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1480,9 +1480,12 @@ do_release_region:
static int serial_omap_remove(struct platform_device *dev)
{
struct uart_omap_port *up = platform_get_drvdata(dev);
+ struct resource *r;
if (up) {
iounmap(up->port.membase);
+ r = platform_get_resource(dev, IORESOURCE_MEM, 0);
+ release_mem_region(r->start, resource_size(r));
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] OMAP: serial: Release the claimed memory region in remove
From: Mark Brown @ 2012-02-11 11:27 UTC (permalink / raw)
To: Shubhrajyoti D; +Cc: linux-serial, Govindraj.R, linux-omap, linux-arm-kernel
In-Reply-To: <1328945607-4025-1-git-send-email-shubhrajyoti@ti.com>
On Sat, Feb 11, 2012 at 01:03:27PM +0530, Shubhrajyoti D wrote:
> Currently the memory region is not released the folowing error is
> observed.
> /testsuites # insmod omap-serial.ko
> [ 130.746917] omap_uart omap_uart.0: memory region already claimed
> [ 130.753143] omap_uart: probe of omap_uart.0 failed with error -16
It'd be better yet to use the devm_ functions to prevent such issues
recurring in future.
^ permalink raw reply
* Hi Dear
From: johnny @ 2012-02-14 10:30 UTC (permalink / raw)
Hello
My name is Kate i would like to be a friend with you
i have more to discuss with you once i hear from you
thanks
ms kate
==================================================
Hallo
Mein Name ist Kate Ich möchte ein Freund mit dir sein
Ich habe mehr zu besprechen mit Ihnen, sobald ich von Ihnen zu hören
dank
Frau Kate
--
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
* [PATCH] tty/serial/mux.c: linux/tty.h included twice
From: Danny Kukawka @ 2012-02-15 17:55 UTC (permalink / raw)
To: Alan Cox; +Cc: Danny Kukawka, Greg Kroah-Hartman, linux-serial, linux-kernel
drivers/tty/serial/mux.c included 'linux/tty.h' twice, remove
the duplicate.
Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
---
drivers/tty/serial/mux.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/mux.c b/drivers/tty/serial/mux.c
index 06f6aef..d080bc5 100644
--- a/drivers/tty/serial/mux.c
+++ b/drivers/tty/serial/mux.c
@@ -17,7 +17,6 @@
*/
#include <linux/module.h>
-#include <linux/tty.h>
#include <linux/ioport.h>
#include <linux/init.h>
#include <linux/serial.h>
--
1.7.8.3
^ permalink raw reply related
* [PATCH] amba-pl011/dma: Add check for the residue in DMA callback
From: Chanho Min @ 2012-02-16 2:44 UTC (permalink / raw)
To: Russell King, Alan Cox, Greg Kroah-Hartman; +Cc: linux-serial, linux-kernel
In DMA-operated uart, I found that rx data can be taken by the UART
interrupts during
the DMA irq handler. pl011_int is occurred just before it goes inside
spin_lock_irq.
When it returns to the callback, DMA buffer already has been flushed.
Then, pl011_dma_rx_chars
gets invalid data. So I add check for the residue as the patch bellow.
Signed-off-by: Chanho Min <chanho.min@lge.com>
---
drivers/tty/serial/amba-pl011.c | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 6800f5f..cc3ea06 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -827,7 +827,12 @@ static void pl011_dma_rx_callback(void *data)
{
struct uart_amba_port *uap = data;
struct pl011_dmarx_data *dmarx = &uap->dmarx;
+ struct dma_chan *rxchan = dmarx->chan;
bool lastbuf = dmarx->use_buf_b;
+ struct pl011_sgbuf *sgbuf = dmarx->use_buf_b ?
+ &dmarx->sgbuf_b : &dmarx->sgbuf_a;
+ size_t pending;
+ struct dma_tx_state state;
int ret;
/*
@@ -838,11 +843,21 @@ static void pl011_dma_rx_callback(void *data)
* we immediately trigger the next DMA job.
*/
spin_lock_irq(&uap->port.lock);
+ /*
+ * Rx data can be taken by the UART interrupts during
+ * the DMA irq handler. So we check the residue here.
+ */
+ rxchan->device->device_tx_status(rxchan, dmarx->cookie, &state);
+ pending = sgbuf->sg.length - state.residue;
+ BUG_ON(pending > PL011_DMA_BUFFER_SIZE);
+ /* Then we terminate the transfer - we now know our residue */
+ dmaengine_terminate_all(rxchan);
+
uap->dmarx.running = false;
dmarx->use_buf_b = !lastbuf;
ret = pl011_dma_rx_trigger_dma(uap);
- pl011_dma_rx_chars(uap, PL011_DMA_BUFFER_SIZE, lastbuf, false);
+ pl011_dma_rx_chars(uap, pending, lastbuf, false);
spin_unlock_irq(&uap->port.lock);
/*
* Do this check after we picked the DMA chars so we don't
--
1.7.0.4
^ permalink raw reply related
* [PATCH] serial/sirf: fixup for changes to pin control
From: Linus Walleij @ 2012-02-16 18:43 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: Stephen Warren, Shawn Guo, Thomas Abraham, Dong Aisheng,
Rajendra Nayak, Haojian Zhuang, Barry Song, Tony Lindgren,
Linus Walleij, linux-serial
We changed the signature of the pin multiplexing functions to
handle any pin business, so fix up the Sirf driver to call this
new interface and rename some variables to make the semantics
understandable.
Cc: linux-serial@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/tty/serial/sirfsoc_uart.c | 20 ++++++++++----------
drivers/tty/serial/sirfsoc_uart.h | 2 +-
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/serial/sirfsoc_uart.c b/drivers/tty/serial/sirfsoc_uart.c
index a60523f..c1a871e 100644
--- a/drivers/tty/serial/sirfsoc_uart.c
+++ b/drivers/tty/serial/sirfsoc_uart.c
@@ -22,7 +22,7 @@
#include <linux/io.h>
#include <asm/irq.h>
#include <asm/mach/irq.h>
-#include <linux/pinctrl/pinmux.h>
+#include <linux/pinctrl/consumer.h>
#include "sirfsoc_uart.h"
@@ -673,12 +673,12 @@ int sirfsoc_uart_probe(struct platform_device *pdev)
port->irq = res->start;
if (sirfport->hw_flow_ctrl) {
- sirfport->pmx = pinmux_get(&pdev->dev, NULL);
- ret = IS_ERR(sirfport->pmx);
+ sirfport->p = pinctrl_get(&pdev->dev, NULL);
+ ret = IS_ERR(sirfport->p);
if (ret)
- goto pmx_err;
+ goto pin_err;
- pinmux_enable(sirfport->pmx);
+ pinctrl_enable(sirfport->p);
}
port->ops = &sirfsoc_uart_ops;
@@ -696,10 +696,10 @@ int sirfsoc_uart_probe(struct platform_device *pdev)
port_err:
platform_set_drvdata(pdev, NULL);
if (sirfport->hw_flow_ctrl) {
- pinmux_disable(sirfport->pmx);
- pinmux_put(sirfport->pmx);
+ pinctrl_disable(sirfport->p);
+ pinctrl_put(sirfport->p);
}
-pmx_err:
+pin_err:
irq_err:
devm_iounmap(&pdev->dev, port->membase);
err:
@@ -712,8 +712,8 @@ static int sirfsoc_uart_remove(struct platform_device *pdev)
struct uart_port *port = &sirfport->port;
platform_set_drvdata(pdev, NULL);
if (sirfport->hw_flow_ctrl) {
- pinmux_disable(sirfport->pmx);
- pinmux_put(sirfport->pmx);
+ pinctrl_disable(sirfport->p);
+ pinctrl_put(sirfport->p);
}
devm_iounmap(&pdev->dev, port->membase);
uart_remove_one_port(&sirfsoc_uart_drv, port);
diff --git a/drivers/tty/serial/sirfsoc_uart.h b/drivers/tty/serial/sirfsoc_uart.h
index fc64260..6e207fd 100644
--- a/drivers/tty/serial/sirfsoc_uart.h
+++ b/drivers/tty/serial/sirfsoc_uart.h
@@ -162,7 +162,7 @@ struct sirfsoc_uart_port {
unsigned char ms_enabled;
struct uart_port port;
- struct pinmux *pmx;
+ struct pinctrl *p;
};
/* Hardware Flow Control */
--
1.7.7.6
^ permalink raw reply related
* RE: [PATCH] serial/sirf: fixup for changes to pin control
From: Stephen Warren @ 2012-02-16 19:01 UTC (permalink / raw)
To: Linus Walleij, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Shawn Guo, Thomas Abraham, Dong Aisheng, Rajendra Nayak,
Haojian Zhuang, Barry Song, Tony Lindgren,
linux-serial@vger.kernel.org
In-Reply-To: <1329417828-6005-1-git-send-email-linus.walleij@linaro.org>
Linus Walleij wrote at Thursday, February 16, 2012 11:44 AM:
> We changed the signature of the pin multiplexing functions to
> handle any pin business, so fix up the Sirf driver to call this
> new interface and rename some variables to make the semantics
> understandable.
>
> Cc: linux-serial@vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Looks good to me for now.
I'll have to do another similar change when I implement the pinctrl_get
API changes we discussed at Linaro Connect (I should start implementing
that today), but I guess that's no big deal.
Should this patch be put into the pinctrl tree since that's where the
API changed, perhaps even squashed into the original commit to avoid
git bisect breakage, unless your branch needs to be stable? Otherwise,
this change will conflict with my future similar change if pulled for
the same kernel version.
--
nvpublic
^ permalink raw reply
* Re: [PATCH] serial/sirf: fixup for changes to pin control
From: Linus Walleij @ 2012-02-16 19:39 UTC (permalink / raw)
To: Stephen Warren
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Shawn Guo, Thomas Abraham,
Dong Aisheng, Rajendra Nayak, Haojian Zhuang, Barry Song,
Tony Lindgren, linux-serial@vger.kernel.org
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF1790EC8791@HQMAIL01.nvidia.com>
On Thu, Feb 16, 2012 at 8:01 PM, Stephen Warren <swarren@nvidia.com> wrote:
> Should this patch be put into the pinctrl tree since that's where the
> API changed, perhaps even squashed into the original commit to avoid
> git bisect breakage, unless your branch needs to be stable?
Hm yeah I will for sure put it into the pinctrl tree.
The Sirf doesn't even have a defconfig so it was just my memory of
the Sirf that got me to remember it. I might squash if I don't get any
comments on this patch.
> Otherwise,
> this change will conflict with my future similar change if pulled for
> the same kernel version.
It'll be in linux-next tomorrow or so.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] serial/sirf: fixup for changes to pin control
From: Greg KH @ 2012-02-16 19:48 UTC (permalink / raw)
To: Linus Walleij
Cc: Stephen Warren, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Shawn Guo, Thomas Abraham,
Dong Aisheng, Rajendra Nayak, Haojian Zhuang, Barry Song,
Tony Lindgren, linux-serial@vger.kernel.org
In-Reply-To: <CACRpkdavPdK13cJ-mdDXwbz3jNCSCzaa8LTdMDXOy4mi+pmdmw@mail.gmail.com>
On Thu, Feb 16, 2012 at 08:39:39PM +0100, Linus Walleij wrote:
> On Thu, Feb 16, 2012 at 8:01 PM, Stephen Warren <swarren@nvidia.com> wrote:
>
> > Should this patch be put into the pinctrl tree since that's where the
> > API changed, perhaps even squashed into the original commit to avoid
> > git bisect breakage, unless your branch needs to be stable?
>
> Hm yeah I will for sure put it into the pinctrl tree.
Great, please feel free to add:
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* pch_uart and pch_phub clock selection
From: Darren Hart @ 2012-02-17 0:57 UTC (permalink / raw)
To: lkml, ; +Cc: Arnd Bergmann, Greg Kroah-Hartman, Alan Cox, linux-serial
I'm working on a tunnel creek (atom e6xx + topcliff PCH) development platform
that uses a 48MHz or 64MHz clock to drive the pch_uart. I've found that if I
force the uart_clock to 48MHz (or 64MHz on the latest rev) I can get the kernel
messages and getty on the serial port.
I see that the the CM-iTC board is special-cased to set a 192MHz uart_clock.
This is done in pch_uart.c code, but there is some register manipulation done in
the pch_phub.c driver and I don't understand the connection. How are the two
related?
Is the pch_phub.c register manipulation required for proper related? It seems to
work without touching those registers if I just force the clock.
The device I'm working with is EFI, and the dmi_get_system_info(DMI_BOARD_NAME)
returns "(null)", so I can't use the same test to identify this board. Is there
another common mechanism I might be able to use?
The following patch (by way of example, not meant for inclusion) gets things
working for this particular board with this command line:
console=ttyPCH1,115200 pch_uart.clock_param=48000000
I believe the right thing to do here is to discover a way to identify the board
and special case the clock as is done for the CM-iTC, but I would like to
understand the purpose of the pch_phub register manipulation code. Does this
make sense?
Thanks,
Darren
>From f83fa6cb575844d8e37f136890fe32258eb88dd2 Mon Sep 17 00:00:00 2001
Message-Id: <f83fa6cb575844d8e37f136890fe32258eb88dd2.1329439822.git.dvhart@linux.intel.com>
From: Darren Hart <dvhart@linux.intel.com>
Date: Wed, 15 Feb 2012 15:44:18 -0800
Subject: [PATCH] pch_uart: Add clock parameter
Allow for the specification of the clock as a module parameter. This is useful
when a board uses a non-standard clock, or when different versions of a board
use different clocks, and that board name or the version are not available to
the kernel.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
---
drivers/tty/serial/pch_uart.c | 29 +++++++++++++++++------------
1 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/tty/serial/pch_uart.c b/drivers/tty/serial/pch_uart.c
index 17ae657..8f192b9 100644
--- a/drivers/tty/serial/pch_uart.c
+++ b/drivers/tty/serial/pch_uart.c
@@ -203,7 +203,7 @@ enum {
#define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
-#define DEFAULT_BAUD_RATE 1843200 /* 1.8432MHz */
+#define DEFAULT_UART_CLOCK 1843200 /* 1.8432MHz */
struct pch_uart_buffer {
unsigned char *buf;
@@ -218,7 +218,7 @@ struct eg20t_port {
unsigned int iobase;
struct pci_dev *pdev;
int fifo_size;
- int base_baud;
+ int uart_clock;
int start_tx;
int start_rx;
int tx_empty;
@@ -287,13 +287,14 @@ static struct pch_uart_driver_data drv_dat[] = {
static struct eg20t_port *pch_uart_ports[PCH_UART_NR];
#endif
static unsigned int default_baud = 9600;
+static unsigned int clock_param = 0;
static const int trigger_level_256[4] = { 1, 64, 128, 224 };
static const int trigger_level_64[4] = { 1, 16, 32, 56 };
static const int trigger_level_16[4] = { 1, 4, 8, 14 };
static const int trigger_level_1[4] = { 1, 1, 1, 1 };
static void pch_uart_hal_request(struct pci_dev *pdev, int fifosize,
- int base_baud)
+ int uart_clock)
{
struct eg20t_port *priv = pci_get_drvdata(pdev);
@@ -332,7 +333,7 @@ static int pch_uart_hal_set_line(struct eg20t_port *priv, int baud,
unsigned int dll, dlm, lcr;
int div;
- div = DIV_ROUND_CLOSEST(priv->base_baud / 16, baud);
+ div = DIV_ROUND_CLOSEST(priv->uart_clock / 16, baud);
if (div < 0 || USHRT_MAX <= div) {
dev_err(priv->port.dev, "Invalid Baud(div=0x%x)\n", div);
return -EINVAL;
@@ -1153,9 +1154,9 @@ static int pch_uart_startup(struct uart_port *port)
priv->tx_empty = 1;
if (port->uartclk)
- priv->base_baud = port->uartclk;
+ priv->uart_clock = port->uartclk;
else
- port->uartclk = priv->base_baud;
+ port->uartclk = priv->uart_clock;
pch_uart_hal_disable_interrupt(priv, PCH_UART_HAL_ALL_INT);
ret = pch_uart_hal_set_line(priv, default_baud,
@@ -1507,7 +1508,7 @@ static int __init pch_console_setup(struct console *co, char *options)
return -ENODEV;
/* setup uartclock */
- port->uartclk = DEFAULT_BAUD_RATE;
+ port->uartclk = clock_param ? clock_param : DEFAULT_UART_CLOCK;
if (options)
uart_parse_options(options, &baud, &parity, &bits, &flow);
@@ -1550,7 +1551,7 @@ static struct eg20t_port *pch_uart_init_port(struct pci_dev *pdev,
unsigned int iobase;
unsigned int mapbase;
unsigned char *rxbuf;
- int fifosize, base_baud;
+ int fifosize, uart_clock;
int port_type;
struct pch_uart_driver_data *board;
const char *board_name;
@@ -1566,12 +1567,15 @@ static struct eg20t_port *pch_uart_init_port(struct pci_dev *pdev,
if (!rxbuf)
goto init_port_free_txbuf;
- base_baud = DEFAULT_BAUD_RATE;
+ uart_clock = DEFAULT_UART_CLOCK;
/* quirk for CM-iTC board */
board_name = dmi_get_system_info(DMI_BOARD_NAME);
if (board_name && strstr(board_name, "CM-iTC"))
- base_baud = 192000000; /* 192.0MHz */
+ uart_clock = 192000000; /* 192.0MHz */
+
+ /* The module parameter overrides default and system quirks. */
+ uart_clock = clock_param ? clock_param : uart_clock;
switch (port_type) {
case PORT_UNKNOWN:
@@ -1597,7 +1601,7 @@ static struct eg20t_port *pch_uart_init_port(struct pci_dev *pdev,
priv->rxbuf.size = PAGE_SIZE;
priv->fifo_size = fifosize;
- priv->base_baud = base_baud;
+ priv->uart_clock = uart_clock;
priv->port_type = PORT_MAX_8250 + port_type + 1;
priv->port.dev = &pdev->dev;
priv->port.iobase = iobase;
@@ -1614,7 +1618,7 @@ static struct eg20t_port *pch_uart_init_port(struct pci_dev *pdev,
spin_lock_init(&priv->port.lock);
pci_set_drvdata(pdev, priv);
- pch_uart_hal_request(pdev, fifosize, base_baud);
+ pch_uart_hal_request(pdev, fifosize, uart_clock);
#ifdef CONFIG_SERIAL_PCH_UART_CONSOLE
pch_uart_ports[board->line_no] = priv;
@@ -1785,3 +1789,4 @@ module_exit(pch_uart_module_exit);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("Intel EG20T PCH UART PCI Driver");
module_param(default_baud, uint, S_IRUGO);
+module_param(clock_param, uint, S_IRUGO);
--
1.7.6.5
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply related
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