[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160317115839.GG2566@sirena.org.uk>
Date: Thu, 17 Mar 2016 11:58:39 +0000
From: Mark Brown <broonie@...nel.org>
To: Michal Suchanek <hramrach@...il.com>
Cc: Maxime Ripard <maxime.ripard@...e-electrons.com>,
Priit Laes <plaes@...es.org>, Chen-Yu Tsai <wens@...e.org>,
linux-spi <linux-spi@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Emilio López <emilio@...pez.com.ar>
Subject: Re: [PATCH 1/2] spi: sun4i: add DMA support
On Thu, Mar 17, 2016 at 12:54:08PM +0100, Michal Suchanek wrote:
> That's what the driver does. The discussion revolves around the fact
> that the driver does not attempt to work (even for very short
> transfers) when the DMA channels are not configured and just bails
> out. AFAICT the channels are always available when the system is
> properly configured and the dmaengine driver loaded.
The driver should tell the core about this constraint so the core can
split the transfers for it.
> Very few device drivers would work with 63byte transfers only and the
> code for manually driving the CS line in case the DMA engine fails to
> configure will necessarily go untested most of the time since most
> systems will have DMA configured properly.
A lot of devices will be perfectly happy with 63 byte transfers,
register accesses for example tend to be much smaller than that. The
manual /CS might be an issue but for most SoCs that is easily addressed
by driving the pin as a GPIO if there's an issue.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists