Re: Tearing down DMA transfer setup after DMA client has finished

From	Mark Brown <broonie@kernel.org>
Newsgroups	linux.kernel
Subject	Re: Tearing down DMA transfer setup after DMA client has finished
Date	2016-12-15 12:20 +0100
Message-ID	<sOCeR-55V-3@gated-at.bofh.it> (permalink)
References	(5 earlier) <sMqBb-24F-7@gated-at.bofh.it> <sMx02-615-3@gated-at.bofh.it> <sMxjj-677-3@gated-at.bofh.it> <sMxCG-6dN-19@gated-at.bofh.it> <sMy5I-6DX-43@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

On Fri, Dec 09, 2016 at 07:23:17PM +0100, Mason wrote:
> On 09/12/2016 18:56, Vinod Koul wrote:

> > Right, but in that case the fallback would be PIO mode, and if that is
> > not availble (IIRC some f your devices don't) then reject the usage with
> > EAGAIN.

> Maybe I'm missing something, but I don't see how that would help.
> Take the NAND Flash controller driver, for instance. PIO is not
> an option, because the ECC engine is tied to DMA.

> And failing with -EAGAIN doesn't help the busy looping situation.
> The caller should be put on some kind of queue to wait for a
> "channel ready" event.

Even without the tie into ECC being an issue it seems like falling back
to PIO could produce poor results at the system level - it's likely that
the PIO would be very expensive and take longer than waiting would've
done, increasing the burden on the CPU and slowing things down overall
for userspace.

Back to linux.kernel | Previous | Next | Find similar | Unroll thread

Thread

Re: Tearing down DMA transfer setup after DMA client has finished Mark Brown <broonie@kernel.org> - 2016-12-15 12:20 +0100

csiph-web