gmane.linux.serial

Re: [PATCH 6/6] serial: add amba-pl011-pci

Russell King - ARM Linux — 2012-05-26T08:43:28

I don't think we want to encourage an ever growing list of platforms
here.  If we did this on ARM, this would be hellishly long.


NAK.  We have interfaces in the AMBA code for dynamically allocating
AMBA devices now - please use them instead of coding your own.  They
avoid bugs.


This looks like debugging.


This comes nowhere close to being sane with the driver model.  This is
an oops waiting to happen.  You can't guarantee that 'adev' will be
unused by the time amba_device_unregister() (or in fact any such call
into the driver model) returns.

This is because these suckers (and all devices) are refcounted.  If you
use the correct interfaces, the devices will be freed for you automatically
at the correct time.

The only thing that won't be is adev->dev.platform_data - the correct way
to do this is the following along with the correct allocation interfaces:

struct amba_device *adev = pci_get_drvdata(pdev);
void *priv = adev->dev.platform_data;

amba_device_unregister(adev);
kfree(priv);

In other wor

Re: [PATCH 6/6] serial: add amba-pl011-pci

Arnd Bergmann — 2012-05-26T08:29:19

Yes, they all look good to me, although patch 5 would have to change
if you do patch 6 the way we discussed here.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 11/15] serial: mxs-auart: Use clk_prepare_enable/clk_disable_unprepare

Fabio Estevam — 2012-05-25T23:14:52

From: Fabio Estevam <fabio.estevam< at >freescale.com>

Prepare the clock before enabling it.

Cc: Alan Cox <alan< at >linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh< at >linuxfoundation.org>
Cc: <linux-serial< at >vger.kernel.org>
Signed-off-by: Fabio Estevam <fabio.estevam< at >freescale.com>
---
 drivers/tty/serial/mxs-auart.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index ec56d83..c109642 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
< at >< at > -552,7 +552,7 < at >< at > auart_console_write(struct console *co, const char *str, unsigned int count)
 s = auart_port[co->index];
 port = &s->port;
 
-clk_enable(s->clk);
+clk_prepare_enable(s->clk);
 
 /* First save the CR then disable the interrupts */
 old_ctrl2 = readl(port->membase + AUART_CTRL2);
< at >< at > -578,7 +578,7 < at >< at > auart_console_write(struct console *co, const char *str, unsigned int count)
 writel(old_ctrl0, port->membase + AUART_CTRL0);
 writel(old_ctrl2,

[PATCH 0/6] Bridging PCI to amba

Alessandro Rubini — 2012-05-25T15:47:48

This patch set introduces use of the pl011 AMBA serial port under a
PCI bridge.  To compile AMBA under x86, though I need <asm/sizes.h>,
which is moved to <linux/sizes.h> as suggested earlier.

I'm hereby volunteering to handle the moving of the various users
of <asm/sizes.h> to <linux/sizes.h>; this set only moves the ARM core
files and the ones that I need under x86.

The whole patch set is sent to the same set of recipients:
all relevant lists, Russell King (for arm), Greg-KH (for uart) and
Arnd Bergmann (for generic include).

With this set in place (plus a clok API not included here) I have
4 serial ports working. We have a number of other devices that can
use existing drivers, but we definitely need <linux/sizes.h> first.

  spusa.root# uname -r
  3.4.0-next-20120524-00014-gae0c129

  spusa.root# dmesg | grep ttyA
  pl011-pci-03:0005: ttyAMA0 at MMIO 0xcf400000 (irq = 46) is a PL011 rev3
  pl011-pci-03:0006: ttyAMA1 at MMIO 0xcec00000 (irq = 47) is a PL011 rev3
  pl011-pci-03:0007: ttyAMA2 at MMIO 0xce

Re: [PATCH] serial/amba-pl011: move custom pin control to driver

Shawn Guo — 2012-05-25T06:26:09

On imx28:

Tested-by: Shawn Guo <shawn.guo< at >linaro.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: struct tty_flip_buffer replacement in newer kernels

Alan Cox — 2012-05-24T16:00:25

On Thu, 24 May 2012 08:05:12 -0700 (PDT)
Dmitriy Alekseev <alexeev6< at >yahoo.com> wrote:


You may have to stick some traces into drivers/tty/8250.c at this point
and see what is going on. It's clearly trying to do the set up right, and
created the ports but didn't believe the hardware. That usually implies
that a parameter is wrong somewhere.

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: struct tty_flip_buffer replacement in newer kernels

Dmitriy Alekseev — 2012-05-24T15:05:12

The link I gave is original source, which I afterwards changed according to my parameters - clock and processor memory map.

You right about offset 0x8, this is offset between ports in my 68 mode, I corrected, but it doesn't give any result.

 
Best regards,
Dmitriy Alekseev


----- Original Message -----
From: Alan Cox <alan< at >lxorguk.ukuu.org.uk>
To: Dmitriy Alekseev <alexeev6< at >yahoo.com>
Cc: 
Sent: Thursday, May 24, 2012 5:22 PM
Subject: Re: struct tty_flip_buffer replacement in newer kernels

On Thu, 24 May 2012 03:38:42 -0700 (PDT)
Dmitriy Alekseev <alexeev6< at >yahoo.com> wrote:


That looks reasonable - UPF_IOREMAP tells the kernel to do the ioremap
for you, UPF_BOOT_AUTOCONF tries to autoconfigure the chip type


And this guides the register spacing (1 = byte spaced, 2 = word spaced, 3
= dword spaced etc)


UPIO_MEM is for MMIO, UPIO_PORT for port I/O

However the values don't look the same as the old driver you linked to -
that seems to be using 0x2800000 and then 8 byte spacing plus a 1843200
clock.

Al

Fw: struct tty_flip_buffer replacement in newer kernels

Dmitriy Alekseev — 2012-05-24T10:38:42

Hi, Alan.

Thank You very much for the answer!
So, if I understand correctly, I took for example this: arch/arm/mach-omap1/board-voiceblue.c
And made in my board specific file:
static struct plat_serial8250_port exar_ports[] = {
        {
                .mapbase        = (unsigned long)(0x30000300), // according to at91rm9200 CS2 memory map
                .flags          = UPF_BOOT_AUTOCONF | UPF_IOREMAP, // I don't know, what kind of flags is suitable for me
                .iotype         = UPIO_MEM, // similar problem
                .regshift       = 1, 
                .uartclk        = 14745600, // Our chip clock frequency
        },
        {
                .mapbase        = (unsigned long)(0x30000200),
                .flags          = UPF_BOOT_AUTOCONF | UPF_IOREMAP,
                .iotype         = UPIO_MEM,
                .regshift       = 1,
                .uartc

RE: [PATCH 1/2] serial: samsung: Remove NULL checking for baud clock

Kyoungil Kim — 2012-05-24T08:39:37

I missed following.

Russell King suggested:

As I said, drivers have no business interpreting anything but IS_ERR(clk) as being an error.  They should not make any other
assumptions.

Suggested-by: Russell King <rmk+kernel< at >arm.linux.org.uk>



--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] serial/amba-pl011: move custom pin control to driver

Linus Walleij — 2012-05-23T19:18:46

From: Linus Walleij <linus.walleij< at >linaro.org>

We had a boot regression in Ux500 in the merge window because
two orthogonal pin control schemes for the PL011 were merged
at the same time:

- One using the .init() and .exit() hooks into the platform
  for Ux500 putting the pins into default vs sleep state
  respectively as the port was started/stopped.
  commit a09806607fd20bed2f8c41fe22793386790a14aa
  "ARM: ux500: switch to using pinctrl for uart0"

- One hogging the default setting at PL011 probe()
  commit 258e055111d3cde2607e0d04eb91da2f7a59b591
  "serial: amba-pl011: adopt pinctrl support"

To get a solution that works for both let's scrap the stuff
in the platform callbacks, instead have the driver itself
select default and sleep states when the port is
started/stopped. Hopefully this works for all clients.
Platform callbacks are bad for device tree migration anyway,
so this rids us of another problem in Ux500.

Cc: linux-serial< at >vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh< at >linuxfoundation.org>
Cc: S

Re: [PATCH 1/1] serial_core: Update buffer overrun statistics.

Corbin — 2012-05-23T14:37:31


Oh, sorry about that. Here is an archived version of the email thread:
http://www.spinics.net/lists/linux-serial/msg06104.html
I'll also copy and paste my patch here:

Currently, serial drivers don't report buffer overruns. When a buffer overrun
occurs, tty_insert_flip_char returns 0, and no attempt is made to insert that
same character again (i.e. it is lost). This patch reports buffer overruns via
the buf_overrun field in the port's icount structure.

Signed-off-by: Corbin Atkinson <corbin.atkinson< at >xxxxxx>
---
 drivers/tty/serial/serial_core.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 9c4c05b..59fb3ba 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
< at >< at > -2526,14 +2526,16 < at >< at > void uart_insert_char(struct uart_port *port,
unsigned int status,
 struct tty_struct *tty = port->state->port.tty;

 if ((status & port->ignore_status_mask & ~overrun) == 0)
-tty_insert_

Re: [PATCH 1/1] serial_core: Update buffer overrun statistics.

Jiri Slaby — 2012-05-22T20:38:19

That it is perfectly concealed.

(I'm not subscribed to linux-serial and cannot find it anywhere. A link
would be appreciated...)

thanks,

Re: [PATCH 1/1] serial_core: Update buffer overrun statistics.

Corbin — 2012-05-22T20:31:15

Jiri,

What do you think of my patch?
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: struct tty_flip_buffer replacement in newer kernels

Alan Cox — 2012-05-22T16:27:00

On Tue, 22 May 2012 07:38:28 -0700 (PDT)
Dmitriy Alekseev <alexeev6< at >yahoo.com> wrote:


Why not use the in kernel 8250 driver (which will drive a stamdard
16540/550/554 as well ?)

To ressurect one you'll need to add kref handling, rework the termios code
and maybe some other bits too.

Take a look how other arm boards use struct plat_serial8250_port and the
serial8250 platform driver. You should just be able to declare the
structures and register the platform device.

Alan

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PATCH] TTY/serial patches for 3.5-rc1 - try 2

Greg KH — 2012-05-22T15:15:27

The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c:

  Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-3.5-rc1

for you to fetch changes up to 59bd234b72fc29887839d792b7d6c7e8d2a577a6:

  serial: bfin_uart: Make MMR access compatible with 32 bits bf609 style controller. (2012-05-17 13:25:56 -0700)

----------------------------------------------------------------
TTY pull request for 3.5-rc1

Here's the big TTY/serial driver pull request for the 3.5-rc1 merge window.

Nothing major in here, just lots of incremental changes from Alan and
Jiri reworking some tty core things to behave better and to get a more
solid grasp on some of the nasty tty locking issues.

There are a few tty and serial driver updates in here as well.

All of this has been in the linux-next releases for a while with no problems.

Signed-off-by: Greg Kroah-Hartman <gregkh< at >linuxfoundation.org>

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

Re: struct tty_flip_buffer replacement in newer kernels

Jack Stone — 2012-05-22T14:44:15

[Re-adding original poster an LKML after I accidentally dropped them.
 Sorry about that]

On 05/22/2012 03:10 PM, Alan Cox wrote:

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: struct tty_flip_buffer replacement in newer kernels

Dmitriy Alekseev — 2012-05-22T14:38:28

This is driver source I found:
http://www.codeforge.com/read/118181/st16c554_serial.c__html

It was written for quad uart st16c554 for arm chip s3c2410, which I tried to adapt for at91rm9200 board and newer kernel version.

Best regards,
Dmitriy Alekseev


----- Original Message -----
From: Alan Cox <alan< at >lxorguk.ukuu.org.uk>
To: Jack Stone <jwjstone< at >fastmail.fm>
Cc: gregkh< at >linuxfoundation.org; alan< at >linux.intel.com; linux-serial< at >vger.kernel.org
Sent: Tuesday, May 22, 2012 6:10 PM
Subject: Re: struct tty_flip_buffer replacement in newer kernels


Your driver shouldn't be looking in those areas. There isn't a correct
replacement. You will need to update it to use the flip buffers properly
not poke its nose in places it shouldn't have.

Perhaps the best thing would be to post a link to the driver ?

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubs

Re: struct tty_flip_buffer replacement in newer kernels

Alan Cox — 2012-05-22T14:10:33

Your driver shouldn't be looking in those areas. There isn't a correct
replacement. You will need to update it to use the flip buffers properly
not poke its nose in places it shouldn't have.

Perhaps the best thing would be to post a link to the driver ?

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PATCH] TTY/serial patches for 3.5-rc1

Greg KH — 2012-05-22T13:20:06

The following changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3:

  Linux 3.4-rc6 (2012-05-06 15:07:32 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-3.5-rc1

for you to fetch changes up to d48b97b403d23f6df0b990cee652bdf9a52337a3:

  Linux 3.4-rc6 (2012-05-06 15:07:32 -0700)

----------------------------------------------------------------
TTY pull request for 3.5-rc1

Here's the big TTY/serial driver pull request for the 3.5-rc1 merge window.

Nothing major in here, just lots of incremental changes from Alan and
Jiri reworking some tty core things to behave better and to get a more
solid grasp on some of the nasty tty locking issues.

There are a few tty and serial driver updates in here as well.

All of this has been in the linux-next releases for a while with no problems.

Signed-off-by: Greg Kroah-Hartman <gregkh< at >linuxfoundation.org>

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

 Documentation/ABI

Fwd: struct tty_flip_buffer replacement in newer kernels

Jack Stone — 2012-05-22T12:32:02

[Add CCs]

-------- Original Message --------
Subject: struct tty_flip_buffer replacement in newer kernels
Date: Tue, 22 May 2012 16:17:02 +0400
From: Dmitriy Alekseev <deathonfuneral< at >gmail.com>
To: linux-kernel< at >vger.kernel.org

Hello

I'm newbie, working under existed serial driver, adapting it for 2.6.32.
During the compilation I have had several problems, which I
succesfully solved except this one:
error: 'struct tty_struct' has no member named 'flip'
In particular, cound you advice correct replacement of "tty->flip.count"

Thanks

[PATCH V2] serial: pxa: add spin lock for console write

Chao Xie — 2012-05-22T04:43:00

at UP mode, when cpu want to print message in kernel, it will invoke
peempt_disable and disable irq. So it is safe for UP mode.
For SMP mode, it is not safe to protect the HW reigsters.
one CPU will run a program which will invoke printf.
another CPU will run a program in kernel that invoke printk.
So when second CPU is trying to printk, it will do
1. save ier register
2. enable uue bit of ier register
3. push buffer to uart fifo
4 .restore ier register
when first CPU want to printf, and it happens between 1 and 4, it will
enable thre bit of ier, and waiting for transmit intterupt. while step 4
will make the ier lost thre bit.
add spin lock here to protect the ier register for console write.

Signed-off-by: Chao Xie <chao.xie< at >marvell.com>
---
 drivers/tty/serial/pxa.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/serial/pxa.c b/drivers/tty/serial/pxa.c
index 5847a4b..aca62f6 100644
--- a/drivers/tty/serial/pxa.c
+++ b/drivers/tty/serial/pxa.c
< at >< at > -670,9 +6