All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-renesas-soc@vger.kernel.org, linux-iio@vger.kernel.org,
	linux-input@vger.kernel.org, linux-media@vger.kernel.org
Subject: Re: [PATCH v6 0/9] i2c: document DMA handling and add helpers for it
Date: Wed, 8 Nov 2017 22:50:37 +0000	[thread overview]
Message-ID: <20171108225037.i4dx5iu5zxc542oq@sirena.co.uk> (raw)
In-Reply-To: <20171104202009.3818-1-wsa+renesas@sang-engineering.com>

[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]

On Sat, Nov 04, 2017 at 09:20:00PM +0100, Wolfram Sang wrote:

> While previous versions until v3 tried to magically apply bounce buffers when
> needed, it became clear that detecting DMA safe buffers is too fragile. This
> approach is now opt-in, a DMA_SAFE flag needs to be set on an i2c_msg. The
> outcome so far is very convincing IMO. The core additions are simple and easy
> to understand. The driver changes for the Renesas IP cores became easy to
> understand, too.

It would really help a lot of things if there were a way to detect if a
given memory block is DMA safe, having to pass the information around
causes so much pain.  There's the fun with vmalloc() mappings too
needing to be handled differently too though that's less likely to bite
I2C.

> I am still not sure how we can teach regmap this new flag. regmap is a heavy
> user of I2C, so broonie's opinion here would be great to have. The rest should
> mostly be updating individual drivers which can be done when needed.

We pretty much assume everything is DMA safe already, the majority of
transfers go to/from kmalloc()ed scratch buffers so actually are DMA
safe but for bulk transfers we use the caller buffer and there might be
some problem users.  I can't really think of a particularly good way of
handling it off the top of my head, obviously not setting the flag is
easy but doesn't get the benefit while always using a bounce buffer
would involve lots of unneeded memcpy().  Doing _dmasafe() isn't
particularly appealing either but might be what we end up with.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2017-11-08 22:50 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-04 20:20 [PATCH v6 0/9] i2c: document DMA handling and add helpers for it Wolfram Sang
2017-11-04 20:20 ` Wolfram Sang
2017-11-04 20:20 ` [PATCH v6 1/9] i2c: add a message flag for DMA safe buffers Wolfram Sang
2017-11-04 20:20 ` [PATCH v6 2/9] i2c: add helpers to ease DMA handling Wolfram Sang
2017-11-04 20:20   ` Wolfram Sang
2017-11-04 20:20 ` [PATCH v6 3/9] i2c: dev: mark RDWR buffers as DMA_SAFE Wolfram Sang
2017-11-04 20:20   ` Wolfram Sang
2017-11-04 20:20 ` [PATCH v6 4/9] i2c: refactor i2c_master_{send_recv} Wolfram Sang
2017-11-11  0:03   ` Jonathan Cameron
2017-11-11  0:03     ` Jonathan Cameron
2017-11-04 20:20 ` [PATCH v6 5/9] i2c: add i2c_master_{send|recv}_dmasafe Wolfram Sang
2017-11-11  0:08   ` Jonathan Cameron
2017-11-11  0:08     ` Jonathan Cameron
2017-11-04 20:20 ` [PATCH v6 6/9] i2c: smbus: use DMA safe buffers for emulated SMBus transactions Wolfram Sang
2017-11-11  0:13   ` Jonathan Cameron
2017-11-11  0:13     ` Jonathan Cameron
2017-11-04 20:20 ` [PATCH v6 7/9] i2c: add docs to clarify DMA handling Wolfram Sang
2017-11-04 20:20 ` [PATCH v6 8/9] i2c: sh_mobile: use core helper to decide when to use DMA Wolfram Sang
2017-11-04 20:20 ` [PATCH v6 9/9] i2c: rcar: skip DMA if buffer is not safe Wolfram Sang
2017-11-08 22:50 ` Mark Brown [this message]
2017-11-27 18:51   ` [PATCH v6 0/9] i2c: document DMA handling and add helpers for it Wolfram Sang
2017-11-28 15:34     ` Mark Brown
2017-12-03 19:43       ` Wolfram Sang
2017-12-04 22:05         ` Mark Brown
2017-12-04 22:05           ` Mark Brown
2017-12-05 11:00           ` Jonathan Cameron
2017-12-05 11:00             ` Jonathan Cameron
2017-12-04 21:25 ` Wolfram Sang

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=20171108225037.i4dx5iu5zxc542oq@sirena.co.uk \
    --to=broonie@kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=wsa+renesas@sang-engineering.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 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.