* Re: [PATCH] amba-pl011/dma: Add check for the residue in DMA callback
From: Linus Walleij @ 2012-02-20 8:31 UTC (permalink / raw)
To: Chanho Min
Cc: Russell King, Per Forlin, Alan Cox, linux-serial, linux-kernel,
Rabin VINCENT
In-Reply-To: <CAOAMb1BoEJWjU9he=xr2irCyDVwDUPmhihQyPc_n3t8HbegLDw@mail.gmail.com>
On Mon, Feb 20, 2012 at 2:24 AM, Chanho Min <chanho0207@gmail.com> wrote:
> 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>
Looks correct!
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Thanks,
Linus Walleij
^ permalink raw reply
* Transfer Notice!!
From: Western Union Outlet @ 2012-02-20 8:50 UTC (permalink / raw)
To: Recipients
Dear Beneficiary.
We write to inform you that we have transferred USD$400,000.00 dollars, I could have called you via phone to give you the MTCN information but we lost your contact phone number. So, I decided to email you the information so that you can start cashing your money in USD5000.00 daily installment with the same MTCN and sender's name which will be valid for 20 days until you cash the full $400,000.00usd as it automatically activates for use for 20 days after the first reactivation.
The money is available for pick up which was deposited for transfer to you by MR Bernard Harry from United Nation Trust Funds. The money is available for pick up by receiver (you) but when you track it, it will display PICKED UP due to the fact that it has been deactivated from our head office for security reason because it has stayed too long in the air as we have been trying to reach you on the phone for some days now but it was not reachable,so it was blocked.
Therefore you can not cash it out in any western union office due to its restriction from our head office,which was a security measure because the money has been in the air for three days now and maybe in danger, hence the mtcn has to be reactivated to enable you cash out the money in any western union office in your area, the reactivation of the MTCN will cost you a token of $155, once this is paid, our head office will release the fund on hold to enable you cash it.To be sure of this please log on to www.westernunion.com and click on track to and enter the sender's info and mtcn below.
Sender's Fist name: Abraham
Sender's Last Name: Elizabeth
MTCN: 5801913322
Question: Who Is Great
Answer: God
Amount: $5000.00USD
Total Amount To be Cashed: $400,000.00Usd
Please also send to us the following details..
1,Re-Comfirm Your Contact Phone Number.................
With due respect please get back to me urgently after tracking the money on-line so i can instruct you on how to send the $155 to us for the reactivation of the MTCN.
Best Regards
Mr.Smith Mcferrin.
Outlet Manager,
Western Union Money Transfer.
^ permalink raw reply
* Re: [PATCH 2/3] tty: serial: OMAP: block idle while the UART is transferring data in PIO mode
From: Cousson, Benoit @ 2012-02-20 12:35 UTC (permalink / raw)
To: Paul Walmsley
Cc: linux-omap, linux-serial, linux-arm-kernel, Kevin Hilman,
Govindraj.R, Greg Kroah-Hartman, Alan Cox, Tomi Valkeinen,
Nayak, Rajendra
In-Reply-To: <20120126025036.31613.67819.stgit@dusk>
+ Rajendra
Hi Paul,
3.3-rc4 is broken in the DT case because of the serial driver. And it looks like it is due to this fix.
We cannot rely on pdata anymore in DT, and in that case it leads to an Oops due to NULL pdata.
[ 2.120605] Unable to handle kernel NULL pointer dereference at virtual address 00000028
[ 2.120605] pgd = ed568000
[ 2.131958] [00000028] *pgd=ad73f831, *pte=00000000, *ppte=00000000
[ 2.131958] Internal error: Oops: 17 [#1] SMP
[ 2.131958] Modules linked in:
[ 2.131958] CPU: 1 Not tainted (3.3.0-rc4-00001-g6851380-dirty #244)
[ 2.153350] PC is at serial_omap_start_tx+0x1c0/0x20c
[ 2.153350] LR is at serial_omap_start_tx+0x1b8/0x20c
[ 2.153350] pc : [<c02b4244>] lr : [<c02b423c>] psr: 60000193
[ 2.163940] sp : ed579e68 ip : c07024b0 fp : a0000113
[ 2.163940] r10: ed780800 r9 : ed6aca00 r8 : 00000017
[ 2.163940] r7 : 00000004 r6 : 00000007 r5 : 00000000 r4 : ed6aca00
[ 2.188262] r3 : ef0ef540 r2 : fa020000 r1 : 00000000 r0 : c02b423c
[ 2.188262] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
[ 2.188262] Control: 10c53c7d Table: ad56804a DAC: 00000015
[ 2.188262] Process rcS (pid: 494, stack limit = 0xed5782f8)
[ 2.214630] Stack: (0xed579e68 to 0xed57a000)
[ 2.214630] 9e60: ed6aca00 ed780800 a0000113 c0476f94 00000002 ed6aca00
[ 2.227752] 9e80: ed780800 20000113 00000000 c02ac2ec 60000193 c02acbd4 00000000 ed6a22d0
[ 2.236328] 9ea0: ef0bf017 c02ae270 00000017 ed780800 ed780cfc 00000017 ef0bf000 ed578000
[ 2.236328] 9ec0: c049dde8 ef0b5380 00000000 c0297488 60000113 c0292f84 ef0bf000 ed780994
[ 2.236328] 9ee0: ef0003c0 00000000 ef0ef540 c0073cfc ed7809b4 ed7809b4 ed780cb4 ef0b5380
[ 2.236328] 9f00: ed780800 b6f15000 00000017 ed578000 00000400 00000000 00000000 c0292fd0
[ 2.236328] 9f20: c06e413c 00000017 c02972b4 ed778800 ed579f80 ed578000 00000000 ef0b5380
[ 2.236328] 9f40: 00000017 b6f15000 ed579f80 00000017 ed578000 00000000 b6f16000 c0107df8
[ 2.287750] 9f60: c0013ec0 ef0ef540 ef0b5380 b6f15000 00000000 00000000 00000017 c0108080
[ 2.287750] 9f80: 00000000 00000000 b6e47600 00000000 00000017 b6f15000 b6e47600 00000004
[ 2.287750] 9fa0: c0013f68 c0013da0 00000017 b6f15000 00000001 b6f15000 00000017 00000000
[ 2.287750] 9fc0: 00000017 b6f15000 b6e47600 00000004 00000017 00000000 00000001 b6f16000
[ 2.287750] 9fe0: b6f15000 beb025d8 b6d8d120 b6ddb1bc 60000110 00000001 0da805a1 84808223
[ 2.330627] [<c02b4244>] (serial_omap_start_tx+0x1c0/0x20c) from [<c02ac2ec>] (__uart_start+0x40/0x44)
[ 2.330627] [<c02ac2ec>] (__uart_start+0x40/0x44) from [<c02acbd4>] (uart_start+0x24/0x34)
[ 2.340393] [<c02acbd4>] (uart_start+0x24/0x34) from [<c02ae270>] (uart_write+0xc0/0xe4)
[ 2.349060] [<c02ae270>] (uart_write+0xc0/0xe4) from [<c0297488>] (n_tty_write+0x1d4/0x404)
[ 2.349060] [<c0297488>] (n_tty_write+0x1d4/0x404) from [<c0292fd0>] (tty_write+0x138/0x22c)
[ 2.366302] [<c0292fd0>] (tty_write+0x138/0x22c) from [<c0107df8>] (vfs_write+0xb4/0x148)
[ 2.366302] [<c0107df8>] (vfs_write+0xb4/0x148) from [<c0108080>] (sys_write+0x40/0x70)
[ 2.366302] [<c0108080>] (sys_write+0x40/0x70) from [<c0013da0>] (ret_fast_syscall+0x0/0x3c)
I guess we should stop accessing the pdata from the driver except during probe and populate the needed information inside the drvdata instead.
And then we will have to add the support for all these OMAP custom hooks without pdata.
A basic fix (below) for the moment is to test for valid pdata inside the driver.
I'll repost it properly if you are fine with it.
Regards,
Benoit
---
>From af9f18e15e0ef0e227b3efa42489b7bd8a20c2a9 Mon Sep 17 00:00:00 2001
From: Benoit Cousson <b-cousson@ti.com>
Date: Mon, 20 Feb 2012 12:19:24 +0100
Subject: [PATCH] tty: serial: OMAP: Fix oops due to NULL pdata in DT boot
The following commit: be4b0281956c5cae4f63f31f11d07625a6988766
(tty: serial: OMAP: block idle while the UART is transferring data in PIO mode),
is introducing a oops if OMAP is booted using device tree blob because
the pdata will not be initialized.
Check if pdata is set before de-referencing it.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
drivers/tty/serial/omap-serial.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f809041..0121486 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -159,7 +159,7 @@ static void serial_omap_stop_tx(struct uart_port *port)
serial_out(up, UART_IER, up->ier);
}
- if (!up->use_dma && pdata->set_forceidle)
+ if (!up->use_dma && pdata && pdata->set_forceidle)
pdata->set_forceidle(up->pdev);
pm_runtime_mark_last_busy(&up->pdev->dev);
@@ -298,7 +298,7 @@ static void serial_omap_start_tx(struct uart_port *port)
if (!up->use_dma) {
pm_runtime_get_sync(&up->pdev->dev);
serial_omap_enable_ier_thri(up);
- if (pdata->set_noidle)
+ if (pdata && pdata->set_noidle)
pdata->set_noidle(up->pdev);
pm_runtime_mark_last_busy(&up->pdev->dev);
pm_runtime_put_autosuspend(&up->pdev->dev);
@@ -1613,7 +1613,7 @@ static int serial_omap_runtime_resume(struct device *dev)
struct uart_omap_port *up = dev_get_drvdata(dev);
struct omap_uart_port_info *pdata = dev->platform_data;
- if (up) {
+ if (up && pdata) {
if (pdata->get_context_loss_count) {
u32 loss_cnt = pdata->get_context_loss_count(dev);
--
1.7.0.4
On 1/26/2012 3:50 AM, Paul Walmsley wrote:
> Prevent OMAP UARTs from going idle while they are still transferring
> data in PIO mode. This works around an oversight in the OMAP UART
> hardware present in OMAP34xx and earlier: an idle UART won't send a
> wakeup when the TX FIFO threshold is reached. This causes long delays
> during data transmission when the MPU powerdomain enters a low-power
> mode. The MPU interrupt controller is not able to respond to
> interrupts when it's in a low-power state, so the TX buffer is not
> refilled until another wakeup event occurs.
>
> This fix changes the erratum i291 DMA idle workaround. Rather than
> toggling between force-idle and no-idle, it will toggle between
> smart-idle and no-idle. The important part of the workaround is the
> no-idle part, so this shouldn't result in any change in behavior.
>
> This fix should work on all OMAP UARTs. Future patches intended for
> the 3.4 merge window will make this workaround conditional on a
> "feature" flag, and will use the OMAP36xx+ TX event wakeup support.
>
> Thanks to Kevin Hilman<khilman@ti.com> for mentioning the erratum i291
> workaround, which led to the development of this approach.
>
> Signed-off-by: Paul Walmsley<paul@pwsan.com>
> Cc: Kevin Hilman<khilman@ti.com>
> Cc: Govindraj.R<govindraj.raja@ti.com>
> Cc: Greg Kroah-Hartman<gregkh@suse.de>
> Cc: Alan Cox<alan@linux.intel.com>
> Cc: Tomi Valkeinen<tomi.valkeinen@ti.com>
> ---
> arch/arm/mach-omap2/serial.c | 8 ++++----
> drivers/tty/serial/omap-serial.c | 7 +++++++
> 2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index 247d894..f590afc 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -107,18 +107,18 @@ static void omap_uart_set_noidle(struct platform_device *pdev)
> omap_hwmod_set_slave_idlemode(od->hwmods[0], HWMOD_IDLEMODE_NO);
> }
>
> -static void omap_uart_set_forceidle(struct platform_device *pdev)
> +static void omap_uart_set_smartidle(struct platform_device *pdev)
> {
> struct omap_device *od = to_omap_device(pdev);
>
> - omap_hwmod_set_slave_idlemode(od->hwmods[0], HWMOD_IDLEMODE_FORCE);
> + omap_hwmod_set_slave_idlemode(od->hwmods[0], HWMOD_IDLEMODE_SMART);
> }
>
> #else
> static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
> {}
> static void omap_uart_set_noidle(struct platform_device *pdev) {}
> -static void omap_uart_set_forceidle(struct platform_device *pdev) {}
> +static void omap_uart_set_smartidle(struct platform_device *pdev) {}
> #endif /* CONFIG_PM */
>
> #ifdef CONFIG_OMAP_MUX
> @@ -349,7 +349,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata,
> omap_up.uartclk = OMAP24XX_BASE_BAUD * 16;
> omap_up.flags = UPF_BOOT_AUTOCONF;
> omap_up.get_context_loss_count = omap_pm_get_dev_context_loss_count;
> - omap_up.set_forceidle = omap_uart_set_forceidle;
> + omap_up.set_forceidle = omap_uart_set_smartidle;
> omap_up.set_noidle = omap_uart_set_noidle;
> omap_up.enable_wakeup = omap_uart_enable_wakeup;
> omap_up.dma_rx_buf_size = info->dma_rx_buf_size;
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index c9c9ba2..11fa156 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -136,6 +136,7 @@ static void serial_omap_enable_ms(struct uart_port *port)
> static void serial_omap_stop_tx(struct uart_port *port)
> {
> struct uart_omap_port *up = (struct uart_omap_port *)port;
> + struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
>
> if (up->use_dma&&
> up->uart_dma.tx_dma_channel != OMAP_UART_DMA_CH_FREE) {
> @@ -158,6 +159,9 @@ static void serial_omap_stop_tx(struct uart_port *port)
> serial_out(up, UART_IER, up->ier);
> }
>
> + if (!up->use_dma&& pdata->set_forceidle)
> + pdata->set_forceidle(up->pdev);
> +
> pm_runtime_mark_last_busy(&up->pdev->dev);
> pm_runtime_put_autosuspend(&up->pdev->dev);
> }
> @@ -286,6 +290,7 @@ static inline void serial_omap_enable_ier_thri(struct uart_omap_port *up)
> static void serial_omap_start_tx(struct uart_port *port)
> {
> struct uart_omap_port *up = (struct uart_omap_port *)port;
> + struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
> struct circ_buf *xmit;
> unsigned int start;
> int ret = 0;
> @@ -293,6 +298,8 @@ static void serial_omap_start_tx(struct uart_port *port)
> if (!up->use_dma) {
> pm_runtime_get_sync(&up->pdev->dev);
> serial_omap_enable_ier_thri(up);
> + if (pdata->set_noidle)
> + pdata->set_noidle(up->pdev);
> pm_runtime_mark_last_busy(&up->pdev->dev);
> pm_runtime_put_autosuspend(&up->pdev->dev);
> return;
>
>
> --
> 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 related
* [PATCH] pch_uart: Change default UART clock setting 192MHz
From: Tomoya MORINAGA @ 2012-02-21 4:55 UTC (permalink / raw)
To: Alan Cox, Greg Kroah-Hartman, linux-serial, linux-kernel
Cc: qi.wang, yong.y.wang, joel.clark, kok.howg.ewe, feng.tang, dvhart,
Tomoya MORINAGA
Currently, PCH_UART uses 1843200Hz as default clock.
However, in case of using high baud rate, users need to modify
clock setting.
This patch uses 192MHz setting as default UART clock setting.
Using this clock, users can use almost high baud rate without modifying
clock settings.
This setting is the same as quirk for CM-iTC board.
So, delete the quirk.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
---
Related patch is
http://marc.info/?l=linux-kernel&m=132979974907774&w=2
---
drivers/tty/serial/pch_uart.c | 15 ++++++---------
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/serial/pch_uart.c b/drivers/tty/serial/pch_uart.c
index 17ae657..d068c34 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 192000000 /* 192.0MHz */
struct pch_uart_buffer {
unsigned char *buf;
@@ -287,6 +287,7 @@ 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;
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 };
@@ -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);
@@ -1553,7 +1554,6 @@ static struct eg20t_port *pch_uart_init_port(struct pci_dev *pdev,
int fifosize, base_baud;
int port_type;
struct pch_uart_driver_data *board;
- const char *board_name;
board = &drv_dat[id->driver_data];
port_type = board->port_type;
@@ -1566,12 +1566,8 @@ static struct eg20t_port *pch_uart_init_port(struct pci_dev *pdev,
if (!rxbuf)
goto init_port_free_txbuf;
- base_baud = DEFAULT_BAUD_RATE;
-
- /* 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 */
+ /* The module parameter overrides default. */
+ base_baud = clock_param ? clock_param : DEFAULT_UART_CLOCK;
switch (port_type) {
case PORT_UNKNOWN:
@@ -1785,3 +1781,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_IRUSR | S_IWUSR));
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH] pch_uart: Change default UART clock setting 192MHz
From: Darren Hart @ 2012-02-21 16:07 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: Alan Cox, Greg Kroah-Hartman, linux-serial, linux-kernel, qi.wang,
yong.y.wang, joel.clark, kok.howg.ewe, feng.tang
In-Reply-To: <1329800140-4279-1-git-send-email-tomoya.rohm@gmail.com>
On 02/20/2012 08:55 PM, Tomoya MORINAGA wrote:
> Currently, PCH_UART uses 1843200Hz as default clock.
> However, in case of using high baud rate, users need to modify
> clock setting.
>
> This patch uses 192MHz setting as default UART clock setting.
> Using this clock, users can use almost high baud rate without modifying
> clock settings.
>
> This setting is the same as quirk for CM-iTC board.
> So, delete the quirk.
This also adds my module parameter "clock_param" to the patch. This
should be added separately. My current version renames this to
user_uartclk. I can send this one separately.
I'll test this today to ensure it works for my development board. I'm
concerned that it won't work for early serial console and I'll still
need to modify the BAUD on the kernel command line to compensate for the
delta between the firmware clock setting (64MHz) and the phub setting to
192MHz. When does the phub driver update the clock registers?
--
Darren
> Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
> ---
> Related patch is
> http://marc.info/?l=linux-kernel&m=132979974907774&w=2
> ---
> drivers/tty/serial/pch_uart.c | 15 ++++++---------
> 1 files changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/tty/serial/pch_uart.c b/drivers/tty/serial/pch_uart.c
> index 17ae657..d068c34 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 192000000 /* 192.0MHz */
>
> struct pch_uart_buffer {
> unsigned char *buf;
> @@ -287,6 +287,7 @@ 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;
> 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 };
> @@ -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);
> @@ -1553,7 +1554,6 @@ static struct eg20t_port *pch_uart_init_port(struct pci_dev *pdev,
> int fifosize, base_baud;
> int port_type;
> struct pch_uart_driver_data *board;
> - const char *board_name;
>
> board = &drv_dat[id->driver_data];
> port_type = board->port_type;
> @@ -1566,12 +1566,8 @@ static struct eg20t_port *pch_uart_init_port(struct pci_dev *pdev,
> if (!rxbuf)
> goto init_port_free_txbuf;
>
> - base_baud = DEFAULT_BAUD_RATE;
> -
> - /* 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 */
> + /* The module parameter overrides default. */
> + base_baud = clock_param ? clock_param : DEFAULT_UART_CLOCK;
>
> switch (port_type) {
> case PORT_UNKNOWN:
> @@ -1785,3 +1781,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_IRUSR | S_IWUSR));
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply
* Re: [PATCH 0/2] Two trivial omap/serial patches
From: Kevin Hilman @ 2012-02-21 19:10 UTC (permalink / raw)
To: NeilBrown
Cc: Alan Cox, linux-serial, linux-omap, linux-arm-kernel,
Paul Walmsley, Govindraj . R
In-Reply-To: <20120219022841.8254.86264.stgit@notabene.brown>
NeilBrown <neilb@suse.de> writes:
> Just a couple of small clean-ups following the recent major changes.
Thanks Neil.
I'll queue these as cleanups for v3.4 since I dont' think they're v3.3
material at this point of the cycle.
I'll also update the changelogs to follow the practice of adding the
shortlog in parens after the commit ID.
Kevin
>
> Thanks,
> NeilBrown
>
> ---
>
> NeilBrown (2):
> ARM: OMAP2: remove some orphan function declarations.
> ARM: OMAP2+: UART: remove unused fields in omap_uart_state.
>
>
> arch/arm/mach-omap2/pm.h | 1 -
> arch/arm/mach-omap2/serial.c | 4 ----
> arch/arm/plat-omap/include/plat/serial.h | 1 -
> 3 files changed, 0 insertions(+), 6 deletions(-)
^ permalink raw reply
* Re: [PATCH 0/2] Two trivial omap/serial patches
From: NeilBrown @ 2012-02-21 19:40 UTC (permalink / raw)
To: Kevin Hilman
Cc: Alan Cox, linux-serial, linux-omap, linux-arm-kernel,
Paul Walmsley, Govindraj . R
In-Reply-To: <87boos57fd.fsf@ti.com>
[-- Attachment #1: Type: text/plain, Size: 526 bytes --]
On Tue, 21 Feb 2012 11:10:30 -0800 Kevin Hilman <khilman@ti.com> wrote:
> NeilBrown <neilb@suse.de> writes:
>
> > Just a couple of small clean-ups following the recent major changes.
>
> Thanks Neil.
>
> I'll queue these as cleanups for v3.4 since I dont' think they're v3.3
> material at this point of the cycle.
Thanks,
>
> I'll also update the changelogs to follow the practice of adding the
> shortlog in parens after the commit ID.
I'll try to remember that for next time.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] tty: serial: OMAP: block idle while the UART is transferring data in PIO mode
From: Paul Walmsley @ 2012-02-21 22:02 UTC (permalink / raw)
To: Cousson, Benoit
Cc: linux-omap, linux-serial, linux-arm-kernel, Kevin Hilman,
Govindraj.R, Greg Kroah-Hartman, Alan Cox, Tomi Valkeinen,
Nayak, Rajendra
In-Reply-To: <4F423E28.3040404@ti.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 940 bytes --]
Salut Benoît,
On Mon, 20 Feb 2012, Cousson, Benoit wrote:
> 3.3-rc4 is broken in the DT case because of the serial driver. And it
> looks like it is due to this fix. We cannot rely on pdata anymore in
> DT, and in that case it leads to an Oops due to NULL pdata.
Sorry about the breakage. I agree with the diagnosis. That code was just
copied from the DMA errata part of the driver, so it will need to be fixed
as well. Otherwise the same problem will happen when DMA is enabled.
> And then we will have to add the support for all these OMAP custom hooks without pdata.
That's really the key question for the medium- to long-term...
> A basic fix (below) for the moment is to test for valid pdata inside the driver.
> I'll repost it properly if you are fine with it.
Looks fine to me, although I'd suggest fixing the DMA workaround path as
well.
Reviewed-by: Paul Walmsley <paul@pwsan.com>
- Paul
^ permalink raw reply
* Re: [PATCH] pch_uart: Change default UART clock setting 192MHz
From: Darren Hart @ 2012-02-21 22:07 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: Alan Cox, Greg Kroah-Hartman, linux-serial, linux-kernel, qi.wang,
yong.y.wang, joel.clark, kok.howg.ewe, feng.tang
In-Reply-To: <1329800140-4279-1-git-send-email-tomoya.rohm@gmail.com>
On 02/20/2012 08:55 PM, Tomoya MORINAGA wrote:
> Currently, PCH_UART uses 1843200Hz as default clock.
> However, in case of using high baud rate, users need to modify
> clock setting.
>
> This patch uses 192MHz setting as default UART clock setting.
> Using this clock, users can use almost high baud rate without modifying
> clock settings.
>
> This setting is the same as quirk for CM-iTC board.
> So, delete the quirk.
With this change, the serial console will work, but only after the
device is initialized. We get garbage out of the early serial console
(as it still uses the 115200 as the BASE_BAUD and the firmware in my
case has set this to 64000000/16):
xĀx�x��x�x��xx�x��xxx�xxx�x��x�x�xxxx���xxx�x�x��x�x�x�����x��xx���x�x�x�xx�x��x�x6
ahci 0000:03:06.0: AHCI 0001.0100 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
ahci 0000:03:06.0: flags: ncq sntf pm led clo only pmp pio slum part ccc
scsi0 : ahci
scsi1 : ahci
...
Perhaps a reasonable solution would be to add a KCONFIG option for the
early_console BASE_BAUD. I prefer the fixed 192MHz solution here to
special casing every EG20T PCH board.
I'll prepare and test a patch for early_serial_console BASE_BAUD.
Please resend these patches with my clock_param changes removed as they
shouldn't be necessary now that we set all boards to 192MHz.
--
Darren
>
> Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
> ---
> Related patch is
> http://marc.info/?l=linux-kernel&m=132979974907774&w=2
> ---
> drivers/tty/serial/pch_uart.c | 15 ++++++---------
> 1 files changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/tty/serial/pch_uart.c b/drivers/tty/serial/pch_uart.c
> index 17ae657..d068c34 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 192000000 /* 192.0MHz */
>
> struct pch_uart_buffer {
> unsigned char *buf;
> @@ -287,6 +287,7 @@ 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;
> 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 };
> @@ -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);
> @@ -1553,7 +1554,6 @@ static struct eg20t_port *pch_uart_init_port(struct pci_dev *pdev,
> int fifosize, base_baud;
> int port_type;
> struct pch_uart_driver_data *board;
> - const char *board_name;
>
> board = &drv_dat[id->driver_data];
> port_type = board->port_type;
> @@ -1566,12 +1566,8 @@ static struct eg20t_port *pch_uart_init_port(struct pci_dev *pdev,
> if (!rxbuf)
> goto init_port_free_txbuf;
>
> - base_baud = DEFAULT_BAUD_RATE;
> -
> - /* 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 */
> + /* The module parameter overrides default. */
> + base_baud = clock_param ? clock_param : DEFAULT_UART_CLOCK;
>
> switch (port_type) {
> case PORT_UNKNOWN:
> @@ -1785,3 +1781,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_IRUSR | S_IWUSR));
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] pch_uart: Change default UART clock setting 192MHz
From: Tomoya MORINAGA @ 2012-02-21 23:43 UTC (permalink / raw)
To: Darren Hart
Cc: Alan Cox, Greg Kroah-Hartman, linux-serial, linux-kernel, qi.wang,
yong.y.wang, joel.clark, kok.howg.ewe, feng.tang
In-Reply-To: <4F43C15D.6080401@linux.intel.com>
2012年2月22日1:07 Darren Hart <dvhart@linux.intel.com>:
> When does the phub driver update the clock registers?
I've already posted pch_phub patch for 192MHz setting.
You can see the patch form below.
>> Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
>> ---
>> Related patch is
>> http://marc.info/?l=linux-kernel&m=132979974907774&w=2
---
ROHM Co., Ltd.
tomoya
^ permalink raw reply
* Re: [PATCH] pch_uart: Change default UART clock setting 192MHz
From: Darren Hart @ 2012-02-22 0:20 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: Alan Cox, Greg Kroah-Hartman, linux-serial, linux-kernel, qi.wang,
yong.y.wang, joel.clark, kok.howg.ewe, feng.tang
In-Reply-To: <CANKRQnjMAVBf2wn01eFD1CKTgtWyhzk2_epz-YprZp3eS1wmMg@mail.gmail.com>
On 02/21/2012 03:43 PM, Tomoya MORINAGA wrote:
> 2012年2月22日1:07 Darren Hart <dvhart@linux.intel.com>:
>> When does the phub driver update the clock registers?
>
> I've already posted pch_phub patch for 192MHz setting.
> You can see the patch form below.
Yes, I applied the patch. The problem seems to be this:
DVHART: parse_options (8250_early.c)
DVHART: pch_console_setup
DVHART: pch_console_setup
DVHART: pch_phub_probe: set CLKCFG UART to 192MHz
As you can see, the pch_phub_probe happens much too late.
I can get it to work with a boot command line like this:
earlycon=uart8250,io,0x2050,115200n8 console=ttyPCH1,115200n8
And hacking all the BASE_BAUD references to be 48000000
(my current hardware sets the clock to 48MHz in firmware).
This gets things working until pch_phub gets around to setting
the CLKCFG register for the UART clock.
I'd prefer to not have to use the earlycon parameter/code,
but we need a way for the pch_uart to understand the difference
between early boot and post-phub setup. Can we read the CLKCFG
register in pch_console_setup to dynamically configure the
port->uartclk? (not sure that's even the right place to do it).
--
Darren
>>> Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
>>> ---
>>> Related patch is
>>> http://marc.info/?l=linux-kernel&m=132979974907774&w=2
>
> ---
> ROHM Co., Ltd.
> tomoya
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply
* [PATCH 0/4] pch_uart: Cleanups, board quirks, and user uartclk parameter
From: Darren Hart @ 2012-02-22 1:59 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Tomoya MORINAGA, Feng Tang, Greg Kroah-Hartman, Alan Cox,
linux-serial, Darren Hart
This series does some minor clean-up to the pch_uart driver, adds support
for the Fish River Island II UART clock, and introduces a user_uartclk
parameter to aid in developing for early and changing hardware.
Note that this series is my proposed alternative solution to that provided
by Tomoya MORNIAGA and Feng Tang which drops the board quirks and opts to
assume a 192 MHz clock on all boards. The problem with this approach is
that the CLKCFG register may have been set to something other than the
192MHz configuration by the firmware. If so, then the pch_uart will send
garbage between the time the boot console is disabled and the pch_phub
sets the CLKCFG register again. In my case, the pch_phub PCI probe occurs
after the pch_uart_console_setup. Even if it happened before, the output
up until the PCI probing would be garbage.
In order to support an early serial console, we cannot rely on the pch_phub
probe function to setup the CFGCLK register. This series relies on the board
quirks and doesn't force the setting of the CLKREG in the pch_phub code.
Instead, it aligns with what is the default configuration (defined by firmware)
for a given board. The user_uartclk provides a mechanism to force a specific
uartclk if necessary.
--
Darren
The following changes since commit 27e74da9800289e69ba907777df1e2085231eff7:
i387: export 'fpu_owner_task' per-cpu variable (2012-02-20 19:34:10 -0800)
are available in the git repository at:
git://git.infradead.org/users/dvhart/linux-2.6.git pch_uart
http://git.infradead.org/users/dvhart/linux-2.6.git/shortlog/refs/heads/pch_uart
Darren Hart (4):
pch_uart: Use uartclk instead of base_baud
pch_uart: Add Fish River Island II uart clock quirks
pch_uart: Add user_uartclk parameter
pch_uart: Use existing default_baud in setup_console
drivers/tty/serial/pch_uart.c | 52 +++++++++++++++++++++++++++++-----------
1 files changed, 37 insertions(+), 15 deletions(-)
--
1.7.6.5
^ permalink raw reply
* [PATCH 2/4] pch_uart: Add Fish River Island II uart clock quirks
From: Darren Hart @ 2012-02-22 1:59 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Darren Hart, Tomoya MORINAGA, Feng Tang, Greg Kroah-Hartman,
Alan Cox, linux-serial
In-Reply-To: <cover.1329875301.git.dvhart@linux.intel.com>
Add support for the Fish River Island II (FRI2) 64MHz UART clock following
the CM-iTC quirk handling mechanism.
Add similar UART clock quirk handling to the pch_console_setup() function
to enable kernel messages on boards with non-standard UART clocks.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Tomoya MORINAGA <tomoya.rohm@gmail.com>
CC: Feng Tang <feng.tang@intel.com>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Alan Cox <alan@linux.intel.com>
CC: linux-serial@vger.kernel.org
---
drivers/tty/serial/pch_uart.c | 28 +++++++++++++++++++++++-----
1 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/pch_uart.c b/drivers/tty/serial/pch_uart.c
index c565817..b070a4a 100644
--- a/drivers/tty/serial/pch_uart.c
+++ b/drivers/tty/serial/pch_uart.c
@@ -203,7 +203,9 @@ enum {
#define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
-#define DEFAULT_UARTCLK 1843200 /* 1.8432MHz */
+#define DEFAULT_UARTCLK 1843200 /* 1.8432 MHz */
+#define CMITC_UARTCLK 192000000 /* 192.0000 MHz */
+#define FRI2_UARTCLK 64000000 /* 64.0000 MHz */
struct pch_uart_buffer {
unsigned char *buf;
@@ -1488,11 +1490,13 @@ pch_console_write(struct console *co, const char *s, unsigned int count)
static int __init pch_console_setup(struct console *co, char *options)
{
+ const char *board_name;
struct uart_port *port;
int baud = 9600;
int bits = 8;
int parity = 'n';
int flow = 'n';
+ int uartclk;
/*
* Check whether an invalid uart number has been specified, and
@@ -1506,8 +1510,18 @@ static int __init pch_console_setup(struct console *co, char *options)
if (!port || (!port->iobase && !port->membase))
return -ENODEV;
- /* setup uartclock */
- port->uartclk = DEFAULT_UARTCLK;
+ /* Setup UART clock, checking for board specific clocks. */
+ uartclk = DEFAULT_UARTCLK;
+
+ board_name = dmi_get_system_info(DMI_BOARD_NAME);
+ if (board_name && strstr(board_name, "CM-iTC"))
+ uartclk = CMITC_UARTCLK;
+
+ board_name = dmi_get_system_info(DMI_PRODUCT_NAME);
+ if (board_name && strstr(board_name, "Fish River Island II"))
+ uartclk = FRI2_UARTCLK;
+
+ port->uartclk = uartclk;
if (options)
uart_parse_options(options, &baud, &parity, &bits, &flow);
@@ -1566,12 +1580,16 @@ static struct eg20t_port *pch_uart_init_port(struct pci_dev *pdev,
if (!rxbuf)
goto init_port_free_txbuf;
+ /* Setup UART clock, checking for board specific clocks. */
uartclk = DEFAULT_UARTCLK;
- /* quirk for CM-iTC board */
board_name = dmi_get_system_info(DMI_BOARD_NAME);
if (board_name && strstr(board_name, "CM-iTC"))
- uartclk = 192000000; /* 192.0MHz */
+ uartclk = CMITC_UARTCLK;
+
+ board_name = dmi_get_system_info(DMI_PRODUCT_NAME);
+ if (board_name && strstr(board_name, "Fish River Island II"))
+ uartclk = FRI2_UARTCLK;
switch (port_type) {
case PORT_UNKNOWN:
--
1.7.6.5
^ permalink raw reply related
* [PATCH 3/4] pch_uart: Add user_uartclk parameter
From: Darren Hart @ 2012-02-22 1:59 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Darren Hart, Tomoya MORINAGA, Feng Tang, Greg Kroah-Hartman,
Alan Cox, linux-serial
In-Reply-To: <cover.1329875301.git.dvhart@linux.intel.com>
For cases where boards with non-default clocks are not yet added to the kernel
or when the clock varies across hardware revisions, it is useful to be
able to specify the UART clock on the kernel command line.
Add the user_uartclk parameter and prefer it, if set, to the default and
board specific UART clock settings. Specify user_uartclock on the command-line
with "pch_uart.user_uartclk=48000000".
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Tomoya MORINAGA <tomoya.rohm@gmail.com>
CC: Feng Tang <feng.tang@intel.com>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Alan Cox <alan@linux.intel.com>
CC: linux-serial@vger.kernel.org
---
drivers/tty/serial/pch_uart.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/pch_uart.c b/drivers/tty/serial/pch_uart.c
index b070a4a..d00b75c 100644
--- a/drivers/tty/serial/pch_uart.c
+++ b/drivers/tty/serial/pch_uart.c
@@ -289,6 +289,7 @@ 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 user_uartclk = 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 };
@@ -1521,7 +1522,7 @@ static int __init pch_console_setup(struct console *co, char *options)
if (board_name && strstr(board_name, "Fish River Island II"))
uartclk = FRI2_UARTCLK;
- port->uartclk = uartclk;
+ port->uartclk = user_uartclk ? user_uartclk : uartclk;
if (options)
uart_parse_options(options, &baud, &parity, &bits, &flow);
@@ -1591,6 +1592,8 @@ static struct eg20t_port *pch_uart_init_port(struct pci_dev *pdev,
if (board_name && strstr(board_name, "Fish River Island II"))
uartclk = FRI2_UARTCLK;
+ uartclk = user_uartclk ? user_uartclk : uartclk;
+
switch (port_type) {
case PORT_UNKNOWN:
fifosize = 256; /* EG20T/ML7213: UART0 */
@@ -1803,3 +1806,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(user_uartclk, uint, S_IRUGO);
--
1.7.6.5
^ permalink raw reply related
* [PATCH 1/4] pch_uart: Use uartclk instead of base_baud
From: Darren Hart @ 2012-02-22 1:59 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Darren Hart, Tomoya MORINAGA, Feng Tang, Greg Kroah-Hartman,
Alan Cox, linux-serial
In-Reply-To: <cover.1329875301.git.dvhart@linux.intel.com>
The term "base baud" refers to the fastest baud rate the device can communicate
at. This is clock/16. pch_uart is using base_baud as the clock itself. Rename
the variables to be semantically correct.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Tomoya MORINAGA <tomoya.rohm@gmail.com>
CC: Feng Tang <feng.tang@intel.com>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Alan Cox <alan@linux.intel.com>
CC: linux-serial@vger.kernel.org
---
drivers/tty/serial/pch_uart.c | 24 ++++++++++++------------
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/tty/serial/pch_uart.c b/drivers/tty/serial/pch_uart.c
index 17ae657..c565817 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_UARTCLK 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 uartclk;
int start_tx;
int start_rx;
int tx_empty;
@@ -293,7 +293,7 @@ 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 uartclk)
{
struct eg20t_port *priv = pci_get_drvdata(pdev);
@@ -332,7 +332,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->uartclk / 16, baud);
if (div < 0 || USHRT_MAX <= div) {
dev_err(priv->port.dev, "Invalid Baud(div=0x%x)\n", div);
return -EINVAL;
@@ -1153,9 +1153,9 @@ static int pch_uart_startup(struct uart_port *port)
priv->tx_empty = 1;
if (port->uartclk)
- priv->base_baud = port->uartclk;
+ priv->uartclk = port->uartclk;
else
- port->uartclk = priv->base_baud;
+ port->uartclk = priv->uartclk;
pch_uart_hal_disable_interrupt(priv, PCH_UART_HAL_ALL_INT);
ret = pch_uart_hal_set_line(priv, default_baud,
@@ -1507,7 +1507,7 @@ static int __init pch_console_setup(struct console *co, char *options)
return -ENODEV;
/* setup uartclock */
- port->uartclk = DEFAULT_BAUD_RATE;
+ port->uartclk = DEFAULT_UARTCLK;
if (options)
uart_parse_options(options, &baud, &parity, &bits, &flow);
@@ -1550,7 +1550,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, uartclk;
int port_type;
struct pch_uart_driver_data *board;
const char *board_name;
@@ -1566,12 +1566,12 @@ static struct eg20t_port *pch_uart_init_port(struct pci_dev *pdev,
if (!rxbuf)
goto init_port_free_txbuf;
- base_baud = DEFAULT_BAUD_RATE;
+ uartclk = DEFAULT_UARTCLK;
/* 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 */
+ uartclk = 192000000; /* 192.0MHz */
switch (port_type) {
case PORT_UNKNOWN:
@@ -1597,7 +1597,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->uartclk = uartclk;
priv->port_type = PORT_MAX_8250 + port_type + 1;
priv->port.dev = &pdev->dev;
priv->port.iobase = iobase;
@@ -1614,7 +1614,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, uartclk);
#ifdef CONFIG_SERIAL_PCH_UART_CONSOLE
pch_uart_ports[board->line_no] = priv;
--
1.7.6.5
^ permalink raw reply related
* [PATCH 4/4] pch_uart: Use existing default_baud in setup_console
From: Darren Hart @ 2012-02-22 1:59 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Darren Hart, Tomoya MORINAGA, Feng Tang, Greg Kroah-Hartman,
Alan Cox, linux-serial
In-Reply-To: <cover.1329875301.git.dvhart@linux.intel.com>
Rather than hardcode 9600, use the existing default_baud parameter (which
also defaults to 9600).
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Tomoya MORINAGA <tomoya.rohm@gmail.com>
CC: Feng Tang <feng.tang@intel.com>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Alan Cox <alan@linux.intel.com>
CC: linux-serial@vger.kernel.org
---
drivers/tty/serial/pch_uart.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/pch_uart.c b/drivers/tty/serial/pch_uart.c
index d00b75c..c2c1bac 100644
--- a/drivers/tty/serial/pch_uart.c
+++ b/drivers/tty/serial/pch_uart.c
@@ -1493,7 +1493,7 @@ static int __init pch_console_setup(struct console *co, char *options)
{
const char *board_name;
struct uart_port *port;
- int baud = 9600;
+ int baud = default_baud;
int bits = 8;
int parity = 'n';
int flow = 'n';
--
1.7.6.5
^ permalink raw reply related
* Re: [PATCH] pch_uart: Change default UART clock setting 192MHz
From: Tomoya MORINAGA @ 2012-02-22 2:28 UTC (permalink / raw)
To: Darren Hart
Cc: Alan Cox, Greg Kroah-Hartman, linux-serial, linux-kernel, qi.wang,
yong.y.wang, joel.clark, kok.howg.ewe, feng.tang
In-Reply-To: <4F4434E4.7040703@linux.intel.com>
2012年2月22日9:20 Darren Hart <dvhart@linux.intel.com>:
> Can we read the CLKCFG
> register in pch_console_setup to dynamically configure the
> port->uartclk? (not sure that's even the right place to do it).
In general implementation, as long as pch_phub is not installed,
nobody accesses the CLKCFG register.
So I think it cannot do.
Beyond general implementation, you would access the register.
thanks
---
ROHM Co., Ltd.
tomoy
^ permalink raw reply
* Re: [PATCH 0/4] pch_uart: Cleanups, board quirks, and user uartclk parameter
From: Tomoya MORINAGA @ 2012-02-22 3:10 UTC (permalink / raw)
To: Darren Hart
Cc: Linux Kernel Mailing List, Feng Tang, Greg Kroah-Hartman,
Alan Cox, linux-serial
In-Reply-To: <cover.1329875301.git.dvhart@linux.intel.com>
2012年2月22日10:59 Darren Hart <dvhart@linux.intel.com>:
> This series does some minor clean-up to the pch_uart driver, adds support
> for the Fish River Island II UART clock, and introduces a user_uartclk
> parameter to aid in developing for early and changing hardware.
>
> Note that this series is my proposed alternative solution to that provided
> by Tomoya MORNIAGA and Feng Tang which drops the board quirks and opts to
> assume a 192 MHz clock on all boards. The problem with this approach is
> that the CLKCFG register may have been set to something other than the
> 192MHz configuration by the firmware. If so, then the pch_uart will send
> garbage between the time the boot console is disabled and the pch_phub
> sets the CLKCFG register again. In my case, the pch_phub PCI probe occurs
> after the pch_uart_console_setup. Even if it happened before, the output
> up until the PCI probing would be garbage.
>
> In order to support an early serial console, we cannot rely on the pch_phub
> probe function to setup the CFGCLK register. This series relies on the board
> quirks and doesn't force the setting of the CLKREG in the pch_phub code.
> Instead, it aligns with what is the default configuration (defined by firmware)
> for a given board. The user_uartclk provides a mechanism to force a specific
> uartclk if necessary.
I think UART console function(including "early serial console") is
used for debug use.
So, if people who want to see the boot log correctly before pch_phub installed,
the people have only to do configure uart_clock by themselves.
So, I think default uart_clock 192MHz setting is better than Darren's opinion.
Let me know your opinion.
thanks,
---
ROHM Co., Ltd.
tomoya
^ permalink raw reply
* Re: [PATCH 0/4] pch_uart: Cleanups, board quirks, and user uartclk parameter
From: Darren Hart @ 2012-02-22 3:36 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: Linux Kernel Mailing List, Feng Tang, Greg Kroah-Hartman,
Alan Cox, linux-serial
In-Reply-To: <CANKRQni9E6NO39MFSak6MjQ0DtmQeviGo966Ex9ZUvai56wCjg@mail.gmail.com>
On 02/21/2012 07:10 PM, Tomoya MORINAGA wrote:
> 2012年2月22日10:59 Darren Hart <dvhart@linux.intel.com>:
>> This series does some minor clean-up to the pch_uart driver, adds support
>> for the Fish River Island II UART clock, and introduces a user_uartclk
>> parameter to aid in developing for early and changing hardware.
>>
>> Note that this series is my proposed alternative solution to that provided
>> by Tomoya MORNIAGA and Feng Tang which drops the board quirks and opts to
>> assume a 192 MHz clock on all boards. The problem with this approach is
>> that the CLKCFG register may have been set to something other than the
>> 192MHz configuration by the firmware. If so, then the pch_uart will send
>> garbage between the time the boot console is disabled and the pch_phub
>> sets the CLKCFG register again. In my case, the pch_phub PCI probe occurs
>> after the pch_uart_console_setup. Even if it happened before, the output
>> up until the PCI probing would be garbage.
>>
>> In order to support an early serial console, we cannot rely on the pch_phub
>> probe function to setup the CFGCLK register. This series relies on the board
>> quirks and doesn't force the setting of the CLKREG in the pch_phub code.
>> Instead, it aligns with what is the default configuration (defined by firmware)
>> for a given board. The user_uartclk provides a mechanism to force a specific
>> uartclk if necessary.
>
> I think UART console function(including "early serial console") is
> used for debug use.
>
> So, if people who want to see the boot log correctly before pch_phub installed,
> the people have only to do configure uart_clock by themselves.
>
> So, I think default uart_clock 192MHz setting is better than Darren's opinion.
>
> Let me know your opinion.
This patch series allows for a functional early serial console as well
as using the UART after boot. It leaves the CM-iTC board alone. So this
seems to enable all use cases, while forcing 192MHz breaks the FRI2
early serial console. I don't see an advantage to that approach other
than the obviously simpler code (which is nice, but should not trump
functionality).
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply
* Re: [PATCH 0/4] pch_uart: Cleanups, board quirks, and user uartclk parameter
From: Tomoya MORINAGA @ 2012-02-22 4:26 UTC (permalink / raw)
To: Darren Hart
Cc: Linux Kernel Mailing List, Feng Tang, Greg Kroah-Hartman,
Alan Cox, linux-serial
In-Reply-To: <4F4462B8.6030607@linux.intel.com>
2012年2月22日12:36 Darren Hart <dvhart@linux.intel.com>:
> This patch series allows for a functional early serial console as well
> as using the UART after boot. It leaves the CM-iTC board alone. So this
> seems to enable all use cases, while forcing 192MHz breaks the FRI2
> early serial console. I don't see an advantage to that approach other
> than the obviously simpler code (which is nice, but should not trump
> functionality).
Your quark "Fish River Island II" is OK.
My concern is default uart_clock remains 1.8432 MHz.
Like I said the advantage before, I think this should be 192MHz not 1.8432 MHz.
Or do you have any reason 1.8432 MHz should be set as PCH_UART default clock.
thanks
---
ROHM Co., Ltd.
tomoya
^ permalink raw reply
* Re: [PATCH 0/4] pch_uart: Cleanups, board quirks, and user uartclk parameter
From: Darren Hart @ 2012-02-22 6:39 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: Linux Kernel Mailing List, Feng Tang, Greg Kroah-Hartman,
Alan Cox, linux-serial
In-Reply-To: <CANKRQnhckD5Dt+0PbD3h=Ggz+U8RoDs0qUn5CgVnsYcH08tRkw@mail.gmail.com>
On 02/21/2012 08:26 PM, Tomoya MORINAGA wrote:
> 2012年2月22日12:36 Darren Hart <dvhart@linux.intel.com>:
>> This patch series allows for a functional early serial console as well
>> as using the UART after boot. It leaves the CM-iTC board alone. So this
>> seems to enable all use cases, while forcing 192MHz breaks the FRI2
>> early serial console. I don't see an advantage to that approach other
>> than the obviously simpler code (which is nice, but should not trump
>> functionality).
>
> Your quark "Fish River Island II" is OK.
> My concern is default uart_clock remains 1.8432 MHz.
> Like I said the advantage before, I think this should be 192MHz not 1.8432 MHz.
>
> Or do you have any reason 1.8432 MHz should be set as PCH_UART default clock.
Ah, that's a good point. We can add a patch to this series that sets the
default to 192MHz, drops the CM-iTC quirk, and does nothing in pch_phub
probe for the FRI2. Would you care to Ack this series and then follow-up
with a patch set the default clock to 192MHz?
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply
* About changing Line Discipline from Kernel
From: Mayank Rana @ 2012-02-22 7:05 UTC (permalink / raw)
To: linux-serial
Hi ,
I have few queries related to using Line Discipline.
1. I understand that line discipline can be changed from user space
application by opening the device and doing ioctl with required Line
Discipline ID. Is it possible to do the same from kernel module who
would be communicating with that line discipline ?
2. Is it way to set default line discipline for particular tty device
to required Line Discipline instead of N_TTY one ?
Appreciate your help on this.
Regards,
_-_Mayank Rana_-_
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH 0/4] pch_uart: Cleanups, board quirks, and user uartclk parameter
From: Tomoya MORINAGA @ 2012-02-22 8:16 UTC (permalink / raw)
To: Darren Hart
Cc: Linux Kernel Mailing List, Feng Tang, Greg Kroah-Hartman,
Alan Cox, linux-serial
In-Reply-To: <4F448DAA.6000207@linux.intel.com>
2012年2月22日15:39 Darren Hart <dvhart@linux.intel.com>:
> We can add a patch to this series that sets the
> default to 192MHz, drops the CM-iTC quirk, and does nothing in pch_phub
> probe for the FRI2.
If you set the clock of pch_uart as 64MHz,
do you need to add quirk for FRI2 to pch_phub so as to provide 64MHz clock?
---
ROHM Co., Ltd.
tomoya
^ permalink raw reply
* Re: About changing Line Discipline from Kernel
From: Søren holm @ 2012-02-22 8:22 UTC (permalink / raw)
To: Mayank Rana; +Cc: linux-serial
In-Reply-To: <4F4493AC.5010405@codeaurora.org>
Onsdag den 22. februar 2012 12:35:16 skrev Mayank Rana:
>
> I have few queries related to using Line Discipline.
>
> 1. I understand that line discipline can be changed from user space
> application by opening the device and doing ioctl with required Line
> Discipline ID. Is it possible to do the same from kernel module who
> would be communicating with that line discipline ?
>
> 2. Is it way to set default line discipline for particular tty device
> to required Line Discipline instead of N_TTY one ?
>
> Appreciate your help on this.
I've earlier done something like this :
/* Attach line discipline to the uctrl tty */
set_fs(get_ds());
ret = put_user(N_PS3D, &ldiscNum);
if (ret != 0) {
PSDEBUG(debuglevel, "Leaving, EFAULT\n");
return -EFAULT;
} else {
set_fs(KERNEL_DS);
ret = uctrl_file->f_op->unlocked_ioctl(uctrl_file, TIOCSETD, (unsigned long)&ldiscNum);
/*
* Decrement use count since setting the line descipline triggers a call to 'n_ps3d_tty_open'
* which increments the use count making it impossible to only the module without --force
*/
module_put(THIS_MODULE);
if (ret < 0) {
PSKERR(debuglevel, "failed with n_tty_ioctl()\n");
return -EFAULT;
}
}
set_fs(old_fs);
--
Søren Holm
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/4] pch_uart: Add Fish River Island II uart clock quirks
From: Alan Cox @ 2012-02-22 8:52 UTC (permalink / raw)
To: Darren Hart
Cc: Linux Kernel Mailing List, Tomoya MORINAGA, Feng Tang,
Greg Kroah-Hartman, Alan Cox, linux-serial
In-Reply-To: <4982ca7a73cfe208a2a5ff0a7e0da54b99ca2d2e.1329875301.git.dvhart@linux.intel.com>
> + /* Setup UART clock, checking for board specific clocks. */
> + uartclk = DEFAULT_UARTCLK;
> +
> + board_name = dmi_get_system_info(DMI_BOARD_NAME);
> + if (board_name && strstr(board_name, "CM-iTC"))
> + uartclk = CMITC_UARTCLK;
> +
> + board_name = dmi_get_system_info(DMI_PRODUCT_NAME);
> + if (board_name && strstr(board_name, "Fish River Island II"))
> + uartclk = FRI2_UARTCLK;
> +
> + port->uartclk = uartclk;
This is confusing, you load product name into a variable called
board_name ?? perhaps "name" would be clearer ?
>
> if (options)
> uart_parse_options(options, &baud, &parity, &bits, &flow);
> @@ -1566,12 +1580,16 @@ static struct eg20t_port *pch_uart_init_port(struct pci_dev *pdev,
> if (!rxbuf)
> goto init_port_free_txbuf;
>
> + /* Setup UART clock, checking for board specific clocks. */
> uartclk = DEFAULT_UARTCLK;
>
> - /* quirk for CM-iTC board */
> board_name = dmi_get_system_info(DMI_BOARD_NAME);
> if (board_name && strstr(board_name, "CM-iTC"))
> - uartclk = 192000000; /* 192.0MHz */
> + uartclk = CMITC_UARTCLK;
> +
> + board_name = dmi_get_system_info(DMI_PRODUCT_NAME);
> + if (board_name && strstr(board_name, "Fish River Island II"))
> + uartclk = FRI2_UARTCLK;
And we have two locations so this is going to get missed on updates. Can
we have one function for this please ?
Alan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox