All of lore.kernel.org
 help / color / mirror / Atom feed
From: broonie@kernel.org (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/2] spi: spi-imx: enable dma support for escpi controller
Date: Tue, 14 Jan 2014 21:55:48 +0000	[thread overview]
Message-ID: <20140114215548.GD15567@sirena.org.uk> (raw)
In-Reply-To: <201401142238.32262.marex@denx.de>

On Tue, Jan 14, 2014 at 10:38:32PM +0100, Marek Vasut wrote:

> I know the MXC SPI controller works in full-duplex mode, thus must have two 
> equally big buffers (one for RX and one for TX) even if used in half-duplex 
> mode, right?

We should factor this stuff out into the core, a bunch of controllers
have that limitation.

> The problem I perceive here is that when I do for example 4 MB long continuous 
> half-duplex transfer with the IMX SPI, your code will happily allocate 4MB big 
> buffer, right ?

Or try to - the other trick here is getting 4MB of contiguous memory in
the first place (unless there's an IOMMU making everything pretty).

> Hence my suggestion, won't it be better to split such long transfers into a 
> chain of DMA descriptors AND use a small (say, 16KiB) buffer for the unwanted 
> direction ? This way, you would allocate the small 16KiB block only once (heck, 
> you can even allocate it in probe() ), and each descriptor would point to this 
> block, overwriting it or sourcing zeroes from it .

Yes, indeed.  I've half started working on some dmaengine code and was
going to do something like this as part of it - the idea was to have the
core generate a sg_list to pass to devices with DMAable transfers which
would enable this sort of rewriting and would also mean we could do
things like scatter/gather more effectively.  Not got as far as actually
getting things into a nice shape for that though.  There's a lot of
common patterns here which we shouldn't be open coding.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140114/8e412fb9/attachment.sig>

  reply	other threads:[~2014-01-14 21:55 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-03 22:53 [PATCH v2 1/2] spi: spi-imx: enable dma support for escpi controller Frank Li
2014-01-03 22:53 ` [PATCH v2 2/2] ARM: dts: imx: enable dma for spi Frank Li
2014-01-06  5:58   ` Shawn Guo
2014-01-09 22:56 ` [PATCH v2 1/2] spi: spi-imx: enable dma support for escpi controller Frank Li
2014-01-14 21:49   ` Mark Brown
2014-01-14  6:02 ` Shawn Guo
2014-01-14 21:39   ` Marek Vasut
2014-01-14 21:52   ` Frank Li
2014-01-15  6:17     ` Shawn Guo
2014-01-14 21:38 ` Marek Vasut
2014-01-14 21:55   ` Mark Brown [this message]
2014-01-14 22:02     ` Marek Vasut
2014-01-14 22:13       ` Mark Brown
2014-01-14 22:25         ` Marek Vasut

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=20140114215548.GD15567@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.