* [PATCH 1/2 v2] serial: bfin_uart: Don't switch baud rate untill the transfer buffer is empty.
From: Sonic Zhang @ 2012-11-19 6:40 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-serial, uclinux-dist-devel, Sonic Zhang
From: Sonic Zhang <sonic.zhang@analog.com>
set_termios may be invoked before the former data transfer is completed. Block until the
tranfer is done.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
---
drivers/tty/serial/bfin_uart.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/bfin_uart.c b/drivers/tty/serial/bfin_uart.c
index 9242d56..f8dc8f1 100644
--- a/drivers/tty/serial/bfin_uart.c
+++ b/drivers/tty/serial/bfin_uart.c
@@ -800,6 +800,7 @@ bfin_serial_set_termios(struct uart_port *port, struct ktermios *termios,
unsigned long flags;
unsigned int baud, quot;
unsigned int ier, lcr = 0;
+ unsigned long timeout;
switch (termios->c_cflag & CSIZE) {
case CS8:
@@ -869,6 +870,14 @@ bfin_serial_set_termios(struct uart_port *port, struct ktermios *termios,
UART_SET_ANOMALY_THRESHOLD(uart, USEC_PER_SEC / baud * 15);
+ /* Wait till the transfer buffer is empty */
+ timeout = jiffies + msecs_to_jiffies(10);
+ while (UART_GET_GCTL(uart) & UCEN && !(UART_GET_LSR(uart) & TEMT))
+ if (time_after(jiffies, timeout)) {
+ dev_warn(port->dev, "timeout waiting for TX buffer empty\n");
+ break;
+ }
+
/* Disable UART */
ier = UART_GET_IER(uart);
UART_PUT_GCTL(uart, UART_GET_GCTL(uart) & ~UCEN);
--
1.7.0.4
^ permalink raw reply related
* RE: [PATCH] serial: bfin_uart: Don't switch baud rate untill the transfer buffer is empty.
From: Zhang, Sonic @ 2012-11-19 6:31 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sonic Zhang
Cc: linux-serial@vger.kernel.org,
uclinux-dist-devel@blackfin.uclinux.org
In-Reply-To: <20121116005946.GA1727@kroah.com>
>-----Original Message-----
>From: Greg Kroah-Hartman [mailto:gregkh@linuxfoundation.org]
>Sent: Friday, November 16, 2012 9:00 AM
>To: Sonic Zhang
>Cc: linux-serial@vger.kernel.org; uclinux-dist-devel@blackfin.uclinux.org; Zhang,
>Sonic
>Subject: Re: [PATCH] serial: bfin_uart: Don't switch baud rate untill the transfer
>buffer is empty.
>
>On Wed, Nov 07, 2012 at 12:55:42PM +0800, Sonic Zhang wrote:
>> From: Sonic Zhang <sonic.zhang@analog.com>
>>
>> set_termios may be invoked before the former data transfer is
>> completed. Block until the tranfer is done.
>>
>> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
>> ---
>> drivers/tty/serial/bfin_uart.c | 4 ++++
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/tty/serial/bfin_uart.c
>> b/drivers/tty/serial/bfin_uart.c index 9242d56..71c0c09 100644
>> --- a/drivers/tty/serial/bfin_uart.c
>> +++ b/drivers/tty/serial/bfin_uart.c
>> @@ -869,6 +869,10 @@ bfin_serial_set_termios(struct uart_port *port,
>> struct ktermios *termios,
>>
>> UART_SET_ANOMALY_THRESHOLD(uart, USEC_PER_SEC / baud * 15);
>>
>> + /* Wait till the transfer buffer is empty */
>> + while (UART_GET_GCTL(uart) & UCEN && !(UART_GET_LSR(uart) &
>TEMT))
>> + barrier();
>
>Where is the "the hardware is hung" break out of this loop?
>
Sorry, I will add time_after check soon.
Regards,
Sonic
>And why "barrier()"?
>
>thanks,
>
>greg k-h
^ permalink raw reply
* Re: [PATCH v3] Add support for new devices: Exar's XR17V35x family of multi-port PCIe UARTs
From: Matt Schulte @ 2012-11-19 5:15 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-serial, Alan Cox, Theodore Ts'o
In-Reply-To: <20121119044233.GA30007@kroah.com>
On Sun, Nov 18, 2012 at 10:42 PM, Greg Kroah-Hartman <greg@kroah.com> wrote:
> On Sun, Nov 18, 2012 at 10:33:33PM -0600, Matt Schulte wrote:
>> On Thu, Nov 15, 2012 at 5:01 PM, Matt Schulte
>> <matts@commtech-fastcom.com> wrote:
>> > Add support for new devices: Exar's XR17V35x family of multi-port PCIe UARTs.
>> >
>> > Built against tty-next 54d5f88f25c38e5500a17b16240cb3775af00876
>> >
>> > Signed-off-by: Matt Schulte <matts@commtech-fastcom.com>
>> > ---
>> > v3: Moved overriding of handle_irq to serial8250_config_port
>> >
>> > v2: Moved extra interrupt handling to its own custom handle_irq
>> >
>> > v1: Hopefully if this gets accepted I will be able to submit an additional
>> > patch to add support for my company's PCIe cards that use these
>> > UARTs.
>>
>> What should I do if I would like to submit an additional patch that
>> depends on this one that has not yet been accepted? Should I combine
>> them and resubmit both or do I just need to wait?
>
> I was waiting for Alan's ack on your first patch here. I suggest
> resending it, and a second one with your additional changes as well.
>
Should I change anything in the original or just resend in its entirety?
^ permalink raw reply
* Re: [PATCH v3] Add support for new devices: Exar's XR17V35x family of multi-port PCIe UARTs
From: Greg Kroah-Hartman @ 2012-11-19 4:42 UTC (permalink / raw)
To: Matt Schulte; +Cc: linux-serial, Alan Cox, Theodore Ts'o
In-Reply-To: <CAJp1Oe6GG34JKaDus9pc8Geo14Wros6S1mmYbAv_oWQQKt7GSQ@mail.gmail.com>
On Sun, Nov 18, 2012 at 10:33:33PM -0600, Matt Schulte wrote:
> On Thu, Nov 15, 2012 at 5:01 PM, Matt Schulte
> <matts@commtech-fastcom.com> wrote:
> > Add support for new devices: Exar's XR17V35x family of multi-port PCIe UARTs.
> >
> > Built against tty-next 54d5f88f25c38e5500a17b16240cb3775af00876
> >
> > Signed-off-by: Matt Schulte <matts@commtech-fastcom.com>
> > ---
> > v3: Moved overriding of handle_irq to serial8250_config_port
> >
> > v2: Moved extra interrupt handling to its own custom handle_irq
> >
> > v1: Hopefully if this gets accepted I will be able to submit an additional
> > patch to add support for my company's PCIe cards that use these
> > UARTs.
>
> What should I do if I would like to submit an additional patch that
> depends on this one that has not yet been accepted? Should I combine
> them and resubmit both or do I just need to wait?
I was waiting for Alan's ack on your first patch here. I suggest
resending it, and a second one with your additional changes as well.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v3] Add support for new devices: Exar's XR17V35x family of multi-port PCIe UARTs
From: Matt Schulte @ 2012-11-19 4:33 UTC (permalink / raw)
To: linux-serial; +Cc: Alan Cox, Greg Kroah-Hartman, Theodore Ts'o
In-Reply-To: <CAJp1Oe4Xh6SDQc43hue5qanm7G5Lw9vMdv-+5nRQ_S+RPpRALQ@mail.gmail.com>
On Thu, Nov 15, 2012 at 5:01 PM, Matt Schulte
<matts@commtech-fastcom.com> wrote:
> Add support for new devices: Exar's XR17V35x family of multi-port PCIe UARTs.
>
> Built against tty-next 54d5f88f25c38e5500a17b16240cb3775af00876
>
> Signed-off-by: Matt Schulte <matts@commtech-fastcom.com>
> ---
> v3: Moved overriding of handle_irq to serial8250_config_port
>
> v2: Moved extra interrupt handling to its own custom handle_irq
>
> v1: Hopefully if this gets accepted I will be able to submit an additional
> patch to add support for my company's PCIe cards that use these
> UARTs.
What should I do if I would like to submit an additional patch that
depends on this one that has not yet been accepted? Should I combine
them and resubmit both or do I just need to wait?
Matt Schutle
^ permalink raw reply
* Re: [PATCH] serial: ifx6x60: ifx_spi_write don't need to do mrdy_assert when fifo is not empty.
From: Greg KH @ 2012-11-18 3:30 UTC (permalink / raw)
To: Chen, Jun D
Cc: Alan Cox, Bi, Chao, serial, Gorby, Russ,
linux-kernel@vger.kernel.org, Wu, Fengguang
In-Reply-To: <9E44E06DBBA23A489DED933DBC291A850FD7A645@SHSMSX102.ccr.corp.intel.com>
http://daringfireball.net/2007/07/on_top
On Sun, Nov 18, 2012 at 03:14:28AM +0000, Chen, Jun D wrote:
> Hi,
> I make this patch on your tty-next tree, Do I need to make it on the branch 3.7-rc6 against?
No, my tty-next branch. But something is odd, it didn't apply at all.
Please try again.
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH] serial: ifx6x60: ifx_spi_write don't need to do mrdy_assert when fifo is not empty.
From: Chen, Jun D @ 2012-11-18 3:14 UTC (permalink / raw)
To: Greg KH
Cc: Alan Cox, Bi, Chao, serial, Gorby, Russ,
linux-kernel@vger.kernel.org, Wu, Fengguang
In-Reply-To: <20121116123834.GA9327@kroah.com>
Hi,
I make this patch on your tty-next tree, Do I need to make it on the branch 3.7-rc6 against?
-----Original Message-----
From: Greg KH [mailto:gregkh@linuxfoundation.org]
Sent: Friday, November 16, 2012 8:39 PM
To: Chen, Jun D
Cc: Alan Cox; Bi, Chao; serial; Gorby, Russ; linux-kernel@vger.kernel.org; Wu, Fengguang
Subject: Re: [PATCH] serial: ifx6x60: ifx_spi_write don't need to do mrdy_assert when fifo is not empty.
On Fri, Nov 16, 2012 at 06:08:37AM -0500, Jun Chen wrote:
>
> This patch check whether the fifo lenth is empty before writing new
> data to fifo.If condition is true,ifx_spi_write need to trigger one
> mrdy_assert. If condition is false,the mrdy_assert will be trigger by the next ifx_spi_io.
>
> Cc: Bi Chao <chao.bi@intel.com>
> Signed-off-by: Chen Jun <jun.d.chen@intel.com>
> ---
> drivers/tty/serial/ifx6x60.c | 14 +++++++++++---
> 1 files changed, 11 insertions(+), 3 deletions(-)
What tree did you make this against? It doesn't apply to my tty-next tree at all :(
greg k-h
^ permalink raw reply
* Re: [PATCH v3 0/3] serial: mxs-auart: add DMA support for auart in mx28
From: Huang Shijie @ 2012-11-17 3:37 UTC (permalink / raw)
To: Lauri Hintsala
Cc: Huang Shijie, gregkh, linux-serial, linux-arm-kernel, linux,
vinod.koul
In-Reply-To: <50A656DE.6080506@bluegiga.com>
On Fri, Nov 16, 2012 at 11:08 PM, Lauri Hintsala
<lauri.hintsala@bluegiga.com> wrote:
> Hi Huang,
>
> Thanks for new version. Now I don't get any errors and the CPU doesn't
> freeze any more but:
>
> 1) AUART corrupts data with baudrate over 1Mbits/s
The tranceivers, such as MAX3380E, will limit the speed.
i ever removed it, and tested the AUART in 3M bits/s.
>
> 2) We would need DMA support without flow control.
:)
I really think it's not wise to support the DMA withou flow control.
it will losts the data in some case.
Even use the FREESCALE's bsp code, I also recomand to use the flow control.
>
> By the way, how do you test drivers? Is there any standard tools for uart
> data and throughput testing?
I tested the driver with our own small tool.
If you want to test it too, I can send you the resource next monday.
You can use it to test if you have received the right data.
thanks
Huang Shijie
>
> Lauri
>
>
> On 11/16/2012 10:03 AM, Huang Shijie wrote:
>>
>> This patch set adds the DMA support for auart in mx28.
>> patch 1:
>> In mx23, the DMA has a bug(see errata:2836). We can not add the
>> DMA support in mx23, but we can add DMA support to auart in mx28.
>> So in order to add the DMA support for the auart in mx28, we
>> should add
>> the platform_device_id to distinguish the distinguish SOCs.
>>
>> patch 2: add the DMA support for mx28
>> Only we meet the following conditions, we can enable the DMA
>> support
>> for auart:
>> (1) We enable the DMA support in the dts file, such as
>> arch/arm/boot/dts/imx28.dtsi.
>> (2) We enable the hardware flow control.
>> (3) We use the mx28, not the mx23. Due to hardware bug(see
>> errata: 2836),
>> we can not add the DMA support to mx23.
>>
>> patch 3: enable the DMA support in dts for mx28
>> You can use the /ttyAPP0 to test this patch set.
>> I tested this patch in mx28-evk board.
>>
>>
>> To Lauri: Please try this patch set. thanks.
>>
>>
>> v2 --> v3:
>> [1] fix a multi-open issue found by Lauri.
>>
>> v1 --> v2:
>> [1] use the inline function, not a macro, to distinguish the SOCs.
>> [2] remove the "inline" for mxs_auart_tx_chars().
>> [3] use the `pio`, not the `pio[1]` to fill the DMA descriptor.
>> [4] use bit operation to serialize the DMA TX.
>> [5] use the RX/TX DMA channel to enable the DMA support, remove
>> the
>> "fsl,auart-enable-dma".
>>
>> Huang Shijie (3):
>> serial: mxs-auart: distinguish the different SOCs
>> serial: mxs-auart: add the DMA support for mx28
>> ARM: dts: enable dma support for auart0 in mx28
>>
>> .../bindings/tty/serial/fsl-mxs-auart.txt | 8 +
>> arch/arm/boot/dts/imx28.dtsi | 1 +
>> drivers/tty/serial/mxs-auart.c | 364
>> +++++++++++++++++++-
>> 3 files changed, 362 insertions(+), 11 deletions(-)
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] serial: atmel_serial: remove atmel open/close hooks
From: Joachim Eastwood @ 2012-11-17 0:09 UTC (permalink / raw)
To: linux, gregkh
Cc: nicolas.ferre, plagnioj, avictor.za, alan, linux-arm-kernel,
linux-serial, Joachim Eastwood
After serial_at91.h was removed the atmel_open/close_hook
code is now useless.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
Hi,
This patch depends on [RFC 3/3] ARM/AVR32: get rid of serial_at91.h
patch from Russell King.
Patch based on current linux-next with "[RFC 3/3] ARM/AVR32: get rid of serial_at91.h"
patch on top. There is a small conflict with Russell's patch
in next now due to another header change.
If there is another tree this patch should be based on please
let me know.
regards
Joachim Eastwood
drivers/tty/serial/atmel_serial.c | 22 ----------------------
1 file changed, 22 deletions(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 76e4c05..5c2337d 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -113,9 +113,6 @@ static void atmel_stop_rx(struct uart_port *port);
#define UART_PUT_TCR(port,v) __raw_writel(v, (port)->membase + ATMEL_PDC_TCR)
#define UART_GET_TCR(port) __raw_readl((port)->membase + ATMEL_PDC_TCR)
-static int (*atmel_open_hook)(struct uart_port *);
-static void (*atmel_close_hook)(struct uart_port *);
-
struct atmel_dma_buffer {
unsigned char *buf;
dma_addr_t dma_addr;
@@ -976,18 +973,6 @@ static int atmel_startup(struct uart_port *port)
pdc->ofs = 0;
}
- /*
- * If there is a specific "open" function (to register
- * control line interrupts)
- */
- if (atmel_open_hook) {
- retval = atmel_open_hook(port);
- if (retval) {
- free_irq(port->irq, port);
- return retval;
- }
- }
-
/* Save current CSR for comparison in atmel_tasklet_func() */
atmel_port->irq_status_prev = UART_GET_CSR(port);
atmel_port->irq_status = atmel_port->irq_status_prev;
@@ -1062,13 +1047,6 @@ static void atmel_shutdown(struct uart_port *port)
* Free the interrupt
*/
free_irq(port->irq, port);
-
- /*
- * If there is a specific "close" function (to unregister
- * control line interrupts)
- */
- if (atmel_close_hook)
- atmel_close_hook(port);
}
/*
--
1.8.0
^ permalink raw reply related
* Re: [RFC 3/3] ARM/AVR32: get rid of serial_at91.h
From: Russell King - ARM Linux @ 2012-11-16 23:08 UTC (permalink / raw)
To: Joachim Eastwood
Cc: linux-arm-kernel, linux-serial, linux-usb, Greg Kroah-Hartman,
Nicolas Ferre, Alan Cox
In-Reply-To: <CAGhQ9VzYc8qqvZxU=AB+NHa4nGKJFxPYR7grc8Ssn-kP1bfq3w@mail.gmail.com>
On Fri, Nov 16, 2012 at 11:08:47PM +0100, Joachim Eastwood wrote:
> When the atmel_open_hook/atmel_open_close assignment is dropped, these
> global variables will be useless so we should remove them as well.
> There are also some other code that uses the variables that can be
> dropped. Should shave another 22 lines of code off atmel_serial.c
>
> I can send out a patch on top of yours if you prefer that.
Yes please.
Thanks.
^ permalink raw reply
* Re: [RFC 3/3] ARM/AVR32: get rid of serial_at91.h
From: Joachim Eastwood @ 2012-11-16 22:08 UTC (permalink / raw)
To: Russell King
Cc: linux-arm-kernel, linux-serial, linux-usb, Greg Kroah-Hartman,
Nicolas Ferre, Alan Cox
In-Reply-To: <E1TEzfE-000780-1t@rmk-PC.arm.linux.org.uk>
Hi Russell,
I made a similar patch a while ago. One note below.
(http://marc.info/?l=linux-arm-kernel&m=133372829203680)
On 21 September 2012 11:36, Russell King <rmk+kernel@arm.linux.org.uk> wrote:
> The definitions provided by serial_at91.h are only used by the
> atmel_serial driver, and the function that uses it is never called
> from anywhere in the kernel. Therefore, these definitions are unused
> and/or obsolete, and can be removed.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> arch/arm/include/asm/mach/serial_at91.h | 33 -----------------------------
> arch/avr32/include/asm/mach/serial_at91.h | 33 -----------------------------
> drivers/tty/serial/atmel_serial.c | 18 ---------------
> 3 files changed, 0 insertions(+), 84 deletions(-)
> delete mode 100644 arch/arm/include/asm/mach/serial_at91.h
> delete mode 100644 arch/avr32/include/asm/mach/serial_at91.h
<snip>
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 3d7e1ee..a6134c9 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -43,7 +43,6 @@
> #include <asm/io.h>
> #include <asm/ioctls.h>
>
> -#include <asm/mach/serial_at91.h>
> #include <mach/board.h>
>
> #ifdef CONFIG_ARM
> @@ -1513,23 +1512,6 @@ static void __devinit atmel_init_port(struct atmel_uart_port *atmel_port,
> }
> }
>
> -/*
> - * Register board-specific modem-control line handlers.
> - */
> -void __init atmel_register_uart_fns(struct atmel_port_fns *fns)
> -{
> - if (fns->enable_ms)
> - atmel_pops.enable_ms = fns->enable_ms;
> - if (fns->get_mctrl)
> - atmel_pops.get_mctrl = fns->get_mctrl;
> - if (fns->set_mctrl)
> - atmel_pops.set_mctrl = fns->set_mctrl;
> - atmel_open_hook = fns->open;
> - atmel_close_hook = fns->close;
> - atmel_pops.pm = fns->pm;
> - atmel_pops.set_wake = fns->set_wake;
> -}
When the atmel_open_hook/atmel_open_close assignment is dropped, these
global variables will be useless so we should remove them as well.
There are also some other code that uses the variables that can be
dropped. Should shave another 22 lines of code off atmel_serial.c
I can send out a patch on top of yours if you prefer that.
regards
Joachim Eastwood
^ permalink raw reply
* Re: [RFC 3/3] ARM/AVR32: get rid of serial_at91.h
From: Andrew Victor @ 2012-11-16 20:46 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Jean-Christophe PLAGNIOL-VILLARD, Russell King, linux-arm-kernel,
linux-serial, linux-usb, Greg Kroah-Hartman, Alan Cox
In-Reply-To: <50A6119E.8010303@atmel.com>
hi,
> Yes, during previous attempt to remove the files, Andrew said that it
> was used internally in his former company. I had no serious reason to
> remove it, so we kept it back then.
> But now it seems the situation has evolved and we must consider the move
> to a single kernel image and the will to clean the include/asm/mach
> directory.
SAN People will just need to maintain a custom patch / driver for this.
No reason to delay the progress of mainline.
Acked-By: Andrew Victor <avictor.za@gmail.com>
^ permalink raw reply
* [tty:tty-next 109/109] drivers/staging/sb105x/sb_pci_mp.h:22:25: fatal error: asm/segment.h: No such file or directory
From: kbuild test robot @ 2012-11-16 19:45 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linux-serial, Greg Kroah-Hartman
tree: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-next
head: 68a81291ff6650f3ff409ebfc58ef97dfe85a2e4
commit: 68a81291ff6650f3ff409ebfc58ef97dfe85a2e4 [109/109] staging: Add SystemBase Multi-2/PCI driver
config: make ARCH=powerpc allmodconfig
All error/warnings:
In file included from drivers/staging/sb105x/sb_pci_mp.c:1:0:
drivers/staging/sb105x/sb_pci_mp.h:22:25: fatal error: asm/segment.h: No such file or directory
compilation terminated.
vim +22 drivers/staging/sb105x/sb_pci_mp.h
68a81291 Steven Rostedt 2012-11-16 16 #include <linux/pci.h>
68a81291 Steven Rostedt 2012-11-16 17 #include <linux/circ_buf.h>
68a81291 Steven Rostedt 2012-11-16 18
68a81291 Steven Rostedt 2012-11-16 19 #include <asm/uaccess.h>
68a81291 Steven Rostedt 2012-11-16 20 #include <asm/io.h>
68a81291 Steven Rostedt 2012-11-16 21 #include <asm/irq.h>
68a81291 Steven Rostedt 2012-11-16 @22 #include <asm/segment.h>
68a81291 Steven Rostedt 2012-11-16 23 #include <asm/serial.h>
68a81291 Steven Rostedt 2012-11-16 24 #include <linux/interrupt.h>
68a81291 Steven Rostedt 2012-11-16 25
---
0-DAY kernel build testing backend Open Source Technology Center
Fengguang Wu, Yuanhan Liu Intel Corporation
^ permalink raw reply
* Re: [PATCH v3 0/3] serial: mxs-auart: add DMA support for auart in mx28
From: Lauri Hintsala @ 2012-11-16 15:08 UTC (permalink / raw)
To: Huang Shijie; +Cc: gregkh, linux-serial, linux-arm-kernel, linux, vinod.koul
In-Reply-To: <1353053034-10944-1-git-send-email-b32955@freescale.com>
Hi Huang,
Thanks for new version. Now I don't get any errors and the CPU doesn't
freeze any more but:
1) AUART corrupts data with baudrate over 1Mbits/s
2) We would need DMA support without flow control.
By the way, how do you test drivers? Is there any standard tools for
uart data and throughput testing?
Lauri
On 11/16/2012 10:03 AM, Huang Shijie wrote:
> This patch set adds the DMA support for auart in mx28.
> patch 1:
> In mx23, the DMA has a bug(see errata:2836). We can not add the
> DMA support in mx23, but we can add DMA support to auart in mx28.
> So in order to add the DMA support for the auart in mx28, we should add
> the platform_device_id to distinguish the distinguish SOCs.
>
> patch 2: add the DMA support for mx28
> Only we meet the following conditions, we can enable the DMA support
> for auart:
> (1) We enable the DMA support in the dts file, such as
> arch/arm/boot/dts/imx28.dtsi.
> (2) We enable the hardware flow control.
> (3) We use the mx28, not the mx23. Due to hardware bug(see errata: 2836),
> we can not add the DMA support to mx23.
>
> patch 3: enable the DMA support in dts for mx28
> You can use the /ttyAPP0 to test this patch set.
> I tested this patch in mx28-evk board.
>
>
> To Lauri: Please try this patch set. thanks.
>
>
> v2 --> v3:
> [1] fix a multi-open issue found by Lauri.
>
> v1 --> v2:
> [1] use the inline function, not a macro, to distinguish the SOCs.
> [2] remove the "inline" for mxs_auart_tx_chars().
> [3] use the `pio`, not the `pio[1]` to fill the DMA descriptor.
> [4] use bit operation to serialize the DMA TX.
> [5] use the RX/TX DMA channel to enable the DMA support, remove the
> "fsl,auart-enable-dma".
>
> Huang Shijie (3):
> serial: mxs-auart: distinguish the different SOCs
> serial: mxs-auart: add the DMA support for mx28
> ARM: dts: enable dma support for auart0 in mx28
>
> .../bindings/tty/serial/fsl-mxs-auart.txt | 8 +
> arch/arm/boot/dts/imx28.dtsi | 1 +
> drivers/tty/serial/mxs-auart.c | 364 +++++++++++++++++++-
> 3 files changed, 362 insertions(+), 11 deletions(-)
>
>
^ permalink raw reply
* Re: [PATCH] serial: ifx6x60: Add module parameters to manage the modem status through sysfs
From: Greg KH @ 2012-11-16 15:01 UTC (permalink / raw)
To: Alan Cox
Cc: Jun Chen, serial, russ.gorby, liu chuansheng, Linux Kernel,
Bi Chao, Alan Cox
In-Reply-To: <20121116150007.273b7038@pyramind.ukuu.org.uk>
On Fri, Nov 16, 2012 at 03:00:07PM +0000, Alan Cox wrote:
> On Fri, 16 Nov 2012 04:38:06 -0800
> Greg KH <gregkh@linuxfoundation.org> wrote:
>
> > On Fri, Nov 16, 2012 at 07:59:49AM -0500, Jun Chen wrote:
> > >
> > > The Medfield Platform implements a recovery procedure consisting in an escalation
> > > from simple and light recovery procedures to stronger ones with increased visibility
> > > and impact to end-user.After platform find some problem from Modem,such as no response,
> > > platform will try do modem warm reset.If several tries failed, platform will try to
> > > do modem cold boot procedure.For Modem Cold Boot, AP is responsible to generate
> > > blob (binary object containing PIN code and other necessary information).
> > > Blob is stored in AP volatile memory. AP decides to read PIN code from cache instead of
> > > prompting end-user, and sends it to modem as if end-user had entered it.
> > >
> > > This patch add module parameters to manage the modem status through sysfs.
> > > Reset_modem can be read and write by user space.When read the reset_modem,user space will
> > > get the mdm_reset_state which used to avoid to run twice at once.When set the reset_modem to
> > > IFX_COLD_RESET_REQ,modem will do cold reset, other val value will trigger modem reset.
> > >
> > > Hangup_reasons used to give one interface to user space to know and clear the modem reset reasons.
> > > Now there are four reasons:SPI timeout, modem initiative reset,modem coredump,spi tranfer error.
> >
> > Why are these module parameters? Why not just "real" sysfs files
> > instead? That way, if you have multiple devices in a system, it will
> > work properly for them. Right now you are limited to 1 device, right?
>
> Yes and its highly unlikely that there will ever be anyone who needs two.
Ok, but why a module parameter? That's a very "odd" way to do this type
of interaction, why not just a "normal" sysfs file instead?
Either way, there's no documentation here, which is needed for a new
kernel/user api that is being created. Someone needs to add an entry
for Documentation/ABI/ here.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] serial: ifx6x60: Add module parameters to manage the modem status through sysfs
From: Alan Cox @ 2012-11-16 15:00 UTC (permalink / raw)
To: Greg KH
Cc: Jun Chen, serial, russ.gorby, liu chuansheng, Linux Kernel,
Bi Chao, Alan Cox
In-Reply-To: <20121116123806.GA9303@kroah.com>
On Fri, 16 Nov 2012 04:38:06 -0800
Greg KH <gregkh@linuxfoundation.org> wrote:
> On Fri, Nov 16, 2012 at 07:59:49AM -0500, Jun Chen wrote:
> >
> > The Medfield Platform implements a recovery procedure consisting in an escalation
> > from simple and light recovery procedures to stronger ones with increased visibility
> > and impact to end-user.After platform find some problem from Modem,such as no response,
> > platform will try do modem warm reset.If several tries failed, platform will try to
> > do modem cold boot procedure.For Modem Cold Boot, AP is responsible to generate
> > blob (binary object containing PIN code and other necessary information).
> > Blob is stored in AP volatile memory. AP decides to read PIN code from cache instead of
> > prompting end-user, and sends it to modem as if end-user had entered it.
> >
> > This patch add module parameters to manage the modem status through sysfs.
> > Reset_modem can be read and write by user space.When read the reset_modem,user space will
> > get the mdm_reset_state which used to avoid to run twice at once.When set the reset_modem to
> > IFX_COLD_RESET_REQ,modem will do cold reset, other val value will trigger modem reset.
> >
> > Hangup_reasons used to give one interface to user space to know and clear the modem reset reasons.
> > Now there are four reasons:SPI timeout, modem initiative reset,modem coredump,spi tranfer error.
>
> Why are these module parameters? Why not just "real" sysfs files
> instead? That way, if you have multiple devices in a system, it will
> work properly for them. Right now you are limited to 1 device, right?
Yes and its highly unlikely that there will ever be anyone who needs two.
Alan
^ permalink raw reply
* [GIT PATCH] TTY/Serial fixes for 3.7-rc5
From: Greg KH @ 2012-11-16 14:20 UTC (permalink / raw)
To: Linus Torvalds, Alan Cox, Jiri Slaby
Cc: Andrew Morton, linux-kernel, linux-serial
The following changes since commit 77b67063bb6bce6d475e910d3b886a606d0d91f7:
Linux 3.7-rc5 (2012-11-11 13:44:33 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-3.7-rc5
for you to fetch changes up to 1838b8c487378c6c576029d9e0e07b5a73036bac:
tty: serial: max310x: Add terminating entry for spi_device_id table (2012-11-14 14:49:42 -0800)
----------------------------------------------------------------
TTY fixes for 3.7-rc5
Here are two TTY driver fixes for 3.7-rc5.
They resolve a bug in the hvc driver that has been reported, and fix a
problem with the list of device ids in the max310x serial driver.
Both have been in linux-next for a while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Axel Lin (1):
tty: serial: max310x: Add terminating entry for spi_device_id table
Paul Mackerras (1):
TTY: hvc_console, fix port reference count going to zero prematurely
drivers/tty/hvc/hvc_console.c | 7 -------
drivers/tty/serial/max310x.c | 1 +
2 files changed, 1 insertion(+), 7 deletions(-)
^ permalink raw reply
* Williams
From: willims gebrel @ 2012-11-16 13:00 UTC (permalink / raw)
My Dear,
I'm happy to inform you about my success in getting those funds transferred under the cooperation of my new partner from Canada based business man; presently I'm in Bahamas for investment projects with my own share of the total sum. Meanwhile, I didn't forget your past efforts and attempts to assist me in transferring those funds despite that it failed us somehow.
Now contact my patina personal adviser in Togo, his name is HON REV.PETER SMITH of church embassy ministry Togo, E-mail: fortbendlawlegal@gmail.com
Ask him to send you the official Draft check of $500.000.00 or by cash which I gave him as order to kept for your compensation for all the past efforts and attempts to assist me in this matter before. I appreciated your collective efforts at that time, so feel free and get in touch with my patina adviser HON.REV. PETER SMITH and instruct him where to send the amount to you. Please do let me know immediately you receive it so that we can share the joy after all the sufferings at that time.
in the moment, I am very busy here In Bahamas because of the investment projects which myself and the new partner are having at hand without confrontations, finally, remember that I had forwarded instruction to the REV.PETER SMITH on your behalf to send you the check or by cash as my patina deposited to him on your name before he left to Canada where he based.
So feel free to get in touch with HON REV.PETER SMITH he will send the amount to you without any delay.
With best regards,
Williams
^ permalink raw reply
* Re: [PATCH] serial: ifx6x60: Add module parameters to manage the modem status through sysfs
From: Greg KH @ 2012-11-16 12:38 UTC (permalink / raw)
To: Jun Chen
Cc: serial, russ.gorby, liu chuansheng, Linux Kernel, Bi Chao,
Alan Cox
In-Reply-To: <1353070789.24092.6.camel@chenjun-workstation>
On Fri, Nov 16, 2012 at 07:59:49AM -0500, Jun Chen wrote:
>
> The Medfield Platform implements a recovery procedure consisting in an escalation
> from simple and light recovery procedures to stronger ones with increased visibility
> and impact to end-user.After platform find some problem from Modem,such as no response,
> platform will try do modem warm reset.If several tries failed, platform will try to
> do modem cold boot procedure.For Modem Cold Boot, AP is responsible to generate
> blob (binary object containing PIN code and other necessary information).
> Blob is stored in AP volatile memory. AP decides to read PIN code from cache instead of
> prompting end-user, and sends it to modem as if end-user had entered it.
>
> This patch add module parameters to manage the modem status through sysfs.
> Reset_modem can be read and write by user space.When read the reset_modem,user space will
> get the mdm_reset_state which used to avoid to run twice at once.When set the reset_modem to
> IFX_COLD_RESET_REQ,modem will do cold reset, other val value will trigger modem reset.
>
> Hangup_reasons used to give one interface to user space to know and clear the modem reset reasons.
> Now there are four reasons:SPI timeout, modem initiative reset,modem coredump,spi tranfer error.
Why are these module parameters? Why not just "real" sysfs files
instead? That way, if you have multiple devices in a system, it will
work properly for them. Right now you are limited to 1 device, right?
And where have you documented these options?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] serial: ifx6x60: ifx_spi_write don't need to do mrdy_assert when fifo is not empty.
From: Greg KH @ 2012-11-16 12:38 UTC (permalink / raw)
To: Jun Chen
Cc: Alan Cox, Bi Chao, serial, russ.gorby, linux-kernel, fengguang.wu
In-Reply-To: <1353064117.24092.4.camel@chenjun-workstation>
On Fri, Nov 16, 2012 at 06:08:37AM -0500, Jun Chen wrote:
>
> This patch check whether the fifo lenth is empty before writing new data to fifo.If condition
> is true,ifx_spi_write need to trigger one mrdy_assert. If condition is false,the mrdy_assert
> will be trigger by the next ifx_spi_io.
>
> Cc: Bi Chao <chao.bi@intel.com>
> Signed-off-by: Chen Jun <jun.d.chen@intel.com>
> ---
> drivers/tty/serial/ifx6x60.c | 14 +++++++++++---
> 1 files changed, 11 insertions(+), 3 deletions(-)
What tree did you make this against? It doesn't apply to my tty-next
tree at all :(
greg k-h
^ permalink raw reply
* Re: [RFC 3/3] ARM/AVR32: get rid of serial_at91.h
From: Russell King - ARM Linux @ 2012-11-16 11:38 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Jean-Christophe PLAGNIOL-VILLARD, Andrew Victor,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman, Alan Cox
In-Reply-To: <50A6119E.8010303-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
On Fri, Nov 16, 2012 at 11:12:46AM +0100, Nicolas Ferre wrote:
> On 11/16/2012 10:53 AM, Jean-Christophe PLAGNIOL-VILLARD :
> > On 10:36 Fri 21 Sep , Russell King wrote:
> >> The definitions provided by serial_at91.h are only used by the
> >> atmel_serial driver, and the function that uses it is never called
> >> from anywhere in the kernel. Therefore, these definitions are unused
> >> and/or obsolete, and can be removed.
> >>
> >> Signed-off-by: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> > personnaly I'm ok with it too
> > Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
> >
> > but Andrew seems use it so let him reply
>
> Yes, during previous attempt to remove the files, Andrew said that it
> was used internally in his former company. I had no serious reason to
> remove it, so we kept it back then.
> But now it seems the situation has evolved and we must consider the move
> to a single kernel image and the will to clean the include/asm/mach
> directory.
>
> So, now, on my side:
>
> Acked-by: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
Thanks for reminding me about this series, I'd completely forgotten about
it. It'll be in the next linux-next tree now.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Need to remove ch35x wch driver which already running
From: Alan Cox @ 2012-11-16 11:23 UTC (permalink / raw)
To: Lokesh; +Cc: linux-serial
In-Reply-To: <loom.20121116T085450-158@post.gmane.org>
On Fri, 16 Nov 2012 07:59:22 +0000 (UTC)
Lokesh <v.lokesh@live.com> wrote:
> HI
>
> I have a pci base serial card i.e wch35x card. for 3.0.5, the driver does not
> exisits. Iam redeveloping for the same from scratch. But due mis detection, the
> pci card claims a driver named "serial".
Actually that is the right driver for the wch35x cards and that would be
why it has bound to them. There are some mods in later kernels to make
the wch work better, but it is the right driver.
If you want to play with it for some reason and write your own driver to
learn stuff then the easiest thing to do is probably add it temporarily
to the blacklist in 8250_pci.c
^ permalink raw reply
* Re: [RFC 3/3] ARM/AVR32: get rid of serial_at91.h
From: Nicolas Ferre @ 2012-11-16 10:12 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD, Russell King, Andrew Victor
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman, Alan Cox
In-Reply-To: <20121116095352.GF4398-RQcB7r2h9QmfDR2tN2SG5Ni2O/JbrIOy@public.gmane.org>
On 11/16/2012 10:53 AM, Jean-Christophe PLAGNIOL-VILLARD :
> On 10:36 Fri 21 Sep , Russell King wrote:
>> The definitions provided by serial_at91.h are only used by the
>> atmel_serial driver, and the function that uses it is never called
>> from anywhere in the kernel. Therefore, these definitions are unused
>> and/or obsolete, and can be removed.
>>
>> Signed-off-by: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> personnaly I'm ok with it too
> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
>
> but Andrew seems use it so let him reply
Yes, during previous attempt to remove the files, Andrew said that it
was used internally in his former company. I had no serious reason to
remove it, so we kept it back then.
But now it seems the situation has evolved and we must consider the move
to a single kernel image and the will to clean the include/asm/mach
directory.
So, now, on my side:
Acked-by: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
>> ---
>> arch/arm/include/asm/mach/serial_at91.h | 33 -----------------------------
>> arch/avr32/include/asm/mach/serial_at91.h | 33 -----------------------------
>> drivers/tty/serial/atmel_serial.c | 18 ---------------
>> 3 files changed, 0 insertions(+), 84 deletions(-)
>> delete mode 100644 arch/arm/include/asm/mach/serial_at91.h
>> delete mode 100644 arch/avr32/include/asm/mach/serial_at91.h
>>
>> diff --git a/arch/arm/include/asm/mach/serial_at91.h b/arch/arm/include/asm/mach/serial_at91.h
>> deleted file mode 100644
>> index ea6d063..0000000
>> --- a/arch/arm/include/asm/mach/serial_at91.h
>> +++ /dev/null
>> @@ -1,33 +0,0 @@
>> -/*
>> - * arch/arm/include/asm/mach/serial_at91.h
>> - *
>> - * Based on serial_sa1100.h by Nicolas Pitre
>> - *
>> - * Copyright (C) 2002 ATMEL Rousset
>> - *
>> - * Low level machine dependent UART functions.
>> - */
>> -
>> -struct uart_port;
>> -
>> -/*
>> - * This is a temporary structure for registering these
>> - * functions; it is intended to be discarded after boot.
>> - */
>> -struct atmel_port_fns {
>> - void (*set_mctrl)(struct uart_port *, u_int);
>> - u_int (*get_mctrl)(struct uart_port *);
>> - void (*enable_ms)(struct uart_port *);
>> - void (*pm)(struct uart_port *, u_int, u_int);
>> - int (*set_wake)(struct uart_port *, u_int);
>> - int (*open)(struct uart_port *);
>> - void (*close)(struct uart_port *);
>> -};
>> -
>> -#if defined(CONFIG_SERIAL_ATMEL)
>> -void atmel_register_uart_fns(struct atmel_port_fns *fns);
>> -#else
>> -#define atmel_register_uart_fns(fns) do { } while (0)
>> -#endif
>> -
>> -
>> diff --git a/arch/avr32/include/asm/mach/serial_at91.h b/arch/avr32/include/asm/mach/serial_at91.h
>> deleted file mode 100644
>> index 55b317a..0000000
>> --- a/arch/avr32/include/asm/mach/serial_at91.h
>> +++ /dev/null
>> @@ -1,33 +0,0 @@
>> -/*
>> - * linux/include/asm-arm/mach/serial_at91.h
>> - *
>> - * Based on serial_sa1100.h by Nicolas Pitre
>> - *
>> - * Copyright (C) 2002 ATMEL Rousset
>> - *
>> - * Low level machine dependent UART functions.
>> - */
>> -
>> -struct uart_port;
>> -
>> -/*
>> - * This is a temporary structure for registering these
>> - * functions; it is intended to be discarded after boot.
>> - */
>> -struct atmel_port_fns {
>> - void (*set_mctrl)(struct uart_port *, u_int);
>> - u_int (*get_mctrl)(struct uart_port *);
>> - void (*enable_ms)(struct uart_port *);
>> - void (*pm)(struct uart_port *, u_int, u_int);
>> - int (*set_wake)(struct uart_port *, u_int);
>> - int (*open)(struct uart_port *);
>> - void (*close)(struct uart_port *);
>> -};
>> -
>> -#if defined(CONFIG_SERIAL_ATMEL)
>> -void atmel_register_uart_fns(struct atmel_port_fns *fns);
>> -#else
>> -#define atmel_register_uart_fns(fns) do { } while (0)
>> -#endif
>> -
>> -
>> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
>> index 3d7e1ee..a6134c9 100644
>> --- a/drivers/tty/serial/atmel_serial.c
>> +++ b/drivers/tty/serial/atmel_serial.c
>> @@ -43,7 +43,6 @@
>> #include <asm/io.h>
>> #include <asm/ioctls.h>
>>
>> -#include <asm/mach/serial_at91.h>
>> #include <mach/board.h>
>>
>> #ifdef CONFIG_ARM
>> @@ -1513,23 +1512,6 @@ static void __devinit atmel_init_port(struct atmel_uart_port *atmel_port,
>> }
>> }
>>
>> -/*
>> - * Register board-specific modem-control line handlers.
>> - */
>> -void __init atmel_register_uart_fns(struct atmel_port_fns *fns)
>> -{
>> - if (fns->enable_ms)
>> - atmel_pops.enable_ms = fns->enable_ms;
>> - if (fns->get_mctrl)
>> - atmel_pops.get_mctrl = fns->get_mctrl;
>> - if (fns->set_mctrl)
>> - atmel_pops.set_mctrl = fns->set_mctrl;
>> - atmel_open_hook = fns->open;
>> - atmel_close_hook = fns->close;
>> - atmel_pops.pm = fns->pm;
>> - atmel_pops.set_wake = fns->set_wake;
>> -}
>> -
>> struct platform_device *atmel_default_console_device; /* the serial console device */
>>
>> #ifdef CONFIG_SERIAL_ATMEL_CONSOLE
>> --
>> 1.7.4.4
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
--
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 3/3] ARM/AVR32: get rid of serial_at91.h
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-16 9:53 UTC (permalink / raw)
To: Russell King, Andrew Victor
Cc: Greg Kroah-Hartman, linux-usb, Nicolas Ferre, linux-serial,
linux-arm-kernel, Alan Cox
In-Reply-To: <E1TEzfE-000780-1t@rmk-PC.arm.linux.org.uk>
On 10:36 Fri 21 Sep , Russell King wrote:
> The definitions provided by serial_at91.h are only used by the
> atmel_serial driver, and the function that uses it is never called
> from anywhere in the kernel. Therefore, these definitions are unused
> and/or obsolete, and can be removed.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
personnaly I'm ok with it too
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
but Andrew seems use it so let him reply
Best Regards,
J.
> ---
> arch/arm/include/asm/mach/serial_at91.h | 33 -----------------------------
> arch/avr32/include/asm/mach/serial_at91.h | 33 -----------------------------
> drivers/tty/serial/atmel_serial.c | 18 ---------------
> 3 files changed, 0 insertions(+), 84 deletions(-)
> delete mode 100644 arch/arm/include/asm/mach/serial_at91.h
> delete mode 100644 arch/avr32/include/asm/mach/serial_at91.h
>
> diff --git a/arch/arm/include/asm/mach/serial_at91.h b/arch/arm/include/asm/mach/serial_at91.h
> deleted file mode 100644
> index ea6d063..0000000
> --- a/arch/arm/include/asm/mach/serial_at91.h
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -/*
> - * arch/arm/include/asm/mach/serial_at91.h
> - *
> - * Based on serial_sa1100.h by Nicolas Pitre
> - *
> - * Copyright (C) 2002 ATMEL Rousset
> - *
> - * Low level machine dependent UART functions.
> - */
> -
> -struct uart_port;
> -
> -/*
> - * This is a temporary structure for registering these
> - * functions; it is intended to be discarded after boot.
> - */
> -struct atmel_port_fns {
> - void (*set_mctrl)(struct uart_port *, u_int);
> - u_int (*get_mctrl)(struct uart_port *);
> - void (*enable_ms)(struct uart_port *);
> - void (*pm)(struct uart_port *, u_int, u_int);
> - int (*set_wake)(struct uart_port *, u_int);
> - int (*open)(struct uart_port *);
> - void (*close)(struct uart_port *);
> -};
> -
> -#if defined(CONFIG_SERIAL_ATMEL)
> -void atmel_register_uart_fns(struct atmel_port_fns *fns);
> -#else
> -#define atmel_register_uart_fns(fns) do { } while (0)
> -#endif
> -
> -
> diff --git a/arch/avr32/include/asm/mach/serial_at91.h b/arch/avr32/include/asm/mach/serial_at91.h
> deleted file mode 100644
> index 55b317a..0000000
> --- a/arch/avr32/include/asm/mach/serial_at91.h
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -/*
> - * linux/include/asm-arm/mach/serial_at91.h
> - *
> - * Based on serial_sa1100.h by Nicolas Pitre
> - *
> - * Copyright (C) 2002 ATMEL Rousset
> - *
> - * Low level machine dependent UART functions.
> - */
> -
> -struct uart_port;
> -
> -/*
> - * This is a temporary structure for registering these
> - * functions; it is intended to be discarded after boot.
> - */
> -struct atmel_port_fns {
> - void (*set_mctrl)(struct uart_port *, u_int);
> - u_int (*get_mctrl)(struct uart_port *);
> - void (*enable_ms)(struct uart_port *);
> - void (*pm)(struct uart_port *, u_int, u_int);
> - int (*set_wake)(struct uart_port *, u_int);
> - int (*open)(struct uart_port *);
> - void (*close)(struct uart_port *);
> -};
> -
> -#if defined(CONFIG_SERIAL_ATMEL)
> -void atmel_register_uart_fns(struct atmel_port_fns *fns);
> -#else
> -#define atmel_register_uart_fns(fns) do { } while (0)
> -#endif
> -
> -
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 3d7e1ee..a6134c9 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -43,7 +43,6 @@
> #include <asm/io.h>
> #include <asm/ioctls.h>
>
> -#include <asm/mach/serial_at91.h>
> #include <mach/board.h>
>
> #ifdef CONFIG_ARM
> @@ -1513,23 +1512,6 @@ static void __devinit atmel_init_port(struct atmel_uart_port *atmel_port,
> }
> }
>
> -/*
> - * Register board-specific modem-control line handlers.
> - */
> -void __init atmel_register_uart_fns(struct atmel_port_fns *fns)
> -{
> - if (fns->enable_ms)
> - atmel_pops.enable_ms = fns->enable_ms;
> - if (fns->get_mctrl)
> - atmel_pops.get_mctrl = fns->get_mctrl;
> - if (fns->set_mctrl)
> - atmel_pops.set_mctrl = fns->set_mctrl;
> - atmel_open_hook = fns->open;
> - atmel_close_hook = fns->close;
> - atmel_pops.pm = fns->pm;
> - atmel_pops.set_wake = fns->set_wake;
> -}
> -
> struct platform_device *atmel_default_console_device; /* the serial console device */
>
> #ifdef CONFIG_SERIAL_ATMEL_CONSOLE
> --
> 1.7.4.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Need to remove ch35x wch driver which already running
From: Lokesh @ 2012-11-16 7:59 UTC (permalink / raw)
To: linux-serial
HI
I have a pci base serial card i.e wch35x card. for 3.0.5, the driver does not
exisits. Iam redeveloping for the same from scratch. But due mis detection, the
pci card claims a driver named "serial".
The lspci -k dispaly driver in use as serial. but in lsmod it does not lists.
I want to remove the serial module which is claiming this device. so that is i
can re write the driver just for learning purpose.
02:00.0 Serial controller: Device 4348:5046 (rev 10) (prog-if 02 [16550])
Subsystem: Device 4348:5046
Flags: medium devsel, IRQ 21
I/O ports at d030 [size=8]
I/O ports at d020 [size=8]
I/O ports at d010 [size=8]
I/O ports at d000 [size=16]
Kernel driver in use: serial
00: 48 43 46 50 01 00 00 02 10 02 00 07 00 00 00 00
10: 31 d0 00 00 21 d0 00 00 11 d0 00 00 01 d0 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 48 43 46 50
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 00 00
^ 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