linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: linux-renesas-soc@vger.kernel.org,
	Magnus Damm <magnus.damm@gmail.com>,
	Gareth Williams <gareth.williams.jx@renesas.com>,
	Phil Edworthy <phil.edworthy@renesas.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jirislaby@kernel.org>,
	linux-serial@vger.kernel.org,
	Milan Stevanovic <milan.stevanovic@se.com>,
	Jimmy Lalande <jimmy.lalande@se.com>,
	Pascal Eberhard <pascal.eberhard@se.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Herve Codina <herve.codina@bootlin.com>,
	Clement Leger <clement.leger@bootlin.com>
Subject: Re: [PATCH 6/7] serial: 8250_dw: Add support for RZ/N1 DMA
Date: Thu, 10 Mar 2022 20:27:43 +0100	[thread overview]
Message-ID: <20220310202743.1a2bf51d@xps13> (raw)
In-Reply-To: <YipCsO+UMcGOqLaG@smile.fi.intel.com>

Hi Andy,

andriy.shevchenko@linux.intel.com wrote on Thu, 10 Mar 2022 20:25:52
+0200:

> On Thu, Mar 10, 2022 at 05:16:49PM +0100, Miquel Raynal wrote:
> > From: Phil Edworthy <phil.edworthy@renesas.com>
> > 
> > The Renesas RZ/N1 devices have a modified Synopsys DW UART. The
> > modifications are mostly related to the DMA handlnig, and so this patch
> > adds support for DMA.  
> 
> > The RZ/N1 UART must be used with the peripheral as the flow
> > controller.  
> 
> (1)
> 
> > This means the DMA length should also be programmed into
> > UART registers.  
> 
> (2)
> 
> Hmm... DMA controller vs. Peripheral flow control is about signalling on the HW
> level on who starts the transaction. This is programmed in the DMA controller
> device driver. Is it what you do in DesignWare DMA patch series?
> 
> Ah, I see now, you set fc here.
> 
> But still it's not clear how (2) and (1) are related.

Both come from the system manual:
(1) table 11.45 "Flow Control Combinations" states that using UART with
DMA requires setting the DMA in the peripheral flow controller mode
regardless of the direction.
(2) chapter 11.6.1.3 "Basic Interface Definitions" explains that the
burst size in the above case must be configured in the peripheral's
register DEST/SRC_BURST_SIZE.

> > Aside from this, there are some points to note about DMA burst sizes.
> > First, DMA must not remove all of the data from the rx FIFO. Otherwise,
> > we do not get a 'character timeout' interrupt, and so do not know that
> > we should push data up the serial stack. Therefore, we have the rx
> > threshold for generating an interrupt set to half the FIFO depth (this
> > is the default for 16550A), and set the DMA burst size when reading the
> > FIFO to a quarter of the FIFO depth.
> > 
> > Second, when transmitting data using DMA, the burst size must be limited
> > to 1 byte to handle then case when transmitting just 1 byte. Otherwise
> > the DMA doesn't complete the burst, and nothing happens.  
> 
> ...
> 
> > +/* Offsets for the Renesas RZ/N1 DesignWare specific registers */
> > +/* DMA Software Ack */
> > +#define RZN1_UART_DMASA			0xa8  
> 
> Is it specific to Renesas? IIRC it's Synopsys DesignWare register, makes
> sense to use appropriate prefix or no prefix.

I have no idea, I can use a more common prefix.

> 
> ...
> 
> > +#define RZN1_UART_xDMACR_1_WORD_BURST	0
> > +#define RZN1_UART_xDMACR_4_WORD_BURST	BIT(1)
> > +#define RZN1_UART_xDMACR_8_WORD_BURST	(BIT(1) | BIT(2))  
> 
> This looks like incorrect use of BIT() macro.
> Please, use plain decimal integers. Something like
> 
> 	1	(0 << 1)
> 	4	(1 << 1)
> 	8	(3 << 1)
> 
> If I'm mistaken, describe the meaning of each bit there.

Matter of taste, I believe, whatever.

> 
> ...
> 
> > +static void rzn1_8250_handle_irq(struct uart_port *port, unsigned int iir)
> > +{
> > +	struct uart_8250_port *up = up_to_u8250p(port);
> > +	struct uart_8250_dma *dma = up->dma;
> > +	unsigned char status;  
> 
> > +	if (up->dma && dma->rx_running) {  
> 
> With
> 
> 	if (!)up->dma && dma->rx_running))
> 		return;
> 
> maybe easier to read the rest.
> 
> > +		status = port->serial_in(port, UART_LSR);
> > +		if (status & (UART_LSR_DR | UART_LSR_BI)) {
> > +			/* Stop the DMA transfer */
> > +			writel(0, port->membase + RZN1_UART_RDMACR);
> > +			writel(1, port->membase + RZN1_UART_DMASA);
> > +		}
> > +	}
> > +}  
> 
> ...
> 
> > +	if (d->is_rzn1 && ((iir & 0x3f) == UART_IIR_RX_TIMEOUT))
> > +		rzn1_8250_handle_irq(p, iir);  
> 
> A few years ago it was a discussion about broken timeout on some platforms
> with Synopsys DesignWare UART + DMA. Can it be that this is actually required
> for all of them that uses same combination of IPs?

I am not sure because I went through the fix for this issue and for me
there are two different things

> 
> ...
> 
> > +static u32 rzn1_get_dmacr_burst(int max_burst)
> > +{  
> 
> > +	u32 val = 0;  
> 
> Redundant assignment and variable itself. Use return statements directly.
> 
> > +	if (max_burst >= 8)
> > +		val = RZN1_UART_xDMACR_8_WORD_BURST;
> > +	else if (max_burst >= 4)
> > +		val = RZN1_UART_xDMACR_4_WORD_BURST;
> > +	else
> > +		val = RZN1_UART_xDMACR_1_WORD_BURST;
> > +
> > +	return val;
> > +}  
> 
> ...
> 
> > +static int rzn1_dw8250_tx_dma(struct uart_8250_port *p)
> > +{
> > +	struct uart_port		*up = &p->port;
> > +	struct uart_8250_dma		*dma = p->dma;
> > +	struct circ_buf			*xmit = &p->port.state->xmit;
> > +	int tx_size;
> > +	u32 val;
> > +
> > +	if (uart_tx_stopped(&p->port) || dma->tx_running ||
> > +	    uart_circ_empty(xmit))
> > +		return 0;
> > +
> > +	tx_size = CIRC_CNT_TO_END(xmit->head, xmit->tail, UART_XMIT_SIZE);  
> 
> > +	writel(0, up->membase + RZN1_UART_TDMACR);
> > +	val = rzn1_get_dmacr_burst(dma->txconf.dst_maxburst);
> > +	val |= tx_size << RZN1_UART_xDMACR_BLK_SZ_OFFSET;
> > +	val |= RZN1_UART_xDMACR_DMA_EN;
> > +	writel(val, up->membase + RZN1_UART_TDMACR);  
> 
> Can this be added as a callback to the serial8250_tx_dma()?
> Ditto for Rx counterpart.

Fair enough.

> 
> > +	return serial8250_tx_dma(p);
> > +}  
> 
> ...
> 
> > +	data->is_rzn1 = of_device_is_compatible(dev->of_node, "renesas,rzn1-uart");  
> 
> Device property API.

I'm not sure to get what you mean here again. The Information is in the
device tree, the compatible string already gives us what we need, why
would we need a device property? (or perhaps I misunderstand what
"device property API" means)
> 
> >  	/* Always ask for fixed clock rate from a property. */
> >  	device_property_read_u32(dev, "clock-frequency", &p->uartclk);  
> 


Thanks,
Miquèl

  reply	other threads:[~2022-03-10 19:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-10 16:16 [PATCH 0/7] RZN1 UART DMA support Miquel Raynal
2022-03-10 16:16 ` [PATCH 1/7] serial: 8250_dma: Use ->tx_dma function pointer to start next DMA Miquel Raynal
2022-03-10 17:59   ` Andy Shevchenko
2022-03-10 16:16 ` [PATCH 2/7] serial: 8250_dw: Move the per-device structure Miquel Raynal
2022-03-10 18:01   ` Andy Shevchenko
2022-03-10 16:16 ` [PATCH 3/7] serial: 8250_dw: Use a fallback CPR value if not synthesized Miquel Raynal
2022-03-10 18:02   ` Andy Shevchenko
2022-03-10 19:01     ` Miquel Raynal
2022-03-11 17:05       ` Andy Shevchenko
2022-03-10 16:16 ` [PATCH 4/7] serial: 8250_dw: Provide the RZN1 CPR register value Miquel Raynal
2022-03-10 16:16 ` [PATCH 5/7] serial: 8250_dw: Add a dma_capable bit to the platform data Miquel Raynal
2022-03-10 18:06   ` Andy Shevchenko
2022-03-10 19:13     ` Miquel Raynal
2022-03-11 17:09       ` Andy Shevchenko
2022-03-10 16:16 ` [PATCH 6/7] serial: 8250_dw: Add support for RZ/N1 DMA Miquel Raynal
2022-03-10 18:25   ` Andy Shevchenko
2022-03-10 19:27     ` Miquel Raynal [this message]
2022-03-11 17:14       ` Andy Shevchenko
2022-03-11  9:39   ` Geert Uytterhoeven
2022-03-11  9:51     ` Geert Uytterhoeven
2022-03-11  9:59       ` Miquel Raynal
2022-03-11 14:48         ` [PATCH] serial: 8250_dw: Use device tree match data Emil Renner Berthing
2022-03-11 17:27           ` Andy Shevchenko
2022-03-16 14:40           ` Miquel Raynal
2022-03-10 16:16 ` [PATCH 7/7] ARM: dts: r9a06g032: Fill the UART DMA properties Miquel Raynal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220310202743.1a2bf51d@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=clement.leger@bootlin.com \
    --cc=gareth.williams.jx@renesas.com \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=herve.codina@bootlin.com \
    --cc=jimmy.lalande@se.com \
    --cc=jirislaby@kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=milan.stevanovic@se.com \
    --cc=pascal.eberhard@se.com \
    --cc=phil.edworthy@renesas.com \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).