Re: [PATCH v4 2/4] spi: Split spi message into max_dma_len size chunks

From: Lukas Wunner <lukas@wunner.de>
To: Mark Brown <broonie@kernel.org>
Cc: stefan.wahren@i2se.com, dri-devel@lists.freedesktop.org,
	linux-spi@vger.kernel.org, linux-rpi-kernel@lists.infradead.org,
	meghana.madhyastha@gmail.com, kernel@martin.sperl.org
Subject: Re: [PATCH v4 2/4] spi: Split spi message into max_dma_len size chunks
Date: Fri, 12 Apr 2019 12:54:48 +0200	[thread overview]
Message-ID: <20190412105448.6xamxj2wtuu3yxvt@wunner.de> (raw)
In-Reply-To: <20190412102206.GG6909@sirena.org.uk> <20190412094721.GE6909@sirena.org.uk>

On Fri, Apr 12, 2019 at 10:47:21AM +0100, Mark Brown wrote:
> On Thu, Apr 11, 2019 at 11:02:26PM +0200, Noralf Trønnes wrote:
> > Den 11.04.2019 20.18, skrev Lukas Wunner:
> > > On Thu, Apr 11, 2019 at 06:42:33PM +0200, Noralf Trønnes wrote:
> > > > @@ -1299,6 +1299,11 @@ static void __spi_pump_messages(struct spi_controller *ctlr, bool in_kthread)
> 
> > > >  	trace_spi_message_start(ctlr->cur_msg);
> 
> > > > +	ret = spi_split_transfers_maxsize(ctlr, ctlr->cur_msg, ctlr->max_dma_len,
> > > > +					  GFP_KERNEL | GFP_DMA);
> 
> > > Um, shouldn't this be ifdef'ed to CONFIG_HAS_DMA?
> 
> > Maybe, I don't know. Mark didn't mentioned it when he commented on a
> > previous version of this. Some hate ifdef's and want to avoid them, some
> > don't.
> 
> I *think* we managed to fix all the architectures to at least stub out
> the DMA interfaces, it's such a pointless thing to have conditional -
> it really only makes a difference for build coverage.

My point was that the call to spi_split_transfers_maxsize() shouldn't
be called on non-DMA-capable platforms in the first place (because it's
DMA-specific).

> On Fri, Apr 12, 2019 at 12:03:35PM +0200, kernel@martin.sperl.org wrote:
> > There is a register of the SPI controller where you have to configure the
> > number of bytes that it will request via DMA (primarily support transfers
> > that are not a multiple of 4 - the data is transferred by DMA as words).
> > So it is not really related to the general DMA implementation but to the
> > DMA (request) support of the SPI controller.

Right, if the transfer is not a multiple of 4, the DMA engine will
write up to 3 surplus bytes to the TX FIFO.  The SPI controller
knows how many bytes it has to send because the length is set via
its DLEN register first.  Internally it counts down the DLEN register
to zero and then stops clocking out bytes.  The surplus bytes written
by the DMA engine are thus left as residue in the TX FIFO and have
to be flushed by setting the CLEAR_TX bit in the CS register.

Thanks,

Lukas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel