* 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
* Re: pch_uart and pch_phub clock selection
From: Tomoya MORINAGA @ 2012-02-20 6:22 UTC (permalink / raw)
To: Feng Tang
Cc: Darren Hart, lkml,, Arnd Bergmann, Greg Kroah-Hartman, Alan Cox,
linux-serial
In-Reply-To: <20120220055708.GA4903@feng-i7>
2012年2月20日14:57 Feng Tang <feng.tang@intel.com>:
> Great! and glad to hear that. Could you update your patch which only touches
> the EG20T UART clock setting? like taking the register setting code out of
> the "switch/case" loop. something like:
OK.
I will modify like you said and post the patch.
thanks.
---
ROHM Co., Ltd.
tomoya
^ permalink raw reply
* [PATCH] serial/amba-pl011: Return early in deadlock work-around if there is no tty
From: Kalle Vahlman @ 2012-02-20 6:07 UTC (permalink / raw)
To: linux-serial; +Cc: stable, Kalle Vahlman
The first amba port does not always have an attached tty, which will
result in a crash if the work-around is activated.
This seems to be the case for example on Snowball which has no modem
hw, which seems to be the main use-case for this work-around.
---
drivers/tty/serial/amba-pl011.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 6800f5f..c3ffbed 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -1061,6 +1061,10 @@ static void pl011_lockup_wa(unsigned long data)
int buf_empty_retries = 200;
int loop;
+ /* Exit early if there is no tty */
+ if (!tty)
+ return;
+
/* Stop HCI layer from submitting data for tx */
tty->hw_stopped = 1;
while (!uart_circ_empty(xmit)) {
--
1.7.1
^ permalink raw reply related
* Re: pch_uart and pch_phub clock selection
From: Feng Tang @ 2012-02-20 5:57 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: Darren Hart, lkml,, Arnd Bergmann, Greg Kroah-Hartman, Alan Cox,
linux-serial
In-Reply-To: <CANKRQniP+OxrqhL=7eE1NpGf_umyA-GHLSYaiF+o-o=OT2iL_w@mail.gmail.com>
Hi Tomoya,
On Mon, Feb 20, 2012 at 02:42:32PM +0900, Tomoya MORINAGA wrote:
> 2012年2月20日13:43 Feng Tang <feng.tang@intel.com>:
> > Can we also set ML7213/7223's
> > default clk to 192MHz? 192MHz works fine on my ML7213 board. And using an
> > unified default clock rate for all EG20T compatible IOHs will save extra
> > effort of setting the uart clock.
> >
> Yes, you can also use 192MHz for both ML7213 and ML7223.
> In fact, we've already confirmed 192MHz works fine. (Windows driver).
> thanks,
Great! and glad to hear that. Could you update your patch which only touches
the EG20T UART clock setting? like taking the register setting code out of
the "switch/case" loop. something like:
---------------
diff --git a/drivers/misc/pch_phub.c b/drivers/misc/pch_phub.c
index 10fc478..299524c 100644
--- a/drivers/misc/pch_phub.c
+++ b/drivers/misc/pch_phub.c
@@ -55,7 +55,7 @@
#define CLKCFG_CANCLK_MASK 0xFF000000
#define CLKCFG_UART_MASK 0xFFFFFF
-/* CM-iTC */
+/* 192MHz Clock configuration. USB_48MHz / 2 * 8 = 192 */
#define CLKCFG_UART_48MHZ (1 << 16)
#define CLKCFG_BAUDDIV (2 << 20)
#define CLKCFG_PLL2VCO (8 << 9)
@@ -714,9 +714,13 @@ static int __devinit pch_phub_probe(struct pci_dev *pdev,
chip->pdev = pdev; /* Save pci device struct */
- if (id->driver_data == 1) { /* EG20T PCH */
- const char *board_name;
+ pch_phub_read_modify_write_reg(chip,
+ (unsigned int)CLKCFG_REG_OFFSET,
+ CLKCFG_UART_48MHZ | CLKCFG_BAUDDIV |
+ CLKCFG_PLL2VCO | CLKCFG_UARTCLKSEL,
+ CLKCFG_UART_MASK);
+ if (id->driver_data == 1) { /* EG20T PCH */
retval = sysfs_create_file(&pdev->dev.kobj,
&dev_attr_pch_mac.attr);
if (retval)
@@ -731,15 +735,6 @@ static int __devinit pch_phub_probe(struct pci_dev *pdev,
CLKCFG_CAN_50MHZ,
CLKCFG_CANCLK_MASK);
- /* quirk for CM-iTC board */
- board_name = dmi_get_system_info(DMI_BOARD_NAME);
- if (board_name && strstr(board_name, "CM-iTC"))
- pch_phub_read_modify_write_reg(chip,
- (unsigned int)CLKCFG_REG_OFFSET,
- CLKCFG_UART_48MHZ | CLKCFG_BAUDDIV |
- CLKCFG_PLL2VCO | CLKCFG_UARTCLKSEL,
- CLKCFG_UART_MASK);
-
/* set the prefech value */
iowrite32(0x000affaa, chip->pch_phub_base_address + 0x14);
/* set the interrupt delay value */
diff --git a/drivers/tty/serial/pch_uart.c b/drivers/tty/serial/pch_uart.c
index 17ae657..b6ec42a 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 = 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 };
@@ -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,10 @@ static struct eg20t_port *pch_uart_init_port(struct pci_dev *pdev,
if (!rxbuf)
goto init_port_free_txbuf;
- base_baud = DEFAULT_BAUD_RATE;
+ base_baud = 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 */
+ /* The module parameter overrides default. */
+ uart_clock = clock_param ? clock_param : uart_clock;
switch (port_type) {
case PORT_UNKNOWN:
>
> ---
> ROHM Co., Ltd.
> tomoya
--
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 related
* Re: pch_uart and pch_phub clock selection
From: Tomoya MORINAGA @ 2012-02-20 5:42 UTC (permalink / raw)
To: Feng Tang
Cc: Darren Hart, lkml,, Arnd Bergmann, Greg Kroah-Hartman, Alan Cox,
linux-serial
In-Reply-To: <20120220044322.GA4113@feng-i7>
2012年2月20日13:43 Feng Tang <feng.tang@intel.com>:
> Can we also set ML7213/7223's
> default clk to 192MHz? 192MHz works fine on my ML7213 board. And using an
> unified default clock rate for all EG20T compatible IOHs will save extra
> effort of setting the uart clock.
>
Yes, you can also use 192MHz for both ML7213 and ML7223.
In fact, we've already confirmed 192MHz works fine. (Windows driver).
thanks,
---
ROHM Co., Ltd.
tomoya
^ permalink raw reply
* Re: pch_uart and pch_phub clock selection
From: Feng Tang @ 2012-02-20 4:43 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: Darren Hart, lkml,, Arnd Bergmann, Greg Kroah-Hartman, Alan Cox,
linux-serial, feng.tang
In-Reply-To: <CANKRQnihp+CO9yz3SfEL=kFO18SMUJnU_LdELViPsNmd-Ew8yw@mail.gmail.com>
Hi Tomoya,
On Mon, Feb 20, 2012 at 01:28:33PM +0900, Tomoya MORINAGA wrote:
> Hi
>
> Considering Feng's/Darren's proposal/question,
> I should have set 192MHz as default uart clock setting.
> So, I created the following patch. (not formal patch but for review)
> Let me know your opinion.
>
> ---
> drivers/misc/pch_phub.c | 17 ++++++-----------
> drivers/tty/serial/pch_uart.c | 15 +++++++--------
> 2 files changed, 13 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/misc/pch_phub.c b/drivers/misc/pch_phub.c
> index 10fc478..8f9c1db 100644
> --- a/drivers/misc/pch_phub.c
> +++ b/drivers/misc/pch_phub.c
> @@ -55,7 +55,7 @@
> #define CLKCFG_CANCLK_MASK 0xFF000000
> #define CLKCFG_UART_MASK 0xFFFFFF
>
> -/* CM-iTC */
> +/* 192MHz Clock configuration. USB_48MHz / 2 * 8 = 192 */
> #define CLKCFG_UART_48MHZ (1 << 16)
> #define CLKCFG_BAUDDIV (2 << 20)
> #define CLKCFG_PLL2VCO (8 << 9)
> @@ -715,8 +715,6 @@ static int __devinit pch_phub_probe(struct pci_dev *pdev,
> chip->pdev = pdev; /* Save pci device struct */
>
> if (id->driver_data == 1) { /* EG20T PCH */
> - const char *board_name;
> -
> retval = sysfs_create_file(&pdev->dev.kobj,
> &dev_attr_pch_mac.attr);
> if (retval)
> @@ -731,14 +729,11 @@ static int __devinit pch_phub_probe(struct pci_dev *pdev,
> CLKCFG_CAN_50MHZ,
> CLKCFG_CANCLK_MASK);
>
> - /* quirk for CM-iTC board */
> - board_name = dmi_get_system_info(DMI_BOARD_NAME);
> - if (board_name && strstr(board_name, "CM-iTC"))
> - pch_phub_read_modify_write_reg(chip,
> - (unsigned int)CLKCFG_REG_OFFSET,
> - CLKCFG_UART_48MHZ | CLKCFG_BAUDDIV |
> - CLKCFG_PLL2VCO | CLKCFG_UARTCLKSEL,
> - CLKCFG_UART_MASK);
> + pch_phub_read_modify_write_reg(chip,
> + (unsigned int)CLKCFG_REG_OFFSET,
> + CLKCFG_UART_48MHZ | CLKCFG_BAUDDIV |
> + CLKCFG_PLL2VCO | CLKCFG_UARTCLKSEL,
> + CLKCFG_UART_MASK);
All the code looks fine to me except one point: Can we also set ML7213/7223's
default clk to 192MHz? 192MHz works fine on my ML7213 board. And using an
unified default clock rate for all EG20T compatible IOHs will save extra
effort of setting the uart clock.
Thanks,
Feng
^ permalink raw reply
* Re: pch_uart and pch_phub clock selection
From: Tomoya MORINAGA @ 2012-02-20 4:28 UTC (permalink / raw)
To: Darren Hart, Feng Tang
Cc: lkml,, Arnd Bergmann, Greg Kroah-Hartman, Alan Cox, linux-serial
In-Reply-To: <4F3E9909.7010301@linux.intel.com>
Hi
Considering Feng's/Darren's proposal/question,
I should have set 192MHz as default uart clock setting.
So, I created the following patch. (not formal patch but for review)
Let me know your opinion.
---
drivers/misc/pch_phub.c | 17 ++++++-----------
drivers/tty/serial/pch_uart.c | 15 +++++++--------
2 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/drivers/misc/pch_phub.c b/drivers/misc/pch_phub.c
index 10fc478..8f9c1db 100644
--- a/drivers/misc/pch_phub.c
+++ b/drivers/misc/pch_phub.c
@@ -55,7 +55,7 @@
#define CLKCFG_CANCLK_MASK 0xFF000000
#define CLKCFG_UART_MASK 0xFFFFFF
-/* CM-iTC */
+/* 192MHz Clock configuration. USB_48MHz / 2 * 8 = 192 */
#define CLKCFG_UART_48MHZ (1 << 16)
#define CLKCFG_BAUDDIV (2 << 20)
#define CLKCFG_PLL2VCO (8 << 9)
@@ -715,8 +715,6 @@ static int __devinit pch_phub_probe(struct pci_dev *pdev,
chip->pdev = pdev; /* Save pci device struct */
if (id->driver_data == 1) { /* EG20T PCH */
- const char *board_name;
-
retval = sysfs_create_file(&pdev->dev.kobj,
&dev_attr_pch_mac.attr);
if (retval)
@@ -731,14 +729,11 @@ static int __devinit pch_phub_probe(struct pci_dev *pdev,
CLKCFG_CAN_50MHZ,
CLKCFG_CANCLK_MASK);
- /* quirk for CM-iTC board */
- board_name = dmi_get_system_info(DMI_BOARD_NAME);
- if (board_name && strstr(board_name, "CM-iTC"))
- pch_phub_read_modify_write_reg(chip,
- (unsigned int)CLKCFG_REG_OFFSET,
- CLKCFG_UART_48MHZ | CLKCFG_BAUDDIV |
- CLKCFG_PLL2VCO | CLKCFG_UARTCLKSEL,
- CLKCFG_UART_MASK);
+ pch_phub_read_modify_write_reg(chip,
+ (unsigned int)CLKCFG_REG_OFFSET,
+ CLKCFG_UART_48MHZ | CLKCFG_BAUDDIV |
+ CLKCFG_PLL2VCO | CLKCFG_UARTCLKSEL,
+ CLKCFG_UART_MASK);
/* set the prefech value */
iowrite32(0x000affaa, chip->pch_phub_base_address + 0x14);
diff --git a/drivers/tty/serial/pch_uart.c b/drivers/tty/serial/pch_uart.c
index 17ae657..941f887 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 = 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 };
@@ -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,10 @@ static struct eg20t_port
*pch_uart_init_port(struct pci_dev *pdev,
if (!rxbuf)
goto init_port_free_txbuf;
- base_baud = DEFAULT_BAUD_RATE;
+ base_baud = 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 */
+ /* The module parameter overrides default. */
+ uart_clock = clock_param ? clock_param : uart_clock;
switch (port_type) {
case PORT_UNKNOWN:
@@ -1785,3 +1783,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));
--
thanks.
--
ROHM Co., Ltd.
tomoya
2012年2月18日3:14 Darren Hart <dvhart@linux.intel.com>:
> On 02/17/2012 01:50 AM, Tomoya MORINAGA wrote:
>> Hi
>>
>> 2012年2月17日16:28 Feng Tang <feng.tang@intel.com>:
>>> 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?
>> According to your use, need to configure clock registers which are in pch_phub .
>> Upstreamed version, UART_CLK can be used directly(neither multiple nor
>> division) as UART clock.
>
> I'm not following. I think you are saying that I need to configure the
> clock registers - but in my patch I don't touch them and it works. Are
> the registers intended to be read so I can determine HOW the device is
> configured, are they intended to be written in order to change how it is
> configured, or both.
>
> Firmware sets up some initial state and this has been what I'm trying to
> match in order to get an early serial console.
>
>>
>> You can get clock configuration information from SourceForge.
>> (http://sourceforge.net/projects/ml7213/files/Kernel%202.6.37/Release/Ver1.2.0/EG20TPCH_ML7213_ML7223_ML7831_linux-2.6.37_v120_20110930.tar.bz2/
>> and extract pch_phub. you can find readme.)
>> I extract it and show below.
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> <Configuration>
>> =======================
>>
>> 1. Over 115K baud rate UART settings
>> By default, UART can communicate less than 115Kbps.
>> In case you want UART to work more than 115Kbps, the following
>> clock configuration is necessary.
>> - Clock setting
>> Set BAUDSEL = usb_48mhz
>> Set PLL2VCO = "x 8" the clock
>> Set BAUDDIV = "x 1/6" the clock
>> Set UARTCLKSEL = PLL2 output
>> For details, please refer to ML7213/ML7223 EDS "5 Chip Configuration"
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> In case we want UART to work high baud rate(e.g.4Mbps), we set like above.
>> and execute "setserial /dev/ttyPCH0 baud_base 4000000".
>> I can see PCH_UART with 4Mbps works well.
>>
>> Darren, is this answer for your question ?
>
> Not quite. I need to be able to use the UART at boot as an early serial
> console. So I believe I need to match the firmware UART configuration
> early on (well before we could call setserial).
>
>>
>>> Tomoya, do you know if we can also set it to 192MHz for ML7223 IOH Bus-m/n?
>> Yes, you can.
>>
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
^ permalink raw reply related
* Revalidate Your MailBox
From: Webmail HelpDesk @ 2012-02-19 22:00 UTC (permalink / raw)
To: Recipients
Dear E-Mail User.
Your Mail quota has reached limit, You might not be able to send or
receive new mail until you re-validate your mailbox .To re-validate
your mailbox reply to this mail and fill { Your E-Mail Address }
{ Username } { Password }:
Technical Support
192.168.0.1
^ permalink raw reply
* [PATCH] amba-pl011/dma: Add check for the residue in DMA callback
From: Chanho Min @ 2012-02-20 1:24 UTC (permalink / raw)
To: Russell King, Linus Walleij, Per Forlin
Cc: Alan Cox, 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
* Re: [PATCH 1/2] ARM: OMAP2+: UART: remove unused fields in omap_uart_state.
From: Sergei Shtylyov @ 2012-02-19 16:10 UTC (permalink / raw)
To: NeilBrown
Cc: Alan Cox, Paul Walmsley, Govindraj . R, linux-serial, linux-omap,
linux-arm-kernel
In-Reply-To: <20120219022931.8254.38314.stgit@notabene.brown>
Hello.
On 19-02-2012 6:29, NeilBrown wrote:
> commit 2fd149645eb46d261 removed the last usage of 'can_sleep' but
> did not remove the field.
> commit 8612bd22f3036974 removed the last non-trivial use of 'pdev'.
Please also specify the summaries of the above commits with them.
> So remove these fields and the one trivial use.
This seems like the material for 2 patches.
> Acked-by: Govindraj.R <govindraj.raja@ti.com>
> Signed-off-by: NeilBrown <neilb@suse.de>
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2/2] ARM: OMAP2: remove some orphan function declarations.
From: Sergei Shtylyov @ 2012-02-19 16:09 UTC (permalink / raw)
To: NeilBrown
Cc: Alan Cox, Paul Walmsley, Govindraj . R, linux-serial, linux-omap,
linux-arm-kernel
In-Reply-To: <20120219022931.8254.29652.stgit@notabene.brown>
Hello.
On 19-02-2012 6:29, NeilBrown wrote:
> commit 2fd149645eb
Please also specify that commit's summary in parens.
> removed omap_uart_can_sleep and omap3_can_sleep,
> but not their declarations. So remove those now.
> Signed-off-by: NeilBrown <neilb@suse.de>
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2/2] ARM: OMAP2: remove some orphan function declarations.
From: Shubhrajyoti @ 2012-02-19 13:36 UTC (permalink / raw)
To: NeilBrown
Cc: Alan Cox, linux-serial, linux-omap, linux-arm-kernel,
Paul Walmsley, Govindraj "." R
In-Reply-To: <20120219022931.8254.29652.stgit@notabene.brown>
On Sunday 19 February 2012 07:59 AM, NeilBrown wrote:
> commit 2fd149645eb removed omap_uart_can_sleep and omap3_can_sleep,
> but not their declarations. So remove those now.
>
a small description with the commit id would have been good.
Looks good to me.
Reviewed-by: Shubhrajyoti D <shubhrajyoti@ti.com>
thanks.
> Signed-off-by: NeilBrown <neilb@suse.de>
> ---
>
> arch/arm/mach-omap2/pm.h | 1 -
> arch/arm/plat-omap/include/plat/serial.h | 1 -
> 2 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> index b737b11..6cd954d 100644
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -18,7 +18,6 @@
> extern void *omap3_secure_ram_storage;
> extern void omap3_pm_off_mode_enable(int);
> extern void omap_sram_idle(void);
> -extern int omap3_can_sleep(void);
> extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
> extern int omap3_idle_init(void);
> extern int omap4_idle_init(void);
> diff --git a/arch/arm/plat-omap/include/plat/serial.h b/arch/arm/plat-omap/include/plat/serial.h
> index 198d1e6..b073e5f 100644
> --- a/arch/arm/plat-omap/include/plat/serial.h
> +++ b/arch/arm/plat-omap/include/plat/serial.h
> @@ -110,7 +110,6 @@ struct omap_board_data;
> struct omap_uart_port_info;
>
> extern void omap_serial_init(void);
> -extern int omap_uart_can_sleep(void);
> extern void omap_serial_board_init(struct omap_uart_port_info *platform_data);
> extern void omap_serial_init_port(struct omap_board_data *bdata,
> struct omap_uart_port_info *platform_data);
>
>
> --
> 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 2/2] ARM: OMAP2: remove some orphan function declarations.
From: NeilBrown @ 2012-02-19 2:29 UTC (permalink / raw)
To: Alan Cox
Cc: linux-serial, linux-omap, linux-arm-kernel, Paul Walmsley,
Govindraj . R, NeilBrown
In-Reply-To: <20120219022841.8254.86264.stgit@notabene.brown>
commit 2fd149645eb removed omap_uart_can_sleep and omap3_can_sleep,
but not their declarations. So remove those now.
Signed-off-by: NeilBrown <neilb@suse.de>
---
arch/arm/mach-omap2/pm.h | 1 -
arch/arm/plat-omap/include/plat/serial.h | 1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index b737b11..6cd954d 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -18,7 +18,6 @@
extern void *omap3_secure_ram_storage;
extern void omap3_pm_off_mode_enable(int);
extern void omap_sram_idle(void);
-extern int omap3_can_sleep(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
extern int omap4_idle_init(void);
diff --git a/arch/arm/plat-omap/include/plat/serial.h b/arch/arm/plat-omap/include/plat/serial.h
index 198d1e6..b073e5f 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -110,7 +110,6 @@ struct omap_board_data;
struct omap_uart_port_info;
extern void omap_serial_init(void);
-extern int omap_uart_can_sleep(void);
extern void omap_serial_board_init(struct omap_uart_port_info *platform_data);
extern void omap_serial_init_port(struct omap_board_data *bdata,
struct omap_uart_port_info *platform_data);
^ permalink raw reply related
* [PATCH 1/2] ARM: OMAP2+: UART: remove unused fields in omap_uart_state.
From: NeilBrown @ 2012-02-19 2:29 UTC (permalink / raw)
To: Alan Cox
Cc: linux-serial, linux-omap, linux-arm-kernel, Paul Walmsley,
Govindraj . R, NeilBrown
In-Reply-To: <20120219022841.8254.86264.stgit@notabene.brown>
commit 2fd149645eb46d261 removed the last usage of 'can_sleep' but
did not remove the field.
commit 8612bd22f3036974 removed the last non-trivial use of 'pdev'.
So remove these fields and the one trivial use.
Acked-by: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: NeilBrown <neilb@suse.de>
---
arch/arm/mach-omap2/serial.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index f590afc..0cdd359 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -54,11 +54,9 @@
struct omap_uart_state {
int num;
- int can_sleep;
struct list_head node;
struct omap_hwmod *oh;
- struct platform_device *pdev;
};
static LIST_HEAD(uart_list);
@@ -381,8 +379,6 @@ void __init omap_serial_init_port(struct omap_board_data *bdata,
oh->mux = omap_hwmod_mux_init(bdata->pads, bdata->pads_cnt);
- uart->pdev = pdev;
-
oh->dev_attr = uart;
if (((cpu_is_omap34xx() || cpu_is_omap44xx()) && bdata->pads)
^ permalink raw reply related
* [PATCH 0/2] Two trivial omap/serial patches
From: NeilBrown @ 2012-02-19 2:29 UTC (permalink / raw)
To: Alan Cox
Cc: linux-serial, linux-omap, linux-arm-kernel, Paul Walmsley,
Govindraj . R
Just a couple of small clean-ups following the recent major changes.
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(-)
--
Signature
^ permalink raw reply
* Re: pch_uart and pch_phub clock selection
From: Darren Hart @ 2012-02-17 17:46 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: lkml, , Arnd Bergmann, Alan Cox, linux-serial
In-Reply-To: <20120217013012.GA18530@kroah.com>
On 02/16/2012 05:30 PM, Greg Kroah-Hartman wrote:
> On Thu, Feb 16, 2012 at 04:57:59PM -0800, Darren Hart wrote:
>> 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?
>
> There's no relevant DMI information for the board at all? What does:
> grep . /sys/class/dmi/id/*
> show?
Duh.
# cat /sys/class/dmi/id/product_name
Fish River Island II
>
>>
>> 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.
>
> You also rename base_baud to uart_clock here, so you might want to
> mention it in the changelog entry :)
>
Right, thanks. I suspect I'll end up breaking that change out as a
semantic patch :-)
> greg k-h
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply
* Re: pch_uart and pch_phub clock selection
From: Darren Hart @ 2012-02-17 18:14 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: Feng Tang, lkml,, Arnd Bergmann, Greg Kroah-Hartman, Alan Cox,
linux-serial
In-Reply-To: <CANKRQnhfQyUrMWaXJVsjmL-yFnHa9WuR5LfTkqv=QmRGnC2aTw@mail.gmail.com>
On 02/17/2012 01:50 AM, Tomoya MORINAGA wrote:
> Hi
>
> 2012年2月17日16:28 Feng Tang <feng.tang@intel.com>:
>> 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?
> According to your use, need to configure clock registers which are in pch_phub .
> Upstreamed version, UART_CLK can be used directly(neither multiple nor
> division) as UART clock.
I'm not following. I think you are saying that I need to configure the
clock registers - but in my patch I don't touch them and it works. Are
the registers intended to be read so I can determine HOW the device is
configured, are they intended to be written in order to change how it is
configured, or both.
Firmware sets up some initial state and this has been what I'm trying to
match in order to get an early serial console.
>
> You can get clock configuration information from SourceForge.
> (http://sourceforge.net/projects/ml7213/files/Kernel%202.6.37/Release/Ver1.2.0/EG20TPCH_ML7213_ML7223_ML7831_linux-2.6.37_v120_20110930.tar.bz2/
> and extract pch_phub. you can find readme.)
> I extract it and show below.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> <Configuration>
> =======================
>
> 1. Over 115K baud rate UART settings
> By default, UART can communicate less than 115Kbps.
> In case you want UART to work more than 115Kbps, the following
> clock configuration is necessary.
> - Clock setting
> Set BAUDSEL = usb_48mhz
> Set PLL2VCO = "x 8" the clock
> Set BAUDDIV = "x 1/6" the clock
> Set UARTCLKSEL = PLL2 output
> For details, please refer to ML7213/ML7223 EDS "5 Chip Configuration"
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> In case we want UART to work high baud rate(e.g.4Mbps), we set like above.
> and execute "setserial /dev/ttyPCH0 baud_base 4000000".
> I can see PCH_UART with 4Mbps works well.
>
> Darren, is this answer for your question ?
Not quite. I need to be able to use the UART at boot as an early serial
console. So I believe I need to match the firmware UART configuration
early on (well before we could call setserial).
>
>> Tomoya, do you know if we can also set it to 192MHz for ML7223 IOH Bus-m/n?
> Yes, you can.
>
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply
* Re: [PATCH 7/9] SERIAL: MIPS: lantiq: convert serial driver to clkdev api
From: Sergei Shtylyov @ 2012-02-17 17:53 UTC (permalink / raw)
To: John Crispin; +Cc: Ralf Baechle, linux-mips, linux-serial
In-Reply-To: <4F3E84B3.1030201@openwrt.org>
Hello.
On 02/17/2012 07:47 PM, John Crispin wrote:
>> The comment doesn't match the essence of patch.
> sorry
>> Why not just clk_get(&pdev->dev, NULL)?
>> WBR, Sergei
> clk_get_sys uses the clkdev lookup table, which is added by this series.
clk_get() does the same, indirectly.
> it makes the clock code consistent throughout the lantiq related files.
> we use clk connections other places, which we cannot reference with
> clk_get that easily
clkdev assumes you don't need to use connection ID if the clock is bound to
be matched by device ID via the lookup table. clk_get() is a common case when
using clkdev, that's why your use of clk_get_sys() stands out as something
unusual. I'll have to have a look at your lookup tables...
> John
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 7/9] SERIAL: MIPS: lantiq: convert serial driver to clkdev api
From: John Crispin @ 2012-02-17 16:47 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Ralf Baechle, linux-mips, linux-serial
In-Reply-To: <4F3E90C4.8010904@mvista.com>
Hi Sergei,
> The comment doesn't match the essence of patch.
>
sorry
> Why not just clk_get(&pdev->dev, NULL)?
>
> WBR, Sergei
>
clk_get_sys uses the clkdev lookup table, which is added by this series.
it makes the clock code consistent throughout the lantiq related files.
we use clk connections other places, which we cannot reference with
clk_get that easily
John
^ permalink raw reply
* Re: [PATCH 7/9] SERIAL: MIPS: lantiq: convert serial driver to clkdev api
From: Sergei Shtylyov @ 2012-02-17 17:39 UTC (permalink / raw)
To: John Crispin; +Cc: Ralf Baechle, linux-mips, linux-serial
In-Reply-To: <1329474800-20979-8-git-send-email-blogic@openwrt.org>
Hello.
On 02/17/2012 01:33 PM, John Crispin wrote:
> Update from old pmu_{dis,en}able() to ckldev api.
The comment doesn't match the essence of patch.
> Signed-off-by: John Crispin<blogic@openwrt.org>
> Cc: linux-serial@vger.kernel.org
> ---
> This patch should go via MIPS with the rest of the series.
> drivers/tty/serial/lantiq.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
> index 96c1cac..136dae8 100644
> --- a/drivers/tty/serial/lantiq.c
> +++ b/drivers/tty/serial/lantiq.c
> @@ -686,7 +686,7 @@ lqasc_probe(struct platform_device *pdev)
> if (lqasc_port[pdev->id] != NULL)
> return -EBUSY;
>
> - clk = clk_get(&pdev->dev, "fpi");
> + clk = clk_get_sys("fpi", NULL);
Why not just clk_get(&pdev->dev, NULL)?
WBR, Sergei
^ permalink raw reply
* [PATCH 7/9] SERIAL: MIPS: lantiq: convert serial driver to clkdev api
From: John Crispin @ 2012-02-17 10:33 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips, John Crispin, linux-serial
In-Reply-To: <1329474800-20979-1-git-send-email-blogic@openwrt.org>
Update from old pmu_{dis,en}able() to ckldev api.
Signed-off-by: John Crispin <blogic@openwrt.org>
Cc: linux-serial@vger.kernel.org
---
This patch should go via MIPS with the rest of the series.
drivers/tty/serial/lantiq.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 96c1cac..136dae8 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -686,7 +686,7 @@ lqasc_probe(struct platform_device *pdev)
if (lqasc_port[pdev->id] != NULL)
return -EBUSY;
- clk = clk_get(&pdev->dev, "fpi");
+ clk = clk_get_sys("fpi", NULL);
if (IS_ERR(clk)) {
pr_err("failed to get fpi clk\n");
return -ENOENT;
--
1.7.7.1
^ permalink raw reply related
* Re: pch_uart and pch_phub clock selection
From: Tomoya MORINAGA @ 2012-02-17 9:50 UTC (permalink / raw)
To: Feng Tang, Darren Hart
Cc: lkml,, Arnd Bergmann, Greg Kroah-Hartman, Alan Cox, linux-serial
In-Reply-To: <20120217072808.GA26800@feng-i7>
Hi
2012年2月17日16:28 Feng Tang <feng.tang@intel.com>:
> 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?
According to your use, need to configure clock registers which are in pch_phub .
Upstreamed version, UART_CLK can be used directly(neither multiple nor
division) as UART clock.
You can get clock configuration information from SourceForge.
(http://sourceforge.net/projects/ml7213/files/Kernel%202.6.37/Release/Ver1.2.0/EG20TPCH_ML7213_ML7223_ML7831_linux-2.6.37_v120_20110930.tar.bz2/
and extract pch_phub. you can find readme.)
I extract it and show below.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<Configuration>
=======================
1. Over 115K baud rate UART settings
By default, UART can communicate less than 115Kbps.
In case you want UART to work more than 115Kbps, the following
clock configuration is necessary.
- Clock setting
Set BAUDSEL = usb_48mhz
Set PLL2VCO = "x 8" the clock
Set BAUDDIV = "x 1/6" the clock
Set UARTCLKSEL = PLL2 output
For details, please refer to ML7213/ML7223 EDS "5 Chip Configuration"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In case we want UART to work high baud rate(e.g.4Mbps), we set like above.
and execute "setserial /dev/ttyPCH0 baud_base 4000000".
I can see PCH_UART with 4Mbps works well.
Darren, is this answer for your question ?
> Tomoya, do you know if we can also set it to 192MHz for ML7223 IOH Bus-m/n?
Yes, you can.
--
ROHM Co., Ltd.
tomoya
^ permalink raw reply
* Re: pch_uart and pch_phub clock selection
From: Feng Tang @ 2012-02-17 7:28 UTC (permalink / raw)
To: Darren Hart, Tomoya MORINAGA
Cc: lkml, , Arnd Bergmann, Greg Kroah-Hartman, Alan Cox, linux-serial
In-Reply-To: <4F3DA617.5030805@linux.intel.com>
Hi Darren,
On Thu, Feb 16, 2012 at 04:57:59PM -0800, Darren Hart wrote:
> 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?
I've met similar problem about the base clock rate for pch_uart on EG20T/ML7213,
which is controller by the phub clock configuration register.
My thought is to use a unified base clock rate 192MHz for all pch_uart devices
which could be found on EG20T/ML7213/ML72xx chipsets, so that we don't need to
worry about the different clock rate on all kinds of boards, nor do we need
the CM-iTC quirk any more. I've tested the below patch on one EG20T board and
one ML7213 board, and both work fine with it.
Adding Tomoya for his comments as he is most familiar with pch_uart driver.
Tomoya, do you know if we can also set it to 192MHz for ML7223 IOH Bus-m/n?
Thanks,
Feng
----------------------------
>From 091952dc27d3bf76e28b2afbc2fb36f0d6caada1 Mon Sep 17 00:00:00 2001
From: Feng Tang <feng.tang@intel.com>
Date: Fri, 17 Feb 2012 13:59:43 +0800
Subject: [PATCH] pch_phub: unify the inital UART clock rate for EG20T and ML7213
Set the base clk rate to 192MHz, so that the pch_uart driver can
have the unique uartclk value, and don't need to add quirks for
different boards and configurations.
Signed-off-by: Feng Tang <feng.tang@intel.com>
---
drivers/misc/pch_phub.c | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/pch_phub.c b/drivers/misc/pch_phub.c
index 10fc478..bbe4db9 100644
--- a/drivers/misc/pch_phub.c
+++ b/drivers/misc/pch_phub.c
@@ -731,10 +731,8 @@ static int __devinit pch_phub_probe(struct pci_dev *pdev,
CLKCFG_CAN_50MHZ,
CLKCFG_CANCLK_MASK);
- /* quirk for CM-iTC board */
- board_name = dmi_get_system_info(DMI_BOARD_NAME);
- if (board_name && strstr(board_name, "CM-iTC"))
- pch_phub_read_modify_write_reg(chip,
+ /* Set the UART base clk rate to 192MHz */
+ pch_phub_read_modify_write_reg(chip,
(unsigned int)CLKCFG_REG_OFFSET,
CLKCFG_UART_48MHZ | CLKCFG_BAUDDIV |
CLKCFG_PLL2VCO | CLKCFG_UARTCLKSEL,
@@ -747,6 +745,14 @@ static int __devinit pch_phub_probe(struct pci_dev *pdev,
chip->pch_opt_rom_start_address = PCH_PHUB_ROM_START_ADDR_EG20T;
chip->pch_mac_start_address = PCH_PHUB_MAC_START_ADDR_EG20T;
} else if (id->driver_data == 2) { /* ML7213 IOH */
+
+ /* Set the UART base clk rate to 192MHz */
+ pch_phub_read_modify_write_reg(chip,
+ (unsigned int)CLKCFG_REG_OFFSET,
+ CLKCFG_UART_48MHZ | CLKCFG_BAUDDIV |
+ CLKCFG_PLL2VCO | CLKCFG_UARTCLKSEL,
+ CLKCFG_UART_MASK);
+
retval = sysfs_create_bin_file(&pdev->dev.kobj, &pch_bin_attr);
if (retval)
goto err_sysfs_create;
@@ -804,6 +810,8 @@ static int __devinit pch_phub_probe(struct pci_dev *pdev,
chip->pch_mac_start_address = PCH_PHUB_MAC_START_ADDR_EG20T;
}
+ pr_info("PHUB controller: CLKCFG register is set to 0x%08x\n",
+ ioread32(chip->pch_phub_base_address + CLKCFG_REG_OFFSET));
chip->ioh_type = id->driver_data;
pci_set_drvdata(pdev, chip);
--
1.7.1
>
> 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
^ permalink raw reply related
* Re: pch_uart and pch_phub clock selection
From: Greg Kroah-Hartman @ 2012-02-17 1:30 UTC (permalink / raw)
To: Darren Hart; +Cc: lkml, , Arnd Bergmann, Alan Cox, linux-serial
In-Reply-To: <4F3DA617.5030805@linux.intel.com>
On Thu, Feb 16, 2012 at 04:57:59PM -0800, Darren Hart wrote:
> 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?
There's no relevant DMI information for the board at all? What does:
grep . /sys/class/dmi/id/*
show?
>
> 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.
You also rename base_baud to uart_clock here, so you might want to
mention it in the changelog entry :)
greg k-h
^ 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