Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752515AbbG3PmB (ORCPT ); Thu, 30 Jul 2015 11:42:01 -0400 Received: from eusmtp01.atmel.com ([212.144.249.242]:57013 "EHLO eusmtp01.atmel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751215AbbG3Pl6 (ORCPT ); Thu, 30 Jul 2015 11:41:58 -0400 Message-ID: <55BA4582.8050401@atmel.com> Date: Thu, 30 Jul 2015 17:40:50 +0200 From: Nicolas Ferre Organization: atmel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Cyrille Pitchen , , , , , CC: , Subject: Re: [PATCH linux-next 1/1] tty/serial: at91: fix I/O accesses on RHR and THR for AVR32 References: In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.161.30.18] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5518 Lines: 159 Le 30/07/2015 16:33, Cyrille Pitchen a ?crit : > This patch fixes I/O accesses on the Receiver Holding Register and on the > Transmitter Holding Register. Indeed AVR32 can only perform 32bit I/O > accesses on registers: using 8bit I/O accesses would read or write garbage > data. > > Fixes: commit b5199d468177 ("tty/serial: at91: add support to FIFOs") In fact, this commit ID is in linux-next, so It might not apply to Linus' tree... > Signed-off-by: Cyrille Pitchen Now that Andy tested the patch: Acked-by: Nicolas Ferre Bye, > --- > Hi all, > > this patch fixes a bug on AVR32 introduced by the support of FIFOs for > AT91. Indeed when FIFOs are enabled they work in Multiple Data mode. > The Multiple Data mode allows to read up to 4 data from the Receiver > Holding Register (RHR) or write up to 4 data into the Transmitter Holding > Register (THR) in a single I/O access. Hence when only one data is to be > read from the RHR or written into the THR, the driver cannot use 32bit I/O > access anymore but must use 8bit I/O access instead. > > For ARM-base AT91 SoCs, 8bit I/O accesses can always be used even when > FIFOs are not available. However AV32 can only use 32bit I/O accesses. > > Since atmel_uart_readb(), resp. atmel_uart_writeb(), was created by the > FIFO support patch to access the RHR, resp. the THR, this patch replaces > it by atmel_uart_read_char(), resp. atmel_uart_write_char(). Hence the > actual width of the I/O access now depends only on the architecture. > > All registers but RHR and THR use 32bit I/O accesses. > > This patch was tested on a at91sam9260ek board. > > Best Regards, > > Cyrille > > ChangeLog: > > v1: initial version > > drivers/tty/serial/atmel_serial.c | 37 +++++++++++++++++++++++++++---------- > 1 file changed, 27 insertions(+), 10 deletions(-) > > diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c > index e91b3b2f0590..5ca5cf3e9359 100644 > --- a/drivers/tty/serial/atmel_serial.c > +++ b/drivers/tty/serial/atmel_serial.c > @@ -204,16 +204,33 @@ static inline void atmel_uart_writel(struct uart_port *port, u32 reg, u32 value) > __raw_writel(value, port->membase + reg); > } > > -static inline u8 atmel_uart_readb(struct uart_port *port, u32 reg) > +#ifdef CONFIG_AVR32 > + > +/* AVR32 cannot handle 8 or 16bit I/O accesses but only 32bit I/O accesses */ > +static inline u8 atmel_uart_read_char(struct uart_port *port) > +{ > + return __raw_readl(port->membase + ATMEL_US_RHR); > +} > + > +static inline void atmel_uart_write_char(struct uart_port *port, u8 value) > { > - return __raw_readb(port->membase + reg); > + __raw_writel(value, port->membase + ATMEL_US_THR); > } > > -static inline void atmel_uart_writeb(struct uart_port *port, u32 reg, u8 value) > +#else > + > +static inline u8 atmel_uart_read_char(struct uart_port *port) > { > - __raw_writeb(value, port->membase + reg); > + return __raw_readb(port->membase + ATMEL_US_RHR); > } > > +static inline void atmel_uart_write_char(struct uart_port *port, u8 value) > +{ > + __raw_writeb(value, port->membase + ATMEL_US_THR); > +} > + > +#endif > + > #ifdef CONFIG_SERIAL_ATMEL_PDC > static bool atmel_use_pdc_rx(struct uart_port *port) > { > @@ -658,7 +675,7 @@ static void atmel_rx_chars(struct uart_port *port) > > status = atmel_uart_readl(port, ATMEL_US_CSR); > while (status & ATMEL_US_RXRDY) { > - ch = atmel_uart_readb(port, ATMEL_US_RHR); > + ch = atmel_uart_read_char(port); > > /* > * note that the error handling code is > @@ -709,7 +726,7 @@ static void atmel_tx_chars(struct uart_port *port) > > if (port->x_char && > (atmel_uart_readl(port, ATMEL_US_CSR) & atmel_port->tx_done_mask)) { > - atmel_uart_writeb(port, ATMEL_US_THR, port->x_char); > + atmel_uart_write_char(port, port->x_char); > port->icount.tx++; > port->x_char = 0; > } > @@ -718,7 +735,7 @@ static void atmel_tx_chars(struct uart_port *port) > > while (atmel_uart_readl(port, ATMEL_US_CSR) & > atmel_port->tx_done_mask) { > - atmel_uart_writeb(port, ATMEL_US_THR, xmit->buf[xmit->tail]); > + atmel_uart_write_char(port, xmit->buf[xmit->tail]); > xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1); > port->icount.tx++; > if (uart_circ_empty(xmit)) > @@ -2294,7 +2311,7 @@ static int atmel_poll_get_char(struct uart_port *port) > while (!(atmel_uart_readl(port, ATMEL_US_CSR) & ATMEL_US_RXRDY)) > cpu_relax(); > > - return atmel_uart_readb(port, ATMEL_US_RHR); > + return atmel_uart_read_char(port); > } > > static void atmel_poll_put_char(struct uart_port *port, unsigned char ch) > @@ -2302,7 +2319,7 @@ static void atmel_poll_put_char(struct uart_port *port, unsigned char ch) > while (!(atmel_uart_readl(port, ATMEL_US_CSR) & ATMEL_US_TXRDY)) > cpu_relax(); > > - atmel_uart_writeb(port, ATMEL_US_THR, ch); > + atmel_uart_write_char(port, ch); > } > #endif > > @@ -2409,7 +2426,7 @@ static void atmel_console_putchar(struct uart_port *port, int ch) > { > while (!(atmel_uart_readl(port, ATMEL_US_CSR) & ATMEL_US_TXRDY)) > cpu_relax(); > - atmel_uart_writeb(port, ATMEL_US_THR, ch); > + atmel_uart_write_char(port, ch); > } > > /* > -- Nicolas Ferre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/