* Re: [PATCH v2 1/1] staging: fwserial: Add TTY-over-Firewire serial driver
From: Stefan Richter @ 2012-11-12 23:33 UTC (permalink / raw)
To: Peter Hurley, Greg Kroah-Hartman
Cc: Alan Cox, linux-kernel, devel, linux1394-devel, linux-serial
In-Reply-To: <55547e779e65e6865f18d537ef1a42191a4b7e46.1351817601.git.peter@hurleysoftware.com>
On Nov 02 Peter Hurley wrote:
> This patch provides the kernel driver for high-speed TTY
> communication over the IEEE 1394 bus.
>
> Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Hi Greg,
you asked for an Ack. Here it is: I am OK with this getting added to the
staging tree.
(Sorry for the delay, I was ill and at the same time buried in work at the
day job.) Note, I only quickly scrolled through v1 and v2. I will do an
actual review when somebody asks to move this from staging into a proper
mainline place.
Peter,
below are some high-level comments to your TODOs.
> ---
> v2
[...]
> ---
> drivers/staging/Kconfig | 2 +
> drivers/staging/Makefile | 1 +
> drivers/staging/fwserial/Kconfig | 9 +
> drivers/staging/fwserial/Makefile | 2 +
> drivers/staging/fwserial/TODO | 37 +
> drivers/staging/fwserial/dma_fifo.c | 310 ++++
> drivers/staging/fwserial/dma_fifo.h | 130 ++
> drivers/staging/fwserial/fwserial.c | 2946 +++++++++++++++++++++++++++++++++++
> drivers/staging/fwserial/fwserial.h | 387 +++++
> 9 files changed, 3824 insertions(+)
> create mode 100644 drivers/staging/fwserial/Kconfig
> create mode 100644 drivers/staging/fwserial/Makefile
> create mode 100644 drivers/staging/fwserial/TODO
> create mode 100644 drivers/staging/fwserial/dma_fifo.c
> create mode 100644 drivers/staging/fwserial/dma_fifo.h
> create mode 100644 drivers/staging/fwserial/fwserial.c
> create mode 100644 drivers/staging/fwserial/fwserial.h
[...]
> --- /dev/null
> +++ b/drivers/staging/fwserial/Kconfig
> @@ -0,0 +1,9 @@
> +config FIREWIRE_SERIAL
> + tristate "TTY over Firewire"
> + depends on FIREWIRE
> + help
> + This enables TTY over IEEE 1394, providing high-speed serial
> + connectivity to cabled peers.
> +
> + To compile this driver as a module, say M here: the module will
> + be called firewire-serial.
This should mention that this is a Linux-only affair at this time: It uses
an ad-hoc defined protocol which no other platform is known to support for
the time being.
[...]
> --- /dev/null
> +++ b/drivers/staging/fwserial/TODO
> @@ -0,0 +1,37 @@
> +TODOs
> +-----
> +1. Implement retries for RCODE_BUSY, RCODE_NO_ACK and RCODE_SEND_ERROR
> + - I/O is handled asynchronously which presents some issues when error
> + conditions occur.
> +2. Implement _robust_ console on top of this. The existing prototype console
> + driver is not ready for the big leagues yet.
> +3. Expose means of controlling attach/detach of peers via sysfs. Include
> + GUID-to-port matching/whitelist/blacklist.
> +
> +-- Issues with firewire stack --
> +1. This driver uses the same unregistered vendor id that the firewire core does
> + (0xd00d1e). Perhaps this could be exposed as a define in
> + firewire-constants.h?
I guess there is no better OUI for this purpose.
The constant could be added to linux/firewire.h, but IMO rather not to
uapi/linux/firewire-constants.h. We don't want this definition to leak
out to userland; userland can hardwire its own hacks itself. :-)
This trivial move to a header should be deferred until the driver moves
out of staging.
> +2. MAX_ASYNC_PAYLOAD needs to be publicly exposed by core/ohci
> + - otherwise how will this driver know the max size of address window to
> + open for one packet write?
Hmm, don't firewire-sbp2 and firewire-net deal with this very problem
already on their own? Firewire-sbp2 tells the target what maximum payload
the local node is ready to accept, and firewire-net figures out whether it
needs to fragment the datagrams in unicast TX depending on the remote
node's capabilities.
> +3. Maybe device_max_receive() and link_speed_to_max_payload() should be
> + taken up by the firewire core?
Sounds like an extension of item 2, and is easier resolved after the
driver moves out of staging.
> +4. To avoid dropping rx data while still limiting the maximum buffering,
> + the size of the AR context must be known. How to expose this to drivers?
I don't see a requirement to know the local or remote node's size of AR
DMA buffer. Rather, keep the traffic throttled such that too frequent
ack-busy are avoided. As far as I have learned from firewire-net, just
limiting the number or in-flight transactions should work reasonably. Of
course, hardware ack-busy retries which the OHCI performs on its own won't
be noticed by software but take away from overall bus bandwidth. IOW the
optimum queue depth is by a certain margin less than the depth at which
software starts to see ack-busy transaction terminations.
Furthermore: In order to avoid dropping data, you don't need to know the
buffer size at all. You need to implement proper software retries. I.e.
either those which you noted yourself at the top of this TODO file, or you
let the userland on top of the TTY handle it if this is possible. (I
don't know how the TTY subsystem and TTY based applications work.)
> +5. Explore if bigger AR context will reduce RCODE_BUSY responses
> + (or auto-grow to certain max size -- but this would require major surgery
> + as the current AR is contiguously mapped)
For the particular application "firewire-net", the present AR-Req DMA
buffer size has apparently been determined as suitable. Of course if you
find a different optimum, that could certainly be changed.
I haven't looked closely, but I suppose your bandwidth requirement
concerns AR-Request DMA, not so much AR-Response DMA, right?
--
Stefan Richter
-=====-===-- =-== -==--
http://arcgraph.de/sr/
^ permalink raw reply
* KONTO UPPDATERING
From: WEBMAIL @ 2012-11-12 7:01 UTC (permalink / raw)
En DGTFX Virus har upptäckts i vår webb tjänsteleverantör. Ditt e-postkonto måste uppgraderas till vår nya Secured DGTFX antivirusprogram 2011/2012 version för att förhindra skador på vår webb leverantör och dina viktiga filer. Klicka på nedan länk, Fyll kolumnerna och skicka tillbaka till oss eller ditt e-postkonto kommer att avslutas för att undvika spridning av viruset.
aktiveringslänk
http://www.formstack.com/forms/?1326104-EUKetyz1zD
Tack för ditt samarbete.
konto Support
Varning Kod: ID67565453
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 02/10] arm: at91: move platfarm_data to include/linux/platform_data/atmel.h
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-12 14:06 UTC (permalink / raw)
To: Joachim Eastwood
Cc: linux-arm-kernel, linux-fbdev, linux-usb, rtc-linux, linux-mmc,
linux-pcmcia, Nicolas Ferre, linux-can, linux-ide, netdev,
linux-serial, linux-input, spi-devel-general
In-Reply-To: <CAGhQ9VxgbCGzOPVtQq-LYsEPuyyGjRDfB3jHPtvbHr1xLgntXA@mail.gmail.com>
On 11:54 Sat 10 Nov , Joachim Eastwood wrote:
> Hi Jean-Christophe,
>
> On 7 November 2012 12:22, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> > Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> > Cc: linux-ide@vger.kernel.org
> > Cc: linux-input@vger.kernel.org
> > Cc: linux-mmc@vger.kernel.org
> > Cc: linux-can@vger.kernel.org
> > Cc: netdev@vger.kernel.org
> > Cc: linux-pcmcia@lists.infradead.org
> > Cc: rtc-linux@googlegroups.com
> > Cc: spi-devel-general@lists.sourceforge.net
> > Cc: linux-serial@vger.kernel.org
> > Cc: linux-usb@vger.kernel.org
> > Cc: linux-fbdev@vger.kernel.org
> > ---
> > HI all,
> >
> > If it's ok with everyone this will go via at91
> > with the patch serie than clean up the include/mach
> >
> > For preparation to switch to arm multiarch kernel
> >
> > Best Regards,
> > J.
> > arch/arm/mach-at91/include/mach/board.h | 55 ----------------------
> > arch/avr32/mach-at32ap/include/mach/board.h | 7 ---
> > drivers/ata/pata_at91.c | 2 +-
> > drivers/input/touchscreen/atmel_tsadcc.c | 2 +-
> > drivers/mmc/host/atmel-mci.c | 2 +-
> > drivers/net/can/at91_can.c | 3 +-
> > drivers/net/ethernet/cadence/at91_ether.c | 2 +-
> > drivers/pcmcia/at91_cf.c | 2 +-
> > drivers/rtc/rtc-at91sam9.c | 2 +-
> > drivers/spi/spi-atmel.c | 2 +-
> > drivers/tty/serial/atmel_serial.c | 2 +-
> > drivers/usb/gadget/at91_udc.c | 2 +-
> > drivers/usb/gadget/atmel_usba_udc.c | 2 +-
> > drivers/usb/host/ohci-at91.c | 2 +-
> > drivers/video/atmel_lcdfb.c | 2 +-
> > include/linux/platform_data/atmel.h | 67 +++++++++++++++++++++++++++
> > 16 files changed, 80 insertions(+), 76 deletions(-)
>
> <snip>
>
> > diff --git a/drivers/net/ethernet/cadence/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c
> > index 4e980a7..35fc6edb 100644
> > --- a/drivers/net/ethernet/cadence/at91_ether.c
> > +++ b/drivers/net/ethernet/cadence/at91_ether.c
> > @@ -31,6 +31,7 @@
> > #include <linux/clk.h>
> > #include <linux/gfp.h>
> > #include <linux/phy.h>
> > +#include <linux/platform_data/atmel.h>
> >
> > #include <asm/io.h>
> > #include <asm/uaccess.h>
> > @@ -38,7 +39,6 @@
> >
> > #include <mach/at91rm9200_emac.h>
> > #include <asm/gpio.h>
> > -#include <mach/board.h>
> >
> > #include "at91_ether.h"
>
> The at91_ether driver in net-next does not need to be change since it
> all mach includes has already been removed by other patches and it
> includes linux/platform_data/macb.h directly.
>
> What tree was these patches based on?
> The at91_ether driver changes has been in linux-next for a long while now.
the conflict is minor easy to handle and the cleanup need to go first on arm soc so this is
based on rc3
Best Regards,
J.
^ permalink raw reply
* (unknown),
From: Jayne Montgomery @ 2012-11-12 13:21 UTC (permalink / raw)
Loan Offer at 3% interest rate, if interested in obtaining a loan contact us for more info via jason.harris511@hotmail.com
^ permalink raw reply
* (unknown),
From: Jayne Montgomery @ 2012-11-12 12:49 UTC (permalink / raw)
Loan Offer at 3% interest rate, if interested in obtaining a loan contact us for more info via jason.harris511@hotmail.com
^ permalink raw reply
* Re: [PATCH v2] serial: xilinx_uartps: kill CONFIG_OF conditional
From: Michal Simek @ 2012-11-12 12:23 UTC (permalink / raw)
To: Josh Cartwright; +Cc: Alan Cox, Greg Kroah-Hartman, linux-serial, linux-kernel
In-Reply-To: <CAHTX3dLjz=WMX_YtRQSwfUDFt1=yMoTeWd7mfqhxi1-TkSggfQ@mail.gmail.com>
2012/11/7 Michal Simek <monstr@monstr.eu>:
> 2012/11/5 Josh Cartwright <josh.cartwright@ni.com>:
>> The Zynq platform requires the use of CONFIG_OF. Remove the #ifdef
>> conditionals in the uartps driver. Make dependency explicit in Kconfig.
>>
>> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
>> ---
>> Michal-
>>
>> Here's a version of this patch outside of my COMMON_CLK patchset as you
>> requested ontop of your arm-next branch. An explicit dependency was
>> added in Kconfig as you had suggested.
>>
>> Thanks,
>> Josh
>>
>> drivers/tty/serial/Kconfig | 1 +
>> drivers/tty/serial/xilinx_uartps.c | 9 ---------
>> 2 files changed, 1 insertion(+), 9 deletions(-)
>
> Tested-by: Michal Simek <monstr@monstr.eu>
>
Greg: Can you please add this patch to your tree?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: [PATCH 2/8] ARM: zynq: move ttc timer code to drivers/clocksource
From: Michal Simek @ 2012-11-12 11:53 UTC (permalink / raw)
To: Josh Cartwright
Cc: Russell King, John Stultz, devicetree-discuss, linux-kernel,
Rob Herring, linux-serial, Greg Kroah-Hartman, Thomas Gleixner,
Alan Cox, linux-arm-kernel, Mike Turquette
In-Reply-To: <20121105214753.GB1254@beefymiracle.amer.corp.natinst.com>
2012/11/5 Josh Cartwright <josh.cartwright@ni.com>:
> On Mon, Nov 05, 2012 at 12:22:55PM +0100, Michal Simek wrote:
>> 2012/10/29 Josh Cartwright <josh.cartwright@ni.com>:
>> > Suggested cleanup by Arnd Bergmann. Move the ttc timer.c code to
>> > drivers/clocksource, and out of the mach-zynq directory.
>> >
>> > The common.h (which only held the timer declaration) was renamed to
>> > xilinx_ttc.h and moved into include/linux.
>> >
>> > Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
>> > Cc: Arnd Bergmann <arnd@arndb.de>
>> > ---
>> > arch/arm/mach-zynq/Makefile | 2 +-
>> > arch/arm/mach-zynq/common.c | 2 +-
>> > drivers/clocksource/Makefile | 1 +
>> > arch/arm/mach-zynq/timer.c => drivers/clocksource/xilinx_ttc.c | 1 -
>> > arch/arm/mach-zynq/common.h => include/linux/xilinx_ttc.h | 4 ++--
>> > 5 files changed, 5 insertions(+), 5 deletions(-)
>> > rename arch/arm/mach-zynq/timer.c => drivers/clocksource/xilinx_ttc.c (99%)
>> > rename arch/arm/mach-zynq/common.h => include/linux/xilinx_ttc.h (91%)
>>
>> Not going to apply this patch till there is clean way how to move all
>> drivers there. Especially I don't like to add xilinx_ttc.h to
>> include/linux folder.
>
> Okay; I think it's best to defer the moving of the ttc driver from this
> patchset. It is not a dependency of the clk driver support stuff.
> If you agree, I can spin up a v2 of the patchset w/o this change, and
> without the serial CONFIG_OF stuff. Should v2 contain the patches
> you've already pulled into testing?
Sure and I see you have done which is good.
Thanks,
Michal
^ permalink raw reply
* (unknown),
From: Jayne Montgomery @ 2012-11-12 10:52 UTC (permalink / raw)
Loan Offer at 3% interest rate, if interested in obtaining a loan contact us for more info via jason.harris511@hotmail.com
^ permalink raw reply
* KONTO UPPDATERING
From: WEBMAIL @ 2012-11-12 7:10 UTC (permalink / raw)
En DGTFX Virus har upptäckts i vår webb tjänsteleverantör. Ditt e-postkonto måste uppgraderas till vår nya Secured DGTFX antivirusprogram 2011/2012 version för att förhindra skador på vår webb leverantör och dina viktiga filer. Klicka på nedan länk, Fyll kolumnerna och skicka tillbaka till oss eller ditt e-postkonto kommer att avslutas för att undvika spridning av viruset.
aktiveringslänk
http://www.formstack.com/forms/?1326104-EUKetyz1zD
Tack för ditt samarbete.
konto Support
Varning Kod: ID67565453
--
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
* KONTO UPPDATERING
From: WEBMAIL @ 2012-11-12 7:05 UTC (permalink / raw)
En DGTFX Virus har upptäckts i vår webb tjänsteleverantör. Ditt e-postkonto måste uppgraderas till vår nya Secured DGTFX antivirusprogram 2011/2012 version för att förhindra skador på vår webb leverantör och dina viktiga filer. Klicka på nedan länk, Fyll kolumnerna och skicka tillbaka till oss eller ditt e-postkonto kommer att avslutas för att undvika spridning av viruset.
aktiveringslänk
http://www.formstack.com/forms/?1326104-EUKetyz1zD
Tack för ditt samarbete.
konto Support
Varning Kod: ID67565453
--
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: Unneeded ARCH dependencies are removed
From: Alexander Shiyan @ 2012-11-11 6:24 UTC (permalink / raw)
To: linux-serial; +Cc: Alan Cox, Greg Kroah-Hartman, Alexander Shiyan
This patch performs a small cleanup tty/Serial/Kconfig file by removing
unneeded ARCH dependencies. This dependencies already included in
board/type symbols.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
---
drivers/tty/serial/Kconfig | 24 ++++++++++++------------
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index b176801..500f043 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -93,7 +93,7 @@ config SERIAL_SB1250_DUART_CONSOLE
config SERIAL_ATMEL
bool "AT91 / AT32 on-chip serial port support"
- depends on (ARM && ARCH_AT91) || AVR32
+ depends on ARCH_AT91 || AVR32
select SERIAL_CORE
help
This enables the driver for the on-chip UARTs of the Atmel
@@ -198,7 +198,7 @@ config SERIAL_CLPS711X_CONSOLE
config SERIAL_SAMSUNG
tristate "Samsung SoC serial support"
- depends on ARM && PLAT_SAMSUNG
+ depends on PLAT_SAMSUNG
select SERIAL_CORE
help
Support for the on-chip UARTs on the Samsung S3C24XX series CPUs,
@@ -208,14 +208,14 @@ config SERIAL_SAMSUNG
config SERIAL_SAMSUNG_UARTS_4
bool
- depends on ARM && PLAT_SAMSUNG
+ depends on PLAT_SAMSUNG
default y if !(CPU_S3C2410 || SERIAL_S3C2412 || CPU_S3C2440 || CPU_S3C2442)
help
Internal node for the common case of 4 Samsung compatible UARTs
config SERIAL_SAMSUNG_UARTS
int
- depends on ARM && PLAT_SAMSUNG
+ depends on PLAT_SAMSUNG
default 6 if ARCH_S5P6450
default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416
default 3
@@ -249,7 +249,7 @@ config SERIAL_SAMSUNG_CONSOLE
config SERIAL_SIRFSOC
tristate "SiRF SoC Platform Serial port support"
- depends on ARM && ARCH_PRIMA2
+ depends on ARCH_PRIMA2
select SERIAL_CORE
help
Support for the on-chip UART on the CSR SiRFprimaII series,
@@ -347,7 +347,7 @@ config SERIAL_ZS_CONSOLE
config SERIAL_21285
tristate "DC21285 serial port support"
- depends on ARM && FOOTBRIDGE
+ depends on FOOTBRIDGE
select SERIAL_CORE
help
If you have a machine based on a 21285 (Footbridge) StrongARM(R)/
@@ -371,7 +371,7 @@ config SERIAL_21285_CONSOLE
config SERIAL_MPSC
bool "Marvell MPSC serial port support"
- depends on PPC32 && MV64X60
+ depends on MV64X60
select SERIAL_CORE
help
Say Y here if you want to use the Marvell MPSC serial controller.
@@ -408,7 +408,7 @@ config SERIAL_PXA_CONSOLE
config SERIAL_SA1100
bool "SA1100 serial port support"
- depends on ARM && ARCH_SA1100
+ depends on ARCH_SA1100
select SERIAL_CORE
help
If you have a machine based on a SA1100/SA1110 StrongARM(R) CPU you
@@ -716,7 +716,7 @@ config SERIAL_SH_SCI_DMA
config SERIAL_PNX8XXX
bool "Enable PNX8XXX SoCs' UART Support"
- depends on MIPS && (SOC_PNX8550 || SOC_PNX833X)
+ depends on SOC_PNX8550 || SOC_PNX833X
select SERIAL_CORE
help
If you have a MIPS-based Philips SoC such as PNX8550 or PNX8330
@@ -1013,7 +1013,7 @@ config SERIAL_SGI_IOC3
config SERIAL_MSM
bool "MSM on-chip serial port support"
- depends on ARM && ARCH_MSM
+ depends on ARCH_MSM
select SERIAL_CORE
config SERIAL_MSM_CONSOLE
@@ -1035,7 +1035,7 @@ config SERIAL_MSM_HS
config SERIAL_VT8500
bool "VIA VT8500 on-chip serial port support"
- depends on ARM && ARCH_VT8500
+ depends on ARCH_VT8500
select SERIAL_CORE
config SERIAL_VT8500_CONSOLE
@@ -1045,7 +1045,7 @@ config SERIAL_VT8500_CONSOLE
config SERIAL_NETX
tristate "NetX serial port support"
- depends on ARM && ARCH_NETX
+ depends on ARCH_NETX
select SERIAL_CORE
help
If you have a machine based on a Hilscher NetX SoC you
--
1.7.8.6
^ permalink raw reply related
* RE: 8250_early for big-endian
From: Noam Camus @ 2012-11-11 4:34 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-serial@vger.kernel.org, Vineet Gupta, Gilad Ben Yossef
In-Reply-To: <20121025121815.0689c196@pyramind.ukuu.org.uk>
________________________________________
From: Alan Cox [alan@lxorguk.ukuu.org.uk]
Sent: Thursday, October 25, 2012 1:18 PM
>If you make the symbols global then they need a prefix to avoid clashes -
>just rename them something like serial8250_early_in/serial8250_early_out
>and of course they ought to be in the header files somewhere...
Hello Alan,
I will appreciate if you can review and comment on below patch.
>From e2dda56ab679d81bb0a021e102519185028deded Mon Sep 17 00:00:00 2001
From: Noam Camus <noamc@ezchip.com>
Date: Sun, 11 Nov 2012 05:49:39 +0200
Subject: [PATCH] tty/8250_early: Turn serial_in/serial_out into weak symbols.
Allows overriding default methods serial_in/serial_out.
In such platform specific replacement it is possible to use,
other regshift, biased register offset, any other manipulation
that is not covered with common default methods.
Overriding default methods may be useful for platforms which got
serial peripheral with registers represented in big endian.
In this situation and assuming that 32 bit operations / alignment
is required then it may be useful to swab words before/after
accessing the serial registers.
Signed-off-by: Noam Camus <noamc@ezchip.com>
CC: Alan Cox <alan@lxorguk.ukuu.org.uk>
---
drivers/tty/serial/8250/8250_early.c | 42 +++++++++++++++++-----------------
include/linux/serial_8250.h | 2 +
2 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_early.c b/drivers/tty/serial/8250/8250_early.c
index eaafb98..eb88f6d 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -48,7 +48,7 @@ struct early_serial8250_device {
static struct early_serial8250_device early_device;
-static unsigned int __init serial_in(struct uart_port *port, int offset)
+unsigned int __weak __init serial8250_early_in(struct uart_port *port, int offset)
{
switch (port->iotype) {
case UPIO_MEM:
@@ -62,7 +62,7 @@ static unsigned int __init serial_in(struct uart_port *port, int offset)
}
}
-static void __init serial_out(struct uart_port *port, int offset, int value)
+void __weak __init serial8250_early_out(struct uart_port *port, int offset, int value)
{
switch (port->iotype) {
case UPIO_MEM:
@@ -84,7 +84,7 @@ static void __init wait_for_xmitr(struct uart_port *port)
unsigned int status;
for (;;) {
- status = serial_in(port, UART_LSR);
+ status = serial8250_early_in(port, UART_LSR);
if ((status & BOTH_EMPTY) == BOTH_EMPTY)
return;
cpu_relax();
@@ -94,7 +94,7 @@ static void __init wait_for_xmitr(struct uart_port *port)
static void __init serial_putc(struct uart_port *port, int c)
{
wait_for_xmitr(port);
- serial_out(port, UART_TX, c);
+ serial8250_early_out(port, UART_TX, c);
}
static void __init early_serial8250_write(struct console *console,
@@ -104,14 +104,14 @@ static void __init early_serial8250_write(struct console *console,
unsigned int ier;
/* Save the IER and disable interrupts */
- ier = serial_in(port, UART_IER);
- serial_out(port, UART_IER, 0);
+ ier = serial8250_early_in(port, UART_IER);
+ serial8250_early_out(port, UART_IER, 0);
uart_console_write(port, s, count, serial_putc);
/* Wait for transmitter to become empty and restore the IER */
wait_for_xmitr(port);
- serial_out(port, UART_IER, ier);
+ serial8250_early_out(port, UART_IER, ier);
}
static unsigned int __init probe_baud(struct uart_port *port)
@@ -119,11 +119,11 @@ static unsigned int __init probe_baud(struct uart_port *port)
unsigned char lcr, dll, dlm;
unsigned int quot;
- lcr = serial_in(port, UART_LCR);
- serial_out(port, UART_LCR, lcr | UART_LCR_DLAB);
- dll = serial_in(port, UART_DLL);
- dlm = serial_in(port, UART_DLM);
- serial_out(port, UART_LCR, lcr);
+ lcr = serial8250_early_in(port, UART_LCR);
+ serial8250_early_out(port, UART_LCR, lcr | UART_LCR_DLAB);
+ dll = serial8250_early_in(port, UART_DLL);
+ dlm = serial8250_early_in(port, UART_DLM);
+ serial8250_early_out(port, UART_LCR, lcr);
quot = (dlm << 8) | dll;
return (port->uartclk / 16) / quot;
@@ -135,17 +135,17 @@ static void __init init_port(struct early_serial8250_device *device)
unsigned int divisor;
unsigned char c;
- serial_out(port, UART_LCR, 0x3); /* 8n1 */
- serial_out(port, UART_IER, 0); /* no interrupt */
- serial_out(port, UART_FCR, 0); /* no fifo */
- serial_out(port, UART_MCR, 0x3); /* DTR + RTS */
+ serial8250_early_out(port, UART_LCR, 0x3); /* 8n1 */
+ serial8250_early_out(port, UART_IER, 0); /* no interrupt */
+ serial8250_early_out(port, UART_FCR, 0); /* no fifo */
+ serial8250_early_out(port, UART_MCR, 0x3); /* DTR + RTS */
divisor = port->uartclk / (16 * device->baud);
- c = serial_in(port, UART_LCR);
- serial_out(port, UART_LCR, c | UART_LCR_DLAB);
- serial_out(port, UART_DLL, divisor & 0xff);
- serial_out(port, UART_DLM, (divisor >> 8) & 0xff);
- serial_out(port, UART_LCR, c & ~UART_LCR_DLAB);
+ c = serial8250_early_in(port, UART_LCR);
+ serial8250_early_out(port, UART_LCR, c | UART_LCR_DLAB);
+ serial8250_early_out(port, UART_DLL, divisor & 0xff);
+ serial8250_early_out(port, UART_DLM, (divisor >> 8) & 0xff);
+ serial8250_early_out(port, UART_LCR, c & ~UART_LCR_DLAB);
}
static int __init parse_options(struct early_serial8250_device *device,
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index c174c90..c490d20 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -105,6 +105,8 @@ extern int early_serial_setup(struct uart_port *port);
extern int serial8250_find_port(struct uart_port *p);
extern int serial8250_find_port_for_earlycon(void);
+extern unsigned int serial8250_early_in(struct uart_port *port, int offset);
+extern void serial8250_early_out(struct uart_port *port, int offset, int value);
extern int setup_early_serial8250_console(char *cmdline);
extern void serial8250_do_set_termios(struct uart_port *port,
struct ktermios *termios, struct ktermios *old);
--
1.7.1
regards,
Noam
^ permalink raw reply related
* Re: [PATCH] serial/8250: Add support for Exar's XR17V35x family of multi-port PCIe UARTs.
From: Alan Cox @ 2012-11-10 23:24 UTC (permalink / raw)
To: Matt Schulte; +Cc: linux-serial, Greg KH, Theodore Ts'o
In-Reply-To: <CAJp1Oe652P=eGTQjo2aWwn2f0iMDz0dM172QjkBcZhx+O2_Ygw@mail.gmail.com>
On Sat, 10 Nov 2012 11:52:32 -0600
Matt Schulte <matts@commtech-fastcom.com> wrote:
> On Fri, Nov 9, 2012 at 5:58 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >> @@ -1484,6 +1526,7 @@ EXPORT_SYMBOL_GPL(serial8250_modem_status);
> >> int serial8250_handle_irq(struct uart_port *port, unsigned int iir)
> >> {
> >> unsigned char status;
> >> + unsigned char int0, int1, int2, int3;
> >> unsigned long flags;
> >> struct uart_8250_port *up =
> >> container_of(port, struct uart_8250_port, port);
> >> @@ -1503,6 +1546,19 @@ int serial8250_handle_irq(struct uart_port
> >> *port, unsigned int iir)
> >> if (status & UART_LSR_THRE)
> >> serial8250_tx_chars(up);
> >>
> >> + /*
> >> + * These Exar UARTs have an extra interrupt indicator that could
> >> + * fire for a few unimplemented interrupts. Put this here just
> >> + * to be on the safe side that these interrupts don't go unhandled.
> >> + */
> >> +
> >> + if (up->port.type == PORT_XR17V35X && status == 0) {
> >> + int0 = serial_port_in(port, 0x80);
> >> + int1 = serial_port_in(port, 0x81);
> >> + int2 = serial_port_in(port, 0x82);
> >> + int3 = serial_port_in(port, 0x83);
> >> + }
> >> +
> >> spin_unlock_irqrestore(&port->lock, flags);
> >> return 1;
> >
> > Provide your own handle_irq method rather than adding more special cases
> > to the default one (you can just wrap the default one and then perform
> > the extra actions). Just a case of trying to keep the fast paths clean and
> > maintainable.
> >
> > Otherwise looks good.
> >
> > Alan
>
> Thanks Alan, would the new Exar_handle_irq method be allowed to be
> inside 8250.c?
If its probed generically then it probably should - we can move it later
anyway
^ permalink raw reply
* Re: [PATCH] serial/8250: Add support for Exar's XR17V35x family of multi-port PCIe UARTs.
From: Matt Schulte @ 2012-11-10 17:52 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-serial, Greg KH, Theodore Ts'o
In-Reply-To: <20121109235800.745dcf15@pyramind.ukuu.org.uk>
On Fri, Nov 9, 2012 at 5:58 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> @@ -1484,6 +1526,7 @@ EXPORT_SYMBOL_GPL(serial8250_modem_status);
>> int serial8250_handle_irq(struct uart_port *port, unsigned int iir)
>> {
>> unsigned char status;
>> + unsigned char int0, int1, int2, int3;
>> unsigned long flags;
>> struct uart_8250_port *up =
>> container_of(port, struct uart_8250_port, port);
>> @@ -1503,6 +1546,19 @@ int serial8250_handle_irq(struct uart_port
>> *port, unsigned int iir)
>> if (status & UART_LSR_THRE)
>> serial8250_tx_chars(up);
>>
>> + /*
>> + * These Exar UARTs have an extra interrupt indicator that could
>> + * fire for a few unimplemented interrupts. Put this here just
>> + * to be on the safe side that these interrupts don't go unhandled.
>> + */
>> +
>> + if (up->port.type == PORT_XR17V35X && status == 0) {
>> + int0 = serial_port_in(port, 0x80);
>> + int1 = serial_port_in(port, 0x81);
>> + int2 = serial_port_in(port, 0x82);
>> + int3 = serial_port_in(port, 0x83);
>> + }
>> +
>> spin_unlock_irqrestore(&port->lock, flags);
>> return 1;
>
> Provide your own handle_irq method rather than adding more special cases
> to the default one (you can just wrap the default one and then perform
> the extra actions). Just a case of trying to keep the fast paths clean and
> maintainable.
>
> Otherwise looks good.
>
> Alan
Thanks Alan, would the new Exar_handle_irq method be allowed to be
inside 8250.c?
Matt
^ permalink raw reply
* Re: [PATCH 02/10] arm: at91: move platfarm_data to include/linux/platform_data/atmel.h
From: Joachim Eastwood @ 2012-11-10 10:54 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: linux-arm-kernel, linux-fbdev, linux-usb, rtc-linux, linux-mmc,
linux-pcmcia, Nicolas Ferre, linux-can, linux-ide, netdev,
linux-serial, linux-input, spi-devel-general
In-Reply-To: <1352287374-25176-2-git-send-email-plagnioj@jcrosoft.com>
Hi Jean-Christophe,
On 7 November 2012 12:22, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: linux-ide@vger.kernel.org
> Cc: linux-input@vger.kernel.org
> Cc: linux-mmc@vger.kernel.org
> Cc: linux-can@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Cc: linux-pcmcia@lists.infradead.org
> Cc: rtc-linux@googlegroups.com
> Cc: spi-devel-general@lists.sourceforge.net
> Cc: linux-serial@vger.kernel.org
> Cc: linux-usb@vger.kernel.org
> Cc: linux-fbdev@vger.kernel.org
> ---
> HI all,
>
> If it's ok with everyone this will go via at91
> with the patch serie than clean up the include/mach
>
> For preparation to switch to arm multiarch kernel
>
> Best Regards,
> J.
> arch/arm/mach-at91/include/mach/board.h | 55 ----------------------
> arch/avr32/mach-at32ap/include/mach/board.h | 7 ---
> drivers/ata/pata_at91.c | 2 +-
> drivers/input/touchscreen/atmel_tsadcc.c | 2 +-
> drivers/mmc/host/atmel-mci.c | 2 +-
> drivers/net/can/at91_can.c | 3 +-
> drivers/net/ethernet/cadence/at91_ether.c | 2 +-
> drivers/pcmcia/at91_cf.c | 2 +-
> drivers/rtc/rtc-at91sam9.c | 2 +-
> drivers/spi/spi-atmel.c | 2 +-
> drivers/tty/serial/atmel_serial.c | 2 +-
> drivers/usb/gadget/at91_udc.c | 2 +-
> drivers/usb/gadget/atmel_usba_udc.c | 2 +-
> drivers/usb/host/ohci-at91.c | 2 +-
> drivers/video/atmel_lcdfb.c | 2 +-
> include/linux/platform_data/atmel.h | 67 +++++++++++++++++++++++++++
> 16 files changed, 80 insertions(+), 76 deletions(-)
<snip>
> diff --git a/drivers/net/ethernet/cadence/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c
> index 4e980a7..35fc6edb 100644
> --- a/drivers/net/ethernet/cadence/at91_ether.c
> +++ b/drivers/net/ethernet/cadence/at91_ether.c
> @@ -31,6 +31,7 @@
> #include <linux/clk.h>
> #include <linux/gfp.h>
> #include <linux/phy.h>
> +#include <linux/platform_data/atmel.h>
>
> #include <asm/io.h>
> #include <asm/uaccess.h>
> @@ -38,7 +39,6 @@
>
> #include <mach/at91rm9200_emac.h>
> #include <asm/gpio.h>
> -#include <mach/board.h>
>
> #include "at91_ether.h"
The at91_ether driver in net-next does not need to be change since it
all mach includes has already been removed by other patches and it
includes linux/platform_data/macb.h directly.
What tree was these patches based on?
The at91_ether driver changes has been in linux-next for a long while now.
regards
Joachim Eastwood
^ permalink raw reply
* Re: [PATCH 02/10] arm: at91: move platfarm_data to include/linux/platform_data/atmel.h
From: Dmitry Torokhov @ 2012-11-10 8:42 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-pcmcia-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Nicolas Ferre,
linux-can-u79uwXL29TY76Z2rM5mHXA,
linux-ide-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Jean-Christophe PLAGNIOL-VILLARD,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <509A5219.2080408-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Wed, Nov 07, 2012 at 01:20:41PM +0100, Marc Kleine-Budde wrote:
> On 11/07/2012 12:22 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
> > Cc: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
> > Cc: linux-ide-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Cc: linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Cc: linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Cc: linux-can-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Cc: linux-pcmcia-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> > Cc: rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
> > Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > ---
> > HI all,
> >
> > If it's ok with everyone this will go via at91
> > with the patch serie than clean up the include/mach
>
> Fine with me.
>
> > For preparation to switch to arm multiarch kernel
>
> Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> (for the CAN related changes)
Acked-by: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
for input piece.
--
Dmitry
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
^ permalink raw reply
* Re: [PATCH] serial/8250: Add support for Exar's XR17V35x family of multi-port PCIe UARTs.
From: Alan Cox @ 2012-11-09 23:58 UTC (permalink / raw)
To: Matt Schulte; +Cc: linux-serial, Greg KH, Theodore Ts'o
In-Reply-To: <CAJp1Oe4DuffN_EWP-zVznBX+JqnE6kEAsXS1oHvfvfLC5DVOAw@mail.gmail.com>
> @@ -1484,6 +1526,7 @@ EXPORT_SYMBOL_GPL(serial8250_modem_status);
> int serial8250_handle_irq(struct uart_port *port, unsigned int iir)
> {
> unsigned char status;
> + unsigned char int0, int1, int2, int3;
> unsigned long flags;
> struct uart_8250_port *up =
> container_of(port, struct uart_8250_port, port);
> @@ -1503,6 +1546,19 @@ int serial8250_handle_irq(struct uart_port
> *port, unsigned int iir)
> if (status & UART_LSR_THRE)
> serial8250_tx_chars(up);
>
> + /*
> + * These Exar UARTs have an extra interrupt indicator that could
> + * fire for a few unimplemented interrupts. Put this here just
> + * to be on the safe side that these interrupts don't go unhandled.
> + */
> +
> + if (up->port.type == PORT_XR17V35X && status == 0) {
> + int0 = serial_port_in(port, 0x80);
> + int1 = serial_port_in(port, 0x81);
> + int2 = serial_port_in(port, 0x82);
> + int3 = serial_port_in(port, 0x83);
> + }
> +
> spin_unlock_irqrestore(&port->lock, flags);
> return 1;
Provide your own handle_irq method rather than adding more special cases
to the default one (you can just wrap the default one and then perform
the extra actions). Just a case of trying to keep the fast paths clean and
maintainable.
Otherwise looks good.
Alan
^ permalink raw reply
* [PATCH] serial/8250: Add support for Exar's XR17V35x family of multi-port PCIe UARTs.
From: Matt Schulte @ 2012-11-09 22:39 UTC (permalink / raw)
To: linux-serial; +Cc: Greg KH, Theodore Ts'o, Alan Cox
From: Matt Schulte <matts@commtech-fastcom.com>
Add support for new devices - Exar's XR17V35x family of multi-port PCIe UARTs.
Built against tty-next 76cc43868c1e9d6344ad6c4992c4f6abd5204a8f
Signed-off-by: Matt Schulte <matts@commtech-fastcom.com>
---
This is the first time I've sent in a patch so let me know if I did
something wrong.
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.
drivers/tty/serial/8250/8250.c | 56 +++++++++++++++++++++
drivers/tty/serial/8250/8250_pci.c | 95 ++++++++++++++++++++++++++++++++++++
include/linux/pci_ids.h | 3 +
include/uapi/linux/serial_core.h | 3 +-
include/uapi/linux/serial_reg.h | 6 ++
5 files changed, 162 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index 5ccbd90..b46066a 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -282,6 +282,15 @@ static const struct serial8250_config uart_config[] = {
.fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
.flags = UART_CAP_FIFO | UART_CAP_AFE | UART_CAP_EFR,
},
+ [PORT_XR17V35X] = {
+ .name = "XR17V35X",
+ .fifo_size = 256,
+ .tx_loadsz = 256,
+ .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_11 |
+ UART_FCR_T_TRIG_11,
+ .flags = UART_CAP_FIFO | UART_CAP_AFE | UART_CAP_EFR |
+ UART_CAP_SLEEP,
+ },
[PORT_LPC3220] = {
.name = "LPC3220",
.fifo_size = 64,
@@ -574,6 +583,18 @@ EXPORT_SYMBOL_GPL(serial8250_clear_and_reinit_fifos);
*/
static void serial8250_set_sleep(struct uart_8250_port *p, int sleep)
{
+ /*
+ * Exar UARTs have a SLEEP register that enables or disables
+ * each UART to enter sleep mode separately. On the XR17V35x the
+ * register is accessible to each UART at the UART_EXAR_SLEEP
+ * offset but the UART channel may only write to the corresponding
+ * bit.
+ */
+ if (p->port.type == PORT_XR17V35X) {
+ serial_out(p, UART_EXAR_SLEEP, 0xff);
+ return;
+ }
+
if (p->capabilities & UART_CAP_SLEEP) {
if (p->capabilities & UART_CAP_EFR) {
serial_out(p, UART_LCR, UART_LCR_CONF_MODE_B);
@@ -882,6 +903,27 @@ static void autoconfig_16550a(struct uart_8250_port *up)
up->capabilities |= UART_CAP_FIFO;
/*
+ * XR17V35x UARTs have an extra divisor register, DLD
+ * that gets enabled with when DLAB is set which will
+ * cause the device to incorrectly match and assign
+ * port type to PORT_16650. The EFR for this UART is
+ * found at offset 0x09. Instead check the Deice ID (DVID)
+ * register for a 2, 4 or 8 port UART.
+ */
+ status1 = serial_in(up, UART_EXAR_DVID);
+ if (status1 == 0x82 || status1 == 0x84 || status1 == 0x88) {
+ if (up->port.flags & UPF_EXAR_EFR) {
+ DEBUG_AUTOCONF("Exar XR17V35x ");
+ up->port.type = PORT_XR17V35X;
+ up->capabilities |= UART_CAP_AFE | UART_CAP_EFR |
+ UART_CAP_SLEEP;
+
+ return;
+ }
+
+ }
+
+ /*
* Check for presence of the EFR when DLAB is set.
* Only ST16C650V1 UARTs pass this test.
*/
@@ -1484,6 +1526,7 @@ EXPORT_SYMBOL_GPL(serial8250_modem_status);
int serial8250_handle_irq(struct uart_port *port, unsigned int iir)
{
unsigned char status;
+ unsigned char int0, int1, int2, int3;
unsigned long flags;
struct uart_8250_port *up =
container_of(port, struct uart_8250_port, port);
@@ -1503,6 +1546,19 @@ int serial8250_handle_irq(struct uart_port
*port, unsigned int iir)
if (status & UART_LSR_THRE)
serial8250_tx_chars(up);
+ /*
+ * These Exar UARTs have an extra interrupt indicator that could
+ * fire for a few unimplemented interrupts. Put this here just
+ * to be on the safe side that these interrupts don't go unhandled.
+ */
+
+ if (up->port.type == PORT_XR17V35X && status == 0) {
+ int0 = serial_port_in(port, 0x80);
+ int1 = serial_port_in(port, 0x81);
+ int2 = serial_port_in(port, 0x82);
+ int3 = serial_port_in(port, 0x83);
+ }
+
spin_unlock_irqrestore(&port->lock, flags);
return 1;
}
diff --git a/drivers/tty/serial/8250/8250_pci.c
b/drivers/tty/serial/8250/8250_pci.c
index 508063b..b724593 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1165,6 +1165,38 @@ pci_xr17c154_setup(struct serial_private *priv,
}
static int
+pci_xr17v35x_setup(struct serial_private *priv,
+ const struct pciserial_board *board,
+ struct uart_8250_port *port, int idx)
+{
+ u8 __iomem *p;
+
+ p = pci_ioremap_bar(priv->dev, 0);
+
+ /*
+ * Setup Multipurpose Input/Output pins.
+ */
+
+ port->port.flags |= UPF_EXAR_EFR;
+ if (idx == 0) {
+ writeb(0x00, p + 0x8f); /*MPIOINT[7:0]*/
+ writeb(0x00, p + 0x90); /*MPIOLVL[7:0]*/
+ writeb(0x00, p + 0x91); /*MPIO3T[7:0]*/
+ writeb(0x00, p + 0x92); /*MPIOINV[7:0]*/
+ writeb(0x00, p + 0x93); /*MPIOSEL[7:0]*/
+ writeb(0x00, p + 0x94); /*MPIOOD[7:0]*/
+ writeb(0x00, p + 0x95); /*MPIOINT[15:8]*/
+ writeb(0x00, p + 0x96); /*MPIOLVL[15:8]*/
+ writeb(0x00, p + 0x97); /*MPIO3T[15:8]*/
+ writeb(0x00, p + 0x98); /*MPIOINV[15:8]*/
+ writeb(0x00, p + 0x99); /*MPIOSEL[15:8]*/
+ writeb(0x00, p + 0x9a); /*MPIOOD[15:8]*/
+ }
+ iounmap(p);
+ return pci_default_setup(priv, board, port, idx);
+}
+
+static int
pci_wch_ch353_setup(struct serial_private *priv,
const struct pciserial_board *board,
struct uart_8250_port *port, int idx)
@@ -1622,6 +1654,27 @@ static struct pci_serial_quirk
pci_serial_quirks[] __refdata = {
.subdevice = PCI_ANY_ID,
.setup = pci_xr17c154_setup,
},
+ {
+ .vendor = PCI_VENDOR_ID_EXAR,
+ .device = PCI_DEVICE_ID_EXAR_XR17V352,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .setup = pci_xr17v35x_setup,
+ },
+ {
+ .vendor = PCI_VENDOR_ID_EXAR,
+ .device = PCI_DEVICE_ID_EXAR_XR17V354,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .setup = pci_xr17v35x_setup,
+ },
+ {
+ .vendor = PCI_VENDOR_ID_EXAR,
+ .device = PCI_DEVICE_ID_EXAR_XR17V358,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .setup = pci_xr17v35x_setup,
+ },
/*
* Xircom cards
*/
@@ -1962,6 +2015,9 @@ enum pci_board_num_t {
pbn_exar_XR17C152,
pbn_exar_XR17C154,
pbn_exar_XR17C158,
+ pbn_exar_XR17V352,
+ pbn_exar_XR17V354,
+ pbn_exar_XR17V358,
pbn_exar_ibm_saturn,
pbn_pasemi_1682M,
pbn_ni8430_2,
@@ -2580,6 +2636,30 @@ static struct pciserial_board pci_boards[]
__devinitdata = {
.base_baud = 921600,
.uart_offset = 0x200,
},
+ [pbn_exar_XR17V352] = {
+ .flags = FL_BASE0,
+ .num_ports = 2,
+ .base_baud = 7812500,
+ .uart_offset = 0x400,
+ .reg_shift = 0,
+ .first_offset = 0,
+ },
+ [pbn_exar_XR17V354] = {
+ .flags = FL_BASE0,
+ .num_ports = 4,
+ .base_baud = 7812500,
+ .uart_offset = 0x400,
+ .reg_shift = 0,
+ .first_offset = 0,
+ },
+ [pbn_exar_XR17V358] = {
+ .flags = FL_BASE0,
+ .num_ports = 8,
+ .base_baud = 7812500,
+ .uart_offset = 0x400,
+ .reg_shift = 0,
+ .first_offset = 0,
+ },
[pbn_exar_ibm_saturn] = {
.flags = FL_BASE0,
.num_ports = 1,
@@ -3826,6 +3906,21 @@ static struct pci_device_id serial_pci_tbl[] = {
PCI_ANY_ID, PCI_ANY_ID,
0,
0, pbn_exar_XR17C158 },
+ /*
+ * Exar Corp. XR17V35[248] Dual/Quad/Octal PCIe UARTs
+ */
+ { PCI_VENDOR_ID_EXAR, PCI_DEVICE_ID_EXAR_XR17V352,
+ PCI_ANY_ID, PCI_ANY_ID,
+ 0,
+ 0, pbn_exar_XR17V352 },
+ { PCI_VENDOR_ID_EXAR, PCI_DEVICE_ID_EXAR_XR17V354,
+ PCI_ANY_ID, PCI_ANY_ID,
+ 0,
+ 0, pbn_exar_XR17V354 },
+ { PCI_VENDOR_ID_EXAR, PCI_DEVICE_ID_EXAR_XR17V358,
+ PCI_ANY_ID, PCI_ANY_ID,
+ 0,
+ 0, pbn_exar_XR17V358 },
/*
* Topic TP560 Data/Fax/Voice 56k modem (reported by Evan Clarke)
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 9d36b82..0199a7a 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1985,6 +1985,9 @@
#define PCI_DEVICE_ID_EXAR_XR17C152 0x0152
#define PCI_DEVICE_ID_EXAR_XR17C154 0x0154
#define PCI_DEVICE_ID_EXAR_XR17C158 0x0158
+#define PCI_DEVICE_ID_EXAR_XR17V352 0x0352
+#define PCI_DEVICE_ID_EXAR_XR17V354 0x0354
+#define PCI_DEVICE_ID_EXAR_XR17V358 0x0358
#define PCI_VENDOR_ID_MICROGATE 0x13c0
#define PCI_DEVICE_ID_MICROGATE_USC 0x0010
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index ebcc73f..78f99d9 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -49,7 +49,8 @@
#define PORT_XR17D15X 21 /* Exar XR17D15x UART */
#define PORT_LPC3220 22 /* NXP LPC32xx SoC "Standard" UART */
#define PORT_8250_CIR 23 /* CIR infrared port, has its own driver */
-#define PORT_MAX_8250 23 /* max port ID */
+#define PORT_XR17V35X 24 /* Exar XR17V35x UARTs */
+#define PORT_MAX_8250 24 /* max port ID */
/*
* ARM specific type numbers. These are not currently guaranteed
diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h
index 5ed325e..d0b4760 100644
--- a/include/uapi/linux/serial_reg.h
+++ b/include/uapi/linux/serial_reg.h
@@ -367,5 +367,11 @@
#define UART_OMAP_MDR1_CIR_MODE 0x06 /* CIR mode */
#define UART_OMAP_MDR1_DISABLE 0x07 /* Disable (default state) */
+/*
+ * These are definitions for the XR17V35X and XR17D15X
+ */
+#define UART_EXAR_SLEEP 0x8b /* Sleep mode */
+#define UART_EXAR_DVID 0x8d /* Device identification */
+
#endif /* _LINUX_SERIAL_REG_H */
--
1.7.2.5
^ permalink raw reply related
* Upgrade!
From: Administrador do Sistema @ 2012-11-09 13:35 UTC (permalink / raw)
ATENÇÃO;
Sua caixa de correio excedeu o limite de armazenamento que é de 5 GB, como definido pelo administrador, que está atualmente em execução no 10.9GB, você pode não ser capaz de enviar ou receber novas mensagens até que você re-validar a sua caixa de correio. Para revalidar sua caixa postal, envie os seguintes dados abaixo:
nome:
Nome de usuário:
senha:
Confirme a Senha:
E-mail:
Se você não conseguir revalidar sua caixa de correio, o correio será desactivado!
obrigado
Administrador do Sistema
--
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
* Sorry, please ignore the last email
From: Ming Li Wu @ 2012-11-08 12:06 UTC (permalink / raw)
To: linux-serial
Hi,
I am really sorry. please ignore the last email.
Mingli
^ permalink raw reply
* [PATCH 1/2] serial: mxs-auart: Allow device tree probing
From: Mingli Wu @ 2012-11-08 11:08 UTC (permalink / raw)
To: jonas
Cc: jonash, Fabio Estevam, Grant Likely, Rob Herring, Alan Cox,
linux-serial, Subodh Nijsure, Shawn Guo
From: Fabio Estevam <fabio.estevam@freescale.com>
Allow device tree probing.
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: <linux-serial@vger.kernel.org>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Subodh Nijsure <snijsure@grid-net.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
.../bindings/tty/serial/fsl-mxs-auart.txt | 27 +++++++++++++
drivers/tty/serial/mxs-auart.c | 42 +++++++++++++++++++-
2 files changed, 67 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
new file mode 100644
index 0000000..2ee903f
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
@@ -0,0 +1,27 @@
+* Freescale MXS Application UART (AUART)
+
+Required properties:
+- compatible : Should be "fsl,<soc>-auart". The supported SoCs include
+ imx23 and imx28.
+- reg : Address and length of the register set for the device
+- interrupts : Should contain the auart interrupt numbers
+
+Example:
+auart0: serial@8006a000 {
+ compatible = "fsl,imx28-auart", "fsl,imx23-auart";
+ reg = <0x8006a000 0x2000>;
+ interrupts = <112 70 71>;
+};
+
+Note: Each auart port should have an alias correctly numbered in "aliases"
+node.
+
+Example:
+
+aliases {
+ serial0 = &auart0;
+ serial1 = &auart1;
+ serial2 = &auart2;
+ serial3 = &auart3;
+ serial4 = &auart4;
+};
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index ec56d83..2e341b8 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -33,6 +33,7 @@
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/pinctrl/consumer.h>
+#include <linux/of_device.h>
#include <asm/cacheflush.h>
@@ -675,6 +676,30 @@ static struct uart_driver auart_driver = {
#endif
};
+/*
+ * This function returns 1 if pdev isn't a device instatiated by dt, 0 if it
+ * could successfully get all information from dt or a negative errno.
+ */
+static int serial_mxs_probe_dt(struct mxs_auart_port *s,
+ struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ int ret;
+
+ if (!np)
+ /* no device tree device */
+ return 1;
+
+ ret = of_alias_get_id(np, "serial");
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to get alias id: %d\n", ret);
+ return ret;
+ }
+ s->port.line = ret;
+
+ return 0;
+}
+
static int __devinit mxs_auart_probe(struct platform_device *pdev)
{
struct mxs_auart_port *s;
@@ -689,6 +714,12 @@ static int __devinit mxs_auart_probe(struct platform_device *pdev)
goto out;
}
+ ret = serial_mxs_probe_dt(s, pdev);
+ if (ret > 0)
+ s->port.line = pdev->id < 0 ? 0 : pdev->id;
+ else if (ret < 0)
+ goto out_free;
+
pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
if (IS_ERR(pinctrl)) {
ret = PTR_ERR(pinctrl);
@@ -711,7 +742,6 @@ static int __devinit mxs_auart_probe(struct platform_device *pdev)
s->port.membase = ioremap(r->start, resource_size(r));
s->port.ops = &mxs_auart_ops;
s->port.iotype = UPIO_MEM;
- s->port.line = pdev->id < 0 ? 0 : pdev->id;
s->port.fifosize = 16;
s->port.uartclk = clk_get_rate(s->clk);
s->port.type = PORT_IMX;
@@ -728,7 +758,7 @@ static int __devinit mxs_auart_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, s);
- auart_port[pdev->id] = s;
+ auart_port[s->port.line] = s;
mxs_auart_reset(&s->port);
@@ -769,12 +799,19 @@ static int __devexit mxs_auart_remove(struct platform_device *pdev)
return 0;
}
+static struct of_device_id mxs_auart_dt_ids[] = {
+ { .compatible = "fsl,imx23-auart", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mxs_auart_dt_ids);
+
static struct platform_driver mxs_auart_driver = {
.probe = mxs_auart_probe,
.remove = __devexit_p(mxs_auart_remove),
.driver = {
.name = "mxs-auart",
.owner = THIS_MODULE,
+ .of_match_table = mxs_auart_dt_ids,
},
};
@@ -807,3 +844,4 @@ module_init(mxs_auart_init);
module_exit(mxs_auart_exit);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Freescale MXS application uart driver");
+MODULE_ALIAS("platform:mxs-auart");
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] serial: mfd: Add nmi_touch_watchdog() into the console write function
From: Alan Cox @ 2012-11-08 10:54 UTC (permalink / raw)
To: Feng Tang; +Cc: linux-serial, gregkh, alan
In-Reply-To: <1352355053-30040-1-git-send-email-feng.tang@intel.com>
On Thu, 8 Nov 2012 14:10:53 +0800
Feng Tang <feng.tang@intel.com> wrote:
> This is following what 8250 driver is doing in console write function,
> to avoid the hardware lockup case.
>
> Signed-off-by: Feng Tang <feng.tang@intel.com>
Looks fine to me.
Acked-by: Alan Cox <alan@linux.intel.com>
^ permalink raw reply
* [PATCH] serial: mfd: Add nmi_touch_watchdog() into the console write function
From: Feng Tang @ 2012-11-08 6:10 UTC (permalink / raw)
To: linux-serial, gregkh, alan; +Cc: Feng Tang
This is following what 8250 driver is doing in console write function,
to avoid the hardware lockup case.
Signed-off-by: Feng Tang <feng.tang@intel.com>
---
drivers/tty/serial/mfd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/mfd.c b/drivers/tty/serial/mfd.c
index c4b50af..bde9fce 100644
--- a/drivers/tty/serial/mfd.c
+++ b/drivers/tty/serial/mfd.c
@@ -1113,6 +1113,8 @@ serial_hsu_console_write(struct console *co, const char *s, unsigned int count)
unsigned int ier;
int locked = 1;
+ touch_nmi_watchdog();
+
local_irq_save(flags);
if (up->port.sysrq)
locked = 0;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2] serial: xilinx_uartps: kill CONFIG_OF conditional
From: Michal Simek @ 2012-11-07 13:04 UTC (permalink / raw)
To: Josh Cartwright; +Cc: Alan Cox, Greg Kroah-Hartman, linux-serial, linux-kernel
In-Reply-To: <20121105212426.GA1972@beefymiracle.amer.corp.natinst.com>
2012/11/5 Josh Cartwright <josh.cartwright@ni.com>:
> The Zynq platform requires the use of CONFIG_OF. Remove the #ifdef
> conditionals in the uartps driver. Make dependency explicit in Kconfig.
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
> ---
> Michal-
>
> Here's a version of this patch outside of my COMMON_CLK patchset as you
> requested ontop of your arm-next branch. An explicit dependency was
> added in Kconfig as you had suggested.
>
> Thanks,
> Josh
>
> drivers/tty/serial/Kconfig | 1 +
> drivers/tty/serial/xilinx_uartps.c | 9 ---------
> 2 files changed, 1 insertion(+), 9 deletions(-)
Tested-by: Michal Simek <monstr@monstr.eu>
Alan: Can you please add this patch to your tree?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: [PATCH 02/10] arm: at91: move platfarm_data to include/linux/platform_data/atmel.h
From: Marc Kleine-Budde @ 2012-11-07 12:20 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: linux-arm-kernel, Nicolas Ferre, linux-ide, linux-input,
linux-mmc, linux-can, netdev, linux-pcmcia, rtc-linux,
spi-devel-general, linux-serial, linux-usb, linux-fbdev
In-Reply-To: <1352287374-25176-2-git-send-email-plagnioj@jcrosoft.com>
[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]
On 11/07/2012 12:22 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: linux-ide@vger.kernel.org
> Cc: linux-input@vger.kernel.org
> Cc: linux-mmc@vger.kernel.org
> Cc: linux-can@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Cc: linux-pcmcia@lists.infradead.org
> Cc: rtc-linux@googlegroups.com
> Cc: spi-devel-general@lists.sourceforge.net
> Cc: linux-serial@vger.kernel.org
> Cc: linux-usb@vger.kernel.org
> Cc: linux-fbdev@vger.kernel.org
> ---
> HI all,
>
> If it's ok with everyone this will go via at91
> with the patch serie than clean up the include/mach
Fine with me.
> For preparation to switch to arm multiarch kernel
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> (for the CAN related changes)
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ 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